11gR2 Real Time Apply / open read only

Hi,
I have a single instance primary database with a physical standby. The release is 11.2.0.1.0.
Max Availability mode
LGWR SYNC transport
Data Guard Broker configuration enabled
Both the primary and standby database are registered with the Grid Infrastructure (Standalone installation on each server, no cluster)
When I stop and start the standby database it seems to default to open read only using Managed Real Time Recovery.
SQL> SELECT DEST_ID, RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS
2> WHERE DEST_ID=2;
DEST_ID RECOVERY_MODE
2 MANAGED REAL TIME APPLY
I do not want to Active Data Guard on this particular database. So I removed and added the database again using srvctl this time supplying the -s mount flag. Now when I stop/start the standby it opens in mount mode and MANAGED recovery which is OK.
My question is why did the standby automatically get opened in read only. Is the a change in behaviour introduced along with Active Data Guard? Is the default behaviour for a database registered with Grid Infrastructure to simply start the database in open mode and becuase this is 11.2 standby this means open read only?
Thanks

Dear user234564,
This has been introduced in Oracle Database 11g Data Guard New Features and it is called the Active Data Guard. With the new release you can open the physical standby database in read only mode and the real time apply will continue as it is on the mount stage. This ability has not been granted on 10g. So i think it could be the normal behaviour.
11g physical standby database will be opened and the MRP process will still apply the archivelogs to the standby database. You can simply have it tested.
Please refer;
http://download.oracle.com/docs/cd/E11882_01/server.112/e10700/manage_ps.htm#CHDGJEFF
Let me give you a quick hint but it is off topic;
The number of standby databases that a primary database can support is increased from 9 to 30 in this release.
The capability to create 30 standby databases, combined with the functionality of the Oracle Active Data Guard option, allows the creation of reader farms that can be used to offload large scale read-only workloads from a production database.Hope That Helps.
Ogan

Similar Messages

How Real Time Apply works while physical standby is open in Read Only mode

Hi,
With Active data guard option, we can open physical standby DB in read only mode, while redo log are being applied. (Real Time Query)
Standby Redo log (SRL) enables Real Time Apply (with "USING CURRENT LOGFILE" clause in recover database command on standby DB)
I am interested to know, how Real Time Query works ?
What is the mechanism with allows us to open physical standby DB in read only mode while redo logs are being applied continuously ?
Regards,
Sujit

Dear user7419391,
That is a new feature in Oracle Database 11g. MRP can use the real time apply in 10g but the concept here is different.
Taken from the following document;
http://www.ascent.co.za/documents/oracle/Oracle%20databse%2011g%20Active-Data-Guard%20datasheet.pdf
*Unique Advantages of Oracle Active Data Guard*
+Active Data Guard is an evolution of Data Guard technology, providing unique+
+performance advantages while leveraging all other enhancements included in Oracle+
+Data Guard 11g. For example, any Data Guard 11g physical standby database can+
+be easily converted to a Snapshot Standby. A Snapshot Standby is open read-write+
+and is ideally suited as a test system, able to process transactions independent of the+
+primary database. A Snapshot Standby maintains protection by continuing to receive+
+data from the production database, archiving it for later use. When tests are+
+complete, a single command discards changes made while open read-write and+
+quickly resynchronizes the standby database with the primary.+
The other link in the previous post is excellent and you really have to read it to understand the active data guard aspects.
Regards.
Ogan

11gr2 Dataguard Active Standby - Unable to get Real-Time apply working

As above, I am unable to get real time apply to work WITHOUT it switching my standby back to MOUNT state. There does not seem to be anyting obvious from the broker, or alert logs.
On the Standby:
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database open read only;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
READ ONLY
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
MOUNTED
Primary:-
SQL> SELECT status, recovery_mode FROM v$archive_dest_status where dest_name = 'LOG_ARCHIVE_DEST_2';
STATUS RECOVERY_MODE
VALID MANAGED REAL TIME APPLY
Edited by: Imran on Apr 17, 2012 10:56 PM

