* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Data Guard SQL Apply - Oracle Software Downloads
Survey
Document related concepts
Global serializability wikipedia , lookup
Commitment ordering wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Serializability wikipedia , lookup
Microsoft Access wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Ingres (database) wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Oracle Database wikipedia , lookup
Functional Database Model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Relational model wikipedia , lookup
Clusterpoint wikipedia , lookup
Transcript
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