Multiple indexes to fix

Posted by James Palmer on 30-Sep-2016 08:51

A client has had their system wiped out by Ransomware. After Imaging not running so they've reverted to an OS snapshot of running databases because it's more recent than the latest full backups. I truncated the BI on the databases and got them served up ok and everything is pretty much ok, except for the indexes. Keep getting the message that records can't be deleted from the indexes. I'm running idxfix on the indexes, but was wondering if there's any reason I can't run idxfix on different tables in different proenv sessions?

All Replies

Posted by George Potemkin on 30-Sep-2016 08:59

To reports the errors you can run a few idxfix sessions in parallel starting them with the -NL parameter.

Then you can use the text of the errors to prepare an input file for idxfix/1. scan records from recid to the same recid and one idxfix session will be able to fix the index corruption almost instantly.

Posted by gus bjorklund on 30-Sep-2016 09:00

don’t mess about with index fix.

rebuild all indexes.

Posted by cjbrandt on 30-Sep-2016 09:31

with 10.2B08 you have the new idxbuild options available so it may be faster than fixing indexes 1 at a time with idxfix.  The other bonus is you don't have to worry about disabling AI before running idxbuild. <g>

Posted by James Palmer on 30-Sep-2016 10:03

Ok we're going for the idxbuild option. What parameters would you recommend?

32bit OS unfortunately.

Workgroup RDBMS.

2 x 2GHz processors

8GB RAM, bearing in mind it's 32bit OS though

190GB free space on the DB drive.

Posted by cjbrandt on 30-Sep-2016 19:37

well before I offered my 2 cents, I never considered a workgroup db and a 32 bit product.  I don't know if the new idxbuild options are available for a workgroup db.  I guess you could try on a test box and see what it does.

this is what I would use for a windows server with a few cpu and nothing else on the server.  if the server manages other items, then lower TF to something around 25.

proutil dbname -C idxbuild all -B 1024  -TF 75 -TB 64 -TM 32 -SG 64 -datascanthreads 4 -threadnum 2 -mergethreads 4 -pfactor 80 

Posted by Rob Fitzpatrick on 30-Sep-2016 20:02

The -threadnum param is Enterprise-only.  You should also add either -T or -SS to direct temp-file I/O to a non-database disk, if possible.  Remember to back up before idxbuild.  ;)

Posted by James Palmer on 01-Oct-2016 10:50

Thanks everyone. It finished in a couple of hours so whatever I did wasn't too bad. And the index issues are sorted. Phew!

Posted by gus bjorklund on 01-Oct-2016 16:32

make sure you have good db backups in case your malware is still there.

the whole server should really be rebuilt from bare metal.

Posted by James Palmer on 01-Oct-2016 18:02

The server Has been rebuilt, in fact the old disk drives have been shredded and new ones installed. Not our job to manage this thankfully.

Posted by Dmitri Levin on 07-Oct-2016 13:17

>>with 10.2B08

>>The other bonus is you don't have to worry about disabling AI before running idxbuild.

Sorry, I did not understand. I believe AI need to be disabled before running  idxbuild in any current version of OE.

$ proutil sports -C idxbuild

OpenEdge Release 11.6.1 as of Fri Feb 19 19:00:44 EST 2016

You cannot perform this operation with after-imaging or 2phase enabled (1525)

Posted by cjbrandt on 07-Oct-2016 16:06

Sorry - poor attempt at humor.  In the original post it was mentioned that the db didn't have AI enabled.

Posted by Dmitri Levin on 12-Oct-2016 13:08

That is a very sensitive topic for us to smile. Inability to add an index for a decent size table w/o a stop of AI and a subsequent need to reseed replication raises the questions "Why are we still using OpenEdge?". The number of skeptics that point me in the direction of SQL or Oracle is growing every year.

Posted by ctoman on 12-Oct-2016 13:34

Then go ahead Dmitri use Oracle or SQL.  Big deal you have to do two extra steps.  

Posted by Dmitri Levin on 12-Oct-2016 13:44

These two extra steps ( backup, transfer to remote site and restore ) take about 2 days with our 1.5 TB database, Being without DR for 2 days for some companies is a big deal.

Not all databases are born equal :)

Posted by ctoman on 12-Oct-2016 13:49

You must be using the native Progress OE backup utility (probkup).  I think it is just poor planning.

Posted by James Palmer on 12-Oct-2016 15:10

So what is the alternative and how is it better? Last I checked anything other than probkup was adding risk to an area you don't need risk. And for seeding replication you have to use it anyway.

Sent from my Android phone

This thread is closed