Monday, May 30, 2016

DataGuard Introduction

-- Oracle Data Guard ensures the High Availability, Data Protection and Disaster Recovery for enterprise data.

-- Oracle Data Guard maintains the one or many Secondary databases(Standby databases) as alternative to the Primary (Production) database.

Primary Database:


A data guard configuration contains one production database also referred to as the primary database, that function in the primary role. This is the database that is associated by most of your applications.


Standby Databases:


Standby database is a transactionally consistent copy of the primary database. Using a backup copy of the primary database, You can create up to nine standby databases and incorporate them in a Data Guard configuration. Once created, Data Guard automatically maintains each standby database by transmitting redo data from the primary database and then applying the redo to the standby database.


-- A standby database can be either a Physical Standby database or a Logical Standby database.


Physical Standby Database:


-- For creating Physical standby database, The primary database must be in ArchiveLog Mode.



-- When new archive log file is generated at the primary side, ARCn background process will copy that archivelog file to standby database over oracle network and handovers to RFS background process resides at the standby side.

-- This RFS(Remote File System) writes the content into online redo logfile of the standby database.

-- When a logswitch occurs on Primary side, At the same time, logswitch occurs on the standby side. Because of that, A new redolog file will be generated in local archive destination of the standby database.

--Upon successful archiving, MRP(Managed Recovery Process) background process reads the archived redo logfile and applielies it on datafiles.

-- In this way, standby database will be keep on synchronized partially with the primary database.


Logical Standby Database:


-- Logical standby database is same with primary database but not physical structure wise.

-- Logical standby database can be in OPEN READ WRITE state but where as physical standby database is in MOUNT state.

-- Advantage of this Logical standby database is that Since it was an OPEN READ WRITE status, It allows general DDL,DML & DRL operations  on top of it.

-- Logical standby internally makes use of LOGMINER utility to construct sql statements from the change vectors(CV) and the constructed sql statements will be applied on logical standby database to synchronize with primary database.

-- Logical standby architechture is similar as Physical standby architechture. But, the difference is that, instead fo the MRP background process, here it uses LSP(Logical Shared Process).

-- So, that LSP internally invokes the LOGMINER.

-- LOGMINER makes the Change Vector(CV), construct sql statements.

-- Logical standby doesn't support all the datatypes which are supported by Primary database. So, For this case, we may loss of some data.

-- All  DDL operations are not supported by the Logical standby. There are few exceptions here in this case also, we loss some data.



Drawbacks of Standby Architecture:


--When Primary database goes down, as a DBA, we need to mannually convert the standby database to new primary database.

-- Since it is having periodical synchronization behaviour, there is a chance of losing the data.


-- When there is a network failure between primary and standby, more number of archive gap occures between primary and standby databases.

-- For this archived log gap, we have the query as  v$archived_gap

-- When archive gap becomes huge, then ARCn background process may stop sending the archives to the standby even after network problem is rectified also.

-- In this case, as a DBA, we used to copy mannually the archive log files from the primary to standby and we used to register mannually them at standby side and there after MRP background process reads that archive log files and applies on the appropriate data file.



Data Guard Broker:


-- Data Guard contains the "Data Guard Broker" infrastructure.

-- Data guard Broker (Observer) is a processor named as DMON. This process will keep on monitoring the primary as well as standby.

-- When primary goes down, DMON automatically wakeup (convert) standby to primary.

-- Data guard performs serial synchronization instead of periodical synchronization. Because it uses LGWR (logwriter) background process to send the redo data from primary to standby.

-- Since we are using LGWR (logwriter) background process, we require standby redo log files at the standby side.

-- Data guard automatic archive gap detection and resolution will be done by using 2 parameters. They are

                       1). FALL_SERVER

                       2). FALL_CLIENT

-- By using FALL_SERVER parameter, Standby makes a request to the primary and primary sends arcives to the standby using FALL_CLIENT parameter.

-- To enable the Data guard Broker, execute below command on both primary and standby machines.

