Download Data Guard SQL Apply - Oracle Software Downloads

DATABASE
DATA GUARD SQL APPLY: BACK TO THE FUTURE
Larry M. Carpenter, Oracle Corporation
INTRODUCTION
In Oracle9i Database, Data Guard introduced a new type of standby technology called SQL Apply which maintains a
Logical standby database (a transactional copy of the primary database) in addition to Data Guard’s existing Physical
standby capability. Since its introduction, Logical Standby databases have been deployed in production at many sites
worldwide augmenting customers’ Disaster Recovery strategies and providing users with more access to the standby
data while removing the overhead of running reports and queries on the production database. At the same time these
actions in no way affect the capabilities and recoverability of the Disaster Recovery strategy already in place.
This paper provides a quick review of the Data Guard architecture, how some customers are using SQL Apply today
in production and what’s coming in Oracle Database 10g to improve the Data Guard SQL Apply technology.
A QUICK REVIEW
Using Data Guard, transactions that make changes to the Primary database generate redo data , which is archived
locally and sent to the Physical or Logical standby databases.
When the redo data is transmitted from the Primary database, it is archived on the standby system in the form of
archived redo logs. Then, the archived redo logs are automatically applied on the standby database to maintain
synchronization with the Primary database.
Prior to Oracle9i Database Release 2, there has been only the Physical standby database implementation where the
standby database can be in recovery or open read-only. In other words, while the Physical standby database is
applying logs it cannot be opened for reporting and vice versa. However, even when opened in read-only mode, the
Physical standby database continues to receive redo data from the primary database, maintaining data protection.
With Logical standby databases, you can have the database available for reporting and be applying the logs to the
standby at the same time, allowing the logical standby database to be used for other business activities. Changes from
the Primary database can be applied concurrently with end user access, because the Logical standby database remains
open for updates made through the execution of SQL statements.
Logical standby databases use the same log transport services as Physical standby databases. Although the method of
transmitting redo data from the Primary database to the standby database is always the same, the main difference
between Physical and Logical standby databases is the manner in which the redo logs are applied.
Paper 40144
DATABASE
REDO APPLY ARCHITECTURE
Figure 1 shows Redo Apply automatically sending the Primary database redo data and applying that redo to a Physical
standby database. The redo can be shipped as it is generated or archived on the Primary database. The redo logs are
applied to each Physical standby database using Data Guard managed recovery (MRP).
Figure 1 – Redo Apply Architecture
The Physical standby database is an exact copy of the Primary (or Production) database and can be used not only for
Disaster Recovery in the event of a failure at the primary site but also for planned events (such as system upgrades or
operating system upgrades) and performing backups of the primary database.
Paper 40144
DATABASE
SQL APPLY ARCHITECTURE
The SQL Apply technology first transforms redo data into SQL statements and then executes the generated SQL
statements on the logical standby database. This is done with the use of LogMiner™ technology. Because the logical
standby database is updated by applying SQL statements, it must remain open. This allows users to access the standby
database for queries and reporting purposes at any time. Figure 2 shows the SQL Apply architecture.
Figure 2 – SQL Apply Architecture
Although the logical standby database is open for read/write operations, the tables being maintained by SQL
generated from a primary database log are read-only to users of the logical standby. While those tables are being
updated, they can be used simultaneously for other tasks such as reporting, summations, and queries. The DBA can
optimize these tasks by creating additional indexes and materialized views on the maintained tables, but the tables
must maintain logical consistency from an application access perspective in order to fulfill the role of a standby data
source. Hence, a logical standby database can be used for other business purposes in addition to disaster recovery.
A logical standby database has some restrictions on datatypes, types of tables, and types of data definition language
(DDL). Unsupported datatypes and tables are described in more detail in the Oracle® Data Guard Concepts and
Administration documentation. Later in this paper we will discuss what of these restrictions have been lifted in Oracle
Database 10g.
Paper 40144
DATABASE
SQL APPLY PROCESSING
SQL Apply manages the application of redo data received from the primary site to a logical standby database. The
LSP coordinates parallel background processes to convert transaction information back to SQL and execute those
SQL statements on the logical standby database.
The following figure (Figure 3) shows the LSP and background PX processes involved in the SQL Apply engine:
Figure 3 – SQL Apply Processing Flow

