copyright © 2012, oracle and/or its affiliates. all rights reserved confidential – oracle...

Copyright © 2012, Oracle and/or its affiliates. All rights reserved Confidential – Oracle Restricted.1

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle. Release timing for Oracle Database 12c is planned for Calendar Year 2013.


Oracle Data Guard Zero-Downtime Database Maintenance Sally PiaoVice PresidentDatabase and Exadata System Test


A look at Rolling Upgrades today

A customer’s viewpoint

Simple Database Upgrades for the future

In Closing

Agenda

4 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Database Rolling Upgrades

PRODPhysica

lSTBY

synchronize

Install new Oracle version in separate homes on A & B, set guaranteed

restore point (GRP) on A

synchronize LogicalSTBY

PRODTemporarily convert B to use SQL

Apply, upgrade and sync

Database A Database B

SWITCHOVERSwitchover, flashback A to GRP,

mount in new/upgraded home PRODPhysical STBY

synchronize PRODUpgrade A via redo stream

and synchronizePhysical STBYrelease n

release n+1

My Oracle Support Note 949322.1





In Closing

Agenda


Just How Many Steps Is That?

1. Disable the Broker configuration

2. Stop the Broker at the Primary

3. Stop the Broker at the Standbys

4. Configure the Redo transport parameters on the target standby

5. Configure the Redo transport parameters on bystander standbys

6. Set the LOG_FILE_NAME_CONVERT parameter to clear logfiles

7. Create a guaranteed restore point on the primary database

8. Create a guaranteed restore point on the standby database

9. Cancel Managed Recovery

10. Execute DBMS_LOGSTDBY.BUILD at primary

11. Convert the standby to a Transient Logical standby using KEEP IDENTITY

12. Open the Transient Logical standby

13. Start SQL Apply

14. Turn off automatic archive log delete

15. Synchronize


But Wait! There’s More!

16. Stop SQL Apply

17. Create a 2nd guaranteed restore point

18. Stop Redo Transport

19. Upgrade the Transient Logical standby

20. Enable Redo Transport

21. Restart SQL Apply

22. Synchronize

23. Start Switchover at Primary

24. Complete Switchover at standby

25. Open new Primary

26. Stop redo transport

27. Flashback the original Primary

28. Mount original Primary in new home

29. Convert it to a physical standby

30. Shutdown

31. Mount new Physical Standby

32. Start Redo Apply

33. Enable redo transport

34. Synchronize

35. Start switchover on new primary


And finally

36. Complete switchover at standby

37. Open new Primary

38. Restart old Primary as a standby

39. Start Managed Recovery

40. Drop 3 guaranteed restore points

41. Enable the Broker Configuration





In Closing

Agenda


DBMS_ROLLING: Concepts

Rolling changes can be applied on the whole Data Guard configuration– Three stages (Specification – Compilation – Execution)

– Execution has three stages: Start, Switchover, Finish

Two key groups– Leading Group

Changes are applied first (before Switchover) Has a Master Database (the future primary database)

– Trailing Group Changes are applied last (after Switchover) Has a Master Database (the original primary)


DBMS_ROLLING: Concepts

Leading Group– Need to identify the Master Database (LGM) during Specification

– LGM starts as a Physical Standby, converted into a Logical Standby (START), and then becomes the primary database (SWITCHOVER)

– Other databases in the Leading Group protect the LGM

– LGM responsibility transferrable on failure

Trailing Group– Contains the original primary database (Trailing Group Master)

– Other databases in the Trailing Group protect the TGM

– TGM responsibility transferrable on failure


Data Guard Simple Rolling UpgradesSimple, Reliable, Repeatable Database Rolling Upgrades

Start Switchover Finish


Goal

Early problem detection Dedicated interface: DBMS_ROLLING PL/SQL package Centralized, simplified, and uniform execution Fault tolerance Configuration rollback Centralized monitoring: DBA_ROLLING views

Simple, Reliable, Repeatable


Upgrading The Database Software

The Data Guard Simple Rolling Upgrades procedure will be usable for database version upgrades starting with the first patchset of Oracle Database12c.

– To upgrade from previous Oracle Database11g releases to Oracle Database12c and to move from the first release of Oracle Database 12c to the first patchset you will need to use the classic Transient Logical Standby upgrade procedure.

The procedure can be used for other database maintenance tasks with the first release


What Kind Of Changes Can Be Made?