Hello;
This is expected.
Works the same exact way on my system. How Redo Data is applied is set when the database is MOUNTED.
See - 6 Redo Apply Services
Data Guard Concepts and Administration 11g Release 2 (11.2) E10700-0
The document is vague on this at best, but think about the error you get if you try to start apply twice.
Data Guard Real-Time Apply FAQ [ID 828274.1]
Best Regards
mseberg
Edited by: mseberg on Apr 17, 2012 10:04 AM
h1. Test
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database open read only;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> select open_mode from v$database;
OPEN_MODE
READ ONLY WITH APPLY
SQL> So I get different results ??
Edited by: mseberg on Apr 17, 2012 10:40 AM
h2. Still more
I would like to change my answer. Based on my test and queries as shown below I believe REAL TIME apply is working. Note the last log says NO because its in progress.
Checking last sequence in v$archived_log
STANDBY               SEQUENCE# APPLIED    COMPLETIO
STANDBY                     343 YES        16-APR-12
STANDBY                     344 YES        16-APR-12
STANDBY                     345 YES        16-APR-12
STANDBY                     346 YES        16-APR-12
STANDBY                     347 YES        17-APR-12
STANDBY                     348 NO         17-APR-12
6 rows selected.
----------------Last log on Primary--------------------------------------|
MAX(SEQUENCE#)
           348
1 row selected.Yes, I doubled check and it works on mine. I guess I read what I wanted to read.
All my Standby redo are setup correctly ( size and numbers )
READ ONLY WITH APPLYYour answer my be the Uwe answer at the end of this thread :
Enabling the Active Dataguard and Real Time Apply
Best Regards
mseberg
Edited by: mseberg on Apr 17, 2012 10:50 AM

Real-time apply in Maximum Performance Mode Not Working

We have configured physical standby database in maximum performance mode. It's working perfectly fine. Archive logs are being applied to the physical standby.
We can open the DB in read-only mode, but real-time apply is not working. Physical standby database is lagging behind the primary db by an archive log. As soon as primary database generates an archive log, it's transported over to the standby and applied immediately by the media recovery process. But real-time redo is not working. Standby redo logs have been configured.
On Physcial Standby:
SQL> alter database recover managed standby database using current logfile disconnect ;
Database Altered.
SQL> select group#, DBID, status,first_time, last_time from v$standby_log ;
GROUP# DBID STATUS FIRST_TIM LAST_TIME
4 UNASSIGNED UNASSIGNED
5 UNASSIGNED UNASSIGNED
6 UNASSIGNED UNASSIGNED
7 UNASSIGNED UNASSIGNED
SQL> select * from v$dataguard_stats ;
NAME
VALUE
UNIT TIME_COMPUTED
apply lag
+00 00:31:36
day(2) to second(0) interval 22-JUN-2010 08:42:06
transport lag
+00 00:31:34
day(2) to second(0) interval 22-JUN-2010 08:42:06
As you could see from the output above, value of transport and apply lag is equal to the elapsed time since last archive log switch.
********* Standby init.ora
db_name = CPRD
db_unique_name = CPRDS
instance_name = CPRD
service_names = hrDBSBY.WORLD
log_archive_format = CPRD%r%s.%t
log_archive_dest_1 = "location=f:\orarch\hresysprod"
log_archive_dest_2='service=hresysprod async db_unique_name=cprd valid_for=(primary_role,online_logfile)'
log_archive_config='dg_config=(cprd,cprds)'
fal_server=hresysprod
fal_client=hresysprods
standby_file_management=auto
log_archive_trace=1
log_file_name_convert = ('hresysprod','hresysprods')
db_file_name_convert = ('hresysprod','hresysprods')
remote_login_passwordfile = exclusive
******* Primary init.ora
log_archive_config='dg_config=(cprd,cprds)'
fal_server=hresysprods
fal_client=hresysprod
standby_file_management=auto
log_archive_format = CPRD%r%s.%t
log_archive_dest_1 = "location=f:\orarch\hrESYSPROD"
log_archive_dest_2='service=hresysprods async db_unique_name=cprds valid_for=(primary_role,online_logfile)'
log_archive_trace=1
remote_login_passwordfile = exclusive
Please advise.
Thanks,
jay

Hi,
In your case you are using ARC process for redo transfer as you have not specified any process in log_archive_dest_2 and default is arch.
I will suggest you to use LGWR to transfer the redo to standby and also check the size of standby redo logs on standby is same to the size of online redo logs on primary
Regards
Anudeep

Standby database errors - Alter database open read only

alter database open read only
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Signalling error 1152 for datafile 1!
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Waiting for thread 1 sequence 216
Mon Dec 20 11:58:18 2010
Standby crash recovery need archive log for thread 1 sequence 216 to continue.
Please verify that primary database is transporting redo logs to the standby database.
Wait timeout: thread 1 sequence 216
Standby crash recovery aborted due to error 16016.
Errors in file /u01/app/oracle/diag/rdbms/mdm2/MDM2/trace/MDM2_ora_17442.trc:
ORA-16016: archived log for thread 1 sequence# 216 unavailable
Recovery interrupted!
Completed standby crash recovery.
Signalling error 1152 for datafile 1!
Errors in file /u01/app/oracle/diag/rdbms/mdm2/MDM2/trace/MDM2_ora_17442.trc:
ORA-10458: standby database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+MDMDG1/mdm2/datafile/system.280.738243341'
ORA-10458 signalled during: alter database open read only...
Mon Dec 20 12:13:46 2010
ALTER DATABASE RECOVER managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (MDM2)
Mon Dec 20 12:13:46 2010
MRP0 started with pid=23, OS id=18974
MRP0: Background Managed Standby Recovery process started (MDM2)
started logmerger process
Mon Dec 20 12:13:51 2010
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 216
Completed: ALTER DATABASE RECOVER managed standby database using current logfile disconnect
The above lines are from alert log of standby database.
Standby standbase
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+MDMDG1/mdm2/datafile/system.280.738243341'
Parameters set on primary are
log_archive_dest_1 LOCATION=+MDMDG3/MDM1/ARCH VALID_FOR=(ALL_LOGFILES,ALL_ROLE ) DB_UNIQUE_NAME=MDM1
log_archive_dest_state_1 ENABLE
log_archive_dest_2 SERVICE=MDM2 SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=MDM2
log_archive_dest_state_2 ENABLE
dg_broker_config_file1 +MDMDG2/mdm/dg_config/dgconfig1_mdm.dat
dg_broker_config_file2 +MDMDG2/mdm/dg_config/dgconfig2_mdm.dat
fal_server MDM2
standby_file_management AUTO
log_archive_config dg_config=(MDM1,MDM2)
db_file_name_convert MDM2, MDM1
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE availability ;
Standby pfile
*.archive_lag_target=900
*.audit_file_dest='/u01/app/oracle/admin/MDM2/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='+MDMDG1/MDM2/CONTROLFILE/controlfile01.ctl','+MDMDG2/MDM2/CONTROLFILE/controlfile02.ctl'
*.db_block_size=8192
*.db_create_file_dest='+MDMDG1'
*.db_domain=''
*.db_file_name_convert='MDM1','MDM2'
*.db_name='MDM'
*.db_recovery_file_dest='+MDMDG2'
*.db_recovery_file_dest_size=10485760000
*.db_unique_name='MDM2'
*.dg_broker_config_file1='+MDMDG2/MDM/DG_CONFIG/dgconfig1_MDM.dat'
*.dg_broker_config_file2='+MDMDG2/MDM/DG_CONFIG/dgconfig2_MDM.dat'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=MDM2XDB)'
*.fal_server='MDM11','MDM12'
*.instance_name='MDM2'
*.log_archive_config='dg_config=(MDM1,MDM2)'
*.log_archive_dest_1='LOCATION=+MDMDG3/MDM2/ARCH VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=MDM2'
*.log_archive_dest_2='SERVICE=MDM1 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=MDM1'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_format='MDM_%t_%s_%r.arc'
*.log_file_name_convert='MDM1','MDM2'
*.memory_target=838860800
*.nls_language='ENGLISH'
*.nls_territory='UNITED KINGDOM'
*.open_cursors=300
*.processes=500
*.remote_login_passwordfile='exclusive'
*.sessions=555
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'
On standby ASM
ASMCMD [+] > find * *
+MDMDG1/ASM/
+MDMDG1/ASM/ASMPARAMETERFILE/
+MDMDG1/ASM/ASMPARAMETERFILE/REGISTRY.253.737811541
+MDMDG1/MDM/
+MDMDG1/MDM2/
+MDMDG1/MDM2/CONTROLFILE/
+MDMDG1/MDM2/CONTROLFILE/controlfile01.ctl
+MDMDG1/MDM2/CONTROLFILE/current.265.738243333
+MDMDG1/MDM2/DATAFILE/
+MDMDG1/MDM2/DATAFILE/CANVAS_POPULARITY_DATA.264.738243343
+MDMDG1/MDM2/DATAFILE/CANVAS_POPULARITY_IDX.277.738243343
+MDMDG1/MDM2/DATAFILE/MDM_SRC_DATA.282.738243343
+MDMDG1/MDM2/DATAFILE/MDM_SRC_IDX.275.738243343
+MDMDG1/MDM2/DATAFILE/MIPS_MDM_DATA.283.738243341
+MDMDG1/MDM2/DATAFILE/MIPS_MDM_IDX.276.738243343
+MDMDG1/MDM2/DATAFILE/SYSAUX.281.738243341
+MDMDG1/MDM2/DATAFILE/SYSTEM.280.738243341
+MDMDG1/MDM2/DATAFILE/TEST_TBSP1.273.738243345
+MDMDG1/MDM2/DATAFILE/TEST_TBSP2.272.738243345
+MDMDG1/MDM2/DATAFILE/UNDOTBS1.256.738243343
+MDMDG1/MDM2/DATAFILE/UNDOTBS2.279.738243343
+MDMDG1/MDM2/DATAFILE/USERS.278.738243347
+MDMDG1/MDM2/ONLINELOG/
+MDMDG1/MDM2/ONLINELOG/group_1.259.738243429
+MDMDG1/MDM2/ONLINELOG/group_2.257.738243431
+MDMDG1/MDM2/ONLINELOG/group_21.284.738243505
+MDMDG1/MDM2/ONLINELOG/group_22.261.738243505
+MDMDG1/MDM2/ONLINELOG/group_23.274.738243505
+MDMDG1/MDM2/ONLINELOG/group_3.258.738243431
+MDMDG1/MDM2/ONLINELOG/group_31.262.738243513
+MDMDG1/MDM2/ONLINELOG/group_32.270.738243513
+MDMDG1/MDM2/ONLINELOG/group_33.263.738243513
+MDMDG1/MDM2/ONLINELOG/group_4.260.738243431
+MDMDG2/MDM/
+MDMDG2/MDM/DG_CONFIG/
+MDMDG2/MDM2/
+MDMDG2/MDM2/AUTOBACKUP/
+MDMDG2/MDM2/AUTOBACKUP/2010_12_20/
+MDMDG2/MDM2/AUTOBACKUP/2010_12_20/s_738242861.263.738244155
+MDMDG2/MDM2/CONTROLFILE/
+MDMDG2/MDM2/CONTROLFILE/controlfile02.ctl
+MDMDG2/MDM2/CONTROLFILE/current.271.738243335
+MDMDG2/MDM2/ONLINELOG/
+MDMDG2/MDM2/ONLINELOG/group_1.270.738243429
+MDMDG2/MDM2/ONLINELOG/group_2.269.738243431
+MDMDG2/MDM2/ONLINELOG/group_21.268.738243505
+MDMDG2/MDM2/ONLINELOG/group_22.272.738243505
+MDMDG2/MDM2/ONLINELOG/group_23.262.738243505
+MDMDG2/MDM2/ONLINELOG/group_3.273.738243431
+MDMDG2/MDM2/ONLINELOG/group_31.266.738243513
+MDMDG2/MDM2/ONLINELOG/group_32.265.738243513
+MDMDG2/MDM2/ONLINELOG/group_33.264.738243513
+MDMDG2/MDM2/ONLINELOG/group_4.261.738243431
+MDMDG3/MDM/
+MDMDG3/MDM/ARCH/
+MDMDG3/MDM2/
+MDMDG3/MDM2/ARCH/
-- Please can I know how to open read only standby database.

