monitor and assess Redo Apply performance
Query the V$RECOVERY_PROGRESS view to monitor and assess Redo Apply
performance. This view contains the following columns:
V$RECOVERY_PROGRESS
COLUMN DESCRIPTION
Average
Apply Rate
Redo Applied / Elapsed Time includes time spent actively applying redo and
time spent waiting for redo to arrive
Active
Apply Rate
Redo Applied / Active Time is a moving average over the last 3 mins.
Excludes time spent waiting for redo to arrive.
Apply
Time/Log
Active apply time averaged per redo log file.
Checkpoint
Time/Log
Log boundary checkpoint time averaged per redo log file
Last
Applied
Redo
SCN and timestamp of the last redo applied. This is the time as stored in
the redo stream and used to compare where the standby database is
relative to the primary.
The most useful statistic is the Active Apply rate because the Average Apply Rate
includes idle time spent waiting for redo to arrive, making the Average Apply Rate
a poor indicator of apply performance.
In a Data Guard physical standby environment, it is important to determine if the
standby database can recover redo as fast as, or faster than, the primary database
can generate redo. The simplest way to determine application throughput in terms
of redo volume is to collect Automatic Workload Repository (AWR) reports on the
primary database during normal and peak workloads, and determine the number of
bytes per second of redo data the production database is producing. You can then
compare the speed at which redo is being generated with the Active Apply Rate
columns in the V$RECOVERY_PROGRESS view to determine if the standby
database is able to maintain the pace.
It is not necessary to tune redo apply If the standby database is able to keep pace
with the primary database during peak periods. If your examination of the
performance statistics described above indicate that redo apply cannot keep pace,
and that the resulting apply lag is not the result of an archive log gap, then proceed
with tuning as described below.
performance. This view contains the following columns:
V$RECOVERY_PROGRESS
COLUMN DESCRIPTION
Average
Apply Rate
Redo Applied / Elapsed Time includes time spent actively applying redo and
time spent waiting for redo to arrive
Active
Apply Rate
Redo Applied / Active Time is a moving average over the last 3 mins.
Excludes time spent waiting for redo to arrive.
Apply
Time/Log
Active apply time averaged per redo log file.
Checkpoint
Time/Log
Log boundary checkpoint time averaged per redo log file
Last
Applied
Redo
SCN and timestamp of the last redo applied. This is the time as stored in
the redo stream and used to compare where the standby database is
relative to the primary.
The most useful statistic is the Active Apply rate because the Average Apply Rate
includes idle time spent waiting for redo to arrive, making the Average Apply Rate
a poor indicator of apply performance.
In a Data Guard physical standby environment, it is important to determine if the
standby database can recover redo as fast as, or faster than, the primary database
can generate redo. The simplest way to determine application throughput in terms
of redo volume is to collect Automatic Workload Repository (AWR) reports on the
primary database during normal and peak workloads, and determine the number of
bytes per second of redo data the production database is producing. You can then
compare the speed at which redo is being generated with the Active Apply Rate
columns in the V$RECOVERY_PROGRESS view to determine if the standby
database is able to maintain the pace.
It is not necessary to tune redo apply If the standby database is able to keep pace
with the primary database during peak periods. If your examination of the
performance statistics described above indicate that redo apply cannot keep pace,
and that the resulting apply lag is not the result of an archive log gap, then proceed
with tuning as described below.
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22034023/viewspace-1068860/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Using V$BACKUP_ASYNC_IO / V$BACKUP_SYNC_IO to Monitor RMAN PerformanceORM
- PerformanceORM
- Egress-Assess-出口資料安全功能測試
- 【REDO】Oracle redo advice-sqlOracle RedoSQL
- 【REDO】Oracle redo undo 學習Oracle Redo
- 2788647047_monitor
- 【REDO】Oracle redo內部結構Oracle Redo
- MySQL redoMySql
- MySQL Performance SchemaMySqlORM
- Postman的Monitor功能Postman
- Verilog 監控 Monitor
- webpack Performance: The Comprehensive GuideWebORMGUIIDE
- Performance Without the Event LoopORMOOP
- 設定performance模式ORM模式
- Boost UDP Transaction PerformanceUDPORM
- Oracle Redo and UndoOracle Redo
- MySQL:Redo & binlogMySql
- Azure Monitor(二)Log Analytics
- JavaScript apply()JavaScriptAPP
- Oracle redo解析之-1、oracle redo log結構計算Oracle Redo
- synchronized的monitor監視器synchronized
- [譯] Performance testing of Flutter appsORMFlutterAPP
- 1383. Maximum Performance of a TeamORM
- Performance and High-Availability OptionsORMAI
- Performance --- 前端效能監控ORM前端
- Guideline 2.3.10 - Performance - Accurate MetadataGUIIDEORM
- MySQL Performance Schema詳解MySqlORM
- mysql之 redo logMySql
- this、apply、call、bindAPP
- Oracle 效能調優工具:SQL MonitorOracleSQL
- plsql developer工具生成sql monitor reportSQLDeveloper
- oracle.Performance.Tuning筆記OracleORM筆記
- chrome devtools使用詳解——PerformanceChromedevORM
- performance_schema詳解一ORM
- Oracle Advanced Performance Tuning Scripts(轉)OracleORM
- [Javascript] Using IIFE to improve code performanceJavaScriptORM
- undo log和redo log
- Redo Byte Address (RBA)(轉)
- oracle的redo和undoOracle