Add Partitioning to Non-Partitioned Tables Change Basicfile LOBs to Securefile LOBs Change XML-CLOB to Binary XML Alter table to be OLTP-compressed

First Release Examples


New Data Type Support

Advanced Data Type Support– XML OR

– Binary XML

– Securefile Deduplication

– Objects/Collections (includes SDO_GEOMETRY, DICOM)

– New Support for Oracle-Supplied Features DBFS AQ Oracle Text XDB

Eliminating Barriers to Utilizing Database Rolling Upgrade


Process – Planning & Setup Phase

Generate an upgrade plan– Call DBMS_ROLLING.INIT_PLAN

Generates an upgrade plan with a configuration specific set of instructions to guide the administrator through the upgrade process

– Call DBMS_ROLLING.SET_PARAMETER Modify parameters of the rolling upgrade

Prepare your changes to the database


Process - Execution Phase

Call DBMS_ROLLING.START_PLAN– Configures primary and standby databases participating in the upgrade

Make changes to the standby database Call DBMS_ROLLING.SWITCHOVER

– Swaps roles between current primary and new primary with the changes, switchover is only downtime required

Call DBMS_ROLLING.FINISH_PLAN– Completes upgrade of the old primary and bystanders and resynchronizes with the new primary


A Sample Walkthrough - Planning Phase

Primary database in Boston Physical standby database in

Cambridge (SYNC) 2nd Physical standby database in

Chicago (ASYNC) Broker Controlled

Current Configuration

DGMGRL> SHOW CONFIGURATION

Configuration – OOW2012

Protection Mode: MaxAvailability Databases: bos - Primary database cam - Physical standby database chi - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:SUCCESS

DGMGRL>



Connect to the Primary Execute the INIT_PLAN

procedure Sets up default parameters

– 2 for each database

– 25 general parameters

Start the Planning Process

SQL> exec dbms_rolling.init_plan(‘cam’);

PL/SQL procedure successfully completed.

SQL> select name, curval from 2 dba_rolling_parameters where scope is null;

NAME CURVAL------------------------ ------------------------ACTIVE_SESSIONS_TIMEOUT 3600ACTIVE_SESSIONS_WAIT 0BACKUP_CTLFILE rolling_change_backup.fDICTIONARY_LOAD_TIMEOUT 3600DICTIONARY_LOAD_WAIT 0EVENT_RECORDS 10000FAILOVER 0GRP_PREFIX DBMSRU_…UPDATED_TGS_WAIT 1

25 rows selected.



Create Redo Transport parameters at target database

– In our example, on CAM to point to BOS and CHI

Required to complete the process after the switchover as the Broker is disabled.

Reconfigure Redo Transport

SQL> alter system set log_archive_dest_5='service="BOS", SYNC reopen=30 db_unique_name="BOS" valid_for=(PRIMARY_ROLE, ONLINE_LOGFILE)';

System altered.

SQL> alter system set log_archive_dest_6='service="CHI", ASYNC reopen=30 db_unique_name="CHI" valid_for=(PRIMARY_ROLE, ONLINE_LOGFILE)';

System altered.

SQL>



Example “INVOLVEMENT” Each database protects the

Primary when in the Standby role– BOS Primary

CAM and CHI protect BOS

– CAM Primary BOS and CHI protect CAM

– CHI Primary BOS and CAM protect CHI

Examining Parameters of the Plan

SQL> select scope, name, curval 2 from dba_rolling_parameters 3 where scope is not null order by scope;

SCO NAME CURVAL--- --------------- ---------------bos INVOLVEMENT FULLbos PROTECTS NONEcam INVOLVEMENT FULLcam PROTECTS PRIMARYchi INVOLVEMENT FULLchi PROTECTS PRIMARY

6 rows selected.

SQL>



Validates plan parameters Creates an upgrade plan

– Successful build required in order to perform a rolling upgrade

Parameter changes require that the procedure is called again

Complete plan can be reviewed in DBA_ROLLING_PLAN

Build the Plan when ready

SQL> select revision, status, phase 2 from dba_rolling_status;

REVISION STATUS PHASE---------- ------------ -------------- 0 READY BUILD PENDING

SQL> exec dbms_rolling.build_plan();



REVISION STATUS PHASE---------- ------------ -------------- 1 READY START PENDING


A Sample Walkthrough - Start Phase

Must be executed on the primary database

– Formally starts the rolling upgrade operation.

– When complete, the configuration possesses a fully configured transient logical standby database.

