Logical Standby--coordinator state = 'IDLE'

Frienz,
DB-Version--10.2.0.4 (64-bit)
OS-Red Hat Enterprise Linux Server release 5.1 (Tikanga)(64-bit)
We have configured physical standby without any issue. While configuring logical standby on 10gr2(RHEL 5.1) and querying
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state'; the output is
NAME VALUE
coordinator state IDLE
But while creating a sample table for a user and switching the logfile, it's reflecting in standby db. Whereas while creating a sample table for sys user, it's not reflecting in standby db.
Is this a new behavior in 10g R2?
Can someone help me in this issue?
Both primary and standby is of same Oracle 10.2.0.4 version.
Thanks in Advance,
Raj
Message was edited by:
Bang

Hi there,
I ran into the same problem you did 6 months. There a document I found that mention about "sys" account. The change under "sys" which SQLPLUS won't reflect to the standby. Create a new user and try your test again.

Similar Messages

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.

[Logical Standby] Which table/SQL caused paging-out

We have a Primary-Logical DR configuration.
Recently, it has a problem with the logical: it's continuously paging out data from some transactions:
SELECT SUBSTR(name, 1, 40) AS NAME, SUBSTR(value,1,32) AS VALUE FROM GV$LOGSTDBY_STATS;
number of preparers     3
number of appliers     18
maximum SGA for LCR cache     4095
parallel servers in use     24
maximum events recorded     1000000
preserve commit order     TRUE
transaction consistency     FULL
record skip errors     Y
record skip DDL     Y
record applied DDL     N
record unsupported operations     Y
coordinator state     IDLE
transactions ready     7
transactions applied     0
coordinator uptime     9646
realtime logmining     Y
apply delay     0
Log Miner session ID     1
txns delivered to client     1068651
DML txns delivered     1017135
DDL txns delivered     15
CTAS txns delivered     0
Recursive txns delivered     51501
Rolled back txns seen     23463
LCRs delivered to client     11682189
bytes of redo processed     14475529508
bytes paged out     1482524624
seconds spent in pageout     8922
bytes checkpointed     0
seconds spent in checkpoint     0
bytes rolled back     7500032
seconds spent in rollback     90
seconds system is idle     0
SELECT SID, SERIAL#, SPID, TYPE, HIGH_SCN, STATUS_CODE, STATUS
FROM GV$LOGSTDBY_PROCESS
ORDER BY TYPE, SPID;
ANALYZER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
APPLIER     16116     ORA-16116: no work available
BUILDER     16243     ORA-16243: paging out 4752 bytes of memory to disk
COORDINATOR     16116     ORA-16116: no work available
PREPARER     16127     ORA-16127: stalled waiting for additional transactions to be applied
PREPARER     16127     ORA-16127: stalled waiting for additional transactions to be applied
PREPARER     16127     ORA-16127: stalled waiting for additional transactions to be applied
READER     16127     ORA-16127: stalled waiting for additional transactions to be applied
select xidusn, xidslt, xidsqn, count(*) from system.logmnr_spill$
group by xidusn, xidslt, xidsqn;
996     46     249     254
710     37     838     825
623     3     706     254
478     7     42564     254
765     38     649     824
42     6     415494     3729
264     35     4817     3738
How can we identify the table/SQL to skip & instantiate it later so the logical DB will not being lag far behind.
Thank you.

Hi,
Best way to find SQL is to mine the current archive log getting applied on standby and check for the SQL, you might not get the exact SQL, but you will get the object which is getting updated.
Or
You can use AWR report from logical standby of this time to find the update statement which is resource extensive.
There is no way to find the exact SQL on primary which is causing the issue on standby.
Regards
Anudeep

Bytes paged out Logical standby (urgent!!!!!)

Hi,
We are having a 3 node LOGICAL STANDBY RAC ,it is continuoulsly paging out bytes to disk.
SQl > select from v$logstdby_stats;*
NAME     VALUE
number of preparers     2
number of appliers     27
maximum SGA for LCR cache     3072
parallel servers in use     32
maximum events recorded     100
preserve commit order     FALSE
transaction consistency     NONE
record skip errors     Y
record skip DDL     Y
record applied DDL     N
record unsupported operations     N
coordinator state     IDLE
transactions ready     0
transactions applied     0
coordinator uptime     10848
realtime logmining     Y
apply delay     0
Log Miner session ID     1
txns delivered to client     3425760
DML txns delivered     3315152
DDL txns delivered     1072
CTAS txns delivered     153
Recursive txns delivered     109536
Rolled back txns seen     4226
LCRs delivered to client     20249373
bytes of redo processed     29038698292
bytes paged out     4482430016
seconds spent in pageout     8677
bytes checkpointed     0
seconds spent in checkpoint     0
bytes rolled back     0
seconds spent in rollback     7
seconds system is idle     0
SQL > SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE     HIGH_SCN     STATUS
COORDINATOR     61551734060     ORA-16116: no work available
READER     61551732712     ORA-16127: stalled waiting for additional transactions to be applied
BUILDER     61551732695     ORA-16243: paging out 607512 bytes of memory to disk
PREPARER     61551732695     ORA-16127: stalled waiting for additional transactions to be applied
PREPARER     61551732692     ORA-16127: stalled waiting for additional transactions to be applied
ANALYZER     61551732694     ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
APPLIER          ORA-16116: no work available
The main issue is LogMiner is busy mining 1 logfile(512mb) from last 6 hrs and the value of " bytes paged out" is continuoulsy increasing and many log switches are happening on the logical standby but still no new transactions are getting applied on logical standby .
we took an AWR report for the given period and found that no SQL were being fired upon...but still generatiing archives of 512mb each .
Database version :- 10.2.0.2 RAC
OS : Solaris 10
Kindly help me to resolve this issue?????????
Edited by: user8974795 on Sep 26, 2011 2:15 AM

