16. November >BEST PRACTICES FOR ORACLE HIGH AVAILABILITY WITH DATA GUARD TECHNOLOGY Mila Friedman, Lufthansa Systems

Transcription

1 16. November 2014 >BEST PRACTICES FOR ORACLE HIGH AVAILABILITY WITH DATA GUARD TECHNOLOGY Mila Friedman, Lufthansa Systems

2 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATAGUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 2

3 >ABOUT LUFTHANSA SYSTEMS Full Service Provider includes consulting, development and implementation of customized industry solutions and operation of applications in the company's own data centers Leading position in the global aviation industry Leading position in cloud computing About employs Offices in Germany and in 16 other countries High-performance data center network with data centers in Kelsterbach near Frankfurt as well as in London, Dallas and Singapore 300 airlines and 150 customers from other Industries About 50 Physical Data Guard Systems Folie 3

4 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATAGUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 4

5 >BEFORE YOUR START Customer requesting and technical requirements Recovery Point Objective (RPO) Is data loss acceptable if the primary site fails? If yes, how much data loss can be tolerated? What is the network bandwidth and latency between primary and standby databases? How far is your standby database from the primary database? Recover Time Objective (RTO) Preventing user errors that my occur at the primary database from reflecting to the standby database ("Delay")? Can Application reconnect automatically after Database Failover? Another use of the standby database Active Data Guard (up Oracle 11g and upwards) Snapshot Database (up Oracle 11g and upwards) Rolling Upgrade Folie 5

6 > BEFORE YOUR START Protection Mode MAXIMUM PROTECTION More then one standby database requested MAXIMUM AVAILABILITY Impact on primary database performance. Up Oracle 12C Fast Sync (SYNC NOAFFIRM) is possible MAXIMUM PERFORMANCE (DEFAULT) LGWR process does not wait for each network I/O to complete before proceeding. Data loss can occur. Folie 6

7 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATA GUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 7

8 >IMPLEMENTING PHYSICAL ORACLE DATA GUARD 1. PRIMARY DATABASE PREPARATION (use the Oracle Standard Documentation or Doc ID to set all necessary steps) Some Parameter Setting Recommendation: DB_CREATE_ONLINE_LOG_DEST_1: Create redologs/standby redologs on the separately filesystem AIX: mount option cio, block size 512 bytes LINUX: mount option dio, block size 1096 bytes OMF Format CONTROL_FILE_RECORED_KEEP_TIME=30 DISK_ASYNCH_IO=TRUE (default) when OS can support LOCAL_LISTENER when you use none default listener port Folie 8

9 >IMPLEMENTING PHYSICAL ORACLE DATA GUARD Flashback Configuration DB_RECOVERY_FILE_DEST DB_RECOVERY_FILE_DEST_SIZE dependes of the database activities (90% from file system size) DB_FLASHBACK_RETENTION_TARGET=60 LOG_ARCHIVE_DEST_2 dependes of the protection Mode Net_timeout = 30 sec (default), not lower The Parameters to prevent database corruption Oracle Versions >= DB_ULTRA_SAFE=DATA_AND_INDEX Unless this is a high performance OLTP DB with many SQLs running <1-2ms The use DB_ULTRA_SAFE=DATA_ONLY Oracle Versions <= DB_ULTRA_SAFE = OFF DB_BLOCK_CHECKING = FULL. DB_LOST_WRITE_PROTECT = NONE. DB_BLOCK_CHECKSUM = FULL Folie 9

10 >IMPLEMENTING PHYSICAL ORACLE DATA GUARD 2. CREATING OF PHYSICAL STANDBY DATABASE Create all requested missed directories on the standby server Create pfile on the primary database and copy it to the standby server Change the Init Parameters for Standby Database Copy of orapwd from production server to the standby server Create spfile from pfile and start standby in nomount status Create new standby database using RMAN Oracle 10g primary database backup is necessary up Oracle 11g - RMAN duplicate from active database Folie 10

