Adv Compression & Logical Standby DB (SQL Apply)

Hi,
Is use of AC on a primary database supported with the SQL Apply (logical standby) version of Data Guard in release 11.1.0.7 ?
thanks !
Curt Lukenbill
Paychex, Inc

Dan, Thanks for the replies. The source of my confusion is the 11g Data Guard Documentation --
In the Appendix, it states --
C.7 Unsupported Table Storage Types
Logical standby databases do not support the following table storage types:
Tables stored with segment compression enabled
We are going to test it out here, and we'll share the results...
I'd hate not to be able to use AC on my primary because we have a SQL*Apply standby associated with it....If this is the case (and we can't use AC on the primary), I hope Oracle is addressing it in 11gR2....
Curt Lukenbill

Similar Messages

Logical standby server stopped applying changes

Hi
I set up a logical standby database with database guard and it worked fine for some time. But recently I had to use it again and discovered that applying changes from primary database to secondary database just stopped working. I see in V$ARCHIVED_LOG one entry per day. If I restart the logical standby then the changes from primary server are also applied. But if I just make a change on primary server and even call 'alter system switch logfile' then I see an entry in V$ARCHIVED_LOG on primary server but not on standby server (BTW in general there are much more entries in this view on the primary server). I checked pairs of log files indicated by the parameter *.log_file_name_convert in standby server's spfile: their last changed date is always the same.
I will paste spfile of my standby server (dh5). Primary server name is dh2.
dh2.__db_cache_size=79691776
dh5.__db_cache_size=96468992
dh2.__java_pool_size=4194304
dh5.__java_pool_size=4194304
dh2.__large_pool_size=4194304
dh5.__large_pool_size=4194304
dh2.__shared_pool_size=71303168
dh5.__shared_pool_size=54525952
dh2.__streams_pool_size=0
dh5.__streams_pool_size=0
*.audit_file_dest='/var/lib/oracle/oracle/product/10.2.0/db_1/admin/dh5/adump'
*.background_dump_dest='/var/lib/oracle/oracle/product/10.2.0/db_1/admin/dh5/bdump'
*.compatible='10.2.0.1.0'
*.control_files='/var/lib/oracle/oracle/product/10.2.0/db_1/oradata/dh5/control01.ctl'
*.core_dump_dest='/var/lib/oracle/oracle/product/10.2.0/db_1/admin/dh5/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_file_name_convert='dh2','dh5'
*.db_name='dh7'
*.db_recovery_file_dest='/var/lib/oracle/oracle/product/10.2.0/db_1/flash_recovery_area'
*.db_recovery_file_dest_size=2147483648
*.db_unique_name='dh5'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=dh2XDB)'
*.fal_client='dh5'
*.fal_server='dh2'
*.job_queue_processes=10
*.log_archive_config='DG_CONFIG=(dh2,dh5)'
*.log_archive_dest_1='LOCATION=/var/lib/oracle/oracle/product/10.2.0/db_1/oradata/dh5_local
VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=dh5'
*.log_archive_dest_2='SERVICE=dh2 LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=dh2'
*.log_archive_dest_3='LOCATION=/var/lib/oracle/oracle/product/10.2.0/db_1/oradata/dh5
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLES)
DB_UNIQUE_NAME=dh5'
*.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
*.log_file_name_convert='oradata/dh2/redo01.log','flash_recovery_area/DH5/onlinelog/o1_mf_4_5x0o5grc_.log','oradata/dh2/r
edo02.log','flash_recovery_area/DH5/onlinelog/o1_mf_5_5x0o61mw_.log','oradata/dh2/redo03.log','flash_recovery_area/DH5/on
linelog/o1_mf_6_5x0o63gj_.log'
*.nls_language='AMERICAN'
*.open_cursors=300
*.pga_aggregate_target=311427072
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=167772160
*.undo_management='AUTO'
*.undo_retention=3600
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='/var/lib/oracle/oracle/product/10.2.0/db_1/admin/dh5/udump'
Thanks in advance for any help.
JM

