Logical standby apply won't apply logs

RDBMS Version: Oracle 10.2.0.2
Operating System and Version: Red Hat Enterprise Linux ES release 4
Error Number (if applicable):
Product (i.e. SQL*Loader, Import, etc.): Oracle Dataguard (Logical Standby)
Product Version:
Hi!!
I have problem logical standby apply won't apply logs.
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE HIGH_SCN
STATUS
COORDINATOR 288810
ORA-16116: no work available
READER 288810
ORA-16240: Waiting for logfile (thread# 1, sequence# 68)
BUILDER 288805
ORA-16116: no work available
TYPE HIGH_SCN
STATUS
PREPARER 288804
ORA-16116: no work available
ANALYZER 288805
ORA-16116: no work available
APPLIER 288805
ORA-16116: no work available
TYPE HIGH_SCN
STATUS
APPLIER
ORA-16116: no work available
APPLIER
ORA-16116: no work available
APPLIER
ORA-16116: no work available
TYPE HIGH_SCN
STATUS
APPLIER
ORA-16116: no work available
10 rows selected.
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, DICT_BEGIN, DICT_END FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TIM NEXT_TIME DIC DIC
66 11-JAN-07 11-JAN-07 YES YES
67 11-JAN-07 11-JAN-07 NO NO
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
NAME
VALUE
coordinator state
IDLE
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
288803 288809
INITPRIMARY.ORA
DB_NAME=primary
DB_UNIQUE_NAME=primary
REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE
service_names=primary
instance_name=primary
UNDO_RETENTION=3600
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standy)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/home/oracle/primary/arch1/
VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=primary'
LOG_ARCHIVE_DEST_2=
'SERVICE=standy LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=standy'
LOG_ARCHIVE_DEST_3=
'LOCATION=/home/oracle/primary/arch2/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=primary'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_MAX_PROCESSES=30
FAL_SERVER=standy
FAL_CLIENT=primary
DB_FILE_NAME_CONVERT='standy','primary'
LOG_FILE_NAME_CONVERT=
'/home/oracle/standy/oradata','home/oracle/primary/oradata'
STANDBY_FILE_MANAGEMENT=AUTO
INITSTANDY.ORA
db_name='standy'
DB_UNIQUE_NAME='standy'
REMOTE_LOGIN_PASSWORDFILE='EXCLUSIVE'
SERVICE_NAMES='standy'
LOG_ARCHIVE_CONFIG='DG_CONFIG=(primary,standy)'
DB_FILE_NAME_CONVERT='/home/oracle/primary/oradata','/home/oracle/standy/oradata'
LOG_FILE_NAME_CONVERT=
'/home/oracle/primary/oradata','/home/oracle/standy/oradata'
LOG_ARCHIVE_FORMAT=%t_%s_%r.arc
LOG_ARCHIVE_DEST_1=
'LOCATION=/home/oracle/standy/arc/
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=standy'
LOG_ARCHIVE_DEST_2=
'SERVICE=primary LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=primary'
LOG_ARCHIVE_DEST_3=
'LOCATION=/home/oracle/standy/arch2/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=standy'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
STANDBY_FILE_MANAGEMENT=AUTO
FAL_SERVER=primary
FAL_CLIENT=standy
Alert Log Banco "Standy" desde a inicialização do SQL Apply
Thu Jan 11 15:00:54 2007
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
Thu Jan 11 15:01:00 2007
alter database add supplemental log data (primary key, unique index) columns
Thu Jan 11 15:01:00 2007
SUPLOG: Updated supplemental logging attributes at scn = 289537
SUPLOG: minimal = ON, primary key = ON
SUPLOG: unique = ON, foreign key = OFF, all column = OFF
Completed: alter database add supplemental log data (primary key, unique index) columns
LOGSTDBY: Unable to register recovery logfiles, will resend
Thu Jan 11 15:01:04 2007
LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
Thu Jan 11 15:01:04 2007
LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
Thu Jan 11 15:01:04 2007
ALTER DATABASE START LOGICAL STANDBY APPLY (standy)
with optional part
IMMEDIATE
Attempt to start background Logical Standby process
LSP0 started with pid=21, OS id=12165
Thu Jan 11 15:01:05 2007
LOGSTDBY Parameter: DISABLE_APPLY_DELAY =
LOGSTDBY Parameter: REAL_TIME =
Completed: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
Thu Jan 11 15:01:07 2007
LOGSTDBY status: ORA-16111: log mining and apply setting up
Thu Jan 11 15:01:07 2007
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
LOGMINER: session# = 1, reader process P000 started with pid=22 OS id=12167
LOGMINER: session# = 1, builder process P001 started with pid=23 OS id=12169
LOGMINER: session# = 1, preparer process P002 started with pid=24 OS id=12171
Thu Jan 11 15:01:17 2007
LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
Thu Jan 11 15:01:17 2007
LOGMINER: Turning ON Log Auto Delete
Thu Jan 11 15:01:26 2007
LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
Thu Jan 11 15:01:26 2007
LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
Thu Jan 11 15:01:26 2007
LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_ATTRCOL$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_CCOL$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_CDEF$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_COL$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_COLTYPE$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_ICOL$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_IND$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDCOMPART$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDPART$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_INDSUBPART$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_LOB$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_LOBFRAG$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_OBJ$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TAB$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABCOMPART$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABPART$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TABSUBPART$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TS$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_TYPE$ have been marked unusable
Thu Jan 11 15:01:33 2007
Some indexes or index [sub]partitions of table SYSTEM.LOGMNR_USER$ have been marked unusable
Thu Jan 11 15:02:05 2007
Indexes of table SYSTEM.LOGMNR_ATTRCOL$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_ATTRIBUTE$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_CCOL$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_CDEF$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_COL$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_COLTYPE$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_DICTIONARY$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_ICOL$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_IND$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_INDCOMPART$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_INDPART$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_INDSUBPART$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_LOB$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_LOBFRAG$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_OBJ$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_TAB$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_TABCOMPART$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_TABPART$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_TABSUBPART$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_TS$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_TYPE$ have been rebuilt and are now usable
Indexes of table SYSTEM.LOGMNR_USER$ have been rebuilt and are now usable
LSP2 started with pid=25, OS id=12180
LOGSTDBY Analyzer process P003 started with pid=26 OS id=12182
LOGSTDBY Apply process P008 started with pid=20 OS id=12192
LOGSTDBY Apply process P007 started with pid=30 OS id=12190
LOGSTDBY Apply process P005 started with pid=28 OS id=12186
LOGSTDBY Apply process P006 started with pid=29 OS id=12188
LOGSTDBY Apply process P004 started with pid=27 OS id=12184
Thu Jan 11 15:02:48 2007
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 12194
RFS[1]: Identified database type as 'logical standby'
Thu Jan 11 15:02:48 2007
RFS LogMiner: Client enabled and ready for notification
Thu Jan 11 15:02:49 2007
RFS LogMiner: RFS id [12194] assigned as thread [1] PING handler
Thu Jan 11 15:02:49 2007
LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
Thu Jan 11 15:02:49 2007
LOGMINER: Turning ON Log Auto Delete
Thu Jan 11 15:02:51 2007
LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_66_608031954.arc
Thu Jan 11 15:02:51 2007
LOGMINER: Begin mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
Thu Jan 11 15:02:51 2007
LOGMINER: End mining logfile: /home/oracle/standy/arch2/1_67_608031954.arc
Please, help me more time!!!!
Thanks.

