Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a D17316 gc20 l12_other
Semelhante a D17316 gc20 l12_other (20)
Último
Último (20)
D17316 gc20 l12_other
- 1. 12 Other Considerations for Oracle Data Guard Copyright © 2006, Oracle. All rights reserved.
- 2. Objectives After completing this lesson, you should be able to do the following: • Back up the primary database with a physical standby database • Back up a logical standby database • Use Flashback Database features in a Data Guard configuration • Encrypt redo information • Configure cascaded redo log destinations 12 - 2 Copyright © 2006, Oracle. All rights reserved.
- 3. Offloading Backups to a Physical Standby • Backups of data files and archived redo logs are fully interchangeable. • Control file backups are not interchangeable. • Primary and standby databases must use the same recovery catalog. • It is not necessary to register the standby database. 12 - 3 Copyright © 2006, Oracle. All rights reserved.
- 4. Using RMAN to Back Up a Physical Standby Database • Invoke RMAN. • Allocate channels if needed. • Issue the BACKUP command. • Use the LIST command to verify the backup. 12 - 4 Copyright © 2006, Oracle. All rights reserved.
- 5. Restrictions and Usage Notes • The database you are backing up must be a physical standby database. • You must be connected to the recovery catalog when backing up. • You cannot back up the standby control file. • You must connect to the physical standby database with the TARGET keyword. 12 - 5 Copyright © 2006, Oracle. All rights reserved.
- 6. Backup and Recovery of a Logical Standby Database • Backup considerations: – Use the same backup method that you use for your primary database. – Files are not interchangeable with the primary database. • Recovery considerations: – Can recover like any other database for loss of individual files – Need to re-create if you lose entire database – Must use a binary copy of control file for control-file recovery 12 - 6 Copyright © 2006, Oracle. All rights reserved.
- 7. Flashback Across Database Changes Flashback Database restores the database to a point-in- time before the following global database changes: • Database RESETLOGS operation • Database switchover or failover to a physical or logical standby database • Physical standby database activation 12 - 7 Copyright © 2006, Oracle. All rights reserved.
- 8. Using Flashback Database and Real-Time Apply RFS Primary database MRP Standby redo log ARC0 Archived Standby redo logs database 12 - 8 Copyright © 2006, Oracle. All rights reserved.
- 9. Using Flashback Database After RESETLOGS Primary Standby database database Redo RESETLOGS after Flashback point-in-time recovery Redo Primary database Standby database 12 - 9 Copyright © 2006, Oracle. All rights reserved.
- 10. 12 - 10 Copyright © 2006, Oracle. All rights reserved.
- 11. Enabling Redo Encryption Redo Primary Standby information database database encrypted 12 - 11 Copyright © 2006, Oracle. All rights reserved.
- 12. Activating a Physical Standby Database for Reporting Redo Redo Primary transport apply Physical database standby database Activate for reporting Redo stream Guaranteed restore point Flashback 12 - 12 Copyright © 2006, Oracle. All rights reserved.
- 13. Activating a Physical Standby Database for Reporting 1. On the physical standby database, perform the following steps: a. Specify initialization parameters to define the flash recovery area if not already configured. b. Cancel Redo Apply. c. Create a guaranteed restore point. 2. On the primary database, perform the following steps to ensure that the physical standby database can be reverted to the restore point: a. Archive the current log. b. Defer the log archive destination for the physical standby database. 12 - 13 Copyright © 2006, Oracle. All rights reserved.
- 14. Activating a Physical Standby Database for Reporting 1. Activate the physical standby database and set protection mode to maximum performance. 2. Perform reporting or testing on the activated database. 3. Revert the activated database to a physical standby database: a. Flash back to the restore point. b. Convert it back into a physical standby database. 4. On the primary database, reenable archiving to the physical standby database destination. 5. Allow Data Guard to automatically resynchronize the physical standby database or use RMAN incremental backups from the primary database to resynchronize the physical standby database. 12 - 14 Copyright © 2006, Oracle. All rights reserved.
- 15. Cascaded Redo Log Destinations Primary Standby database database Redo Standby database Redo 12 - 15 Copyright © 2006, Oracle. All rights reserved.
- 16. Configuring Cascaded Redo Log Destinations: Physical Standby • On the primary database, use the LGWR transport. • On the receiving standby database: – Configure standby redo logs. – Configure LOG_ARCHIVE_DEST_n to send redo to the next standby. Primary Physical Physical or database standby logical standby 12 - 16 Copyright © 2006, Oracle. All rights reserved.
- 17. 12 - 17 Copyright © 2006, Oracle. All rights reserved.
- 18. Role Transitions with Cascaded Redo Log Destinations • Standby databases that receive redo data from a physical standby database: – No change: Switchover and failover are exactly the same. – May take longer • Standby databases that receive redo data from a logical standby database cannot participate in a switchover involving the primary database. 12 - 18 Copyright © 2006, Oracle. All rights reserved.
- 19. Summary In this lesson, you should have learned how to: • Back up the primary database with a physical standby database • Back up a logical standby database • Use Flashback Database features in a Data Guard configuration • Encrypt redo information • Configure cascaded redo log destinations 12 - 19 Copyright © 2006, Oracle. All rights reserved.
- 20. 12 - 20 Copyright © 2006, Oracle. All rights reserved.
Notas do Editor
- Offloading Backups to a Physical Standby Recovery Manager (RMAN) can back up the standby database and its associated archived redo logs. Standby backups of data files and archived redo logs are fully interchangeable with primary database backups. In other words, you can execute the RESTORE command to restore a backup of a standby data file to the primary database, and you can restore a backup of a primary data file to the standby database. The standby control file and primary control file, however, are not interchangeable. Both the primary database and standby database must use the same recovery catalog. Note that you do not need to register the standby database in the catalog if the primary is already registered; simply connect to the standby database and execute the BACKUP command.
- Using RMAN to Back Up a Physical Standby Database Use the RMAN BACKUP command to back up the standby database. Performing a backup on the standby database is exactly the same as a backup of the primary database, except that the backup takes place on the standby site.
- Restrictions and Usage Notes If physical standby database backups are to be usable for restore jobs at the primary site, you must be connected to the recovery catalog when backing up the standby database or must resynchronize the physical standby database shortly after the backup. This step is necessary because there is no way for the primary database to know about the standby backups unless the backup records are stored in the recovery catalog. You cannot back up the standby control file. Also, you cannot make an image copy or non-RMAN backup of the standby control file and then use it to restore the primary database. When you back up the standby database, you must connect to the standby database with the TARGET keyword (not the AUXILIARY keyword). Essentially, the standby database is “substituting” for the primary database during the backup.
- Backup and Recovery of a Logical Standby Database You can back up your logical standby database by using the same method that you use for your primary database. The backup files are not interchangeable with the primary database. Remember that this is a different database. You can use the same recovery techniques as with any other database for loss of data files or online log files. You must use the backups of the logical (not the primary) database. If the entire logical standby database is lost, you must re-create the logical standby. If you lose all copies of your control file, you must use a binary copy of the control file when performing the recovery. Using a trace file or the CREATE CONTROLFILE command for control file recovery does not create a logical standby control file. You can make a binary copy of the control file by doing either of the following: Shut down the logical standby and copy the control file to a backup. Issue the following command while the logical standby database is open: ALTER DATABASE BACKUP CONTROLFILE TO '<filename>'; This command creates a binary copy of the control file with the name that you supply.
- Flashback Across Database Changes In Oracle Database 10 g Release 2, you can use flashback database functionality to flash back through the global database changes described above. To flash back through any of these database state changes, Flashback Database must be previously enabled. Enabling Flashback Database for your database remains unchanged from the previous release. Previously, when any of these global database changes were made, the flashback logs were discarded. Oracle Database 10 g Release 2 maintains the flashback logs through the above global database changes, thereby extending the functionality of the Flashback Database command.
- Oracle Database 10 g : Data Guard Administration 12 - Using Flashback Database and Real-Time Apply You can reduce failover time by using the Oracle Data Guard real-time apply feature. You can protect a physical standby database from logical data corruption or user error by using Flashback Database.
- Oracle Database 10 g : Data Guard Administration 12 - Using Flashback Database After RESETLOGS Physical Standby Configuration For a physical standby database, it is possible that the Redo Apply service might not halt when it encounters the OPEN RESETLOGS command in the redo information. If the physical standby database’s SCN is far enough behind the primary database’s SCN, then the Redo Apply service will be able to interpret the OPEN RESETLOGS command without stopping. Use the following procedure to avoid re-creating a standby database after you have performed an OPEN RESETLOGS on the primary database and the managed recovery process has halted on the physical standby database: 1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN when the OPEN RESETLOGS command was issued. This is necessary to enable the standby to recover properly through the OPEN RESETLOGS . Use the following query to find the “before RESETLOGS ” SCN: SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database; 2. On the standby database, obtain the current SCN by using the following query: SELECT TO_CHAR(current_scn) FROM v$database;
- Oracle Database 10 g : Data Guard Administration 12 - Using Flashback Database After RESETLOGS (continued) 3. Flash back the standby database to the “before RESETLOGS ” SCN that you queried in step 1: FLASHBACK STANDBY DATABASE TO SCN < before RESETLOGS SCN >; 4. Restart managed recovery on the standby database. The standby database should now be ready to receive and apply logs from the primary database: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; Logical Standby Configuration For a logical standby database, it is possible that the SQL Apply service might not halt when it encounters the OPEN RESETLOGS command in the redo information. If the logical standby database’s SCN is far enough behind the primary database’s SCN, then the SQL Apply service will be able to interpret the OPEN RESETLOGS command without stopping. Use the following procedure to avoid re-creating a standby database after you have performed an OPEN RESETLOGS on the primary database and the SQL Apply process has halted on the logical standby database: 1. On the primary database, determine an SCN that is at least two SCNs prior to the SCN when the OPEN RESETLOGS command was issued. This is necessary to enable the standby to recover properly through the OPEN RESETLOGS . Use the following query to find the “before RESETLOGS ” SCN: SELECT TO_CHAR(resetlogs_change# - 2) FROM v$database; 2. On the standby database, obtain the current SCN with the following query: SELECT TO_CHAR(current_scn) FROM v$database; 3. Flash back the standby database to the “before RESETLOGS ” SCN that you queried in step 1: FLASHBACK STANDBY DATABASE TO SCN < before RESETLOGS SCN >; 4. Restart SQL Apply on the standby database. The standby database should now be ready to receive and apply logs from the primary database: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
- Oracle Database 10 g : Data Guard Administration 12 - Enabling Redo Encryption You can optionally enable encryption of the redo data by using the following procedure: 1. Install the Oracle Advanced Security option at both the primary and standby databases. Configure the appropriate SQLNET.ORA parameters to enable Oracle Net to encrypt the redo traffic shipped to the standby. An outline of the tasks to configure encryption on the client and on the server using Oracle Net Manager is as follows: a. Navigate to the Oracle Advanced Security profile. b. Choose the Encryption tab. c. Select CLIENT or SERVER from the list. d. From the Encryption Type list, select one of the following: REQUESTED, REQUIRED, ACCEPTED, or REJECTED. e. (Optional) In the Encryption Seed field, enter between 10 and 70 random characters; the encryption seed for the client should not be the same as that for the server. f. Choose File > Save Network Configuration. The SQLNET.ORA file is updated. g. Repeat this procedure to configure encryption on the other system. Refer to the Oracle Database Advanced Security Administrator’s Guide for detailed information.
- Activating a Physical Standby Database for Reporting In Oracle Database 10 g Release 2, using a combination of the capabilities of Data Guard, guaranteed restore points, and the Flashback Database features, a physical standby database can be temporarily activated in read/write mode for running reports and flashed back to revert it to a physical standby database. When the physical standby database is flashed back, Data Guard automatically synchronizes it with the primary database. You do not need to re-create the physical standby database from a backup copy of the primary database.
- Activating a Physical Standby Database for Reporting (continued) The steps to activate a physical standby database for reporting are outlined on this page and the next.
- Activating a Physical Standby Database for Reporting (continued) When you activate a physical standby database temporarily as read/write, it does not receive logs from the primary database to provide disaster protection. In this case, you should use multiple standby databases to ensure full disaster protection while a standby is activated temporarily. Also, you should note that any results stored in the database by a reporting tool are lost when the standby database is flashed back. Any results that should be saved must be copied from the database before flashing it back.
- Oracle Database 10 g : Data Guard Administration 12 - Cascading Redo Log Destinations To reduce the load on your primary system, you can implement cascaded redo log destinations , whereby a standby database receives its redo data from another standby database instead of directly from the primary database. You can configure a physical standby database to retransmit the incoming redo data that it receives from the primary database to other remote destinations in the same manner as the primary database. Note: You must use SQL commands when managing a cascaded redo log destination configuration because Data Guard broker does not support this feature.
- Oracle Database 10 g : Data Guard Administration 12 - Configuring Cascaded Redo Log Destinations: Physical Standby To enable a physical standby database to send the incoming redo data to another set of destinations, you must do the following: Define the LOG_ARCHIVE_DEST_ n initialization parameter on the primary database to set up a physical standby database as the starting point for a cascade to use the LGWR transport method. Use either the SYNC or the ASYNC network protocol, depending on your requirements. On the receiving physical standby database, define sufficient standby redo log files and ensure that archiving is enabled. Define the LOG_ARCHIVE_DEST_ n initialization parameter on the physical standby database that will define the end points of the cascade. Remember that, as part of the original setup of the physical standby database, you should have defined a local archive destination to be used for local archiving when the physical standby database transitions to the primary role. For example, you might define the LOG_ARCHIVE_DEST_1 initialization parameter to be the 'LOCATION=/physical1/arch' location. When the physical standby database switches roles, any archived redo log files are put into that directory with the same format that you defined with the LOG_ARCHIVE_FORMAT initialization parameter.
- Oracle Database 10 g : Data Guard Administration 12 - Configuring Cascaded Redo Log Destinations: Physical Standby (continued) This local archiving destination can be the same as the one that is defined in the parameter STANDBY_ARCHIVE_DEST , but this is not required. A side effect of this configuration is that the archiver process on the standby database now tries to send the redo data not only to the cascading end points, but also to the other standby databases and the primary database if they are defined and enabled. The shipping of redo back to the primary or another standby is not a problem, because the receiving database will reject it. If the destination is another standby database and it has not received the log file successfully, then the shipping of redo acts as an active gap resolution. You can avoid the shipping of redo to the primary and other standbys by setting the state to DEFER for any destinations not involved in the cascade. However, you must remember to enable them again if you do a switchover or failover operation. If you want to have one initialization parameter file handle both the cascaded redo log destinations and the original primary and standby destinations, define the destinations for the primary database and other standby databases as well as for the cascading standby databases. However, the total remote destinations still cannot exceed 10, including the local archiving destination.
- Oracle Database 10 g : Data Guard Administration 12 - Role Transitions with Cascaded Redo Log Destinations The process to perform a switchover or failover is exactly the same in a cascaded redo log destinations configuration, because all physical standby databases that receive retransmitted primary database redo data are identical and valid for role transitions. The only difference is that additional time may be required for the end-of-redo data to cascade to the standby database. Any standby database that receives redo data that is cascaded from a logical standby database cannot participate in a switchover involving the primary database. (Only logical standby databases that receive redo data directly from the primary database can participate in switchovers.) If you fail over to a database that receives redo data generated by a logical standby database, then the only other logical standby databases that receive redo data cascaded from the same logical standby database are able to continue to participate in the Data Guard configuration after the failover.