LSP0 process coordinates the parallel mining processes with the parallel applying processes.
PX processes are actually two groups of parallel execution processes that are automatically started by LSP0.
The first group of PX processes uses the LogMiner™ to mine redo logs received from the primary database. The
second group is used to apply these log files to the logical standby database. What is important to note is that the
mining and applying phases are done in parallel, and are synchronized by LSP0 to maintain a high level of database
performance. At all times during the application of redo, the Logical standby database is open and the data
contained within available for use.
Paper 40144
DATABASE
CUSTOMER CASE STUDIES
It is always interesting to see how others are using a new technology and for what purposes. Data Guard SQL Apply
is no exception. Over the past year many customers have been investigating, planning and implementing Logical
standby databases complementing their Physical standby setup. The following three sections outline two banks
current production implementations of Data Guard using both Physical and Logical standby databases.
BANK NUMBER 1 – A WEB SITE
This implementation of Data Guard uses both Logical and Physical standby databases to provide both DR and
general external user access to the data. The data in this case is the content for the Internet web site for this Bank.
Inside the firewall are the Production and its associated Physical standby databases. Outside the firewall are two
Logical standby databases, which provide the content for the web site. This setup is shown in Figure 4 below.
The Web Application developers of the bank constantly update the content of the web site by adding or modifying
the tables in the production database. The redo generated by these updates is sent to the two Logical standby
databases outside the firewall where it is applied and becomes available for the web site. Internet users access the web
site and find all the information about the bank including the bank’s services, eBanking information, Investor
Relations and even job openings.
Figure 4 – An External Web Site
Since there are two Logical standbys the web site is able to maintain load balancing by splitting the incoming users
over both standbys. In the event that one of the systems fail the web site still functions using the remaining standby.
If this happens then when the failed standby comes back on line it is resynchronized with the Production database
automatically using the gap resolution capability of Data Guard. In this manner they are always ‘up’ on the outside.
If there is a failure at the Production site the Physical standby can be brought online by failing over and it will
continue to service the developers and send updates to the web site. By using this kind of implementation the bank
was able to separate the developers from the user very easily thereby preventing any problems with the web site.
Paper 40144
DATABASE
BANK NUMBER 1 – ONLINE BANKING
The same bank has also implemented an on-line banking system to service their customer’s banking needs. In this
case the Production and its Physical standby are outside the firewall where the users perform their banking on the
Production database. The Physical standby provides data protection and rapid failover in the event they lose the
primary site. Inside the firewall is a Logical standby that is used for reporting and general querying. Figure 5 shows
the setup for this application.
Figure 5 – An Online Banking Application
In this application the Production database must reside outside the firewall so that incoming Internet users can
perform banking transactions. The Physical standby must also be kept outside so that if a failover is warranted the
users can continue without any changes to the security setup that allows them to access the database in the first place.
The Logical standby database is another matter. The Internet users have no need to access the data kept in the
Logical standby database since they access and maintain that data from the Production database. The internal users
who wish to do reporting and querying of the data could access the Logical standby if it was kept outside however
this would require that each user knows where the database is and also requires that more ports be opened so that
they can access the data. With the Logical standby inside the firewall only Data Guard needs to send information (the
Redo) through the firewall and the users do their work inside without sending any data over the outside to inside link.
Paper 40144
DATABASE
BANK NUMBER 2 – BRANCH BANKING
In this Data Guard implementation (shown in Figure 6) the databases involved are all within the bank’s Intranet with
no access from outside. The main users are the employees of each branch where they access the customer’s data in
the Production database at a central server. Users who need to perform queries and reports on the production data
have been moved off to the Logical standby. At a remote site the Physical standby provides DR protection and if
necessary can easily become the Primary database (from a switch over or fail over) for the Logical standby as well.
Figure 6 – A Branch Banking Application
The Logical standby database is currently on the same system as the Production database to facilitate management of
the two open databases and prepare for the time when they will be able to move queries from the Branch users off
the Production database onto the Logical standby as well as the reporting function. When that time arrives a Physical
standby database could be created from the Logical standby (as a cascaded redo destination) and placed on the same
server as the remote Physical standby database completing their DR strategy in the event the entire Primary site is lost
and the Branch and Reporting users need to Failover.
Paper 40144
DATABASE
NEW FEATURES FOR LOGICAL STANDBY IN ORACLE DATABASE 10g
Many of the issues faced by customers implementing Logical standby databases in 9i have been either completely
solved or, at the very least, improved upon considerably in Oracle Database 10g. The main issues usually are the work
that has to be done to create a logical standby database, the lack of support for certain types of data and tables, the lag
time for a Logical standby database to be caught up with the Primary database and general monitoring and
management the DBA can and has to do. This next section discusses the following subjects and how Data Guard has
improved them in Oracle Database 10g.

