Home » Server Options » Data Guard » why did the current configuration produces a temporary 10M archive log (rdbms 10.2.0.4, os windows 32 bit)
why did the current configuration produces a temporary 10M archive log [message #522941] Wed, 14 September 2011 11:24 Go to next message
kytemanaic
Messages: 55
Registered: February 2009
Member
Hi

my primary db_unique_name ctastd
my physical standby db_unique_name ctastd

here's my configuration for the standby


cta.__db_cache_size=67108864
cta.__java_pool_size=4194304
cta.__large_pool_size=4194304
cta.__shared_pool_size=83886080
cta.__streams_pool_size=4194304
*.archive_lag_target=0
#*.audit_file_dest='D:\ora102\CTA\adump'
*.audit_sys_operations=TRUE
*.audit_trail='TRUE'
*.background_dump_dest='D:\ora102\CTA\bdump'
*.compatible='10.2.0.3.0'
cta.control_files='D:\ORA102\CTA\CONTROL01.CTL'#Restore Controlfile
*.core_dump_dest='D:\ora102\CTA\cdump'
*.db_block_size=4096
*.db_name='CTA'
cta.db_recovery_file_dest=''
*.db_recovery_file_dest_size=9G
cta.db_unique_name='CTA'
*.dg_broker_start=TRUE
*.dispatchers=''
cta.fal_client='cta_primary'
cta.fal_server='cta_standby'
*.log_archive_config='DG_CONFIG=(CTA,CTASTD)'
cta.log_archive_dest_1='location="D:\Ora102\cta\cta_arc"','valid_for=(ONLINE_LOGFILE,ALL_ROLES)'
cta.log_archive_dest_2='SERVICE=cta_standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ctastd'
cta.log_archive_dest_state_1='ENABLE'
cta.log_archive_dest_state_2='ENABLE'

cta.log_archive_format='%s_%t_%r.arc'
cta.log_archive_trace=0
*.remote_login_passwordfile='EXCLUSIVE'
*.standby_file_management='auto'
*.undo_management='AUTO'
*.undo_tablespace='UNDOTBS1'
*.user_dump_dest='D:\ora102\CTA\udump'
*.utl_file_dir='c:\temp'
log_file_name_convert='junk','junk'
standby_archive_dest='D:\Ora102\cta\cta_arc'
*.sga_target=167772160
standby_file_management=auto
compatible=10.2.0.4


here's my error code

ORA-16014: log 6 sequence# 204 not archived, no available destinations
ORA-00312: online log 6 thread 1: 'D:\ORA102\CTA\REDO06.LOG'

Thu Sep 15 00:12:29 2011
Primary database is in MAXIMUM PERFORMANCE mode
RFS[5]: Successfully opened standby log 4: 'D:\ORA102\CTA\REDO04.LOG'



before clearing the unarchive logs

here's the query I found out about the status of both online and standby redo logs on the standby, cta

SYS@CTA>select loggroup.GROUP#, loggroup.SEQUENCE#, loggroup.archived, loggroup.status, logdetail.type
  2  from v$log loggroup
  3  join v$logfile logdetail on
  4  loggroup.GROUP# = logdetail.GROUP#;

    GROUP#  SEQUENCE# ARC STATUS           TYPE                                 
---------- ---------- --- ---------------- -------                              
         1        205 YES CLEARING_CURRENT ONLINE                               
         3        204 YES CLEARING         ONLINE                               
         2        203 YES CLEARING         ONLINE                               

SYS@CTA>
SYS@CTA>
SYS@CTA>select loggroup.GROUP#, loggroup.SEQUENCE#, loggroup.archived, loggroup.status, logdetail.type
  2  from v$standby_log loggroup
  3  join v$logfile logdetail on
  4  loggroup.GROUP# = logdetail.GROUP#;

    GROUP#  SEQUENCE# ARC STATUS     TYPE                                       
---------- ---------- --- ---------- -------                                    
         4        205 YES ACTIVE     STANDBY                                    
         5          0 NO  UNASSIGNED STANDBY                                    
         6        204 NO  ACTIVE     STANDBY                                    
         7          0 YES UNASSIGNED STANDBY       



if u look at the standby log option, it is quite obvious it is wrong as sequence 205 is not even archived, so alert log

so here's I temporary resolve the issue


alter database recover managed standby database cancel;

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=manual;

alter database clear unarchived logfile group 4;

alter database clear unarchived logfile group 6;

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

alter database recover managed standby database disconnect from session;




here's the outcome


SYS@CTA>SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, applied FROM V$ARCHIVED_LOG whe
re resetlogs_change#= 508247427 ORDER BY SEQUENCE#;


       200 14-SEP-11 14-SEP-11 YES
       201 14-SEP-11 14-SEP-11 YES
       202 14-SEP-11 15-SEP-11 YES
       203 15-SEP-11 15-SEP-11 YES
       204 15-SEP-11 15-SEP-11 YES




here's the log

Media Recovery Waiting for thread 1 sequence 204
Thu Sep 15 00:16:17 2011
RFS[6]: Archived Log: 'D:\ORA102\CTA\CTA_ARC\204_1_759234670.ARC'
Thu Sep 15 00:16:17 2011
Completed: alter database recover managed standby database disconnect from session
Thu Sep 15 00:16:47 2011
Media Recovery Log D:\ORA102\CTA\CTA_ARC\204_1_759234670.ARC
Media Recovery Waiting for thread 1 sequence 205 (in transit)



notice that server is waiting for sequence 5

I've configured other data guard configuration, if I did remember wrongly, if the current sequence is said 205,

there should by right have a temporary archive log 205 at the local archiving destination, log_archive_dest_1

i.e.
not correct one

9/14/2011  11:02 PM           605,184 197_1_759234670.AR
9/14/2011  11:03 PM             2,048 198_1_759234670.AR
9/14/2011  11:35 PM           173,568 199_1_759234670.AR
9/14/2011  11:42 PM           137,728 200_1_759234670.AR
9/14/2011  11:43 PM             1,024 201_1_759234670.AR
9/15/2011  12:03 AM           651,264 202_1_759234670.AR
9/15/2011  12:10 AM            24,064 203_1_759234670.AR
9/15/2011  12:16 AM           128,512 204_1_759234670.AR


correct one

9/14/2011  11:02 PM           605,184 197_1_759234670.AR
9/14/2011  11:03 PM             2,048 198_1_759234670.AR
9/14/2011  11:35 PM           173,568 199_1_759234670.AR
9/14/2011  11:42 PM           137,728 200_1_759234670.AR
9/14/2011  11:43 PM             1,024 201_1_759234670.AR
9/15/2011  12:03 AM           651,264 202_1_759234670.AR
9/15/2011  12:10 AM            24,064 203_1_759234670.AR
9/15/2011  12:16 AM           128,512 204_1_759234670.AR
9/15/2011  12:16 AM           1048576 205_1_759234670.AR




the size of the temporary archive log should be equivalent to the size of the current log group

anyone know how to resolve the issue of always having

ORA-16014: log 6 sequence# 204 not archived, no available destinations

thanks a lot!
Re: why did the current configuration produces a temporary 10M archive log [message #522952 is a reply to message #522941] Wed, 14 September 2011 15:02 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
I think you have some misunderstanding of how Data Guard works. Here are some examples:


Quote:
the size of the temporary archive log should be equivalent to the size of the current log group
What does this mean? What is a "temporary archice log"? There is no reason why an archive log should be the same size as an online log: it will be the size of however much redo was in the online log at the time of the log switch, which could be a lot less.



Quote:
if u look at the standby log option, it is quite obvious it is wrong as sequence 205 is not even archived,
Redo is written to your standby logs as it is generated, this has nothing to do with whether the online log has been archived.


Quote:
alter database clear unarchived logfile group 4; alter database clear unarchived logfile group 6;
This was possibly disastrous. It looks as though you cleared your standby logs before they had been applied. This why you are now getting the ora-16014.

If you cannot find a copy of those missing logs on your primary, then your standby is irreversibly broken, and you will have to re-create it.
Re: why did the current configuration produces a temporary 10M archive log [message #522971 is a reply to message #522952] Wed, 14 September 2011 22:41 Go to previous messageGo to next message
kytemanaic
Messages: 55
Registered: February 2009
Member
I believe I do have some misunderstanding of how Data Guard works.

primary cta
physical standby ctastd

I have the following configurations at standby site


cta.log_archive_dest_1='location="D:\Ora102\cta\cta_arc"','valid_for=(ONLINE_LOGFILE,ALL_ROLES)'

cta.log_archive_dest_2='SERVICE=cta_standby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ctastd'

standby_archive_dest='D:\Ora102\cta\cta_arc'


I have 4 standby redo logs


from http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#i1265762

Quote:


Example 5-6 Initialization Parameters for LGWR Asynchronous Archiving

LOG_ARCHIVE_DEST_1='LOCATION=/arch1/chicago'
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE

Figure 5-5 shows the LNSn process collecting redo data from the online redo log files and transmitting it over Oracle Net to the RFS process on the standby database.


it does tell us what happen to the primary site, but I have to second guess what happen at the standby only from the diagram itself.

in the ideal condition, if there's a log switch in logfile group 1, first redo will be transmitted and written to the standby redo log right? this one agreed and observed.

next the archiver process at the standby site is supposed to archived to the standby_archive_dest, in this case log_archive_dest_1, right?

does the archive process need to wait for all for standby redo logs to be written before it can archived to the standby archive destination?

thanks!
Re: why did the current configuration produces a temporary 10M archive log [message #523013 is a reply to message #522971] Thu, 15 September 2011 03:05 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
Quote:
if there's a log switch in logfile group 1, first redo will be transmitted and written to the standby redo log right?
I've already told you that this is wrong. You need to read your manual again: section 5.3.2.
Re: why did the current configuration produces a temporary 10M archive log [message #523024 is a reply to message #523013] Thu, 15 September 2011 03:48 Go to previous messageGo to next message
kytemanaic
Messages: 55
Registered: February 2009
Member
pse correct me if I'm wrong again,

with reference to http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/log_transport.htm#i1265666

Quote:


Using the LGWR process differs from ARCn processing (described in Section 5.3.1), because instead of waiting for the online redo log to switch at the primary database and then writing the entire archived redo log at the remote destination all at once, the LGWR process selects a standby redo log file at the standby site that reflects the log sequence number (and size) of the current online redo log file of the primary database. Then, as redo is generated at the primary database, it is also transmitted to the remote destination


even before there's a log switch of say logfile group 1 said sequence 213,

the redo data is already transmitted and written to the standby redo log 4 right?

when a log switch happens at the primary at logfile group 1, log switch also happens at standby redo logfile 4, redo data is being archived from standby logfile group 4 (this being done by standby arc process) and applied to data files by MRP processs.

If my assumption is correct then there must be something wrong with the archival process at the standby db, because it always keep complaining about

ORA-16014: log 6 sequence# 204 not archived, no available destinations

when in actual fact is not being archived.


SYS@CTA>select loggroup.GROUP#, loggroup.SEQUENCE#, loggroup.archived, loggroup.status, logdetail.type
  2  from v$log loggroup
  3  join v$logfile logdetail on
  4  loggroup.GROUP# = logdetail.GROUP#;

    GROUP#  SEQUENCE# ARC STATUS           TYPE                                 
---------- ---------- --- ---------------- -------                              
         1        205 YES CLEARING_CURRENT ONLINE                               
         3        204 YES CLEARING         ONLINE                               
         2        203 YES CLEARING         ONLINE                               

SYS@CTA>
SYS@CTA>
SYS@CTA>select loggroup.GROUP#, loggroup.SEQUENCE#, loggroup.archived, loggroup.status, logdetail.type
  2  from v$standby_log loggroup
  3  join v$logfile logdetail on
  4  loggroup.GROUP# = logdetail.GROUP#;

    GROUP#  SEQUENCE# ARC STATUS     TYPE                                       
---------- ---------- --- ---------- -------                                    
         4        205 YES ACTIVE     STANDBY 


how is it possible that standby log file group 4 is indicated as archived when it is not?
Re: why did the current configuration produces a temporary 10M archive log [message #523031 is a reply to message #523024] Thu, 15 September 2011 04:35 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
Quote:
If my assumption is correct then there must be something wrong with the archival process at the standby db, because it always keep complaining about

ORA-16014: log 6 sequence# 204 not archived, no available destinations
I've already told you that this is because YOU broke it with your CLEAR command.
I'm sorry to have to say this, but if you don't bother to read what I say, I'm going to give up. Perhaps someone else can help.
ARC1: Archiving not possible: No primary destinations [message #523317 is a reply to message #523031] Fri, 16 September 2011 12:55 Go to previous message
kytemanaic
Messages: 55
Registered: February 2009
Member

ARC1: Evaluating archive   log 5 thread 1 sequence 246
ARC1: Archiving not possible: No primary destinations
Fri Sep 16 16:14:02 2011
ARC0: Evaluating archive   log 5 thread 1 sequence 246
ARC0: Unable to archive thread 1 sequence 246
      Log actively being archived by another process
Fri Sep 16 16:14:02 2011
ARC1: Failed to archive thread 1 sequence 246 (4)
Fri Sep 16 16:14:02 2011
ARCH: Archival stopped, error occurred. Will continue retrying
Fri Sep 16 16:14:02 2011
Errors in file d:\ora102\cta\bdump\cta_arc0_3000.trc:
ORA-16038: log 5 sequence# 246 cannot be archived
ORA-00001: unique constraint (.) violated

Fri Sep 16 16:14:37 2011
Errors in file d:\ora102\cta\udump\cta_rfs_3732.trc:
ORA-16401: archivelog rejected by RFS

Fri Sep 16 16:15:37 2011
Errors in file d:\ora102\cta\udump\cta_rfs_972.trc:
ORA-16401: archivelog rejected by RFS



I have finally able to capture the most important part of the alert log ,i.e.
ARC1: Archiving not possible: No primary destinations

I recreated the physical standby database,

I encountered the above error, upon googling, I found this post

http://arjudba.blogspot.com/2008/07/archiving-not-possible-no-primary.html

change my archival destination in the physical standby to

alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST';

what puzzled me right now is why the physical standby refused to archived to D:\ORA102\CTA\CTA_ARC\

because from http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmconfg.htm#sthref361

Quote:

If you set any local destinations for LOG_ARCHIVE_DEST_n, then archived redo logs are stored only in the destinations you specify using those parameters.


also I still believe there's something wrong somewhere


SYS@CTA>select loggroup.GROUP#, loggroup.SEQUENCE#, loggroup.archived, loggroup.
status, logdetail.type
  2  from v$log loggroup
  3  join v$logfile logdetail on
  4  loggroup.GROUP# = logdetail.GROUP#;

    GROUP#  SEQUENCE# ARC STATUS           TYPE
---------- ---------- --- ---------------- -------
         1        268 YES CLEARING_CURRENT ONLINE
         3        267 YES CLEARING         ONLINE
         2        266 YES CLEARING         ONLINE

3 rows selected.

SYS@CTA>
SYS@CTA>
SYS@CTA>select loggroup.GROUP#, loggroup.SEQUENCE#, loggroup.archived, loggroup.
status, logdetail.type
  2  from v$standby_log loggroup
  3  join v$logfile logdetail on
  4  loggroup.GROUP# = logdetail.GROUP#;

    GROUP#  SEQUENCE# ARC STATUS     TYPE
---------- ---------- --- ---------- -------
         4        268 YES ACTIVE     STANDBY
         5          0 NO  UNASSIGNED STANDBY
         6          0 NO  UNASSIGNED STANDBY
         7          0 NO  UNASSIGNED STANDBY
4 rows selected.


why I believe there's something wrong is becoz sequence 268 is the current sequence yet it indicated as being "archived" which is not right.

[Updated on: Fri, 16 September 2011 13:13]

Report message to a moderator

Previous Topic: How to resolve ORA-16401: archivelog rejected by RFS
Next Topic: Data Guard Configuration for new server
Goto Forum:
  


Current Time: Thu Mar 28 08:49:28 CDT 2024