user5846399 wrote:
ORA-16016: archived log for thread 1 sequence# 216 unavailable
Recovery interrupted!archived log for thread 1 sequence# 216
This file is needed for recovery, Find it and move it to the standby database side.

Enabling the Active Dataguard and Real Time Apply

11.2.0.2 on AIX
I gather that , to enable Active Dataguard, you need to execute
STARTUP ; ----not startup mount
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;The above commands will enable both Active Dataguard (Real Time QUERY) and Real Time Apply. Right?
To enable just 'Real Time Apply' , I need to
startup mount
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;Am I right ?
Question on 'WITH SESSION SHUTDOWN' clause
While googling I've come across the following variant with an additonal 'WITH SESSION SHUTDOWN' clause
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE WITH SESSION SHUTDOWN;What difference does this clause bring ?
Is this claused used to enable Active Dataguard feature or 'Real Time Apply' or both ?

I gather that , to enable Active Dataguard, you need to execute
STARTUP ; ----not startup mount
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
The above commands will enable both Active Dataguard (Real Time QUERY) and Real Time Apply. Right? Yes, It will be in both recovery / realtime + Read only mode, Also you can use
To enable just 'Real Time Apply' , I need to
startup mount
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;Am I right ?Yes. It will be in just recovery/real time mode.
Question on 'WITH SESSION SHUTDOWN' clause
While googling I've come across the following variant with an additonal 'WITH SESSION SHUTDOWN' clause
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE WITH SESSION SHUTDOWN;What difference does this clause bring ?
Is this claused used to enable Active Dataguard feature or 'Real Time Apply' or both ?It has multiple options based on startup type
For this example check link of Julian Dyke.
http://juliandyke.wordpress.com/2010/10/14/oracle-11gr2-active-data-guard/

