Beruflich Dokumente
Kultur Dokumente
Flashback Archive Data Guard Streams Online Maintenance Data Recovery Advisor
Current approaches to manage historical data are inefficient and often ineffective
Database level
Enabled using Triggers Significant performance and maintenance overhead
External or Third-party
Mine redo logs History stored in separate database Cannot seamlessly query OLTP and history data
Alerts generated when flashback data archive is 90% full Automatically purges historical data after expiration of specified retention period
supports ad-hoc purge by administrators (privileged operation
Summary
Managing historical data should no longer be a onerous task Flashback Data Archive provides a secure, efficient, easy to use and applicant transparent solution
Easy to implement Centralized, Integrated and query-able Highly storage and performance efficient Automatic, Policy-based management
Data Guard
Snapshot Standby
Leverage Standby Database for Testing
Updates
Queries Updates
Primary Database
Preserves zero data loss, although no real time query or fast failover Truly leverages DR hardware for multiple purposes Similar to storage snapshots, but provides DR at the same time anduses single copy of storage
Snapshot Standby
Easier than manual steps in 10.2
10.2
Standby
>
>
Standby
Primary >
Compare versions of blocks on the standby with that in the incoming redo stream Version discrepancy implies lost writes Can use the standby to failover and restore data consistency
FastStartFailoverLagLimit Immediate fast-start failover for user-configurable health conditions ENABLE FAST_START FAILOVER [CONDITION <value>];
Condition examples: Datafile Offline Corrupted Controlfile Corrupted Dictionary Inaccessible Logfile Stuck Archiver Any explicit ORA-xyz error
Upgrade
Physical
No need for separate logical standby for upgrade Also possible in 10.2 (more manual steps)
Leverage your physical standbys!
Streams
Streams Overview
Source Database Target Database
Propagate
Redo Logs
Capture
Apply1 Apply2
All sites active and updateable Automatic conflict detection & optional resolution Non-Oracle Supports data transformations Database Flexible configurations n-way, hub & spoke, Database platform / release / schema structure can differ Provides HA for applications where update conflicts can be avoided or managed
Transparent Gateway
Recheck
In-flight data Rows that are different
Converge feature
Identify truth database (local or remote) for row diffs DBMS_COMPARISON
Synchronous Capture
Available in all editions of Oracle Database 11g Efficient internal mechanism to immediately capture change Changes captured as part of the user transaction
DML only LCRs enqueued persistently to disk
When to use:
Replicate a few low activity tables of highly active source database Capture from redo logs cannot be implemented
DBMS_CAPTURE_ADM.CREATE_SYNC_CAPTURE
Auto-discovery of streams topology on multiple databases Automatic performance analysis across all databases Per-Stream Analysis:
Time-based analysis of each component (waits, CPU, etc.) using ASH
Bottleneck components
Top wait events of bottleneck
Change Apply
Per-Component Analysis:
Throughput and latency Aborted or Enabled
Integrated with ADDM Stream errors are integrated with Server-generated Alerts
Solution
Split the queue between live and down destinations Merge queues after recovery
Maintains high performance for all replicas Automated, fast catch-up for unavailable replica
Propagation A
Destination Database B
Dequeue LCRs
Queue
Propagation B
Queue
Apply Process
Destination Database C
Dequeue Apply LCRs Process Queue Propagation C
Source Database
CLONED Propagation A
Queue
X
Dequeue LCRs
Destination Database A
Queue
Apply Process
Destination Database B
Dequeue LCRs
Queue
Apply Process
Destination Database C
Apply Dequeue Process LCRs
Queue
Propagation C
Source Database
CLONED Propagation A
Destination Database A
Dequeue LCRs
Queue
Enqueue LCRs
Queue
Apply Process
Destination Database B
Dequeue LCRs
Queue
Apply Process
Destination Database C
Apply Dequeue Process LCRs
Queue
Propagation C
Destination Database A
Dequeue LCRs
Queue
Propagation A
Destination Database B
Dequeue LCRs
Queue
Propagation B
Queue
Apply Process
Destination Database C
Apply Dequeue Process LCRs
Queue
Propagation C
Streams performance
Improved Manageability
Scheduler support Performance views
Flashback Transaction
Flashback Transaction
Automatically finds and backs out a transaction and all its dependent transactions
Utilizes undo, archived redo logs, supplemental logging
Finalize changes with commit, or roll back
Recovery
However, problem diagnosis and choosing the right solution can be error prone and time consuming
Errors more likely during emergencies
Time to Repair
RMAN Enhancements
Better performance
Intra-file parallel backup and restore of single data files (multi-section backup) Faster backup compression (ZLIB, ~40% faster)
Better security
Virtual private catalog allows a consolidation of RMAN repositories and maintains a separation of responsibilities.
Ultra-Safe Mode
The DB_ULTRA_SAFE parameter provides an easy way to turn on the safest mode. It affects the default values of the following parameters
DB_BLOCK_CHECKING, which initiates checking of database blocks. This check can often prevent memory and data corruption. DB_BLOCK_CHECKSUM, which initiates the calculation and storage of a checksum in the cache header of every data block when writing it to disk. Checksums assist in detecting corruption caused by underlying disks, storage systems or I/O systems. DB_LOST_WRITE_PROTECT, which initiates checking for "lost writes". Data block lost writes occur on a physical standby database, when the I/O subsystem signals the completion of a block write, which has not yet been completely written in persistent storage. Of course, the write operation has been completed on the primary database.
Q&A
High Availability
Flashback Archive Data Guard Streams Online Maintenance Data Recovery Advisor