Hello!
thank you for the reply.
The archive 1_68_608031954.arc that error of reading occurred, did not exist in the date of the error sees below:
$ ls -lh /home/oracle/standy/arch2/
total 108M
-rw-r----- 1 oracle oinstall 278K Jan 11 15:00 1_59_608031954.arc
-rw-r----- 1 oracle oinstall 76K Jan 11 15:00 1_60_608031954.arc
-rw-r----- 1 oracle oinstall 110K Jan 11 15:00 1_61_608031954.arc
-rw-r----- 1 oracle oinstall 1.0K Jan 11 15:00 1_62_608031954.arc
-rw-r----- 1 oracle oinstall 2.0K Jan 11 15:00 1_63_608031954.arc
-rw-r----- 1 oracle oinstall 96K Jan 11 15:00 1_64_608031954.arc
-rw-r----- 1 oracle oinstall 42K Jan 11 15:00 1_65_608031954.arc
-rw-r----- 1 oracle oinstall 96M Jan 13 06:10 1_68_608031954.arc
-rw-r----- 1 oracle oinstall 12M Jan 13 13:29 1_69_608031954.arc
$ ls -lh /home/oracle/primary/arch1/
total 112M
-rw-r----- 1 oracle oinstall 278K Jan 11 14:21 1_59_608031954.arc
-rw-r----- 1 oracle oinstall 76K Jan 11 14:33 1_60_608031954.arc
-rw-r----- 1 oracle oinstall 110K Jan 11 14:46 1_61_608031954.arc
-rw-r----- 1 oracle oinstall 1.0K Jan 11 14:46 1_62_608031954.arc
-rw-r----- 1 oracle oinstall 2.0K Jan 11 14:46 1_63_608031954.arc
-rw-r----- 1 oracle oinstall 96K Jan 11 14:55 1_64_608031954.arc
-rw-r----- 1 oracle oinstall 42K Jan 11 14:55 1_65_608031954.arc
-rw-r----- 1 oracle oinstall 4.2M Jan 11 14:56 1_66_608031954.arc
-rw-r----- 1 oracle oinstall 5.5K Jan 11 14:56 1_67_608031954.arc
-rw-r----- 1 oracle oinstall 96M Jan 13 06:09 1_68_608031954.arc
-rw-r----- 1 oracle oinstall 12M Jan 13 13:28 1_69_608031954.arc
Alert log
hu Jan 11 15:01:00 2007
SUPLOG: Updated supplemental logging attributes at scn = 289537
SUPLOG: minimal = ON, primary key = ON
SUPLOG: unique = ON, foreign key = OFF, all column = OFF
Completed: alter database add supplemental log data (primary key, unique index) columns
LOGSTDBY: Unable to register recovery logfiles, will resend
Thu Jan 11 15:01:04 2007
LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
Thu Jan 11 15:01:04 2007
LOGMINER: Error 308 encountered, failed to read missing logfile /home/oracle/standy/arch2/1_68_608031954.arc
You it would know as to help me?
Would be a BUG of the Oracle 10g?
Thanks.

