Data Guard no available

Dear,
We are using oracle 9i with data guard. Today i check the data guard from standby server. I get following message
ORA-16525: the Data Guard broker is not yet available
ORA-06512: at "SYS.X$DBMS_DRS", line 109
ORA-06512: at line 2
after i run following command on standby machine
SQL> alter system set DG_BROKER_START = true;
System altered.
The problem still can't solve. How can i check or solve the problem?
ManyThanks

ORA-16525: the Data Guard broker is not yet available
Cause: The Data Guard broker process has not yet been started, is initializing, or has failed to start.
Action: If the broker has not been started, set DG_BROKER_START to true and allow the broker to finish initializing before making the request. If the broker failed to start, check the Data Guard log for possible errors. Otherwise, retry the operation.

Similar Messages

Oracle Data Guard 9i

This is a quote from an Oracle publication on Oracle Data Guard 9i.
"Oracle Data Guard's new SQL Apply feature creates a "logical standby" that enables continuous access to a working copy of your primary database. With SQL Apply, the standby database is continuously available for reporting and other operations, while always at-the-ready for unplanned failovers. Data Guard provides log shipping, remote mirroring, zero-data-loss disaster protection, and a single point of control and automation. "
My question is: Is the standby database open in read-write or read-only mode?
If, its only read, is there ANY other way read-write version of a database could be created at a remote site besides:
a) Complete copying - duplicate database at remote site open in read-write.
b) Distributed database - replication - remote users access their own version and the two keep themselves in sync.
c) Parallel server - one database - two instances.

Data Guard is available for Linux (within Oracle9i).
It's a tool to make it much more easier to create a standby
database, but I don't think it's required!
Regards,
Thomas.
Is Oracle 9i data guard for Linux available??
Well, my real question is, I need to setup 9i standby database
on Linux. Do I need data guard installed in order to setup
standby database??

RMAN x Data Guard

I have to construct a site with critical data that cannot be lost in any circumstances (every DBA should say this).
I thought of using Data Guard to availability. But the costs were prohibitive. Then, I would only use the RMAN to manage the backups. I can obtain the same data security degree using only RMAN, can't I?
The only difference is that in case of disaster, with Data Guard the database would return into production faster than with RMAN, isn't it?
Can I create a standby database with RMAN without using Data Guard?

Refer to metalink Note:469493.1 for detailed steps in creating a standby database using RMAN. Check with Oracle sales on how licensing works with standby db...i think you need one on activating standby..

ORA-16525: the Data Guard broker is not yet available while conneting ...

Hi,
I am trying to connect oracle database instance in dgmgrl prompt.
Following error message appear ...
DGMGRL>
DGMGRL> connect sys/<password>@<oracle_service_name>
Connected.
Error:
ORA-16525: the Data Guard broker is not yet available
ORA-06512: at "SYS.DBMS_DRS", line 124
ORA-06512: at line 1
DGMGRL> exit
$ e
We are using oracle enterprise manager ...
SSM

