Oracle Active Data Guard Rolling Upgrade

Oracle Active Data Guard
Database Rolling Maintenance

Larry M. Carpenter
Distinguished Product Manager - Oracle
Kalyan Kumar Kallepally

Senior Database Administrator - Wellcome Trust Sanger Institute
Joydip Kundu
Director, Software Development - Oracle
1 Copyright © 2012, Oracle and/or its affiliates. All rights reserved Confidential – Oracle Restricted.
Agenda
 A look at Rolling Upgrades today

 A customer’s viewpoint
 Simple Database Upgrades for the future
 In Closing
My Oracle Support Note 949322.1
Database Rolling Upgrades
Database A Database B
Install new Oracle version in separate
homes on A & B, set guaranteed Physical
PROD synchronize
STBY
restore point (GRP) on A
Temporarily convert B to use SQL synchronize Logical
Apply, upgrade and sync PROD
STBY
Switchover, flashback A to GRP, Physical SWITCHOVER

mount in new/upgraded home STBY PROD
Upgrade A via redo stream Physical synchronize

and synchronize STBY
PROD
release n
release n+1
3 Copyright © 2011, Oracle and/or its affiliates. All rights reserved.

Agenda

 In Closing
Introducing
Kalyan Kallepally
Senior Database Administrator
Upgrade Databases With Minimal
downtime
Oracle Open World - 2012
by
Kalyan Kallepally
Senior Database Administrator
Wellcome Trust Sanger Institute
Cambridge, UK
kalyan.kallepally@sanger.ac.uk
Who am I
• Working as Senior Database Administrator at
– Wellcome Trust Sanger Institute
• 10+ years of experience in Oracle (8-11gr2)
• 5+ years of experience in MySQL, SQL Server
• Recently started blogging
– www.dbakalyan.wordpress.com
– You can reach me on dba_kkk@yahoo.co.uk
Wellcome Trust Sanger Institute
• One of the leading genomics centres in the world

• Located in Hinxton, south of Cambridge, UK
• Founded in 1993 by the Wellcome Trust and the UK Medical Research Council
(MRC)
• Primarily funded by the Wellcome Trust
• The institute is named after Dr Fred Sanger – The double Nobel prize-winning
biochemist
• Responsible for the completion of 1/3 of the human genome
• Current computational
capacity of 16k cores:
– 12k cores on blade format
– 4k cores in racked servers
• Current usable storage
capacity 16 Petabytes:
– Estimated growth 3
Petabytes/year
• Data shared globally across
the world with many
scientific research institutes
Database Layout
• Primary database (300G)
– ASM
– 2 Physical standbys (local and remote)
• Local standby is within same site as of the primary
but placed in a different quadrant of the datacentre
• DR standby is 10 miles away from the Primary with
dedicated private 10Gb/s WAN to DR datacentre
Upgrade Process
• Upgraded database from 11.1.0.6 to 11.2.0.3
using Transient Logical standby
– Down time reduced by 98%
• Upgrade process is split into 2 phases:
– Phase 1 (Upgrade Primary Database)
– Phase 2 (Upgrade Standbys & Switchback)
Phase - 1
Upgrade Primary Database
Read Write Clients Read Only Clients
11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
11.1.0.6 Redo shipping
Production
Database Backup
ASM Oracle Home (11.1.0.6)

Broker
11.1.0.6 DR Site
Oracle Home (11.1.0.6)
Physical Standby
Sync or Async Database
Redo shipping Redo
apply ASM
Redo Logs

Upgrade Pre-requisites
• Disable Data Guard Broker
• Protection level must be either Maximum
availability or Maximum performance
• Ensure Flashback is enabled on all databases in
the Data Guard configuration
• Create guaranteed restore points
• Parameter “compatible” must be set to same on
all the databases
11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
Primary
Database Backup

Broker
11.1.0.6 DR Site
Physical Standby
• Disable Broker Redo shipping Redo
apply ASM
• Enable Flashback Redo Logs
• Create Guaranteed Restore points

11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
Primary
Database Backup

Broker
11.1.0.6 DR Site
Logical Standby
Physical Standby
Redo shipping Redo
• Convert the DR physical standby to apply ASM
Transient Logical Standby Redo Logs

SQL
apply
• Check if Logical standby is in sync Transform Redo to SQL