11 >IMPLEMENTING PHYSICAL ORACLE DATA GUARD RMAN: DUPLICATE FROM ACTIVE DATABASE Oracle 11.2: DUPLICATE FROM ACTIVE DATABASE uses datafiles image copies which does not support section size, compression No string for the target connection Only "push" technique (DUPLICATE FROM ACTIVE DATABASE only from primary) Oracle 12.1: DUPLICATE FROM ACTIVE DATABASE USING COMPRESSED BACKUPSET "Pull" technique (DUPLICATE FROM ACTIVE DATABASE from standby) with backup sets A net string for the target connect Folie 11

12 >IMPLEMENTING PHYSICAL ORACLE DATAGUARD RMAN: TESTING RMAN DUPLICATE for Oracle 12C Connection from Primary Connection from the Standby (script started on Standby) Connection from Primary using COMPRESSED backup sets Connection from Primary using backup sets and 4 parallel streams Connection from primary without backup sets RESULT: By default, backup sets will be used if channels are not specified Backups with backup sets are quicker than without Compressed backups take much more CPU and were much slower Parallel backups are quicker (if the network has sufficient throughput) Folie 12

13 >IMPLEMENTING PHYSICAL ORACLE DATA GUARD 3. ACTIVATE STANDBY DATABASE Check flashback setting on the standby database Standby Redologs Standby redologs should be created on primary and standby databases. Group number of standby redologs: group number of redologs + 1. Size of standby redologs should be equal to the size of redologs Set on Recovery Oracle 10g/11G ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION USING CURRENT LOGFILE; For Oracle 12C Real-Time Apply is default. ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; Set on Log shipping on the primary database Run Switchover using SQL*Plus before you start to configure Data Guard Broker Folie 13

14 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATA GUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 14

15 >DATA GUARD BROKER It is a centralized management tool that can be used to manage the entire configuration using a GUI (Enterprise Manager) or CLI (DGMGRL) interface. It provides an extensive health check mechanism for the primary database, standby databases and supporting services in the configuration. It reduces the complexity of role management services. Switchover and Failover operations can be performed from a centralized console. Folie 15

16 >DATA GUARD BROKER 1. CONFIGURE SPECIFIC STATIC LISTENER ENTRY (DB_UNIQUE_NAME_DGMGRL) IN THE LISTENER OF EACH INSTANCE. A static entry is needed for the Broker to be able to connect remotely to a database that has been shut down by the Broker during certain operations. They are required for the Broker to complete the following operations: Switchover from the Primary database to a Physical Standby database Reinstatement of failed Primary database after a manual or automatic failover has occurred. Conversion of a Snapshot Standby database back to a Physical Standby database. ORA will occur during switchover in the case of the wrong listener configuration Folie 16

17 >DATA GUARD BROKER 2. START DATA BROKER Set the broker configuration files on the primary and standby databases on 2 different locations example DG_BROKER_CONFIG_FILE1 = $ORACLE_BASE/ADMIN/<SID>/DGBROKER/DR1<DB_UNIQUE_NAME>.DAT'; DG_BROKER_CONFIG_FILE2 = /ORADATA/<SID>/DGBROKER/DR2<DB_UNIQUE_NAME>.DAT'; Start dataguard broker process (dmon) on the primary and standby databases ALTER SYSTEM SET DG_BROKER_START=TRUE; The broker log file is created in the same directory as the alert log and is named drc<$oracle_sid>.log. Folie 17

18 >DATA GUARD BROKER 3. BROKER CONFIGURATION WITH DGMGRL Create a broker configuration DGMGRL> CONNECT / CREATE CONFIGURATION <configuration name> AS PRIMARY DATABASE IS <database name> CONNECT IDENTIFIER IS <connect identifier>; ADD DATABASE <database name> AS CONNECT IDENTIFIER IS <connect identifier> MAINTAINED AS {PHYSICAL LOGICAL} Enable a broker configuration DGMGRL> ENABLE CONFIGURATION; Check the broker logfile Folie 18

