Slow replication on logical standby DB

Hi All,
Before 5 day we run update statistics script on our MIS DB. Now, we face slow replication in peak hours on this from RAC and not able to generate reports.
Please suggest me why this happen, how to solve this ? It very critical for me ..
Details are following-----
BEGIN
-- Run job synchronously.
DBMS_SCHEDULER.run_job (job_name=> 'SYS.GATHER_STATS_JOB');
END;
Oracle Version-----
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Productio
NLSRTL Version 10.2.0.3.0 - Production
AIX Version 5.3
SQL> select NAME ,OPEN_MODE, PROTECTION_MODE ,DATABASE_ROLE,GUARD_STATUs,LOG_MODE from v$database;
OPEN_MODE PROTECTION_MODE DATABASE_ROLE GUARD_S LOG_MODE
READ WRITE MAXIMUM PERFORMANCE LOGICAL STANDBY ALL ARCHIVELOG
Topas -------------
Topas Monitor for host: UMISDB01 EVENTS/QUEUES FILE/TTY
Wed Jan 20 11:51:13 2010 Interval: 2 Cswitch 6723 Readch 0.0G
Syscall 4300 Writech 6657.3K
Kernel 5.4 |## | Reads 2780 Rawin 0
User 58.1 |################# | Writes 288 Ttyout 1337
Wait 2.9 |# | Forks 0 Igets 0
Idle 33.7 |########## | Execs 0 Namei 33
Physc = 2.25 %Entc= 64.2 Runqueue 5.0 Dirblk 0
Waitqueue 6.5
Network KBPS I-Pack O-Pack KB-In KB-Out
en6 2.2 7.0 5.0 0.4 1.8 PAGING MEMORY
en1 0.0 0.0 0.0 0.0 0.0 Faults 2762 Real,MB 16384
lo0 0.0 0.0 0.0 0.0 0.0 Steals 7251 % Comp 94.4
PgspIn 3 % Noncomp 5.5
Disk Busy% KBPS TPS KB-Read KB-Writ PgspOut 0 % Client 5.5
hdisk10 100.0 4.2K 542.5 4.2K 0.0 PageIn 5530
hdisk6 100.0 9.6K 1.2K 9.0K 659.1 PageOut 1664 PAGING SPACE
hdisk5 100.0 8.8K 1.1K 8.1K 715.3 Sios 7194 Size,MB 32768
hdisk4 29.1 1.4K 89.9 128.6 1.3K % Used 9.9
hdisk15 8.5 1.1K 46.2 92.4 1.0K NFS (calls/sec) % Free 91.1
hdisk8 3.5 261.2 31.6 0.0 261.2 ServerV2 0
hdisk14 2.5 514.4 14.6 0.0 514.4 ClientV2 0 Press:
hdisk12 2.0 759.5 8.5 0.0 759.5 ServerV3 0 "h" for help
hdisk0 1.5 16.1 4.0 12.1 4.0 ClientV3 0 "q" to quit
hdisk13 0.5 827.8 13.6 0.0 827.8
hdisk1 0.5 4.0 1.0 0.0 4.0
hdisk7 0.5 442.1 7.5 0.0 442.1
Name PID CPU% PgSp Owner
oracle 1876038 14.1 15.3 oracle
oracle 1597544 14.0 11.3 oracle
lrud 16392 0.5 0.6 root
oracle 1515570 0.4 467.5 oracle
oracle 1695836 0.3 27.3 oracle
oracle 1642498 0.3 323.3 oracle
oracle 1204230 0.3 291.3 oracle
oracle 512222 0.2 483.5 oracle
oracle 1368188 0.2 7.4 oracle
oracle 1458238 0.2 227.3 oracle
oracle 1712180 0.1 307.4 oracle
oracle 1638546 0.1 37.2 oracle
aioserve 848030 0.1 0.4 root
Signal 2 received
Thanks in advance

Santosh Pradhan wrote:
Hi ,
oracle 10.2.0.3 enterprise edition logical standby
We performed heavy updates on our production database due to which logical standby gone lots of logs behind with primary database and log are getting apply on logical standby very slowly.
Kindly suggest how to speed up apply process on logical standby ....Hope you are using "ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;" command
Here please check the below note for Adjusting the Number of APPLIER Processes , also if redo transport is slow check the settings for "LOG_ARCHIVE_MAX_PROCESSES"
http://docs.oracle.com/cd/B28359_01/server.111/b28294/manage_ls.htm#CHDBGBFC

