17
12 Copyright © 2006, Oracle. All rights reserved. Other Considerations for Oracle Data Guard

D17316 gc20 l12_other

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: D17316 gc20 l12_other

12Copyright © 2006, Oracle. All rights reserved.

Other Considerations for Oracle Data Guard

Page 2: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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

Page 3: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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.

Page 4: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 4

Using RMAN to Back Up a Physical Standby Database

1. Invoke RMAN.

2. Allocate channels if needed.

3. Issue the BACKUP command.

4. Use the LIST command to verify the backup.

Page 5: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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.

Page 6: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 6

Backup and Recovery of aLogical 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

Page 7: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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

Page 8: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 8

Using Flashback Database and Real-Time Apply

RFS

Standbyredo log

MRP

ARC0

Archivedredo logs

Primary database

Standby database

Page 9: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 9

Using Flashback Database After RESETLOGS

Redo

Redo

Flashback

Primary database

Standby database

RESETLOGS after

point-in-timerecovery

Primary database Standby database

Page 10: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 11

Enabling Redo Encryption

Primarydatabase

Standbydatabase

Redo information encrypted

Page 11: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 12

Activating a Physical Standby Database for Reporting

Physical standby database

Flashback

Redoapply

Redo stream

Redotransport

Guaranteed

restore

point

Primary database

Activate for

reporting

Page 12: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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.

Page 13: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 14

Activating a Physical Standby Database for Reporting

3. Activate the physical standby database and set protection mode to maximum performance.

4. Perform reporting or testing on the activated database.

5. 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.

6. On the primary database, reenable archiving to the physical standby database destination.

7. 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.

Page 14: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 15

Cascaded Redo Log Destinations

Primarydatabase

Standbydatabase

Standbydatabase

Redo

Redo

Page 15: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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.

Physical standby

Primarydatabase

Physical orlogical standby

Page 16: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 18

Role Transitions withCascaded 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.

Page 17: D17316 gc20 l12_other

Copyright © 2006, Oracle. All rights reserved.12 - 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