Similar Messages

Logical standby stuck waiting for dictionary logs

Hello,
I created a logical standby (v. 10.2.0.3). It is in state 'WAITING FOR DICTIONARY LOGS', for a few days now.
Does anyone know how to get past this? It looks like the log that contained the Logminer Dictionary was applied
already.
Thanks in advance for any insight you can provide.

Make sure the archivelogs are reaching the standby. Check your alert logs on both databases to confirm there is no archival problem.

Standby db doesn't apply logs

hi all,
my problem is that none archive logs are actually applied to the standby database
Background Managed Standby Recovery process started
Starting datafile 1 recovery in thread 1 sequence 15536
Datafile 1: '/oracle/ean1/database/data/EAN1_SYSTEM01.dbf'
Starting datafile 2 recovery in thread 1 sequence 15536
Datafile 2: '/oracle/ean1/database/data/EAN1_UNDO01.dbf'
Starting datafile 3 recovery in thread 1 sequence 15536
Datafile 3: '/oracle/ean1/database/data/EAN1_D01_DATA01.dbf'
Starting datafile 4 recovery in thread 1 sequence 15536
Datafile 4: '/oracle/ean1/database/data/EAN1_I01_DATA01.dbf'
Thu Sep 7 15:36:12 2006
Completed: alter database recover managed standby database di
Thu Sep 7 15:36:12 2006
Media Recovery Waiting for thread 1 seq# 15536
the actual log file on the stdb is 15535 and on the prd-db 15549
can someone help me?

Due to some error archive gap occurred in your setup. V$ARCHIVE_GAP can help you. Copy the missing archive logs to standby database and register them as follows.
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE /disk1/oracle/dbs/log-1292880008_10.arc;
After you register these logs on the logical standby database, you can restart log apply services.
-aijaz

Logical Standby Apply Process Performance

Hello,
We are testing our logical standby database for sql apply process.We run batch jobs in our active database and monitor the standby database for the time it takes to bring the database in sync following are the steps we follow:
1) Insure active and standby are in sync.
2) Stop sql apply on standby database.
3) Run Batch job on active database.
4) After completion of the job on active,start sql apply on standby.
Following are the details of the time taken by sql apply,based on the previous runs:
1st. 654K volume = 4 hrs (2727 records per min)
2nd. 810K volume = 8 hrs 45 mins (1543 records per min)
3rd. 744K volume = 7 hrs 17 mins (1704 records per min)
Following are the details of the logical stdby parameters :
MAX_SGA 100
MAX_SERVERS 15
PREPARE_SERVERS 4
APPLY_SERVERS 8
MAX_EVENTS_RECORDED 10000
RECORD_SKIP_ERRORS TRUE
RECORD_SKIP_DDL TRUE
RECORD_APPLIED_DDL FALSE
RECORD_UNSUPPORTED_OPERATIONS FALSE
EVENT_LOG_DEST DEST_EVENTS_TABLE
LOG_AUTO_DELETE TRUE
LOG_AUTO_DEL_RETENTION_TARGET 1440
PRESERVE_COMMIT_ORDER TRUE
ALLOW_TRANSFORMATION FALSE
can we ensure SQL apply process to apply data in consistent volume,Is it okay for a sql apply process to take same amount of time what the actual batch takes in active instance,can we further tweak apply process to get better performance.
Please help.
Thank you !!

Following are the details of the time taken by sql apply,based on the previous runs:
1st. 654K volume = 4 hrs (2727 records per min)
2nd. 810K volume = 8 hrs 45 mins (1543 records per min)
3rd. 744K volume = 7 hrs 17 mins (1704 records per min)
Following are the details of the logical stdby parameters :
Hi,
By looking at the above apply rate, the apply process is working normally and not having issues.
Since it's a bulk batch data update in PRIMARY, it's obvious and quite normal that it will take time in STANDBY database to get applied and in sync with PRIMARY.
Still, if you need to consider improving the performance, look out for adjusting the APPLIER & PREPARER process. (parameteres, APPLY_SERVERS & PREPAR_SERVERS).