Similar Messages

Slow apply on logical standby

Hi ,
oracle 10.2.0.3 enterprise edition logical standby
We performed heavy updates on our production database due to which logical standby gone lots of logs behind with primary database and log are getting apply on logical standby very slowly.
Kindly suggest how to speed up apply process on logical standby ....

Santosh Pradhan wrote:
Hi ,
oracle 10.2.0.3 enterprise edition logical standby
We performed heavy updates on our production database due to which logical standby gone lots of logs behind with primary database and log are getting apply on logical standby very slowly.
Kindly suggest how to speed up apply process on logical standby ....Hope you are using "ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;" command
Here please check the below note for Adjusting the Number of APPLIER Processes , also if redo transport is slow check the settings for "LOG_ARCHIVE_MAX_PROCESSES"
http://docs.oracle.com/cd/B28359_01/server.111/b28294/manage_ls.htm#CHDBGBFC

SQL apply is very slow on Logical Standby..!!

Hello all,
We are having Data Guard setup in our environment where we are having Primary, Physical Standby as well as logical standby databases..
DB Version : 10.2.0.1 in all databases (Pri, Phy and Logical)
OS : RHEL4
Only Oracle is running on this Box..
Since last month we are facing problems in Logical Standby database where it seems SQL apply has become very slow..
Archive log files are successfully transferring from Primary but since SQL apply has become slow logical standby is lagging behind primary by two days..
How do i speed up this SQL apply..?? Any ideas and suggestions are most welcome..
I checked TOP command to find out which oracle processes are consuming maximum CPU and i have found ora_p000_oracle, ora_p001_oracle, ora_p002_oracle, ora_p003_oracle, ora_p004_oracle, ora_p005_oracle, etc processes are consuming highest CPU and Load Average has always been above 1..
Any help would be greatly appreciated..
Thanks - HP

Hello;
These Oracle notes might help :
Slow Performance In Logical Standby Database Due To Lots Of Activity On Sys.Aud$ [ID 862173.1]
Oracle10g Data Guard SQL Apply Troubleshooting [ID 312434.1]
Developer and DBA Tips to Optimize SQL Apply [ID 603361.1]
Best Regards
mseberg

Logical Standby....

Hi, I have Created Logical Standby data base on my windows 2003 Advance Server Machine and Oracle 10.2.0.3.
now I am having some problem that my LOGSTDBY is not in sync with the Primary DB from few days and in alertlog it is showing this error....
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, builder process P001 started with pid=18 OS id=2820
LOGMINER: session# = 1, reader process P000 started with pid=17 OS id=2816
LOGSTDBY Analyzer process P003 started with pid=20 OS id=2828
LOGSTDBY Apply process P005 started with pid=39 OS id=2984
LOGSTDBY Apply process P006 started with pid=40 OS id=2988
Fri Aug 21 11:56:17 2009
LOGMINER: Begin mining logfile: G:\ORACLE\ORADATA\SOS\ARCHIVE\SOST001S63660.ARC
Fri Aug 21 11:56:17 2009
LOGMINER: Turning ON Log Auto Delete
LOGSTDBY Apply process P004 started with pid=22 OS id=2980
LOGSTDBY Apply process P008 started with pid=42 OS id=2996
LOGMINER: session# = 1, preparer process P002 started with pid=19 OS id=2824
LOGSTDBY Apply process P007 started with pid=41 OS id=2992
Fri Aug 21 11:56:26 2009
Errors in file d:\oracle\admin\sos\bdump\logstdby_p004_2980.trc:
ORA-00604: error occurred at recursive SQL level 2
ORA-00955: name is already used by an existing object
Fri Aug 21 11:56:26 2009
LOGSTDBY status: ORA-00955: name is already used by an existing object
LOGSTDBY Apply process P004 pid=22 OS id=2980 stopped
Fri Aug 21 11:56:29 2009
Errors in file d:\oracle\admin\sos\bdump\logstdby_lsp0_2944.trc:
ORA-12801: error signaled in parallel query server P004
ORA-00955: name is already used by an existing object
LOGSTDBY Apply process P006 pid=40 OS id=2988 stopped
LOGSTDBY Analyzer process P003 pid=20 OS id=2828 stopped
LOGSTDBY Apply process P005 pid=39 OS id=2984 stopped
LOGSTDBY Apply process P007 pid=41 OS id=2992 stopped
LOGSTDBY Apply process P008 pid=42 OS id=2996 stopped
Fri Aug 21 11:58:50 2009
Redo Shipping Client Connected as PUBLIC
Plz rply ASAP

