DATA GUARD 101

DATA GUARD

PRESENTOR:- KAMRAN SIDDIQUESENIOR CONSULTANT/ARCHITECT (HA EXPERT)

CGI

DONT WAIT OPPORTUNITY TO CREATE TECHNOLOGYUSE TECHNOLOGY TO CREATE OPPORTUNITYBASIC CONCEPTS

Basic Steps for Creating a Physical Standby database

MY TRICKS..

REFERENCES

QUESTIONS

AGENDAA softwareAn extension to Oracle RDBMSProtects DATATakes data and automatically puts it elsewhere.Makes DATA available for Failover.Maintain larger Distances.Automatic resync with Production database.High availability, data protection, and disaster recovery for enterprise data.WHAT IS DATA GUARDTransactionally consistent copy of the primary database.Using a backup copy of the primary database.Up to 30 Standby Databases and integrations with DG .Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database.Can be a SINGLE-INSTANCE OR RAC.

What is a Standby Database ???DG configuration contains one Production databaseFunctions as Primary Role.Mainly accessed by Production applications.Can be a Single-instance or RACPrimary Database1-PHYSICAL STANDBYA physical standby database is kept in sync with the primary database by using media recovery to apply redo that was generated on the primary database.A block-for-block identical copy of the primary database.Excellent choice for disaster recovery.Data will be intact and consistent with data that existed on the primary.Can receive and apply redo in read only-access (11.1.0).

TYPES OF STANDBY DATABASES2-LOGICAL STANDBY DATABASEContains the same logical information as the production database but physical organization and structure of the DATA can be different.synchronization with the primary database through SQL Apply.Transforms the data in the redo received from the primary database into SQL statements and then executes the SQL statements on the standby database.Can be used for Reporting.Upgrade/Migration purpose with no downtime.Patch sets with no downtime.

TYPES OF STANDBY DATABASESContinueA fully updatable standby database.Receives and archives redo data from a primary database (like physical/logical)Does not apply the redo data that it receives (Differs from physical/logical)Redo apply starts once standby is converted into physical standby.Temporary/updatable snapshot of a physical standby.Conversion to physical standby could be a lengthy process.

Snapshot Standby Database11.1.0Database Version = 10.2.0.4 Enterprise 64-bitPrimary platform = Linux 64-bit)Secondary platform= Linux 32-bit)You can not use DG Broker tool to manage this environment. This restriction is lifted from Data Guard 11g onward.My TrickDifferent word sizes9one production database and one or more standby databasesconnected by Oracle Net may be dispersed geographicallyNo restriction on the distance.SQL command-lineData Guard Broker interface (DGMGRL)GUI interface integrated with EM.Data Guard ConfigurationsA distributed management framework that automates the creation, maintenance, and monitoring of Data Guard configurations.Oracle Enterprise Manager graphical user interface (GUI) or the Data Guard command-line interface (DGMGRL)Create and enable Data Guard configurationsManage an entire Data Guard configuration from any system in the configurationManage and monitor Data Guard configurations that contain Oracle RAC primary or standby databasesSimplify switchovers and failovers Enable fast-start failover to fail over automatically when the primary database becomes unavailable. What is Data Guard Broker1-Redo Transport ServicesTransmit redo data from the primary system to the standby systems .Resolving any gaps in the archived redo log files due to a network failure.Automatically detects missing or corrupted archived redo log files on a standby system .Automatically retrieve replacement archived redo log files from the primary database or another standby database

Data Guard Services2-Apply ServicesAutomatically apply the redo data on the standby database to maintain consistency with the primary database.Allows read-only access to the data Data Guard ServicesPhysical standby---Data Guard uses Redo Apply technology.Physical standby-- applies redo data on the standby database using standard recovery techniques of an Oracle database.Logical Standby--Data Guard uses SQL Apply technologyfirst transforms the received redo data into SQL statementsThen executes the generated SQL statements on the logical standby database

Difference between physical and Logical Standby..with respect to services3-Role Transitions

Switchover --role reversal between the primary database and one of its standby databases.Switchover No Data Loss

Failover --failure of the primary databaseFailover --transition of a standby database to the primary roleFailover Can configure Data Guard to ensure no data loss.Data Guard ServicesBoth primary and standby databases must be set at the same compatibility mode as the minimum releaseMy TrickCompatibilityA standby database cannot be open read-only in any environment that has binary-level PL/SQL-related incompatibilities between primary and standby databasesMy TrickDifferent binary-level 1-Maximum ProtectionRedo data needed to recover a transaction must be written to both the online redo log and to the standby redo log on at least one synchronized standby database before the transaction commitZero Data LossProcessing on primary is suspended if no standby is available.

