View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Data Guard SQL ApplyBack to the Future!
Larry M. CarpenterSenior 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 DatabaseAsynchronous/Synchronous
Redo Shipping
PrimaryDatabase
Network
DIGITAL DATA STORAGE
DIGITAL DATA STORAGE
Backup
Redo Apply
MRP
SQL Apply Architecture
Logical Standby Database
ContinuouslyOpen for Reports
SQLApply
TransformRedo to
SQLAdditional
Indexes and Materialized
Views
Asynchronous/Synchronous
Redo Shipping
NetworkNetwork
PrimaryDatabase
• Maintains a ‘Logical’ transactional copy of the Primary Database
SQL Apply Engine Architecture
Logical Standby Database
Remote Archived Logs
MiningGroup
ApplyingGroup
SQL
LSP
PX PX
RFS
PX 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 StandbyProduction 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 10g 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-LineBackup
Primary Database
Physical/Logical Standby Database
Create and Copy Logical Standby
Control File
Transport Service
Restore
1
2
3
4
Zero Down Time Instantiation
Recovery Activation
Change DBNAME and DBID
Logical Standby Database!
Start SQL Apply Services
5 6
7
8
Data Types
New Support for:– LONG– LONG_RAW– Multi-byte CLOB– NCLOB– BINARY_FLOAT (New in Oracle Database 10g)– BINARY_DOUBLE (New in Oracle Database 10g)
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
StandbyDatabase
StandbyRedo Logs
Real Time Apply
Archived Redo Logs
Archived Redo Logs
PrimaryDatabase
Transactions
Online Redo Logs
Oracle N
etReal Time
Apply!
RFSLGWR
ARCH ARCH
LSPMRP
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 Database Standby DatabaseRedo
Shipment
DelayedApply
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 ('2003-08-15 16: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 TimeReporting
Flashback Log
Flashback Log
Primary: No reinstantiation after failover!
RedoShipment
Primary Database Standby 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 TableDEPARTMENTS Table CompressionEMPLOYEES Table CompressionJOBS Table CompressionJOB_HISTORY Table CompressionLOCATIONS Table CompressionREGIONS 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---------- ---------- ------- 1 48 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#----------- --------------- ---------- -------------- 961263 1 961263 1
Using Wildcards to Skip Tables
DBMS_LOGSTDBY.SKIP(stmt, schema_name, table_name, proc_name, use_like, esc);
In Oracle9i 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 StandbyDatabase
Redo from
primary Restart SQL
ApplySkip 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 10g, 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 DatabaseVersion 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 One Node Two
Upgrade the Logical Standby
Production DatabaseVersion 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 One Node Two
Run In Mixed Environment
Production DatabaseVersion 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 One Node 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 One Node 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 One Node 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 One Node 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 One Node 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: http://otn.oracle.com/deploy/availability/htdocs/maa.html
– New SQL Apply Best Practices Paper now available!
HA Portal on OTN: http://otn.oracle.com/deploy/availability
Data Guard home page on OTN: http://otn.oracle.com/deploy/availability/htdocs/odg_overview.html
Oracle Consulting Services: http://otn.oracle.com/consulting
Next StepsHigh 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 http://otn.oracle.com/deploy/availability/
Next StepsHigh 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 http://otn.oracle.com/deploy/availability/
Real Application Clusters
Data Guard
Database Backup & Recovery
Flashback Recovery
LogMiner, Online Redefinition, and Cross Platform Transportable
Tablespaces
Database HA Demos All Four DaysIn The Oracle Demo Campground