ORACLE 11G "real time apply" not work?????

we have a database original on ORACLE 10.2.0.4 and we upgrade it to 11.1.0.7.
after that we create standby database and tried to use "real time apply" feature.
Primary database can transfer log files to standby database and standby database also can apply logs. The problem is it can NOT work on "real time apply".
Ant ideal what wrong?
=== procedures ====== (standby database)
SQL> startup mount;
ORACLE instance started.
Total System Global Area 2087780352 bytes
Fixed Size 2161272 bytes
Variable Size 1795163528 bytes
Database Buffers 251658240 bytes
Redo Buffers 38797312 bytes
Database mounted.
SQL> alter database open read only;
Database altered.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> select PROTECTION_MODE, PROTECTION_LEVEL, DATABASE_ROLE, SWITCHOVER_STATUS, OPEN_MODE, GUARD_STATUS from v$database;
PROTECTION_MODE PROTECTION_LEVEL DATABASE_ROLE SWITCHOVER_STATUS
OPEN_MODE GUARD_S
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE PHYSICAL STANDBY NOT ALLOWED
MOUNTED NONE
SQL> select process, status from v$managed_standby;
PROCESS STATUS
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
ARCH CONNECTED
RFS IDLE
MRP0 APPLYING_LOG
6 rows selected.
========== Primary database init.ora file setup =====
### for DG use
db_unique_name = DBPMY
log_archive_config='dg_config=(DBPMY,DBSBY)'
log_archive_dest_1='LOCATION=/Archive/DBPMY/arch/arch MANDATORY'
log_archive_dest_2='service=DBSBY valid_for=(online_logfiles,primary_role) db_unique_name=DBSBY LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30'
*.log_archive_format='DBPMY_%r_%t_%s.arc'
log_archive_dest_state_1 = enable
log_archive_dest_state_2 = enable