19 >DATA GUARD BROKER Check Configuration DGMGRL> show configuration verbose; Example DGMGRL> SHOW CONFIGURATION VERBOSE; CONFIGURATION - T1201T PROTECTION MODE: MAXAVAILABILITY DATABASES: T1201T_4 - PRIMARY DATABASE T1201T_3 - PHYSICAL STANDBY DATABASE FAST-START FAILOVER: DISABLED CONFIGURATION STATUS: SUCCESS In the case of ERROR and WARNING check drc<$oracle_sid>.log and alert<$oracle_sid>.log to get more information. Folie 19

20 >DATA GUARD BROKER The change of the properties Most changes (check Oracle Documentation to get complete list) need to be made using dgmgrl, otherwise the Broker is not aware of the new values and you'll end up having to drop and recreate the Broker configuration. Example DGMGRL> edit database 'LORA112' set property 'ArchiveLagTarget'=1200; Property "ArchiveLagTarget" updated DGMGRL> edit database 'LORA112_2' set property 'ArchiveLagTarget'=1200; Property "ArchiveLagTarget" updated Folie 20

21 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATAGUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 21

22 >CLIENT FAILOVER OCI Automatic client failover in a Data Guard configuration includes relocating Database Services to new the primary database. Make sure, that service_name used to connect the database is not included in the service_names parameter neither in primary nor in standby database. 1. Create and start new Service on the primary database EXEC DBMS_SERVICE.CREATE_SERVICE( SERVICE_NAME, SERVICE_NAME ); EXEC DBMS_SERVICE.START_SERVICE( SERVICE_NAME ); 2. Configure client TNSNAMES.ORA entry to connect to the database using SERVICE_NAME <SERVICE_NAME>.WORLD = (DESCRIPTION = (CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3) (only for Oracle Client up 11Gr2) (ADDRESS_LIST= (ADDRESS = (PROTOCOL = TCP)(Host = <Horstname1>)(Port = <Listener_Port>)) (ADDRESS = (PROTOCOL = TCP)(Host = <Horstname2>)(Port = <Listener_Port>)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = <Service_NAME>) ) ) Folie 22

23 >CLIENT FAILOVER 3. Create trigger to start service on on the primary database during startup CREATE OR REPLACE PACKAGE body manage_dgswitch_pkg AS PROCEDURE manage_dgservice as role varchar(30); ora_err varchar(100); active_service number; BEGIN select database_role into role from v$database; if role='primary' then select count(*) into active_service from sys.v_$active_services where name = '&SERVICE_NAME'; if (active_service<1) then dbms_service.start_service('&service_name'); end if; end if; EXCEPTION when others then ora_err := substr(sqlerrm,1,100); execute immediate 'ALTER SESSION SET events ''20099 incident(manage_dgswitch_pkg)''' ; raise_application_error(-20099,ora_err); END manage_dgservice; END manage_dgswitch_pkg; CREATE OR REPLACE TRIGGER manage_dgservice after startup on database BEGIN manage_dgswitch_pkg.manage_dgservice; END; / Folie 23

24 >CLIENT FAILOVER Configure OCI Client Failover, when Application can use only ONE IP address Configure add IP address (VIP) and VIP Listener, that switched to another server during switchover and failover, if the database starts as primary database. This solution is implemented using After startup trigger Folie 24

25 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATAGUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 25

26 >FAST-START FAILOVER CONFIGURATION Health Condition (default) Datafile Offline Corrupted Dictionary Corrupted Controlfile Folie 26

27 >FAST-START FAILOVER CONFIGURATION 1. Determine the protection mode Protection Mode Prerequisites Oracle 10g: Maximum Availability Up Oracle 11g: Maximum Availability, Maximum Performance 2. Specify the target standby database with the FastStartFailoverTarget configuration property Example DGMGRL> edit database 'T1201_2' set property > FastStartFailoverTarget='T1201_3'; DGMGRL> edit database 'T1201_3' set property > FastStartFailoverTarget='T1201_2'; 3. Set The FastStartFailoverLagLimit (only for Maximum Performance Protection Mode) 4. Set FastStartFailoverthreshold metric (default 30 sec) Do not set FastStartFailoverthreshold to low (<30 sec) value Folie 27

