Standby database Error in applying archives

Hi All
Environment:
Oracle 8i
Platform- HP-UX
I have production database on HPUX box and standby database on anothe HPUX box.
I am applying archive to standby everyday manually.
In last week, I have added ney datafile webapp03 in Production database tablespace.
When I apply archive to standby database. It says archive apply sucessfully but give below warning:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01195: online backup of file 25 needs more recovery to be consistent
ORA-01110: data file 25: '/u06/oradata/vestcom/webapp03.dbf'
Yesterday I have copied datafile from production to standby database.
But still I am getting same warning:
Please let me know in detail, I am totally new in this admin field.
Please help me out for this issue:
Thanks in Advance.
R M

Absolutely. First place the tablespace space in backup mode, then copy over the datafile and then end the backup mode - applying the log files should be fine now.
HTH
Thanks
Chandra

Similar Messages

Physical standby database error

Hi,
I try to create physical standby in my local machine using oracle 10g
version :10.2.0.1.0
Os: windows xp.
I followed steps and parameter files
on primary :-
sql>alter database force logging;
orcl.__db_cache_size=155189248
orcl.__java_pool_size=4194304
orcl.__large_pool_size=4194304
orcl.__shared_pool_size=75497472
orcl.__streams_pool_size=0
*.audit_file_dest='D:\oracle\product\10.2.0/admin/orcl/adump'
*.background_dump_dest='D:\oracle\product\10.2.0/admin/orcl/bdump'
*.compatible='10.2.0.1.0'
*.control_files='D:\oracle\product\10.2.0\oradata\orcl\control01.ctl','D:\oracl
e\product\10.2.0\oradata\orcl\control02.ctl','D:\oracle\product\10.2.0\orad
ata\orcl\control03.ctl'
*.core_dump_dest='D:\oracle\product\10.2.0/admin/orcl/cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_unique_name='orcl'
*.log_archive_config='DG_CONFIG=(orcl,stby)'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=80740352
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.sga_target=244318208
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\oracle\product\10.2.0/admin/orcl/udump'
*.log_archive_dest_1='LOCATION=D:\oracle\archive
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'
*.log_archive_dest_2='SERVICE=stby LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stby'
*.log_archive_format=%t_%s_%r.arc
*.log_archive_dest_state_1=ENABLE
*.log_archive_dest_state_2=ENABLE
On standby
orcl.__db_cache_size=155189248
orcl.__java_pool_size=4194304
orcl.__large_pool_size=4194304
orcl.__shared_pool_size=75497472
orcl.__streams_pool_size=0
*.audit_file_dest='D:\stby\adump'
*.background_dump_dest='D:\stby\bdump'
*.compatible='10.2.0.1.0'
*.control_files='D:\stby\ctrl.ctl'
*.core_dump_dest='D:\stby\cdump'
*.db_block_size=8192
*.db_domain=''
*.db_file_multiblock_read_count=16
*.db_name='orcl'
*.db_unique_name='stby'
*.log_archive_config='DG_CONFIG=(orcl,stby)'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=orclXDB)'
*.job_queue_processes=10
*.open_cursors=300
*.pga_aggregate_target=80740352
*.processes=150
*.remote_login_passwordfile='NONE'
*.sga_target=244318208
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\stby\udump'
*.db_file_name_convert='D:\oracle\product\10.2.0\oradata\orcl','D:\stby'
*.log_file_name_convert='D:\oracle\product\10.2.0\oradata\orcl','D:\stby'
*.log_archive_dest_1='LOCATION=D:\oracle\archive
VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stby'
*.log_archive_dest_2='SERVICE=orcl LGWR ASYNC
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=orcl'
*.standby_archive_dest='D:\stby\archive'
*.log_archive_dest_state_1=ENABLE
*.log_archive_dest_state_2=ENABLE
*.standby_file_management='AUTO'
*.fal_server='orcl'
*.fal_client='stby'
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup pfile=D:\stby\initstby.ora nomount;
ORACLE instance started.
Total System Global Area 247463936 bytes
Fixed Size 1248332 bytes
Variable Size 79692724 bytes
Database Buffers 159383552 bytes
Redo Buffers 7139328 bytes
SQL> alter database mount standby database;
Database altered.
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-01154: database busy. Open, close, mount, and dismount not allowed now
SQL> recover managed standby database cancel;
Media recovery complete.
SQL> alter database open read only;
Database altered.
SQL> select sequence#,first_time,next_time from v$archived_log order by sequence
no rows selected
No archive s generated in standby ..
what i mistake.
Reagrds
S.Azar

