Arkansas Banner Users Group (ABUG) 2006Crashes Happen - Downtime Won't with Data Guard

Stephen ReaMonday, April 24, 2006 11:30 AM

Session Rules of EtiquetteNo smokin'No drinkin'No cussin'No tobaccer spittin'No tomater throwin'

Data Guard - Oracle's Answer to Disaster RecoverySee how to quickly implement a Data Guard physical standby database in a day.Learn how to switch over to your standby database in minutes.Possibly offload your batch reporting workload to your standby database.Replace your forebodings about crashes with "Don't worry ... be happy!"

Oracle Data Guard Concepts and Administration Release 2 (9.2)

Data Guard Flow (Oracle 9i)

Data Guard Flow (Oracle 10g)

Data Guard Protection ModesMaximum PerformanceUpdates committed to primary and sent to standby without waiting to see if they were applied to standbyPros: Little or no effect on performance of primaryCons: Slight chance of lost transactions (on failover)

Maximum Availability (we will implement this one)Attempts to apply updates to standby before committed to primaryLowers protection to Maximum Performance temporarily if updates can't be applied to standbyPros: Primary continues unaffected if connection to standby is lost or the updates are delayedCons: Slight performance hit on primary; lost transactions on failover possible only if the standby has been unreachable

Data Guard Protection ModesMaximum ProtectionAssures updates are applied to standby before committed to primaryPros: No chance of lost transactionsCons: Primary will freeze if connection to standby is lost or the updates are delayed

Notes: We will be implementing a physical standby database locally on the same server here. Logical standby databases are not covered. Implementing the standby on a remote server will be similar - just use a different IP address, and the standby instance name can be the same as the primary in that case.

Primary Database Requirementsfor Data GuardFORCE LOGGING must be enabled: SQL> select force_logging from v$database; SQL> alter database force logging;

ARCHIVELOG mode and automatic archiving must be enabled: SQL> archive log list

MAXLOGFILES >= (2 * Current Redo Log Groups) + 1: SQL> select records_used "Current Groups", records_total "Max Groups" from v$controlfile_record_section where type = 'REDO LOG';

listener.ora AdditionsDefine the standby database SID on the standby site:(SID_DESC= (SID_NAME=PROD2) (ORACLE_HOME=/pgms/oracle/product/v9204))

(in $ORACLE_HOME/network/admin/listener.ora)

tnsnames.ora AdditionsDefine the standby database connect string on the primary site:myserver_prod2 = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 123.45.67.89) -- whatever host IP has PROD2 (Port = 1521) ) ) (CONNECT_DATA = (SID = PROD2) ) ) (define myserver_prod and myserver_prod2 on both primary and standby sites for quick switchovers)

sqlnet.ora and /etc/oratab AdditionsEnable dead connection detection on the primary and standby sites:sqlnet.expire_time=2 (in $ORACLE_HOME/network/admin/sqlnet.ora)

Add the standby database's entry to /etc/oratab on the standby site:PROD2:/pgms/oracle/product/v9204:N

Standby Database Parameter FileCreate the initPROD2.ora parameter file to be used for the standby database (done from primary database):If your primary is using an spfile: $ sqlplus "/ as sysdba" SQL> create pfile='$ORACLE_HOME/dbs/initPROD2.ora' from spfile;Else, if your primary is using a pfile: $ cp -p $ORACLE_HOME/dbs/initPROD.ora $ORACLE_HOME/dbs/initPROD2.ora

Note: We will be modifying both the primary and standby parameter files to handle being in either the primary or the standby mode for quick switchovers.