Hi,
please execute the following steps:
1. Copy the partially corrupted file over from primary.
2. Re-register the logfile if needed.
alter database register or replace logical logfile 'xxxxxxxxxxxxx';
3. Restart Logical Apply

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 is in Normal State but it dosent apply any changes.

I had a Rac active data guard 11.2.0.3   and i converted it to logical standby database.
My soluition was same as this link : http://docs.oracle.com/cd/E11882_01/server.112/e41134/create_ls.htm#SBYDB4734
After that configuration was complete,
When i change for example 1 row in a table in primary server, it does'nt Apply in standby server .I have checked alert log file and i have not seen any error in alert logfile.
Primary parameter file:
*.db_name='KS'
*.db_unique_name='KS'
*.dg_broker_start=true
*.fal_client='KS'
*.fal_server='KSSTBY_standby'
*.log_archive_config='DG_CONFIG=(KS,ksstby)'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=KS'
*.log_archive_dest_2='SERVICE=KSSTBY_standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ksstby'
*.log_archive_dest_3='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=KS'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_dest_state_3='ENABLE'
*.log_archive_format='archive_%s_%t_%r'
*.log_file_name_convert='+DATA/KSSTBY','+DATA/KS','+fra/KSSTBY','+fra/KS'
*.db_file_name_convert='+DATA/KSSTBY','+DATA/KS'
*.standby_file_management='auto'
Logical standby parameter file:
*.db_name='KS'
*.db_unique_name='ksstby'
*.fal_client='ksstby'
*.fal_server='KS_primary'
*.log_archive_config='DG_CONFIG=(KS,ksstby)'
*.log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ksstby'
*.log_archive_dest_2='SERVICE=KS_primary LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=KS'
*.log_archive_dest_3='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=ksstby'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_dest_state_3='ENABLE'
*.log_archive_format='archive_%s_%t_%r'
*.log_file_name_convert='+DATA/KS','+DATA/KSSTBY','+fra/KS','+fra/KSSTBY'
*.db_file_name_convert='+DATA/KS','+DATA/KSSTBY'
*.standby_file_management='auto'
The Status of Standby server :
select sequence#,applied from dba_logstdby_log;
    SEQUENCE# APPLIED
1 5486 CURRENT
2 5487 CURRENT
3 5488 CURRENT
4 5489 NO
5 5490 NO
6 5491 NO
7 5492 NO
8 5493 NO
9 5494 NO
select * from v$logstdby_stats;
    NAME VALUE
1 logminer session id 1
2 number of preparers 1
3 number of appliers 5
4 server processes in use 9
5 maximum SGA for LCR cache (MB) 30
6 preserve commit order TRUE
7 transaction consistency FULL
8 coordinator state INITIALIZING
9 coordinator startup time 28-APR-15
select * from v$logstdby_state;
    PRIMARY_DBID SESSION_ID REALTIME_APPLY STATE
1 3130490787 1 Y APPLYING
Please help to me.

Start Firefox in <u>[[Safe Mode]]</u> to check if one of the extensions is causing the problem (switch to the DEFAULT theme: Tools > Add-ons > Appearance/Themes).
* Don't make any changes on the Safe mode start window.
* https://support.mozilla.com/kb/Safe+Mode
* [[Troubleshooting extensions and themes]]
In Firefox 4 [http://kb.mozillazine.org/Safe_mode Safe mode] disables extensions and disables hardware acceleration.
Check if there is an update available for your graphics display card driver.
* Tools > Options > Advanced > General > Browsing: "Use hardware acceleration when available"
In Firefox 4 you can use one of these to start in <u>[[Safe mode]]</u>:
* Help > Restart with Add-ons Disabled
* Hold down the Shift key while double clicking the Firefox desktop shortcut (Windows)

Logical Standby SQL Apply Using Incorrect Decode Statement

We are seeing statements erroring out on our logical standby that have been rewritten (presumably by sql apply) with decode statements that don't appear to be correct. For example, here is one of the rewritten statements.
update /*+ streams restrict_all_ref_cons */ "CADPROD"."OMS_SQL_STATEMENT" p
set *"APPLICATION"=decode(:1,'N',"APPLICATION",:2)*,
"STATEMENT"=dbms_reputil2.get_final_lob(:3,"STATEMENT",:4)
where (:5='N' or(1=1 and (:6='N' or(dbms_lob.compare(:7,"STATEMENT")=0)or(:7 is null and "STATEMENT" is null)))) and(:8="APPLICATION")
The problem comes in, we believe, with the attempt to write the value "APPLICATION" to the application column which is only a 10 character field. the value for the :1 bind variable is "N" and the value for :2 is null.
We see the following error on the logical standby:
ORA-00600: internal error code, arguments: [kgh_heap_sizes:ds], [0x01FCDBE60], [], [], [], [], [], []
ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [kxtoedu+54] [PC:0x2542308] [ADDR:0xFFFFFFFFFFFFFFFF] [UNABLE_TO_READ] []
ORA-12899: value too large for column "CADPROD"."OMS_SQL_STATEMENT"."APPLICATION" (actual: 19576, maximum: 10)
Is this a configuration issue or is it normal for SQL Apply to convert statements from logminer into decode statements?
We have an Oracle 10.2.0.4 database running on windows 2003 R2 64-bit os. We have 3 physical and 2 logical standby's, no problems on the physical standbys.

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

ORA-01403 - Logical Standby Apply ends on delete/update statement

- This thread is relocated to this forum; advice from Daniel Roy -
After implementing 2 logical standby databases and running pretty smooth for a while 'strange' errors occur which puzzle me. Sometimes I skip a transaction or exclude a schema from replication and hold my breath for what next roars its ugly head.
Despite fulfilling all logical standby prerequisites and maintaining primary keys on tables I now run into ORA-01403 errors. The updated table only contains 1 row and has a foreign key to another small table.
I could instantiate these tables, but I want to understand why these errors occur and prevent them form happing or learn how to resolve them best.
Anyone around who dealt with these matters and won?
I'm running this implementation with Oracle 9.2.0.7 on Tru64 51.b
I'm able to create the logical standby databases manually and with aid of the Data Guard Creation Wizard (EM10g 10.1).
Can anyone also help me out with refining the faulty transaction from e.g. V$LOGMNR_CONTENTS? (Without disrupting the data guard setup).
I've already retrieved redo info from archivelogs, but there must be an easy way.
Regards,
Erik

Any way for you to turn tracing on for the DB where you see this ORA-01403 error? We could then probably find out exactly what goes wrong. It's very hard for us to know exactly what might be wrong, since we don't know your exact setup (except for this table). Let me know if that's not possible, and I could construct a logical DB setup to test (even tho it would be on Windows, I don't have Tru64).
Daniel