Anand... wrote:
Firstly you can use "*select sequence#,first_time,next_time from v$archived_log order by sequence#;"* command in mount stage itself.No need to open the standby database in ready only mode.
No rows selected in mount stage also.
The V$ARCHIVED_LOG fixed view on the physical standby database shows all the archived redo log files received from the primary database.
sql> select * from v$archived_log;
no rows selected.
and No archived logs received from primary database to physical standby . i think here i wrongly configure parameter file.
sql> RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION; -- > start Redo Apply
When you do log switch on the primary are the archive logs getting transferred to the standby database???Is there some error in the alert log file in the primary database.
No..
>
[http://advait.wordpress.com/2007/06/12/setting-up-oracle-dataguard-for-10g/]
Regards
S.Azar

Standby database is not applying redo logs due to missing archive log

We use 9.2.0.7 Oracle Database. My goal is to create a physical standby database.
I have followed all the steps necessary to fulfill this in Oracle Data Guard Concepts and Administration manual. Archived redo logs are transmitted from primary to standby database regularly. But the logs are not applied due to archive log gap.
SQL> select process, status from v$managed_standby;
PROCESS STATUS
ARCH CONNECTED
ARCH CONNECTED
MRP0 WAIT_FOR_GAP
RFS RECEIVING
RFS ATTACHED
SQL> select * from v$archive_gap;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
1 503 677
I have tried to find the missing archives on the primary database, but was unable to. They have been deleted (somehow) regularly by the existing backup policy on the primary database. I have looked up the backups, but these archive logs are too old to be in the backup. Backup retention policy is 1 redundant backup of each file. I didn't save older backups as I didn't really need them from up to this point.
I have cross checked (using rman crosscheck) the archive log copies on the primary database and deleted the "obsolete" copies of archive logs. But, v$archived_log view on the primary database only marked those entries as "deleted". Unfortunately, the standby database is still waiting for those logs to "close the gap" and doesn't apply the redo logs at all. I am reluctant to recreate the control file on the primary database as I'm afraid this occurred through the regular database backup operations, due to current backup retention policy and it probably might happen again.
The standby creation procedure was done by using the data files from 3 days ago. The archive logs which are "producing the gap" are older than a month, and are probably unneeded for standby recovery.
What shall I do?
Kind regards and thanks in advance,
Milivoj

On a physical standby database
To determine if there is an archive gap on your physical standby database, query the V$ARCHIVE_GAP view as shown in the following example:
SQL> SELECT * FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
1 7 10
The output from the previous example indicates your physical standby database is currently missing log files from sequence 7 to sequence 10 for thread 1.
After you identify the gap, issue the following SQL statement on the primary database to locate the archived redo log files on your primary
database (assuming the local archive destination on the primary database is LOG_ARCHIVE_DEST_1):
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND 2> SEQUENCE# BETWEEN 7 AND 10;
NAME
/primary/thread1_dest/arcr_1_7.arc /primary/thread1_dest/arcr_1_8.arc /primary/thread1_dest/arcr_1_9.arc
Copy these log files to your physical standby database and register them using the ALTER DATABASE REGISTER LOGFILE statement on your physical standby database. For example:
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_7.arc';
SQL> ALTER DATABASE REGISTER LOGFILE
'/physical_standby1/thread1_dest/arcr_1_8.arc';
After you register these log files on the physical standby database, you can restart Redo Apply.
Note:
The V$ARCHIVE_GAP fixed view on a physical standby database only returns the next gap that is currently blocking Redo Apply from continuing. After resolving the gap and starting Redo Apply, query the V$ARCHIVE_GAP fixed view again on the physical standby database to determine the next gap sequence, if there is one. Repeat this process until there are no more gaps.
Restoring the archived logs from the backup set
If the archived logs are not available in the archive destination then at that time we need to restore the required archived logs from the backup step. This task is accomplished in the following way.
To restore range specified archived logs:
Run {
Set archivelog destination to '/oracle/arch/arch_restore'
Restore archivelog from logseq=<xxxxx> until logseq=<xxxxxxx>
To restore all the archived logs:
Run {
Set archivelog destination to '/oracle/arch/arch_restore';
Restore archivelog all;
}

Standby database errors - Alter database open read only

alter database open read only
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Signalling error 1152 for datafile 1!
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Waiting for thread 1 sequence 216
Mon Dec 20 11:58:18 2010
Standby crash recovery need archive log for thread 1 sequence 216 to continue.
Please verify that primary database is transporting redo logs to the standby database.
Wait timeout: thread 1 sequence 216
Standby crash recovery aborted due to error 16016.
Errors in file /u01/app/oracle/diag/rdbms/mdm2/MDM2/trace/MDM2_ora_17442.trc:
ORA-16016: archived log for thread 1 sequence# 216 unavailable
Recovery interrupted!
Completed standby crash recovery.
Signalling error 1152 for datafile 1!
Errors in file /u01/app/oracle/diag/rdbms/mdm2/MDM2/trace/MDM2_ora_17442.trc:
ORA-10458: standby database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+MDMDG1/mdm2/datafile/system.280.738243341'
ORA-10458 signalled during: alter database open read only...
Mon Dec 20 12:13:46 2010
ALTER DATABASE RECOVER managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (MDM2)
Mon Dec 20 12:13:46 2010
MRP0 started with pid=23, OS id=18974
MRP0: Background Managed Standby Recovery process started (MDM2)
started logmerger process
Mon Dec 20 12:13:51 2010
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Waiting for thread 1 sequence 216
Completed: ALTER DATABASE RECOVER managed standby database using current logfile disconnect
The above lines are from alert log of standby database.
Standby standbase
SQL> alter database open read only;
alter database open read only
ERROR at line 1:
ORA-10458: standby database requires recovery
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+MDMDG1/mdm2/datafile/system.280.738243341'
Parameters set on primary are
log_archive_dest_1 LOCATION=+MDMDG3/MDM1/ARCH VALID_FOR=(ALL_LOGFILES,ALL_ROLE ) DB_UNIQUE_NAME=MDM1
log_archive_dest_state_1 ENABLE
log_archive_dest_2 SERVICE=MDM2 SYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=MDM2
log_archive_dest_state_2 ENABLE
dg_broker_config_file1 +MDMDG2/mdm/dg_config/dgconfig1_mdm.dat
dg_broker_config_file2 +MDMDG2/mdm/dg_config/dgconfig2_mdm.dat
fal_server MDM2
standby_file_management AUTO
log_archive_config dg_config=(MDM1,MDM2)
db_file_name_convert MDM2, MDM1
ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE availability ;
Standby pfile
*.archive_lag_target=900
*.audit_file_dest='/u01/app/oracle/admin/MDM2/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='+MDMDG1/MDM2/CONTROLFILE/controlfile01.ctl','+MDMDG2/MDM2/CONTROLFILE/controlfile02.ctl'
*.db_block_size=8192
*.db_create_file_dest='+MDMDG1'
*.db_domain=''
*.db_file_name_convert='MDM1','MDM2'
*.db_name='MDM'
*.db_recovery_file_dest='+MDMDG2'
*.db_recovery_file_dest_size=10485760000
*.db_unique_name='MDM2'
*.dg_broker_config_file1='+MDMDG2/MDM/DG_CONFIG/dgconfig1_MDM.dat'
*.dg_broker_config_file2='+MDMDG2/MDM/DG_CONFIG/dgconfig2_MDM.dat'
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=MDM2XDB)'
*.fal_server='MDM11','MDM12'
*.instance_name='MDM2'
*.log_archive_config='dg_config=(MDM1,MDM2)'
*.log_archive_dest_1='LOCATION=+MDMDG3/MDM2/ARCH VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=MDM2'
*.log_archive_dest_2='SERVICE=MDM1 ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=MDM1'
*.log_archive_dest_state_1='ENABLE'
*.log_archive_dest_state_2='ENABLE'
*.log_archive_format='MDM_%t_%s_%r.arc'
*.log_file_name_convert='MDM1','MDM2'
*.memory_target=838860800
*.nls_language='ENGLISH'
*.nls_territory='UNITED KINGDOM'
*.open_cursors=300
*.processes=500
*.remote_login_passwordfile='exclusive'
*.sessions=555
*.standby_file_management='AUTO'
*.undo_tablespace='UNDOTBS1'
On standby ASM
ASMCMD [+] > find * *
+MDMDG1/ASM/
+MDMDG1/ASM/ASMPARAMETERFILE/
+MDMDG1/ASM/ASMPARAMETERFILE/REGISTRY.253.737811541
+MDMDG1/MDM/
+MDMDG1/MDM2/
+MDMDG1/MDM2/CONTROLFILE/
+MDMDG1/MDM2/CONTROLFILE/controlfile01.ctl
+MDMDG1/MDM2/CONTROLFILE/current.265.738243333
+MDMDG1/MDM2/DATAFILE/
+MDMDG1/MDM2/DATAFILE/CANVAS_POPULARITY_DATA.264.738243343
+MDMDG1/MDM2/DATAFILE/CANVAS_POPULARITY_IDX.277.738243343
+MDMDG1/MDM2/DATAFILE/MDM_SRC_DATA.282.738243343
+MDMDG1/MDM2/DATAFILE/MDM_SRC_IDX.275.738243343
+MDMDG1/MDM2/DATAFILE/MIPS_MDM_DATA.283.738243341
+MDMDG1/MDM2/DATAFILE/MIPS_MDM_IDX.276.738243343
+MDMDG1/MDM2/DATAFILE/SYSAUX.281.738243341
+MDMDG1/MDM2/DATAFILE/SYSTEM.280.738243341
+MDMDG1/MDM2/DATAFILE/TEST_TBSP1.273.738243345
+MDMDG1/MDM2/DATAFILE/TEST_TBSP2.272.738243345
+MDMDG1/MDM2/DATAFILE/UNDOTBS1.256.738243343
+MDMDG1/MDM2/DATAFILE/UNDOTBS2.279.738243343
+MDMDG1/MDM2/DATAFILE/USERS.278.738243347
+MDMDG1/MDM2/ONLINELOG/
+MDMDG1/MDM2/ONLINELOG/group_1.259.738243429
+MDMDG1/MDM2/ONLINELOG/group_2.257.738243431
+MDMDG1/MDM2/ONLINELOG/group_21.284.738243505
+MDMDG1/MDM2/ONLINELOG/group_22.261.738243505
+MDMDG1/MDM2/ONLINELOG/group_23.274.738243505
+MDMDG1/MDM2/ONLINELOG/group_3.258.738243431
+MDMDG1/MDM2/ONLINELOG/group_31.262.738243513
+MDMDG1/MDM2/ONLINELOG/group_32.270.738243513
+MDMDG1/MDM2/ONLINELOG/group_33.263.738243513
+MDMDG1/MDM2/ONLINELOG/group_4.260.738243431
+MDMDG2/MDM/
+MDMDG2/MDM/DG_CONFIG/
+MDMDG2/MDM2/
+MDMDG2/MDM2/AUTOBACKUP/
+MDMDG2/MDM2/AUTOBACKUP/2010_12_20/
+MDMDG2/MDM2/AUTOBACKUP/2010_12_20/s_738242861.263.738244155
+MDMDG2/MDM2/CONTROLFILE/
+MDMDG2/MDM2/CONTROLFILE/controlfile02.ctl
+MDMDG2/MDM2/CONTROLFILE/current.271.738243335
+MDMDG2/MDM2/ONLINELOG/
+MDMDG2/MDM2/ONLINELOG/group_1.270.738243429
+MDMDG2/MDM2/ONLINELOG/group_2.269.738243431
+MDMDG2/MDM2/ONLINELOG/group_21.268.738243505
+MDMDG2/MDM2/ONLINELOG/group_22.272.738243505
+MDMDG2/MDM2/ONLINELOG/group_23.262.738243505
+MDMDG2/MDM2/ONLINELOG/group_3.273.738243431
+MDMDG2/MDM2/ONLINELOG/group_31.266.738243513
+MDMDG2/MDM2/ONLINELOG/group_32.265.738243513
+MDMDG2/MDM2/ONLINELOG/group_33.264.738243513
+MDMDG2/MDM2/ONLINELOG/group_4.261.738243431
+MDMDG3/MDM/
+MDMDG3/MDM/ARCH/
+MDMDG3/MDM2/
+MDMDG3/MDM2/ARCH/
-- Please can I know how to open read only standby database.

user5846399 wrote:
ORA-16016: archived log for thread 1 sequence# 216 unavailable
Recovery interrupted!archived log for thread 1 sequence# 216
This file is needed for recovery, Find it and move it to the standby database side.

Standby database error

Hi Guys..
I am using oracle 10.2.0.4.0 on windows 2003 server. I created a physical standby database successfully.
On standby database, I fired the following query
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#
SEQUENCE# FIRST_TIM NEXT_TIME
10715 02-AUG-10 02-AUG-10
10716 02-AUG-10 02-AUG-10
10717 02-AUG-10 03-AUG-10
10718 03-AUG-10 03-AUG-10
10719 03-AUG-10 03-AUG-10
10720 03-AUG-10 03-AUG-10
10721 03-AUG-10 03-AUG-10
10722 03-AUG-10 03-AUG-10
10723 03-AUG-10 03-AUG-10
10724 03-AUG-10 03-AUG-10
10725 03-AUG-10 03-AUG-10
SEQUENCE# FIRST_TIM NEXT_TIME
10726 03-AUG-10 03-AUG-10
10727 03-AUG-10 03-AUG-10
10728 03-AUG-10 03-AUG-10
10729 03-AUG-10 03-AUG-10
I then did alter system switch logfile on primary database
Then on standby I fired the above query
SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#
SEQUENCE# FIRST_TIM NEXT_TIME
10715 02-AUG-10 02-AUG-10
10716 02-AUG-10 02-AUG-10
10717 02-AUG-10 03-AUG-10
10718 03-AUG-10 03-AUG-10
10719 03-AUG-10 03-AUG-10
10720 03-AUG-10 03-AUG-10
10721 03-AUG-10 03-AUG-10
10722 03-AUG-10 03-AUG-10
10723 03-AUG-10 03-AUG-10
10724 03-AUG-10 03-AUG-10
10725 03-AUG-10 03-AUG-10
SEQUENCE# FIRST_TIM NEXT_TIME
10726 03-AUG-10 03-AUG-10
10727 03-AUG-10 03-AUG-10
10728 03-AUG-10 03-AUG-10
10729 03-AUG-10 03-AUG-10
*10730 03-AUG-10 03-AUG-10*
My question is everytime I do alter systyem switch logfile on primary , two trace files are generated on primary database which are:
stutest_lns1_5764.trc
Dump file c:\oracle\admin\stutest\bdump\stutest_lns1_5764.trc
Tue Aug 03 15:50:35 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows Server 2003 Version V5.2 Service Pack 2
CPU : 8 - type 8664, 2 Physical Cores
Process Affinity : 0x0000000000000000
Memory (Avail/Total): Ph:8414M/16378M, Ph+PgF:10750M/17814M
Instance name: stutest
Redo thread mounted by this instance: 1
Oracle process number: 43
Windows thread id: 5764, image: ORACLE.EXE (LNS1)
*** SERVICE NAME:(SYS$BACKGROUND) 2010-08-03 15:50:35.996
*** SESSION ID:(213.29604) 2010-08-03 15:50:35.996
*** 2010-08-03 15:50:35.996 60512 kcrr.c
LNS1: initializing for LGWR communication
LNS1: connecting to KSR channel
Success
LNS1: subscribing to KSR channel
Success
*** 2010-08-03 15:50:35.996 60565 kcrr.c
LNS1: initialized successfully ASYNC=1
Destination is specified with ASYNC=61440
Redo shipping client performing standby login
*** 2010-08-03 15:50:36.043 68145 kcrr.c
Logged on to standby successfully
Client logon and security negotiation successful!
Archiving to destination STUSTDBY ASYNC blocks=20480
Allocate ASYNC blocks: Previous blocks=0 New blocks=20480
Log file opened [logno 2]
*** 2010-08-03 16:00:58.344
Archiving to destination STUSTDBY ASYNC blocks=20480
Log file opened [logno 1]
*** 2010-08-03 16:04:44.383
Archiving to destination STUSTDBY ASYNC blocks=20480
Log file opened [logno 3]
*** 2010-08-03 16:07:36.794
Archiving to destination STUSTDBY ASYNC blocks=20480
Log file opened [logno 2]
stutest_lgwr_4092.trc
Dump file c:\oracle\admin\stutest\bdump\stutest_lgwr_4092.trc
Fri Jul 30 17:01:59 2010
ORACLE V10.2.0.4.0 - 64bit Production vsnsta=0
vsnsql=14 vsnxtr=3
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows Server 2003 Version V5.2 Service Pack 2
CPU : 8 - type 8664, 2 Physical Cores
Process Affinity : 0x0000000000000000
Memory (Avail/Total): Ph:13601M/16378M, Ph+PgF:10927M/17814M
Instance name: stutest
Redo thread mounted by this instance: 1
Oracle process number: 6
Windows thread id: 4092, image: ORACLE.EXE (LGWR)
*** 2010-07-30 17:01:59.622
*** SERVICE NAME:() 2010-07-30 17:01:59.606
*** SESSION ID:(221.1) 2010-07-30 17:01:59.606
Maximum redo generation record size = 156160 bytes
Maximum redo generation change vector size = 150676 bytes
*** 2010-07-30 22:01:00.446
Warning: log write time 770ms, size 2KB
*** 2010-07-30 22:08:37.586
Warning: log write time 1120ms, size 9KB
*** 2010-07-30 22:08:41.258
Warning: log write time 680ms, size 7KB
*** 2010-07-30 22:09:58.244
Warning: log write time 660ms, size 1KB
*** 2010-07-30 22:11:21.388
Warning: log write time 860ms, size 6KB
*** 2010-07-30 23:42:11.203
Warning: log write time 580ms, size 1KB
*** 2010-07-31 00:04:13.917
Warning: log write time 980ms, size 8KB
*** 2010-07-31 00:06:40.422
Warning: log write time 930ms, size 22KB
*** 2010-07-31 00:08:11.940
Warning: log write time 1800ms, size 23KB
*** 2010-07-31 21:13:33.694
Warning: log write time 1460ms, size 40KB
*** 2010-07-31 21:13:39.522
Warning: log write time 2790ms, size 87KB
*** 2010-07-31 21:13:46.054
Warning: log write time 4940ms, size 69KB
*** 2010-07-31 21:13:50.038
Warning: log write time 3980ms, size 81KB
*** 2010-07-31 21:13:55.616
Warning: log write time 5580ms, size 61KB
*** 2010-07-31 21:14:01.726
Warning: log write time 6110ms, size 77KB
*** 2010-07-31 21:14:08.258
Warning: log write time 3530ms, size 140KB
*** 2010-07-31 21:14:19.508
Warning: log write time 1500ms, size 3KB
*** 2010-07-31 22:07:49.954
Warning: log write time 930ms, size 1KB
*** 2010-07-31 23:16:01.054
Warning: log write time 1080ms, size 103KB
*** 2010-07-31 23:17:52.854
Warning: log write time 1360ms, size 3KB
*** 2010-07-31 23:23:26.631
Warning: log write time 710ms, size 2KB
*** 2010-08-01 00:04:58.476
Warning: log write time 690ms, size 13KB
*** 2010-08-01 00:06:51.980
Warning: log write time 590ms, size 20KB
*** 2010-08-01 00:07:38.153
Warning: log write time 1540ms, size 28KB
*** 2010-08-01 00:08:02.748
Warning: log write time 770ms, size 64KB
*** 2010-08-01 00:11:04.628
Warning: log write time 1140ms, size 43KB
*** 2010-08-01 17:05:49.886
Warning: log write time 780ms, size 3KB
*** 2010-08-01 21:00:46.571
Warning: log write time 910ms, size 365KB
*** 2010-08-01 21:09:22.447
Warning: log write time 2910ms, size 22KB
*** 2010-08-01 21:09:27.932
Warning: log write time 4430ms, size 62KB
*** 2010-08-01 21:09:34.010
Warning: log write time 6060ms, size 74KB
*** 2010-08-01 21:09:40.088
Warning: log write time 3080ms, size 150KB
*** 2010-08-01 21:09:45.495
Warning: log write time 2410ms, size 99KB
*** 2010-08-01 21:09:50.370
Warning: log write time 4870ms, size 40KB
*** 2010-08-01 21:09:55.401
Warning: log write time 5030ms, size 82KB
*** 2010-08-01 21:09:59.151
Warning: log write time 3610ms, size 65KB
*** 2010-08-01 23:05:40.560
Warning: log write time 720ms, size 4KB
*** 2010-08-01 23:06:05.030
Warning: log write time 1670ms, size 21KB
*** 2010-08-01 23:17:55.537
Warning: log write time 1540ms, size 116KB
*** 2010-08-01 23:23:35.891
Warning: log write time 600ms, size 1KB
*** 2010-08-02 00:05:52.363
Warning: log write time 1340ms, size 48KB
*** 2010-08-02 00:06:43.427
Warning: log write time 1060ms, size 24KB
*** 2010-08-02 00:06:50.177
Warning: log write time 1730ms, size 209KB
*** 2010-08-02 00:07:08.256
Warning: log write time 950ms, size 17KB
*** 2010-08-02 00:11:25.436
Warning: log write time 1690ms, size 8KB
*** 2010-08-02 00:12:11.313
Warning: log write time 850ms, size 45KB
*** 2010-08-02 00:13:55.754
Warning: log write time 560ms, size 3KB
*** 2010-08-02 11:27:52.686
Warning: log write time 1440ms, size 46KB
*** 2010-08-02 11:27:58.780
Warning: log write time 3790ms, size 54KB
*** 2010-08-02 11:28:02.546
Warning: log write time 3760ms, size 70KB
*** 2010-08-02 11:28:08.483
Warning: log write time 5940ms, size 74KB
*** 2010-08-02 11:28:13.812
Warning: log write time 2330ms, size 139KB
*** 2010-08-02 11:28:18.796
Warning: log write time 1980ms, size 79KB
*** 2010-08-02 11:28:25.093
Warning: log write time 3360ms, size 88KB
*** 2010-08-02 11:28:29.421
Warning: log write time 4330ms, size 38KB
*** 2010-08-02 16:10:45.927
Warning: log write time 590ms, size 3KB
*** 2010-08-02 22:08:57.806
Warning: log write time 700ms, size 37KB
*** 2010-08-02 23:07:22.262
Warning: log write time 1750ms, size 234KB
*** 2010-08-02 23:13:44.993
Warning: log write time 1410ms, size 17KB
*** 2010-08-03 00:04:08.387
Warning: log write time 670ms, size 6KB
*** 2010-08-03 00:07:44.347
Warning: log write time 1890ms, size 1024KB
*** 2010-08-03 00:08:14.395
Warning: log write time 1680ms, size 1024KB
*** 2010-08-03 00:08:26.817
Warning: log write time 570ms, size 36KB
*** 2010-08-03 00:08:39.427
Warning: log write time 1540ms, size 1024KB
*** 2010-08-03 00:08:50.818
Warning: log write time 1810ms, size 1025KB
*** 2010-08-03 00:08:58.990
Warning: log write time 1640ms, size 942KB
*** 2010-08-03 00:09:21.303
Warning: log write time 1580ms, size 1024KB
*** 2010-08-03 00:09:33.710
Warning: log write time 1790ms, size 1025KB
*** 2010-08-03 00:09:42.382
Warning: log write time 1860ms, size 1024KB
*** 2010-08-03 00:09:50.945
Warning: log write time 1590ms, size 1024KB
*** 2010-08-03 10:28:34.753
Warning: log write time 2330ms, size 47KB
*** 2010-08-03 10:29:44.440
Warning: log write time 810ms, size 1KB
*** 2010-08-03 10:32:27.392
Warning: log write time 890ms, size 1KB
*** 2010-08-03 10:36:02.536
Warning: log write time 2070ms, size 8KB
*** 2010-08-03 10:44:34.174
Warning: log write time 740ms, size 7KB
*** 2010-08-03 12:04:46.687
Warning: log write time 2850ms, size 86KB
*** 2010-08-03 12:04:52.656
Warning: log write time 2970ms, size 85KB
*** 2010-08-03 12:04:54.547
Warning: log write time 1810ms, size 45KB
*** 2010-08-03 14:06:20.827
Warning: log write time 500ms, size 0KB
*** 2010-08-03 14:13:46.404
Warning: log write time 820ms, size 0KB
*** 2010-08-03 15:50:32.996
*** 2010-08-03 15:50:32.996 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
Initializing PGA storage for Netserver communication
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
.. yes it needs to be started
Starting LNS1 ...
Subscribing to KSR Channel [id=1]
success!
Indicating recv buffer for KSR Channel [id=1]
success
Waiting for LNS1 to initialize itself
*** 2010-08-03 15:50:36.012 57343 kcrr.c
Netserver LNS1 [pid 5764] for mode ASYNC has been initialized
Performing a channel reset to ignore previous responses
Connecting as publisher to KSR Channel [id=1]
Successfully started LNS1 [pid 5764] for dest STUSTDBY mode ASYNC ocis=0x00000000144AE5B0
*** 2010-08-03 15:50:36.012 57846 kcrr.c
Making upiahm request to LNS1 [pid 5764]: Begin Time is <08/03/2010 15:50:32>. NET_TIMEOUT = <10> seconds
*** 2010-08-03 16:00:58.266
*** 2010-08-03 16:00:58.266 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
Previous Async LNS1 [pid 5764] is running .. no need to start another one
LGWR detected that Async LNS1 [pid 5764] is already running
*** 2010-08-03 16:04:44.289
*** 2010-08-03 16:04:44.289 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
Previous Async LNS1 [pid 5764] is running .. no need to start another one
LGWR detected that Async LNS1 [pid 5764] is already running
*** 2010-08-03 16:07:36.747
*** 2010-08-03 16:07:36.747 57052 kcrr.c
Initializing NetServer[LNS1] for dest=STUSTDBY mode ASYNC
LNSb is not running anymore.
Check if new Async LNS1 needs to be started..
Previous Async LNS1 [pid 5764] is running .. no need to start another one
LGWR detected that Async LNS1 [pid 5764] is already running
*** 2010-08-03 16:13:06.633
Warning: log write time 570ms, size 0KB
Did I miss something while creating standby.???
Thanks for the help

are these databases on same server.
BTW These are not errors, they are warning ... I have also seen these kind of warning many times. they can be ignored if ur shipping and recovery on standby is Preperly happening.
Regards
jasbir

Recover standby database error

Hi
here is the error message i got when i run this command
09:30:35 SYS@MOZAI> alter database recover standby database until cancel;
alter database recover standby database until cancel
ERROR at line 1:
ORA-00279: change 126425376421 generated at 02/26/2012 09:26:00 needed for thread 2
ORA-00289: suggestion : +ARCH
ORA-00280: change 126425376421 for thread 2 is in sequence #312362
Any suggestion is highly apprciated .
Thanks

Hello;
You probably started the recovery ( to apply redo from the Primary )
Cancel this before doing the command you trying :
alter database recover managed standby database cancel;Then issue your command again.
Best Regards
mseberg

Oracle 9i standby database error

Hi all,
I am getting this error on my standby DB while it's archiving a log...and I've even restarted the DB and media recovery.Also, it's not a disk space issue.
Errors in file f:\oracle\admin\xxxprd\bdump\xxxprd_pmon_5224.trc:
ORA-16145: archival for thread# 1 sequence# 19113 in progress
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Any ideas ?
Much appreciated

Hi;
Please see below notes which could be helpful for your issue
https://support.oracle.com/CSP/main/article?cmd=show&type=COMMUNITIES&doctype=COMTHREAD&id=75725
http://download.oracle.com/docs/cd/B19306_01/server.102/b14219/e12700.htm#sthref4916
OERR: ORA-16145 archival for thread# %s sequence# %s in progress [ID 172871.1]
Regard
Helios

Rman standby database error

Hi All,
I am getting the following error when trying to CONFIGURE STANDBY database using rman,db version 10.2.0.2(HP-UX 11.2),library link seems to be fine.
do i have to relink the library to oracle on the stanby db host too? any suggestion please.
connect target / catalog rman@xx auxiliary sys@aux
RMAN> run {
allocate channel c1 device type 'sbt_tape';
ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE 'SBT_TAPE';
duplicate target database for standby dorecover;}2> 3> 4>
allocated channel: c1
channel c1: sid=164 instance=WWPODSP1 devtype=SBT_TAPE
channel c1: Data Protector A.06.00/331
released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of allocate command on aux1 channel at 05/09/2007 16:57:07
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 11
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 45 DAYS;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE 'SBT_TAPE' TO 'control_file_%F';
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'SBT_LIBRARY=/opt/omni/lib/libob2oracle8_64bit.so';
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/u01/app/oracle/product/10.2.0/db_1/dbs/snapcf_WWPODSP1.f'; # default

sorry here is the exact commands.
rman TARGET / AUXILIARY sys/xxx@WWPODSS catalog rman@rman
Recovery Manager: Release 10.2.0.2.0 - Production on Wed May 9 17:29:37 2007
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: WWPODSP (DBID=669261963)
recovery catalog database Password:
connected to recovery catalog database
connected to auxiliary database: WWPODSP (not mounted)
RMAN> run
2> {
3> duplicate target database for standby dorecover;}
Starting Duplicate Db at 09-MAY-07
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 05/09/2007 17:33:35
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 11
RMAN>

AdphistUpdatePatchLevel:Unexpected Database Error while applying 3480000 MP

Hi,
Application Install - Version: 11.5.9
upgrading from 11.5.9 to 11.5.10.2, applying 3480000 MP finally stopped with errors.
Errors:
AutoPatch error:
ORA-01403: no data found
ORA-06512: at "APPS.AD_VERSION_UTIL", line 245
ORA-06512: at "APPS.AD_VERSION_UTIL", line 279
ORA-06512: at "APPS.AD_VERSION_UTIL", line 361
ORA-06512: at line 1
Error in adphistUpdatePatchLevel(IA, A)
Error calling adphistUpdateRlseAndPatchLvl().
Error calling adphistStoreCurPatchHistInDB2
AutoPatch error:
Unable to save Patch History information to Database
Trying to save to APPLTOP instead....
Saving Patch History information to APPL_TOP...
AutoPatch error:
adphistUpdatePatchLevel: Unexpected Database Error
Reply ASAP...

check metalink note
(Error in adphistUpdatePatchLevel(CLN, A) when applying Applications 11.5.9 Maintenance Pack)
Note:264969.1
fadi

Archive apply issue for standby database in Standard Edition.

We have setup standby database in Oracle standard edition. the archive log cannot be send by oracle automatically. So we manually send the archive over. But do not see the database apply the archive log file. What could be wrong and where should we check on it?
We also used following when finishing the standby DB after running "recover standby database;" for a few archive log file:
alter database recover managed standby database disconnect from session;
======================================================================================
This is the status:
SQL> select OPEN_MODE, SWITCHOVER# ,REMOTE_ARCHIVE ,ARCHIVELOG_CHANGE#,SWITCHOVER_STATUS, DATABASE_ROLE from v$database;
OPEN_MODE SWITCHOVER# REMOTE_A ARCHIVELOG_CHANGE# SWITCHOVER_STATUS DATABASE_ROLE
MOUNTED 495550636 ENABLED 1.2201E+13 SESSIONS ACTIVE PHYSICAL STANDBY

The DB version is 10.2.0.5
I can do this to apply at standby DB:
SQL> set autorecovery on
SQL> recover standby database;
Then I tried to run this to leave the session:
alter database recover managed standby database disconnect from session;
Do not seen any apply.
=============================
Here is the last lines of alert log:
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/cntus/redolog/redo01b.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Thu Sep 06 15:08:34 EDT 2012
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/cntus/redolog/redo01b.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Clearing online redo logfile 1 /u02/cntus/redolog/redo01a.log
Clearing online log 1 of thread 1 sequence number 10158
Thu Sep 06 15:08:34 EDT 2012
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/u03/cntus/redolog/redo01b.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
ORA-27037: unable to obtain file status
SVR4 Error: 2: No such file or directory
Additional information: 3
Thu Sep 06 15:08:34 EDT 2012
Errors in file /oracle/admin/cntus/bdump/cntus_mrp0_12389.trc:
ORA-19527: physical standby redo log must be renamed
ORA-00312: online log 1 thread 1: '/u02/cntus/redolog/redo01a.log'
Clearing online redo logfile 1 complete
Media Recovery Waiting for thread 1 sequence 10166
Thu Sep 06 15:08:35 EDT 2012
Completed: alter database recover managed standby database disconnect from session
======
We have the directory /u02/cntus/redolog and /u03/cntus/redolog. But nothing in there. Should we create redo for it? Is this a separate issue?
Thanks!

Error in mounting the standby database

Hi All,
OS:Solaris
DB:10G
I am facing the below mentioned error while i am trying to create a standby database on the same server.
Following are the steps that i have followed for the same.
1.Checked the connectivity.
2.Created the pfile for primary DB as mentioned below:
*.DB_BLOCK_SIZE=8192
*.OPEN_CURSORS=300
*.CURSOR_SHARING=FORCE
*.BACKGROUND_DUMP_DEST='/11g/oradata/admin/ettest/bdump'
*.CORE_DUMP_DEST='/11g/oradata/admin/ettest/cdump'
*.USER_DUMP_DEST='/11g/oradata/admin/ettest/udump'
*.CONTROL_FILES=("/11g/oradata/admin/data/controlfiles/control01.ctl","/11g/oradata/admin/data/controlfiles/control02.ctl")
*.DB_NAME=ettest
*.PROCESSES=150
*.UNDO_MANAGEMENT=AUTO
*.UNDO_TABLESPACE=undotbs
*.compatible='10.2.0.1.0'
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.LOG_ARCHIVE_DEST_1='Location=/11g/oradata/archives/'
*.LOG_ARCHIVE_DEST_STATE_2='ENABLE'
*.DB_FILE_NAME_CONVERT='/11g/oradata/admin/data/datafiles/','/11g/oradata_dr/ettestdr/datafiles/'
*.LOG_FILE_NAME_CONVERT='/11g/oradata/admin/data/logfiles/','/11g/oradata_dr/ettestdr/redologs/'
*.STANDBY_ARCHIVE_DEST='/11g/oradata_dr/ettestdr/dr_archives/ettestdr'
*.LOG_ARCHIVE_DEST_2='SERVICE=ettestdr'
*.FAL_SERVER='ETTESTDR'
*.FAL_CLIENT='ETTEST'
3. Created the pfile for DR:
*.DB_UNIQUE_NAME=ettestdr
*.DB_BLOCK_SIZE=8192
*.OPEN_CURSORS=300
*.CURSOR_SHARING=FORCE
*.BACKGROUND_DUMP_DEST='/11g/oradata_dr/ettestdr/admin/bdump'
*.CORE_DUMP_DEST='/11g/oradata_dr/ettestdr/admin/cdump'
*.USER_DUMP_DEST='/11g/oradata_dr/ettestdr/admin/udump'
*.CONTROL_FILES=("/11g/oradata_dr/ettestdr/controlfiles/standbycontrolfile.ctl")
*.DB_NAME=ettestdr
*.PROCESSES=150
*.UNDO_MANAGEMENT=AUTO
*.UNDO_TABLESPACE=undotbs
*.compatible='10.2.0.1.0'
*.FAL_SERVER='ETTEST'
*.FAL_CLIENT='ETTESTDR'
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.LOG_ARCHIVE_DEST_1='Location=/11g/oradata/archives/'
*.STANDBY_ARCHIVE_DEST='/11g/oradata_dr/ettestdr/dr_archives/ettestdr'
*.LOG_ARCHIVE_DEST_2='SERVICE=ettestdr'
*.LOG_ARCHIVE_DEST_STATE_2='DEFER'
*.DB_FILE_NAME_CONVERT='/11g/oradata_dr/ettestdr/datafiles/','/11g/oradata/admin/data/datafiles/'
*.LOG_FILE_NAME_CONVERT='/11g/oradata_dr/ettestdr/redologs/','/11g/oradata/admin/data/logfiles/'
4.In the mean time i have backed up the database and transferd the same on the DR location and then i ahve created the standbycontrolfiel using the command on priamary server with sys login using the command:
alter databse create standby controlfile as '/path';5.My Primary was up using the said pfile.
6.I was also able to put my DR in nomount stage using the above pfile
7.I transfered the controlfile at the appropriate location of the DR server and when i am trying to mount the DR db using:
alter database mount standby database;I am getting the below mentioned error
SQL> alter database mount standby database;
alter database mount standby database
ERROR at line 1:
ORA-01103: database name 'ETTEST' in control file is not 'ETTESTDR'
Kindly suggest...BR
Sphinx
Edited by: $phinx19 on Dec 12, 2012 5:29 AM

Hi,
You must create pfile for Standby side with parameter DB_UNIQUE_NAME = ettestdr but DB_NAME is same with primary as DB_NAME = ettest.
*.DB_UNIQUE_NAME=ettestdr
*.DB_BLOCK_SIZE=8192
*.OPEN_CURSORS=300
*.CURSOR_SHARING=FORCE
*.BACKGROUND_DUMP_DEST='/11g/oradata_dr/ettestdr/admin/bdump'
*.CORE_DUMP_DEST='/11g/oradata_dr/ettestdr/admin/cdump'
*.USER_DUMP_DEST='/11g/oradata_dr/ettestdr/admin/udump'
*.CONTROL_FILES=("/11g/oradata_dr/ettestdr/controlfiles/standbycontrolfile.ctl")
*.DB_NAME=ettest
*.PROCESSES=150
*.UNDO_MANAGEMENT=AUTO
*.UNDO_TABLESPACE=undotbs
*.compatible='10.2.0.1.0'
*.FAL_SERVER='ETTEST'
*.FAL_CLIENT='ETTESTDR'
*.STANDBY_FILE_MANAGEMENT='AUTO'
*.LOG_ARCHIVE_DEST_1='Location=/11g/oradata/archives/'
*.STANDBY_ARCHIVE_DEST='/11g/oradata_dr/ettestdr/dr_archives/ettestdr'
*.LOG_ARCHIVE_DEST_2='SERVICE=ettest'
*.LOG_ARCHIVE_DEST_STATE_2='DEFER'
*.DB_FILE_NAME_CONVERT='/11g/oradata_dr/ettestdr/datafiles/','/11g/oradata/admin/data/datafiles/'
*.LOG_FILE_NAME_CONVERT='/11g/oradata_dr/ettestdr/redologs/','/11g/oradata/admin/data/logfiles/' And in pfile for standby *.LOG_ARCHIVE_DEST_2='SERVICE=ettest' - after switchover logs transport to primary (ettest)
Regards
Mahir M. Quluzade
www.mahir-quluzade.com
Edited by: Mahir M. Quluzade on Dec 12, 2012 5:44 PM

Standby database Archive log destination confusion

Hi All,
I need your help here..
This is the first time that this situation is arising. We had sync issues in the oracle 10g standby database prior to this archive log destination confusion.So we rebuilt the standby to overcome this sync issue. But ever since then the archive logs in the standby database are moving to two different locations.
The spfile entries are provided below:
*.log_archive_dest_1='LOCATION=/m99/oradata/MARDB/archive/'
*.standby_archive_dest='/m99/oradata/MARDB/standby'
Prior to rebuilding the standby databases the archive logs were moving to /m99/oradata/MARDB/archive/ location which is the correct location. But now the archive logs are moving to both /m99/oradata/MARDB/archive/ and /m99/oradata/MARDB/standby location, with the majority of them moving to /m99/oradata/MARDB/standby location. This is pretty unusual.
The archives in the production are moving to /m99/oradata/MARDB/archive/ location itself.
Could you kindly help me overcome this issue.
Regards,
Dan

Hi Anurag,
Thank you for update.
Prior to rebuilding the standby database the standby_archive_dest was set as it is. No modifications were made to the archive destination locations.
The primary and standby databases are on different servers and dataguard is used to transfer the files.
I wanted to highlight one more point here, The archive locations are similar to the ones i mentioned for the other stndby databases. But the archive logs are moving only to /archive location and not to the /standby location.

Add Datafile in Logical Standby Database

Hi,
I have add one datafile in our primary RAC DB. We had logical standby database with file management is equal to manual. Both the primary RAC and logical standby db have the different storage structure. When the archive applied on the logical standby database its throws the error " error in creating datafile 'path'";
Would appreciate if come to know the steps to add the datafile in this kind of environment. and how can i overcome from this problem now except skip transaction for that ddl.
Thanks in advance.
Dewan

When the archive applied on the logical standby database its throws the error " error in creating datafile 'path'";Can you post the error message with the number.
From Manual..
8.3.1.2 Adding a Tablespace and a Datafile When STANDBY_FILE_MANAGEMENT Is Set to MANUAL
The following example shows the steps required to add a new datafile to the primary and standby database when the STANDBY_FILE_MANAGEMENT initialization parameter is set to MANUAL. You must set the STANDBY_FILE_MANAGEMENT initialization parameter to MANUAL when the standby datafiles reside on raw devices.
Add a new tablespace to the primary database:
SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf'
2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;
Verify the new datafile was added to the primary database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/oradata/payroll/t_db1.dbf
/disk1/oracle/oradata/payroll/t_db2.dbf
Perform the following steps to copy the tablespace to a remote standby location:
Place the new tablespace offline:
SQL> ALTER TABLESPACE new_ts OFFLINE;
Copy the new tablespace to a local temporary location using an operating system utility copy command. Copying the files to a temporary location will reduce the amount of time the tablespace must remain offline. The following example copies the tablespace using the UNIX cp command:
% cp /disk1/oracle/oradata/payroll/t_db2.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf
Place the new tablespace back online:
SQL> ALTER TABLESPACE new_ts ONLINE;
Copy the local copy of the tablespace to a remote standby location using an operating system utility command. The following example uses the UNIX rcp command:
%rcp /disk1/oracle/oradata/payroll/s2t_db2.dbf standby_location
Archive the current online redo log file on the primary database so it will get transmitted to the standby database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
Use the following query to make sure that Redo Apply is running. If the MRP or MRP0 process is returned, Redo Apply is being performed.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
Verify the datafile was added to the standby database after the archived redo log file was applied to the standby database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
/disk1/oracle/oradata/payroll/s2t_db1.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf

Recover Standby Database suggests wrong filename

Hi,
I am running Oracle Database 10g Release 10.2.0.3.0 - 64bit Production Standard Edition on Linux version 2.6.9-42.0.8.ELsmp ([email protected]) (gcc version 3.4.6 20060404 (Red Hat 3.4.6-3))
I've created a physical standby database, but since I am running Standard Edition, I am not using the DataGuard features. I use the rsync utility to copy over the archivelogs to the standby database, and I apply them periodically to the standby database.
The standby database is started this way :
startup nomount pfile='/u01/oradata/orcl/initorcl.stdby';
alter database mount standby database;
And the archives are applied this way :
recover standby database;
AUTO
(AUTO for the command to apply all available archive logs automatically, using the suggested paths and filenames)
My problem is that once in a while (maybe once every 2-3 weeks), the suggested filename does not have the same format as the rest of the time. I then have to manually specify the correct filename and it goes fine after that.
Example :
In this example, you will see that it is first looking for sequence 22907 (o1_mf_1_22907_5n3m1xrf_.arc), then 22908 (o1_mf_1_22908_5n3m4kf0_.arc) [Notice the format of the file name] and then tries to look for sequence 22909, but looks for filename ".o1_mf_1_22909_5n3md1h5_.arc.qXMz5s"
Mon Jan 4 06:22:01 2010
ALTER DATABASE RECOVER standby database
Media Recovery Start
Managed Standby Recovery not using Real Time Apply
ORA-279 signalled during: ALTER DATABASE RECOVER standby database ...
Mon Jan 4 06:22:02 2010
ALTER DATABASE RECOVER CONTINUE DEFAULT
Mon Jan 4 06:22:02 2010
Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/o1_mf_1_22907_5n3m1xrf_.arc
Mon Jan 4 06:24:20 2010
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Mon Jan 4 06:24:20 2010
ALTER DATABASE RECOVER CONTINUE DEFAULT
Mon Jan 4 06:24:20 2010
Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/o1_mf_1_22908_5n3m4kf0_.arc
Mon Jan 4 06:24:46 2010
ORA-279 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Mon Jan 4 06:24:46 2010
ALTER DATABASE RECOVER CONTINUE DEFAULT
Mon Jan 4 06:24:46 2010
Media Recovery Log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/.o1_mf_1_22909_5n3md1h5_.arc.qXMz5s
Errors with log /oraarch/oracle/flash_recovery_area/GIGA10G/archivelog/2010_01_04/.o1_mf_1_22909_5n3md1h5_.arc.qXMz5s
ORA-308 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
Mon Jan 4 06:24:46 2010
ALTER DATABASE RECOVER CANCEL
Mon Jan 4 06:24:46 2010
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER CANCEL
Can someone explain to me why is this happening please ?
Thanks a lot,
Mat

@fjfranken
Yes. If I manually enter the name of the file for the sequence requested instead of passing the suggested fielname, it works fine.
And the log_archive_format is not defined, I am using the flash_recovery_area and let Oracle manage this automatically.
@Hemant K Chitale
Unfortunately, those sequences are not listed anymore in the V$ARCHIVED_LOG view.
Well, I think the the problem might be related to files that are being written to at some time...
Thanks,
Mat

Standby database recovery problems....

HP-UX 11.23
oracle 10.2.0.2
I know that this has been discussed quite a bit. I've spent a number of hours on this forum alone today just reading through the search hits. I've tried some of the 'tricks' that have been described in the threads. But I'm still getting the same error....
My standby database lost connectivity with my primary, and stopped receiving logs. I got no notification, because my scripts were not set up to catch this event...
The retention policy on my primary is 30 days of archive logs. After that, they are deleted. (I don't agree with it, but not my call)
The standby got more than 30 days out of sync, so I decided to just refresh the whole standby.
Since cold backups are not an option, I did an alter system checkpoint to flush all archive logs. Then I issued a complete hot backup.
Once completed, I went ahead and created a fresh standby control file, as well as a fresh backup control file. In that exact order.
I transferred all db files, archive logs, and control files over to the standby.
I ran the commands:
startup nomount;
(SUCCESSFUL)
alter database mount standby database;
(SUCCESSFUL)
recover standby database;
I let it run through all the archive log files until it errored saying it couldn't find "X" file being the next sequence that wasn't in the directory. Which to my understanding, is normal...time to quit recovery.
When I entered cancel, I get the following error.
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 7313561157126 generated at 12/17/2008 19:01:02 needed for
thread 1
ORA-00289: suggestion : /oraarch/swesc/1_13729_640853326.arc
ORA-00280: change 7313561157126 for thread 1 is in sequence #13729
ORA-00278: log file '/oraarch/swesc/1_13728_640853326.arc' no longer needed for
this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
CANCEL
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/ora1/oradata/peregrine/system01.dbf'
So my understanding of this is that it means that you still need to apply logs.
So I grabbed the logs that had been auto created during the time that I was rebuilding everything and applied them.
Same errors.
I'm at a loss here. How can it still be out of sync? Is there a way to force it to a specific sequence so that I can successfully open it and then shut it down to complete the sequence?
Thanks.

Thanks OrionNet. Great info!!
Here is the response.
OrionNet wrote:
select * from v$archive_gap
NO ROWS SELECTED.
and all the logs got applied
select applied , count(*) from v$archived_log;
-- This should return 1 rows with "YES", number of logs applied.
I had to change change this as it complained about "not a single-group group function
I changed it by adding group by applied to the end...
NO ROWS SELECTED
Then you should try activating standby database
SQL> alter database force nomount pfile='....'; -- or without the pfile
SQL> alter database mount standby database;
-- If all the archived logs have been applied to your standby then stop recovery
SQL> alter database recover manated standby cancel;
-- Note if it fails on activating the database ;shutdown and mount it again and activate (skip stopping recovery step).
SQL> alter database activate standby database;
IF successfull, then perform followin
SQL> alter database open;Regards
OrionNet;
I thought that in a primary/standby scenario, thiat this action would automatically shut down the primary. I can't have that.
HOLDING OFF ON REST FOR RESPONSE...
Edited by: WillyB on Dec 17, 2008 9:40 PM

Standby database Error in applying archives

Similar Messages

Maybe you are looking for