Standby Database Parameters (changes in copy of primary's values) Change pathnames, such as control_files, background_dump_dest, core_dump_dest, user_dump_dest, and audit_file_dest, and add:

# log_archive_dest = /orcl/oradata/PROD2/archivelogslog_archive_dest_1 = 'LOCATION=/orcl/oradata/PROD2/archivelogs MANDATORY' # for switchoverlog_archive_dest_state_1 = ENABLE # for switchoverlog_archive_dest_2 = 'SERVICE=myserver_prod LGWR SYNC' # for switchoverlog_archive_dest_state_2 = ENABLE # for switchoverstandby_archive_dest = /orcl/oradata/PROD2/archivelogsstandby_file_management = AUTO # or MANUAL for raw devicesremote_archive_enable = TRUE # TRUE or RECEIVE, change RECEIVE to SEND on switchoverinstance_name = PROD2lock_name_space = PROD2 # use when primary and standby on same system; same as instance_namefal_server = myserver_prod # "fal" is Fetch Archive Log, for log gap resolutionfal_client = myserver_prod2db_file_name_convert = ('/PROD/','/PROD2/')log_file_name_convert = ('/PROD/','/PROD2/')

Primary Database Parameters (changes in primary's values)#log_archive_dest = /orcl/oradata/PROD/archivelogslog_archive_dest_1 = 'LOCATION=/orcl/oradata/PROD/archivelogs MANDATORY'log_archive_dest_state_1 = ENABLElog_archive_dest_2 = 'SERVICE=myserver_prod2 LGWR SYNC'log_archive_dest_state_2 = ENABLEstandby_archive_dest = /orcl/oradata/PROD/archivelogs # for switchoverstandby_file_management = AUTO # for switchover; or MANUAL for raw devicesremote_archive_enable = TRUE # TRUE or SEND, change SEND to RECEIVE on switchoverinstance_name = PRODlock_name_space = PROD # use when primary and standby on same system; same as instance_namefal_server = myserver_prod2 # for switchoverfal_client = myserver_prod # for switchoverdb_file_name_convert = ('/PROD2/','/PROD/') # for switchoverlog_file_name_convert = ('/PROD2/','/PROD/') # for switchover

(If primary uses spfile, wait until after the standby database files are copied/created to make these parameter changes.)

Standby Database Datafiles, etc.Create the standby control file from the primary database: SQL> alter database create standby controlfile as '/orcl/oradata/PROD2/ctrl_PROD_01.ctl';

Shut down the primary database and copy or FTP its datafiles, redo log files, and the just-created standby parameter file and standby control file, to the standby site.

Standby Database Datafiles, etc.Copy the standby control file on the standby site to the other file names listed in the control_files init.ora parameter.

Create the standby's password file, if needed, on the standby site: $ orapwd file=$ORACLE_HOME/dbs/orapwPROD2 password= entries=5

Reload the listener on the primary and standby sites: $ lsnrctl reload

Standby Database StartupStart the standby database in nomount mode, create the spfile if wanted, mount the standby database, and change to managed recovery: $ . oraenv PROD2 $ sqlplus "/ as sysdba" SQL> create spfile from pfile; SQL> startup nomount SQL> alter database mount standby database; SQL> alter database recover managed standby database disconnect from session; SQL> exit

Primary Database StartupIf your primary is using an spfile, set the primary database parameters in the spfile as listed earlier. Sample "alter system" commands are shown below: SQL> startup nomount SQL> alter system reset log_archive_dest scope=spfile sid='*'; SQL> alter system set log_archive_dest_1 = 'LOCATION=/orcl/oradata/PROD/archivelogs MANDATORY' scope=spfile; etc SQL> shutdown

Primary Database StartupStart up the primary database with the new parameters: SQL> startupStart archiving to the standby database by issuing a log switch: SQL> alter system switch logfile;Congratulations! You now have a workingstandby database for your primary database.But wait There's more

Add Standby Redo Log Groups to Standby DatabaseCreate standby redo log groups on standby database (start with next group number; create one more group than current number of groups) after switching out of managed recovery mode: SQL> sqlplus "/ as sysdba" SQL> alter database recover managed standby database cancel; SQL> alter database open read only; SQL> select max(group#) maxgroup from v$logfile; SQL> select max(bytes) / 1024 "size (K)" from v$log; SQL> alter database add standby logfile group 4 ('/orcl/oradata/PROD2/stby_log_PROD_4A.rdo', '/orcl/oradata/PROD2/stby_log_PROD_4B.rdo') size 4096K; etc SQL> column member format a55 SQL> select vs.group#,vs.bytes,vl.member from v$standby_log vs, v$logfile vl where vs.group# = vl.group# order by vs.group#,vl.member;

Add Tempfile To StandbyAdd a tempfile to the standby database for switchover or read-only access, then, switch back to managed recovery: SQL> alter tablespace temp add tempfile '/data/oradata/PROD2/temp_PROD_01.dbf' size 400064K reuse; SQL> alter database recover managed standby database disconnect from session; SQL> select * from v$tempfile; SQL> exit

Add Standby Redo Log Groups to Primary DatabaseCreate standby logfile groups on the primary database for switchovers (start with next group number; create one more group than current number of groups): $ sqlplus "/ as sysdba" SQL> select max(group#) maxgroup from v$logfile; SQL> select max(bytes) / 1024 "size (K)" from v$log; SQL> alter database add standby logfile group 4 ('/orcl/oradata/PROD/stby_log_PROD_4A.rdo', '/orcl/oradata/PROD/stby_log_PROD_4B.rdo') size 4096K; etc SQL> column member format a55 SQL> select vs.group#,vs.bytes,vl.member from v$standby_log vs, v$logfile vl where vs.group# = vl.group# order by vs.group#,vl.member;

Switch To Maximum Availability Protection ModeSwitch to the desired "maximum availability" protection mode on the primary database (from the default "maximum performance"): SQL> select value from v$parameter where name = 'log_archive_dest_2'; -- must show LGWR SYNC SQL> shutdown normal SQL> startup mount SQL> alter database set standby database to maximize availability; SQL> alter database open; SQL> select protection_mode from v$database;

Test Updates Propagatingto StandbyTry some edits on the primary and check to see that the changes made it to the standby:On the primary: SQL> update spriden set spriden_first_name = 'James' where spriden_pidm = 1234 and spriden_change_ind is null; SQL> commit; SQL> alter system switch logfile;On the standby (wait a few seconds first): SQL> alter database recover managed standby database cancel; SQL> alter database open read only; SQL> select * from spriden where spriden_pidm = 1234 and spriden_change_ind is null; SQL> alter database recover managed standby database disconnect from session;

Running Reports with a StandbySet standby to Read Only to run reports: SQL> alter database recover managed standby database cancel; SQL> alter database open read only; SQL> @myreport.sql SQL> alter database recover managed standby database disconnect from session;

Shutdown and Startup for Standby DatabaseTo shut down a standby database:If in read-only access, switch back to managed recovery (after terminating any other active sessions): SQL> alter database recover managed standby database disconnect from session;Cancel managed recovery and shutdown: SQL> alter database recover managed standby database cancel; SQL> shutdown immediate

To start up a standby database: SQL> startup nomount SQL> alter database mount standby database; SQL> alter database recover managed standby database disconnect from session;

Switchover - Swapping Primary and StandbyEnd all activities on the primary and standby database.On the primary (switchover status should show "TO STANDBY"): SQL> select database_role,switchover_status from v$database; SQL> alter database commit to switchover to physical standby; SQL> shutdown immediate SQL> startup nomount SQL> alter database mount standby database;On the standby (switchover status should show "SWITCHOVER PENDING"): SQL> select database_role,switchover_status from v$database; SQL> alter database commit to switchover to primary; SQL> shutdown normal SQL> startupOn the primary: SQL> alter database recover managed standby database disconnect from session;On the standby: SQL> alter system archive log current;Change tnsnames.ora entry on all servers to swap the connect strings (myserver_prod and myserver_prod2).

Failover - Standby Becomes PrimaryEnd all activities on the standby database.May need to resolve redo log gaps (not shown here).On the standby: SQL> alter database recover managed standby database finish; SQL> alter database commit to switchover to primary; SQL> shutdown immediate SQL> startupChange tnsnames.ora entry on all servers to point the primary connect string to the standby database.New standby needs to be created. Old primary is no longer functional.

SummaryData Guard provides an automated standby database which can essentially eliminate downtime of your production data.Setup is easy and fairly straightforward.Maintenance is minimal.Switchovers and failovers can be done within a few minutes.Reporting can be offloaded to the standby to ease the workload on the primary.And It's Free! (Included with Enterprise Edition)

Whew! Glad Thats Over! Any Questions?

Presenter InformationStephen Rea, Oracle Database AdministratorUniv of AR Cooperative Extension Service 2301 S. University Avenue P.O. Box 391 Little Rock, AR 72203501-671-2207srea@uaex.eduhttp://www.uaex.edu/srea/dataguard.htm