11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
Primary
Database Backup

Broker
11.1.0.6
11.2.0.3 DR Site
Oracle Home (11.1.0.6) Logical Standby
Redo shipping
• Install new version of Oracle ASM
database Software Redo Logs

SQL
• Upgrade the LSTBY using DBUA from apply
the new ORACLE HOME Transform Redo to SQL
• After successful upgrade check if Oracle

OracleHome
Home(11.2.0.3)
(11.1.0.6)
LSTBY is in sync again

11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
Primary
Database Backup
SQL
apply
Broker
Transform
11.2.0.3 DR Site
Redo to SQL
Sync or Async Logical Standby
Redo shipping Database
• Plan for switch over to LSTBY
ASM
• Stop the redo transmission to PSTBY Redo Logs
Online SQL
• Up to this point absolutely there is no Redo Logs apply
impact on the availability of the Transform Redo to SQL
primary database. OracleHome

Oracle Home(11.2.0.3)
(11.1.0.6)
• Switch over
• Re-point the clients, services
Phase - 2
Upgrade Standbys & Switch Back
11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
Logical Standby
Database Backup
SQL
ASM
apply Oracle Home (11.1.0.6)
Broker
Transform
11.2.0.3 DR Site
Redo to SQL
Oracle Home (11.1.0.6) Primary
Sync or Async
• LSTBY (previous Primary) is in a
ASM
Transient state
Online
• It is Running lower version than primary Redo Logs
• Cannot understand/apply changes

received from the higher version of OracleHome
(11.1.0.6)
primary database
• Cannot provide disaster recovery
11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Sync or Async
Physical Standby
Logical Standby
Database
Database Backup
Redo
SQL
ASM apply
apply Oracle Home (11.1.0.6)
Broker
Transform
11.2.0.3 DR Site
Redo to SQL
(11.1.0.6)
Oracle Home (11.2.0.3) Primary
Sync or Async
• Flashback LSTBY to guaranteed restore
ASM
point and shut down
Online
• Install new oracle version Redo Logs
• Mount database from new home and

convert LSTBY to PSTBY OracleHome
(11.1.0.6)
• When Redo Apply starts, it registers a new
incarnation from the primary database
11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
11.2.0.3
11.1.0.6
Sync or Async
Redo shipping
Physical Standby
Database Backup
ASM Redo
apply Online
Redo Logs Broker
Redo Logs
11.2.0.3 DR Site
(11.2.0.3) Primary
Sync or Async
• Wait for physical standby to be upgraded Redo
apply ASM
via the redo stream
Redo Logs
Online
• At this point you have a second Redo Logs
interruption to the database availability

• Switch Back Primary to its Original OracleHome
(11.1.0.6)
location
• Re-point the clients accordingly
11.1.0.6 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
11.2.0.3 Sync or Async
Redo shipping
Primary
Database Backup
ASM Oracle
OracleHome
Home(11.2.0.3)
(11.1.0.6)
Online Broker
Redo Logs
11.2.0.3 DR Site
(11.2.0.3)
Oracle Home (11.1.0.6) Physical Standby
Sync or Async
• Install new database home on other Redo
apply ASM
standbys
Redo Logs
• Mount PSTBY from new home
• Flashback database to guaranteed
restore point OracleHome
(11.1.0.6)
11.1.0.6
11.2.0.3 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Redo shipping
Primary
Database Backup
ASM
Oracle
OracleHome
Home(11.2.0.3)
(11.1.0.6)
Online Broker
Redo Logs
11.2.0.3 DR Site
(11.2.0.3) Physical Standby
Sync or Async
• Enable the redo transmission to Redo
apply ASM
local PSTBY to catch up to new
Redo Logs
incarnation
• PSTBY will be upgraded via redo
stream Oracle
OracleHome
Home(11.2.0.3)
(11.1.0.6)
• Enable Broker
11.2.0.3 Local Site
Physical Standby
Redo Database
apply
ASM
Redo Logs
Redo shipping
Primary
Database Backup
ASM
Oracle
OracleHome
Home(11.2.0.3)
(11.1.0.6)
Online Broker
Redo Logs
11.2.0.3 DR Site
(11.2.0.3) Physical Standby
Sync or Async
• Drop guaranteed restore points Redo
apply ASM
• Rolling upgrade has Finished and
Redo Logs
databases are back in the original
positions
• With very minimal interruptions OracleHome
(11.1.0.6)
Pros & Cons
Regular /Conventional Upgrade Rolling Upgrade using Transient LSTBY
• Upgrade using DBUA/CLI • Down time is required for only
(50mins) switchover (reduced by 98% -
• Upgrade using datapump - 5mins)
Complete Down time required • Standbys are automatically
for exports, scp & imports
(approx 3 hrs) upgraded
– Manually recreate standbys • Fail safe options at each step
after the upgrade • Down time is independent of
• Errors at any stage can database size
increase down time
Caveats
• Need to upgrade grid/ASM before the database upgrade
• Need to manually update the OCR (srvctl) registries
• If Upgrading from 11gR1 to 11gR2 then move the database
spfile from $OH/dbs to ASM - if not, DBUA will fail
• If the “compatible” parameter is changed after LSTBY upgrade
- database cannot be rolled back
• To change the “compatible” parameter after the upgrade
- another downtime is needed
References
• http://www.oracle.com/technetwork/database/features/availability/maa-
wp-11g-transientlogicalrollingu-1-131927.pdf
• http://www.oracle.com/technetwork/database/features/availability/maa-
wp-11g-upgrades-made-easy-131972.pdf
Over to Larry
Thank you
Just How Many Steps Is That?
1. Disable the Broker configuration 8. Create a guaranteed restore point on the

