General Improvements with Oracle 10g Data Guard
| The new features of Oracle 10g Data Guard were developed with the following goals in mind:
The general improvements to the Data Guard environment include the introduction of Real Time Apply, integration of the latest flashback support, advanced security support with authentication and encryption, specifying role-based destinations, and improved Data Guard configuration management. New features with 10g Release 2 include Automatic Failover Flashback Database support across switchovers, and improved asynchronous redo transmission support. Real Time ApplyReal Time Apply is a new optional feature that automatically applies redo information from the primary database's redo log files to the standby database in real time (at the same time the redo log files are being written to) by the remote file server (RFS) process. With Real Time Apply enabled, redo information from standby redo log files can be recovered at the same time the log files are being written to, as opposed to when a log switch occurs. Prior releases of Data Guard required this redo data to be fully archived at the standby site via archive logs prior to being applied. Real Time Apply, however, allows your standby databases to be closely synchronized with your primary databases, which increases the speed of switchover and failover times and in turn reduces your downtime impact. If for any reason the apply service is unable to process the redo data in a timely fashion, the apply service will automatically go to the archive log files as needed. Also, if you define a delay on a destination and use Real Time Apply, the delay is ignored. Using Real Time Apply in conjunction with Maximum Protection, programs get the benefits of both zero data loss as well as minimal downtime in the event of a planned or unplanned outage. The benefits of using Real Time Apply include the following:
Real Time Apply is also supported by the Data Guard Broker, so you can utilize this feature via the Enterprise Manager GUI or via the command-line interface.
Figure 16.1 details the overall process for the 10g Real Time Apply architecture. Figure 16.1. Oracle 10g Real Time Apply architecture.
Standby redo log files are required for Real Time Apply processing. It is recommended that you have one more standby redo log group than your primary database redo log group for Real Time Apply. For physical standby databases, the managed recovery process (MRP) will apply the redo information from the standby redo logs as soon as the remote file server (RFS) process finishes writing. To enable Real Time Apply for your physical standby database environment, issue the following statement: SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE; For logical standby databases, the logical standby process (LSP) will apply the redo information from the standby redo logs as soon as the remote file server (RFS) process finishes writing. To enable Real Time Apply for your logical standby database environment, issue the following statement: SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; To verify that Real Time Apply is enabled, you can query the RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view. When Real Time Apply is enabled, the column will display the MANAGED REAL TIME APPLY value. SQL> select recovery_mode from v$archive_dest_status; RECOVERY_MODE ----------------------- MANAGED REAL TIME APPLY Flashback Database Support
In prior releases of Oracle Data Guard, any failover operation required you to re-instantiate the old primary database so it could be re-established into the Data Guard environment. Also, any time you had to perform a RESETLOGS operation on your primary database, it invalidated your standby database and required a full rebuild of your standby. Re-instantiation of the standby database often took a long time because you had to restore from a remote or local backup copy, which often included copying large files across a network. In Oracle 10g, however, Data Guard can utilize the benefits of Flashback Database to mitigate these problems.
You must have the Flashback Database feature enabled on the old primary database prior to using this feature. When using the new 10g Flashback Database technology in your Data Guard environment, the need to rebuild your standby from a past failover or RESETLOGS is a thing of the past. Now when you experience a failover, you can convert the old primary database into a new standby database without doing a complete rebuild from a previous backup. You can flashback the old primary database so that it only contains the changes already applied to the old standby database. Also, any RESETLOGS operation can be resolved by invoking Flashback Database on your standby to ensure that your standby contains only the changes that are represented in your primary database. Using Flashback Database on your standby database also eliminates the need for any delay of redo data. Previously, some shops purposely delayed the application of redo data to add a layer of protection against user or logical corruption on the standby. Also, using the 10g Real Time Apply feature along with Flashback Database enables the standby database to be more closely synchronized with the primary database, thereby reducing failover and switchover times, while not promoting user or logical corruption. Using Flashback Database to aid in the rebuild and recovery efforts of standby re-instantiation is well worth the price to upgrade to Oracle 10g. This feature alone will save DBAs valuable time because they will no longer need to copy or restore from a previous backup to enable the standby database. A detailed step-by-step configuration of 10g Flashback Database with a physical and logical standby database is discussed later in this chapter. Redo Transmission Authentication and EncryptionAuthentication is now required for all redo shipments in Oracle 10g Data Guard. You must set the REMOTE_LOGIN_PASSWORDFILE parameter to SHARED or EXCLUSIVE at all sites in your Data Guard environment. Also, the password for SYS must be the same at all databases within your Data Guard environment, but it is noted that the password can be changed. This password check is only performed once, when a connection is established for the redo shipment. Also in 10g, you now have the option to utilize redo encryption during the redo shipment. To enable encryption of the redo transfer, do the following:
When you set the necessary parameters in the SQLNET.ORA file, Oracle Net will be allowed to encrypt and integrity-checksum all redo traffic shipped to the standby database. Role-Based DestinationsNew in Oracle 10g, the LOG_ARCHIVE_DEST_n initialization parameter introduces a new attribute, VALID_FOR, which allows you to identify exactly when the archived destination will be used as well as for what type of log file. This new attribute allows you to set up specific archive log destinations to be used only under specific standby database roles. Now, when you experience a switchover or failover, there is no need to enable or disable role-specific archive destinations after performing a role switch. The VALID_FOR attribute accepts two parameters, archive_source and database_role. The archive_source keywords are as follows:
The database_role keywords are as follows:
Almost all possible combinations for archive_source and database_role are accepted. One combination, however, returns an error: STANDBY_LOGFILE, PRIMARY_ROLE. If this is specified, it will cause the ORA-16026 error for all database roles: The parameter LOG_ARCHIVE_DEST_n contains an invalid attribute value. Although it is valid to configure standby redo log files on a primary database, a database that is running in the primary role cannot use standby redo log files. Because the keywords are unique, the archive_source and database_role values can be specified in any order. Following are a few examples of how you can use the new attribute VALID_FOR: LOG_ARCHIVE_DEST_3= 'SERVICE=DRZEUS VALID_FOR= (STANDBY_LOGFILE,STANDBY_ROLE)' LOG_ARCHIVE_DEST_1= 'LOCATION=/ora_log/ZEUS VALID_FOR= (ALL_LOGFILES,ALL_ROLES)' To identify all destination settings that are currently configured in your Data Guard environment, you will need to review the new VALID_NOW column in the V$ARCHIVE_DEST view. This column indicates whether the archive log destination will be used. SQL> select valid_type, valid_role, valid_now from v$archive_dest; VALID_TYPE VALID_ROLE VALID_NOW ---------------- ------------ ---------------- ALL_LOGFILES ALL_ROLES YES STANDBY_LOGFILE STANDBY_ROLE WRONG VALID_TYPE ONLINE_LOGFILE STANDBY_ROLE WRONG VALID_ROLE ALL_LOGFILES ALL_ROLES UNKNOWN ALL_LOGFILES ALL_ROLES UNKNOWN ALL_LOGFILES ALL_ROLES UNKNOWN The column values for VALID_NOW are as follows:
Improved Data Guard Configuration Management
DB_UNIQUE_NAME replaces LOCK_NAME_SPACE, which is now deprecated in 10g. You can still use LOCK_NAME_SPACE in 10g and it will not halt the startup of your instance, but DB_UNIQUE_NAME takes precedence over LOCK_NAME_SPACE. 10g Data Guard identifies all the databases in its configuration using the new initialization parameter DB_UNIQUE_NAME. When assigning database identifiers with this new parameter, you must choose names that are unique for each database. When you have chosen your unique value for DB_UNIQUE_NAME, the value must remain constant for the given database, so please choose names that are easy for you to remember and identify. The default value for DB_UNIQUE_NAME is the database name, so if you use the Data Guard Manager GUI to create a standby, it will set this to a unique value for your new standby. Each DB_UNIQUE_NAME value can be as many as 30 characters long and must be the same for all instances in a RAC database environment. In prior versions of Oracle Data Guard, this process was also achieved by using the LOCK_NAME_SPACE initialization parameter. Oracle 10g Database Release 2 expands the usage of DB_UNIQUE_NAME by reassigning the default value of SERVICE_NAMES to DB_UNIQUE_NAME.DB_DOMAIN rather than DB_NAME.DB_DOMAIN. Improved Data Guard STARTUP CommandStarting with 10g, the STARTUP command now evaluates the database's control file to determine what type of database it is. Now, issuing STARTUP or STARTUP MOUNT brings the standby database up to the appropriate state without requiring the explicit use of the terms STANDBY DATABASE or READ ONLY. In prior versions, you needed to explicitly issue three statements to start, mount, and open a physical standby in read only mode. The STARTUP statement starts, mounts, and opens a physical standby database in read-only mode, all in one step. In prior versions, you had to issue two commands to start and then mount your physical standby. Now, however, the STARTUP MOUNT statement both starts and mounts a physical standby database. You will still need to start the managed recovery process via the ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION command, however. Improved Data Guard ArchivingNow with 10g, the ALTER DATABASE ARCHIVELOG command enables automatic archiving by default, thus eliminating the need to issue a separate LOG ARCHIVE START command. If needed, a new MANUAL parameter on the ALTER DATABASE ARCHIVELOG statement overrides automatic archiving and allows manual archiving. To check which archive log mode your database is in, query the LOG_MODE column of the V$DATABASE view like so: SQL> select log_mode from v$database; LOG_MODE --------- AUTOMATIC Also with 10g, the archive process can now archive to remote standby redo logs directly. Previously, only the log writer (LGWR) process could archive remotely to standby redo log files. This feature eliminates the need to register partial archived redo logs in case your standby database crashes. |
EAN: 2147483647
Pages: 214