DG broker is the way to go. There are only minor points you can't control - like when you have standby redo logs and no redo application delay, dg broker will always start real-time apply.
Also, DG broker is the only way if you want fast-start failover (10gR2 feature).
What is the latency of your nework, especially under load? Add this latency to each commit - will the commit time be acceptable? If not, you cannot use sync.
What version do you use? In 10gR1, there are issues with async - there is only about 50MB buffer, and if you get such backlog, even with async commit will wait for standby. (In 10gR2 this is solved, async will read from disk redo logs.)
NET_TIMEOUT - set it low for sync (so commits won't hang long), higher for async. Default is 180 seconds, Oracle recommends minimum value to 10 seconds. I would start with 10 sec for sync, 180 for sync. The main question is, how reliable your network is, and how long brownouts you want to survive without affecting data protection (with the expense of performance).
Regarding the proper setting of all bells and whistles of archive_log_dest_n - I had best experience with leaving it to dg broker. Just set LogXptMode property to sync/async/arch, and let dg broker set everything else (service, valid_for, affirm, retries...).
The authoritative source: http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm#Publications
If you are on 10.2.0.1 - 10.2.0.3, please see metalink bug 5578157, 5587231 - if sqlnet.outbound_connection_timeout is not set, the lgwr can hang even if net_timeout is set. (Yes, real-world experience:-)

Error: ORA-16525: the Data Guard broker is not yet available

Hi ,
After upgrading from 11201 to 11203 ON AIX GI/RDBMS on standby but have not upgraded the primary db yet.I had set dg_broker_start=false and disable configuration before i started the upgrade .
once the GI for oracle restart was upgraded i upgraded the rdbms binaries and brought up the standby on mount ,while trying to enable configuration its throwing the below error.I had already started the broker process.
SQL> show parameter dg_
NAME TYPE VALUE
dg_broker_config_file1 string /u01/app/omvmxp1/product/11.2.
0/dbhome_2/dbs/dr1mvmxs2.dat
dg_broker_config_file2 string /u01/app/omvmxp1/product/11.2.
0/dbhome_2/dbs/dr2mvmxs2.dat
dg_broker_start boolean TRUE
DGMGRL> show configuration;
Configuration - Matrxrep_brkr
Protection Mode: MaxAvailability
Databases:
mvmxp2 - Primary database
mvmxs2 - Physical standby database
Error: ORA-16525: the Data Guard broker is not yet available
Fast-Start Failover: DISABLED
Configuration Status:
ERROR
from drcmvmxs2.log
Starting Data Guard Broker bootstrap <<Broker Configuration File Locations:
dg_broker_config_file1 = "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr1mvmxs2.dat"
dg_broker_config_file2 = "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr2mvmxs2.dat"
12/19/2012 16:05:33
Data Guard Broker shutting down
DMON Process Shutdown <<12/19/2012 16:10:20
Starting Data Guard Broker bootstrap <<Broker Configuration File Locations:
dg_broker_config_file1 = "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr1mvmxs2.dat"
dg_broker_config_file2 = "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr2mvmxs2.dat"
~
Regards
Edited by: Monto on Dec 19, 2012 1:23 PM

Hi,
I removed the configuration and removed the broker files from RAC primary(mvmxp2) and single instance standby(mvmxs2) and re-created back.i tried it many times but getting error "ORA-16532" .I needed to have this standby backup before i start upgrading the primary.
SQL> alter system set dg_broker_start=true scope=both;
System altered.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options
palmer60:/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs>dgmgrl
DGMGRL for IBM/AIX RISC System/6000: Version 11.2.0.3.0 - 64bit Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys@mvmxp2
Password:
Connected.
DGMGRL> CREATE CONFIGURATION 'Matrxrep'
AS
PRIMARY DATABASE IS 'mvmxp2'
CONNECT IDENTIFIER IS 'mvmxp2';> > >
Configuration "Matrxrep" created with primary database "mvmxp2"
DGMGRL> ADD DATABASE 'mvmxs2'
AS
CONNECT IDENTIFIER IS 'mvmxs2'
;Database "mvmxs2" added
DGMGRL> SHOW CONFIGURATION;
Configuration - Matrxrep
Protection Mode: MaxPerformance
Databases:
mvmxp2 - Primary database
mvmxs2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
DGMGRL> ENABLE CONFIGURATION;
Enabled.
DGMGRL> SHOW DATABASE MVMXS2;
Database - mvmxs2
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: (unknown)
Apply Lag: (unknown)
Real Time Query: OFF
Instance(s):
mvmxs2
Database Status:
DGM-17016: failed to retrieve status for database "mvmxs2"
ORA-16532: Data Guard broker configuration does not exist
ORA-16625: cannot reach database "mvmxs2"
DGMGRL>
tailed the drcmvmxs2.log during stop and start of the broker
palmer60:/u01/app/omvmxp1/diag/rdbms/mvmxs2/mvmxs2/trace>tail -f drcmvmxs2.log
12/19/2012 20:32:20
drcx: cannot open configuration file "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr1mvmxs2.dat"
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
12/19/2012 20:32:55
drcx: cannot open configuration file "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr2mvmxs2.dat"
ORA-27037: unable to obtain file status
IBM AIX RISC System/6000 Error: 2: No such file or directory
Additional information: 3
12/19/2012 20:59:10
Data Guard Broker shutting down
DMON Process Shutdown <<12/19/2012 20:59:35
Starting Data Guard Broker bootstrap <<Broker Configuration File Locations:
dg_broker_config_file1 = "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr1mvmxs2.dat"
dg_broker_config_file2 = "/u01/app/omvmxp1/product/11.2.0/dbhome_2/dbs/dr2mvmxs2.dat"
Not sure how to fix this one.
Regards

Data guard synchronization after link down b/w primary and physical standby

Hi All,
I have configured data guard on oracle 11gr2 db. Normally switchover between my primary and physical standby happens smoothly and the Apply lag would be zero. Recently We had to test a scenario when the network link between Primary and Physical standby is completely down and Physical standby is isolated completely for more than half an hour.
When we brought up the link every thing worked smoothly but apply lag started increasing from 0 to around 3 hrs. And then it started reducing to 0. Currently Apply lag and transport lag shows 0.
But is this normal behaviour of oracle data guard that when the link between primary and physical standby is completely down, It requires 3-4 hrs for resynchronization ??? Even when during isolation, there were very few transactions happend on primary database ??
Are there any documents available for this scenario??
Thanks

Hi, after the link is up, if there were some transactions and produced archive logs it's normal to take some time for resync. To check if 3-4 hours is normal or not, you can repeat the scenario and this time check
- how many archivelogs does primary produce in this period.
- after the link is up, does archivelog transfer immediately starts from primary to standby? Is primary able to send these archivelogs parallel?
- Is there anything wrong with the apply process?
check primary & standby alert log files, and run this query on standby to check the transport and apply processes:
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
regards

Data Guard Failover after primary site network failure or disconnect.

Hello Experts:
I'll try to be clear and specific with my issue:
Environment:
Two nodes with NO shared storage (I don't have an Observer running).
Veritas Cluser Server (VCS) with Data Guar Agent. (I don't use the Broker. Data Guard agent "takes care" of the switchover and failover).
Two single instance databases, one per node. NO RAC.
What I'm being able to perform with no issues:
Manual switch(over) of the primary database by running VCS command "hagrp -switch oraDG_group -to standby_node"
Automatic fail(over) when primary node is rebooted with "reboot" or "init"
Automatic fail(over) when primary node is shut down with "shutdown".
What I'm NOT being able to perform:
If I manually unplug the network cables from the primary site (all the network, not only the link between primary and standby node so, it's like a server unplug from the energy source).
Same situation happens if I manually disconnect the server from the power.
This is the alert logs I have:
This is the portion of the alert log at Standby site when Real Time Replication is working fine:
Recovery of Online Redo Log: Thread 1 Group 4 Seq 7 Reading mem 0
Mem# 0: /u02/oracle/fast_recovery_area/standby_db/onlinelog/o1_mf_4_9c3tk3dy_.log
At this moment, node1 (Primary) is completely disconnected from the network. SEE at the end when the database (standby which should be converted to PRIMARY) is not getting all the archived logs from the Primary due to the abnormal disconnect from the network:
Identified End-Of-Redo (failover) for thread 1 sequence 7 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 15922544 time 12/23/2013 17:12:48
Media Recovery Complete (primary_db)
Terminal Recovery: successful completion
Forcing ARSCN to IRSCN for TR 0:15922544
Mon Dec 23 17:13:22 2013
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance primary_db - Archival ErrorAttempt to set limbo arscn 0:15922544 irscn 0:15922544
ORA-16014: log 4 sequence# 7 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/u02/oracle/fast_recovery_area/standby_db/onlinelog/o1_mf_4_9c3tk3dy_.log'
Resetting standby activation ID 2071848820 (0x7b7de774)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Mon Dec 23 17:13:33 2013
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Terminal Recovery: applying standby redo logs.
Terminal Recovery: thread 1 seq# 7 redo required
Terminal Recovery:
Recovery of Online Redo Log: Thread 1 Group 4 Seq 7 Reading mem 0
Mem# 0: /u02/oracle/fast_recovery_area/standby_db/onlinelog/o1_mf_4_9c3tk3dy_.log
Identified End-Of-Redo (failover) for thread 1 sequence 7 at SCN 0xffff.ffffffff
Incomplete Recovery applied until change 15922544 time 12/23/2013 17:12:48
Media Recovery Complete (primary_db)
Terminal Recovery: successful completion
Forcing ARSCN to IRSCN for TR 0:15922544
Mon Dec 23 17:13:22 2013
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance primary_db - Archival ErrorAttempt to set limbo arscn 0:15922544 irscn 0:15922544
ORA-16014: log 4 sequence# 7 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/u02/oracle/fast_recovery_area/standby_db/onlinelog/o1_mf_4_9c3tk3dy_.log'
Resetting standby activation ID 2071848820 (0x7b7de774)
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Mon Dec 23 17:13:33 2013
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH
Attempt to do a Terminal Recovery (primary_db)
Media Recovery Start: Managed Standby Recovery (primary_db)
started logmerger process
Mon Dec 23 17:13:33 2013
Managed Standby Recovery not using Real Time Apply
Media Recovery failed with error 16157
Recovery Slave PR00 previously exited with exception 283
ORA-283 signalled during: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH...
Mon Dec 23 17:13:34 2013
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process MMNL
Stopping background process MMON
License high water mark = 38
All dispatchers and shared servers shutdown
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
ALTER DATABASE DISMOUNT
Shutting down archive processes
Archiving is disabled
Mon Dec 23 17:13:38 2013
Mon Dec 23 17:13:38 2013
Mon Dec 23 17:13:38 2013
ARCH shutting downARCH shutting down
ARCH shutting down
ARC0: Relinquishing active heartbeat ARCH role
ARC2: Archival stopped
ARC0: Archival stopped
ARC1: Archival stopped
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Mon Dec 23 17:13:40 2013
Stopping background process VKTM
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
Mon Dec 23 17:13:43 2013
Instance shutdown complete
Mon Dec 23 17:13:44 2013
Adjusting the default value of parameter parallel_max_servers
from 1280 to 470 due to the value of parameter processes (500)
Starting ORACLE instance (normal)
************************ Large Pages Information *******************
Per process system memlock (soft) limit = 64 KB
Total Shared Global Region in Large Pages = 0 KB (0%)
Large Pages used by this instance: 0 (0 KB)
Large Pages unused system wide = 0 (0 KB)
Large Pages configured system wide = 0 (0 KB)
Large Page size = 2048 KB
RECOMMENDATION:
Total System Global Area size is 3762 MB. For optimal performance,
prior to the next instance restart:
1. Increase the number of unused large pages by
at least 1881 (page size 2048 KB, total size 3762 MB) system wide to
get 100% of the System Global Area allocated with large pages
2. Large pages are automatically locked into physical memory.
Increase the per process memlock (soft) limit to at least 3770 MB to lock
100% System Global Area's large pages into physical memory
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 32
Number of processor cores in the system is 16
Number of processor sockets in the system is 2
CELL communication is configured to use 0 interface(s):
CELL IP affinity details:
    NUMA status: NUMA system w/ 2 process groups
    cellaffinity.ora status: cannot find affinity map at '/etc/oracle/cell/network-config/cellaffinity.ora' (see trace file for details)
CELL communication will use 1 IP group(s):
    Grp 0:
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.
IMODE=BR
ILAT =88
LICENSE_MAX_USERS = 0
SYS auditing is disabled
NUMA system with 2 nodes detected
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /u01/oracle/product/11.2.0.4
System name:    Linux
Node name:      node2.localdomain
Release:        2.6.32-131.0.15.el6.x86_64
Version:        #1 SMP Tue May 10 15:42:40 EDT 2011
Machine:        x86_64
Using parameter settings in server-side spfile /u01/oracle/product/11.2.0.4/dbs/spfileprimary_db.ora
System parameters with non-default values:
processes                = 500
sga_target               = 3760M
control_files            = "/u02/oracle/orafiles/primary_db/control01.ctl"
control_files            = "/u01/oracle/fast_recovery_area/primary_db/control02.ctl"
db_file_name_convert     = "standby_db"
db_file_name_convert     = "primary_db"
log_file_name_convert    = "standby_db"
log_file_name_convert    = "primary_db"
control_file_record_keep_time= 40
db_block_size            = 8192
compatible               = "11.2.0.4.0"
log_archive_dest_1       = "location=/u02/oracle/archivelogs/primary_db"
log_archive_dest_2       = "SERVICE=primary_db ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=primary_db"
log_archive_dest_state_2 = "ENABLE"
log_archive_min_succeed_dest= 1
fal_server               = "primary_db"
log_archive_trace        = 0
log_archive_config       = "DG_CONFIG=(primary_db,standby_db)"
log_archive_format       = "%t_%s_%r.dbf"
log_archive_max_processes= 3
db_recovery_file_dest    = "/u02/oracle/fast_recovery_area"
db_recovery_file_dest_size= 30G
standby_file_management = "AUTO"
db_flashback_retention_target= 1440
undo_tablespace          = "UNDOTBS1"
remote_login_passwordfile= "EXCLUSIVE"
db_domain                = ""
dispatchers              = "(PROTOCOL=TCP) (SERVICE=primary_dbXDB)"
job_queue_processes      = 0
audit_file_dest          = "/u01/oracle/admin/primary_db/adump"
audit_trail              = "DB"
db_name                  = "primary_db"
db_unique_name           = "standby_db"
open_cursors             = 300
pga_aggregate_target     = 1250M
dg_broker_start          = FALSE
diagnostic_dest          = "/u01/oracle"
Mon Dec 23 17:13:45 2013
PMON started with pid=2, OS id=29108
Mon Dec 23 17:13:45 2013
PSP0 started with pid=3, OS id=29110
Mon Dec 23 17:13:46 2013
VKTM started with pid=4, OS id=29125 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Mon Dec 23 17:13:46 2013
GEN0 started with pid=5, OS id=29129
Mon Dec 23 17:13:46 2013
DIAG started with pid=6, OS id=29131
Mon Dec 23 17:13:46 2013
DBRM started with pid=7, OS id=29133
Mon Dec 23 17:13:46 2013
DIA0 started with pid=8, OS id=29135
Mon Dec 23 17:13:46 2013
MMAN started with pid=9, OS id=29137
Mon Dec 23 17:13:46 2013
DBW0 started with pid=10, OS id=29139
Mon Dec 23 17:13:46 2013
DBW1 started with pid=11, OS id=29141
Mon Dec 23 17:13:46 2013
DBW2 started with pid=12, OS id=29143
Mon Dec 23 17:13:46 2013
DBW3 started with pid=13, OS id=29145
Mon Dec 23 17:13:46 2013
LGWR started with pid=14, OS id=29147
Mon Dec 23 17:13:46 2013
CKPT started with pid=15, OS id=29149
Mon Dec 23 17:13:46 2013
SMON started with pid=16, OS id=29151
Mon Dec 23 17:13:46 2013
RECO started with pid=17, OS id=29153
Mon Dec 23 17:13:46 2013
MMON started with pid=18, OS id=29155
Mon Dec 23 17:13:46 2013
MMNL started with pid=19, OS id=29157
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /u01/oracle
Mon Dec 23 17:13:46 2013
ALTER DATABASE   MOUNT
ARCH: STARTING ARCH PROCESSES
Mon Dec 23 17:13:50 2013
ARC0 started with pid=23, OS id=29210
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Successful mount of redo thread 1, with mount id 2071851082
Mon Dec 23 17:13:51 2013
ARC1 started with pid=24, OS id=29212
Allocated 15937344 bytes in shared pool for flashback generation buffer
Mon Dec 23 17:13:51 2013
ARC2 started with pid=25, OS id=29214
Starting background process RVWR
ARC1: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
Mon Dec 23 17:13:51 2013
RVWR started with pid=26, OS id=29216
Physical Standby Database mounted.
Lost write protection disabled
Completed: ALTER DATABASE   MOUNT
Mon Dec 23 17:13:51 2013
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
         USING CURRENT LOGFILE DISCONNECT FROM SESSION
Attempt to start background Managed Standby Recovery process (primary_db)
Mon Dec 23 17:13:51 2013
MRP0 started with pid=27, OS id=29219
MRP0: Background Managed Standby Recovery process started (primary_db)
ARC2: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance primary_db - Archival Error
ORA-16014: log 4 sequence# 7 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/u02/oracle/fast_recovery_area/standby_db/onlinelog/o1_mf_4_9c3tk3dy_.log'
At this moment, I've lost service and I have to wait until the prmiary server goes up again to receive the missing log.
This is the rest of the log:
Fatal NI connect error 12543, connecting to:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=primary_db)(CID=(PROGRAM=oracle)(HOST=node2.localdomain)(USER=oracle))))
VERSION INFORMATION:
        TNS for Linux: Version 11.2.0.4.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
Time: 23-DEC-2013 17:13:52
Tracing not turned on.
Tns error struct:
    ns main err code: 12543
TNS-12543: TNS:destination host unreachable
    ns secondary err code: 12560
    nt main err code: 513
TNS-00513: Destination host unreachable
    nt secondary err code: 113
    nt OS err code: 0
Fatal NI connect error 12543, connecting to:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=primary_db)(CID=(PROGRAM=oracle)(HOST=node2.localdomain)(USER=oracle))))
VERSION INFORMATION:
        TNS for Linux: Version 11.2.0.4.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
