Book for Oracle DBA DATA GUARD Interview

1. How to setup Data Guard?

High Level Steps

Part 1 - Standby Creation

1. Prepare primary pwdfile/logging

2. Set parameters for primary
3. Set-up TNS requirements
4. Prepare Standby pwdfile
5. Start standby database
6. Duplicate target DB for standby
7. Start transport and apply mechanism

2. What are different types of modes in Data Guard and which is default?

Maximum Availability

This protection mode provides the highest level of data protection that is possible without
compromising the availability of a primary database. Transactions do not commit until all redo data
needed to recover those transactions has been written to the online redo log and to the standby redo
log on at least one synchronized standby database. If the primary database cannot write its redo stream
to at least one synchronized standby database, it operates as if it were in maximum performance mode
to preserve primary database availability until it is again able to write its redo stream to a synchronized
standby database.

This mode ensures that no data loss will occur if the primary database fails, but only if a second fault
does not prevent a complete set of redo data from being sent from the primary database to at least one
standby database.

Maximum Performance

This protection mode provides the highest level of data protection that is possible without affecting the
performance of a primary database. This is accomplished by allowing transactions to commit as soon as
all redo data generated by those transactions has been written to the online log. Redo data is also
written to one or more standby databases, but this is done asynchronously with respect to transaction
commitment, so primary database performance is unaffected by delays in writing redo data to the
standby database(s).

This protection mode offers slightly less data protection than maximum availability mode and has
minimal impact on primary database performance.This is the default protection mode.

Maximum Protection
This protection mode ensures that no data loss will occur if the primary database fails. To provide this
level of protection, the redo data needed to recover a transaction must be written to both the online
redo log and to the standby redo log on at least one synchronized standby database before the
transaction commits. To ensure that data loss cannot occur, the primary database will shut down, rather
than continue processing transactions, if it cannot write its redo stream to at least one synchronized
standby database.

Transactions on the primary are considered protected as soon as Data Guard has written the redo data
to persistent storage in a standby redo log file. Once that is done, acknowledgment is quickly made back
to the primary database so that it can proceed to the next transaction. This minimizes the impact of
synchronous transport on primary database throughput and response time. To fully benefit from
complete Data Guard validation at the standby database, be sure to operate in real-time apply mode so
that redo changes are applied to the standby database as fast as they are received. Data Guard signals
any corruptions that are detected so that immediate corrective action can be taken.

Because this data protection mode prioritizes data protection over primary database availability, Oracle
recommends that a minimum of two standby databases be used to protect a primary database that runs
in maximum protection mode to prevent a single standby database failure from causing the primary
database to shut down.

Maximum Availability Maximum Performance Maximum Protection

AFFIRM NOAFFIRM AFFIRM

SYNC ASYNC SYNC

3. How many standby databases we can create (in 10g/11g)?

Till Oracle 10g, 9 standby databases are supported.

From Oracle 11g R2, we can create 30 standby databases.

4. What are the parameters we’ve to set in primary/standby for Data Guard?

5. What is the use of fal_server & fal_client, is it mandatory to set these?

FAL_SERVER specifies the FAL (fetch archive log) server for a standby database.The value is an Oracle
Net service name, which is assumed to be configured properly on the standby database system to point
to the desired FAL server.

FAL_CLIENT specifies the FAL (fetch archive log) client name that is used by the FAL service, configured
through the FAL_SERVER parameter, to refer to the FAL client. The value is an Oracle Net service name,
which is assumed to be configured properly on the FAL server system to point to the FAL client (standby
database). Given the dependency of FAL_CLIENT on FAL_SERVER, the two parameters should be
configured or changed at the same time.

FAL_CLIENT and FAL_SERVER are initialization parameters used to configure log gap detection and
resolution at the standby database side of a physical database configuration. This functionality is
provided by log apply services and is used by the physical standby database to manage the detection
and resolution of archived redo logs.

FAL_CLIENT and FAL_SERVER only need to be defined in the initialization parameter file for the standby
database(s). It is possible; however, to define these two parameters in the initialization parameter for
the primary database server to ease the amount of work that would need to be performed if the
primary database were required to transition its role.