Hi,
Nice to hear you issue got resolved.
It is good practice to keep monitoring the progress of SQL apply on the logical standby on a regular basis.
You can mark my response as helpful if it has helped you.
Regards
Anudeep

Logical standby real time apply problem

Hi all,
The real time apply for logical standby on my Oracle 10.2 DB is not working
SELECT SEQUENCE#, FIRST_TIME, APPLIED
FROM DBA_LOGSTDBY_LOG
ORDER BY SEQUENCE#;
SEQUENCE# FIRST_TI APPLIED
2113 07/10/09 NO
2115 07/10/09 NO
2116 07/10/09 NO
There is no error inside alert log.
Any help
Thanks

Using Real-Time Apply to Apply Redo Data Immediately
http://docs.oracle.com/cd/E11882_01/server.112/e25608/log_apply.htm#i1022881
1.What is compatible parameter, it should be 11.1
2.Try to check parameters mentioned in below link:
http://easyoradba.com/2011/01/10/real-time-apply-in-oracle-data-guard-10g/
Regards
Girish Sharma
Edited by: Girish Sharma on Nov 15, 2012 12:37 PM

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.

Data Guard Logical Standby Skip Handler bug

Does anyone know of a documented bug concerning the skip handler not skipping a grant on a view in a schema with a SCHEMA_DDL skip handler defined?
Here is my test case.
On Primary:
Create table scott.junk (x number) tablespace users; (created successfully on logical standby)
On logical standby:
exec dbms_logstdby.skip('SCHEMA_DDL','SCOTT','%'null,true,'\'); (created skip handler on all SCOTT objects)
On Primary:
grant select on scott.junk to public; (successfully skipped due to missing object)
On Primary:
create view scott.v_junk as select * from scott.junk; (successfully skipped on logical standby)
On Primary:
grant select on scott.v_junk to public; (received 'ora-00942 table or view does not exist' on logical standby and SQL Apply stopped).
I'm running version 10.2.0.4 but have not applied the recommended patch bundle for logcal standby #7937113.8.
If anyone knows whether this has been documented or not, please let me know. If not, I will submit an SR to get this documented.
Thanks,
Michael Anderson
OCP - Bank of the West

When I look at the syntax for the package
http://www.morganslibrary.org/reference/dbms_logstdby.html
what I see is:
dbms_logstdby.skip(
stmt        IN VARCHAR2,
schema_name IN VARCHAR2 DEFAULT NULL,
object_name IN VARCHAR2 DEFAULT NULL,
proc_name   IN VARCHAR2 DEFAULT NULL,
use_like    IN BOOLEAN DEFAULT TRUE,
esc         IN CHAR1    DEFAULT NULL);So looking at your code:
exec dbms_logstdby.skip('SCHEMA_DDL','SCOTT','%'null,true,'\'); (created skip handler on all SCOTT objects)
'SCHEMA_DDL' is your statement.
'SCOTT' is your schema name.
'%' indicates all objects
and ... shouldn't there be a comma before the NULL?
In the future don't provide values where the default's will suffice. It makes thing's far simpler.

Interesting issue with Logical Standby and database triggers

We have a Logical Standby that each month we export (expdp) a schema (CSPAN) that is being maintained by SQL Apply and import (impdp)it to a 'frozen copy' (eg CSPAN201104) using REMAP_SCHEMA.
This works fine although we've noticed that because triggers on the original schema being exported have the original schema (CSPAN) hard-referenced in the definition are imported into and owned by the new 'frozen' schema but are still 'attached' to the original schema's tables.
This is currently causing the issue where the frozen schema trigger is INVALID and causing the SQL Apply to fail. This is the error:
'CSPAN201104.AUD_R_TRG_PEOPLE' is
invalid and failed re-validation
Failed SQL update "CSPAN"."PEOPLE" set "ORG_ID" = 2, "ACTIVE_IND" = 'Y', "CREATE_DT" = TO_DATE('22-JUL-08','DD-MON-RR'),"CREATOR_NM" = 'LC', "FIRST_NM" = 'Test', "LAST_PERSON" ='log'...
Note: this trigger references the CSPAN schema (...AFTER INSERT ON CSPAN.PEOPLE...)
I suspect that triggers on a SQL Apply Maintained schema in a Logical Standby do not need to be valid (since they do not fire) but what if they reference a SQL Apply schema but are 'owned' by a non-SQL Apply schema? This trigger references a SQL Apply table so it should not fire
This is 10gR2 (10.2.0.4) on 64 bit Windows.
Regards
Graeme King

OK, I've finally got around to actually test this and it looks like you are not quite correct Larry in this statement...
'Since this trigger belongs to a new schema that is not controlled by SQL Apply (CSPAN201105) it will fire. But the trigger references a schema that is controlled by SQL Apply (CSPAN) so it will fail because it has to be validated.'
My testing concludes that even though the trigger belongs to a schema CSPAN201105 (not controlled by SQL Apply) and references a schema controlled by SQL Apply - it does not fire. However it DOES need to be valid or it breaks SQL Apply.
My testing was as follows:
Primary DB
Create new EMP table in CSPAN schema on Primary
Create new table TRIGGER_LOG in CSPAN schema on Primary
Create AFTER INSERT/UPDATE trigger on CSPAN.EMP table (that inserts into TRIGGER_LOG table)
**All of the above replicates to Standby**
Standby DB
Create new table TRIGGER_LOG_STNDBY in CSPAN201105 schema on Primary
Create new trigger in CSPAN201105 schema that fires on INSERT/UPDATE on CSPAN.EMP but that inserts into CSPAN201105.TRIGGER_LOG_STNDBY table)
Primary DB
Insert 4 rows into CSPAN.EMP
Update 2 rows in CSPAN.EMP
TRIGGER_LOG table has 6 rows as expected
Standby DB
TRIGGER_LOG table has 6 rows as expected
TRIGGER_LOG_STNDBY table has **0 rows**
Re-create trigger in CSPAN201105 schema that fires on INSERT/UPDATE on CSPAN.EMP but that inserts into CSPAN201105.TRIGGER_LOG_STNDBY table) **but with syntax error**
Primary DB
Update 1 row in CSPAN.EMP
TRIGGER_LOG table has 7 rows as expected
Standby DB
SQL Apply is broken - ORA-04098: trigger 'CSPAN201105.TEST_TRIGGER_TRG' is invalid and failed re-validation