2. Stop the Broker at the Primary standby database
3. Stop the Broker at the Standbys 9. Cancel Managed Recovery
4. Configure the Redo transport parameters 10. Execute DBMS_LOGSTDBY.BUILD at
on the target standby primary
5. Configure the Redo transport parameters 11. Convert the standby to a Transient
on bystander standbys Logical standby using KEEP IDENTITY
6. Set the LOG_FILE_NAME_CONVERT 12. Open the Transient Logical standby
parameter to clear logfiles 13. Start SQL Apply
7. Create a guaranteed restore point on the 14. Turn off automatic archive log delete
primary database 15. Synchronize
But Wait! There’s More!
16. Stop SQL Apply 26. Stop redo transport

17. Create a 2nd guaranteed restore point 27. Flashback the original Primary
18. Stop Redo Transport 28. Mount original Primary in new home
19. Upgrade the Transient Logical standby 29. Convert it to a physical standby
20. Enable Redo Transport 30. Shutdown
21. Restart SQL Apply 31. Mount new Physical Standby
22. Synchronize 32. Start Redo Apply
23. Start Switchover at Primary 33. Enable redo transport
24. Complete Switchover at standby 34. Synchronize
25. Open new Primary 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
Agenda

 In Closing
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 Upgrades
Simple, Reliable, Repeatable Database Rolling Upgrades
Start Switchover Finish
Goal
Simple, Reliable, Repeatable
 Early problem detection

 Dedicated interface: DBMS_ROLLING PL/SQL package
 Centralized, simplified, and uniform execution
 Fault tolerance
 Configuration rollback
 Centralized monitoring: DBA_ROLLING views
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?
First Release Examples
 Add Partitioning to Non-Partitioned Tables

 Change Basicfile LOBs to Securefile LOBs
 Change XML-CLOB to Binary XML
 Alter table to be OLTP-compressed
New Data Type Support
Eliminating Barriers to Utilizing Database Rolling Upgrade
 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
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
Current Configuration
 Primary database in Boston DGMGRL> SHOW CONFIGURATION
Configuration – OOW2012
 Physical standby database in Protection Mode: MaxAvailability
Cambridge (SYNC) Databases:

bos - Primary database
cam - Physical standby database
 2nd Physical standby database in chi - Physical standby database
Chicago (ASYNC) Fast-Start Failover: DISABLED
Configuration Status:
 Broker Controlled SUCCESS
DGMGRL>
Start the Planning Process
 Connect to the Primary SQL> exec dbms_rolling.init_plan(‘cam’);
PL/SQL procedure successfully completed.

 Execute the INIT_PLAN SQL> select name, curval from
procedure 2 dba_rolling_parameters where scope is null;
NAME CURVAL
 Sets up default parameters ------------------------