Create Index statement doesnt propagate to Logical Standby

Hi,
We have a logical standby 10.2.0.3 for our primary database in 10.2.0.3. An index which was created in primary hasnt propagated to standby. The index cannot be seen in the standby . The index was not skipped or DML/DDLs on that particular table were not skipped as well. Any ideas about this behaviour ?

Was it created with nologging option?
Check for unrecoverable transactions:
set linesize 132
set pages 100
col name format a55
SELECT name, unrecoverable_change# FROM v$datafile;

Best practice on using Flashback and Logical Standby

Hello,
I'm testing a fail-back scenario where I first need to activate a logical standby, then do some dummy transactions before I flashback this db and resme the redo apply. Here is what the steps look like:
1)     Ensure logical standby is in-sync with primary
2)     Enable flashback on standby
3)     Create a flashback guaranteed restore point
4)     Defer log shipping from primary
5)     Activate the logical standby so it’s fully open to read-write
6)     Dummy activities against the standby (which is now fully open)
7)     Flashback the database to the guaranteed checkpoint
8)     Resume log shipping on primary
9)     Resume redo apply on secondary
In the end, i can see the log shipping is happening but the logical standby does not apply any of these..and there is no error in the alert log on Standby side. But the following query could explains why the standby is idle:
SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
COORDINATOR ORA-16240: Waiting for log file (thread# 2, sequence# 0)
ORA-16240: Waiting for log file (thread# string, sequence# string)
Cause: Process is idle waiting for additional log file to be available.
Action: No action necessary. This informational statement is provided to record the event for diagnostic purposes.
I dont understand why it's looking for sequence #0 after the flashback.
Thanks for the help.

Hello;
I hesitate to answer your question because you are not doing a good job of keeping the forum clean :
Total Questions: 13 (13 unresolved)
Please consider closing some of you old answered questions and rewarding those who helped you.
No action necessary.
Do you really have a thread 2? ( Redo thread number )
Quick check
select applied_scn,latest_scn from v$logstdby_progress;Use the DBA_LOGSTDBY_LOG View if you don't have a thread 2 then the sequence# is meaningless.
COLUMN DICT_BEGIN FORMAT A10;
SELECT FILE_NAME, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#,
TIMESTAMP, DICT_BEGIN, DICT_END, THREAD# AS THR# FROM DBA_LOGSTDBY_LOG
ORDER BY SEQUENCE#;Logical Standby questions are difficult, not a lot of them out there I'm thinking.
Check
http://docs.oracle.com/cd/E14072_01/server.112/e10700/manage_ls.htm
"Waiting On Gap State" ( However I still believe you don't have a 2nd thread# )
OR
http://psilt.wordpress.com/2009/04/29/simple-logical-standby/
Best Regards
mseberg
Edited by: mseberg on Apr 26, 2012 5:13 PM

Logical standby on 9i stalls

hello.
Has anyone ever seen this or knows how to resolve it?...
I created a logical standby database which works at the beginning. All ddl and dml gets propagated until I try a shutdown of the primary. When I bring back the primary, archive logs are still being sent correctly to standby, but standby stalls. SELECT APPLIED_SCN, NEWEST_SCN FROM DBA_LOGSTDBY_PROGRESS shows no progress for applied_scn.
CPU is at 100% by a one of the Parallel Query processes. I don't see any locks being held on any objects. looking at the v$sqlarea, the following query generates an enormous and constantly growing rows_processed also parse and execute requests are huge and growing as well. It seems that this process is stuck in an infinite loop running this query (I gave it 2 days - no change). This query is also at the bottom of the lsp trace log. I tried a different machine for a standby - same problem. couldn't find anything on metalink or any documentation.
thanks,
Henry
offending query:
ELECT C.SEGCOL#, C.INTCOL#, C.COLNAME, C.TYPE#, C.LENGTH, C.PRECISION,
C.SCALE, C.Interval_Leading_Precision,
C.Interval_Trailing_Precision, C.PROPERTY,
C.CHARSETID, C.CHARSETFORM
FROM SYSTEM.LOGMNRC_GTCS C
WHERE C.LOGMNR_UID = :Logminer_ID
AND C.OBJV# = :ObjVersion
AND C.OBJ# = :ObjNum
ORDER BY C.SEGCOL#
alert log:
Fri Dec 17 18:08:50 2004
WARNING: the following transaction makes no progress
WARNING: in the last 300 seconds for the given message!
WARNING: xid =
0x0008.012.00000283 cscn = 5835031, message# = 2, slavid = 1
lsp trace:
*** 2004-12-17 18:13:53.263
WARNING: the following transaction makes no progress
WARNING: in the last 300 seconds for the given message!
WARNING: xid = 0x0008.012.00000283 cscn = 5835031, message# = 2, slavid = 1
KNACDMP: *******************************************************
KNACDMP: Dumping apply coordinator's context at efffe9a8
KNACDMP: Apply Engine # 0
KNACDMP: Apply Engine name
KNACDMP: Coordinator's Watermarks ------------------------------
KNACDMP: Apply High Watermark = 0x0000.00590901
KNACDMP: Apply Low Watermark = 0x0000.00590901
KNACDMP: Fetch Low Watermark = 0x0000.00590934
KNACDMP: Oldest SCN = 0x0000.00590874
KNACDMP: Last replicant syncpoint SCN = 0x0000.00000000
KNACDMP: Last syncpoint at primary SCN = 0x0000.00590901
KNACDMP: First partition max SCN = 0x0000.005a89e7
KNACDMP: Last partition max SCN = 0x0000.005a89e7
KNACDMP: Last processed SCN = 0x0000.00590901
KNACDMP: Coordinator's constants -------------------------------
KNACDMP: number of apply slaves = 5
KNACDMP: safety level (K) = 1
KNACDMP: max txns in memory = 40000
KNACDMP: max constraints per table = 119
KNACDMP: hash table size (in entries) = 40000
KNACDMP: Coordinator's intervals -------------------------------
KNACDMP: syncpoint interval (ms) = 0
KNACDMP: write low watermark interval(ms)= 1
KNACDMP: Coordinator's timers/counters -------------------------
KNACDMP: current time = 1103336032
KNACDMP: low watermark timer = 0
KNACDMP: shutdown counter = 1
KNACDMP: syncpoint timer = 1103335430
KNACDMP: Coordinator's State/Flags -----------------------------
KNACDMP: Coordinator's State = KNACST_APPLY_UNTIL_END
KNACDMP: Coordinator's Flags = 4
KNACDMP: Slave counts ------------------------------------------
KNACDMP: number of reserved slaves = 0
KNACDMP: number of admin slaves = 0
KNACDMP: number of slaves in wait cmt = 3
KNACDMP: number of safe slaves = 4
KNACDMP: Slave Lists -------------------------------------------
KNACDMP: Dumping All Slaves :-
Slave id = 0, State = 8, Flags = 0, Not Assigned
Slave id = 1, State = 5, Flags = 1, Assigned Xid = 0x0008.012.00000283
Slave id = 2, State = 6, Flags = 3, Assigned Xid = 0x0009.003.0000028a
Slave id = 3, State = 6, Flags = 3, Assigned Xid = 0x0003.02d.0000028b
Slave id = 4, State = 7, Flags = 3, Assigned Xid = 0x0009.022.00000289
Slave id = 5, State = 0, Flags = 0, Not Assigned
KNACDMP: End dumping all slaves
KNACDMP: syncdep slaves = { 2 3 }
KNACDMP: cont chunk slaves = { }
KNACDMP: cont slaves = { }
KNACDMP: exec txn slaves = { }
KNACDMP:Idle slaves (1) ={ 5 }
KNACCPD: *******************************************************
v$lock information for this slave is:
type:PS, id1:1, id2:4, lmode:4, request:0
type:SR, id1:1, id2:0, lmode:4, request:0
Current SQL for this slave is:
SELECT C.SEGCOL#, C.INTCOL#, C.COLNAME, C.TYPE#, C.LENGTH, C.PRE
CISION, C.SCALE, C.Interval_Leading_Precision,
C.Interval_Trailing_Precision, C.PROPERTY, C.CHARSE
TID, C.CHARSETFORM FROM SYSTEM.LOGMNRC_GTCS C WHERE
C.LOGMNR_UID = :Logminer_ID AND C.OBJV# = :ObjVersio
n AND C.OBJ# = :ObjNum ORDER BY C.SEGC
OL#
KNACCPD: end ***************************************************

Check following doc for procedure to set up a logical standby database
Creating a Logical Standby Database

Logical standby: ORA-01031: insufficient privileges

Dear Colleagues,
Today in my Logical Standby don't apply archivelogs and I see an error in alert.log:
ORA-26808: Apply process AS01 died unexpectedly.
ORA-01031: insufficient privileges
Also I see next logs in trace files:
h4.
1)
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
ORACLE_HOME = /ora/Ora11203
System name: Linux
Node name: base
Release: 2.6.18-308.20.1.el5
Version: #1 SMP Tue Nov 6 04:38:29 EST 2012
Machine: x86_64
Instance name: oracle
Redo thread mounted by this instance: 1
Oracle process number: 43
Unix process pid: 16634, image: oracle@base (AS01)
*** 2013-04-04 16:58:47.062
*** SESSION ID:(146.16811) 2013-04-04 16:58:47.062
*** CLIENT ID:() 2013-04-04 16:58:47.062
*** SERVICE NAME:(SYS$USERS) 2013-04-04 16:58:47.062
*** MODULE NAME:(Streams) 2013-04-04 16:58:47.062
*** ACTION NAME:( - Apply Server) 2013-04-04 16:58:47.062
knasplcr: eager error was not rolled back
++ LCR Dump Begin: 0x2b0cf2a6d168 - ddl
op: 5, Original op: 5, baseobjn: 0, objn: 0, objv: 0
DF: 0x00000002, DF2: 0x00000010, MF: 0x00020810, MF2: 0x00000000
PF: 0x00000000, PF2: 0x08000000
MergeFlag: 0x00, FilterFlag: 0x00
Id: 0, iotPrimaryKeyCount: 0, numChgRec: 1
NumCrSpilled: 0
RedoThread#: 1, rba: 0x0213d7.00023455.01ac
scn: 0x0002.fc0f8769, (scn: 0x0000.00000000, scn_sqn: 0, lcr_sqn: 0)xid: 0x0019.00e.0007f8d9, parentxid: 0x0019.00e.0007f8d9, proxyxid: 0x0000.000.00000000
ncol: 0 newcount: 24, oldcount: 0
LUBA: 0x4.1000ad1.e.0.0
++ LCR Dump Begin: 0x59b1afdc8 - commit
op: 7, Original op: 7, baseobjn: 0, objn: 0, objv: 0
DF: 0x00000002, DF2: 0x00000010, MF: 0x00220000, MF2: 0x02000000
PF: 0x00100000, PF2: 0x08040000
MergeFlag: 0x03, FilterFlag: 0x00
Id: 3, iotPrimaryKeyCount: 0, numChgRec: 0
NumCrSpilled: 0
RedoThread#: 1, rba: 0x0213d7.00023456.0108
scn: 0x0002.fc0f876b, (scn: 0x0002.fc0f876b, scn_sqn: 1, lcr_sqn: 1)xid: 0x0019.00e.0007f8d9, parentxid: 0x0019.00e.0007f8d9, proxyxid: 0x0000.000.00000000
ncol: 0 newcount: 0, oldcount: 0
LUBA: 0x4.1000ad1.e.0.0
Apply Slave is exiting due to error ORA-1031KSV 1031 error in slave process
*** 2013-04-04 16:58:47.067
ORA-01031: insufficient privileges
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-01031: insufficient privileges
h4.
2)
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Data Mining and Real Application Testing options
ORACLE_HOME = /ora/Ora11203
System name: Linux
Node name: base
Release: 2.6.18-308.20.1.el5
Version: #1 SMP Tue Nov 6 04:38:29 EST 2012
Machine: x86_64
Instance name: oracle
Redo thread mounted by this instance: 1
Oracle process number: 30
Unix process pid: 16404, image: oracle@base (LSP0)
*** 2013-04-04 16:41:58.401
*** SESSION ID:(294.35251) 2013-04-04 16:41:58.401
*** CLIENT ID:() 2013-04-04 16:41:58.401
*** SERVICE NAME:(SYS$BACKGROUND) 2013-04-04 16:41:58.401
*** MODULE NAME:() 2013-04-04 16:41:58.401
*** ACTION NAME:() 2013-04-04 16:41:58.401
knahcapplymain: encountered error=26808
*** 2013-04-04 16:41:58.401
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=0, mask=0x0)
----- Error Stack Dump -----
ORA-26808: Apply process AS02 died unexpectedly.
ORA-01031: insufficient privileges
KNACDMP: *******************************************************
KNACDMP: Dumping apply coordinator's context at 25487cb0
KNACDMP: Apply Engine # 0
KNACDMP: Apply Engine name
KNACDMP: Coordinator's Watermarks ------------------------------
KNACDMP: Apply High Watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Apply Low Watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Recovery Low Watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Fetch Low Watermark = 0002fc0f876b (SCN=0x0002.fc0f876b)
KNACDMP: Fetch Low Watermark Time = 811857327
KNACDMP: Oldest SCN = (SCN=0x0000.00000000)
KNACDMP: Oldest XID =
KNACDMP: Oldest Create Time = 0
KNACDMP: Last replicant syncpoint SCN = 0x0000.00000000
KNACDMP: Last syncpoint at primary SCN = 0x0002.fc0f875f
KNACDMP: First partition max pos = 0002fc10fab4 (SCN=0x0002.fc10fab4)
KNACDMP: Last partition max pos = 0002fc10fab4 (SCN=0x0002.fc10fab4)
KNACDMP: Last processed = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Conservative pos = 0002fc0f8cb2 (SCN=0x0002.fc0f8cb2)
KNACDMP: Recovery start pos = (SCN=0x0000.00000000)
KNACDMP: Recovery high watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Spill LWM = (SCN=0x0000.00000000)
KNACDMP: Spill LWM Create Time = 0
KNACDMP: Coordinator's constants -------------------------------
KNACDMP: number of apply slaves = 5
KNACDMP: min number of apply slaves = 5
KNACDMP: max number of apply slaves = 5
KNACDMP: safety level (K) = 1
KNACDMP: max txns in memory = 400
KNACDMP: max constraints per table = 620
KNACDMP: hash table size (in entries) = 10000000
KNACDMP: Coordinator's intervals -------------------------------
KNACDMP: syncpoint interval (ms) = 0
KNACDMP: write low watermark interval(ms)= 1
KNACDMP: Coordinator's timers/counters -------------------------
KNACDMP: current time = 1365082918
KNACDMP: low watermark timer = 0
KNACDMP: syncpoint timer = 1365082918
KNACDMP: txnbufsize timer = 1365082220
KNACDMP: Coordinator's txn counts -------------------------
KNACDMP: total txns applied = 0
KNACDMP: number of unassigned comp txns = 0
KNACDMP: number of unassigned incomp txns= 0
KNACDMP: avg number of unassigned txns = 0.00
KNACDMP: total applied at last plwm write= 0
KNACDMP: apply prog. entries below plwm = 0
KNACDMP: total unassigned lcrs = 0
KNACDMP: Coordinator's State/Flags -----------------------------
KNACDMP: Coordinator's State = KNACST_APPLY_UNTIL_END
KNACDMP: Coordinator's Flags = 0x408004
KNACDMP: Slave counts ------------------------------------------
KNACDMP: number of reserved slaves = 0
KNACDMP: number of admin slaves = 0
KNACDMP: number of slaves in wait cmt = 1
KNACDMP: number of slaves suspended = 0
KNACDMP: number of safe slaves = 1
KNACDMP: avg number of idle slaves = 0.00
KNACDMP: number of slaves initializing = 0
KNACDMP: number of slaves terminating = 0
KNACDMP: Slave Lists -------------------------------------------
KNACDMP: Dumping All Slaves :-
Slave id = 0, State = 8, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 1, State = 9, Flags = 2, Assigned Xid = 0x001e.006.0005d213 1 txns 0 lcrs
Slave id = 2, State = 5, Flags = 1, Assigned Xid = 0x0019.00e.0007f8d9 1 txns 0 lcrs
Slave id = 3, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 4, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 5, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
KNACDMP: End dumping all slaves
KNACDMP: syncdep slaves = { }
KNACDMP: cont chunk slaves = { }
KNACDMP: cont slaves = { }
KNACDMP: exec txn slaves = { }
KNACDMP: Active slaves (2) = { 1 2 }
KNACDMP: Idle slaves (3) = { 3 4 5 }
KNACDMP: Txn Lists ---------------------------------------------
KNACDMP: Dumping all txns :-
XID = 0x001e.006.0005d213 Commit pos = 0002fc06718c (SCN=0x0002.fc06718c) State = 0
Lcr cnt = 0
Assigned to slavid = 1
Fetched chunks = 142
depslaves = { } wm depslaves = { }
XID = 0x0019.00e.0007f8d9 Commit pos = 0002fc0f876b (SCN=0x0002.fc0f876b) State = 1
Lcr cnt = 0
Assigned to slavid = 2
Fetched chunks = 1
depslaves = { } wm depslaves = { }
KNACDMP: End dumping all txns.
KNACDMP: Complete txns = { 0x0019.00e.0007f8d9 ** NO UNASS ** }
KNACDMP: Unassigned txns = { }
KNACDMP: *******************************************************
Warning: Apply error received: ORA-26714: User Error encountered during apply process. Clearing.
knahcapplymain: encountered error=26808
*** 2013-04-04 16:58:47.073
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=0, mask=0x0)
----- Error Stack Dump -----
ORA-26808: Apply process AS01 died unexpectedly.
ORA-01031: insufficient privileges
KNACDMP: *******************************************************
KNACDMP: Dumping apply coordinator's context at 25487cb0
KNACDMP: Apply Engine # 0
KNACDMP: Apply Engine name
KNACDMP: Coordinator's Watermarks ------------------------------
KNACDMP: Apply High Watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Apply Low Watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Recovery Low Watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Fetch Low Watermark = 0002fc0f876b (SCN=0x0002.fc0f876b)
KNACDMP: Fetch Low Watermark Time = 811857327
KNACDMP: Oldest SCN = (SCN=0x0000.00000000)
KNACDMP: Oldest XID =
KNACDMP: Oldest Create Time = 0
KNACDMP: Last replicant syncpoint SCN = 0x0000.00000000
KNACDMP: Last syncpoint at primary SCN = 0x0002.fc0f875f
KNACDMP: First partition max pos = 0002fc10fab4 (SCN=0x0002.fc10fab4)
KNACDMP: Last partition max pos = 0002fc10fab4 (SCN=0x0002.fc10fab4)
KNACDMP: Last processed = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Conservative pos = 0002fc0f8cb2 (SCN=0x0002.fc0f8cb2)
KNACDMP: Recovery start pos = (SCN=0x0000.00000000)
KNACDMP: Recovery high watermark = 0002fc0f875f (SCN=0x0002.fc0f875f)
KNACDMP: Spill LWM = (SCN=0x0000.00000000)
KNACDMP: Spill LWM Create Time = 0
KNACDMP: Coordinator's constants -------------------------------
KNACDMP: number of apply slaves = 5
KNACDMP: min number of apply slaves = 5
KNACDMP: max number of apply slaves = 5
KNACDMP: safety level (K) = 1
KNACDMP: max txns in memory = 400
KNACDMP: max constraints per table = 620
KNACDMP: hash table size (in entries) = 10000000
KNACDMP: Coordinator's intervals -------------------------------
KNACDMP: syncpoint interval (ms) = 0
KNACDMP: write low watermark interval(ms)= 1
KNACDMP: Coordinator's timers/counters -------------------------
KNACDMP: current time = 1365083926
KNACDMP: low watermark timer = 0
KNACDMP: syncpoint timer = 1365083926
KNACDMP: txnbufsize timer = 1365083218
KNACDMP: Coordinator's txn counts -------------------------
KNACDMP: total txns applied = 0
KNACDMP: number of unassigned comp txns = 0
KNACDMP: number of unassigned incomp txns= 1
KNACDMP: avg number of unassigned txns = 0.00
KNACDMP: total applied at last plwm write= 0
KNACDMP: apply prog. entries below plwm = 0
KNACDMP: total unassigned lcrs = 0
KNACDMP: Coordinator's State/Flags -----------------------------
KNACDMP: Coordinator's State = KNACST_APPLY_UNTIL_END
KNACDMP: Coordinator's Flags = 0x8204
KNACDMP: Slave counts ------------------------------------------
KNACDMP: number of reserved slaves = 0
KNACDMP: number of admin slaves = 0
KNACDMP: number of slaves in wait cmt = 0
KNACDMP: number of slaves suspended = 0
KNACDMP: number of safe slaves = 1
KNACDMP: avg number of idle slaves = 0.00
KNACDMP: number of slaves initializing = 0
KNACDMP: number of slaves terminating = 0
KNACDMP: Slave Lists -------------------------------------------
KNACDMP: Dumping All Slaves :-
Slave id = 0, State = 8, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 1, State = 5, Flags = 1, Assigned Xid = 0x0019.00e.0007f8d9 1 txns 0 lcrs
Slave id = 2, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 3, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 4, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
Slave id = 5, State = 0, Flags = 0, Not Assigned 0 txns 0 lcrs
KNACDMP: End dumping all slaves
KNACDMP: syncdep slaves = { }
KNACDMP: cont chunk slaves = { }
KNACDMP: cont slaves = { }
KNACDMP: exec txn slaves = { }
KNACDMP: Active slaves (1) = { 1 }
KNACDMP: Idle slaves (4) = { 2 3 4 5 }
KNACDMP: Txn Lists ---------------------------------------------
KNACDMP: Dumping all txns :-
XID = 0x001e.006.0005d213 Commit pos = 0002fc06718c (SCN=0x0002.fc06718c) State = 0
Lcr cnt = 0
Not Assigned
Fetched chunks = 142
depslaves = { } wm depslaves = { }
XID = 0x0019.00e.0007f8d9 Commit pos = 0002fc0f876b (SCN=0x0002.fc0f876b) State = 1
Lcr cnt = 0
Assigned to slavid = 1
Fetched chunks = 1
depslaves = { } wm depslaves = { }
KNACDMP: End dumping all txns.
KNACDMP: Complete txns = { 0x0019.00e.0007f8d9 ** NO UNASS ** }
KNACDMP: Unassigned txns = { 0x001e.006.0005d213 }
KNACDMP: *******************************************************
*** 2013-04-04 16:58:47.513
Warning: Apply error received: ORA-26714: User Error encountered during apply process. Clearing.
I watched this link http://docs.oracle.com/cd/E11882_01/server.112/e17069/strms_trapply.htm#i1014714 and I checked grants of schemas owners. These grants identical as on Primary DB Server.
I don't know what I need to do. It's very critical Server. Please help me.