Time: 23-DEC-2013 17:13:55
Tracing not turned on.
Tns error struct:
    ns main err code: 12543
TNS-12543: TNS:destination host unreachable
    ns secondary err code: 12560
    nt main err code: 513
TNS-00513: Destination host unreachable
    nt secondary err code: 113
    nt OS err code: 0
started logmerger process
Mon Dec 23 17:13:56 2013
Managed Standby Recovery starting Real Time Apply
MRP0: Background Media Recovery terminated with error 16157
Errors in file /u01/oracle/diag/rdbms/standby_db/primary_db/trace/primary_db_pr00_29230.trc:
ORA-16157: media recovery not allowed following successful FINISH recovery
Managed Standby Recovery not using Real Time Apply
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
         USING CURRENT LOGFILE DISCONNECT FROM SESSION
Recovery Slave PR00 previously exited with exception 16157
MRP0: Background Media Recovery process shutdown (primary_db)
Fatal NI connect error 12543, connecting to:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=primary_db)(CID=(PROGRAM=oracle)(HOST=node2.localdomain)(USER=oracle))))
VERSION INFORMATION:
        TNS for Linux: Version 11.2.0.4.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
Time: 23-DEC-2013 17:13:58
Tracing not turned on.
Tns error struct:
    ns main err code: 12543
