Which three factors can influence the rate of redo apply on a physical standby database?
A.
the network latency between the primary and standby databases
B.
the number of archiver processes on the standby database
C.
the number and size of standby redo logs on the primary database
D.
the rate of redo generation on the primary database
E.
the number and size of standby redo logs on the standby database
Explanation:
Consider using the following methods to optimize the time it takes to apply redo to physical standby databases.
* (B) Set Parallel Recovery to Twice the Number of CPUs on One Standby Host
* (E) During media recovery or Redo Apply, the redo log file is read, and data blocks that require redo application are parsed out. With parallel media recovery,
these data blocks are subsequently distributed evenly to all recovery processes to be read into the buffer cache. The default is serial recovery or zero parallelism,
which implies that the same recovery process reads the redo, reads the data blocks from disk, and applies the redo changes.https://docs.oracle.com/cd/B19306_01/server.102/b14239/manage_ps.htm#BACHIBGG
It should be number of recovery slave processes not archive processes.
ACD is the answer
If the number of standby redo log files is not the same in the primary and the standby database, in a case of a switchover, it can be a problem and can affect the performance. So “C” can be right!
A – This is wrong! The network latency will be influence the redo shipment, not directly the redo apply.
B – This is wrong! Indifferent to the number of archiver process in the standby database, only one archiver process is responsible to archiver the standby redo log files.
Someone else?
Notes:
Oracle Data Guard 11g Handbook
Scaling and Tuning Data Guard Apply Recovery
Several recommendations can improve the Redo Apply rate as well as redo transmission. The following describes how to scale and tune Redo Apply.
Top Six Considerations for Tuning the Recovery Rate
The following considerations and best practices can improve the recovery rate. Note that other Data Guard tuning considerations, such as redo shipping, were covered in Chapter 2.
■■ During media recovery, at each log boundary (log switch), Oracle does a full checkpoint and updates all the file headers. It is recommended that you increase the primary database’s ORL as well as the standby database’s SRL sizes so that a log switch occurs at a minimum of 15-minute intervals.
■■ Use the PARALLEL option while in managed recovery. The next section covers parallel media recovery in more detail.
■■ Implement real-time apply. Although this recommendation does not directly affect recovery rate, it does directly affect (improves) your recovery time objective (RTO).
■■ Media recovery hinges on the DBWR’s ability to write out modified blocks from the buffer cache to disk as efficiently as possible. It is very important that the DBWR processes have enough I/O bandwidth to perform this task. To increase DBWR throughput, always use native asynchronous I/O by setting DISK_ASYNCH_IO=TRUE (default). In the rare case that asynchronous I/O is not available, use DBWR_IO_SLAVES to improve the effective data block write rate with synchronous I/O.
■■ As with all cases of database recovery, the most important factor is I/O bandwidth. Oracle media recovery is driven and predominantly dependent on I/O bandwidth, and without sufficient I/O bandwidth, the apply process will be stalled. Thus it is important to ensure that enough I/O bandwidth is available on the standby site. Calibrate_IO is a new utility introduced in 11g. That allows a user to gauge the overall I/O throughput on the server. For more details on Calibrate_IO see MetaLink Note 727062.1.1
■■ Remember that media recovery is heavily dependent on the Oracle buffer cache. Thus a large database cache size can significantly improve media recovery performance. While in managed recovery mode, several standby database SGA components can be reduced, and this memory can be moved and reallocated to the DB_CACHE_SIZE. For example, memory associated with the JAVA_POOL, DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE, and a portion of the SHARED_POOL_SIZE can be reallocated to the DB_CACHE_SIZE. However, upon switchover or failover, the new primary will require a production-ready set
of initialization parameters that can support the production workload.
https://docs.oracle.com/cd/B19306_01/server.102/b14239/manage_ps.htm#BACHIBGG
8.6 Tuning the Log Apply Rate for a Physical Standby Database
Consider using the following methods to optimize the time it takes to apply redo to physical standby databases. Also, see the Oracle Media Recovery Best Practices white paper for more information: http://otn.oracle.com/deploy/availability/htdocs/maa.htm.
Set Parallel Recovery to Twice the Number of CPUs on One Standby Host
During media recovery or Redo Apply, the redo log file is read, and data blocks that require redo application are parsed out. With parallel media recovery, these data blocks are subsequently distributed evenly to all recovery processes to be read into the buffer cache. The default is serial recovery or zero parallelism, which implies that the same recovery process reads the redo, reads the data blocks from disk, and applies the redo changes.
To implement parallel media recovery or Redo Apply, add the optional PARALLEL clause to the recovery command. Furthermore, set the database parameter PARALLEL_MAX_SERVERS to at least the degree of parallelism. The following examples show how to set recovery parallelism:
RECOVER STANDBY DATABASE PARALLEL #CPUs * 2;
You should compare several serial and parallel recovery runs to determine optimal recovery performance.
Set DB_BLOCK_CHECKING=FALSE for Faster Redo Apply Rates
Setting the DB_BLOCK_CHECKING=FALSE parameter during standby or media recovery can provide as much as a twofold increase in the apply rate. The lack of block checking during recovery must be an accepted risk. Block checking should be enabled on the primary database. The DB_BLOCK_CHECKSUM=TRUE (the default) should be enabled for both production and standby databases. Because the DB_BLOCK_CHECKING parameter is dynamic, it can be toggled without shutting down the standby database.
Set PARALLEL_EXECUTION_MESSAGE_SIZE = 4096
When using parallel media recovery or parallel standby recovery, increasing the PARALLEL_EXECUTION_MESSAGE_SIZE database parameter to 4K (4096) can improve parallel recovery by as much as 20 percent. Set this parameter on both the primary and standby databases in preparation for switchover operations. Increasing this parameter requires more memory from the shared pool by each parallel execution slave process.
The PARALLEL_EXECUTION_MESSAGE_SIZE parameter is also used by parallel query operations and should be tested with any parallel query operations to ensure there is sufficient memory on the system. A large number of parallel query slaves on a 32-bit installation may reach memory limits and prohibit increasing the PARALLEL_EXECUTION_MESSAGE_SIZE from the default 2K (2048) to 4K.
Tune Disk I/O
The biggest bottlenecks encountered during recovery are read and write I/O. To relieve the bottleneck, use native asynchronous I/O and set the database parameter DISK_ASYNCH_IO to TRUE (the default). The DISK_ASYNCH_IO parameter controls whether or not disk I/O to datafiles is asynchronous. Asynchronous I/O should significantly reduce database file parallel reads and should improve overall recovery time.
But, i saw that:
Data Guard Redo Transport & Network Best Practices
Oracle Database 10g Release 2
Oracle Maximum Availability Architecture White Paper – February 2007
ARCH Redo Transport
• Consider increasing the number of ARCn processes. The default number of ARCn processes created when the database is 2. The LOG_ARCHIVE_MAX_PROCESSES initialization parameter controls the maximum number of ARCn processes. This parameter can be set as high as 30 in Oracle Database 10g Release 2. The maximum value in previous releases was 10. The larger number of ARCn processes make it possible to quickly resolve archive log gaps that can occur during extended network or standby database outages. A large number will also provide enough ARCn processes to support remote archiving parallelism, which can be enabled using the MAX_CONNECTIONS attribute discussed in the next section.
Note: Setting LOG_ARCHIVE_MAX_PROCESSES to a high value may increase contention with other application that use the same network resources. Hence, you should consider the impact on other applications when determining the optimal value for LOG_ARCHIVE_MAX_PROCESSES. Determining the optimal value can only be achieved through testing large archive log gap scenarios in your environment.
• Set MAX_CONNECTIONS attribute to 2 or higher (on the LOG_ARCHIVE_DEST_n initialization parameter) for all destinations. Doing so enables remote parallel archiving which can significantly reduce the overall time needed to transfer an archive log. The maximum value for MAX_CONNECTIONS is 5.
Optimizing ARCH Performance
Regardless of redo transport chosen, there is always one ARCH process dedicated to archiving online redo logs locally (Data Guard 10g onward). When ARCH redo transport services are configured the local archive will complete first and a different ARCH process will begin the remote archive using the following logic:
1. Read 10 megabytes from the local archive log and issue a network send to the RFS process on the standby
2. The RFS process receives the redo sent by the ARCH process and performs I/O into either the standby redo log or archive redo logs, depending upon how the user has configured Data Guard.
3. Once the I/O has completed the RFS sends an acknowledgement back to ARCH
4. ARCH reads the next 10 megabytes and then repeats the above process
If the MAX_CONNECTIONS attribute has been configured for the remote archive destination then up to five ARCH processes (depending upon configuration) can participate in sending a single archive log remotely. The actual RFS write time is illustrated with “RFS random i/o” for writes to standby redo logs or “RFS sequential i/o” for writes into archive log files.
Examining the ARCH wait on SENDREQ wait event to assess ARCHs performance can be misleading. This is due to the fact that the network activity by the ARCH ping mechanism (periodically checking on standby availability) is captured within that wait event and it can lead to misleading numbers. The most reliable method to assess ARCH performance is to enable log_archive_trace to level 128 to get additional messages printed to the alert log. Using the timestamps and the archive log file size you can assess overall throughput.
As with LGWR SYNC/ASYNC, it is important to have efficient disk I/O on the standby and primary flash recovery area as well as properly sized network socket buffers. The same tuning items performed for ASYNC should be performed for ARCH. In addition to those tuning items the remote destination should be configured with the MAX_CONNECTIONS attribute set to 5. This will enable parallel ARCH transfer and improve overall throughput for individual archive log files.
The LOG_ARCHIVE_MAX_PROCESSES initialization parameter can be also be set as high as 30, enabling up to 30 ARCH processes (1 dedicated to local archival, and 29 also able to archive either locally or remotely). The Oracle Database 10g Release 2 default is 2. It is always a good idea to increase this level beyond the default when using Data Guard. ARCH processes will be consumed by local archival, by resolving archive log gaps at the standby that result from network or standby database outages, or by normal remote archival if Redo Transport Services have been configured to utilize archiver processes. Increase the LOG_ARCHIVE_MAX_PROCESSES value to a minimum level needed to accommodate what you configure for MAX_CONNECTIONS. If you have the bandwidth to support additional redo streams, consider setting LOG_ARCHIVE_MAX_PROCESSES to as high a value as your network can accommodate. This makes it possible to send multiple archive logs in parallel to handle peaks in workload or to more quickly resolve log archive gaps caused by network or standby failures.
Oracle Data Guard 11g Handbook
LOG_ARCHIVE_MAX_PROCESSES We mention this parameter here because the default setting is still 2, which is not enough. Archive processes on the primary database are responsible for archiving the ORL files as they become full and for resolving gaps in the redo stream to a standby database. And on a standby database, they are responsible for archiving the SRL files and forwarding the archive logs to a cascaded standby database. On the primary, one archive process is limited to servicing only the ORL files and is not allowed to talk to a standby database at all. This special ARCH process is referred to as the “Dedicated ARCH Process.” But the others are all allowed to perform both functions. While an archive process is sending an archive log to a standby database, it is not available to assist in archiving the ORL files. Even though the prime directive of an archive process is “Always archive the online log files first before processing a gap,” it is still possible in the worst case to have only that one archive process archiving the online log files. If you do not have enough processes, then in a time of a large gap of a slow network, you could be reduced to one archive process for the ORL files. And we are all painfully aware that if the ORL files all get full at the same time, production stalls until one gets archived. The multi-threaded gap resolution attribute (MAX_CONNECTIONS), introduced in Oracle Database 10g, allows Data Guard to use more than one archive process to send a single log file to a standby, which uses even more of the processes. So,at a minimum, set this parameter at 4 with a maximum of 30.
log_archive_max_processes=’4′
So, in this case i think that “B” is the best choice!
B,D and E
What do you think about?
A,D and E
E is correct because you need to have 1 more group of standby redologs than online redos and the size should be the same or bigger than online redos.