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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 效能監視器- Performance MonitorORM
- DATA GUARD 跨平臺支援(Redo Apply)APP
- DataGuard之Apply Services(redo應用和SQL應用)APPSQL
- Using V$BACKUP_ASYNC_IO / V$BACKUP_SYNC_IO to Monitor RMAN PerformanceORM
- zabbix和mysql performance monitor模板實現mysql資料庫的監控MySqlORM資料庫
- Egress-Assess-出口資料安全功能測試
- 主庫歷經open resetlogs後,如何redo apply 物理備庫_flashback physical standby dbAPP
- 如何調優物理備庫的重作日誌應用速率_redo apply_dg_data guardAPP
- Table Monitor
- performance of the databaseORMDatabase
- 【REDO】Oracle redo undo 學習Oracle Redo
- [Shell] monitor filesystem
- 【REDO】Oracle redo內部結構Oracle Redo
- 【REDO】Oracle redo advice-sqlOracle RedoSQL
- MySQL Performance SchemaMySqlORM
- Website Performance OptimizationWebORM
- Oracle Performance ChecklistOracleORM
- SQL Performance AnalyzerSQLORM
- to improve sqlite performanceSQLiteORM
- Redo Log之一:理解Oracle redo logOracle Redo
- CROSS APPLY 和outer apply 的區別ROSAPP
- Postman的Monitor功能Postman
- 【SQL】Oracle SQL monitorSQLOracle
- Health Monitor簡介
- Monitor ASM DG IOASM
- aix_system_monitorAI
- MySQL redoMySql
- JavaScript apply()JavaScriptAPP
- Performance Without the Event LoopORMOOP
- Boost UDP Transaction PerformanceUDPORM
- oracle performance tunningOracleORM
- Oracle Performance Tune PlanOracleORM
- 【SQL Performance Analyzer】Oracle 11g SQL Performance Analyzer feature使用SQLORMOracle
- Ice中Monitor的使用
- Oracle Real Time SQL MonitorOracleSQL
- dubbo-monitor安裝
- sql monitor的使用(一)SQL
- C# 物件鎖——MonitorC#物件