It's like that. We had one take a processor-week. Be patient. It really
can repair a badly damaged database; it does a lot of checking.
AUDITDB is to be avoided at all costs. Since V2, there are a lot of ways
to make it less frequent. Set yourself up with roll-forward recovery,
mirroring, and everything else, to minimize the chances you will ever
need it. Split your server in two, to cut AUTITDB running time in half.
Use ADSM's software mirroring even if you have RAID disks.
But on the other hand, the last time I had to run one, I knew (with IBM's
help) that the problem was in a disk storage pool, so I made it migrate
as much as possible to tape, and then fired it off with a parameter to
auidit only the disk storage pools, and it took only 20 minutes to audit
the mostly empty disk storage pools.
P.S. Whomever has that 1.6meg BMP file in their sig, STOP THAT!
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Aliases: u52983 AT uicvm.uic DOT edu R.Deschner AT uic
DOT edu
|