Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Entity–attribute–value model wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Oracle Database wikipedia , lookup
Functional Database Model wikipedia , lookup
Relational model wikipedia , lookup
ContactPoint wikipedia , lookup
Agenda Data Guard Architecture & Features Data Guard Success Stories & Benefits Data Guard Architecture & Features 1. Introduction 2. concepts and architecture 3. process architecture 4. data protection mode 5. data guard implementation 6. role management 7. summary 8. Q&A Oracle High Availability Features Oracle provides the following features for high availability: - Oracle Real Application Clusters - Oracle Data Guard - Oracle Streams - Oracle Flashback Technology - Automatic Storage Management - Recovery Manager - Flash Recovery Area - Oracle Security Features - Fast-Start Fault Recovery - LogMiner - Hardware Assisted Resilient Data (HARD) Initiative Oracle High Availability Solutions for Unplanned Downtime What is Oracle Data Guard? Oracle’s disaster recovery solution for Oracle data Feature of Oracle Database Enterprise Edition Automates the creation and maintenance of one or more transactionally consistent copies (standby) of the production (or primary) database If the primary database becomes unavailable (disasters, maintenance), a standby database can be activated and assume the primary role Oracle Data Guard Focus Data Failures & Site Disasters: – – – Data Protection Data Availability Data Recovery All 3 are important! Data is the core asset of the enterprise! • Also addresses human errors & planned maintenances Data Guard Overview Clients Clients Primary Site Data Changes Data Guard Broker Standby Site Data Guard Configuration Primary Site Standby Site A Standby Site B Standby Database Primary Database Standby Database Managed as a single configuration Primary and standby databases can be Real Application Clusters or single-instance Oracle Up to nine standby databases supported in a single configuration Oracle Data Guard Architecture Physical Standby Database Sync or Async Redo Shipping Backup Production Database Redo Apply Network DIGITAL DATA STORAGE DIGITAL DATA STORAGE Broker Transform Redo to SQL Logical Standby Database SQL Apply Open for Reports Additional Indexes & MVs process architecture Archiver Processes (ARCn) By default, redo transport services use ARCn processes to archive the online redo log files on the primary database. on the LOG_ARCHIVE_DEST_n initialization parameter to control the automated transfer of redo data from the primary database to other destinations. must specify either the LOCATION attribute to archive to a local destination or the SERVICE attribute for remote archival. Log Writer Process (LGWR) can optionally enable redo transport services to use the LGWR process to transmit redo data to remote destinations. process architecture Log Writer Process (LGWR) Using the LGWR process differs from ARCn processing, because instead of waiting for the online redo log to switch at the primary database and then writing the entire archived redo log at the remote destination all at once. The transmission to the remote destination will either be synchronous or asynchronous, based on whether the SYNC or the ASYNC attribute is set on the LOG_ ARCHIVE_DEST_n parameter. The SYNC attribute performs all network I/O synchronously, in conjunction with each write operation to the online redo log file, and waits for the network I/O to complete. LGWR SYNC Archival to a Remote Destination with Standby Redo Log Files process architecture The ASYNC attribute performs all network I/O asynchronously and control is returned to the executing application or user immediately, without waiting for the network I/O to complete. If you configure a destination to use the LGWR process, but for some reason the LGWR process becomes unable to archive to the destination, then redo transport will revert to using the ARCn process to complete archival operations. LNSn process collecting redo data from the online redo log files and transmitting it over Oracle Net to the RFS process on the standby database. LGWR ASYNC Archival with Network Server (LNSn) Processes process architecture fetch archive log (FAL) uses the fetch archive log (FAL) client and server to send archived redo log files to standby destinations following a network outage, for automatic gap resolution, and resynchronization. remote file server process (RFS) On the remote destination, the remote file server process (RFS) will, in turn, write the redo data to an archived redo log file from a standby redo log file. Log apply services use Redo Apply (MRP process1) or SQL Apply (LSP process2) to apply the redo to the standby database. Data Guard Redo Apply Primary Database Data Guard Broker Physical Standby Database Redo Apply Network Redo Shipment Backup DIGITAL DATA STORAGE Standby Redo Logs Physical Standby Database is a block-for-block copy of the primary database Uses the database recovery functionality to apply changes Can be opened in read-only mode for reporting/queries Can also be used for backups, offloading production database Data Guard SQL Apply Additional Indexes & Materialized Views Primary Database Data Guard Broker Logical Standby Database Transform Redo to SQL and Apply Continuously Open for Reports Network Redo Shipment Logical Standby Database is an open, independent, active database Standby Redo Logs Contains the same logical information (rows) as the production database Physical organization and structure can be very different Can host multiple schemas Can be queried for reports while logs are being applied via SQL Can create additional indexes and materialized views for better query performance Data Type and DDL Support on a Logical Standby Database Logical standby databases support the following data types: ‧ BINARY_DOUBLE ‧BINARY_FLOAT ‧ DATE ‧ BLOB ‧CHAR ‧CLOB and NCLOB ‧ CLOB and NCLOB ‧INTERVAL YEAR TO MONTH ‧ INTERVAL YEAR TO MONTH ‧ LONG ‧ INTERVAL DAY TO SECOND ‧ LONG RAW ‧ NCHAR NUMBER ‧ NVAR ‧ CHAR2RAW ‧ TIMESTAMP ‧ TIMESTAMP WITH LOCAL TIMEZONE ‧ TIMESTAMP WITH TIMEZONE ‧ VARCHAR2 and VARCHAR Data Type and DDL Support on a Logical Standby Database Logical standby databases do not support the following data types: ‧ ROWID ‧ UROWID ‧ BFILE ‧Encrypted columns ‧ XMLType ‧ User-defined types ‧ Collections (including VARRAYS and nested tables) ‧ Multimedia data types (including Spatial, Image, and Context) Skipped SQL Statements on a Logical Standby Database By default, the following SQL statements are automatically skipped by SQL Apply: ‧ALTER DATABASE ‧ALTER MATERIALIZED VIEW ‧ALTER SESSION ‧ALTER SESSION ‧CREATE CONTROL FILE ‧CREATE DATABASE ‧ALTER SYSTEM ‧CREATE DATABASE LINK ‧LOCK TABLE ‧SET CONSTRAINTS ‧ ALTER MATERIALIZED VIEW LOG ‧ SET ROLE ‧SET TRANSACTION ‧CREATE MATERIALIZED VIEW ‧EXPLAIN ‧LOCK TABLE ‧CREATE PFILE FROM SPFILE ‧SET ROLE ‧CREATE SPFILE FROM PFILE ‧CREATE SCHEMA AUTHORIZATION ‧DROP DATABASE LINK ‧DROP MATERIALIZED VIEW ‧ DROP MATERIALIZED VIEW LOG All other SQL statements executed on the primary database are applied to the logical standby database. Protection from Human Errors and Data Corruptions Primary Site Optional Delayed Apply Standby Site Data Changes Application of changes received from the primary can be delayed at standby to allow for the detection of user errors and prevent standby to be affected Administrators may choose not to configure any delay – if both primary and standby are affected, then they can be simply flashed back [10g] The apply process also revalidates the log records to prevent application of any log corruptions Switchover and Failover Primary and Standby role transitions Switchover – – – Planned role reversal No database reinstantiation required Used for maintenance of OS or hardware Failover – – Unplanned failure (e.g. disasters) of primary Primary database must be reinstantiated / flashed back [10g] Initiated using simple SQL / GUI interface Data Guard automates the processes involved Data Guard Configuration Before Switchover Data Guard Environment After Switchover Failover to a Standby Database Flexible Data Protection Modes Protection Mode Risk of Data Loss Redo Shipment Maximum Protection Zero Data Loss Double Failure Protection Synchronous redo shipping to 2 sites Maximum Availability Zero Data Loss Single Failure Protection Synchronous redo shipping Maximum Performance Minimal data loss – usually 0 to few seconds Asynchronous redo shipping Balance cost, availability, performance, and transaction protection Minimum Requirements for Data Protection Modes LOG_ARCHIVE_DEST_n Parameter Attributes ■ AFFIRM specifies that all disk I/O to archived redo log files and standby redo log files is performed synchronously and completes successfully before the log writer process continues. ■ NOAFFIRM specifies that all disk I/O to archived redo log files and standby redo log files is performed asynchronously; the log writer process on the primary database does not wait until the disk I/O completes before continuing. Confirm the configuration is perating in the new protection mode Query the V$DATABASE view to confirm the Data Guard configuration is operating in the new protection mode. SQL> SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE; PROTECTION_MODE --------------------MAXIMUM AVAILABILITY PROTECTION_LEVEL --------------------MAXIMUM AVAILABILITY Automatic Resynchronization Network connectivity problems may occur Data Guard automatically resynchronizes standbys after network connectivity restored – Implicit ARCH process idling away on the primary ‘pings’ all standbys on a regular basis to see if they are missing any redo data If so it sends them the missing redo data – Explicit Gap discovered during apply process in physical standby Based on FAL_SERVER and FAL_CLIENT settings, primary notified, and it sends missing redo data Data Guard Broker Distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations Create and enable Data Guard configurations, including setting up redo transport services and log apply services Manage an entire Data Guard configuration from any system in the configuration Manage and monitor Data Guard configurations that contain Real Application Clusters primary or standby databases Management operations can be performed locally or remotely through easy-to-use interfaces: Use either the Oracle Enterprise Manager graphical user interface (GUI) or Data Guard Broker’s command-line interface (DGMGRL) Real Time Apply Redo data is applied to the standby database as soon as it is received from the primary database – – – If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. Enables real-time reporting, faster switchovers/failovers. If real-time apply is enabled, Data Guard recovers redo data directly from the current standby redo log file as it is being filled up by the RFS process. For Redo Apply : (physical standby databases) ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE For SQL Apply : (logical standby databases) ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE When real time apply is enabled, RECOVERY_MODE column in V$ARCHIVE_DEST_STATUS displays “MANAGED REAL TIME APPLY” Real Time Apply Architecture An up-to-date Physical/Logical Standby Database Oracle Net Transactions LGWR Online Redo Logs Primary Database MRP/ LSP RFS Standby Redo Logs ARCH Real Time Apply ARCH Archived Redo Logs Archived Redo Logs Applying Redo Data to a Standby Destination Using Real-Time Apply SQL Apply: Zero Downtime Instantiation Logical standby database can now be created from an online backup of the primary database, without shutting down or quiescing the primary database – No shutdown implies no downtime of production system – No quiesce implies no wait on quiesce and no dependence on Resource Manager SQL Apply – Rolling Database Upgrades Upgrade Redo Clients A Version X 1 B Logs Queue Version X Initial SQL Apply Config A X 2 X+1 Upgrade node B to X+1 Redo Redo Upgrade B A B X+1 X+1 4 Switchover to B, upgrade A A X 3 B X+1 Run in mixed mode to test Patch Set Upgrades Major Release Upgrades Cluster Software & Hardware Upgrades Example – Ease of Use Switchover using Enterprise Manager is now literally two mouse clicks Switched! Agenda Data Guard Architecture & Features Data Guard Success Stories & Benefits Data Guard Customers Transportation Telecom Financial/ Insurance Utilities Government Manufacturing Health Care Other Industries e-Commerce Usage Examples Chicago Dallas Primary Database Standby Database Standby Database Primary Database Maximize primary and standby resources Example A Example B Standby machine must be powerful enough to support multiple production instances after switchover / failover Primary Site A Primary Database Primary Site B Primary Database Primary Site C Primary Database Standby Database Standby Database Standby Database Standby Site Data Guard Usage Examples Primary Site Standby Site A Synchronous transport LAN attached Used to offload backups First choice for switchover candidate Standby Site B Synchronous transport LAN attached Used to offload reporting Standby Site C Example C Asynchronous transport WAN attached Delayed apply Provides DR and data protection QUESTIONS ANSWERS