Data Guard Protection Modes2-Maximum AvailabilityMinimal Data LossSimilar to Maximum protection modeIf not standby database ,primary operates as if it were in maximum performance mode to preserve primary database availability until it is again able to write its redo stream to a synchronized standby database.Data Guard Protection Modes

3-Maximum PerformanceDefault protection mode.Highest level of data protection that is possible without affecting the performance of a primary databaseAsynchronous in terms of transaction commitment.primary database performance is unaffected by delays in writing redo data to the standby database(s).

Data Guard Protection Modes

Symmetric configuration with RAC at all sitesSame number of instancesAsymmetric configuration with RAC at all sitesDifferent number of instancesAsymmetric configuration with mixture of RAC and single instanceSome single-instance sites not running under Oracle Clusterware

Metalink note 413484.1My trick..Architectural Touch...RAC and DATA GUARD topologiesBeginning with Oracle Database 11.1.0.7, a physical standby database can be used to execute a rolling database upgrade to a new Oracle Patch Set or database release by using the transient logical rolling database upgrade processMy TrickTransient Logical Database Rolling UpgradesBasic Steps for Creating a Physical Standby database

Two Vmwares (2.6.32-100.26.2.el5) 11.2.0.3.0Primary ASM Secondary ASMPrimary Database Name => PrimaryPrimary DB_UNIQUE_NAME => PrimaryStandby DB_UNUIQUE_NAME =>SecondaryPrimary Hostname =>primary.localdomainSecondary Hostname => secondary.localdomain

HA VMEnable Force Logging

SQL> ALTER DATABASE FORCE LOGGING;

Database altered.

Step 1Primary SiteOn the primary node, connect to the primary database and create a PFILE from the SPFILE

create pfile='/home/oracle/stage/secondary.ora' from spfile; Step 2On the primary node, perform an RMAN backup of the primary database that places the backup pieces into the staging directory

RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' DATABASE PLUS ARCHIVELOG;

RMAN> BACKUP DEVICE TYPE DISK FORMAT '/opt/oracle/stage/%U' CURRENT CONTROLFILE FOR STANDBY; Step 3DB_UNIQUE_NAMELOG_ARCHIVE_CONFIGLOG_ARCHIVE_DEST_2DB_FILE_NAME_CONVERTLOG_FILE_NAME_CONVERTSTANDBY_FILE_MANAGEMENTFAL_SERVERFAL_CLIENTSERVICE_NAMESDB_RECOVERY_DESTLOG_ARCHIVE_DEST_1

Step 4:-Initialization parametersBefore After db_unique_name=CALGARY_DGdb_unique_name=VANCOUVER_DGINSTANCE_NAME=CALGARYinstance_name=VANCOUVERlog_archive_config='dg_config=(VANCOUVER_DG,CALGARY_DG)log_archive_dest_2='service=CALGARY valid_for=(online_logfiles,primary_role) db_unique_name=CALGARY_DGdb_file_name_convert='+DATA/CALGARY','+DATA/VANCOUVER','+RECOVERY/CALGARY','+RECOVERY/VANCOUVER'log_file_name_convert='+DATA/CALGARY','+DATA/VANCOUVER','+RECOVERY/CALGARY','+RECOVERY/VANCOUVER'standby_file_management=autofal_server='CALGARY'fal_client='VANCOUVER'service_names='VANCOUVER'Examplelog_archive_config='dg_config=(VANCOUVER_DG,CALGARY_DG)' log_archive_dest_2='service=VANCOUVERvalid_for=(online_logfiles,primary_role) db_unique_name=VANCOUVER_DG' db_file_name_convert='+DATA/VANCOUVER/',+DATA/CALGARY/', +RECOVERY/VANCOUVER,+RECOVERY/CALGARY log_file_name_convert='+DATA/VANCOUVER/',+DATA/CALGARY/', +RECOVERY/VANCOUVER,+RECOVERY/CALGARY standby_file_management=auto fal_server=VANCOUVER' fal_client='CALGARY' service_names=CALGARY CONFIGURE PRIMARY DATABASE FOR DG...ExamplePRIMARY = (DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.105)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = primary) ) )=================================================SECONDARY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.2.106)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = secondary) ) )

Step 6 :-CONFIGURE ORACLE NET SERVICESCreate password file for standby database

orapwd file=orapwstandby password=xxxx

Password must be same as Primary password file

OR

Copy primary password file over standby site.