In Primary site:

FAL_SERVER=STANDBY
FAL_CLIENT=PRIMARY

In Standby site:

FAL_SERVER=PRIMARY
FAL_CLIENT=STANDBY

6. What are differences between physical, logical, snapshot standby and ADG
(or) what are different types of standby databases?

Physical standby – in mount state, MRP will apply archives

ADG – in READ ONLY state, MRP will apply archives
Logical standby – in READ ONLY state, LSP will run
Snapshot standby databases – Physical standby database can be converted to snapshot standby
database, which will be in READ WRITE mode, can do any kind of testing, then we can convert back
snapshot standby database to physical standby database and start MRP which will apply all pending
archives.
7. How to find out backlog of standby?
select round((sysdate – a.NEXT_TIME)*24*60) as “Backlog”,m.SEQUENCE#-1 “Seq Applied”,m.process,
m.status from v$archived_log a, (select process,SEQUENCE#, status from v$managed_standby where
process like ‘%MRP%’)m where a.SEQUENCE#=(m.SEQUENCE#-1);

8. If you didn’t have access to the standby database and you wanted to find out what error has
occurred in a data guard configuration, what view would you check in the primary database to check
the error message?
You can check the v$dataguard_status view.

select message from v$dataguard_status;

9. How can u recover standby which far behind from primary (or) without archive logs how can we
make standby sync?
By using RMAN incremental backup.

10. What is snapshot standby (or) How can we give a physical standby to user in READ WRITE mode
and let him do updates and revert back to standby?
Till Oralce 10g, create guaranteed restore point, open in read write, let him do updates, flashback to
restore point, start MRP. From Oracle 11g, convert physical standby to snapshot standby, let him do
updates, convert to physical standby, start MRP.

11. What are new features in 11g Data Guard?

1) Data Protection
• Advanced Compression
• Lost-write protection
• Fast-Start Failover
2) Increase ROI
• Active Data Guard
• Snapshot Standby
3) High Availability
• Faster Redo Apply
• Faster failover & switchover
• Automatic Failover using ASYNC
4) Manageability
• Mixed Windows/Linux

12. What are the uses of standby redo log files?

Standby Redo Logs (SRL) : is similar to Online Redo Log (ORL) and only difference
between two is that Standby Redo Log is used to store redo data received from another
database (primary database).

13. In what scenarios Standby Redo Logs are required ?

Standby Redo Log is required if
1) Your standby database is in maximum protection or maximum availabilitymodes.
(Physical Standby Database can run in one of three modes – Maximum Protection, Maximum
Availability and Maximum Performance)
or
2) If you are using Real-Time Apply on Standby Database.
or
3) If you are using Cascaded Destinations
14. What is RTA (real time apply) mode MRP?

15. What is the difference between normal MRP (managed apply) and RTA MRP (real time apply)?
Standby database runs in three different modes

Maximum Performance
Maximum availability
Maximum protection

Maximum performance is yours ASYNChronous apply of redo entries at standby site and
problems at standby site
doesn't halt your production site at all.
e.g : Network failed between primary site and standby site, you will not face any issue at
production site.

Maximum protection is your SYNChronous apply of redo entries at standby site and a problem
at standby site halts the
production site as well. This ensures that both the site are in complete sync and even disaster at
primary site will not result
in data loss.

Maximum availability is in between your above two modes, it works like a maximum protection
mode and provide synchronous
transmission of redo entries, but in case of unavailability at standby site it doesn't halt primary
database rather convert itself to maximum
performance mode.

When you ask difference between

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Above command will start MRP process and starts the recovery of configured database with
redo entries. Disconnect from session releases the control back to client connection.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE

DISCONNECT;

Above command will use Real Time Apply, a new feature which was introduced in 10g, this
will ensure that the redo entries will be applied directly from standby log files, thus you receive a
real time data. This facilitate 11g Active data guard concept as well.

Thus this command starts the MRP process, but it does't wait for the logs to complete before
applying, rather it picks up changed
entries from current standby logfiles and recovers the database.

