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?
10.2B08
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.
don’t mess about with index fix.
rebuild all indexes.
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>
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.
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
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. ;)
Thanks everyone. It finished in a couple of hours so whatever I did wasn't too bad. And the index issues are sorted. Phew!
make sure you have good db backups in case your malware is still there.
the whole server should really be rebuilt from bare metal.
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.
>>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)
Sorry - poor attempt at humor. In the original post it was mentioned that the db didn't have AI enabled.
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.
Then go ahead Dmitri use Oracle or SQL. Big deal you have to do two extra steps.
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 :)
You must be using the native Progress OE backup utility (probkup). I think it is just poor planning.
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