ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL

I am using oracle 9.2.0.8 db version. I am trying to configure logical standby database. When I issue "ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL" i get following error.
ERROR at line 1:
ORA-01427: single-row subquery returns more than one row
ORA-06512: at line 1

Hello,
Please, have a look on the Alert log fille, and post the error message if any.
May be you'll have more information about the offending subquery.
Best regards,
Jean-Valentin

Similar Messages

Logical standby apply won't apply logs

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

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

Unable to start logical standby

Hi All,
I'm having some problems trying to start my logical standby. I managed to successfullly create a physical standby and ensured that it was collecting and applying archive logs. Running Oracle 10g on 11g Grid ASM
I then converted it to a logical and i'm getting this problem : -
SYS@Logical > ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
ERROR at line 1:
ORA-00254: error in archive control string ''
ORA-06512: at "SYS.DBMS_INTERNAL_LOGSTDBY", line 615
ORA-06512: at line 1
The following is my parameters on the logical db
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=Primary
log_archive_dest_3 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=Logical
*log_archive_dest_2 points to another physical that is working ok.
standby_archive_dest string LOCATION=USE_DB_RECOVERY_FILE_DEST
db_recovery_file_dest string +FLASH_RECOVERY_AREA
This is the only line relevant in my alert log
ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE
ORA-254 signalled during: ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE...
These are the parameters on my primary db
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=Primary
log_archive_dest_3 string SERVICE=logical LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=logical
log_archive_dest_4 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=primary
SYS@Primary > select SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI,FORCE_LOGGING from v$database;
SUP SUP FOR
YES YES YES
Can anyone tell me what i'm doing wrong? I 've looked up google and metalink and it keeps coming down to me putting in a archive parameter wrong. I don't htink i'ts on the primary, or it would have errored with the creation of the physical database.
Any help woudl be appreciated.
Thanks.

Hey Damorgan,
I should have made it clear, sorry. That isn't the syntax I used to create the parameters, that is a screen grab of the parameter with me editing it to make it easier to read. So apologies for the confusion.
To test the physical standby, I switched an archive log on the primary and then queried v$archived_log to make sure the logs were applied and compared the values between both the primary and physical. I did several log switches and it i could see it replicate on the physical.
Do you have any other suggestions on how to check for a physical standby?

Stop/start logical standby db

Version 10203 on AIX
Have to stop/start logical standby db, new to data guard, Please confirm these are the steps to do that
on primary db
SQL > alter system switch logfile ;
SQL > alter system archive log current ; ( to make sure current transactions come thru)
check tail of alert log of standby to make sure these redologs shipped & mined
standby db
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY; (stop SQL Apply)
SQL> shutdown immediate;
Lsnrctl stop listener_corp_remrpt-haprimary db
SQL > shutdown immediate ;
Lsnrctl stop listener_corp_remprd-ha
Dont shutdown abort for any case, if both dbs are going down, first stop SQL apply on standby, take primary down and then take standby down)
Startup
primary
SQL>startup;
Lsnrctl start listener_corp_remprd-ha
Standby
SQL > startup
SQL > alter database start logical standby apply immediate ;
Lsnrctl start listener_corp_remrpt-ha

Hi
As you posted ,you are using Real Time Sql apply,So,it is LGWR who transfer changes to standby site.It is very safe to follow these steps for new user.
1.Stop logical standby apply(Standby Database).
2.Shutdown Primary Database.
3.Shutdown logical standby Database.
At startup
1.Start Logical Standby Database.
2.Start Primary Database.
3.Start logical standby apply.
At the case when primary database is taking long time to shutdown processed ,You can also use
shutdown abort,but before doing abort be sure you have stop logical standby apply.When your primary database started,it automatically perform instance recovery.Primary site have to resolve gap in this case.
At the case when you must have to perform shutdown abort at primary database,you can do it.By doing it you will not loose anything.Primary database has to resolve gap and it will take time to be consistent with primary site.
Tinku

