O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
A Scribd passará a dirigir o SlideShare em 1 de dezembro de 2020A partir desta data, a Scribd passará a gerenciar sua conta do SlideShare e qualquer conteúdo que você possa ter na plataforma. Além disso, serão aplicados os Termos gerais de uso e a Política de Privacidade da Scribd. Se prefira sair da plataforma, por favor, encerre sua conta do SlideShare. Saiba mais.
Oracle Data Guard Presented by Satishbabu Gunukula12+ Years of Experience in Oracle, SQLServer DatabaseTechnologiesOracle Certified Professional Oracle 8i,9i,10gOracle Certified Expert Oracle 10g RAC http://www.oracleracexpert.com
Agenda Data Guard and its benefits? Data Guard Architecture Types of Data guards and Benefits Advantages with different types of Data guards Processes and Services Data Guard Protection Modes Data Guard Role Transitions Data Guard Broker Architecture Data Guard features across versions Data Guard Setup
Why undertake Disaster Recovery? Disaster can strike at any time Unprepared organizations can loose all the critical data. Even prepared companies can suffer financial loss during system down time. Disasters can be natural calamities or man-made problems
Origin … Impact of Disasters Customers across the globe will be effected High Availability Challenges Down time -- unplanned or planned Setup and Maintenance cost. Identifying the Disaster Recovery Site (DR Site)
Why Data Guard ? Prior to Data Guard: Standby database What is Standby database? A standby database is a database replica created from a backup of a primary database. By applying archived redo logs from the primary database to the standby database, you can keep the two databases synchronized Used for : Disaster protection Protection against data corruption Supplemental reporting Data guard is one of the most effective solutions available today in terms of High Availability. Why?
Before Data guard… Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle databases to survive disasters and data corruptions.”
Pre-requisites: Same Oracle Enterprise Edition must be installed. primary database must run in ARCHIVELOG mode. Hardware and Operating System architecture must be same. Primary and Standby must have its own control file Can be configured on the same or different systems. Turn on FORCE LOGGING at the primary. SYSDBA privileges to user accounts.
Data Guard Benefits Disaster recovery, data protection, and high availability Complete data protection Efficient use of system resources Flexibility in data protection to balance availability against performance requirements Automatic gap detection and resolution Centralized and simple management Integration with Oracle Database (no separate installation) Automatic role transitions
Processes Involved in the Architecture Below are the main processes in DG configuration: 1) Logwriter (LGWr) Process 2) Archiver (ARCH) Process 3) Logwriter Network Server (LNS) 4) Fetch Archive Logs (FAL) for Client –Server mechanism 5) Remote File Server (RFS) 6) Managed Recovery Process (MRP) for Physical standby 7) Logical Standby Process (LSP) for Logical Standby If Data Guard Broker is enabled : 8) Data Guard Broker Monitor (DMON) process
Redo log Data flow Flow of Redo Data from Primary to Standby Database
Apply Services At High Level Data Guard comprises of two parts Redo Apply – For physical standby SQL Apply - for logical standby The Physical and logical standby databases utilize the same redo transport and role management services, only apply process is different. Either can be used to offload query and reporting from the primary database. Either can be used to execute a rolling database upgrade All standby databases are first created as physical standby databases during the standby database instantiation process. Several additional steps are required to convert a physical standby database to a logical standby database.
Redo Apply A physical standby database applies redo data received from the primary using Oracle media recovery. The Redo Apply uses a specialized process, called the Managed Recovery Process. As the RFS process is writing redo data to Standby Redo Logs (SRLs), MRP reads the redo data and applies it to the physical standby database. MRP is started on the physical standby database by mounting the database and using the following command: SQL> alter database recover managed standby database using current logfile disconnect from session;
Redo Apply MRP may also transparently switch to reading from a standby archived log if the SRL is archived before MRP can complete reading of the.
SQL Apply SQL Apply uses a collection of background processes that perform the task of applying changes from the primary database to the logical standby database.
Types of Dataguards: Physical Standby Physical standby Provides a physically identical copy of the primary database, Identical to the primary database on a block-for-block basis. The database schema, including indexes, are the same. Synchronized with the primary database, through Redo Apply.
Data guard :Physical Standby Benefits Benefits: Disaster recovery and high availability Enables a robust and efficient disaster recovery and high availability solution Data protection Ensures no data loss, even in the face of unforeseen disasters. Supports all data types, and all DDL and DML operations Reduction in primary database workload Oracle Recovery Manager (RMAN) can use to off-load backups from the primary database saving valuable CPU and I/O cycles. Performance The Redo Apply technology applies changes using low-level recovery mechanisms and is most efficient method for applying high volumes of redo.
Types of Dataguard :Logical Standby Logical standby Contains same logical information physical organization and structure of the data can be different Synchronized with the primary database, through SQL Apply Can be used for queries and reporting at any time.
Logical Standby benefits Benefits: Along with disaster recovery, high availability, and data protection; Efficient use of standby hardware resources Additional indexes and materialized views can be created to improve query performance and suit specific business requirements. Reduction in primary database workload
Services Involved: •Log Transport Services Transmit redo data from the primary system to the standby systems in the configuration Enforce the database protection modes •Log Apply Services Automatically apply archived redo logs on the standby database Maintains transactional synchronization with the primary database Allows transitionally consistent read-only access to the data. Redo Apply for Physical standby. SQL Apply for Logical stand by. •Role Management Services An Oracle database operates in one of two roles: primary or standby Achieved by Switch over and Fail over operations.
Protection Modes There are Three protection modes Maximum Availability Maximize Protection Maximize Performance There are 3 ways of shipping redo data to a physical standby: LGWR SYNC LGWR ASYNC ARCH
Maximum Protection Mode This mode ensures that zero data loss occurs if a primary fails. The default is Maximum Performance. In case if standby unavailable then processing stops at primary. This the highest level of protection Maximum protection configuration - LGWR SYNC, SRLs SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;
Maximum Availability Mode This mode provides highest level of data protection with out compromising the availability of primary database If last standby is unavailable, processing continues at primary. As long as network stys up - Zero Data Loss Maximum availability configuration - LGWR SYNC, do not need SRLs SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY
Maximum Performance Mode This mode provides the highest level of data protection that is possible without affection the performance of a primary database Highest level of performance This mode has least impact on system and protects from failure of any single component Maximum performance configuration - LGWR ASYNC, or ARCH SQL> ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;
Role Transitions: A database operates in one of the following mutually exclusive roles: primary or standby. Data Guard enables you to change these roles dynamically by issuing the SQL statements , or by using either of the Data Guard brokers interfaces. Oracle Data Guard supports the following role transitions: Switch over Failover
Switchover Allows the primary database to switch roles with one of its standby databases. There is no data loss during a switchover. After a switchover, each database continues to participate in the Data Guard configuration with its new role.
Failover A failover is typically used only when the primary database becomes unavailable, and there is no possibility of restoring it to service within a reasonable period of time. The specific actions performed during a failover vary based on whether a logical or a physical standby database is involved in the failover, the state of the Data Guard configuration at the time of the failover, and on the specific SQL statements used to initiate the failover
Data guard Broker: The Data Guard broker is a distributed management framework that automates and centralizes the creation, maintenance, and monitoring of Data Guard configurations Can be administered either from Oracle Enterprise Manager or Broker’s CLI (DGMGRL) List of operations that Broker automates : Creating and Enabling DG configurations – both Primary and Physical/Logical Managing DG configuration from any site. Implementing Switchover and Failover operations
Some Data Guard Featuresacross versions 9i,10g and11g
DG features in Oracle 9.1: 9i : (9.1) Oracle 8i Standby renamed as Oracle 9i Data Guard Oracle9i Data Guard broker No data loss Database Switch over Archive gaps automatically detected Background managed recovery mode. Standby redo logs.
Enhancements in 9.2: 9i : (9.2) Logical Standby Database Data protection modes (Max Protection/Availability/Performance) Cascading Redo Log Destinations Data Guard Broker Supports up to 9 Physical and Logical Standby databases For Failover and Switchover operations New Key words for REMOTE_ARCHIVE_ENABLE (Send/Receive)
Data guard Enhancements in 10g : Fast –start Failover Logical standby LGWR ASYNC Redo Transport Enhancement Real Time Apply Rolling Upgrade
Dataguard Enhancements in 11g : Improved Data Protection High Availability Manageability Increased ROI
Improved Data Protection Faster redo transport Advanced Compression log_archive_dest= ‘service=dbname ASYNC COMPRESSION= ENABLE’ Redo Compression edit the broker property Redo Compression=Enable Lost–Write Protection
Higher Availability: Faster Redo apply and SQL apply Faster failover and switch over Enhanced Fast -start failover Transient logical standby NEW GC HA console
Active Data guard Offload readonly queries to physical standby Offload increamental backups to physical standby
Rolling Database Upgrades The Rolling upgrade process involves upgrading the logical standby database to the next release The patch set upgrade can be performed with near zero database downtime.
Setup Overview : Step 1: Prepare the Primary for Standby Step 2: Configure Primary parameters Step 3: Configure Primary listener and tnsnames Step 4: Copy the necessary files and create Standby controlfile Step 5: Configure the Standby Parameters Step 6: Configure Standby listener and tnsnames Step 7: Startup the Standby Site and Apply redo
Primary Database Req for DataGuard FORCE LOGGING must be enabled: SQL> Select name, database_role from v$database; SQL> select force_logging from v$database; SQL> alter database force logging; Database must be in ARCHIVELOG mode and automatic archiving must be enabled: SQL> archive log list
Create Standby Controlfile Shutdown the Primary database and copy the necessary files to standby site SQL> STATUP MOUNT SQL>ALTER DATABASE CREATE STANDBY CONTROLFILE AS /oradata/orclDB/stdby01.ctl; Copy the standby control file to standby site
Mount Standby Database and Apply redo Keep the database in Standby mode SQL>STARTUP MOUNT; Start Redo Apply SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; The DISCONNECT FROM SESSION option used to run background session to apply Redo