There are a couple of things to look at.
1. Real time apply requires standby redo logs on the standby database. On the standby database run this query:
SELECT * FROM v$logfile where type = 'STANDBY';
if you get 0 rows back you'll need to create standby logfiles
The general guideline is to size them exactly like your redo logs but add one additional standby log to ensure it doesn't cause a bottleneck.
2. Get the size of your logfiles:
SELECT GROUP#, BYTES FROM V$LOG;
3. For example if you have 3 redo logs that are 50 MB in size, create 4 standby redo logs 50 MB each and don't multiplex them.
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog1.rdo') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog2.rdo') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog3.rdo') SIZE 50M;
ALTER DATABASE ADD STANDBY LOGFILE ('/Archive/DBSBY/onlinelog/slog4.rdo') SIZE 50M;
4. Cancel recovery on standby
recover managed standby database cancel;
5. Restart recovery using real time apply
recover managed standby database using current logfile disconnect;
6. To validate that real time is working you can check a few places.
-It will say in the database alert log on standby that it's using real time apply
OR
-Check primary
SELECT status, recovery_mode FROM v$archive_dest_status where dest_name = 'LOG_ARCHIVE_DEST_2';
If the recovery_mode is "MANAGED REAL TIME APPLY" then real time apply is working, if it's anything else then we'll need to check more things.
NOTE that if you are going to allow your current primary to switch roles and become a standby then you'll want to create standby redo logs on primary as well
Sometimes recovery gets "stuck" and simply resetting the destination parameters can resolve it:
alter system set log_archive_dest_2='service=DBSBY valid_for=(online_logfiles,primary_role) db_unique_name=DBSBY LGWR ASYNC=20480 OPTIONAL REOPEN=15 NET_TIMEOUT=30';
There are some other things we can check next but let's start with the easiest fixes first.