ORA-279 signalled during: ALTER DATABASE RECOVER automatic standby databas

Hi,
oracle server:8.1.7.0.0
os:solaris 5.9
we created standby server by taking coldbackup of primary server and we are using rsync to syschronize the archive log files between production and standby servers but every over we recover the standby server by executing
sql>recover automatic standby database:
but in alert log file i am getting the following error :
but when i googled for ora-279 error some people says it is default behaviour and can it be ignored and why it is asking next logfile.
Media Recovery Log /oratranslog/arch_1_1701118.arc
Wed Mar 26 21:35:34 2008
Media Recovery Log /oratranslog/arch_1_1701119.arc
Wed Mar 26 21:35:54 2008
Media Recovery Log /oratranslog/arch_1_1701120.arc
ORA-279 signalled during: ALTER DATABASE RECOVER automatic standby database...
Wed Mar 26 21:36:24 2008
ALTER DATABASE RECOVER CANCEL
Wed Mar 26 21:36:24 2008
Media Recovery Cancelled
Completed: ALTER DATABASE RECOVER CANCEL
Thanks and Regards
Prakash
juniour oracle dba

damorgan,
He is running 8.1.7.0. "DataGuard" scripts were initially available for 9i and then
backported (and available as a seperate download) for 8i. Many 8i implementations
did not and do not use DataGuard.
Even if it is "Jurassic" {which it certainly is NOT}, they obviously do have a good
reason for setting up a standby -- they DO have data of value. So, maybe they have
not upgraded to 9i or 10g. There could be a dozen reasons
1. Server HW/OS doesn't support 9i/10g, not budgetting for Server upgrade
2. Application using Forms 2.x or 4.5 and not tested on 9i / 10g (4.5 not certified
on 9i)
3. Low end client PCs working perfectly with Character-mode forms, not powerful
enought to run Jinitiator and Forms 6i / 9i
Just because someone hasn't upgraded to 10g doesn't mean that they are at fault
when you do NOT know the reason why they have not upgraded.
Surely, they do know that 8i is desupported. Don't you think that their management
has undertaken due diligence / cost-benefit analysis in considering whether they
should upgrade to 10g ?
Maybe they have another project implementing 10g in parallel and will be able
to shutdown this environment soon. Maybe they don't need to do so.
Do understand that people are intelligent enough to make their own decisions
considering their particular circumstances and don't go shooting off with your
assumption that anyone not running 10g is a dinosaur.

ALTER DATABASE RECOVER MANAGE STANDBY DATABASE

During the creation of Logical Standby database (NOAA2), after issuing the statement:
"ALTER DATABASE RECOVER MANAGE STANDBY DATABASE"
the following error appears:
FAL[server, ARC1]: Complete FAL noexpedite archive (thread 1 sequence 46 destination NOAA2)
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3113 when pinging standby NOAA2.
Can someone please shed any light on the problem.
Thank you.

Perform these steps on Standby and see if it works
%lsnrctl stop
%lsnrctl start

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

Hi,
on 10g R2, how to know if :
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT;
is already applied ?
thank you.

user522961 wrote:
thanks to all.
Should I issue the following and others on standby or on primary ?
select process,status from v$managed_standby;
Regards.You need execute that from standby instance.In additionally you can see standby instances alert.log.And if this process is active then if you execute this command again then you will get an error like "Media recover is active".

Physical standby database to Logical standby

Can I convert a physical standby database to Logical standby,

Go Through Below link
>>>Can you convert a Logical standby to a Physical Standby?

Apply Patches on Oracle Database with Logical Standby Database

Here I am:
I got a primary database with a logical standby database running Oracle 11g. I got two client applications, one is the production site pointing to the primary one, another one is just a backup site pointing to the logical one.Things will only be written into the primary database every mid night and client applications can only query the database but not add, update nor delete.And now, I want to apply the latest patch on both of my databases. I am also the DNS administrator, I can make the name server pointing to the backup site instead of the production one.I want to firstly apply the patch on the logical one, and then the physical one.
I found some reference which explains how to apply patches by adopting "Rolling Upgrade Method". however, I want to avoid doing any "switch over" mentioned in the reference because I can make use of name server. Can I just apply patches as the following way?
1)Stop SQL apply
2)Apply patches on logical standby database
3)let the name server point to the backup site
4)Apply patches on the primary database
5)Start SQL apply
6)Let the name server point back to the production site
Thanks in advance.

