Data Guard Management

 You have three options on which to manage Data Guard

SQL* Plus 

Guard Broker - a distributed management tool configuring management using the DGMGRL command line.

Enterprise Manager - provides the data vendor with a graphical representation that replaces the DGMGRL 

To use Enterprise Manager, you must have a data broker installed. The vendor maintains a configuration file that includes profiles for all databases. Changes can be propagated to all databases in the configuration. The vendor also includes a command to start the monitor, a process that monitors the status of the database configuration and performs automatic shutdowns.

FIGURE 1-01. Primary Database Archiving When There Is No Standby Database

You may think that the database manager is one point of failure, which needs to be corrected: the sales process is the basis of any database in the organization and communication. If the system you entered goes down, connect to another database in the settings and restart the control.

Apply Services

There are two ways to apply recovery, Redo Apply (physical standby) and SQL Apply (logical standby). Both have the same characteristics: 

• Both share basic data 
• Both can prevent data exchange 
• Both provide a high degree of isolation between the primary database and the standby database. 
• Both can be easily switched from the standby database to the primary database 
• Both of them provide a standby database that does not affect the primary database.

Redo Apply(physical standby)

Redo apply is essentially a block-by-block physical copy of the main database, redo apply uses media recovery to read records from SRL into memory and apply the change vectors directly to the standby database. 

Media Recovery performs simultaneous recovery for high performance, it includes Media Recovery Manager (MRP0) and multiple parallel application processes (PR0?). The scheduler manages the recovery time, integrates the redo through the SCN through multiple sessions (if in an RAC environment), and converts the redo into a change map of the partitioned application process. 

The application process reads the data block, collects the variables from the graph, and adds the variables to the data block. This method allows you to use the database as read-only. Active data protection checks for readable text changes in previous versions using the SCN "query". 

The media recovery process in the standby database promotes SCN queries after all transaction-based changes have been made. The SCN query is revealed to the user through the current_scn column of the v$database view. Using read-only will only be able to see data up to the SCN query, so the standby database can be opened in read-only mode while media recovery is active, making it a standby database. 

You can use SYNC or ASYNC and separate it from physical I/O corruption. A corruption investigation is conducted on the following points: 

 In the main when you restore transport - LGWR, LNS, ARCH use parameter DB_UTRA_SAFE. 

Sleep during recovery - RFS, ARCH, MRP, and DBWR use DB_BLOCK_CHECKSUM and DB_LOST_WRITE_PROTECT parameters. 

If Data Protection detects corruption, it will automatically restore a new copy of the master file data using the difference resolution method in the hope that the original data is free of corruption. 

The main feature of this solution is 

• Full application and data transparency - no data types or other restrictions 
• The performance is very high, the complexity is not controlled, and a small part of the movement 
• End-to-end validation before application, including corruption due to lost text 
• It can be used for read-only queries and reports while providing disaster recovery 
• Can perform database upgrade rolling from Oracle Database 11g.

SQL Apply(Logical Standby)

SQL Apply uses a logical fallback process (LSP) to configure a variable application in a standby database. SQL Apply requires more configuration than Redo Apply, the processes that make up SQL Apply, read SRL and "I" redo by converting it to a logical change record, then create a SQL transaction and apply SQL to the standby database. Since there are more moving parts, it requires more CPU, memory, and I/O, and it slows down the application. 

 SQL Apply does not support all data types, such as XML in object-relational formats, and Oracle-provided formats such as Oracle Spatial, Oracle intermedia, and Oracle text. The advantage of SQL Apply is that the database is open for reading and writing while the application is running, as you cannot make any changes to the duplicate data that you may have entered. 

change and delete data from local tables and features added to the database, you can create virtual views and local entries. This makes it ideal for using reporting tools etc.

The main feature of this solution is 

• The standby database is open for reading while the SQL application is running 
• Security settings that prevent changes to data stored by SQL applications. 
• Revolving database upgrades can be done from Oracle Database 11g using the KEEP IDENTITY clause 

Synchronous :

Synchronous transport (SYNC) is also called the "zero data loss" method because the LGWR does not let it know that the commitment was successful until the LNS can confirm that the return required to recover the data transaction is recorded in the backup site.

         

  FIGURE 1-02. LGWR SYNC Archival to a Remote Destination with Standby Redo Log Files

In the diagram on the right, the order of business is 

 

The user performs a transaction by creating a redo log in the SGA, LGWR reads the redo log from the log buffer, writes it to the online redo file, and waits for confirmation from the LNS. 

LNS reads the same redo record from storage and transfers it to the standby database using Oracle Net Services. RFS retrieves the recovery from the standby database and writes to SRL. 

When the RFS receives a write from disk, it transmits an acknowledgment to the LNS system in the backend database which, in turn, informs the LGWR that the transmission is complete. LGWR sends support to support staff. 

This configuration is really dependent on network performance and can have a significant impact on back-end databases. Low network outages will have a significant impact on response times. This effect is observed in the SENDREQ wait event \" LNS wait in the v$system_event dynamic performance check.

There is also a timeout value that can change in the event of a network outage, we will discuss this in detail in the installation section.

Asynchronous :

Asynchronous transport (ASYNC) differs from SYNC in that it eliminates the requirement for LGWR to wait for confirmation from the LNS, thus creating "zero side" performance in the main database, n 'regardless of the distance between the primary and secondary locations. 

LGWR will continue to recognize the success of the promise even if bandwidth prevents the transmission of previous transactions from being sent directly to the standby database. If the LNS cannot maintain and restore the backup log before the restore is sent to the standby server, 

LNS automatically switches to reading and sending from a log file instead of a buffer in the SGA. Once the LNS is captured, it returns to reading directly from the SGA buffer. The log buffer rate is checked with the X$LOGBUF_READHIST check. A low success rate indicates that the LNS is reading from the log file instead of saving the log. If this happens, try increasing the size of the log buffer.

                                         

                  FIGURE 1-03. LGWR ASYNC Archival with Network Server (LNSn) Processes

The downside of ASYNC is the increased risk of data loss. If a failure destroys the primary database before the transit time is reduced to zero, all committed transactions that are part of the transit delay are lost. So again make sure that the network bandwidth is sufficient and that you are getting the lowest latency.

Oracle recently released an advanced compression option. This new product has many compression features, one of which is redo compression for data storage, and it supports both SYNC and ASYNC. 

Like all compression tools, it has an impact on CPU resources but will reduce network bandwidth usage.

Oracle Data Guard Architecture

The exception in the log file occurs whenever the database continues to execute transactions when the LNS process stops redo transfers to the standby database (network problem). 

The main database continues to write to the current log file, fills it up, then switches to the new log file, and starts archiving the file. Before you know it, many archive and log files need to be processed. from LNS, creating a large space in the log file. The database uses the ARCH method in the primary database to continuously ping the database during outages. When the database is finally returned, the ARCH process queries the standby control file (through the RFS process) to determine the last complete record file received from the source for the previous day. 

The ARCH process will transfer the missing files to the standby database using another ARCH process. During the next record exchange, the LNS will attempt and succeed in establishing a connection to the standby database and initiate continuous retransmissions as the ACH process settles. space behind. Once the failover application process can capture the current redo log, the application process automatically switches from reading the redo log to reading the current SRL.