Zero Downtime Logical Standby Database Creation

Support for more Data Types

Real Time Apply

Flashback Database and SQL Apply
o

Eliminating the need for a Delayed Standby and re-creating the Primary after Failover
Improved and more Secure Ease of Use
ZERO DOWNTIME LOGICAL STANDBY CREATION
The first thing a potential logical standby customer runs into is the complexity and delicateness of creating their
logical Standby database. Not only is there a lot of up front work that has to be done, there are also lots of steps that
must be followed to the letter for SQL Apply to function correctly. In addition, to get a logical standby setup you
had to either use a current cold backup of your primary database or attempt to quiesce the production database in
order to get a consistent view of the transactions. The fact that a number of customers in spite of these drawbacks
are and have been willing to undertake this adventure is a solid testimonial to the value of the Logical Standby
technology and to the functionality of the current 9i version.
So, what will Data Guard SQL Apply in Oracle Database 10g bring to the table to make the life of the customer easier
and make the procedure of setting up their logical standby databases more bullet proof?

Zero Downtime Instantiation!
The ability to setup your logical standby without bringing down the Production database or even affecting the
progress of the users and removing the dependency on the Resource Manager if you wanted to use a hot backup of
the primary database.
How does it work?
Quite simply, in Oracle Database 10g a logical standby starts its life as a pseudo physical standby until it has reached
the point where there are no in flight transactions, and then morphs into a full logical standby.
You still have to make sure the primary database can support a logical standby database to your needs and is ready to
do so. This includes checking for unsupported tables (a lot less now), checking uniqueness of the tables and turning
on FORCE LOGGING, SUPPLEMENTAL LOGGING and, of course, ARCHIVELOG mode. If you don’t have a
password file you need to create one now as it will be required on both sides of your configuration. The following
are the general steps required to create a Logical Standby database in Oracle Database 10g.
1. Take an on-line backup of your primary database. (For that matter you can take ANY backup of your
Primary database, even last Sunday’s as long as you have the Archive Logs available to bring it up to date,
automatically!)
Paper 40144
DATABASE
2. Create a logical standby control file. SQL Apply has its own control file now. The syntax is the same as for
physical with the keyword ‘PHYSICAL’ replaced with ‘LOGICAL’. ALTER DATABASE CREATE
LOGICAL STANDBY CONTROL FILE AS ‘LOGSTNDBY.CTL’; It is as simple as that. A lot of the
manual steps in 9i are automated and hidden behind this one simple command. The dictionary build is
started automatically, the start and end SCN numbers of the build are stored in the control file and the
control file is marked as a Physical/Logical control file making the transformation to a full logical standby
that much easier later.
3. Copy the backup files, the standby control file and the initialization parameter file (if you are using SPFILES
you need to create a text one first) over to the standby system. You will notice that I did not mention copying
the archive logs. That’s because normal gap handling will fetch them automatically, they just need to be on
disk and still in the primary database’s control file archive log list.
4. Setup the minimum initialization parameters to start redo transport from the primary to the standby and redo
reception at the standby side. At a minimum this means on the primary the ‘LOG_ARCHIVE_DEST_n’
parameters and on the standby the ‘STANDBY_ARCHIVE_DEST’, DB_FILE_NAME_CONVERT,
LOG_FILE_NAME_CONVERT, FAL_SERVER, FAL_CLIENT and PARALLEL_MAX_SERVERS
parameters. You will also have to modify the CONTROLFILE parameter to point to your logical standby
control file as well as any other parameters with pathnames in them, as usual. You MUST create a password
file for the standby now otherwise redo transport will not be able to function. As usual you must also have a
listener for this standby up and running and the appropriate TNSNAMES definitions on both systems..
5. Start and mount the Standby using STARTUP MOUNT. At this point you have a running pseudo physical
standby. To start redo shipping from the primary perform a log switch on the primary and start managed
recovery on the standby with ALTER DATABASE RECOVER MANAGED STANDBY DATABASE; and wait
for it to complete. The MRP knows this is actually a logical standby by the SCN numbers stored in the
control file and will perform point in time recovery to the dictionary build end SCN and stop. If it is missing
any archive logs (gaps) that it needs to bring the standby up to this SCN it will use the FAL gap resolution
mechanism to fetch them automatically from the primary as usual. That’s why they have to be on disk and
still in the control file. If they are not you will have to bring them over yourself and do some manual
recovery of the standby first.
6. At this point you have recovered your pseudo Physical standby up to the point where the dictionary is
present and all in-flight transactions are resolved and committed. You are ready to ‘morph’ your standby into
its full Logical self! This is a single activate command, ALTER DATABASE ACTIVATE STANDBY
DATABASE; Since you setup the pathname conversion parameters above, the data and log files will be
correctly modified to their current location.
7. All that’s left to do now is to complete the transformation by resetting the database name and id using the
DBNEWID utility. This part of the procedure is the same as in 9i and includes a couple of shutdowns and
startups open resetlogs, running the DBNEWID utility, fixing the parameter file (changing dbname for
example) and of course recreating the password file. You might also want to use this point to create the
missing temporary data files too.
8. You are now running a bona fide logical standby. Redo should be shipping again from the primary so start
up the SQL Apply with ALTER DATABASE START LOGICAL STANDBY APPLY; without the ‘INITIAL’
keyword. SQL Apply knows where to start from the same SCN in the control file that the MRP used.
Of course this is just an overview of the steps required to get a logical standby up and running. As you can see there
are fewer steps, no downtime for the Primary, and it is much more bulletproof. For a complete detailed look at the
procedure, as usual, refer to the appropriate chapter of the documentation.
Paper 40144
DATABASE
SUPPORT FOR MORE DATA
The lack of support in a Logical standby database for certain data types and tables has been improved in Oracle
Database 10g, although there are still some restrictions.
For data types there is new support for the tables that contain columns with the following data types:

LONG

LONG_RAW

Multi-byte CLOB

NCLOB

BINARY_FLOAT (New in Oracle Database 10g)

BINARY_DOUBLE (New in Oracle Database 10g)
In addition to the new data types, Index Only tables are also supported but with some restrictions.

No LOB columns in the IOT

No IOT with Overflow
REAL-TIME APPLY
In the current release of Data Guard both Redo Apply and SQL Apply standbys will not process and apply redo that
is sent from the Primary database until a log switch has been executed at the Primary database. This has no impact
on the level of data protection gained by having the standby since the redo is off of the primary and safely somewhere
else. However it can delay the amount of time required to perform a failover or switchover to a Physical standby or
the availability of current up to date data in a Logical standby. If desired (and configured) with Oracle Database 10g
the redo data is applied to the standby database as it is received from the primary database. This means that the data
is in the standby database before a log switch has occurred at the primary database. For a physical standby this means
that failover and switchover do not have to wait for the current redo to be applied before completing the operation.
For a Logical standby the availability of the data is much faster and queries will return data that was just committed
on the Primary with much less lag time.
The use of Real-Time apply is a configurable option that can be used at any or all of your standbys and is done using
new attributes to the existing apply engine syntax.

For SQL Apply:
o

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
For Redo Apply:
o
o
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;
Paper 40144
DATABASE
FLASHBACK DATABASE AND SQL APPLY
One of the biggest problems today after a failover is that the original primary database must be recreated as a standby
to return your configuration to its original setup. This means copying all of the datafiles from the newly failed over
Primary back to the original primary system. This can mean a lot of work and time without a standby. Of course this
assumes that the failure encountered did not actually damage the original database.
The following steps assume that the user has performed a failover and that Flashback database had been enabled on
the old primary database. Without restoring the old primary, this procedure brings the old primary back into the Data
Guard configuration as a new standby.
1. On the new primary database, find out the SCN at which the old standby database became the new primary
database, via the following query:
SELECT value FROM dba_logstdby_parameters where name =
'END_PRIMARY_SCN';
2. After the old primary site becomes available again, mount the old primary database. Flashback the old
primary to "standby became primary SCN " discovered in step 1.
3. Set the database guard on.
ALTER DATABASE GUARD ALL;
4. Open the old primary with resetlogs
ALTER DATABASE OPEN RESETLOGS;
5. Restart SQL apply by pointing it to the new primary database
ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY <dblink>;
6. On the new primary enable log transport to the old primary (new standby).
In this manner only the SQL Apply dictionary of the new Primary needs to be retrieved (automatically!) and removes
the requirement of copying all of the data files across the network.
An additional use for Flashback Database and SQL Apply is that a delay on the standby would not be necessary if
Flashback was enabled on the standby. In the event that some human error occurred on the primary the standby
could be ‘flashed back’ to before the error and then a failover performed reducing downtime to recover from the
error and allow the Logical Standby to be used with Real-Time apply providing queries and reports access to up-todate data.
SECURE SWITCHOVER
The act of switching roles between a Primary database and either a Physical or Logical standby database is pretty
much the same today for the DBA but the work that goes on behind the scenes is quite different.
With a Physical standby the users have to be logged off the database and the final bit of redo is sent over to the
standby notifying it that a switchover has been started. Once received and applied at the Physical standby the MRP
(apply engine) stops and the standby is ready to become a Primary database.
A Logical standby database must do much more work since the current Primary is not yet a ‘Logical’ standby database
and has no real knowledge of what the current Logical standby looks like. A new dictionary build must be performed
on the new Primary and that redo sent to the old Primary, now the new Logical standby. Until the redo containing
the new dictionary is received at the new Logical standby, it cannot apply the redo coming in from what is now the
Primary database. This leave a very small window in which some redo might be sent to the standby that cannot be
recovered in the event that the new Primary fails. This is a very small window generally but a window just the same.
Data Guard in Oracle Database 10g provides a new PREPARE command that closes this window completely. Now a
switchover will be performed as follows:
Paper 40144
DATABASE
On the current Primary you first perform the prepare command.
ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY
This informs the primary that it will become a logical standby and can start receiving redo from the current logical
standby. Once done the second Prepare command is executed on the logical standby that is to become the Primary
database. This tells the standby to start the dictionary build and ship the redo to the current primary in preparation
for the switchover.
ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY
When this command completes and you are returned to the SQL prompt the dictionary is built and safely sent to the
current Primary database. Now you can proceed with the normal switch over to complete the operation.
On the current Primary database:
ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY
On the Logical standby database:
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY
And the process is complete. Finally start the SQL Apply engine on the new Logical standby with
ALTER DATABASE START LOGICAL STANDBY APPLY
And the dictionary will be processed and all new redo applied correctly.
It should be noted that if there is a physical standby in the configuration the switchover should be performed
between the Primary and the Physical standby since the Logical standby will not know the difference between the two
and continue to operate normally. If the switchover is done between the Primary and the Logical standby the
Physical standby becomes a cascaded standby form the new Logical standby database and not a Physical standby of
the new Primary.
Paper 40144
DATABASE
MONITORING THE LOGICAL STANDBY DATABASE
Setting up a Logical standby requires knowledge of what tables will not be supported at the standby side. In the
current version of Data Guard the DBA_LOGSTDBY_UNSUPPORTED view did not always explain exactly what was
wrong with a certain table. For example, a table that is an Index Only Table would show up as unsupported but upon
examining the columns in the table you would not see any unsupported data types. A new column, called
ATTRIBUTES, has been added to the view to fully explain what is wrong with the table. In this manner you will see
immediately that an unsupported tables has table compression or uses an unsupported IOT without having to look at
the columns.
SQL> SELECT DISTINCT table_name, attributes
2> FROM dba_logstdby_unsupported
3> WHERE owner = 'HR';
TABLE_NAME
ATTRIBUTES
------------ --------------------COUNTRIES
Index Organized Table
DEPARTMENTS Table Compression
EMPLOYEES
Table Compression
JOBS
Table Compression
JOB_HISTORY Table Compression
LOCATIONS
Table Compression
REGIONS
Table Compression
7 rows selected.
Another important function that a DBA performs on a regular basis is monitoring the progress of the SQL Apply
engine through the archive logs and transactions. This is important to ensure that the Logical standby is keeping up
to date and has not run into something that must be manually resolved, a new data file on the Primary for example.
The DBA_LOGSTDBY_LOG view has been updated to show which archive logs have been completely applied and can
be safely deleted if necessary.
SQL> SELECT thread#, sequence#, applied FROM
2> dba_logstdby_log order by sequence#;
THREAD# SEQUENCE# APPLIED
---------- ---------- ------1
48 YES
1
49 CURRENT
1
50 CURRENT
1
51 CURRENT
1
52 CURRENT
1
53 CURRENT
6 rows selected.
The DBA_LOGSTDBY_PROGESSS view has also been updated to include more information on the current progress of
SQL Apply through the redo stream.
Using the new columns in DBA_LOGSTDBY_PROGRESS you can see more details on the progress of the SQL apply
service in your standby database. All columns are the NUMBER data type.






