PRESENTOR:- KAMRAN SIDDIQUE SENIOR CONSULTANT/ARCHITECT (HA EXPERT) CGI DON’T WAIT OPPORTUNITY TO CREATE TECHNOLOGY…USE TECHNOLOGY TO CREATE OPPORTUNITY

 BASIC CONCEPTS  Basic Steps for Creating a Physical Standby database  MY TRICKS..  REFERENCES  QUESTIONS

 A software  An extension to Oracle RDBMS  Protects DATA  Takes 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.

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

 DG configuration contains one Production database  Functions as Primary Role.  Mainly accessed by Production applications.  Can be a Single-instance or RAC

1-PHYSICAL STANDBY  A 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).

2-LOGICAL STANDBY DATABASE  Contains 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.

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

 Database Version = Enterprise 64- bit  Primary 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.

 one production database and one or more standby databases  connected by Oracle Net  may be dispersed geographically  No restriction on the distance.  SQL command-line  Data Guard Broker interface (DGMGRL)  GUI interface integrated with EM.

 A 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 configurations  Manage an entire Data Guard configuration from any system in the configuration  Manage and monitor Data Guard configurations that contain Oracle RAC primary or standby databases  Simplify switchovers and failovers  Enable fast-start failover to fail over automatically when the primary database becomes unavailable.

1-Redo Transport Services  Transmit 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

2-Apply Services  Automatically apply the redo data on the standby database to maintain consistency with the primary database.  Allows read-only access to the data

 Physical 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 technology  first transforms the received redo data into SQL statements  Then executes the generated SQL statements on the logical standby database

3-Role Transitions Switchover --role reversal between the primary database and one of its standby databases. Switchover –No Data Loss Failover --failure of the primary database Failover --transition of a standby database to the primary role Failover –Can configure Data Guard to ensure no data loss.

 Both primary and standby databases must be set at the same compatibility mode as the minimum release

 A standby database cannot be open read-only in any environment that has binary-level PL/SQL-related incompatibilities between primary and standby databases

1-Maximum Protection  Redo 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 commit  Zero Data Loss  Processing on primary is suspended if no standby is available.

2-Maximum Availability  Minimal Data Loss  Similar to Maximum protection mode  If 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.

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

 Symmetric configuration with RAC at all sites Same number of instances  Asymmetric configuration with RAC at all sites Different number of instances  Asymmetric configuration with mixture of RAC and single instance Some single-instance sites not running under Oracle Clusterware Metalink note

 Beginning with Oracle Database , 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 process

Basic Steps for Creating a Physical Standby database

 Two Vmwares ( el5)   Primary ASM  Secondary ASM  Primary Database Name => Primary  Primary DB_UNIQUE_NAME => Primary  Standby DB_UNUIQUE_NAME =>Secondary  Primary Hostname =>primary.localdomain  Secondary Hostname => secondary.localdomain

 Enable Force Logging SQL> ALTER DATABASE FORCE LOGGING; Database altered.

 On the primary node, connect to the primary database and create a PFILE from the SPFILE  create pfile='/home/oracle/stage/secondary. ora' from spfile;

 On 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;

 DB_UNIQUE_NAME  LOG_ARCHIVE_CONFIG  LOG_ARCHIVE_DEST_2  DB_FILE_NAME_CONVERT  LOG_FILE_NAME_CONVERT  STANDBY_FILE_MANAGEMENT  FAL_SERVER  FAL_CLIENT  SERVICE_NAMES  DB_RECOVERY_DEST  LOG_ARCHIVE_DEST_1

BeforeAfter db_unique_name=CALGARY_DGdb_unique_name=VANCOUVER_DG INSTANCE_NAME=CALGARYinstance_name=VANCOUVER log_archive_config='dg_config=(VANCOUVER_DG,CALGARY_ DG) log_archive_dest_2='service=CALGARY valid_for=(online_logfiles,primary_role) db_unique_name=CALGARY_DG db_file_name_convert='+DATA/CALGARY','+DATA/VANCOUVER','+RECOVERY/CALGARY','+RECOVERY/V ANCOUVER' log_file_name_convert='+DATA/CALGARY','+DATA/VANCOUVER','+RECOVERY/CALGARY','+RECOVERY/V ANCOUVER' standby_file_management=auto fal_server='CALGARY' fal_client='VANCOUVER' service_names='VANCOUVER'

 log_archive_config='dg_config=(VANCOUVER_DG,CALGAR Y_DG)'  log_archive_dest_2='service=VANCOUVER valid_for=(online_logfiles,primary_role) db_unique_name=VANCOUVER_DG'  db_file_name_convert='+DATA/VANCOUVER/',’+DATA/CAL GARY/', ’+RECOVERY/VANCOUVER’,’+RECOVERY/CALGARY’  log_file_name_convert='+DATA/VANCOUVER/',’+DATA/CAL GARY/', ’+RECOVERY/VANCOUVER’,’+RECOVERY/CALGARY’  standby_file_management=auto  fal_server=‘VANCOUVER'  fal_client='CALGARY'  service_names=CALGARY