TNS-12543: TNS:destination host unreachable
    ns secondary err code: 12560
    nt main err code: 513
TNS-00513: Destination host unreachable
    nt secondary err code: 113
    nt OS err code: 0
Mon Dec 23 17:14:01 2013
Fatal NI connect error 12543, connecting to:
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=node1)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=primary_db)(CID=(PROGRAM=oracle)(HOST=node2.localdomain)(USER=oracle))))
VERSION INFORMATION:
        TNS for Linux: Version 11.2.0.4.0 - Production
        TCP/IP NT Protocol Adapter for Linux: Version 11.2.0.4.0 - Production
Time: 23-DEC-2013 17:14:01
Tracing not turned on.
Tns error struct:
    ns main err code: 12543
TNS-12543: TNS:destination host unreachable
    ns secondary err code: 12560
    nt main err code: 513
TNS-00513: Destination host unreachable
    nt secondary err code: 113
    nt OS err code: 0
Error 12543 received logging on to the standby
FAL[client, ARC0]: Error 12543 connecting to primary_db for fetching gap sequence
Archiver process freed from errors. No longer stopped
Mon Dec 23 17:15:07 2013
Using STANDBY_ARCHIVE_DEST parameter default value as /u02/oracle/archivelogs/primary_db
Mon Dec 23 17:19:51 2013
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance primary_db - Archival Error
ORA-16014: log 4 sequence# 7 not archived, no available destinations
ORA-00312: online log 4 thread 1: '/u02/oracle/fast_recovery_area/standby_db/onlinelog/o1_mf_4_9c3tk3dy_.log'
Mon Dec 23 17:26:18 2013
RFS[1]: Assigned to RFS process 31456
RFS[1]: No connections allowed during/after terminal recovery.
Mon Dec 23 17:26:47 2013
flashback database to scn 15921680
ORA-16157 signalled during: flashback database to scn 15921680...
Mon Dec 23 17:27:05 2013
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (primary_db)
Mon Dec 23 17:27:05 2013
MRP0 started with pid=28, OS id=31481
MRP0: Background Managed Standby Recovery process started (primary_db)
started logmerger process
Mon Dec 23 17:27:10 2013
Managed Standby Recovery starting Real Time Apply
MRP0: Background Media Recovery terminated with error 16157
Errors in file /u01/oracle/diag/rdbms/standby_db/primary_db/trace/primary_db_pr00_31486.trc:
ORA-16157: media recovery not allowed following successful FINISH recovery
Managed Standby Recovery not using Real Time Apply
Completed: alter database recover managed standby database using current logfile disconnect
Recovery Slave PR00 previously exited with exception 16157
MRP0: Background Media Recovery process shutdown (primary_db)
Mon Dec 23 17:27:18 2013
RFS[2]: Assigned to RFS process 31492
RFS[2]: No connections allowed during/after terminal recovery.
Mon Dec 23 17:28:18 2013
RFS[3]: Assigned to RFS process 31614
RFS[3]: No connections allowed during/after terminal recovery.
Do you have any advice?
Thanks!
Alex.

