The RecoveryThreads attribute determines the number of threads used to rebuild indexes during recovery.
If RecoveryThreads=1, during recovery, indexes that must be rebuilt are done serially. If you have enough processors available to work on index rebuilds on your computer, setting this attribute to a number greater than 1 can improve recovery performance. The performance improvement occurs only if different processors can work on different indexes. There is no parallelism in index rebuild within the same index.
The value of RecoveryThreads can be any value up to the number of CPUs available on your system.
Database recovery in TimesTen consists of several steps:
1. Read the most recent checkpoint file from disk and load it into the database shared memory segment. This is primarily an I/O bound activity. The time taken will depend on the size of the checkpoint file and the speed of your storage subsystem. This is a sequential activity (not parallelised in any way)
2. Replay all pending transactions from the transaction logs. This is also a sequential activity. This step is both CPU and I/O intensive. The time taken depends on how many pending transactions need to be replayed.
3. When the end of the log stream is reached, rollback any open transactions. This step is usually short but sometimes it may take significant time (e.g. if it has to roll back an uncomiitted update of 1M rows). Same comments apply as for (2).
4. Any indexes that were modified during steps 2 and 3 are dropped and re-built. This is mainly a CPU intensive operation. The time taken depends on the number of indexes to be rebuilt, the size of the underlying tables, the setting of the RecoveryThreads parameter and the number of CPUs in the system.
For startup after a clean shutdown steps 2, 3 and 4 are effectively no-ops and take virtually no time.
So, modifying RecoveryThreads can only help with step (4) and only in the case where recovery is needed. Whether it will actually help depends on the factors I have listed above. To spped up step (1) you need to use faster storage. To speed up (2) you need faster CPUs and maybe faster storage.
Thanks for this data, I will talk with sysadmin in order to get technical information and check on disk.
I am very worried because yesterday the server where my database is running brokedown, so to restart server took close to 20 minutes adding to load database to memory 20 more minutes, I lost close to 40 minutes on production.
I will review all external factors which could affect my database load.
It seems that your database is corrupted and you need database recovery software. I have used [http://www.recoverdatatools.com/oracle-recovery.html] from website recoverdatatools.com/oracle-recovery.html to recover corrupted database. They provide free download sample also.
It seems that your database is corrupted and you need database recovery software. You should use [Oracle database recovery software|http://www.recoverdatatools.com/oracle-recovery.html] to recover corrupted database. They provide free download sample also.