e.g : You used current logfile syntax for recovery and you did insert into tableName values(1) at
primary site, changes are captured in
the redo log and LGWR is used to transfer entries to standby site. The entries are transferred to
RFS Process at the standby site, which
copies the entry to standby redo logfiles, since the method used is current logfile. The changes
are applied immediately. Thus your changed
data at primary site and standby site is available immediately rather than waiting for the entire
log to be filled before applying to standby site.
- See more at: http://www.oracledba.in/Articles/display_article.aspx?
article_id=43#sthash.oXf1Vypb.dpuf

16. What are various parameters in log_archive_dest and it’s use?

LOG_ARCHIVE_DEST is applicable only if we are running the database in
ARCHIVELOG mode. LOG_ARCHIVE_DEST parameter are used to specified the
archiving location. The Location specified by log_archive_dest must be local . We
choose to archive only two local location i.e, primary and a secondary destination (
using LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST ) .

The LOG_ARCHIVE_DEST_n initialization parameter defines up to ten (where n =

1, 2, ... 10) destinations in oracle 10g and thirty one (n=1,2....31) destination in
oracle 11g , each of which must specify either the LOCATION or
the SERVICE attribute to specify where to archive the redo data. All other attributes
are optional.We set the attributes for the LOG_ARCHIVE_DEST_n initialization
parameter to control different aspects of how redo transport services transfer redo
data from a production or primary database destination to another (standby)
database destination.For every LOG_ARCHIVE_DEST_n initialization parameter that
we define, we must specify a corresponding LOG_ARCHIVE_DEST_STATE_n
parameter. The LOG_ARCHIVE_DEST_STATE_n (where n is an integer from 1 to 10)
initialization parameter specifies whether the corresponding destination is currently
enabled or disabled.

17. What is the difference between SYNC/ASYNC, LGWR/ARCH, and AFFIRM/NOAFFIRM?

Synchronous transport (SYNC) is also referred to as "zero data loss" method because the LGWR is not
allowed to acknowledge a commit has succeeded until the LNS can confirm that the redo needed to
recover the transaction has been written at the standby site.

In the diagram to the right the phases of a transaction are

1. The user commits a transaction creating a redo record in the SGA, the LGWR reads the redo
record from the log buffer and writes it to the online redo log file and waits for confirmation
from the LNS
2. The LNS reads the same redo record from the buffer and transmits it to the standby database
using Oracle Net Services, the RFS receives the redo at the standby database and writes it to the
SRL
3. When the RFS receives a write complete from the disk, it transmits an acknowledgment back to
the LNS process on the primary database which in turns notifies the LGWR that the transmission
is complete, the LGWR then sends a commit acknowledgment to the user

This setup really does depend on network performance and can have a dramatic impact on the primary
databases, low latency on the network will have a big impact on response times. The impact can be seen
in the wait event "LNS wait on SENDREQ" found in thev$system_event dynamic performance view.

There is also a timeout value that can be adjusted in the event of a network failure, we will discuss this
in more detail in the installation section
Asynchronous transport (ASYNC) is different from SYNC in that it eliminates the requirement that the
LGWR waits for a acknowledgment from the LNS, creating a "near zero" performance on the primary
database regardless of distance between the primary and the standby locations. The LGWR will continue
to acknowledge commit success even if the bandwidth prevents the redo of previous transaction from
being sent to the standby database immediately. If the LNS is unable to keep pace and the log buffer is
recycled before the redo is sent to the standby, the LNS automatically transitions to reading and sending
from the log file instead of the log buffer in the SGA. Once the LNS has caught up it then switches back
to reading directly from the buffer in the SGA.

The log buffer ratio is tracked via the view X$LOGBUF_READHIST a low hit ratio indicates that the LNS is
reading from the log file instead of the log buffer, if this happens try increasing the log buffer size.

The drawback with ASYNC is the increased potential for data loss, if a failure destroys the primary
database before the transport lag is reduced to zero, any committed transactions that are part of the
transport lag are lost. So again make sure that the network bandwidth is adequate and that you get the
lowest latency possible.
Controls whether a redo transport destination acknowledges received redo data before or after writing
it to the standby redo log:

