All the Views expressed here are my own and do not reflect opinions or views of the anyone else.All the views are tested on my testing environment and kindly test the post before applying anything on production.You can reach to me at firstname.lastname@example.org .
Monday, October 17, 2011
Data Guard Architecture Oracle 11g Part-I
I have decided to post the Architecture of the Standby Database, although there are lots of stuff on the Internet but most of them are lengthy and are not so juicy . I have read a good notes on Standby Database Architecture and further decided to post it . Though, I have modified few topics to make it more clear , juicy and interesting .Hope you all find helpful and enjoy this after reading.
Oracle Data Guard is the most effective and comprehensive data availability, data protection and disaster recovery solution for enterprise databases. It provides a method for customers to actively utilize their disaster recovery configuration for read-only queries and reports while it is in standby role. Additionally, a standby database can be used to offload backups from production databases or for Quality Assurance and other test activities that require read-write access to an exact replica of production. These capabilities are unique to Oracle .
Oracle Data Guard is the management, monitoring, and automation software infrastructure that creates,maintains, and monitors one or more standby databases to protect enterprise data from failures, disasters, errors, and corruptions.Data Guard is basically a ship redo and then apply redo, as we know redo is the information needed to recover a database transaction. A production database referred to as a primary database transmits redo to one or more independent replicas referred to as standby databases. Standby databases are in a continuous state of recovery, validating and applying redo to maintain synchronization with the primary database. A standby database will also automatically re-synchronize if it becomes temporary disconnected to the primary due to power outages, network problems, etc.
The diagram below shows the overview of Data Guard, firstly the redo transport services transmits redo data from the primary to the standby as it is generated, secondly services apply the redo data and update the standby database files, thirdly independently of Data Guard the database writer process updates the primary database files and lastly Data Guard will automatically re-synchronize the standby database following power or network outages using redo data that has been archived at the primary.
Redo records contain all the information needed to reconstruct changes made to a database. During recovery the database will read the change vectors in the redo records and apply the changes to the relevant blocks.Redo records are buffered in a circular fashion in the redo log buffer of the SGA, the log writer process (LGWR) is the background process that handles redo log buffer management. The LGWR at specific times writes redo log entries into a sequential file (online redo log file) to free space in the buffer, the LGWR writes the following.
1.) A commit record : When ever a transaction is committed the LGWR writes the transaction redo records from the buffer to the log file and assigns a system change number (SCN), only when this process is complete is the transaction said to be committed.
2.) Redo log buffers : If the redo log becomes a third full or if 3 seconds have passed sine the last time the LGWR wrote to the log file, all redo entries in the buffer will be written to the log file. This means that redo records can be written to the log file before the transaction has been committed and if necessary media recovery will rollback these changes using undo that is also part of the redo entry.
Remember that the LGWR can write to the log file using "group" commits, basically entire list of redo entries of waiting transactions (not yet committed) can be written to disk in one operation, thus reducing I/O. Even through the data buffer cache has not been written to disk, Oracle guarantees that no transaction will be lost due to the redo log having successfully saved any changes.
Data Guard Redo Transport Services coordinate the transmission of redo from the primary database to the standby database, at the same time the LGWR is processing redo, a separate Data Guard process called the Log Network Server (LNS) is reading from the redo buffer in the SGA and passes redo to Oracle Net Services from transmission to a standby database, it is possible to direct the redo data to nine standby databases, we can also use Oracle RAC and they don't all need to be a RAC setup. The process Remote File Server (RFS) receives the redo from LNS and writes it to a sequential file called a standby redo log file (SRL).