APPLIED_SEQUENCE# Sequence number for a log containing the APPLIED_SCN.
APPLIED_THREAD# Thread number for a log containing the APPLIED_SCN.
READ_SEQUENCE# Sequence number for a log containing the READ_SCN .
READ_THREAD# Thread number for a log containing the READ_SCN.
NEWEST_SEQUENCE# Sequence number for a log containing the NEWEST_SCN.
NEWEST_THREAD# Thread number for a log containing the NEWEST_SCN.
SQL> SELECT applied_scn, applied_thread#, newest_scn,
Paper 40144
DATABASE
2> newest_thread#
3> FROM dba_logstdby_progress;
APPLIED_SCN APPLIED_THREAD# NEWEST_SCN NEWEST_THREAD#
----------- --------------- ---------- -------------961263
1
961263
1
When using REAL TIME APPLY, the apply values may be greater the newest. This is expected and normal behavior.
MANAGING SQL APPLY
Finally managing your Logical standby database, though necessary, does not have to be complex, whether it is
deciding on what tables in the Logical Standby database will be maintained, bypassing the standby guard to add other
objects (new tables or indexes on current tables), or restarting the apply engine after a failed transaction. The latter
two have been transformed from running a package to simple to use SQL commands.
Previously the wildcard features in SKIP procedure did not allow for some tables to be skipped without skipping
other tables. For instance if you attempt to skip a table called MI_DATA you would also skip MINDATA. Now with
these additional options you will be able to better control what is skipped.
DBMS_LOGSTDBY.SKIP(stmt,schema_name,table_name,proc_name,use_like,esc);