28 >FAST-START FAILOVER CONFIGURATION 5. Observer Configuration Observer Tasks Monitors the availability of the primary database and initial FSFO Reinstate new standby database after FSFO Conditions for FSFO Failover By default the observer will initiate failover to the target standby if ALL of the following are true: observer is running observer and the standby both lose contact with the primary observer is still in contact with the standby FastStartFailoverthreshold timeout has elapsed Folie 28

29 >FAST-START FAILOVER CONFIGURATION How Observer Monitoring really works? In below example FastStartFailoverthreshold =30 sec The observer will be pinging SQL Net ping using every few seconds. If a ping takes more than 30/2 seconds then the ping is canceled, the connection is dropped and a new connection made and a new ping sent. So if the primary freezes up for anything more than 15 seconds and then takes more than 15 seconds to open a new connection and answer the 2nd ping, the Observer will see it as dead, even though no errors have been reported. So it then signals the target standby to perform failover. The standby checks how long since it heard from the primary and sure enough it says its more than 30 seconds, though there is no direct evidence for this, just the acknowledgment that it accepted the failover so it must have been more than 30 seconds. Folie 29

30 >FAST-START FAILOVER CONFIGURATION Location The best location, when the observer is located separate from the production and standby data centers and connects to the production and standby database via the same network used by the client application. We install observer on the application server (if it is possible) in the different Environment The Steps to configure Observer on the application server in the different Environment Install the complete Oracle Client Administrator Observer must match the database version Compatibility Matrix (Doc ID ) Configure the tnsnames.ora file on the observer system so that the observer is able to connect to the primary database and the pre-selected target standby database. Configure External Password Store (Note: ) no license for the Advanced Security Option required Folie 30

31 >FAST-START FAILOVER CONFIGURATION Observer stop/start Observer should be started as background process. If you start observer manual using dgmgrl command line and you leave the session, the connection to the database will be lost. From 11.2 onwards, one can use the following command to start observer: dgmgrl -logfile /tmp/observer.log "start observer" & After observer start the new process (dgmglr) will be start Observer start script (here example for Oracle 12C) export ORACLE_BASE=/ora_u01/app/oraagt export TNS_ADMIN=/ora_u01/app/oraagt/admin/network export ORACLE_HOME=/ora_u01/app/oraagt/product/ /client64 # Set up search paths export PATH=$PATH:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/openwin/bin:/usr/ccs/bin/:. export BASE_PATH=$PATH export PATH=$ORACLE_HOME/bin:$BASE_PATH dgmgrl -logfile $ORACLE_BASE/Observer/log/ob<DB_NAME>.log /@<db_connect_string> "start observer file='/ora_u01/app/oraagt/product/ /client64/<db_name>.dat'" & Folie 31

32 >FAST-START FAILOVER CONFIGURATION Observer stop script (here example for Oracle 12C) export ORACLE_BASE=/ora_u01/app/oraagt export TNS_ADMIN=/ora_u01/app/oraagt/admin/network export ORACLE_HOME=/ora_u01/app/oraagt/product/ /client64 # Set up search paths export PATH=$PATH:/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/openwin/bin:/usr/ccs/bin/:. export BASE_PATH=$PATH export PATH=$ORACLE_HOME/bin:$BASE_PATH dgmgrl -logfile $ORACLE_BASE/Observer/log/ob<DB_NAME>.log << eof connect /@<db_connect_string_primary> stop observer; Integrate this script into server runlevel to provide automatic stop/start during server reboot Folie 32

