I dont have much help to offer, only some history. I do not think there was
ever any performance work done
in this area, so hopefully there is some low hanging fruit. I have a fuzzy
memory that restart recover undo was
really inefficient as there is not a good way to walk backward in the log
Thanks for the pointes Kristian. I definitely will be in this code shortly.
The system appeared to not be CPU bound but rather I/O bound. I need to get a
test setup into a condition like at the customer first and then start doing
some debugging and profiling to see where things are.
Den 20.04.2016 16.46, skrev Bergquist, Brett:
> It took longer (and never finished) to process the recovery logs file that it
> did to restore the database from the previous night from backup (that took 6
> hours to "untar") At about 14 hours, the recovery log files were not
> finished
It took longer (and never finished) to process the recovery logs file that it
did to restore the database from the previous night from backup (that took 6
hours to "untar") At about 14 hours, the recovery log files were not finished
processing so we had to give up and restore from backup.
So what would be useful would be something like:
Performing database recovery
Starting analysis pass
215 transactions detected to be processed
Starting redo pass
…. anything that could give some feedback
Starting undo pass
….anything that could give some feedback
I'm afraid all I can add is:
We are doing a “truss -p 2>&1 | grep open” but what I am seeing right now
is that one complete pass was made through the logs and I thought that it was
about done. Now it is going into a pattern where it processes something like
log359.dat
log358.dat
…
> Another issue with about 1100 log files needing to be
> processed after a restart of the database network server.
Ouch. :(
> is any logging that can tell when pass the database recovery is on
Perhaps use an operating system level monitoring tool (Process Monitor
on Windows, strace on Linux,