So, my problem is solved very easy.
Logical Standby didn't work because I added grant SYSDBA to temporary user and revoked this grant at once and I didn't change orapwSID file on Logical Standby from Primary.
http://docs.oracle.com/cd/E11882_01/server.112/e25608/create_ps.htm#SBYDB00424Note:
Whenever you grant or revoke the SYSDBA or SYSOPER privileges or change the login password of a user who has these privileges, you must replace the password file at each physical or snapshot standby database in the configuration with a fresh copy of the password file from the primary database.
>
So, I deleted temporary user on Logical Standby and it solved the problem.
Thanks a lot to all who helped me!

Logical standby stopped lastnight

Subject: Logical standby stopped lastnight
Author: raghavendra rao yella, United States
Date: Nov 14, 2007, 0 minutes ago
Os info: solaris 5.9
Oracle info: 10.2.0.3
Error info: ORA-16120: dependencies being computed for transaction at SC
N 0x0002.c8f6f182
Message: Our logical standby stopped last night. we tried to stop and start the standby but no help.
Below are some of the queries to get the status:
APPLIED_SCN LATEST_SCN MINING_SCN RESTART_SCN
11962328446 11981014649 11961580453 11961536228
APPLIED_TIME LATEST_TIME MINING_TIME RESTART_TIME
07-11-13 09:09:41 07-11-14 10:26:26 07-11-13 08:57:53 07-11-13 08:56:36
sys@RP06>SELECT TYPE, HIGH_SCN, STATUS FROM V$LOGSTDBY;
TYPE HIGH_SCN STATUS
COORDINATOR 1.1962E+10 ORA-16116: no work available
READER 1.1962E+10 ORA-16127: stalled waiting for additional transact
ions to be applied
BUILDER 1.1962E+10 ORA-16127: stalled waiting for additional transact
ions to be applied
PREPARER 1.1962E+10 ORA-16127: stalled waiting for additional transact
ions to be applied
ANALYZER 1.1962E+10 ORA-16120: dependencies being computed for transac
tion at SCN 0x0002.c8f6c002
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
APPLIER ORA-16116: no work available
10 rows selected.
Select PID,
TYPE,
STATUS
From
V$LOGSTDBY
Order by
HIGH_SCN; 2 3 4 5 6 7 8
PID TYPE STATUS
17896 ANALYZER ORA-16120: dependencies being computed for transaction at SC
N 0x0002.c8f6f182
17892 PREPARER ORA-16127: stalled waiting for additional transactions to be
applied
17890 BUILDER ORA-16243: paging out 8144 bytes of memory to disk
17888 READER ORA-16127: stalled waiting for additional transactions to be
applied
28523 COORDINATOR ORA-16116: no work available
17904 APPLIER ORA-16116: no work available
17906 APPLIER ORA-16116: no work available
17898 APPLIER ORA-16116: no work available
17900 APPLIER ORA-16116: no work available
17902 APPLIER ORA-16116: no work available
10 rows selected.
How can i get this transaction information, which log miner is looking for dependencies?
Let me know if you have any questions.
Thanks in advance.
Message was edited by:
raghu559

