MyWiki

Ez az oldal csak olvasható. Megtekintheted a forrását, de nem változtathatod meg. Ha úgy gondolod, hogy ez helytelen, kérdezd az Adminisztrátorokat!
====== Physical Data Guard Apply ======

Naszóval.

===== 10g-ben =====

//**By default**, log apply services **wait for the full archived redo log file to arrive** on the standby database before applying it to the standby database. //

//[...] data transmitted from the primary database is received by the remote file server process (RFS) on the standby system where the RFS process writes the redo data to either archived redo log files or standby redo log files. //

//However, if you use standby redo log files, you can enable **real-time apply**, which allows Data Guard **to recover redo data from the current standby redo log** file as it is being filled up by the RFS process.//

//Standby redo log files are required to use real-time apply.//

Szóval itt két külön "dimenzió" van:
  
1. a standby oldalon: van standby log is, vagy csak archív log van
     * van standby log: használhatsz real-time apply-t
     * nincs standby log: várnod kell, még teliíródik az archív log  
2. az éles oldalról: archív log megy át vagy redo logból megy át az adat 
    * az archív log megy át: ARCn Archival Processin
    * az online redo logból megy át az adat: LGWR Archival Processing
       * szinkron módon: SYNC 
       * aszikron módon: ASYNC


==== ARCn Archival Processing ====

//On the primary database, after the ARC0 process successfully archives the local online redo log to the local destination (LOG_ARCHIVE_DEST_1), the ARC1 process transmits redo from the local archived redo log files (instead of the online redo log files) to the remote standby destination (LOG_ARCHIVE_DEST_2).//

http://docs.oracle.com/cd/B19306_01/server.102/b14239/img/default_archiving.gif


==== LGWR Archival Processing ====

//You must specify the LGWR and SERVICE attributes on the LOG_ARCHIVE_DEST_n parameter to enable redo transport services to use the LGWR process to transmit redo data to remote archival destinations.//


=== LGWR SYNC Archival  ===

//Specifying the SYNC attribute on the LOG_ARCHIVE_DEST_n parameter is optional, because this is the default for LGWR archival processing. //

http://docs.oracle.com/cd/B19306_01/server.102/b14239/img/lgwrsync.gif


=== LGWR ASYNC Archival ===
 
//When the LGWR and ASYNC attributes are specified, the log writer process writes to the local online redo log file, while the network server (LNSn) processes (one for each destination) asynchronously transmit the redo to remote destinations. The LGWR process continues processing the next request without waiting for the LNS network I/O to complete.//

http://docs.oracle.com/cd/B19306_01/server.102/b14239/img/lgwrasync.gif


===== 11g-ben =====

//**By default**, apply services **waits for a standby redo log file to be archived** before applying the redo that it contains. However, you can enable real-time apply, which allows apply services to apply the redo in the current standby redo log file as it is being filled.//

//Real-time apply requires a standby database that is configured with a standby redo log and that is in ARCHIVELOG mode.//

//If the **real-time apply** feature is enabled, apply services can **apply redo data as it is received, without waiting for the current standby redo log file to be archived**. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.//


http://docs.oracle.com/cd/E11882_01/server.112/e41134/img/sbydb049.gif

11g-ben tehát már nincs meg a 2. "dimenzió", itt nincs külön LGWR-es opció, hanem alapból így működik. A real-time apply az ugyanaz mint 10g esetén.  11g-ben sem kötelező standby redo log használa, az csak a real-time apply-hoz kell.


===== 12c-ben =====
//**By default**, apply services **waits for a standby redo log file to be archived** before applying the redo that it contains. However, you can enable real-time apply, which allows apply services to apply the redo in the current standby redo log file as it is being filled.//

//Real-time apply requires a standby database that is configured with a standby redo log and that is in ARCHIVELOG mode.//

//If the **real-time apply** feature is enabled, then apply services can **apply redo data as it is received, without waiting for the current standby redo log file to be archived**.//

//(As of Oracle Database 12c Release 1 (12.1), the USING CURRENT LOGFILE clause is deprecated and no longer necessary to start real-time apply.)//

Itt sem kötelező a standby redo log, de ha van, akkor automatikus a real-time apply.
----

A DELAY meg NODELAY az ezektől független, ezzel késleltetheted mesterségesen a rágörgetést.