Unlike redo copy latch, checkpoint queue latch latch is being held very briefly. This indicates that the block is linked very fast, and that the extra time is spent elsewhere. That overhead is the main focus of this article. With DTrace, we can trace offsets [1]. An offset is the position of the instruction in bytes relative to the function start. As we shall see, we can get useful information by analyzing an offset trace even without disassembling the code.
In addition to offsets, the following script traces latch allocations within the function. The first column is the timing in microseconds relative to the function entry. Each LRU latch protects a working data set [2]. There are indeed working data sets:.
The loop iterates over the working data sets. Otherwise, the shared pool is used. Set this initialization parameter if the database reports an error in the alert. The message should resemble the following:. Configuring the large pool prevents RMAN from competing with other subsystems for the same memory. Requests for contiguous memory allocations from the shared pool are usually small under 5 KB in size. However, it is possible that a request for a large contiguous memory allocation can either fail or require significant memory housekeeping to release the required amount of contiguous memory.
Although the shared pool may be unable to satisfy this memory request, the large pool is able to do so. The large pool does not have a least recently used LRU list; the database does not attempt to age memory out of the large pool. There are several tasks you can perform to identify and remedy bottlenecks that affect RMAN's performance on tape backups:. In some situations when performing a backup to tape, RMAN may not be able to send data blocks to the tape drive fast enough to support streaming.
For example, during an incremental backup, RMAN only backs up blocks changed since a previous datafile backup as part of the same strategy. If you do not turn on change tracking, RMAN must scan entire datafiles for changed blocks, and fill output buffers as it finds such blocks. If there are not many changed blocks, RMAN may not fill output buffers fast enough to keep the tape drive streaming. You can improve performance by increasing the degree of multiplexing used for backing up.
This increases the rate at which RMAN fills tape buffers, which makes it more likely that buffers are sent to the media manager fast enough to maintain streaming. If writing to tape is the source of a bottleneck for your backups, consider using incremental backups as part of your backup strategy.
Incremental level 1 backups write only the changed blocks from datafiles to tape, so that any bottleneck on writing to tape has less impact on your overall backup strategy. In particular, if tape drives are not locally attached to the node running the database being backed up, then incremental backups can be faster.
If none of the previous steps improves backup performance, then try to determine the exact source of the bottleneck. If the rate is lower than the rate that the device specifies, then consider tuning this aspect of the backup and restore process. This section describes instance recovery, and how Oracle's Fast-Start Fault Recovery improves availability in the event of a crash or instance failure. It also offers guidelines for tuning the time required to perform crash and instance recovery.
Instance and crash recovery are the automatic application of redo log records to Oracle data blocks after a crash or system failure. During normal operation, if an instance is shut down cleanly as when using a SHUTDOWN IMMEDIATE statement , rather than terminated abnormally, then the in-memory changes that have not already been written to the datafiles on disk are written to disk as part of the checkpoint performed during shutdown.
However, if a single instance database crashes or if all instances of an Oracle Real Application Cluster configuration crash, then Oracle performs crash recovery at the next startup. If one or more instances of an Oracle Real Application Cluster configuration crash, then a surviving instance performs instance recovery automatically.
Instance and crash recovery occur in two steps: cache recovery followed by transaction recovery. The database can be opened as soon as cache recovery completes, so improving the performance of cache recovery is important for increasing availability.
During the cache recovery step, Oracle applies all committed and uncommitted changes in the redo log files to the affected data blocks. The work required for cache recovery processing is proportional to the rate of change to the database update transactions each second and the time between checkpoints.
To make the database consistent, the changes that were not committed at the time of the crash must be undone in other words, rolled back. During the transaction recovery step, Oracle applies the rollback segments to undo the uncommitted changes. Periodically, Oracle records a checkpoint. A checkpoint is the highest system change number SCN such that all data blocks less than or equal to that SCN are known to be written out to the data files. If a failure occurs, then only the redo records containing changes at SCNs higher than the checkpoint need to be applied during recovery.
The duration of cache recovery processing is determined by two factors: the number of data blocks that have changes at SCNs higher than the SCN of the checkpoint, and the number of log blocks that need to be read to find those changes. Frequent checkpointing writes dirty buffers to the datafiles more often than otherwise, and so reduces cache recovery time in the event of an instance failure. If checkpointing is frequent, then applying the redo records in the redo log between the current checkpoint position and the end of the log involves processing relatively few data blocks.
Burleson is the American Team Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals. Feel free to ask questions on our Oracle forum. Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise.
AND f. The results for a small system running on a laptop:. MTTR Advisor. These other parameters are:. Any setting above defaults back to Due to what the parameter represents, the two-phase instance recovery process of roll forward and roll back, some amount of time is going to be spent on startup to apply committed transactions not yet written to datafiles and to roll back the uncommitted ones.
Therefore, a setting of 0 and obviously anything less than that is not realistic. Whether the time is 10 seconds, 30 seconds, or 2 minutes, examples depend, to a degree, on how the redo logs are sized.
The results of the following query show the system is pretty much calibrated. If the advisor is not started, the following graph will not appear under the Instance Recovery section of the Recovery Settings page in OEM. Burleson, and Steve Callan.
0コメント