Hello;
What's not clear to me in your question at this point:
What I'm NOT being able to perform:
If I manually unplug the network cables from the primary site (all the network, not only the link between primary and standby node so, it's like a server unplug from the energy source).
Same situation happens if I manually disconnect the server from the power.
This is the alert logs I have:"
Are you trying a failover to the Standby?
Please advise.
Is it possible your "valid_for clause" is set incorrectly?
Would also review this:
ORA-16014 and ORA-00312 Messages in Alert.log of Physical Standby
Best Regards
mseberg

How do i find dataloss in Data Guard?

We are using redo log, in async mode, following is our setting.
SERVICE=xxx_sb max_failure=100 reopen=600 LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=xxx_sb
When i query V$managed_Standby for delay_mins, its always zero. Meaning there is no delay in copying a log. I have 2 questions..
1. How can i communicate to business that in worst case we will lose x Mintues of data? Its an OLTP, where the transactions are less then 2mins. Also during the night there are some batch jobs where the transactions are 60mins longs.
2. Most of the time during peak hours there is a log switch happening every 10-15mins but during non-peak it may not happen for a long period of time, is it advisable to set ARCHIVE_LAG_TIME to 10 mins? as im not using archiver , we are using log writer for standby.
any explanation or point to documentation would be appreciated,
Thanks,

Production databases who are running with fully fined configured Data Guard, do'nt have any dataloss because failover operation ensures zero data loss if dataguard is configured with maximum protection mode or maximum availability mode at failover time.
http://www.dbazone.com/docs/oracle_10gDataGuard_overview.pdf
The above pdf is oracle white paper which too confirmed it.
LGWR SYNC AFFIRM in Oracle Data Guard is used for zero data loss. How does one ensure zero data loss? Well, the redo block generated at the primary has to reach the standby across the network (that's where the SYNC part comes in - i.e. it is a synchronous network call), and then the block has to be written on disk on the standby (that's where the AFFIRM part comes in) - typically on a standby redo log.
Can you have LGWR SYNC NOAFFIRM? Yes sure. Then you will have synchronous network transport, but the only thing you are guaranteed is that the block has reached the remote standby's memory. It has not been written on to disk yet. So not really a zero data loss solution (e.g. what if the standby instance crashes before the disk I/O).
To sum up -> LGWR SYNC AFFIRM means primary transaction commits are waiting for ntk I/O + disk I/O acks. LGWR SYNC NOAFFIRM means primary transaction commits are waiting for ntk I/O only.
Source:http://www.dbasupport.com/forums/showthread.php?t=54467
HTH
Girish Sharma

What is wrong with my Data Guard system?

What is wrong with my Data Guard system(10g10.2.0 on OEL5.0)? What method should I take to diagnose it and repair it?
After shutting down last night, my Data Guard does not run normally today.
On the primary database I issue the following commands:
DGMGRL> show configuration verbose;
Configuration
Name: sdb10g
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
sdb10g - Primary database
stdby10g - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 30 seconds
Observer: hostp
Current status for "sdb10g":
Warning: ORA-16607: one or more databases have failed
DGMGRL> show fast_start failover;
show fast_start failover;
Syntax error before or at "fast_start"
SQL> startup
ORACLE instance started.
Database mounted.
ORA-16649: database will open after Data Guard broker has evaluated Fast-Start
Failover status
On the physical standby database I issue the commands:
SQL> startup mount
ORACLE instance started.
Database mounted.
SQL> recover managed standby database disconnect;
Media recovery complete.
DGMGRL> show configuration verbose;
Configuration
Name: sdb10g
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: ENABLED
Databases:
sdb10g - Primary database
stdby10g - Physical standby database
- Fast-Start Failover target
Fast-Start Failover
Threshold: 30 seconds
Observer: hostp
Current status for "sdb10g":
Warning: ORA-16607: one or more databases have failed
DGMGRL> disable fast_start failover;
Error: ORA-01034: ORACLE not available
Failed.
Message was edited by:
frank.qian
null
null

The primary database cannot be opened and the fast_start failover cannot be discabled:
SQL> SQL> ALTER DATABASE open
ERROR at line 1:
ORA-16649: database will open after Data Guard broker has evaluated Fast-Start
Failover status
DGMGRL> disable fast_start failover;
Error: ORA-01034: ORACLE not available

Clarification on Data Guard(Physical Standyb db)

Hi guys,
I have been trying to setup up Data Guard with a physical standby database for the past few weeks and I think I have managed to setup it up and also perform a switchover. I have been reading a lot of websites and even Oracle Docs for this.
However I need clarification on the setup and whether or not it is working as expected.
My environment is Windows 32bit (Windows 2003)
Oracle 10.2.0.2 (Client/Server)
2 Physical machines
Here is what I have done.
Machine 1
1. Create a primary database using standard DBCA, hence the Oracle service(oradgp) and password file are also created along with the listener service.
2. Modify the pfile to include the following:-
oradgp.__db_cache_size=436207616
oradgp.__java_pool_size=4194304
oradgp.__large_pool_size=4194304
oradgp.__shared_pool_size=159383552
oradgp.__streams_pool_size=0
*.audit_file_dest='M:\oracle\product\10.2.0\admin\oradgp\adump'
*.background_dump_dest='M:\oracle\product\10.2.0\admin\oradgp\bdump'
*.compatible='10.2.0.3.0'
*.control_files='M:\oracle\product\10.2.0\oradata\oradgp\control01.ctl','M:\oracle\product\10.2.0\oradata\oradgp\control02.ctl','M:\oracle\product\10.2.0\oradata\oradgp\control03.ctl'
*.core_dump_dest='M:\oracle\product\10.2.0\admin\oradgp\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='oradgp'
*.db_recovery_file_dest='M:\oracle\product\10.2.0\flash_recovery_area'
*.db_recovery_file_dest_size=21474836480
*.fal_client='oradgp'
*.fal_server='oradgs'
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=E:\ArchLogs VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=oradgp'
*.log_archive_dest_2='SERVICE=oradgs LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=oradgs'
*.log_archive_format='ARC%S_%R.%T'
*.log_archive_max_processes=30
*.nls_territory='IRELAND'
*.open_cursors=300
*.pga_aggregate_target=203423744
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=612368384
*.standby_file_management='auto'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='M:\oracle\product\10.2.0\admin\oradgp\udump'
*.service_names=oradgp
The locations on the harddisk are all available and archived redo are created (e:\archlogs)
3. I then add the necessary (4) standby logs on primary.
4. To replicate the db on the machine 2(standby db), I did an RMAN backup as:-
RMAN> run
{allocate channel d1 type disk format='M:\DGBackup\stby_%U.bak';
backup database plus archivelog delete input;
5. I then copied over the standby~.bak files created from machine1 to machine2 to the same directory (M:\DBBackup) since I maintained the directory structure exactly the same between the 2 machines.
6. Then created a standby controlfile. (At this time the db was in open/write mode).
7. I then copied this standby ctl file to machine2 under the same directory structure (M:\oracle\product\10.2.0\oradata\oradgp) and replicated the same ctl file into 3 different files such as: CONTROL01.CTL, CONTROL02.CTL & CONTROL03.CTL
Machine2
8. I created an Oracle service called the same as primary (oradgp).
9. Created a listener also.
9. Set the Oracle Home & SID to the same name as primary (oradgp) <<<-- I am not sure about the sid one.
10. I then copied over the pfile from the primary to standby and created an spfile with this one.
It looks like this:-
oradgp.__db_cache_size=436207616
oradgp.__java_pool_size=4194304
oradgp.__large_pool_size=4194304
oradgp.__shared_pool_size=159383552
oradgp.__streams_pool_size=0
*.audit_file_dest='M:\oracle\product\10.2.0\admin\oradgp\adump'
*.background_dump_dest='M:\oracle\product\10.2.0\admin\oradgp\bdump'
*.compatible='10.2.0.3.0'
*.control_files='M:\oracle\product\10.2.0\oradata\oradgp\control01.ctl','M:\oracle\product\10.2.0\oradata\oradgp\control02.ctl','M:\oracle\product\10.2.0\oradata\oradgp\control03.ctl'
*.core_dump_dest='M:\oracle\product\10.2.0\admin\oradgp\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='oradgp'
*.db_recovery_file_dest='M:\oracle\product\10.2.0\flash_recovery_area'
*.db_recovery_file_dest_size=21474836480
*.fal_client='oradgs'
*.fal_server='oradgp'
*.job_queue_processes=10
*.log_archive_dest_1='LOCATION=E:\ArchLogs VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=oradgs'
*.log_archive_dest_2='SERVICE=oradgp LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=oradgp'
*.log_archive_format='ARC%S_%R.%T'
*.log_archive_max_processes=30
*.nls_territory='IRELAND'
*.open_cursors=300
*.pga_aggregate_target=203423744
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=612368384
*.standby_file_management='auto'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='M:\oracle\product\10.2.0\admin\oradgp\udump'
*.service_names=oradgs
log_file_name_convert='junk','junk'
11. User RMAN to restore the db as:-
RMAN> startup mount;
RMAN> restore database;
Then RMAN created the datafiles.
12. I then added the same number (4) of standby redo logs to machine2.
13. Also added a tempfile though the temp tablespace was created per the restore via RMAN, I think the actual file (temp01.dbf) didn't get created, so I manually created the tempfile.
14. Ensuring the listener and Oracle service were running and that the database on machine2 was in MOUNT mode, I then started the redo apply using:-
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
It seems to have started the redo apply as I've checked the alert log and noticed that the sequence# was all "YES" for applied.
****However I noticed that in the alert log the standby was complaining about the online REDO log not being present****
So copied over the REDO logs from the primary machine and placed them in the same directory structure of the standby.
########Q1. I understand that the standby database does not need online REDO Logs but why is it reporting in the alert log then??########
I wanted to enable realtime apply so, I cancelled the recover by :-
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
and issued:-
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
This too was successful and I noticed that the recovery mode is set to MANAGED REAL TIME APPLY.
Checked this via the primary database also and it too reported that the DEST_2 is in MANAGED REAL TIME APPLY.
Also performed a log swith on primary and it got transported to the standby and was applied (YES).
Also ensured that there are no gaps via some queries where no rows were returned.
15. I now wanted to perform a switchover, hence issued:-
Primary_SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
All the archivers stopped as expected.
16. Now on machine2:
Stdby_SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
17. On machine1:
Primary_Now_Standby_SQL>SHUTDOWN IMMEDIATE;
Primary_Now_Standby_SQL>STARTUP MOUNT;
Primary_Now_Standby_SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
17. On machine2:
Stdby_Now_Primary_SQL>ALTER DATABASE OPEN;
Checked by switching the logfile on the new primary and ensured that the standby received this logfile and was applied (YES).
However, here are my questions for clarifications:-
Q1. There is a question about ONLINE REDO LOGS within "#" characters.
Q2. Do you see me doing anything wrong in regards to naming the directory structures? Should I have renamed the dbname directory in the Oracle Home to oradgs rather than oradgp?
Q3. When I enabled real time apply does that mean, that I am not in 'MANAGED' mode anymore? Is there an un-managed mode also?
Q4. After the switchover, I have noticed that the MRP0 process is "APPLYING LOG" status to a sequence# which is not even the latest sequence# as per v$archived_log. By this I mean:-
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS,FROM V$MANAGED_STANDBY;
MRP0 APPLYING_LOG 1 47 452 1024000
but :
SQL> select max(sequence#) from v$archived_log;
46
Why is that? Also I have noticed that one of the sequence#s is NOT applied but the later ones are:-
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
42 NO
43 YES
44 YES
45 YES
46 YES
What could be the possible reasons why sequence# 42 didn't get applied but the others did?
After reading several documents I am confused at this stage because I have read that you can setup standby databases using 'standby' logs but is there another method without using standby logs?
Q5. The log switch isn't happening automatically on the primary database where I could see the whole process happening on it own, such as generation of a new logfile, that being transported to the standby and then being applied on the standby.
Could this be due to inactivity on the primary database as I am not doing anything on it?
Sorry if I have missed out something guys but I tried to put in as much detail as I remember...
Thank you very much in advance.
Regards,
Bharath
Edited by: Bharath3 on Jan 22, 2010 2:13 AM

Parameters:
Missing on the Primary:
DB_UNIQUE_NAME=oradgp
LOG_ARCHIVE_CONFIG=DG_CONFIG=(oradgp, oradgs)
Missing on the Standby:
DB_UNIQUE_NAME=oradgs
LOG_ARCHIVE_CONFIG=DG_CONFIG=(oradgp, oradgs)
You said: Also added a tempfile though the temp tablespace was created per the restore via RMAN, I think the actual file (temp01.dbf) didn't get created, so I manually created the tempfile.
RMAN should have also added the temp file. Note that as of 11g RMAN duplicate for standby will also add the standby redo log files at the standby if they already existed on the Primary when you took the backup.
You said: ****However I noticed that in the alert log the standby was complaining about the online REDO log not being present****
That is just the weird error that the RDBMS returns when the database tries to find the online redo log files. You see that at the start of the MRP because it tries to open them and if it gets the error it will manually create them based on their file definition in the controlfile combined with LOG_FILE_NAME_CONVERT if they are in a different place from the Primary.
Your questions (Q1 answered above):
You said: Q2. Do you see me doing anything wrong in regards to naming the directory structures? Should I have renamed the dbname directory in the Oracle Home to oradgs rather than oradgp?
Up to you. Not a requirement.
You said: Q3. When I enabled real time apply does that mean, that I am not in 'MANAGED' mode anymore? Is there an un-managed mode also?
You are always in MANAGED mode when you use the RECOVER MANAGED STANDBY DATABASE command. If you use manual recovery "RECOVER STANDBY DATABASE" (NOT RECOMMENDED EVER ON A STANDBY DATABASE) then you are effectively in 'non-managed' mode although we do not call it that.
You said: Q4. After the switchover, I have noticed that the MRP0 process is "APPLYING LOG" status to a sequence# which is not even the latest sequence# as per v$archived_log. By this I mean:-
Log 46 (in your example) is the last FULL and ARCHIVED log hence that is the latest one to show up in V$ARCHIVED_LOG as that is a list of fully archived log files. Sequence 47 is the one that is current in the Primary online redo log and also current in the standby's standby redo log and as you are using real time apply that is the one it is applying.
You said: What could be the possible reasons why sequence# 42 didn't get applied but the others did?
42 was probably a gap. Select the FAL columns as well and it will proably say 'YES' for FAL. We do not update the Primary's controlfile everytime we resolve a gap. Try the same command on the standby and you will see that 42 was indeed applied. Redo can never be applied out of order so the max(sequence#) from v$archived_log where applied = 'YES' will tell you that every sequence before that number has to have been applied.
You said: After reading several documents I am confused at this stage because I have read that you can setup standby databases using 'standby' logs but is there another method without using standby logs?
Yes, If you do not have standby redo log files on the standby then we write directly to an archive log. Which means potential large data loss at failover and no real time apply. That was the old 9i method for ARCH. Don't do that. Always have standby redo logs (SRL)
You said: Q5. The log switch isn't happening automatically on the primary database where I could see the whole process happening on it own, such as generation of a new logfile, that being transported to the standby and then being applied on the standby.
Could this be due to inactivity on the primary database as I am not doing anything on it?
Log switches on the Primary happen when the current log gets full, a log switch has not happened for the number of seconds you specified in the ARCHIVE_LAG_TARGET parameter or you say ALTER SYSTEM SWITCH LOGFILE (or the other methods for switching log files. The heartbeat redo will eventually fill up an online log file but it is about 13 bytes so you do the math on how long that would take :^)
You are shipping redo with ASYNC so we send the redo as it is commited, there is no wait for the log switch. And we are in real time apply so there is no wait for the log switch to apply that redo. In theroy you could create an online log file large enough to hold an entire day's worth of redo and never switch for the whole day and the standby would still be caught up with the primary.

Need suggestion on Active data guard or Logical Stand by

Hi All,
Need a suggestion of on below scenario.
We have a production database ( oracle version 11g R2 ) and planning to have a Logical standby or physical standy (Active data guard). Our usage of the standby database is below.
1) Planning to run online reports (100+) 24x7. So might create additional indexes,materialized views etc.
2) daily data feed ( around 300+ data files ) to data warehouse. daily night, jobs will be scheduled to extract data and send to warehouse. Might need additional tables for jobs usage.
Please suggest which one is good.
Regards,
vara.

Hello,
In active dataguad Whig is feature from 11gRx ,
If you choose active dataguard, you have couple of good options, one is you can make a high availability of your production database, which can act as image copy of production, as you are asking in 11g you have more advantage where you can open in read only mode and at the sometime MRP will be active, so you can redirect users to connect standby to perform select operations for reporting purpose. So that you can control much load on production ,
Even uou can perform switchover in case of role change, perform failover if your primary is completely lost. Also you can convert to physical to logical standby databases & you can configure FSFO
You have plenty of options with active dataguard.
Refer http://www.orafaq.com/node/957
consider closing the thread if answered and keep the forum clean.
>
User Profile for user11261773
user11261773
Handle:     user11261773
Status Level:     Newbie
Registered:     Jul 14, 2011
Total Posts:     12
Total Questions:     6 (5 unresolved)
>
Edited by: CKPT on Mar 18, 2012 8:14 PM

Use of Flashback Database in Data guard environments

11.2.0.3/RHEL 5.8
I've come across several docs which talk about configuring FLASHBACK DATABASE in dataguard environments. We have several
Physical standby DBs (Single Instance & RAC) running in our shop.I would like to know two or three major(common) use of FLASHBACK DATABASE in data guard environments.
I understood one use mentioned in the below URL ie. recovering from a logical mistake
http://uhesse.com/2010/08/06/using-flashback-in-a-data-guard-environment/
I would like to know what are the other major/common use of Flashback Database feauture in DataGuard environment

A couple of other uses:
1) You can use flashback to test your DR. So you can activate your standby. Test application/network connectivity and functionality on your DR site and when done revert this database back to a physical standby. You do however have to ensure that this is allowed in your environment. In some places I have worked this would be a big no no as there were zero data loss requirements. However some companies will allow this as long as the standby is back in place within a certain time period.
2) In the case that you have to do a failover for whatever reason, but then what was the primary site becomes available, you can flashback what was your primary to make it the standby rather than re-instatiating the database from scratch.
Eg. You have a power outage at your primary site so you perform a failover and your standby becomes the primary. Once what was your primary site is back online, you can convert your previous primary into a standby by doing a full back/restore (or whatever method you choose) to recreate your standby again. However you also have the option of using flashback on this database and then convert it into a standby as this would potentially be quicker than re-instantiating the standby.

