Recently, I have been headacked in the DataGuard environment. In case the network failure will result in a problem that the PRIMARY library does not work short time. The phenomenon of this problem is basically like this: When there is a problem between Primary and Standby, in the test environment, we unplug the STANDBY network cable. At this time, when the primary log switches (log switch), primary will try Notifying Standby as the same archive, but because the network is not accessed, there is a 30-second Timeout by default, and any DML operation on the primary will be hoved within 30 seconds. So far, I have not found a good way to effectively shorten this timeout time, although according to the documentation, it should be shortened to 15 seconds. Even if it is 15 seconds, it is also unbearable, especially if the DataGuard environment is built on the WAN, such as through 2m DDN line, then the chance of network failure is relatively high. If it is possible to cause the main business library to operate due to DataGuard's network reasons, no matter whether it is not very easy to accept for my individual. The network failure chance on the WAN is large, then if we change to the LAN, it can reduce the incidence of such a fault. I think that I can use Dataguard.
Cascaded Redo Log Destinations
Features. This test is made today, and the effect is still ideal. The so-called Cascaded Redo log destinations feature refers to the A machine to pass the REDO data to the B machine (Standby), and then the B machine will pass the received REDO to the C machine (STANDBY), this transit method in Physical Standby and You can be implemented in Logical Standby. If A, B is in the same LAN, and B, C communicate via WAN, even if the network problem occurs, it does not affect A transmitting REDO to B, which will not affect A business. Probably configured as follows: 1. A (Primary) of init parameters:.. * Log_archive_dest_1 = 'LOCATION = / oradata / ctsdb / archive' * log_archive_dest_2 = 'SERVICE = CTSDB.JUMPER LGWR ASYNC = 20480 NET_TIMEOUT = 15 MAX_FAILURE = 2 REOPEN = 10' 2. init parameters B (Standby1) of:.. * log_archive_dest_1 = 'LOCATION = / oradata / ctsdb / archive' * log_archive_dest_2 = 'SERVICE = CTSDB.STANDBY' * .standby_archive_dest = '/ oradata / ctsdb / archive' 3. C (Standby2) of init parameters:. * Log_archive_dest_1 = 'LOCATION = / oradata / ctsdb / archive' * .standby_archive_dest = '/ oradata / ctsdb / archive' * .fal_client = 'ctsdb.standby' * fal_server = 'ctsdb.. Jumper 'other profiles, such as Listener.ora and Tnsnames.ora, no longer described again. Some interesting places in Alertlog on the B machine: Thu Jan 13 12:05:27 2005RFS: SuccessFully Opened Standby logfile 4: '/oradata/ctsdb/redo04.log' tu jan 13 12:05:33 2005RFS: SuccessFully opened standby logfile 5: '/oradata/ctsdb/redo05.log' Thu Jan 13 12:05:38 2005RFS: Successfully opened standby logfile 6: '/oradata/ctsdb/redo06.log'RFS: Successfully opened standby logfile 7:' / ORADATA/CTSDB/redo07.log'RFS: No Standby Redo Logfiles of Size 6144 Blocks Available Previous Test and Freeelists