Logical Standby out of sync after archiver stuck (how to resync)

Hi,
I had an archiver stuck on my logical standby database for about 4 hours this night.
2 hours later my primary db also had an archiver stuck.
After solving the problem by repairing the backup mechanism and startup of the archivelog backup I realised
that some tables are out of sync.
How can I get back all things back in sync again?
DB: 11gR2 EE
OS: RedHat Linux 5.5
Thanks
941743

Hi,
I don't sure have or not resyncronization whole schema, but you can use with PL/SQL as
Stop SQL Apply on logical standby database
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
on primary
SQL> begin
2> for t in (select table_name from db_tables where owner = '<your schema name>')
3> loop
4> DBMS_LOGSTDBY.INSTANTIATE_TABLE(shema_name => '<your schema name>', object_name => T.Table_name, dblink => '<you dblink name>');
5> end loop;
6>end;
Start SQL Apply on logical standby database
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;If you skip DML and DDL for your schema, then you must UNSKIP DML and DDL on this tables you must add following script to PL/SQL block before INSTANTIATE_TABLEs.
DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', schema_name => '<your schema name>', object_name => T.Table_Name);
DBMS_LOGSTDBY.UNSKIP(stmt => 'DDL', schema_name => '<your schema name>', object_name => T.Table_Name);Regards
Mahir M. Quluzade
Edited by: Mahir M. Quluzade on Sep 13, 2012 6:17 PM

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: 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!

Transportable tablespaces with Logical Standby