Data Guard configuration for RAC database disappeared from Grid control

Primary Database Environment - Three node cluster
RAC Database 10.2.0.1.0
Linux Red Hat 4.0 2.6.9-22 64bit
ASM 10.2.0.1.0
Management Agent 10.2.0.2.0
Standby Database Environment - one Node database
Oracle Enterprise Edition 10.2.0.1.0 Single standby
Linux Red Hat 4.0 2.6.9-22 64bit
ASM 10.2.0.1.0
Management Agent 10.2.0.2.0
Grid Control 10.2.0.1.0 - Node separate from standby and cluster environments
Oracle 10.1.0.1.0
Grid Control 10.2.0.1.0
Red Hat 4.0 2.6.9-22 32bit
After adding a logical standby database through Grid Control for a RAC database, I noticed sometime later the Data Guard configuration disappeared from Grid Control. Not sure why but it is gone. I did notice that something went wrong with the standby creation but i did not get much feedback from Grid Control. The last thing I did was to view the configuration, see output below.
Initializing
Connected to instance qdcls0427:ELCDV3
Starting alert log monitor...
Updating Data Guard link on database homepage...
Data Protection Settings:
Protection mode : Maximum Performance
Log Transport Mode settings:
ELCDV.qdx.com: ARCH
ELXDV: ARCH
Checking standby redo log files.....OK
Checking Data Guard status
ELCDV.qdx.com : ORA-16809: multiple warnings detected for the database
ELXDV : Creation status unknown
Checking Inconsistent Properties
Checking agent status
ELCDV.qdx.com
qdcls0387.qdx.com ... OK
qdcls0388.qdx.com ... OK
qdcls0427.qdx.com ... OK
ELXDV ... WARNING: No credentials available for target ELXDV
Attempting agent ping ... OK
Switching log file 672.Done
WARNING: Skipping check for applied log on ELXDV : disabled
Processing completed.
Here are the steps followed to add the standby database in Grid Control
Maintenance tab
Setup and Manage Data Guard
Logged in as sys
Add standby database
Create a new logical standby database
Perform a live backup of the primary database
Specify backup directory for staging area
Specify standby database name and Oracle home location
Specify file location staging area on standby node
At the end am presented with a review of the selected options and then the standby database is created
Has any body come across a similar issue?
Thanks,