● AFFIRM—specifies that a redo transport destination acknowledges received redo

data after writing it to the standby redo log.

● NOAFFIRM—specifies that a redo transport destination acknowledges received redo

data before writing it to the standby redo log.

● LGWR transmission
● All writings into the online redo log are synchronously or asynchronously transmitted to the
standby database. If there is astandby redo log on the standby site, it is used. If there is no
standby redo log on the standby site, an archive log will be gradually filled. However, the
uncompletely filled archive log cannot be used in case of a disaster. Therefor, it is recommended
to use standby redo logs.
● LGWR transmission is specified through the log_archive_dest_noption LGWR:
● log_archive_dest_2='service=to_standby lgwr'
● If LGWR transmission is used, there should be a row havingclient_process=LGWR
in v$managed_standby.
● ARCH transmission
● Data is transmitted as an archived redo logs.
● ARCH transmission is specified through the log_archive_dest_noption ARCH:
● log_archive_dest_2='service=to_standby arch'
● If ARCH transmission is used, there should be a row havingclient_process=ARCH
in v$managed_standb

18. What is Data Guard broker (or) what is the use of dgmgrl?

19. What is StaticConnectIdentifier property used for?

The StaticConnectIdentifier configurable instance-specific property specifies the
connection identifier that the DGMGRL client will use when starting database instances.
20. What is failover/switchover (or) what is the difference between failover & switchover?
Switchover – This is done when both primary and standby databases are available. It is pre-planned.
Failover – This is done when the primary database is NO longer available (ie in a Disaster). It is not pre-
planned.
A switchover (or graceful switchover) is a planned role reversal between the primary and the standby
databases. This is used when there is a planned outage on the primary database or primary server and
you do not want to have extended downtime on the primary database. The switchover allows you to
switch the roles of the databases so that the standby databases now becomes a primary databases and
all your users and applications can continue operations on the “new” primary database (on the standby
server). During the switchover operation there is a small outage. How long the outage lasts, depends on
a number of factors including the network, the number and sizes of the redo logs. The switchover
operation happens on both the primary and standby database.
A failover operation is what happens when the primary database is no longer available. The failover
operation only happens on the standby database. The failover operation activatesthe standby database
and turns this into a primary database. This process cannot be reversed so the decision to failover
should be carefully made. The failover process is initiated during a real disaster or severe outage.

21. What are the background processes involved in Data Guard?

The Log Transport Service and Log Apply Service form the backbone of the Data Guard environment. The
log transport service starts on the primary database and completes on the standby database. The
following processes facilitate the log transport service on the primary and the standby site:

- Archiver Process ? The archiver process (ARCn or ARCH) is responsible for archiving online
redo logs. The archival destination could be a local destination or a remote standby database
site. In the case of a Data Guard configuration, one of the archival destinations must be a
standby database. The archiver process of the primary database writes the redo log file.
For a better data protection mode, the standby redo log files can be configured on the standby
database. In this case, the archiver process on the standby site will be used to archive the
standby redo log files.

- Log Writer (LGWR) ? The log writer process on the primary database writes entries from the
redo log buffer to the online redo log file. When the current online redo log file is full, it triggers
the archiver process to start the archiving activity. In some cases, the log writer process writes
redo entries to the online redo log file of the primary database and the standby redo log file of
the standby database. Usually, in this kind of arrangement the LGWR works as the log transport
agent that is setup to achieve high data protection modes.

- Remote File Server (RFS) Process ? The RFS process runs on the standby database and is
responsible for communication between the primary and the standby database. For the log
transport service, the RFS on the standby database receives the redo records from the archiver
or the log writer process of the primary database over Oracle Net and writes to filesystem on the
standby site.

- Fetch Archive Log (FAL) ? The FAL process has two components: FAL Client and FAL Server.
Both processes are used for archive gap resolution. If the Managed Recovery Process (MRP) on
the standby database site detects an archive gap sequence, it initiates a fetch request to the FAL
client on the standby site. This action, in turn, requests the FAL server process on the primary
database to re-transmit the archived log files to resolve the gap sequence. Archive gap
sequences will be discussed later in this chapter.

