DataGuard_architecture

Editor's Notes

• #3: Oracle Database 10 g : Data Guard Administration 2 -
• #4: Oracle Database 10 g : Data Guard Administration 2 - Hardware and Operating System Requirements These are the operational requirements for Data Guard with respect to the hardware and the operating system: The hardware for the primary and standby database systems can be different. For example, the number of CPUs, the memory size, and the storage configuration can differ. The operating system and platform architecture for the primary and standby databases must be the same. The operating system on both databases must be the same, but the operating system release does not need to be the same. Note: Standby databases can use a different directory structure from the primary database. If both the primary and the standby databases are on the same server, you must ensure that the operating system allows you to mount two databases with the same name on the same system simultaneously. There are certain parameters that must be specified to support this configuration, as discussed in the lesson titled “Creating a Physical Standby Database by Using SQL.”
• #5: Oracle Database 10 g : Data Guard Administration 2 - Oracle Database Software Requirements These are the operational requirements for Data Guard with respect to Oracle Database software: You must install the same release of Oracle Database Enterprise Edition for the primary database and all standby databases in your Data Guard configuration. You must have SYSDBA system privileges for the user accounts that you use to manage the primary and standby database instances. Furthermore, the SYS user must have the same password on all databases in the configuration. The primary database and each standby database must have their own control files. The primary database must be configured in ARCHIVELOG mode.
• #6: Oracle Database 10 g : Data Guard Administration 2 - Oracle Database Software Requirements (continued) Some data definition language (DDL) statements permit the NOLOGGING clause, which causes some database operations not to generate redo records in the database redo log. The NOLOGGING setting can speed up operations that can be easily recovered outside of the database recovery mechanisms, but it can negatively affect media recovery and standby databases. You can enable FORCE LOGGING to force the writing of redo records even when NOLOGGING has been specified in DDL statements. To protect against unlogged direct writes in the primary database that cannot be propagated to the standby database, enable FORCE LOGGING on the primary database before taking data file backups for standby creation. You should maintain FORCE LOGGING mode as long as the standby database is active. If you use Oracle Automatic Storage Management (ASM) and Oracle Managed Files (OMF) in a Data Guard configuration, you should use ASM and OMF symmetrically on the primary and standby database. If any database in your Data Guard configuration uses ASM, OMF, or both, then every database in the configuration should use ASM, OMF, or both, respectively.
• #7: Oracle Database 10 g : Data Guard Administration 2 - Oracle Data Guard: Architecture Oracle Data Guard leverages the existing database redo generation architecture to keep the standby databases in the configuration synchronized with the primary database. By using the existing architecture, Oracle Data Guard minimizes its impact on the primary database. Oracle Data Guard uses several processes to achieve the automation that is necessary for disaster recovery and high availability. Some of these processes existed before the introduction of Data Guard; others were created specifically to support Oracle Data Guard. These processes are discussed in more detail on the next few pages.
• #8: Oracle Database 10 g : Data Guard Administration 2 - Primary Database Flow On the primary database, Data Guard redo transport services use the following processes: Log writer (LGWR) process: LGWR collects transaction redo information and updates the online redo logs. In synchronous mode, it ships redo information directly to the remote file server (RFS) process on the standby database and waits for a confirmation before proceeding. In asynchronous mode, it ships the redo information directly but does not wait before proceeding. In asynchronous mode, LGWR submits the network I/O request to the network server (LNS n ) process for that destination. Archiver (ARC n ) process: ARC n , or a SQL session performing an archival operation, creates a copy of the online redo logs locally for use in a primary database recovery. The ARC n process may also ship the redo stream to the RFS process while simultaneously archiving the online log. ARC n is also responsible for proactively detecting and resolving gaps on all standby databases. Fetch archive log (FAL) (physical standby databases only): FAL provides a client/server mechanism for resolving gaps detected in the range of archived redo logs that are generated at the primary database and received at the standby database. This process is started only when needed and shuts down as soon as it is finished. It is very likely you will not see this process running. Note: You can configure a primary database to ship redo information to a single standby database by using either LGWR or ARC n , but not both.
• #9: Oracle Database 10 g : Data Guard Administration 2 - Standby Database Flow On the standby database, Data Guard log apply services use the following processes: Remote file server (RFS) process: RFS receives redo information from the primary database. RFS can write the redo into standby redo logs or directly to archived redo logs. Each LNS n and ARC n process from the primary database has its own RFS process. Note: The use of standby redo logs is discussed in more detail later in the lesson. Archiver (ARC n ) process: The ARC n process archives the standby redo logs. Managed recovery process (MRP): For physical standby databases only, MRP applies archived redo log information to the physical standby database. If you start the managed recovery with the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE SQL statement, this foreground session performs the recovery. If you use the optional DISCONNECT [FROM SESSION] clause, the MRP background process starts. If you use Data Guard broker to manage your standby databases, the broker always starts the MRP background process for a physical standby database. Logical standby process (LSP): For logical standby databases only, LSP controls the applying of archived redo log information to the logical standby database.
• #10: Oracle Database 10 g : Data Guard Administration 2 - Standby Redo Logs A standby redo log is used only when the database is in the standby role to store redo data received from the primary database. Standby redo logs form a separate pool of log file groups. Configuring standby redo log files is highly recommended on all standby databases in a Data Guard configuration, including the primary database to aid in role reversal. A standby redo log is required to implement: The maximum protection and maximum availability levels of data protection Real-time apply Cascaded redo log destinations Standby redo logs are recommended for maximum performance data protection mode. Unless you are using the real-time apply feature, standby redo logs must be archived before the data can be applied to the standby database. The standby archival operation occurs automatically. Note: The real-time apply feature is discussed in more detail later in this lesson.
• #11: Oracle Database 10 g : Data Guard Administration 2 - Data Guard Redo Apply: Architecture The Data Guard physical standby Redo Apply architecture consists of: A production (primary) database, which is linked to one or more standby databases (up to nine) that are identical copies of the production database The limit of nine standby databases is imposed by the LOG_ARCHIVE_DEST_n parameter. In Oracle Database 10 g , the maximum number of destinations is 10. One is used as the local archive destination, leaving the other nine for uses such as the standby database. Note: You can use the Cascaded Redo Log Destinations feature to incorporate more than nine standby databases in your configuration. Refer to the lesson titled “Other Considerations for Oracle Data Guard” for additional information about this feature. The primary database is open and active. The standby databases are either in recovery mode or open in read-only mode, but not both.
• #12: Oracle Database 10 g : Data Guard Administration 2 - Data Guard Redo Apply: Architecture (continued) The standby database, which is updated by redo that is automatically shipped from the primary database. The redo can be shipped because it is generated or archived on the primary database. Redo is applied to each standby database by using standard Oracle recovery techniques. During planned downtime, you can perform a switchover to a standby database. When a failure occurs, you may perform a failover to one of the standby databases. The physical standby database can also be used to back up the primary database.
• #13: Oracle Database 10 g : Data Guard Administration 2 - Data Guard SQL Apply: Architecture In a logical standby database configuration, Data Guard SQL Apply uses redo information shipped from the primary system. However, instead of using media recovery to apply changes (as in the physical standby database configuration), archived redo log information is transformed into equivalent SQL statements by using LogMiner technology. These SQL statements are then applied to the logical standby database. The logical standby database is open in read/write mode and is available for reporting capabilities.
• #14: Oracle Database 10 g : Data Guard Administration 2 - SQL Apply Process: Architecture SQL Apply uses a collection of parallel execution servers and background processes that apply changes from the primary database to the logical standby database as follows: The reader process reads redo records from the archived redo log files. The preparer processes convert the block changes into table changes or logical change records (LCRs). At this point, the LCRs do not represent any specific transactions. The builder process assembles completed transactions from the individual LCRs. The analyzer process examines the records, possibly eliminating transactions and identifying dependencies between the different transactions. The coordinator process (LSP): Assigns transactions Monitors dependencies between transactions and coordinates scheduling Authorizes the commitment of changes to the logical standby database The applier process: Applies the LCRs to the database Asks the coordinator process to approve transactions with unresolved dependencies (the transactions are scheduled appropriately so that the dependencies are resolved) Commits the transactions
• #15: Oracle Database 10 g : Data Guard Administration 2 - Real-Time Apply When you enable the optional real-time apply feature, log apply services apply the redo data from standby redo log files in real time (at the same time the log files are being written to) as opposed to recovering redo from archived redo log files when a log switch occurs. If for some reason the apply service is unable to keep up (for example, if you have a physical standby in READ ONLY mode for a period of time), then the apply service automatically goes to the archived redo log files as needed. The apply service also tries to catch up and go back to reading the standby redo log files as soon as possible. Real-time application of redo information provides a number of benefits, including quicker switchover and failover operations, instantly up-to-date results after you change a physical standby database to read-only, up-to-date reporting from a logical standby database, and the ability to leverage larger logs files. Having larger log files with real-time apply is desirable because the apply service stays with a log longer and the overhead of switching has less impact on the real-time apply processing. The RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view contains the value MANAGED REAL TIME APPLY when log apply services are running in real-time apply mode.
• #16: Oracle Database 10 g : Data Guard Administration 2 - Real-Time Apply (continued) If you define a delay on a destination (with the DELAY attribute) and use real-time apply, the delay is ignored. For physical standby databases, the managed recovery process (MRP) applies the redo from the standby redo log files after the remote file server (RFS) process finishes writing. To start real-time apply for a physical standby database, issue the following command: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; For logical standby databases, the logical standby process (LSP) applies the redo from the standby redo log files after the RFS process finishes writing. To start real-time apply for a logical standby database, issue the following command: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; Note: Standby redo log files are required for real-time apply. It is highly recommended that you have one more standby redo log group than the number of online log groups on the primary database. Real-time apply is supported by the broker.
• #17: Oracle Database 10 g : Data Guard Administration 2 - Setting the DB_UNIQUE_NAME Parameter Data Guard identifies all the databases in its configuration by using the DB_UNIQUE_NAME initialization parameter. Choose a unique name for each database and assign it with this parameter. The DB_UNIQUE_NAME value must remain constant for a given database. Therefore, you should choose names that are easy for you to remember and identify, and you should not change the names after you have assigned them. Each DB_UNIQUE_NAME value can be up to 30 characters long and must be the same for all instances in a RAC database. The default is the database name. If you use Enterprise Manager to create a standby database, it sets this to a unique value for the new standby database.
• #18: Oracle Database 10 g : Data Guard Administration 2 - Specifying Role-Based Destinations The VALID_FOR attribute of the LOG_ARCHIVE_DEST_ n initialization parameter allows you to identify exactly when the archive destination is to be used, as well as for which type of log file it is used. The attribute uses a keyword pair to identify the source of the archival as well as the database role. In the example in the slide, there is a destination on the standby database and the primary database defined with the VALID_FOR setting shown. This destination is to be used on the standby database only after a switchover, when the standby becomes a primary. The destination on the old primary is ignored when it becomes a standby. You supply two values for the VALID_FOR attribute: archival_source and database_role . The archival_source keywords are the following: ONLINE_LOGFILE : This destination is used only when archiving online redo log files. STANDBY_LOGFILE : This destination is used only when archiving standby redo log files or receiving archive logs from another database. ALL_LOGFILES : This destination is used when archiving either online or standby redo log files.
• #19: Oracle Database 10 g : Data Guard Administration 2 - Specifying Role-Based Destinations (continued) The database_role keywords are the following: PRIMARY_ROLE : This destination is used only when the database is in the primary database role. STANDBY_ROLE : This destination is used only when the database is in the standby (logical or physical) role. ALL_ROLES : This destination is used when the database is in either the primary or standby (logical or physical) role. Note: Because the keywords are unique, the archival_source and database_role values can be specified in any order. For example, VALID_FOR=(PRIMARY_ROLE,ONLINE_LOGFILE) is functionally equivalent to VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) .
• #20: Oracle Database 10 g : Data Guard Administration 2 - Combinations for VALID_FOR In the table, the word Valid means that the archive log destination is used in a database that is in the role defined by the column heading. The Ignored value means the archive log destination is not appropriate and a destination of this type is ignored. An ignored destination does not generate an error. ALL_LOGFILES, ALL_ROLES is not a recommended setting for a logical standby for any destination. Because a logical standby is an open database that is creating its own redo, there is a real possibility of having the log files overwrite each other. This gives you a system that is unrecoverable and/or unable to keep synchronized with the primary database. There is only one invalid combination: STANDBY_LOGFILE , PRIMARY_ROLE . If this is specified, it causes an error for all database roles. If this is set, you receive the following error at startup: ORA-16026: The parameter LOG_ARCHIVE_DEST_n contains an invalid attribute value Note: Both the single and plural forms of the keywords are valid. For example, you can specify either PRIMARY_ROLE or PRIMARY_ROLES , and ONLINE_LOGFILE or ONLINE_LOGFILES .
• #21: Oracle Database 10 g : Data Guard Administration 2 - Identifying Destination Settings The VALID_NOW column in V$ARCHIVE_DEST indicates whether or not the archive log destination is used. The column values are the following: YES : This value indicates that the archive log destination is appropriately defined for the current database role. WRONG VALID_TYPE : This value indicates that the archive log destination is appropriately defined for the current database role but cannot be used. For example, LOG_ARCHIVE_DEST_2 is set to (STANDBY_LOGFILES,STANDBY_ROLE) , but WRONG VALID_TYPE is returned because this standby destination does not have a standby redo log implemented. WRONG VALID_ROLE : This value indicates that the archive log destination is not appropriately defined for the current database role. For example, LOG_ARCHIVE_DEST_3 is set to (ONLINE_LOGFILES,STANDBY_ROLE) , but WRONG VALID_ROLE is returned because this destination is currently running in the primary database role. UNKNOWN : This value indicates that the archive log destination is not defined. The VALID_TYPE and VALID_ROLE columns are the respective values from the VALID_FOR attribute that is specified for each archive log destination.
• #22: Oracle Database 10 g : Data Guard Administration 2 - Standby Redo Log Configuration You must create at least the same number of standby redo log files as are contained on the primary database. It is highly recommended that you have one more standby redo log group than you have online redo log groups as the primary database. In addition, the files must be the same size or larger than the primary database’s online redo logs. If your online redo log files are of different sizes, the RFS process automatically uses the same size standby redo log as the online redo log file. The RFS process writes to an archive redo log file if any of the following conditions are met: There are no standby redo logs. It cannot find the same size standby redo log as the incoming online redo log file. All of the standby redo logs of the correct size have not yet been archived.
• #23: Oracle Database 10 g : Data Guard Administration 2 - Using SQL to Add Standby Redo Logs You can create standby redo logs by using the ADD STANDBY LOGFILE clause of the ALTER DATABASE statement. Although standby redo logs are used only when the database is operating in the standby role, you should create standby redo logs on the primary database so that switching roles does not require additional DBA intervention. To verify that standby redo logs have been created, query V$STANDBY_LOG or V$LOGFILE with SELECT * FROM v$logfile WHERE type = 'STANDBY' . The standby redo log status is shown as ACTIVE or UNASSIGNED . The following is an example of output from V$STANDBY_LOG : SQL> SELECT group#,status,first_change# 2 FROM v$standby_log; GROUP# STATUS FIRST_CHANGE# ------ ---------- ------------- 3 ACTIVE 144545 4 UNASSIGNED 0 5 UNASSIGNED 0
• #24: Oracle Database 10 g : Data Guard Administration 2 - Using Enterprise Manager to Add Standby Redo Logs When you create a standby configuration with Enterprise Manager, it recommends a configuration of standby redo logs. This recommendation includes creating the standby redo logs on the primary database as well as on any standby databases in the configuration. Configuring standby redo logs is covered in more detail in the lesson titled “Creating a Configuration and Physical Standby Database by Using Enterprise Manager.”
• #25: Oracle Database 10 g : Data Guard Administration 2 - Standby Database Modes You can use log apply services to maintain your physical standby database in one of the following modes: Redo Apply: In this mode, redo transport services archive the logs to the standby database, and log apply services automatically apply these logs. The database is in the MOUNT state; no reads of the data are possible. Open read-only mode: If you want to use the standby database for reporting purposes, then open it in read-only mode in a Data Guard environment. Log apply services cannot apply archived redo logs to the standby database when it is in this mode, but the primary database continues to ship redo to the standby database. You can easily change between managed recovery mode and read-only mode. In most implementations of a Data Guard environment, you may want to make this transition at various times so that you can do one of the following: Update a physical standby database that is used primarily for reporting Ensure that data is correctly applied to a physical standby database that is used primarily for disaster protection
• #26: Oracle Database 10 g : Data Guard Administration 2 - Standby Database Modes (continued) Open read/write mode: In this mode, log apply services continue to manage the application of log information from archived redo logs. In addition, the database is open for reporting. The logs are being applied to the logical standby database while users are allowed to perform queries on the tables that are being updated by the log apply service. Users are not allowed to perform DML on the tables in the schemas that the log apply service is maintaining. However, users can modify database objects in other schemas that are not being maintained by the log apply service.
• #27: Oracle Database 10 g : Data Guard Administration 2 -
• #28: Oracle Database 10 g : Data Guard Administration 2 -
• #29: Oracle Database 10 g : Data Guard Administration 2 -
• #30: Oracle Database 10 g : Data Guard Administration 2 -