Still no outage

Start the Process

SQL> exec dbms_rolling.start_plan();


SQL> select dbun, role, engine_status, 2 update_progress from dba_rolling_databases;

DBUN ROLE ENGINE_STATUS UPDATE_PROG---------- --------- -------------- -----------bos PRIMARY NOT APPLICABLE NOT STARTEDcam LOGICAL RUNNING NOT STARTEDchi PHYSICAL RUNNING NOT STARTED


REVISION STATUS PHASE---------- ------------ -------------- 1 READY SWITCH PENDING


A Sample Walkthrough - Start Phase

Make your changes to the database– For example, move a table from LOBs to Securefile LOBs

Stop SQL Apply Make the changes to the Transient Logical Standby Restart SQL Apply

Perform the changes


A Sample Walkthrough - Switchover Phase

Prior to the switchover you can move read clients to the transient logical standby to avoid an outage

Update users will be stalled and eventually must reconnect to the new primary using standard client failover best practices.

Outage should be no more than 90-120 seconds for the database

Switchover!

SQL> exec dbms_rolling.switchover();



DBUN ROLE ENGINE_STATUS UPDATE_PROG---------- --------- -------------- -----------bos LOGICAL STOPPED NOT STARTEDcam PRIMARY NOT APPLICABLE NOT STARTEDchi PHYSICAL STOPPED NOT STARTED


REVISION STATUS PHASE---------- ------------ -------------- 1 READY FINISH PENDING


A Sample Walkthrough - Finish Phase

Manually restart and mount the all other databses

Execute the FINISH Procedure to finalize the rolling upgrade operation.

– Configures the former primary as a physical standby, and configures remaining physical standbys to recover the change redo from the new primary.

Finish the change

SQL> exec dbms_rolling.finish_plan();



DBUN ROLE ENGINE_STATUS UPDATE_PROG---------- --------- -------------- -----------bos PHYSICAL RUNNING FINISHEDcam PRIMARY NOT APPLICABLE FINISHEDchi PHYSICAL RUNNING FINISHED


REVISION STATUS PHASE---------- ------------ -------------- 1 READY DONE


A Sample Walkthrough - Finish Phase

Enable the Broker– It reconfigures itself to the new

Primary database ‘CAM’.

Execute a Broker switchover– If required to return to the original

configuration.

Re-enable the Broker and switchover

DGMGRL> enable configuration;Enabled.DGMGRL> show configuration

Configuration – OOW2012

Protection Mode: MaxAvailability Databases: cam - Primary database bos - Physical standby database chi - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:SUCCESS

DGMGRL> switchover to bos;Performing switchover NOW, please wait...…Switchover succeeded, new primary is "bos"





In Closing

Agenda


DBMS_ROLLING: Key Features

Specify – Compile – Execute Protocol– Catch configuration errors at Compilation step

– Run-time errors are detected during Execution

State is kept in the database– Provides robustness

Run-time steps are constant – Regardless of how many databases are involved

Handles failure at the original primary database Allows Data Protection for the upgraded primary right from the start


Behind the Scenes

PROD PhysicalSTBY

Synchronize – redo applySets guaranteed restore point

(GRP) on A and B

Synchronize – sql apply Logical

STBY

PRODConverts B to transient logical

Database A Database B

PRODSWITCHOVERSwitchover PhysicalSTBY

Synchronize – redo applyPROD

Flashback A to GRP, upgrade via redo stream

Physical STBY

Current StructureNew Structure


Now How Many Steps?

Prepare for maintenance– Disable the Broker, INIT_PLAN, BUILD_PLAN, Configure Redo transport

START_PLAN Perform Maintenance SWITCHOVER Mount original Primary FINISH_PLAN

– Enable the Broker, Switchover

Resources• OTN HA Portal:

http://www.oracle.com/goto/availability

• Maximum Availability Architecture (MAA): http://www.oracle.com/goto/maa

• MAA Blogs: http://blogs.oracle.com/maa

• Exadata on OTN:http://www.oracle.com/technetwork/database/exadata/index.html

• Oracle HA Customer Success Stories on OTN:http://www.oracle.com/technetwork/database/features/ha-casestudies-098033.html


Graphic Section Divider


The preceding is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle's products remains at the sole discretion of Oracle. Release timing for Oracle Database 12c is planned for Calendar Year 2013.

copyright © 2012, oracle and/or its affiliates. all rights reserved confidential – oracle...

Documents