Real time apply

Hello
Oracle 10.2.0.1
I have dataguard configuration with standby file management auto and real time apply
SQL> SELECT DEST_ID, RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS
where dest_id=2;
DEST_ID RECOVERY_MODE
2 MANAGED REAL TIME APPLY1-) I create a table in primary database
2-) I cancel recovery in standy database (recover managed standby database cancel;)
3-) I open standby database in read only
Since real time apply is enabled why I cannot see my new created table in standby database?

Khurram;
When I change the protection mode, I got the below alerts, therefore I couldnt open the database:
LGWR: Primary database is in MAXIMUM PROTECTION mode
LGWR: Destination LOG_ARCHIVE_DEST_2 is not serviced by LGWR
LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
LGWR: Minimum of 1 LGWR standby database required
Mon Sep 28 20:19:15 2009
Errors in file /oracle/u01/admin/orclprod/bdump/orclprod_lgwr_29882.trc:
ORA-16072: a minimum of one standby database destination is required
Mon Sep 28 20:19:15 2009
Errors in file /oracle/u01/admin/orclprod/bdump/orclprod_lgwr_29882.trc:
ORA-16072: a minimum of one standby database destination is required
LGWR: terminating instance due to error 16072
Instance terminated by LGWR, pid = 29882

Redo apply Vs real time apply

Hi all ;
I have some confusion regarding redo apply Vs real time apply.
When applying redo data in standby site , how do we find whether it was done by redo apply or real time apply ?
Please discuss in detail. I need some clarification about this.
Thanks in advance ..

Hi baris ,
Thanks .. again little confusion. NO documents to find answer.
If a logical corruption occurs on your primary by a human mistake such as truncate table, wrong delete etc,
so a delayed standby is more appropriate. Furthermore you can configure flashback database feature
on your standby database when you use real time apply.
Is this possible ?
1) Do you mean flashback will be enabled only in standby database except primary database ?
What are the changes made in primary that only transfer to standby if so ,
2) How do we recover deleted objects in standby ?
FYI : I have a doubt with time delay option, we will discuss this things in new thread. please do NOT mind it.

Starting a Physical Standby DB which is configured with real-time apply

Hi,
I wanted to get clarification on the correct procedure for starting and stopping a physical standby database. The Dataguard documentation states the following:
1. Start and mount the database:
SQL> STARTUP MOUNT;
2. Start log apply services:
To start Redo Apply, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
To start real-time apply, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE;
My configuration is using real-time apply based on the information provided by the RECOVERY_MODE column of the V$ARCHIVED_DEST_STATUS view. Should I execute both ALTER statements or just the second one. If only the second one, how will the database re-synchronize, especially after a long down time. Also, must I do anything on the primary database prior to starting up the physical standby?
I'm using Oracle 10g SP1 on a linux server.

No. But you can recover until the last arch file generated on the primary, then you cancel the recovery and then use query#2 to start applying real-time. Refer to Note:343424.1 on Metalink.

Behaviour of v$standby_log; during real time apply...

hi,
i would like to understand the behaviour of this view, during REDO APPLY or real time apply using standby redo log configuration. as in my db, when there is a apply in progress i see the status column having value ACTIVE and DBID column has value of standby DBID where the apply is in progress and then status column goes to UNASSIGNED value and DBID column has no value inside it....i mean blank......why is this so? request you to please help me to understand this....following is the log
SQL> select * from v$standby_log;
GROUP# DBID THREAD# SEQUENCE# BYTES BLOCKSIZE USED ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME LAST_CHANGE# LAST_TIME
7 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
8 3903727333 1 58534 104857600 512 338944 YES ACTIVE 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12
9 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
10 3903727333 2 38929 104857600 512 235008 YES ACTIVE 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12
11 UNASSIGNED 2 0 104857600 512 0 NO UNASSIGNED
12 UNASSIGNED 2 0 104857600 512 0 NO UNASSIGNED
6 rows selected.
SQL> /
GROUP# DBID THREAD# SEQUENCE# BYTES BLOCKSIZE USED ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME LAST_CHANGE# LAST_TIME
7 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
8 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
9 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
10 UNASSIGNED 2 0 104857600 512 0 NO UNASSIGNED
11 UNASSIGNED 2 0 104857600 512 0 NO UNASSIGNED
12 3903727333 2 38931 104857600 512 5120 YES ACTIVE 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12