Logical Standby Scenario..!!

Hello,
We are having dataguard setup with Primary, Physical standby and Logical Standby databases located on three different machines..
Oracle Version : 10.2.0.1
OS : RHEL 4 on (x86 32-Bit)
Following are our initialization parameters for all the three instances..
Primary Database Parameters--_
*.db_unique_name='betapri'
*.fal_client='BETAPRI'
*.fal_server='BETAPHYSTDBY'
*.instance_name='oracle'
*.log_archive_config='DG_CONFIG=(betapri,betaphystdby,betalogstdby)'
*.log_archive_dest_1='LOCATION=/u01/app/oracle/archive/oracle VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=betapri MANDATORY'
*.log_archive_dest_2='SERVICE=BETAPHYSTDBY LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=betaphystdby'
*.log_archive_dest_3='SERVICE=BETALOGSTDBY LGWR SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=betalogstdby'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_dest_state_3='ENABLE'
*.standby_archive_dest='/u01/app/oracle/archive/oracle'
*.standby_file_management='AUTO'
*.remote_login_passwordfile='EXCLUSIVE'
Physical standby Database Parameters--_
*.db_unique_name='betaphystdby'
*.fal_client='BETAPHYSTDBY'
*.fal_server='BETAPRI'
*.instance_name='oracle'
*.log_archive_config='DG_CONFIG=(betapri,betaphystdby,betalogstdby)'
*.log_archive_dest_1='LOCATION=/u01/app/oracle/archive/oracle VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=betaphystdby'
*.log_archive_dest_2='SERVICE=BETAPRI LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=betapri'
*.log_archive_dest_3='SERVICE=BETALOGSTDBY VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=betalogstdby'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_dest_state_3='ENABLE'
*.standby_archive_dest='/u01/app/oracle/archive/oracle'
*.standby_file_management='AUTO'
*.remote_login_passwordfile='EXCLUSIVE'*Logical Standby Database Parameters *_
*.db_unique_name='betalogstdby'
*.instance_name='oracle'
*.log_archive_config='DG_CONFIG=(betapri,betaphystdby,betalogstdby)'
*.log_archive_dest_1='LOCATION=/u01/app/oracle/archive/betalogstdby VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=betalogstdby'
*.log_archive_dest_2='LOCATION=/u01/app/oracle/archive/oracle VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=betalogstdby'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.standby_archive_dest='/u01/app/oracle/archive/oracle'
*.standby_file_management='AUTO'
*.remote_login_passwordfile='EXCLUSIVE'Whole data guard setup is working properly as per the configuration.. But just for testing purpose i did FAILOVER_ and made our physical standby as new primary database and using Flashback i made my old primary as new physical standby and haven't made any changes to logical standby database since as per my init parameters i guess logical standby should remain in sync and keep applying the logs..
But performing this scenario logical standby seems to be messed up.. My new primay database does generate archives to logical standby but logical standby logmnr doesn't apply the changes to the database.. So once i issue "ALTER DATABASE START LOGICAL STANDBY APPLY" following message gets displayed in alert log *"Fatal Error: LogMiner processed beyond new branch scn."*
Tue Sep 29 18:55:14 2009
alter database start logical standby apply
Tue Sep 29 18:55:14 2009
ALTER DATABASE START LOGICAL STANDBY APPLY (oracle)
Tue Sep 29 18:55:14 2009
No optional part
Attempt to start background Logical Standby process
LSP0 started with pid=16, OS id=18308
LOGSTDBY status: ORA-16111: log mining and apply setting up
Tue Sep 29 18:55:14 2009
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
Tue Sep 29 18:55:14 2009
Fatal Error: LogMiner processed beyond new branch scn.
LOGSTDBY status: ORA-01346: LogMiner processed redo beyond specified reset log scn
Tue Sep 29 18:55:14 2009
Errors in file /u01/app/oracle/admin/oracle/bdump/oracle_lsp0_18308.trc:
ORA-01346: LogMiner processed redo beyond specified reset log scn
LOGSTDBY status: ORA-16222: automatic Logical Standby retry of last action
LOGSTDBY status: ORA-16111: log mining and apply setting up
Tue Sep 29 18:55:14 2009
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
Tue Sep 29 18:55:14 2009
Fatal Error: LogMiner processed beyond new branch scn.
LOGSTDBY status: ORA-01346: LogMiner processed redo beyond specified reset log scn
Tue Sep 29 18:55:14 2009
Errors in file /u01/app/oracle/admin/oracle/bdump/oracle_lsp0_18308.trc:
ORA-01346: LogMiner processed redo beyond specified reset log scn
Tue Sep 29 18:55:14 2009
ORA-16210 signalled during: alter database start logical standby apply... Note : I am having flashback enabled only on one database which was my old primary..
Please any comments, help or suggestions would be great..
Thanks - HP