Once the log transport service completes the transmission of redo records to the standby site,
the log apply service starts applying the changes to the standby database. The log apply service
operates solely on the standby database. The following processes on the standby site facilitate
the log apply operations:
 - Managed Recovery Process (MRP) ? The MRP applies the redo entries from the archived
redo logs onto the physical standby database.

- Logical Standby Process (LSP) ? The LSP applies the redo records from archived redo logs to
the logical standby database. The Oracle database log miner engine is used by the logical
standby process for the SQL apply operations. Using the log miner engine, the LSP process
recreates the SQL statements from redo logs that have been executed on the primary database.
These statements are then applied to the standby database to keep it current with the primary
database.

1. How to setup Data Guard?

2. What are different types of modes in Data Guard and
which is default?
Maximum performance:
This is the default protection mode. It provides the high level of data protection
that is possible without affecting the performance of a primary database. This
is accomplished by allowing transactions to commit as soon as all redo data
generated by those transactions has been written to the online log.

Maximum protection:
This protection mode ensures that no data loss will occur if the primary
database fails. To provide this level of protection, the redo data needed to
recover a transaction must be written to both the online redo log and to at
least one standby database before the transaction commits. To ensure that
data loss cannot occur, the primary database will shut down, rather than
continue processing transactions.

Maximum availability:
This protection mode provides the highest level of data protection that is
possible without compromising the availability of a primary database.
Transactions do not commit until all redo data needed to recover those
transactions has been written to the online redo log and to at least one
standby database.

3. How many standby databases we can create (in 10g/11g)?

Till Oracle 10g, 9 standby databases are supported.

From Oracle 11g R2, we can create 30 standby databases.

4. What are the parameters we’ve to set in primary/standby
for Data Guard?
5. What is the use of fal_server & fal_client, is it mandatory
to set these?
6. What are differences between physical, logical, snapshot
standby and ADG (or) what are different types of standby
databases?
Physical standby – in mount state, MRP will apply archives

ADG – in READ ONLY state, MRP will apply archives

Logical standby – in READ ONLY state, LSP will run

Snapshot standby databases – Physical standby database can be converted

to snapshot standby database, which will be in READ WRITE mode, can do
any kind of testing, then we can convert back snapshot standby database to
physical standby database and start MRP which will apply all pending
archives.

7. How to find out backlog of standby?

select round((sysdate – a.NEXT_TIME)*24*60) as “Backlog”,m.SEQUENCE#-
1 “Seq Applied”,m.process, m.status

from v$archived_log a, (select process,SEQUENCE#, status from

v$managed_standby where process like ‘%MRP%’)m where
a.SEQUENCE#=(m.SEQUENCE#-1);

8. If you didn’t have access to the standby database and you

wanted to find out what error has occurred in a data guard
configuration, what view would you check in the primary
database to check the error message?
You can check the v$dataguard_status view.

select message from v$dataguard_status;

9. How can u recover standby which far behind from primary

(or) without archive logs how can we make standby sync?
By using RMAN incremental backup.
10. What is snapshot standby (or) How can we give a
physical standby to user in READ WRITE mode and let him do
updates and revert back to standby?
Till Oralce 10g, create guaranteed restore point, open in read write, let him do
updates, flashback to restore point, start MRP.

From Oracle 11g, convert physical standby to snapshot standby, let him do
updates, convert to physical standby, start MRP.

11. What are new features in 11g Data Guard?

12. What are the uses of standby redo log files?

13. What is dg_config?

14. What is RTA (real time apply) mode MRP?

15. What is the difference between normal MRP (managed

apply) and RTA MRP (real time apply)?

16. What are various parameters in log_archive_dest and it’s

use?

17. What is the difference between SYNC/ASYNC,

LGWR/ARCH, and AFFIRM/NOAFFIRM?
18. What is Data Guard broker (or) what is the use of
dgmgrl?

19. What is StaticConnectIdentifier property used for?

20. What is failover/switchover (or) what is the difference

between failover & switchover?

21. What are the background processes involved in Data

Guard?
MRP, LSP,