Data Guard SQL Apply Back to the Future! Larry M. Carpenter Senior Principal Consultant Server Technologies Oracle Corporation Session id: 40144

A Quick Review  What’s in the Oracle Data Guard ‘Stack’?  A High Level Overview – Redo Apply – SQL Apply  How does SQL Apply do it today?  A Couple of Customer Case Studies – How they use Oracle Data Guard Today. – What Business Problems they solved. – What can we do to make it better?

At the Highest Level  Data Guard comprises of two parts – REDO APPLY  Maintains a physical, block for block copy of the Production (also called Primary) database. – SQL APPLY  Maintains a logical, transaction for transaction copy of the Production database.

REDO Apply Architecture Maintains a ‘Physical’ block for block copy of the Primary Database Physical Standby Database Asynchronous/ Synchronous Redo Shipping Primary Database Network Backup Redo Apply MRP

SQL Apply Architecture Logical Standby Database Continuously Open for Reports SQL Apply Transform Redo to SQL Additional Indexes and Materialized Views Asynchronous/ Synchronous Redo Shipping Network Primary Database Maintains a ‘Logical’ transactional copy of the Primary Database

SQL Apply Engine Architecture Logical Standby Database Remote Archived Logs Mining Group Applying Group SQL LSP PX RFS PX Log Transport Services Redo

Customer Case Studies  How are customers using SQL Apply today? – A look at two European Banks and their setup – What Problems were they able to solve?  What are we doing to make life easier and better? – For the Business – For the User – For the DBA!

Bank #1 –Web Site  Users access only the standby outside the firewall.  Web Developers access only the Production DB.  Physical Standby provides extra Disaster Recovery FireWall Logical Standby Physical Standby Production Database Web Developers Internet Users Logical Standby FireWall

Bank #1 – Online Banking  Users access the Production DB outside the firewall.  Query Users access only the Logical Standby  Physical Standby outside firewall provides Disaster Recovery FireWall Production Database Physical Standby Logical Standby Reporting and Query Users Internet Users

Bank #2 – Branch Banking  Branch Users access the Production DB.  Query Users access only the Logical Standby  Physical Standby Disaster Recovery  Production Database and Logical standby on the same server Production Database Physical Standby Logical Standby Reporting and Query Users Branch Users

Oracle Database 10 g Solving Those Problems!  Zero Downtime Logical Standby Database Creation – Faster, Easier, Bulletproof  Support for more Data Types – Wider range of applications and functionality supported by SQL Apply  Real Time Apply  Integration with Flash Back Database  Improved Ease of Use  Rolling Database Upgrades – Going Forward

Zero Downtime Instantiation  Logical standby databases easy to create – Using an On-line backup! – No shut down and no quiesce of the Primary – No shutdown = no downtime of production system – No quiesce = no wait on quiesce  And no dependence on Resource Manager

Zero Down Time Instantiation On-Line Backup Primary Database Physical/Logical Standby Database Create and Copy Logical Standby Control File Transport Service Restore

Zero Down Time Instantiation RecoveryActivation Change DBNAME and DBID Logical Standby Database! Start SQL Apply Services

Support for more Data Primary database Logical standby database Index Organized Tables More datatypes

Data Types  New Support for: – LONG – LONG_RAW – Multi-byte CLOB – NCLOB – BINARY_FLOAT (New in Oracle Database 10 g ) – BINARY_DOUBLE (New in Oracle Database 10 g )

Index Only Tables  IOT Support in a Logical standby database – No LOB columns in the IOT – No IOT with Overflow

Real Time Apply  Redo data is applied to the standby database as it is received from the primary database. – Apply services on the standby do not wait until the current standby redo log file is archived.  Invoked through SQL: – For SQL Apply:  ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; – For Redo Apply:  ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

An up-to-date Logical or Physical Standby Database Standby Redo Logs Real Time Apply Archived Redo Logs Archived Redo Logs Primary Database Transactions Online Redo Logs Oracle Net Real Time Apply! RFSLGWR ARCH LSP MRP

Existing Site Recovery Tradeoffs  Log apply may be delayed to protect from user errors but: – Switchover/Failover gets delayed – Reports run on old data  After failing over to standby, production DB must be rebuilt Primary DatabaseStandby Database Redo Shipment Delayed Apply Reporting on delayed data

Flashback Database  A new strategy for point in time recovery  Eliminate the need to restore a whole database backup  Integrated seamlessly with RMAN – Think of it as a continuous backup – Restores just changed blocks  It’s fast - recover in minutes, not hours  It’s easy - single command restore RMAN> FLASHBACK DATABASE TIMESTAMP to_timestamp (' :00:00', 'YYYY-MM-DD HH24:MI:SS');

Enhanced DR with Flashback Database  Flashback DB removes the need to delay application of logs  Flashback DB removes the need to reinstantiate primary after failover  Real-time apply enables real-time reporting on standby Real Time Apply No Delay!Real Time Reporting Flashback Log Flashback Log Primary: No reinstantiation after failover! Redo Shipment Primary DatabaseStandby Database

Ease of Use  New and Improved Data Guard Manager!  Monitoring SQL Apply – Unsupported Storage Attributes – Applied Logs and Apply Progress  Managing the Logical Standby – Bypassing the Guard – Skipping Table Redo – Skipping Failed (and subsequently fixed) Transactions

Enterprise Manager New Features  Streamlined browser-based interface that enables complete standby database lifecycle management  Focus on: – Ease of use – Management based on best practices – Pre-built integration with other HA features

Viewing Unsupported Objects 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.