Any resolution on this?
I just created a Logical Standby database and I'm getting the same warning (WARNING: No credentials available for target ...) when I do a 'Verify Configuration' from the Data Guard page.
Everything else seems to be working fine. Logs are being applied, etc.
I can't figure out what credentials its looking for.

Still need to do full backup after using data guard?

In our system, there is a physical standby database in data guard configuration. Is there still a need to do full backup and incremental backup?

Jackliusr wrote:
In our system, there is a physical standby database in data guard configuration. Is there still a need to do full backup and incremental backup?Preferred to have full backup daily.
May be you can perform failover of your standby, in case there is no availability on primary database. Then do you think the standby system stability is same as primary and can give same performance?
standby location can be too far and this is only if in case of disaster.
Another case, lets suppose your standby is behind than primary for 4-5 days due to some issues. At the same time your production crashed then you may have chance to loose 4-5 days fo data. So recommended to have full backup always from primary database.
If you are checking stability of standby database daily and able to check your data by opening properly and you wont prefer to RMAN backup, Then it is fine. But it is highly recommended to have RMAN backup.
BTW, You can have RMAN full backup on standby, if you want to avoid resources to use on primary

Data Guard - Redo log files

Hi....
I have done data guard .......every thing is fine.......archives are bring transferred to standby..........
Also, during configuration, I had created standby redolog groups 4,5,6 and copied to standby.....
But in real time apply.......the standby is not using standby redolog groups 4,5,6........when i am query v$log it is showing group 1,2,3.
Actually, its should use standby redo log for maximum availability.
Please help....
Thanks in advance.

There was a similar question here just a few days ago:
Data Guard - redo log files

Data Guard no available

Similar Messages

Maybe you are looking for