Hi reega,
Thanks for your reply, our logical stdby has '+RT06_DATA/RT06'
and primary has '+OT06_DATA/OT06TSG001'
so we are using db_file_name_convert init parameter but it doesn't work.
Is there any thing particular steps hiding to use this parameter? as i tried this parameter for rman cloning it din't work, as a workaround i used rman set new name command for clonning.
Let me know if you have any questions.
Thanks in advance.

Logical standby: SQL Apply too slow

Hi all,
I have a question regarding SQL Apply performance in logical standby. There are two kind of operations that are remarkably slow when applying them on logical standby. These are "truncate table" and "delete from table" operations.
When logical standby pick up one of mentioned statements from logs one of appliers start working whereas rest others are waiting. It looks like standby hang and very slow sql apply is moving on gradually and finally when operation completes standby is behind primary for 4 or 5 or even 8 hours.
What can be done in this regard to speed up sql apply and alleviate this situation?
Best Regards,
Alex

Are you absolutely sure that the truncate is the problem (and deletes). How did you check it?
You can use LogMiner to check what are most of the commands in the log currently applied. I use this:
BEGIN
sys.DBMS_LOGMNR.ADD_LOGFILE( LOGFILENAME => '/home/oracle/arc_43547_1_595785865.arc', OPTIONS => sys.DBMS_LOGMNR.ADDFILE);
END;
BEGIN
sys.DBMS_LOGMNR.START_LOGMNR( OPTIONS => sys.DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
END;
SELECT seg_owner,seg_name,table_name,operation,COUNT(1) FROM V$LOGMNR_CONTENTS
GROUP BY seg_owner,seg_name,table_name,operation
ORDER BY COUNT(1) DESC
BEGIN
sys.DBMS_LOGMNR.END_LOGMNR();
END;
Most of the times in our cases when SQL Apply is slow is because of high activity on particular object. This can be detected by high number of DMLs for that object using LogMiner. If this object is not needed on the logical standby you can skip it and thus SQL Apply will be faster because it will not apply changes for this particular one. If it's needed and this is not a regular rate, then you can skip it temporarily, turn on SQL Apply , after problematic logs are applied, turn off SQL Apply, instantiate the object and unskip it, turn on sql apply again.
Another thing that can drastically slowdown SQL Apply is the size of memory available for SQL Apply(Alert log shows that max is ~4.5GB or something like this, I'm not sure )
You can increase it with something like this:
ALTER DATABASE STOP LOGICAL STANDBY APPLY;
BEGIN
DBMS_LOGSTDBY.APPLY_SET('MAX_SGA', 3000); -- set to 3000 MB
END;
ALTER DATABASE START LOGICAL STANDBY APPLY;
You have to increase it if the following reports:
SELECT NAME, VALUE FROM V$LOGSTDBY_STATS
WHERE NAME LIKE '%page%' OR
NAME LIKE '%uptime%' or name like '%idle%';
that 'bytes paged out' increases if run every few seconds during slow SQL Apply.
I hope that it's something that can be fixed using the above info. If no, please comment and share your investigations.
Thanks

Logical Standby - 9iR2

Hi, i have a litle problem with Logical Standby database a few second the start apply the redo the view V$LOGSTDBY_STATS is empty.
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;
Database altered.
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
NAME VALUE
coordinator state APPLYING
SQL> SELECT NAME, VALUE FROM V$LOGSTDBY_STATS WHERE NAME = 'coordinator state';
no rows selected

Is the coordinator state process up and running for your Data Guard 9iR2 logical standby environment?
Here is how to check:
COLUMN LID FORMAT 9999
COLUMN SERIAL# FORMAT 9999
COLUMN SID FORMAT 9999
SELECT SID, SERIAL#, LOGSTDBY_ID AS LID, SPID, TYPE, HIGH_SCN FROM V$LOGSTDBY_PROCESS;
You should see processes similar to the following if things are setup correctly:
SID SERIAL# LID SPID TYPE HIGH_SCN
48 6 -1 11074 COORDINATOR 7178242899
56 56 0 10858 READER 7178243497
46 1 1 10860 BUILDER 7178242901
45 1 2 10862 PREPARER 7178243295
37 1 3 10864 ANALYZER 7178241034
36 1 4 10866 APPLIER 7178239467
35 3 5 10868 APPLIER 7178239463
34 7 6 10870 APPLIER 7178239461
33 1 7 10872 APPLIER 7178239472
9 rows selected.
I would review my setup and configuration steps for your Data Guard 9i Logical Standby environment.
For more tips on monitoring see here:
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/manage_ls.htm#CHDEFEFC
And do review your setup and configuration. The steps are covered in the Oracle 9i Data Guard Concepts Guide. See here:
http://download.oracle.com/docs/cd/B10501_01/server.920/a96653/toc.htm
In particular, please review your setup per the guidelines in Chapter 4 of the guide.
Regards,
Ben Prusinski
http://oracle-magician.blogspot.com/

Logical Standby--coordinator state = 'IDLE'

Similar Messages

Maybe you are looking for