Appreciate your kind reply Robert..
Would it be the only option left for me to re instantiate the logical standby..? Or what if i enable flashback on logical standby and then try to flashback till "standby_became_primary_scn" and then try to start logical standby apply.. Will this work in my scenario?
Any suggestions or comments are most welcome.
Thanks - HP

Refresh Schema in Primary (and Logical Standby)

Does anyone have a recommendation for the best way to refresh a 16Gb schema in a Primary Database that has a logical standby?
I attempted to refresh our main schema in our Primary by using IMPDP. I tried to follow the same steps as I would if I had to upgrade a Primary database with a Logical Standby in place. I defered the Log archive log dest state associated with the logical standby, stopped the SQL Apply on the standby and disabled Data Guard, then dropped the schema in the Standby, created and imported the schema. i then performed the drop, recreate and import in the Primary. After that I did a DBMS_LOGSTDBY.BUILD on the Primary. Finally I enabled DG, restarted the apply and enabled the log arch dest on the primary.
One issue I did have was that i did not defer the archivelogs until after the import had started so it did send some archives over - of course DG was disabled and the apply was off but now the status of DG is normal but i have a big gap in Last Received Log and Last Applied Log and of the missing archives, the oldest have 'Committed Transactions Applied', newer ones have 'Not Applied' and the newest have 'Not Received'.
I think I'm hosed but I am confused on the best approach. I did try just to perform the import on the Primary previously (last year) but I remember that the volume of data killed the replication.
This is 10.2.0.4 on Windows 2003 Server (64bit)
Thanks
Graeme

i suppossed that you did : alter database open resetlog; right?
In first place, try to see any error in redo transport:
alter system switch logfile;
select status, error from v$archive_dest where dest_id = 2;
any error?
for more information, please check:
http://www.idevelopment.info/data/Oracle/DBA_tips/Data_Guard/DG_45.shtml

Help! 10g logical standby not replicating "create table" on standby

Hi,
I'm setting up a logical standby environment and everything works, except when I tried to create a simple table on the primary, the table doesn't show up on the standby. I tried creating a new tablespace on the primary and it shows up right away on the standby. I checked the error logs on both primary and standby and no errors.
create table test1 (id number(10) primary key, col1 varchar(20), col2 varchar(20));
The table is created successfully on primary and I also inserted couple of rows and all committed.
I even tried the following query on the standby to check any failed events and the "create table" DDL doesn't show up , even if it failed:
select event_time, status, event from dba_logstdby_events order by event_timestamp, commit_scn
So I'm now confused. The logical standby is active and applying. What would be the issue? How do I find out ?
Thanks

had you started apply using this syntax
real time apply
alter database start logical standby apply immediate;
check lag:
alter session set nls_date_format='dd/mm hh24:mi';
select newest_time || chr(22)|| newest_scn||chr(10)||applied_time||chr(22)||applied_scn||chr(13)||chr(16)||(newest_scn-applied_scn) lag from dba_logstdby_progress
/

Why FRA filling faster in logical standby server.

I have two standby servers one physical and one logical for my primary database. I have notice that on logical standby server the FRA is filling faster then physical standby server. Any one have some suggestions.
Thx

>
I have two standby servers one physical and one logical for my primary database. I have notice that on logical standby server the FRA is filling faster then physical standby server. Any one have some suggestions.
>
That is to be expected, because the logical standby not only creates archive logs on behalf of the transmission from the primary but also generates its own archivelogs on behalf of the filling (& archiving) of the local online logfiles. If you watch a logical standby applying, you may notice that the standby logs are getting archived and the online logs as well. That is significant for a logical standby and leads to (at least temporary) higher space consumption in the recovery area. Temporary, because the applied archive logs can get deleted (automatically, if you allow that).
Kind regards
Uwe
http://uhesse.wordpress.com

Problem while mining archivelog in Logical Standby Database

I have configure Data Guard with one Primary database, one physical standby and one logical standby database; redo are applied correcly on the physical standby database but on the logical standby database when logminer begin mining logfile it encounter this errors :
ORA-00600 internal error code, arguments : [kpotcgah-7],[64],[X4],[],[],[],[],[]
ORA-12801 error signaled in parallel query server P003
ORA-07445
ORA-12805 parallel query server died unexpectedly

Unfortunately ORA-00600 errors are beyond the scope ot this forum, as they require tools and source code available only at Oracle Support. The only directions you most probably will get here is to issue a Service Request. Oracle support will, among other things, ask you if you are at the latest available patch for your platform.
Good luck.

How to skip delete on logical standby