Does anyone know whether or not transportable tablespaces can be used in a Logical Standby environment? I know they can be used with a Physical Standby, and the documentation covers how to do this, but there's nothing about Logical Standby. This is Oracle 10.2.0.4/SLES 10.
Thanks.

Using transportable tablespaces to a logical standby environment. Actually, there is a paragraph in the 10.2 Data Guard Concepts and Administration manual. I will summarize:
After creating the transportable tablespace export file on the source system, copy the datafiles to both the primary and logical standby systems.
On the dataguard logical standby, within SQLplus, issue SQL> alter session disable guard;
Import the tablespaces into the logical standby database
SQL> alter session enable guard;
Import the tablespaces into the primary database.
In 10.1, we imported the tablespaces into an environment with a physical standby and then converted the physical standby to a logical standby.
I tested the procedure for 10.2 and it seemed to work. Has anyone else done this and if so, are you aware of any issues? Like I said, the documentation is one very brief paragraph.
Thanks.

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

Sql Apply issue in logical standby database--(10.2.0.5.0) x86 platform

Hi Friends,
I am getting the following exception in logical standby database at the time of Sql Apply.
After run the command alter database start logical standby apply sql apply services start but after few second automatically stop and getting following exception.
alter database start logical standby apply
Tue May 17 06:42:00 2011
No optional part
Attempt to start background Logical Standby process
LOGSTDBY Parameter: MAX_SERVERS = 20
LOGSTDBY Parameter: MAX_SGA = 100
LOGSTDBY Parameter: APPLY_SERVERS = 10
LSP0 started with pid=30, OS id=4988
Tue May 17 06:42:00 2011
Completed: alter database start logical standby apply
Tue May 17 06:42:00 2011
LOGSTDBY status: ORA-16111: log mining and apply setting up
Tue May 17 06:42:00 2011
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 4, Transaction Chunk Size = 201
LOGMINER: Memory Size = 100M, Checkpoint interval = 500M
Tue May 17 06:42:00 2011
LOGMINER: krvxpsr summary for session# = 1
LOGMINER: StartScn: 0 (0x0000.00000000)
LOGMINER: EndScn: 0 (0x0000.00000000)
LOGMINER: HighConsumedScn: 2660033 (0x0000.002896c1)
LOGMINER: session_flag 0x1
LOGMINER: session# = 1, preparer process P002 started with pid=35 OS id=4244
LOGSTDBY Apply process P014 started with pid=47 OS id=5456
LOGSTDBY Apply process P010 started with pid=43 OS id=6484
LOGMINER: session# = 1, reader process P000 started with pid=33 OS id=4732
Tue May 17 06:42:01 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1417, X:\TANVI\ARCHIVE2\ARC01417_0748170313.001
Tue May 17 06:42:01 2011
LOGMINER: Turning ON Log Auto Delete
Tue May 17 06:42:01 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01417_0748170313.001
Tue May 17 06:42:01 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1418, X:\TANVI\ARCHIVE2\ARC01418_0748170313.001
LOGSTDBY Apply process P008 started with pid=41 OS id=4740
LOGSTDBY Apply process P013 started with pid=46 OS id=7864
LOGSTDBY Apply process P006 started with pid=39 OS id=5500
LOGMINER: session# = 1, builder process P001 started with pid=34 OS id=4796
Tue May 17 06:42:02 2011
LOGMINER: skipped redo. Thread 1, RBA 0x00058a.00000950.0010, nCV 6
LOGMINER: op 4.1 (Control File)
Tue May 17 06:42:02 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01418_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1419, X:\TANVI\ARCHIVE2\ARC01419_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01419_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1420, X:\TANVI\ARCHIVE2\ARC01420_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01420_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1421, X:\TANVI\ARCHIVE2\ARC01421_0748170313.001
LOGSTDBY Analyzer process P004 started with pid=37 OS id=5096
Tue May 17 06:42:03 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01421_0748170313.001
LOGSTDBY Apply process P007 started with pid=40 OS id=2760
Tue May 17 06:42:03 2011
Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_p001_4796.trc:
ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
LOGSTDBY Apply process P012 started with pid=45 OS id=7152
Tue May 17 06:42:03 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1422, X:\TANVI\ARCHIVE2\ARC01422_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01422_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1423, X:\TANVI\ARCHIVE2\ARC01423_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01423_0748170313.001
Tue May 17 06:42:03 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1424, X:\TANVI\ARCHIVE2\ARC01424_0748170313.001
LOGMINER: session# = 1, preparer process P003 started with pid=36 OS id=5468
Tue May 17 06:42:03 2011
LOGMINER: End mining logfile: X:\TANVI\ARCHIVE2\ARC01424_0748170313.001
Tue May 17 06:42:04 2011
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 1425, X:\TANVI\ARCHIVE2\ARC01425_0748170313.001
LOGSTDBY Apply process P011 started with pid=44 OS id=6816
LOGSTDBY Apply process P005 started with pid=38 OS id=5792
LOGSTDBY Apply process P009 started with pid=42 OS id=752
Tue May 17 06:42:05 2011
krvxerpt: Errors detected in process 34, role builder.
Tue May 17 06:42:05 2011
krvxmrs: Leaving by exception: 600
Tue May 17 06:42:05 2011
Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_p001_4796.trc:
ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
LOGSTDBY status: ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
Tue May 17 06:42:06 2011
Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_lsp0_4988.trc:
ORA-12801: error signaled in parallel query server P001
ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []
Tue May 17 06:42:06 2011
LogMiner process death detected
Tue May 17 06:42:06 2011
logminer process death detected, exiting logical standby
LOGSTDBY Analyzer process P004 pid=37 OS id=5096 stopped
LOGSTDBY Apply process P010 pid=43 OS id=6484 stopped
LOGSTDBY Apply process P008 pid=41 OS id=4740 stopped
LOGSTDBY Apply process P012 pid=45 OS id=7152 stopped
LOGSTDBY Apply process P014 pid=47 OS id=5456 stopped
LOGSTDBY Apply process P005 pid=38 OS id=5792 stopped
LOGSTDBY Apply process P006 pid=39 OS id=5500 stopped
LOGSTDBY Apply process P007 pid=40 OS id=2760 stopped
LOGSTDBY Apply process P011 pid=44 OS id=6816 stopped
Tue May 17 06:42:10 2011