--On Primary Server

       $ps -ef | grep dmon

       $export ORACLE_SID=prime

       $sqlplus / as sysdba

       sql>alter system set dg_broker_start=true scope=both;

       sql>!

       $ps -ef | grep dmon 


-- On Standby server

       $ps -ef | grep dmon

       $export ORACLE_SID=stand

       $sqlplus / as sysdba

       sql>alter system set dg_broker_start=true scope=both;

       sql>!

       $ps -ef | grep dmon


Availability:


-- Data Guard will protect the data from natural disasters like floods,fire,---etc.

-- Purpose of data guard is availability of data

-- Types of Availabilities are

     * Low Level Availability

     * Medium Level Availability

     * High Level Availability


-- We can achieve Medium Level Availability through Data Guard

-- We can achieve High Level Availability through RAC.

-- In RAC environment, each and every instance is called node. using RAC, we can have many instances for a single database..


Services in Data Guard:


1). Log Transport Service ( Redo Transport Service )

2). Log Apply Service ( Redo Apply Service )

-- Transferring the archivelog files from the production database to the standby database is known as Log Transport Service.

-- Applying the archivelog files is known as Log Apply Service.

-- Whenever the database is in the MRP ( Managed Recovery Process ) mode, Then only the archivelog files will be applied.

-- Whenever the standby database is in the MOUNT or OPEN state, Then only logs will be transfered . If it is in NOMOUNT or SHUTDOWN stage, Logs will not be transferd.


PROTECTION MODES:


--Data Guard provides a feature to protect the data by introducing the Protection Modes. They
 are

       1). Maximum Protection

       2). Maximum Availability

       3). Maximum Performance

-- The Default Mode of data guard is Maximum Performance.


1). Maximum Protection:

-- This mode guarantees 100% of the data protection.

-- No data loss by this mode.

-- In this mode, Production database commits a transaction, if and only if it gets safe acknowledgement from any of the standby.

-- If a safe acknowledgement is not received by from any of its configure standby databases, then after a threshold amount of time primary will goes down.


2). Maximum Availability:

-- It ensures high level of availability.

-- This mode is also similarly act as Maximum Protection mode.

-- But the difference is a production will commit the transaction even if it doesn't receives safe acknowledgement from any of its configured standby databases.

-- Here we have a little amount of data loss.

-- In this mode, It is recommended to have multiple standby databases.


3). Maximum Performance:

-- It is a default mode.

-- In this mode, we transfer redo data from primary to standby using "LogWriter Asynchronise Processor".

-- In this mode, primary database never bother about acknowledgement from standby.

-- Primary database will keep on committing the transactions without waiting for acknowledgement from standby.



Data Guard 10g Features:


Real Time Apply ( RTA ):


-- When we enable this RTA feature, MRP or LSP process applies the redo data on top of the consumed data files as soon as that redo data arrives into standby database.

-- Means, Once the transaction is completed at the production side, The changes will be reflected to standby side immediately without performing a log switch.



Data Guard 11g Features:



Active Standby database ( 11gR1 ):

-- A physical standby database which is in OPEN READ ONLY mode is called as Active Standby database.

-- We can convert the Physical standby to Logical standby as below

-- STEP1: Stop the MRP

-- STEP2:  Open the database in read only mode

-- STEP3:  Start the MRP

-- Advantage of Active Data guard is standby can serve the DRL ( SELECT ) statements , while currently being synchronized with the primary by the MRP.



Snap Shot Standby database ( 11gR2 ):


-- A physical standby database which is in OPEN ( READ WRITE ) mode is called as Snap Shot Standby datase.

-- We can convert the physical standby to Snap shot standby database.

-- Advantage of Snap shot standby is that We don't require an another server to create a clone database. Some standby database can be used as a clone database by converting it into Snap shot standby database.



Role Transitions / Role Management:


-- There are 2 types of transitions namely

    1). Switchover

    2). Failover


1). Switchover:

-- Converting the production database to the standby database and vice versa.


2). Failover:

-- Converting the standby database to the production ( primary ) database, whenever the production database get crashed.



















No comments:

Post a Comment