Here are the steps to identify the object in question:
1) Start the replication on logical standby
2) Once the replication starts it will show you the same error in the alert log file as you mentioned above.
3) Query DBA_LOGSTDBY_EVENTS order by EVENT_TIMESTAMP. The last event will capture the name of the object that is creating the problem.
4) Based on your knowledge of database /application objects, you can skip that table using DBMS_LOGSTADBY.SKIP and start the replication again without any issue.
5) If you dont need that object in the logical DB to be replicated then let it be skipped, otherwise reinstate the object again in logical standby.
Amar.

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 Apply became TOO SLOW !!

Hi,
I recently have setup a logical standby database. Everything was fine until the apply procedure on the standby became too slow:
SQL> alter session set nls_date_format = 'HH24:MI:SS (MM/DD)';
Session altered.
SQL> SELECT APPLIED_SCN, APPLIED_TIME, READ_SCN, READ_TIME, NEWEST_SCN, NEWEST_TIME FROM DBA_LOGSTDBY_PROGRESS;
APPLIED_SCN APPLIED_TIME READ_SCN READ_TIME NEWEST_SCN
NEWEST_TIME
3036960310 18:33:28 (05/31) 3035938077 18:12:43 (05/31) 3060387972
16:30:16 (06/02)
SQL>
The applied time changed about 20 minutes during last 46 hours. v$logstdby says:
COORDINATOR: ORA-16116: no work available
READER, BUILDER and PREPARER: ORA-16127: stalled waiting for additional transactions to be applied
All APPLIERs: ORA-16116: no work available
I really don't have any idea about this issue. Any help will be appreciated.
regards

One reason could be the SQL Apply engine performs too many slow full table scans, check metalink note:
Determining if SQL Apply Engine is Performing Full Table Scans
Doc ID: Note:255958.1
If this is the reason for the slowness you have to tune your DML statements.
Werner

Streams Replication:Source database Physical or Logical Standby DB

Can the source database in streams replication be a physical or logical standby database ? If so, is the process of configuring streams the same as a regular database ? Are there any best practices or different configuration if the source is Logical or Physical standby DB ?
Thanks in advance.

Never done it, but I don't see any reason why it should not work.
Streams, at capture site, is only a data dictionary game and in a logical standby your data dictionary is open read write.
Streams, at capture site, never touch the source tables, in fact they may even not exists from Streams point of view,
as it deals only with the redo that are generated.
So Streams horizon is limited to the data dictionary, the log buffer, the archives and, in SYSAUX tablespace, all the LOGMNR_% tables. All these structures are read write in the logical standby. However, for the capture/propagation you may have to set to true the 'include_tagged_lcr' parameters.

Streams Replication: Logical Standby DB as source

I don't have much experience with streams replications. So, the following might sound like a silly questions to Oracle Gurus:
If the source database is a logical standby database, can stream replication be used to replicate some of the tables in the source database to the target DB ?
The source and the target DB are 11g R2.
Thanks in adavance:
- Sanjay
Edited by: sanjayku on Dec 8, 2010 4:38 PM

Never done it, but I don't see any reason why it should not work.
Streams, at capture site, is only a data dictionary game and in a logical standby your data dictionary is open read write.
Streams, at capture site, never touch the source tables, in fact they may even not exists from Streams point of view,
as it deals only with the redo that are generated.
So Streams horizon is limited to the data dictionary, the log buffer, the archives and, in SYSAUX tablespace, all the LOGMNR_% tables. All these structures are read write in the logical standby. However, for the capture/propagation you may have to set to true the 'include_tagged_lcr' parameters.

Logical standby Slow after starting auditing