Pl follow the steps in MOS Doc 437276.1 ( Upgrading Oracle Database with a Logical Standby Database In Place )
HTH
Srini

Logical Standby Apply Process Performance

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

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

Logical Standby 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

Physical Standby database Vs. Logical Standby database

I have few questions regarding capability of Logical Standby Database against Physical Standby database.
1. How efficient is Logical Standby database in terms of Physical Standby Database?? How both differ from each other and can I use Logical Standby Database for disaster Recovery?? Can It be use for recovering the failed Primary Instance?? If yes how efficient and reliable it is??
2. What are the known bugs and roadblocks for logical standby database on Oracle 10.2.0.1 on Soalris X86-64?
3.As logical standby database not going to replicate each and every schema of Primary database?? how is the change management effects to the logical standby from primary?? I mean there are some parameters and job that we create on primary how can it be transferred over to the logical standby??

1. How efficient is Logical Standby database in terms
of Physical Standby Database?? How both differ from
each other and can I use Logical Standby Database for
disaster Recovery?? Can It be use for recovering the
failed Primary Instance?? If yes how efficient and
reliable it is??I'm not sure what sort of "efficiency" you're talking about here...
Physical standby is just the old, tried and true application of archived logs to recover a database. Very solid, very old school.
Logical standby, on the other hand, is parsing the redo log, extracting logical change records, and applying them to the standby database. This obviously takes a bit more processing effort, it's newer technology, it doesn't have quite the level of support that physical standby does (i.e. certain data types are excluded), etc. You certainly can use it for failover, but it isn't quite as robust as a physical standby. Of course, this is getting better and better all the time and is definitely a focus of Oracle's development efforts.
On the other hand, logical standby systems can do things other than act as a warm standby. They can be open serving reports, for example. You can create additional structures (i.e. new materialized views) to support reporting. A physical standby is pretty much always going to be in managed recovery mode, so it cannot be queried.
2. What are the known bugs and roadblocks for logical
standby database on Oracle 10.2.0.1 on Soalris
X86-64?a) You'll want to do a Metalink search
b) If you're talking about a high-availability solution, why are you looking at a base release of the database? Why wouldn't you apply the latest patchset?
3.As logical standby database not going to replicate
each and every schema of Primary database?? how is
the change management effects to the logical standby
from primary?? I mean there are some parameters and
job that we create on primary how can it be
transferred over to the logical standby??I'm not sure I understand... Changes made to the primary generate redo. Oracle parses that redo, generates a LCR, and sends that to the standby database where that change record gets applied.
Justin

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 Apply Processes Die when granting a user sysdba on Primary

I've run into an issue where the sql apply processes are stopping when granting a user sysdba privilege on the primary.
The error is insufficient privileges.
Of course the workaround that we have used is to skip the transaction on the logical and then manually grant the sysdba privilege on the standby. I'm hoping there is a more elegant solution as I have 8 DBAs on my team and each on of the transactions will need to be skipped individually, and is a bit of a pain. Just thought I would ask if anyone out there has run into the same issue and has a better workaround.

I think you misunderstand. We run our standby in guard_mode 'STANDBY', which allows sys to perform the grant operation directly on the logical. Where it is failing is when we grant on the primary. That or I misunderstand. Are you saying that if I put in the script on the primary, the alter session command, then it will propagate down cleanly? That is something I have not tried of course, but makes sense how that could work, unless it throws an error on the primary because it is not a standby.

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

ALTER DATABASE START LOGICAL STANDBY APPLY INITIAL

Similar Messages

Maybe you are looking for