GROUP# DBID THREAD# SEQUENCE# BYTES BLOCKSIZE USED ARC STATUS FIRST_CHANGE# FIRST_TIM NEXT_CHANGE#
7 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
8 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
9 UNASSIGNED 1 0 104857600 512 0 NO UNASSIGNED
10 UNASSIGNED 2 0 104857600 512 0 NO UNASSIGNED
11 UNASSIGNED 2 0 104857600 512 0 NO UNASSIGNED
12 3903727333 2 38931 104857600 512 5120 YES ACTIVE 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12 2.3217E+10 05-JAN-12Here DBID would be same,
These standby redo log file groups can contain either of thread 1 or thread2, Multiple threads are used in RAC environment.
In general architecture, Once if any log switch (or) redo log is full then these will be dumped into archive log files, then it will assigned to new redo log files. Here in primary redo log file, you can see the status as Current, Active, Inactive so on.
During real time apply, whenever data written into primary redo log files, At the same time log writer will be active and that will be assigned to the one of the redo log file..not redo log file, you have to say standby redo log in standby database.
here unassigned means, this standby redo log file, can be used for next time, might earlier status as "active". Whenever standby redo log file is active then only DBID you can see.
If its in unassigned it will be idle, again if any new allocation then these will become active. its like chain/loop. It is very much normal behaviour.
UNASSIGNED - Online redo log has never been written to. This is the state of a redo log that was just added, or just after a RESETLOGS when it is not the current redo log.
ACTIVE - Log is active but is not the current log. It is needed for failure recovery. It may be in use for block recovery. It may or may not be archived.
HTH.

MS Access database opens read only

An Access application with linked databases opens read only, but sometimes is editable. The system was developed in Access 10 on a Win 7 machine and migrated to a standalone laptop running Win 8 and Office 365.
The Access 10 has no problem in operating the application. The Win 8 laptop randomly opens the application read only. I have reviewed Trust settings and there is no difference between the different laptops and systems.
Is this a common problem? Is it associated with Win 8? Is it associated with Access form Office 365? The application is crucial to the business and we are getting way behind because we don't have a reliable or useful system. Last year the same application
ran satisfactorily on Win 7 and Access 10.
I would welcome some thoughts leading too a solution.

Hi,
Did you get the error message like "You are trying to open a read-only database". If yes, this issue may be due to the permission of the Access database. If we migrate the Access database from Access 2010 to Access 2013, the user/account's permission
may be changed with different Windows operation system. We need the full control permission of the Access database. To workaround this issue, follow these steps:
On the desktop, double-click My Computer.
Locate the Microsoft Access database that you moved.
Right-click the database name, and then click Properties.
In the Properties dialog box, clear the Read-only check box under
Attributes.
Click OK to apply the change.
Open your database in Access.
Please note: Make sure the user has full control of the root folder.
If no, please tell us the whole error message, we'd like to do further troubleshooting.
Regards,
George Zhao
TechNet Community Support
It's recommended to download and install
Configuration Analyzer Tool (OffCAT), which is developed by Microsoft Support teams. Once the tool is installed, you can run it at any time to scan for hundreds of known issues in Office
programs.

Real-time apply cascaded logical standby database

Hi
I have a primary database orcl
Pysical standby database orcl_std
Cascaded logical standby database orcl_tri which receives archivelogs from orcl_std
Real time apply is enabled both in orcl_std (physical standby) and orcl_tri (logical standby)
When I create a table in primary orcl, I am unable to see it on orcl_tri (Although real time apply is enabled)
However, when I switch log in primary, I can see the new table on orcl_tri.
My question is, why realtime apply is not working in my scenerio ?
orcl_std : ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION USING CURRENT LOGFILE;
orcl_tri: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Oracle 11.2.0.3.0