ACTIVE_SESSIONS_TIMEOUT
------------------------
3600
ACTIVE_SESSIONS_WAIT 0
– 2 for each database BACKUP_CTLFILE rolling_change_backup.f
DICTIONARY_LOAD_TIMEOUT 3600
– 25 general parameters DICTIONARY_LOAD_WAIT

EVENT_RECORDS
0
10000
FAILOVER 0
GRP_PREFIX DBMSRU_
…
UPDATED_TGS_WAIT 1
25 rows selected.
Reconfigure Redo Transport
 Create 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)';
parameters at target database
System altered.
– In our example, on CAM to point SQL> alter system set log_archive_dest_6='service="CHI",
to BOS and CHI ASYNC reopen=30 db_unique_name="CHI"
valid_for=(PRIMARY_ROLE, ONLINE_LOGFILE)';
 Required to complete the process System altered.
after the switchover as the Broker SQL>
is disabled.
Examining Parameters of the Plan
 Example “INVOLVEMENT” SQL> select scope, name, curval

2 from dba_rolling_parameters
3 where scope is not null order by scope;
 Each database protects the SCO NAME CURVAL
Primary when in the Standby role ---

bos
---------------
INVOLVEMENT
---------------
FULL
bos PROTECTS NONE
– BOS Primary cam
cam
INVOLVEMENT
PROTECTS
FULL
PRIMARY
chi INVOLVEMENT FULL
 CAM and CHI protect BOS chi PROTECTS PRIMARY
– CAM Primary 6 rows selected.
SQL>
 BOS and CHI protect CAM
– CHI Primary
 BOS and CAM protect CHI
Build the Plan when ready
 Validates plan parameters SQL> select revision, status, phase

2 from dba_rolling_status;
 Creates an upgrade plan REVISION STATUS PHASE

---------- ------------ --------------
0 READY BUILD PENDING
– Successful build required in order
SQL> exec dbms_rolling.build_plan();
to perform a rolling upgrade
 Parameter changes require that SQL> select revision, status, phase

the procedure is called again
REVISION STATUS PHASE
 Complete plan can be reviewed in

---------- ------------ --------------
1 READY START PENDING
DBA_ROLLING_PLAN
A Sample Walkthrough - Start Phase
Start the Process
 Must be executed on the primary SQL> exec dbms_rolling.start_plan();

database
SQL> select dbun, role, engine_status,
– Formally starts the rolling upgrade 2 update_progress from dba_rolling_databases;
operation. DBUN
----------
ROLE
---------
ENGINE_STATUS
--------------
UPDATE_PROG
-----------
bos PRIMARY NOT APPLICABLE NOT STARTED
– When complete, the configuration cam LOGICAL RUNNING NOT STARTED
chi PHYSICAL RUNNING NOT STARTED
possesses a fully configured
SQL> select revision, status, phase
transient logical standby 2 from dba_rolling_status;
database. REVISION STATUS PHASE

---------- ------------ --------------
 Still no outage
1 READY SWITCH PENDING
A Sample Walkthrough - Start Phase
Perform the changes
 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
A Sample Walkthrough - Switchover Phase
Switchover!
 Prior to the switchover you can SQL> exec dbms_rolling.switchover();

move read clients to the transient
logical standby to avoid an outage 2 update_progress from dba_rolling_databases;
DBUN ROLE ENGINE_STATUS UPDATE_PROG

 Update users will be stalled and ---------- --------- -------------- -----------
bos LOGICAL STOPPED NOT STARTED
eventually must reconnect to the cam
chi
PRIMARY
PHYSICAL
NOT APPLICABLE
STOPPED
NOT STARTED
NOT STARTED
new primary using standard client SQL> select revision, status, phase
failover best practices. 2 from dba_rolling_status;

 Outage should be no more than ---------- ------------ --------------
1 READY FINISH PENDING
90-120 seconds for the database
A Sample Walkthrough - Finish Phase
Finish the change
 Manually restart and mount the all SQL> exec dbms_rolling.finish_plan();

other databses
 Execute the FINISH Procedure to 2 update_progress from dba_rolling_databases;
DBUN ROLE ENGINE_STATUS UPDATE_PROG

finalize the rolling upgrade ---------- --------- -------------- -----------
bos PHYSICAL RUNNING FINISHED
operation. cam
chi
PRIMARY
PHYSICAL
NOT APPLICABLE
RUNNING
FINISHED
FINISHED
– Configures the former primary as SQL> select revision, status, phase

