Dataguard logical standby issue on lacking

we have logical standby database and its has been lacking sql apply from 14 hrs from primary database. Is there anyway i can stop sql apply and recover the database through archive files and make sync with primary and then again start the sql apply on logical standby database.
Please adivce

Neon,
I won't respond any further. The Dataguard Concepts and Administration Manual does contain a section on Troubleshooting.
It is quite clear you are using technology on which you have insufficient knowledge.
However, you belong to the class of wannabe-DBAs here,who as soon as they run into trouble start posting doc questions labeled with
'I need the detail steps'
'Urgent'
or (new development) post
'Any help' every half hour, when a volunteer didn't respond to their question.
If you want a quick response, submit a SR at Metalink. At least those analists are getting paid to answer your doc questions.
Sybrand Bakker
Senior Oracle DBA

Similar Messages

Oracle DataGuard Logical Standby

Hi , I'd like to know what are the premisses to make a standby logical replication.
I have two environments (production and standby) with different number of processors and storage.
I'd like to know if it's possible to create data guard solution with these two environments and what are the premisses that I need aware to install the solution.
Thanks in advance.

Hello;
Yes the storage ( as long as you have enough space ) and cpu don't matter.
You can use hardware that's quite a bit different and it will work fine.
You can also create a Logical Standby fro a physical standby.
These notes may help :
NOTE 413484.1 - Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration
Mixed Oracle Version support with Data Guard Redo Transport Services [ID 785347.1]
Logical Standby's don't seem to be very popular and the support base suffers because of this. I would consider a physical standby with Active Data Guard if costs allow.
Active Data Guard makes an excellent "Reader" database plus I believe your switchover and failover options are much better than a Logical Standby.
Oracle DataGuard Logical Standby Setup :
http://orajourn.blogspot.com/2007/02/setting-up-logical-standby-database.html
http://garyzhu.net/notes/DataGuard.html
Best Regards
mseberg
Edited by: mseberg on Apr 25, 2012 10:07 AM

Logical Standby Issue

Hi Friends,
I have 4 doubts. Please help me to clear my confusion.
Doubt 1:-
I have one primary and one logical standby database. When i restart the primary database or logical standby database or whenever data is not transffering to standby database, I execute the package "EXECUTE DBMS_LOGSTDBY.BUILD;". Then it starts to transfer the data to standby. My question is executing this package many times will affect the primary database? or my configuration is wrong?
Doubt 2:-
I configured DGMGRL for both database and i can switch over and switch back to logical standby database. It automatically start to apply the data to new logical standby database. But when i switch back to old primary database, It didnt transfer the data automatically. So i execute the package "EXECUTE DBMS_LOGSTDBY.BUILD;" in primary. Then it starts to transfer the data. My question is my switchback is wrong? or it happens like that only?
Note:- I check the verbose of both database before switchback. It show success.
Doubt 3:-
When i check the switchover status in logical standby database, It show "NOT ALLOWED". Even though i can switch over by using dgmgrl. Why logical standby database showing "NOT ALLOWED"?
Doubt 4:-
Is it any possible to view that what commands executing by dgmgrl process in background while it switchovering to logical standby database.?
Because when i try to switchover manually it didnt work. Many times i tried. But in dgmgrl, I simply give "switchover to logdb;", It works.
Please help to me to understand clearly.
Thank you in advance.

