Lgwr transmission mode in DG
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Log_archive_dest_2 = 'service = Boston lgwr sync net_timeout = 30 valid_for = (online_logfile, primary_role )'
Sync is the default value (you can leave it empty, but it is better not to write it in. See it ).
If the sync attribute is configured, it is best to include the net_timeout attribute. net_timeout controls the length of time for the lgwr process to wait for the network service process. If net_timeout seconds do not respond, the lgwr process will return an error message.
To write redo In Sync Mode:
~~~~~~~~~~~~~~~~~~~~~~~
1. When the lgwr process on the primary database commits a transaction, the lnsn process initiates network I/O to the remote standby database;
2. on the slave database, the Remote File Service (RFS) receives redo information from the lnsn process of the master database over the network and writes it to the standby log;
3. Transactions in the primary database will not be submitted until the redo log of the primary database and the standby log of the standby database are written;
4. When a log switch occurs on the master database, the log switch of the slave database is also triggered. The arcn process of the slave database archives the standby logfile to the standby_archive_dest directory on the slave database;
5. After the backup database is archived, The mrpn process (or SQL application-LSP process) is enabled and applied to the backup database.
6. If logs are applied in a timely manner, the DG will directly recover the current redo information from the standby log when the RFS process is full, and then archive the data by the arcn process.
Steps for writing redo in async mode:
~~~~~~~~~~~~~~~~~~~~~~~
Log_archvie_dest_2 = 'service = Boston lgwr async'
From 10.2, there is no need to configure net_timeout for The async attribute. Because in 10.2, the lgwr process will never wait for lnsn for any reason, so the net_timeout attribute is not required.
1. When a transaction occurs in the master database, the lgwr process writes the redo information into the local redo logfile. The lgwr process continues to process the next request without waiting for the completion of the LNS network I/O;
2. The lnsn network service process asynchronously transmits the redo information to the remote destination. If you want to transmit data to multiple remote destinations, the lnsn process (one for each destination) initiates the network I/O to all destinations in parallel.
3. When online redo logs are full, log switching, archiving, and backup database applications are usually the same.
About the password file in DG
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ensure that the password of the Sys user is the same between the master and slave databases. Data Guard provides a secure environment to prevent possible tampering when redo data is transferred to the standby database. Redo transmission uses authenticated network sessions to pass redo data. These sessions are authenticated using the Sys User Password contained in the password file. Therefore, all databases in the Data guard configuration must use the password file, and the Sys password contained in the password file must be the same on all systems.
Valid_for attributes
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Log_archive_dest_2 = 'service = bforcl lgwr async valid_for (all_logfiles, primary_role )'
Valid_for allows you to configure the destination attribute for the master and slave database roles at the same time, so that the DG can work normally after switching. Simplified failover and failover. Default valid_for = (all_logfiles, all_roles)
Format: valid_for = (redo_log_type, database_role)
Redo_log_type includes online_logfile, standby_logfile, and all_logfiles.
Database_role includes: primary_role, standby_role, and all_roles
Redo_log_type indicates the type of the log file to be archived;
Database_role means that when the database is in this role, the log files (redo_log_type logs) will be archived to the log_archive_dest_n address ).
For example:
1. Configure log_archive_dest_2 = 'service = primary lgwr async valid_for = (online_logfile, primary_role )'
When the standby database is switched to the master database, that is, when the database role is primary, logs in online_logfile (online Log File) will be archived to the database where tnsnames = primary.
2. Configure log_archive_dest_3 = 'location =/data/arch valid_for = (standby_logfile, standby_role )'
When the database role is standby, when the standby log is full, the Standby log will be archived to the/data/arch directory. Instead of archiving the online logfile content here.
The role of valid_for can be summarized in one sentence:
Control: When the database configured with valid_for is in database_role, the path configured for archiving redo_log_type to log_archive_dest_n is allowed.
If redo_log_type is online_logfile, redo records in online logs are archived;
If redo_log_type is standby_logfile, the records in standby log are archived;
If log_archvie_dest_n is configured as location, it is archived to the local directory;
If log_archvie_dest_n is configured as a service, it is archived to the slave database.