* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Paper 40144 - Southern Utah University | Cedar City, UT
Tandem Computers wikipedia , lookup
Commitment ordering wikipedia , lookup
Serializability wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Access wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Ingres (database) wikipedia , lookup
Functional Database Model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Concurrency control wikipedia , lookup
Oracle Database wikipedia , lookup
Relational model wikipedia , lookup
Clusterpoint wikipedia , lookup
Session id: 40144 Data Guard SQL Apply Back to the Future! Larry M. Carpenter Senior Principal Consultant Server Technologies Oracle Corporation 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 Primary Database Asynchronous/ Synchronous Redo Shipping Physical Standby Database MRP Redo Apply Network Backup DIGITAL DATA STORAGE DIGITAL DATA STORAGE • Maintains a ‘Physical’ block for block copy of the Primary Database SQL Apply Architecture Primary Database Network Logical Standby Database Continuously Open for Reports Asynchronous/ Synchronous Redo Shipping SQL Apply Transform Redo to SQL Additional Indexes and Materialized Views • Maintains a ‘Logical’ transactional copy of the Primary Database SQL Apply Engine Architecture Mining Group PX PX Redo LSP Applying Group PX PX SQL RFS Log Transport Services Remote Archived Logs Logical Standby Database 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 Internet Users FireWall Logical Standby Logical Standby FireWall Users access only the standby outside the firewall. Web Developers access only the Production DB. Physical Standby provides extra Disaster Recovery Web Developers Production Database Physical Standby Bank #1 – Online Banking Internet Users Production Database Physical Standby FireWall Users access the Production DB outside the firewall. Query Users access only the Logical Standby Physical Standby outside firewall provides Disaster Recovery Reporting and Query Users Logical Standby Bank #2 – Branch Banking Branch Users Production Database 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 Logical Standby Physical Standby Reporting and Query 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 1 3 On-Line Backup 2 Primary Database Restore Create and Copy Logical Standby Control File 4 Transport Service Physical/Logical Standby Database Zero Down Time Instantiation 5 6 Recovery Activation 7 Change DBNAME and DBID 8 Start SQL Apply Services Logical Standby Database! Support for more Data Index Organized Tables Primary database Logical standby database More datatypes 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; Real Time Apply Oracle Net Transactions LGWR ARCH LSP MRP RFS Online Redo Logs Primary Database Archived Redo Logs An up-to-date Logical or Physical Standby Database Standby Redo Logs ARCH Real Time Apply! Archived Redo Logs Existing Site Recovery Tradeoffs Primary Database Standby Database Redo Shipment Delayed Apply 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 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 Primary Database Redo Shipment Real Time Apply Standby Database Real Time Reporting No Delay! Flashback Log Flashback Log Primary: No reinstantiation after failover! 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 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 -----------COUNTRIES DEPARTMENTS EMPLOYEES JOBS JOB_HISTORY LOCATIONS REGIONS ATTRIBUTES --------------------Index Organized Table Table Compression Table Compression Table Compression Table Compression Table Compression 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 New Guard Bypass Syntax SQL> ALTER SESSION DISABLE GUARD; SQL> ALTER SESSION ENABLE GUARD; 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 Logical Standby Database Redo from primary Skip Failed transaction Restart SQL Apply ALTER DATABASE START STANDBY 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 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 Database Version X Logical Standby Version X Node One Node Two 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 Upgrade the Logical Standby Production Database Version X Logical Standby Version X+1 Node One Node Two 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. Run In Mixed Environment Production Database Version X Logical Standby Version X+1 Node One Node Two 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 Switch Over Applications Logical Standby Version X Production Database Version X+1 Node One Node Two 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. Upgrade Node One Logical Standby Version X+1 Production Database Version X+1 Node One Node Two Upgrade the Logical Standby database on Node One. Applications still running on Node Two, the Upgraded Production Database. Re-Enable Redo Shipping Logical Standby Version X+1 Production Database Version X+1 Node One Node Two 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 Switch Back to Original Setup Production Database Version X+1 Logical Standby Version X+1 Node One Node Two 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 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 Steps High Availability Sessions from Oracle Tuesday in Moscone Room 304 Wednesday in Moscone Room 304 11:00 AM 8:30 AM How Oracle Database 10g Revolutionizes Availability and Enables the Grid Oracle Database 10g - RMAN and ATA Storage in Action 11:00 AM 3:30 PM Oracle Recovery Manager (RMAN) 10g: Reloaded Oracle Data Guard: Maximum Data Protection at Minimum Cost 1:00 PM 5:00 PM Proven Techniques for Maximizing Availability Oracle Database 10g Time Navigation: Human-Error Correction 4:30 PM Data Guard SQL Apply: Back to the Future For More Info On Oracle HA Go To http://otn.oracle.com/deploy/availability/ Next Steps High Availability Sessions from Oracle Thursday Database HA Demos All Four Days In The Oracle Demo Campground 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 Real Application Clusters Data Guard Database Backup & Recovery Flashback Recovery LogMiner, Online Redefinition, and Cross Platform Transportable Tablespaces For More Info On Oracle HA Go To http://otn.oracle.com/deploy/availability/ Reminder – please complete the OracleWorld online session survey Thank you. QUESTIONS ANSWERS