Hi:
I have logical standby, which was keeping with the primary database, then we started auditing on the primary database(Database auditing.) , After starting auditing my Logical standby not keeping with primary, after doing reasearch we found out that there are so many sql statement from sys schema on AUD$ table, and they are doing full tablescan on it, which is of 3GB as off now. Also This table is own by sys and by default all sys objects should be excluded from logical standby apply. But this is not, when I tryed to skip it by my self, then apply process gives ora-600 and stops.
I think it is a bug or what ???
Any help on this will be appriciated.
Regards
Bhushan

Hi Guys:
After taking my time we decided to truncate the sys.AUD$ on the LOGICAL STANDBY and that solved our problem.Now LS is catching up fast as I can see the progree is verry fast.
Still if anybody from "ORACLE CORP" is reading this thread they should give us the reason why the sys.aud$ table is beging replicated on the LOGICAL STANDBY site. is this a BUG in oracle?
Regards
Bhushan

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

Data guard-- very slow replication.

Hi Experts,
I am facing problem in an Oracle 10G R1 data guard implementation running on Solaris 10 64bit platform.
The primary database site has got 2 Sun servers running on RAC while the parallel standby site has got exactly the
same hardware. A LOGICAL standby policy is in use.
->>>The standby database is taking some 30 mintutes to get 10-15 new insertions from the primary database, ironically the system is not under production so no question about systemload.
* How can I tune the data replication time gap between the primary site and the standby site.
* Any pointer to some documentation 'd be highly appreciated.
Many thanks
Nitin

Hi NItin,
Here is my Logical standby: SQL Apply too slow on this matter.
Did you make any changes to following settings of logical standby parameters:
EAGERSIZE
PARALLEL_MAX_SERVERS
APPLY_SERVERS
LCR Cache size i.e. MAX_SGA
Please read before Note:603361.1 and Note:312434.1.
Please let me know if you decide to change something. I can advise some more or less appropriate values but you need to test them thoroughly.
Best Regards,
Alex

Logical Standby and Streams

Hi,
I am considering different replication scenarios for our future system and have a (maybe stupid:) question. Is it technically possible to create a logical standby database (Data Guard) and than replicate it further using Streams?
Regards,
Tim

Yes , This is possible with logical standby but you need to have mechanisms to take care of role transitioning in case of fail over. See Oracle document http://download.oracle.com/docs/cd/E14072_01/server.112/e10700/whatsnew.htm (Key word search "streams")
Thanks
http://swervedba.wordpress.com/
Edited by: swervedba on May 30, 2011 8:48 PM

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

Logical standby not working

Hi,
i have configured logical standby in 11gr2. IT replicates properly. Now the replication get stopped and it show the below error. Please suggest me to start the replication.
LOGMINER: Begin mining logfile during commit scan for session 1 thread 1 sequence 10618, //u01/primary_2345.dbf
Fri Mar 30 13:06:14 2012
LOGMINER: End mining logfiles during commit scan for session 1
LOGMINER: Turning ON Log Auto Delete
LOGMINER: Begin mining logfile for session 1 thread 1 sequence 10618, /u01/primary_2345.dbf
Fri Mar 30 13:06:15 2012
LOGSTDBY Analyzer process AS00 started with server id=0 pid=39 OS id=8993
Fri Mar 30 13:06:15 2012
LOGSTDBY Apply process AS01 started with server id=1 pid=40 OS id=8995
Fri Mar 30 13:06:15 2012
LOGSTDBY Apply process AS02 started with server id=2 pid=41 OS id=8997
Fri Mar 30 13:06:15 2012
LOGSTDBY Apply process AS03 started with server id=3 pid=43 OS id=8999
Fri Mar 30 13:06:15 2012
LOGSTDBY Apply process AS04 started with server id=4 pid=45 OS id=9001
Fri Mar 30 13:06:15 2012
LOGSTDBY Apply process AS05 started with server id=5 pid=46 OS id=9003
LOGSTDBY Apply process AS01 server id=1 pid=40 OS id=8995 stopped
Errors in file /oracle/oracle/diag/rdbms/lgdb/lgdb/trace/lgdb_as01_8995.trc:
ORA-01418: specified index does not exist
Errors in file /oracle/oracle/diag/rdbms/lgdb/lgdb/trace/lgdb_lsp0_8930.trc:
ORA-26808: Apply process AS01 died unexpectedly.
ORA-01418: specified index does not exist
LOGSTDBY Analyzer process AS00 server id=0 pid=39 OS id=8993 stopped
LOGSTDBY Apply process AS02 server id=2 pid=41 OS id=8997 stopped
LOGSTDBY Apply process AS05 server id=5 pid=46 OS id=9003 stopped
LOGSTDBY Apply process AS03 server id=3 pid=43 OS id=8999 stopped
LOGSTDBY Apply process AS04 server id=4 pid=45 OS id=9001 stopped
LOGMINER: session#=1 (Logical_Standby$), reader MS00 pid=34 OS id=8985 sid=22 stopped
LOGMINER: session#=1 (Logical_Standby$), builder MS01 pid=36 OS id=8987 sid=23 stopped
LOGMINER: session#=1 (Logical_Standby$), preparer MS02 pid=37 OS id=8989 sid=1910 stopped
=====================================================================================================================
In in the trace file, It show as
ORA-01418: specified index does not exist
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-01418: specified index does not exist