a physical standby, and configures
remaining physical standbys to ---------- ------------ --------------
1 READY DONE
recover the change redo from the
new primary.
A Sample Walkthrough - Finish Phase
Re-enable the Broker and switchover
 Enable the Broker DGMGRL> enable configuration;

Enabled.
DGMGRL> show configuration
– It reconfigures itself to the new Configuration – OOW2012
Primary database ‘CAM’. Protection Mode: MaxAvailability
Databases:
 Execute a Broker switchover cam - Primary database
bos - Physical standby database
– If required to return to the original chi - Physical standby database
configuration. Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> switchover to bos;

Performing switchover NOW, please wait...
…
Switchover succeeded, new primary is "bos"
Agenda

 In Closing
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
Current Structure
Behind the Scenes New Structure
Database A Database B
Sets guaranteed restore point
Synchronize – redo apply Physical
(GRP) on A and B PROD
STBY
Converts B to transient logical PROD Synchronize – sql apply Logical

STBY
Switchover Physical SWITCHOVER

PROD
STBY
Flashback A to GRP, upgrade Physical Synchronize – redo apply
via redo stream STBY PROD
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

Oracle Active Data Guard Rolling Upgrade

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Active Data Guard Rolling Upgrade

Uploaded by

Copyright:

Available Formats

Oracle Active Data Guard

Database Rolling Maintenance

Kalyan Kumar Kallepally

 A look at Rolling Upgrades today

Switchover, flashback A to GRP, Physical SWITCHOVER

Upgrade A via redo stream Physical synchronize

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

 A look at Rolling Upgrades today

• One of the leading genomics centres in the world

ASM Oracle Home (11.1.0.6)

Oracle Home (11.1.0.6)

ASM Oracle Home (11.1.0.6)

• Create Guaranteed Restore points

Oracle Home (11.1.0.6)

ASM Oracle Home (11.1.0.6)

Transient Logical Standby Redo Logs

Oracle Home (11.1.0.6)

ASM Oracle Home (11.1.0.6)

database Software Redo Logs

the new ORACLE HOME Transform Redo to SQL

• After successful upgrade check if Oracle

LSTBY is in sync again

impact on the availability of the Transform Redo to SQL

primary database. OracleHome

• Cannot understand/apply changes

• Mount database from new home and

interruption to the database availability

1. Disable the Broker configuration 8. Create a guaranteed restore point on the

16. Stop SQL Apply 26. Stop redo transport

36. Complete switchover at standby

 A look at Rolling Upgrades today

 Rolling changes can be applied on the whole Data Guard configuration

Start Switchover Finish

 Early problem detection

 The Data Guard Simple Rolling Upgrades procedure will

 Add Partitioning to Non-Partitioned Tables

 Generate an upgrade plan

 Prepare your changes to the database

 Make changes to the standby database

 Primary database in Boston DGMGRL> SHOW CONFIGURATION

Cambridge (SYNC) Databases:

Chicago (ASYNC) Fast-Start Failover: DISABLED

 Connect to the Primary SQL> exec dbms_rolling.init_plan(‘cam’);

PL/SQL procedure successfully completed.

procedure 2 dba_rolling_parameters where scope is null;

– 25 general parameters DICTIONARY_LOAD_WAIT

 Create Redo Transport SQL> alter system set log_archive_dest_5='service="BOS",

 Required to complete the process System altered.

after the switchover as the Broker SQL>

 Example “INVOLVEMENT” SQL> select scope, name, curval

Primary when in the Standby role ---

– CAM Primary 6 rows selected.

 Validates plan parameters SQL> select revision, status, phase

 Creates an upgrade plan REVISION STATUS PHASE

 Parameter changes require that SQL> select revision, status, phase

 Complete plan can be reviewed in

 Must be executed on the primary SQL> exec dbms_rolling.start_plan();

PL/SQL procedure successfully completed.

database. REVISION STATUS PHASE

 Make your changes to the database

 Prior to the switchover you can SQL> exec dbms_rolling.switchover();

PL/SQL procedure successfully completed.

DBUN ROLE ENGINE_STATUS UPDATE_PROG

REVISION STATUS PHASE