PRIMARY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = primary) ) ================================================= SECONDARY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = secondary) )

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

 $ rman target auxiliary /  RMAN> DUPLICATE TARGET DATABASE FOR STANDBY;

 The recommended number of standby redo logs is: (maximum # of logfiles +1) * maximum # of threads  If 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.

 Start managed recovery on the standby database:  SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

 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;

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

 To start log apply services on a physical standby database ALTER 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 archived ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

 DGMGRL> show configuration; Configuration - DRSOLUTION Protection Mode: MaxPerformance Databases: PRIMARY - Primary database SECONDARY - Physical standby database Fast-Start Failover: DISABLED Configuration Status: SUCCESS

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

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

Verify Managed Recovery is Running (non-broker) on the standby SELECT PROCESS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%'; SELECT DELAY_MINS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; SQL> select database_role,protection_level,fs_failover_status from v$database; V$DATAGUARD_STATUS V$LOG &V$STANDBY_LOG…REDO LOG CHANGED. V$MANAGED_STANDBY..RECOVERY PROGRESS Select max(sequence#),thread# from v$archived_log where applied=‘YES’ group by thread#; Secondary Select max(sequence#) from v$log;......primary

 Dgmgrl /  Connect  DGMGRL> 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;

 DGMGRL> SWITCHOVER TO STANDBY;  Site "standby" was not found  DGMGRL> 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"...

 1. Shutdown the new primary database If 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 mode SQL> startup upgrade 3. Invalidate existing PL/SQL modules in preparation to convert the format required by the new primary.  SQL> spool utlirp.log SQL> spool off 4. Restart the database If using RAC then set database back to clustered: SQL> alter system set cluster_database=true scope=spfile; SQL> shutdown immediate SQL> startup 5. Recompile all invalid PL/SQL modules to be in the format required by the new primary database. SQL> spool utlrp.log SQL> 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';

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

 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 +FLASH db_recovery_file_dest_size big integer 3882M

 Step 2 Bring the physical standby database to mount stage.  Step 3 Stop managed recovery if it is active. SQL> alter database recover managed standby database cancel; Database altered.

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

 SQL> shutdown immediate ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> startup ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance ORACLE instance started. Total System Global Area bytes Fixed Size bytes Variable Size bytes Database Buffers bytes Redo Buffers bytes Database mounted. Database opened. SQL> select open_mode,database_role from v$database; OPEN_MODE DATABASE_ROLE READ WRITE SNAPSHOT STANDBY

 Step 1 Shutdown the snapshot standby database.  Step 2 Bring the database to the mount stage.  Step 3 Issue the command ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

 Step 3 Issue the command ALTER DATABASE CONVERT TO PHYSICAL STANDBY;  Step 4 :- Shutdown the database and mount it.  Step 5 Start the media recovery process.

SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount Database mounted. SQL> alter database convert to physical standby; Database altered. SQL> shutdown immediate ORA-01507: database not mounted ORACLE instance shut down. SQL> startup mount Redo Buffers bytes Database 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;

 DGMGRL> CONVERT DATABASE "SECONDARY" TO SNAPSHOT STANDBY; Converting database "SECONDARY" to a Snapshot Standby database, please wait... Database "SECONDARY" converted successfully

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

 Create Restore Point CREATE restore point before_rw guarantee flashback database;  Failover the standby database: ALTER DATABASE ACTIVATE STANDBY DATABASE  Open Database in Read Write Mode:

 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 Configuration Scenario 1: Creating a Configuration  Scenario 2: Setting Database Properties Scenario 2: Setting Database Properties  Scenario 3: Enabling the Configuration and Databases Scenario 3: Enabling the Configuration and Databases  Scenario 4: Setting the Configuration Protection Mode Scenario 4: Setting the Configuration Protection Mode  Scenario 5: Performing Routine Management Tasks Scenario 5: Performing Routine Management Tasks  Scenario 6: Performing a Switchover Operation Scenario 6: Performing a Switchover Operation  Scenario 7: Performing a Failover Operation Scenario 7: Performing a Failover Operation  Scenario 8: Monitoring a Data Guard Configuration Scenario 8: Monitoring a Data Guard Configuration

 atures/availability/s hughesallstatemaa pdf atures/availability/s hughesallstatemaa pdf  atures/availability/s hughesallstatemaa pdf atures/availability/s hughesallstatemaa pdf  atures/availability/data-guard-esg-case- studies pdf atures/availability/data-guard-esg-case- studies pdf  nsider/media/ _bank_of_aus_ mp 3 nsider/media/ _bank_of_aus_ mp 3  Metalink note Metalink note

For any further information contact me at