11gR2 RAC-Dataguard Sync issue Between Primary & Standby
I have a 2 node RAC -DG setup between 2 remote data centres. After building DataGuard between them I am now coming across stange latency stats. Read more…
I have a 2 node RAC -DG setup between 2 remote data centres. After building DataGuard between them I am now coming across stange latency stats. Read more…
1) Remove the Data Guard Broker Configuration
Using the Commandline DGMGRL
SQL> show parameter dg_broker;
NAME TYPE VALUE
———————————— ———– ——————————
dg_broker_config_file1 string /mnt/data/oradata/PROD/dr1PROD.dat
dg_broker_config_file2 string /mnt/data/oradata/PROD/dr2PROD.dat
dg_broker_start boolean TRUE
I generally don’t cut and paste metalink notes. But in case you are using DG , for diagnosis you will have to use 2 metalink scripts, [ID 241438.1] & [ID 241374.1] Read more…
I generally don’t cut and paste metalink notes. But in case you are using DG , for diagnosis you will have to use 2 metalink scripts, [ID 241438.1] & [ID 241374.1] Read more…
DGMGRL> show database PROD;
Object “prod” was not found
** 11.2.0.2 – You may see errors at dgmgrl if you don’t include database name in quotes
In this post, I will show you how easy it is to fail-over on standby dataguard database when primary is not available. Read more…
My DGMGRL configuration is returning warnings as below.
DGMGRL> show database primary;
Database – primary
Role: PRIMARY
Intended State: TRANSPORT-ON
Instance(s):
primary
Database Warning(s):
ORA-16789: standby redo logs not configured
Generally you don’t have to set up Dataguard on a single machine. But there are occasions when you have to build test environment for destruction and this post is tuned for such opportunity.
I was looking for a NAGIOS monitoring script which will list the archive gap between Primary and 2 of my Standby databases.
The following represents the Oracle recommended method for automating database startup and shutdown of Oracle 10g instances.
LOGICAL | DBA_LOGSTDBY_EVENTS | Contains information about the activity of the logical standby database system. It can be used to determine the cause of failures that occur when SQL Apply is applying redo to logical standby databases. |
LOGICAL | DBA_LOGSTDBY_LOG | Shows the log files registered for logical standby databases. |
LOGICAL | DBA_LOGSTDBY_NOT_UNIQUE | Identifies tables that have no primary and no non-null unique indexes. |
LOGICAL | DBA_LOGSTDBY_PARAMETERS | Contains the list of parameters used by SQL apply. |
LOGICAL | DBA_LOGSTDBY_PROGRESS | Describes the progress of SQL Apply on the logical standby database. |
LOGICAL | DBA_LOGSTDBY_SKIP | Lists the tables that will be skipped by SQL Apply. |
LOGICAL | DBA_LOGSTDBY_SKIP_TRANSACTION | Lists the skip settings chosen. |
DBA_LOGSTDBY_UNSUPPORTED | Identifies the schemas and tables (and columns in those tables) that contain unsupported datatypes. Use this view when you are preparing to create a logical standby database. | |
PHYSICAL/LOGICAL | V$ARCHIVE_DEST | Read more… |
The primary and standby database have the same filesystem layout, i.e. archive redo is at same place on both servers. Read more…
Why standby periodically lags during the day?
The script reports the time it took to apply the log, the size of the log, and the redo apply rate for that log.
This process will reverse database roles in a Data Guard setup, i.e. standby database becomes primary.