Hi mseberg,
Thanks for your reply.
There is no load or network issue as I`ve just created these databases for the experiement.
I have the same output from standby and primary databases.
SQL> select bytes/1024/1024 from v$standby_log;
BYTES/1024/1024
             10
             10
             10I can see below output in standby alertlog
Fri Nov 16 08:39:51 2012
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
ALTER DATABASE START LOGICAL STANDBY APPLY (orcl)
with optional part
IMMEDIATE
Attempt to start background Logical Standby process
Fri Nov 16 08:39:51 2012
LSP0 started with pid=37, OS id=16141
Completed: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
LOGMINER: SpillScn 1953318, ResetLogScn 995548
LOGMINER: summary for session# = 1
LOGMINER: StartScn: 0 (0x0000.00000000)
LOGMINER: EndScn: 0 (0x0000.00000000)
LOGMINER: HighConsumedScn: 1955287 (0x0000.001dd5d7)
LOGMINER: session_flag: 0x1
LOGMINER: Read buffers: 16
Fri Nov 16 08:39:55 2012
LOGMINER: session#=1 (Logical_Standby$), reader MS00 pid=30 OS id=16145 sid=49 started
Fri Nov 16 08:39:55 2012
LOGMINER: session#=1 (Logical_Standby$), builder MS01 pid=39 OS id=16149 sid=44 started
Fri Nov 16 08:39:55 2012
LOGMINER: session#=1 (Logical_Standby$), preparer MS02 pid=40 OS id=16153 sid=50 started
LOGMINER: Turning ON Log Auto Delete
LOGMINER: Begin mining logfile during commit scan for session 1 thread 1 sequence 202, +DATA/orcl_std/archivelog/2012_11_15/thread_1_seq_202.349.799450179
LOGMINER: End mining logfiles during commit scan for session 1
LOGMINER: Turning ON Log Auto Delete
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 202, +DATA/orcl_std/archivelog/2012_11_15/thread_1_seq_202.349.799450179
LOGMINER: End   mining logfile for session 1 thread 1 sequence 202, +DATA/orcl_std/archivelog/2012_11_15/thread_1_seq_202.349.799450179
Fri Nov 16 08:40:04 2012
LOGSTDBY Analyzer process AS00 started with server id=0 pid=41 OS id=16162
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS03 started with server id=3 pid=45 OS id=16175
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS04 started with server id=4 pid=46 OS id=16179
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS01 started with server id=1 pid=42 OS id=16167
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS05 started with server id=5 pid=47 OS id=16183
Fri Nov 16 08:40:05 2012
LOGSTDBY Apply process AS02 started with server id=2 pid=44 OS id=16171Do you think real-time apply wasnt setup properly ?

When to use Real Time Apply for Logical standby..!!

Hello All,
I have been trying many ways to speed up the archival on primary and improve sql apply on logical standby, but still we are getting about 45-50 mins of delay between primary and logical standby.
We wanted to have our transactions applied on logical standby within couple minutes. Which i guess wont be possible in async mode.
That's why i am planning to implement Real Time apply between primary and logical standby.
Now since both our databases are too far away from each other (Primary is in US and logical is in India) would it be recommended to implement real time apply in such scenario? And if implemented would it affect Primary DB Performance?
Also if there might be some packet loss or network hitch would Primary will try again and keep logical DB in Sync with Primary?
Any help or suggestions would be great.
Thanks.

yes, real time apply is recommended in your scenario.
however due to the geographical distance between your primary and standby; I would suggest to keep your standby in current mode - max performance ; ASYNC- itself. It would not affect the performace of the primary.
As long as you set the FAL parameters and configure tnsnames properly and ensure proper deletion policy for archivelog cleanup in primary ( so that it's not deleted before shipping if need be), you shouldn't find any problem with primary & standby synching.
Good Luck.
Cheers.

RMAN in active data guard with real time apply ON without a catalog DB

I would like to know whether I can take RMAN backups (both level 0 & incremental) in active data guard with real time apply ON without a catalog database. version is 11.2.0.3.2. Will it make difference in the control file of standby syncing with primary? Can I use these backups on primary to restore and recover the database(including control file backup)?

Thank you very much msberg. Could you please answer the below queries as well?
Should I cancel Real Time Apply before starting RMAN?
Will it make difference in the control file of standby syncing with primary? Is it possible to use these backups on primary to restore and recover the database(including control file backup)? If possible, how will I do that?

11gR2 Real Time Apply / open read only

Similar Messages

Maybe you are looking for