Errors in file x:\oracle\product\10.2.0\admin\tanvi\bdump\tanvi_p001_4796.trc:
ORA-00600: internal error code, arguments: [krvxbpx20], [1], [1418], [2380], [16], [], [], []submit an SR to ORACLE SUPPORT.
refer these too
*ORA-600/ORA-7445 Error Look-up Tool [ID 153788.1]*
*Bug 6022014: ORA-600 [KRVXBPX20] ON LOGICAL STANDBY*

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

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

Slow SQL Apply on Logical Standby Database in Oracle10g

Hi,
We are using Oracle 10g Logical Standby database in our production farm but whenever there is bulk data load (5-6 GB data) on the primary database, the logical standby seems to be hung. It takes days to apply the 5-6 GB data on the logical standby.
Can anybody give me some pointers how can I make my SQL Apply fast on the logical standby for bulk data.
Thanks
Amit

Hi there,
I've a similar problem. I did an insert of 700k on a table. It takes me over 1 1/2 hours to see the data. Notice, I increased the "max_sga" to 300m and "max_servers" to 25" and didn't help the performance at all.
My version is 10.2.0.3 with the patch 6081550.
APPLIED_SCN APPLIED_TIME RESTART_SCN RESTART_TIME LATEST_SCN LATEST_TIME MINING_SCN MINING_TIME
1015618 29-NOV-2007 18:28:51 1009600 29-NOV-2007 18:28:51 1017519 29-NOV-2007 19:54:07 1015656 29-NOV-2007 18:32:14

Adv Compression & Logical Standby DB (SQL Apply)

Similar Messages

Maybe you are looking for