Step 5$ rman target sys/oracle@primary auxiliary /

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;Step 7- From the standby host, duplicate the primary databaseThe recommended number of standby redo logs is:(maximum # of logfiles +1) * maximum # of threadsIf uses two online log files for each thread. the number of standby redo logs should be (2 + 1) * 1 = 3. That is, one more standby redo log file for each thread.Step 8 Add standby redo logs to standby database Start managed recovery on the standby database:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; Step 9:-Create standby redo logs on the primary database to support the standby role SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 GROUP 5 SIZE 10M, GROUP 6 SIZE 10M, GROUP 7 SIZE 10M; SQL> ALTER DATABASE ADD STANDBY LOGFILE THREAD 2 GROUP 8 SIZE 10M, GROUP 9 SIZE 10M, GROUP 10 SIZE 10M; CONFIGURE PRIMARY DATABASE FOR DG...ExampleData Guard configuration includes a primary database and up to 30 standby databases. These standby databases may be a mix of physical and logical standby databases.My Trick

To start log apply services on a physical standby databaseALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; If the real-time apply feature is enabled, apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archivedALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

Applying Redo Data to Physical Standby DatabasesDGMGRL> show configuration;

Configuration - DRSOLUTION

Protection Mode: MaxPerformance Databases: PRIMARY - Primary database SECONDARY - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:SUCCESS

END PRODUCTIt is not necessary that the primary and the standby both be Oracle RAC databases, or both use ASM. For example, the primary database may be running Oracle RAC with or without ASM, and the standby database(s) may be single-instance, with or without ASM. Furthermore, the versions of ASM and CRS do not need to be the same between the primary and standby systems.

My TrickExadata Database Machine: It is transparent to Data Guard whether primary and/or standby databases reside on an Exadata Database Machine or on other hardware, as long as the platform ID's of primary and standby systems within the same Data Guard configuration conform to the support requirements.If Exadata Hybrid Columnar Compression (EHCC) is used, it is strongly recommended that both primary and standby databases reside on Exadata. My Trick Verify Managed Recovery is Running (non-broker) on the standby

SELECT PROCESSFROM V$MANAGED_STANDBYWHERE PROCESS LIKE 'MRP%';

SELECT DELAY_MINSFROM V$MANAGED_STANDBYWHERE PROCESS = 'MRP0';

SQL> select database_role,protection_level,fs_failover_status from v$database;

V$DATAGUARD_STATUSV$LOG &V$STANDBY_LOGREDO LOG CHANGED.V$MANAGED_STANDBY..RECOVERY PROGRESSSelect max(sequence#),thread# from v$archived_log where applied=YES group by thread#; SecondarySelect max(sequence#) from v$log;......primary

Data DictionaryDgmgrl /Connect sys/password@primary/secondaryDGMGRL> CREATE CONFIGURATION 'DRSolution' AS PRIMARY DATABASE IS 'North_Sales' CONNECT IDENTIFIER IS North_Sales.foo.com; DGMGRL> ADD DATABASE 'DR_Sales' AS CONNECT IDENTIFIER IS DR_Sales.foo.com MAINTAINED AS PHYSICAL; Configuring Data Guard BrokerDGMGRL> SWITCHOVER TO STANDBY;Site "standby" was not foundDGMGRL> SWITCHOVER TO "SECONDARY";Performing switchover NOW, please wait...New primary database "SECONDARY" is opening...Operation requires shutdown of instance "primary" on database "PRIMARY"Shutting down instance "primary"...ORA-01109: database not open

Database dismounted.ORACLE instance shut down.Operation requires startup of instance "primary" on database "PRIMARY"Starting instance "primary"...

Switchover1. Shutdown the new primary databaseIf using RAC then set database to unclustered: SQL> alter system set cluster_database=false scope=spfile;SQL> shutdown immediate

2. Startup the new primary in UPGRADE modeSQL> startup upgrade

3. Invalidate existing PL/SQL modules in preparation to convert the format required by the new primary. SQL> spool utlirp.logSQL> @?/rdbms/admin/utlirpSQL> spool off

4. Restart the databaseIf using RAC then set database back to clustered: SQL> alter system set cluster_database=true scope=spfile;SQL> shutdown immediateSQL> startup

5. Recompile all invalid PL/SQL modules to be in the format required by the new primary database.SQL> spool utlrp.logSQL> @?/rdbms/admin/utlrpSQL> spool off

6. Verify that all expected packages and classes are valid.SQL> SELECT count(*) FROM dba_objects WHERE status='INVALID';SQL> SELECT distinct object_name FROM dba_objects WHERE status='INVALID';

MY TRICK

Additional Role Transition Procedures when using mixed Oracle binaries:

Restore pointAn implicit guaranteed restore point is created when a physical standby database is converted into a snapshot standby database and this restore point is used to flashback a snapshot standby to its original state when it is converted back into a physical standby database.

Steps to convert Physical Standby Database to the Snapshot Standby Database

STEP 1

A-

If not already configured , configure flash recovery area;Alter system set db_recovery_file_dest_size=

B-

Set Flash recovery area.Alter system set db_recovery_file_dest=

db_recovery_file_dest string +FLASHdb_recovery_file_dest_size big integer 3882M

Steps to convert Physical Standby Database to the Snapshot Standby Database Continue...

Step 2Bring the physical standby database to mount stage.

Step 3Stop managed recovery if it is active.

SQL> alter database recover managed standby database cancel;

Database altered.

Steps to convert Physical Standby Database to the Snapshot Standby Database Continue...Step 4

Convert physical standby database to snapshot standby database.

ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

The database is dismounted during conversion and must be restarted.

Steps to convert Physical Standby Database to the Snapshot Standby Database Continue...SQL> shutdown immediateORA-01109: database not open

Database dismounted.ORACLE instance shut down.SQL> startupORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instanceORACLE instance started.

Total System Global Area 835104768 bytesFixed Size 2217952 bytesVariable Size 507512864 bytesDatabase Buffers 322961408 bytesRedo Buffers 2412544 bytesDatabase mounted.Database opened.SQL> select open_mode,database_role from v$database;

OPEN_MODE DATABASE_ROLE-------------------- ----------------READ WRITE SNAPSHOT STANDBY

Steps to convert the Snapshot Standby Database to the Physical Standby DatabaseStep 1

Shutdown the snapshot standby database.

Step 2 Bring the database to the mount stage.Step 3Issue the command

ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Steps to convert the Snapshot Standby Database to the Physical Standby DatabaseStep 3Issue the command

ALTER DATABASE CONVERT TO PHYSICAL STANDBY; Step 4 :-Shutdown the database and mount it . Step 5Start the media recovery process.Steps to convert the Snapshot Standby Database to the Physical Standby DatabaseSQL> shutdown immediateDatabase closed.Database dismounted.ORACLE instance shut down.SQL> startup mountDatabase mounted.SQL> alter database convert to physical standby;

Database altered.

SQL> shutdown immediateORA-01507: database not mounted

ORACLE instance shut down.SQL> startup mountRedo Buffers 2412544 bytesDatabase mounted.SQL> select open_mode,database_role from v$database;

OPEN_MODE DATABASE_ROLE-------------------- ----------------MOUNTED PHYSICAL STANDBY

SQL> alter database recover managed standby database disconnect;

Conversion by using DGMGRLDGMGRL> CONVERT DATABASE "SECONDARY" TO SNAPSHOT STANDBY;Converting database "SECONDARY" to a Snapshot Standby database, please wait...Database "SECONDARY" converted successfully

Conversion by using DGMGRLContinue...DGMGRL> CONVERT DATABASE "SECONDARY" TO PHYSICAL STANDBY;Converting database "SECONDARY" to a Physical Standby database, please wait...Operation requires shutdown of instance "secondary" on database "SECONDARY"Shutting down instance "secondary"...ORA-01109: database not open

Database dismounted.ORACLE instance shut down.Operation requires startup of instance "secondary" on database "SECONDARY"Starting instance "secondary".How to use Snapshot Database for 10gCreate Restore PointCREATE restore point before_rw guarantee flashback database; Failover the standby database: ALTER DATABASE ACTIVATE STANDBY DATABASEOpen Database in Read Write Mode:How to use Snapshot Database for 10gcontinue..Revert database back to standby mode: Shutdown the database;Startup database in mount mode;Flashback database;FLASH BACK DATABASE TO RESTORE POINT before_rw; ALTER DATABASE CONVERT TO PHYSICAL STANDBY; Scenario 1: Creating a ConfigurationScenario 2: Setting Database PropertiesScenario 3: Enabling the Configuration and DatabasesScenario 4: Setting the Configuration Protection ModeScenario 5: Performing Routine Management TasksScenario 6: Performing a Switchover OperationScenario 7: Performing a Failover OperationScenario 8: Monitoring a Data Guard Configuration

Scenarios

http://www.oracle.com/technetwork/database/features/availability/s291923-2-hughesallstatemaa-133334.pdfhttp://www.oracle.com/technetwork/database/features/availability/s291923-2-hughesallstatemaa-133334.pdfhttp://www.oracle.com/technetwork/database/features/availability/data-guard-esg-case-studies-133297.pdfhttp://streaming.oracle.com/ebn/podcasts/db_insider/media/7548105_bank_of_aus_040709.mp3 Metalink note 413484.1

ReferencesFor any further informationcontact me at

Kamran.siddique@cgi.com