Wrong forum mate. This forum deals with SQL and PL/SQL languages and related issues - not database administration and configuration issues.
The shared memory error is not unusual though ito SQL and PL/SQL. It is often a result of not using sharable SQL - in other words, SQL statements that are not using bind variables.
This causes additional consumption and fragmentation of shared pool memory. The very worse thing to do in this case would be to increase the size of the shared pool. That is akin to moving the wall a bit further away so that one can run even faster and harder into it.
But I'm merely speculating as you may have another cause for this problem. I suggest that you:
- post this in the [url http://forums.oracle.com/forums/forum.jspa?forumID=61]Database Forum
- research this error on [url http://metalink.oracle.com]Metalink

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

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

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

Large import on dataguard (logical standby) 11.2

The action I'll like to perform is to do a large import on the production enviroment without that this import will be applied on the logical-standby environment (because its to large for the standby envoriment to keep it up) and after that I will do this same import on the logical standby.
What the most common way to do this large import on logical standby enviroment after this is performed on the produnction ?
something like ;
alter session disable guard;
do the import
alter session enable guard;
alter database start logical standby apply skip failed transaction;
thanks in adv

if the table you are importing will have changes made to it AFTER the import and you want those changes replicated to the logical standby then you have to actually re-sync the table FROM primary.
Step 1. Skip the table DML on logical
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', schema_name => 'schema', object_name =>'table_name');
Step 2. Import the table into primary
Step 3. Stop Logical Standby apply
alter database recover managed standby database cancel;
Step 4. Get the restart_scn on Logical Standby to use for the flashback scn with exp_dp
SELECT RESTART_SCN FROM V$LOGSTDBY_PROGRESS;
Step 5. On Primary export the table using the restart_scn from logical
expdp DIRECTORY=DP_DIR DUMPFILE=sync_table.dmp LOGFILE=sync_table.log tables=schema.table_name flashback_scn=6146375299983
Step 6. On Logical import the table
impdp DIRECTORY=DP_DIR dumpfile=sync_table.dmp TABLE_EXISTS_ACTION=REPLACE
Step 7. Unskip the table and start the apply on logical standby
EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', schema_name => 'schema', object_name =>'table_name');
alter database start logical standby apply immediate;
Now the tables should both be synced up and any new changes made to the table on primary will replicate correctly to logical.
Note that oracle must maintain a read consistent copy of the table as of the SCN you specified, depending on how long it takes to export you may run into rollback segment issues. I'd plan on doing this during the least busy time on your db and increase undo to avoid ORA-01555

Dataguard - logical standby - need help - not updating data at commit

Hi
Need help ?
We have logical standby setup where data is not updated at standby when committed at Primary. It only updates when alter system swith logfile.
On Primary:
log_archive_dest_2='service=xxStandby LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=xxStandby'
On Standby:
we have already created standby redo logs ( 1+ # redo logs)
we used ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NODELAY;
The data only ships when we do the ALTER SYSTEM SWITCH LOGFILE whereas it should so when data is commited on the primary.
Is there anything we are missing or need attention.
Please help
Thanks you so much

Yes, I have standby redo logs = ( 1 + # redo logs on the primary) and are of same size.
I also changed the log_archive_dest_2 setting for valid_for to ALL_LOGFILES, but the performance is still very slow... we are now overr 9 hrs behind the primary.
log_archive_dest_2='service=xxStandby LGWR ASYNC valid_for=(ALL_LOGFILES,primary_role) db_unique_name=xxStandby'
The Logical standby performance reallly not good at all. trying to increase sga/pga more ... hoping this will speed up some
Paul

Dataguard Logical Standby

Question: We're just thinking here.
If I have a primary database (A), which has a logical standby database (B), is it possible to have a logical standby database (C) for database (B)?
We have users that are updating tables in the logical standby database (B) but these are different tables than what are being updated from primary database (A).
Thank you

Yes.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/cascade_appx.htm#i636960

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 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.

ORA-01403: no data found on LOGICAL STANDBY database

Hi ,
Logical Standby issue :
Oracle 10.2.0.2 enterprise edition .
M Working on LOGICAL Standby since 1 yrs but still i havent got this ......................................
I m getting countinuously no data foud errror on logical standby database .
I found the table causing the proble(db_logstdby_events) and skipped that table and instanciated table using bwlow package:
exec dbms_logstdby.instantiate_table (.......................................
but when i start apply process on logical standby it again give no data found for new table :
Even i tried to instantiate the table using EXPORT/IMPORT during down time but the same facing same problem .
As much as i known abt the error that is :
table1
id
10
20
30
Now if sql apply process on logical standby tries to performe the update transaction(for example) as belows
update table1 set id=100 where id=50;
above query will not be completed cos it will never find the values 50 which is not in table .Thts why this error comming ..
Now my worry is ... no users dare to change/make such changes on Logical standby .So if there is no changes in tables then sqll apply should get all the values to be needded for an update ......
watingggg guyssss/......

Troubleshooting ORA-1403 errors with Flashback Transaction
In the event that the SQL Apply engine errors out with an ORA-1403, it may be possible to utilize flashback transaction on the standby database to reconstruct the missing data. This is reliant upon the undo_retention parameter specified on the standby database instance.
ORA-1403: No Data Found
Under normal circumstances the ORA-1403 error should not be seen in a Logical Standby environment. The error occurs when data in a SQL Apply managed table is modified directly on the standby database, and then the same data is modified on the primary database.
When the modified data is updated on the primary database and received by the SQL Apply engine, the SQL Apply engine verifies the original version of the data is present on the standby database before updating the record. When this verification fails, an ORA-1403: No Data Found error is thrown by Oracle Data Guard: SQL Apply.
The initial error
When the SQL Apply engine verification fails, the error thrown by the SQL Apply engine is reported in the alert log of the logical standby database as well as a record being inserted into the DBA_LOGSTDBY_EVENTS view. The information in the alert log is truncated, while the error is reported in it's entirety in the database view.
LOGSTDBY stmt: update "SCOTT"."MASTER"
set
"NAME" = 'john'
where
"PK" = 1 and
"NAME" = 'andrew' and
ROWID = 'AAAAAAAAEAAAAAPAAA'
LOGSTDBY status: ORA-01403: no data found
LOGSTDBY PID 1006, oracle@staco03 (P004)
LOGSTDBY XID 0x0006.00e.00000417, Thread 1, RBA 0x02dd.00002221.10
The Investigation
The first step is to analyze the historical data of the table that threw the error. This can be achieved using the VERSIONS clause of the SELECT statement.
SQL> select versions_xid
, versions_startscn
, versions_endscn
, versions_operation
, pk
, name
from scott.master
versions between scn minvalue and maxvalue
where pk = 1
order by nvl(versions_startscn,0);
VERSIONS_XID VERSIONS_STARTSCN VERSIONS_ENDSCN V PK NAME
03001900EE070000 3492279 3492290 I 1 andrew
02000D00E4070000 3492290 D 1 andrew
Depending upon the amount of undo retention that the database is configured to retain (undo_retention) and the activity on the table, the information returned might be extensive and the versions between syntax might need to be changed to restrict the amount of information returned.
From the information returned, it can be seen that the record was first inserted at scn 3492279 and then was deleted at scn 3492290 as part of transaction ID 02000D00E4070000. Using the transaction ID, the database should be queried to find the scope of the transaction. This is achieved by querying the flashback_transaction_query view.
SQL> select operation
, undo_sql
from flashback_transaction_query
where xid = hextoraw('02000D00E4070000');
OPERATION UNDO_SQL
DELETE insert into "SCOTT"."MASTER"("PK","NAME") values
('1','andrew');
BEGIN
Note that there is always one row returned representing the start of the transaction. In this transaction, only one row was deleted in the master table. The undo_sql column when executed will restore the original data into the table.
SQL> insert into "SCOTT"."MASTER"("PK","NAME") values ('1','andrew');
SQL> commit;
The SQL Apply engine may now be restarted and the transaction will be applied to the standby database.
SQL> alter database start logical standby apply;

Logical Standby working issues Oracle 9i, Windows

Hi,
Set up Oracle 9i Logical Standby on Windows. (instructions as per Oracle Documentation)
Did not have any issues setting up.
While setting up the Logical Standby, Recovered the Primary Database until Oct 10/09 8:16 pm
Registered the archive log in the logical standby generated hence and the FAL took care of copying/registering the rest of the archivelogs.
Created and inserted some records in Primary database and could see them in Standby.
So far so good.
On Oct11 data was entered into Primary database. Archivelogs were shipped to Standby, I could see them registered in DBA_LOGSTDBY_LOG.
The APPLIED_SCN,NEWEST_SCN were in sync as per DBA_LOGSTDBY_PROGRESS.
Today, we had some issues with data and when we queried the user tables: (no skip settings)
Couldn't see any data in standby past the recovery...
No errors reported in DBA_LOGSTDBY_EVENTS. No errors in Alert log also.
What could be happening?
Thanks,
Madhuri

I figured it out...
Today, we had some issues with data and when we queried the user tables: (no skip settings)
Couldn't see any data in standby past the recovery...I was using two tables as random spot check and both did not get updated. So, I was under the impression SQL APPLY did not do anything.
But, it did apply the redo on the rest of the tables.
These 2 tables in question were skipped because both of them had Function Based indexes.
They are very huge individual tables .
So, exporting them from Primary database and Importing them into Standby Database. Skipping DML in DataGuard.
That solved the problem.
--Madhuri

Logical Standby Data Consistency issues

Hi all,
We have been running a logical standby instance for about three weeks now. Both our primary and logical are 11g (11.1.0.7) databases running on Sun Solaris.
We have off-loaded our Discoverer reporting to the logical standby.
About three days ago, we started getting the following error message (initially for three tables, but from this morning on a whole lot more)
ORA-26787: The row with key (<coulmn>) = (<value>) does not exist in table <schema>.<table>
This error implies that we have data consistency issues between our primary and logical standby databases, but we find that hard to believe
because the "data guard" status is set to "standby", implying that schemas' being replicated by data guard are not available for user modification.
any assistance in this regard would be greatly appreciated.
thanks
Mel

It is a bug : Bug 10302680 . Apply the corresponding Patch 10302680 to your standby db.

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 Dataguard experience. Robust? Reliable?

DBAs,
Need sharing from all of your experience using logical standby Dataguard in 10gR2 or 11gR1. Do you feel that this logical standby technology requires high operational overhead (e.g. lots of problems, bugs, not so robust, error prone, etc). Transaction load is rather high for my environment.
I only use physical standby so far.
Thanks in advance

Hi - first you need to know the purpose of requiring a logical standby.
If it's for active standby - you might consider active dataguard in 11g.
Also you have to go through the doc for the list of limitation/s (regarding db objects) on logical standby - there's quite a few of them.
A well maintained/monitored system will have no additional admin overhead (maybe not initially) than the orhers.
cheers.
Lovell.

When using DataGuard, the logical standby DB is already "OPEN"?

When I was setting up the physical standby DB several years ago no DataGuard got involved), I had the impression that the standby DB is in MOUNT status.
But since when using DataGuard to set up the logical standby DB, the logical standby DB can be used as it is already OPENed.
Is it actually in OPEN status? If so, can the primary and logical standby have the same SID without any trouble?
Please help advise. Thanks a lot!

Hello Christy,
yes it is ok that both database are in status OPEN, that is also the main reason for using logical standby databases (you can do changes and queries on standby too).
I hope you don't use a logical standby database in a SAP environment, because of this is NOT supported. Check sapnote #105047 - Point "14. Data Guard". A logical standby database has limitations.
If you just want to use the physical standby database for queries you can open it in read only or you can use flashback technology for read/write. With Oracle 11g you have these features included in data guard itself (Active Data Guard / Snapshot StandBy) to perform such steps automatically.
Regards
Stefan

Dataguard logical standby issue on lacking

Similar Messages

Maybe you are looking for