knasplcr: eager error was not rolled back
++ LCR Dump Begin: 0x9ffffffffd3f8070 - ddl
op: 5, Original op: 5, baseobjn: 0, objn: 1607159, objv: 65535
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: 0x00297a.0000a2ec.03b0
scn: 0x0000.0d2761ba, (scn: 0x0000.00000000, scn_sqn: 0, lcr_sqn: 0)xid: 0x0004.014.00013503, parentxid: 0x0004.014.00013503, proxyxid: 0x0000.000.00000000
ncol: 0 newcount: 24, oldcount: 0
LUBA: 0x10.4000d6a.14.7.92
++ LCR Dump Begin: 0xc0000002197a6580 - 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: 22, iotPrimaryKeyCount: 0, numChgRec: 0
NumCrSpilled: 0
RedoThread#: 1, rba: 0x00297a.0000a303.0070
scn: 0x0000.0d2761c8, (scn: 0x0000.0d2761c8, scn_sqn: 1, lcr_sqn: 1)xid: 0x0004.014.00013503, parentxid: 0x0004.014.00013503, proxyxid: 0x0000.000.00000000
ncol: 0 newcount: 0, oldcount: 0
LUBA: 0x10.4000d6e.14.14.34
Apply Slave is exiting due to error ORA-1418KSV 1418 error in slave process
ORA-01418: specified index does not exist
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-01418: specified index does not exist

Logical Standby Problem

My environment is Primary database is 11.1.0.7 64bit on Windows 2003 Enterprise 64bit. Logical is on the same platform and oracle version but a different server. I created a physical standby first and it applied the logs quickly without any issues. I received no errors when I changed it over to a Logical standby database. The problem that is happening is as soon as I issue the command "alter database start logical standby apply;" the CPU usage goes to 100% and the SQL apply takes a long time to apply a log. When I was doing this on 10G I never ran into this, as soon as the log was received, it was applied within a couple of minutes. I don't think it could be a memory issue since there is plenty on the Logical standby server. I just can't figure out why the SQL apply is so slow and the CPU usage skyrockets. I went through all of the steps in the guide "Managing a Logical Standby Database" from Oracle and I don't see anything wrong. The only difference between the two databases is that on the Primary I have Large Page support enabled, I don't on the Logical. Any help would be greatly appreciated, I need to use this Logical to report off of.

Thanks for the responses. I have found what is causing the problem. I kept noticing that the statements it was slowing down on were the ones where data was being written to the SYS.AUD$ table in the System tablespace on the Logical Standby database. A quick count of the records showed that I had almost 6 million records in that table. After I decided to truncate SYS.AUD$ on the Logical, the archive logs started to apply normally. I wonder why the Logical has a problem with this table and the Primary doesn't. I didn't even know auditing was turned on on the Primary database, it must be enabled by default. Now I know why my System table space has grown from 1gb to 2gb since November.
Now that I fixed it for now, I am unsure what to do to keep this from happening. Can I turn off Auditing on the Logical and keep it on for the Primary? Would this stop data from being written to the SYS.AUD$ table on the Logical? It doesn't appear that there is any kind of cleanup on this table that is offered by Oracle, I guess I can just clean out this table occasionally but that is just another thing to add to the list of maintenance tasks. I notice that you can also write this audit data to a file on the OS. Has anyone here done that?

Slow replication on logical standby DB

Similar Messages

Maybe you are looking for