Checking for Applied Logs SQL> SELECT thread#, sequence#, applied FROM 2> dba_logstdby_log order by sequence#; THREAD# SEQUENCE# APPLIED YES 1 49 CURRENT 1 50 CURRENT 1 51 CURRENT 1 52 CURRENT 1 53 CURRENT 6 rows selected.

Viewing the Progress of SQL Apply SQL> SELECT applied_scn, applied_thread#, newest_scn, 2> newest_thread# 3> FROM dba_logstdby_progress; APPLIED_SCN APPLIED_THREAD# NEWEST_SCN NEWEST_THREAD#

New Guard Bypass Syntax SQL> ALTER SESSION ENABLE GUARD; SQL> ALTER SESSION DISABLE GUARD;

Using Wildcards to Skip Tables DBMS_LOGSTDBY.SKIP(stmt, schema_name, table_name, proc_name, use_like, esc);  In Oracle9 i Database all names are wildcard matched. – TEST_T% for table_name skips all tables starting with TEST and with anything in the place of the ‘_’.  No way to indicate that you only wanted table TEST_TABLE and not TEST1TABLE.  Set use_like to False to use the escape character.  Set esc to a \ for example to allow better matching – Now TEST\_T% will only skip TEST_TABLE.

Automatically Skipping the Last Failed Transaction ALTER DATABASE START STANDBY APPLY SKIP FAILED TRANSACTION; Logical Standby Database Redo from primary Restart SQL Apply Skip Failed transaction

Remember Those Banks?  Logical Standby Creation simple, fast and online!  Logical standbys no longer have to lag an archive log behind the Primary!  More Data types = More Applications!  Better View of the Logical Standby Status!  Easier to Manage!

Rolling Database Upgrades  In Oracle Database 10 g, SQL Apply provides the starting point for performing rolling upgrades of the Oracle RDBMS software and database with minimal interruption of service.  By utilizing a Logical standby database customers can upgrade one database while running on the original production database and then run in a mixed version environment before returning to the original, but upgraded, configuration!

Those Banks (Again)? Production Database Version X Logical Standby Version X  Initial Data Guard Setup with all databases at Version X  Applications running on Node One, the Production Database.  Reporting and Query Applications running on the Logical standby Node OneNode Two

Upgrade the Logical Standby Production Database Version X Logical Standby Version X+1  Stop Redo shipping to the Logical Standby on Node Two.  Archive logs stack up on Node One.  Upgrade Logical Standby  Test General reporting and queries on the upgraded logical standby  Applications still running on Node One, the Production Database. Node OneNode Two

Run In Mixed Environment Production Database Version X Logical Standby Version X+1  Re-enable Redo Shipping to the Logical Standby on Node Two  Stacked Archive logs automatically sent to resynchronize the Logical Standby (Bring it up to date)  Applications still running on Node One, the Production Database.  Reporting and Query Applications running on upgraded Logical standby Node OneNode Two

Switch Over Applications Logical Standby Version X Production Database Version X+1  Switch over databases from Node One to Node Two.  Original Production Database is now a Logical Standby.  Redo Shipping to Node One is stopped.  Archive logs stack up on Node Two.  Applications running on Node Two, the Upgraded Production Database. Node OneNode Two

Upgrade Node One Logical Standby Version X+1 Production Database Version X+1  Upgrade the Logical Standby database on Node One.  Applications still running on Node Two, the Upgraded Production Database. Node OneNode Two

Re-Enable Redo Shipping Logical Standby Version X+1 Production Database Version X+1  Re-enable Redo Shipping to the Logical Standby on Node One  Stacked Archive logs automatically sent to resynchronize the Logical Standby (Bring it up to date)  Applications still running on Node Two, the Production Database.  Reporting and Query Applications running on upgraded Logical standby Node OneNode Two

Switch Back to Original Setup Production Database Version X+1 Logical Standby Version X+1  Initial Data Guard Setup with all databases at Version X+1  Applications running on Node One, the Production Database.  Reporting and Query Applications running on the Logical standby Node OneNode Two

SQL Apply and Oracle Database 10g  Improving upon a great foundation! – Creating Logical Standby databases is a snap! – Querying up-to-date data with Real-Time Apply! – Supporting more and more Applications! – Moving forward to Rolling Upgrades!

Resources  Maximum Availability Architecture white papers: – New SQL Apply Best Practices Paper now available!  HA Portal on OTN:  Data Guard home page on OTN:  Oracle Consulting Services:

Next Steps High Availability Sessions from Oracle 11:00 AM How Oracle Database 10g Revolutionizes Availability and Enables the Grid 3:30 PM Oracle Recovery Manager (RMAN) 10g: Reloaded 5:00 PM Proven Techniques for Maximizing Availability 8:30 AM Oracle Database 10g - RMAN and ATA Storage in Action 11:00 AM Oracle Data Guard: Maximum Data Protection at Minimum Cost 1:00 PM Oracle Database 10g Time Navigation: Human-Error Correction 4:30 PM Data Guard SQL Apply: Back to the Future Wednesday in Moscone Room 304Tuesday in Moscone Room 304 For More Info On Oracle HA Go To

Next Steps High Availability Sessions from Oracle 8:30 AM in Moscone Room 304 Oracle Database 10g Data Warehouse Backup and Recovery: Automatic, Simple, Reliable 8:30 AM in Moscone Room 104 Building RAC Clusters over InfiniBand Thursday For More Info On Oracle HA Go To Real Application Clusters Data Guard Database Backup & Recovery Flashback Recovery LogMiner, Online Redefinition, and Cross Platform Transportable Tablespaces Database HA Demos All Four Days In The Oracle Demo Campground

Reminder – please complete the OracleWorld online session survey Thank you.

A Q & Q U E S T I O N S A N S W E R S