Dear guys and gurus,
On next month i will have plan to delete history data on my Primary database, but i still want to keep them in logical standby as the data warehouse. So, how can i skip delete statement from primary database apply to logical standby.
Oracle SQL apply only support for Skip DML but not for keep delete statemen (on 10g and 11g)
SQL>exec dbms_logstdby.skip(statement => 'DELETE',schema_name => 'SCOTT', object_name => 'DEPT');
BEGIN dbms_logstdby.skip(statement => 'DELETE',schema_name => 'SCOTT', object_name => 'DEPT'); END;
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00306: wrong number or types of arguments in call to 'SKIP'
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
I do search and see one post about 3 years age about this question but still not answered.So, do you have any idea for this ???
So thanks and best regards.
Ch

You might want to play with this but here is an idea.
CREATE OR REPLACE PROCEDURE schema.handle_delete (
old_stmt IN VARCHAR2,
stmt_type IN VARCHAR2,
schema IN VARCHAR2,
name IN VARCHAR2,
xidusn IN NUMBER,
xidslt IN NUMBER,
xidsqn IN NUMBER,
error IN VARCHAR2,
new_stmt OUT VARCHAR2
) AS
BEGIN
-- Default to what we already have
new_stmt := old_stmt;
-- Ignore any GRANT errors on SYS or HR schemas
IF INSTR(UPPER(old_stmt),'DELETE') > 0
THEN
IF schema IS NULL
OR (schema IS NOT NULL AND
(UPPER(schema) = '<SCHEMA>' OR UPPER(SCHEMA) = '<SCHEMA>' )
THEN
new_stmt := NULL;
-- record the fact that we just skipped
END IF;
END IF;
END handle_delete;
Register the error handler with SQL Apply:
SQL> EXECUTE DBMS_LOGSTDBY.SKIP_ERROR ( -
statement => 'DML', -
schema_name => NULL, -
object_name => NULL, -
proc_name => 'SYS.HANDLE_DELETE');

Logical standby issue after adding a new user at production db server

Hello Experts,
I am facing a issue related to logical standby db server where after adding a new user at production db server logical standby has stopped sql apply. Can anybody give some idea to find out the root cause and give some tips to resolve the issue.
tried below .....
SELECT EVENT_TIME, STATUS, EVENT FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP, COMMIT_SCN, CURRENT_SCN;
got error
ORA-16227: DDL skipped due to missing object
ORA-01403: no data found
ORA-00942: table or view does not exist
OS : RHEL 4 (IBM P5)
DB : Oracle 10g (10.2.0.1)
Achyot

Please let me know if can skip the DDL at which it is failing.
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Use EXECUTE DBMS_LOGSTDBY.SKIP
ALTER DATABASE START LOGICAL STANDBY APPLY;
Thanks,
Renu

Logical Standby - Log Apply Error

Hi All
I have configured a 10.2.0.4 logical standby database (single instance) for RAC primary by LOG APPLY process stopped with this error:
ORA-01422: exact fetch returns more than requested number of rows.
Now I did run this command before creating logical standby: EXECUTE DBMS_LOGSTDBY.BUILD;
And I know that there are 80 tables which cannot be uniquely identified, which is fine by business.
Could you someone please tell how can I deal with this problem.
Regards
Amit

I have configured a 10.2.0.4 logical standby database (single instance) for RAC primary by LOG APPLY process stopped with this error:
ORA-01422: exact fetch returns more than requested number of rows.
Now I did run this command before creating logical standby: EXECUTE DBMS_LOGSTDBY.BUILD;
And I know that there are 80 tables which cannot be uniquely identified, which is fine by business.
Could you someone please tell how can I deal with this problem. It looks like a Bug too, check this below note
*Bug 5889516 - Intermittently ORA-1422 logical standby errors [ID 5889516.8]*

10gR2 Logical Standby database not applying logs

No errors are appearing in the logs and I've started the apply process :ALTER DATABASE START LOGICAL STANDBY APPLY but when I query dba_logstdby_log, none of the logs for the last 4 days shows as applied and the first SCN is still listed as current. Any thoughts on where I should start looking?
the latest event in DBA_LOGSTDBY_EVENTS is the startup of the log mining and apply.
I do not have standby redo logs so I cannot do real time apply, though I am looking to implementing this. Obviously, this is pretty new to me.

Sorry I didn't mention this before, the logs are being transferred, I verified their location on the os and it matches the location in the dba_logstdby_log view.

Controlling "Log apply" on Logical standby.

Hi,
We are going Live with logical standby ina day or two, and suddenly found what seems to be a potential problem in the near future.
Despite issuing the command
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;Logs are not getting applied immediately. Each of the logfile is taking somewhere around 5 to 10 minutes. That, was considered not so serious a problem. But sometimes, we find that there are too many logfiles left behind, and it is taking more than a day to get applied. I don't know how to prevent such a situation. I don't know how to get them all applied if at all such situation arises.
DB Version: 10.2.0.4
O/S: RHEL 4
Logfile size: 50M
Please help. I will be prepared with all documents to face this situation.
Aswin.
Edited by: ice_cold_aswin on May 6, 2010 7:12 PM

In Logical Standby the redo generated on the primary is converted to SQL and applied at the Logical Standby DB.
Check the network to see if there is any latency. And also check the views like v$system_event to get an overview of the wait events on the Primary DB.
Once refer to the docs for the Logical Standby Wait events.
Edited by: user8710159 on May 6, 2010 10:15 AM

Logical standby stuck at initializing SQL apply only coordinator process up

Hi
OS: solaris 5.10
Hardware: sun sparc
Oracle database: 11.2.0.1.0
Primary database name: asadmin
Standby database name: test
I had been trying to convert a physical standby to logical standby database. Both the primary and standby reside on the same machine.
The physical standby was created with a hot backup of primary.
I had been following document id 278371.1 to convert the physical to logical standby and used the following steps:
Relevant init parameters on primary:
*.db_name='asadmin'
*.db_unique_name='asadmin'
*.log_archive_config='dg_config=(asadmin,test)'
*.log_archive_dest_1='location=/u01/asadmin/archive valid_for=(all_logfiles,all_roles) db_unique_name=asadmin'
*.log_archive_dest_2='SERVICE=test async valid_for=(online_logfiles,primary_role) db_unique_name=test'
*.log_archive_dest_state_1='enable'
*.log_archive_dest_state_2='enable'
*.fal_client='asadmin'
*.fal_server='test'
*.remote_login_passwordfile='EXCLUSIVE'
Relevant init parameters on standby database:
*.db_name='test' -- Was asadmin before I renamed the DB during conversion to logical standby
*.db_unique_name='test'
*.log_archive_dest_1='location=/u01/test/archive valid_for=(all_logfiles,all_roles) db_unique_name=test'
*.log_archive_dest_2='service=asadmin async valid_for=(online_logfiles,primary_role) db_unique_name=asadmin'
*.log_archive_dest_state_1=enable
*.log_archive_dest_state_2=defer
*.remote_login_passwordfile='EXCLUSIVE'*.fal_server=test
*.fal_client=asadmin
Steps on primary:
1) alter system set log_archive_dest_state_2=defer;
2) shutdown immediate;
3) Made sure that the physical standby has applied all of the redo sent to it following the shutdown.
4) startup mount;
5) ALTER DATABASE BACKUP CONTROLFILE to '/home/oracle/control01.ctl';
6) ALTER SYSTEM ENABLE RESTRICTED SESSION;
7) ALTER DATABASE OPEN;
8) Verified that the supplemental logging is on.
9) ALTER SYSTEM ARCHIVE LOG CURRENT;
10) Checked for the checkpoint change no. at this point which is 72403818 and is present in archive log file 1_62_775102253.dbf
11) EXECUTE DBMS_LOGSTDBY.BUILD;
12) ALTER SYSTEM ARCHIVE LOG CURRENT;
13) Checked for the archive log containing dictionary build which is 1_64_775102253.dbf
14) ALTER SYSTEM DISABLE RESTRICTED SESSION;
Details of archive logs and related checkpoint change nos:
NAME FIRST_CHANGE# NEXT_CHANGE#
/u01/asadmin/archive/1_61_775102253.dbf 72402901 72403817
/u01/asadmin/archive/1_62_775102253.dbf 72403817 72404069
/u01/asadmin/archive/1_63_775102253.dbf 72404069 72404211
/u01/asadmin/archive/1_64_775102253.dbf 72404211 72405700
Steps on standby:
1) shutdown immediate;
2) Copy the archivelog file 61(was created at primary after apply stopped at standby), 62(contains checkpoint no. 72403818), 63 and 64(contains dictionary build). Copy the backup controlfile from step 5 above to the controlfile location in standby init.
3) startup mount;
4) Rename all datafiles and redo log files (including standby redo log files) to the correct path on standby.
5) alter database recover automatic from '/u01/test/archive' until change 72405700 using backup controlfile; -- This completed error-free
6) alter database guard all; -- this completed error free
7) alter database open resetlogs; -- this completed error free.
8) nid target=sys/oracle12 dbname=test
9) Changed the db_name in init file to new name test.
10) Added a tempfile to temp tablespaces.
11) ALTER DATABASE REGISTER LOGICAL LOGFILE '/u01/test/archive/1_61_775102253.dbf'; -- ORA-16225: Missing LogMiner session name for Streams
12) ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL 72405700; -- This completed error free.
Also enabled the log_archive_dest_state_2 on primary.
After this output from some views:
SQL> SELECT SESSION_ID, STATE FROM V$LOGSTDBY_STATE;
SESSION_ID STATE
1 INITIALIZING
SQL> SELECT SID, SERIAL#, SPID, TYPE FROM V$LOGSTDBY_PROCESS;
SID SERIAL# SPID TYPE
587 22 15476 COORDINATOR
SELECT PERCENT_DONE, COMMAND
FROM V$LOGMNR_DICTIONARY_LOAD
WHERE SESSION_ID = (SELECT SESSION_ID FROM V$LOGSTDBY_STATE);
PERCENT_DONE
COMMAND
0
SQL> SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
COORDINATOR ORA-16111: log mining and apply setting up
SQL> SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN NEWEST_SCN
72405700 72411501
SELECT THREAD#, SEQUENCE#, FILE_NAME FROM DBA_LOGSTDBY_LOG L
WHERE NEXT_CHANGE# NOT IN
(SELECT FIRST_CHANGE# FROM DBA_LOGSTDBY_LOG WHERE L.THREAD# = THREAD#)
ORDER BY THREAD#,SEQUENCE#;
no rows selected
SQL> SELECT EVENT_TIME, STATUS, EVENT
FROM DBA_LOGSTDBY_EVENTS
ORDER BY EVENT_TIMESTAMP, COMMIT_SCN; 2 3
EVENT_TIME STATUS EVENT
14-FEB-12 02:00:50 ORA-16111: log mining and apply setting up
14-FEB-12 02:00:50 Apply LWM 72405699, HWM 72405699, SCN 72405699
14-FEB-12 02:20:11 ORA-16128: User initiated stop apply successfully
completed
14-FEB-12 02:20:39 ORA-16111: log mining and apply setting up
14-FEB-12 02:20:39 Apply LWM 72405699, HWM 72405699, SCN 72405699
14-FEB-12 02:54:15 ORA-16128: User initiated stop apply successfully
completed
14-FEB-12 02:57:38 ORA-16111: log mining and apply setting up
EVENT_TIME STATUS EVENT
14-FEB-12 02:57:38 Apply LWM 72405699, HWM 72405699, SCN 72405699
14-FEB-12 03:01:36 ORA-16128: User initiated stop apply successfully
completed
14-FEB-12 03:13:44 ORA-16111: log mining and apply setting up
14-FEB-12 03:13:44 Apply LWM 72405699, HWM 72405699, SCN 72405699
14-FEB-12 04:32:23 ORA-16128: User initiated stop apply successfully
completed
14-FEB-12 04:34:17 ORA-16111: log mining and apply setting up
14-FEB-12 04:34:17 Apply LWM 72405699, HWM 72405699, SCN 72405699
EVENT_TIME STATUS EVENT
14-FEB-12 04:36:16 ORA-16128: User initiated stop apply successfully
completed
14-FEB-12 04:36:21 ORA-16111: log mining and apply setting up
14-FEB-12 04:36:21 Apply LWM 72405699, HWM 72405699, SCN 72405699
14-FEB-12 05:15:22 ORA-16128: User initiated stop apply successfully
completed
14-FEB-12 05:15:29 ORA-16111: log mining and apply setting up
14-FEB-12 05:15:29 Apply LWM 72405699, HWM 72405699, SCN 72405699
I also greped for lsp and lcr processes and found that lsp is up but do not see any lcr.
The logs are getting transported to the archive destination on standby whenever they are archived on primary but are not getting applied to standby.
Also in case the standby is down while a log is generated on primary it is not automatically transported to standby once the standby is up, means gap resolution is also not working.
I see the following in alert log every time I try to restart the log apply, everything seems to be stuck at initialization.
ALTER DATABASE START LOGICAL STANDBY APPLY (test)
with optional part
IMMEDIATE
Attempt to start background Logical Standby process
Tue Feb 14 05:15:28 2012
LSP0 started with pid=28, OS id=23391
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 0, ResetLogScn 0
-- NOTHING AFTER THIS

Hello;
I noticed some of your parameters seem to be wrong.
fal_client - This is Obsolete in 11.2
You have db_name='test' on the Standby, it should be 'asadmin'
fal_server=test is set like this on the standby, it should be 'asadmin'
I might consider changing VALID_FOR to this :
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)Would review 4.2 Step-by-Step Instructions for Creating a Logical Standby Database of Oracle Document E10700-02
Document 278371.1 is showing its age in my humble opinion.
-----Wait on this until you fix your parameters----------------------
Try restarting the SQL Apply
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATEI don't see the parameter MAX_SERVERS, try setting it to 8 times the number of cores.
Use these statements to trouble shoot :
SELECT NAME, VALUE, UNIT FROM V$DATAGUARD_STATS;
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME LIKE ;TRANSACTIONS%';
SELECT COUNT(1) AS IDLE_PREPARERS FROM V$LOGSTDBY_PROCESS WHERE
TYPE = 'PREPERER' AND STATUS_CODE = 16166;Best Regards
mseberg
Edited by: mseberg on Feb 14, 2012 7:37 AM

Logical standby apply won't apply logs

Similar Messages

Maybe you are looking for