33 >FAST-START FAILOVER CONFIGURATION 6. ENABLE FAST_START_FAILOVER using DGMGRL DGMGRL> connect / Connected as SYSDG. DGMGRL> enable fast_start failover; DGMGRL> show configuration verbose; Configuration Name: T120 Enabled: YES Protection Mode: MaxAvailability Fast-Start Failover: ENABLED Databases: T120_2 - Primary database T120_3 - Physical standby database Fast-Start Failover Threshold: 40 seconds Observer: oragct2 Shutdown Primary: TRUE Current status for "T120": SUCCESS 7. Run Switchover and Failover Tests with the application using DGMGRL Not use the manual Switchover using SQL*Plus, otherwise the Broker is not aware of the new values and you'll end up having to drop and recreate the Broker configuration. Folie 33

34 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATAGUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 34

35 >DATA GUARD ADMINISTRATION The Steps after Failover Startup mount of the new standby database using dgmgrl Observer will reinstate the standby database Check Redo/Apply -Transport Check Cloud-Control Information (if you use it) (The bugs: , ) Check, if flashback set to ON on standby databases Check, if the protection mode is correct Check DataGuard Configuration using dgmgrl Remove all old archivelogs and flashback logs on standby and primary database Folie 35

36 >DATA GUARD ADMINISTRATION Lufthansa Systems RMAN backup concept Configure and activate backup on the primary and secondary sites. If the database_role='primary' the backup will be continued, in another case the script will be finished with "exit 0" There is only one RMAN CATALOG in which the primary database is registered. on the primary side. It is to recommend having a separately backup for the Disaster Recovery Database with separately RMAN CATALOG in the same location. Due to the fact, that standby database cannot be registered in the RMAN CATALOG, register the primary database in the new RMAN CATALOG. This new RMAN CATALOG can be used for backup on the standby database. For the case, that backup is taken from the PRIMARY database, set the following configuration : For the standby database: Oracle 10g: RMAN> CONNECT TARGET RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY; Oracle up 11g RMAN> CONNECT TARGET RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; For the primary database RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; Folie 36

37 >DATA GUARD ADMINISTRATION Parameter changes Some parameters (e.g ALTER SYSTEM and ALTER DATABASE SET) will be NOT PROPAGATED to the standby database. Online data move (Up Oracle 12C) after datafile move on the primary database the file will be NOT MOVED to new location on the standby database. The steps to do on the standby database: cancel media recovery: alter database recover managed standby database cancel; move datafile ' alter database move datafile '<source location>' to '<taget location>; activate media recovery: alter database recover managed standby database disconnect from session; Configure the job to check the parameter/config differences on on the primary and standby databases. Folie 37

38 >DATA GUARD ADMINISTRATION Active DataGuard (Up Oracle 11g ) Create add service and use "after startup" trigger to handle this service. Set Active DataGuard ALTER DATABASE OPEN; ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION USING CURRENT LOGFILE; Folie 38

39 >DATA GUARD ADMINISTRATION Data Guard Standby-First Patch Apply (up Oracle Database ) The following types of patches are candidates to be Data Guard Standby-First certified: Database home interim patches Exadata bundle patches (e.g. Monthly and quarterly database patches for Exadata) Database patch set updates Folie 39

40 >Agenda ABOUT LUFTHANSA SYSTEMS BEFORE YOUR START IMPLEMENTING PHYSICAL ORACLE DATA GUARD DATA GUARD BROKER CLIENT FAILOVER FAST-START FAILOVER CONFIGURATION(FSFO) DATA GUARD ADMINISTRATION DATA GUARD AND VIRTUALISATION Folie 40

41 >DATA GUARD AND VIRTUALISATION The primary and standby server should run on different physical servers. LINUX VMWARE : Affinity Rules configuration IBM POWER VM: Create the job to check, if the primary and standby LPAs have different "Hardware system identifier" Our Tests (For Oracle 10g/11g/12c) Live Partition Mobility / vmotion with Workload Live Partition Mobility / vmotion with Redo log shipment Workload Live Partition Mobility / vmotion during Fast-Start Failover RESULT: No Virtualization specific problems have been detected Folie 41

42 >THANK YOU FOR YOUR ATTENTION. ANY QUESTIONS? 16. November 2014