use_like – should a wildcard pattern match be performed. Default is true. Set to False to use the escape
character.

esc – specifies what escape character is being used in the pattern matching.
Bypassing the Standby guard (the security that prevents users from changing the standby database or, at least, the
objects maintained by SQL Apply) required executing a package to allow your session to perform modifications to the
Logical standby database. Now you will be able to turn the guard off and back on with a simple ALTER DATABASE
command.
SQL> ALTER SESSION DISABLE GUARD;
SQL> ALTER SESSION ENABLE GUARD;
And last, but definitely not least, restarting the SQL Apply after it has stopped due to some problem that has been
corrected, will no longer require finding out what the failed transaction’s id is and executing yet another package to
force the transaction to be skipped when SQL Apply restarts. Now this functionality is merely a few extra words on
the start command.
ALTER DATABASE START STANDBY APPLY SKIP FAILED TRANSACTION;
Be very careful when skipping transactions. Generally speaking skipping a DDL operation is fine as long as you are
able to reproduce it manually. But if you skip a DML operation you may make your Logical standby unusable.
Paper 40144
DATABASE
ROLLING UPGRADES
In Oracle Database 10g, Data Guard provides the foundation for performing rolling upgrades of the Oracle database
software from the first release of Oracle Database 10g onwards with minimal interruption of service. This will be
accomplished with the use of a Logical Standby database and switching over between the Primary database and the
Logical standby. The follow slides so the basic proposed steps for performing this RDBMS rolling upgrade.
INITIAL CONFIGURATION
As with the banks described at the beginning of this paper, the initial setup might look something like that shown in
Figure 7 below.
Figure 7 – Step 1
You configuration consists of the Production database where the users are currently attached and a Logical standby
which can be remote or local. All of these databases are running the initial version, which we will call Version X.
Paper 40144
DATABASE
STEP 1 – UPGRADE THE LOGICAL STANDBY
The first step is to stop shipping redo to the Logical standby and upgrade the Oracle software and database at the
Logical standby site to Version X+1.
Figure 8 – Step 2
The redo is stacked up waiting for the Logical standby to return. This has no impact on the performance of the
Primary database since it is a controlled action. Once the Logical standby database is upgraded, normal testing can be
performed to ensure that it functions correctly. The testing would be Read-only on the objects being maintained by
SQL Apply but could be Read-Write on any other objects.
Paper 40144
DATABASE
RUN IN A MIXED ENVIRONMENT
You can now re-enable the redo shipping from the Primary database to the Logical standby (running in Version X+1)
and the archive logs that were not sent yet will be automatically shipped to the standby and applied.
Figure 9 – Step 3
You can run in this mixed version environment for as long as necessary until you are confident that everything works
as you expect.
Paper 40144
DATABASE
SWITCH OVER TO THE LOGICAL STANDBY
When ready you can perform a switch over and move the users (and applications) from the current Primary database
to the newly upgraded Logical standby database. This requires a short period where the users cannot update either
database.
Figure 10 – Step 4
At this point transaction will be running on the new Primary database, which is running in Version X+1. The original
primary database is now a Logical standby. However, since you are not shipping the redo to the original database you
may want to create a second Physical standby database from the new Primary for security. This can be done even
before the switchover occurs.
Paper 40144
DATABASE
UPGRADE ORIGINAL PRIMARY AND PHYSICAL STANDBY
With the users and transaction executing on the new Primary you can now upgrade the original Primary, which is now
a Logical standby.
Figure 11 – Step 5
This is done by shutting down the database and upgrading the Oracle software. Once that is complete you would
perform the upgrade of the original Primary database (on Node One).
Paper 40144
DATABASE
RESYNCHRONIZE THE ORIGINAL PRIMARY
Now you can re-enable the destination on the new Primary and all of the redo that has been created since the
switchover will be sent to the Logical standby (on Node One) and applied, bringing it up to date with the Primary.
Figure 12 – Step 6
Paper 40144
DATABASE
SWITCH BACK TO ORIGINAL CONFIGURATION
Now all that is left to do to return to your original configuration is to perform another switch over from the Primary
(on Node Two) to the Logical standby (on Node One).
Figure 13 – Step 7
At this point all of the databases have been upgraded to Version X+1 with minimal interruption of service.
SUMMARY
SQL Apply technology boosts the flexibility of the data protection and usage of Data Guard through the support of
Logical standby databases. With logical standby databases, you can have the database available for reporting and be
applying the logs to the standby at the same time, allowing the logical standby database to be used for other business
activities while still maintaining a high level of Disaster protection by combining logical standby databases with
physical standby databases.
Data Guard in Oracle Database 10g extends the functionality of SQL Apply to enable Logical standby databases to
serve a wider range of applications.
Paper 40144