(Warn) Failed To Find Arch For Message (Message:0×1)

2009.11.01 10:51 上午 »Author: bosonmaster »
产生该问题的原因就是log_archive_max_processes 参数设置太小引起的，默认的是2，在10GR最大可以增加到30，我修改为10，问题就解决了，在METALINK：375229.1，文档描述如下
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.6
This problem can occur on any platform.
"Checked for relevance on 27-Jan-2009"
Symptoms
- After starting the database receive the following errors in trace file:>
tkcrrsarc: (WARN) Failed to find ARCH for message (message:0x1)
tkcrrpa: (WARN) Failed initial attempt to send ARCH message (message:0x1)
<<
- After manual performing log switches the following messages occur in the alert.log:>
Shutting down archive processes
Wed Oct 19 14:13:22 2005
ARCH shutting down
ARC2: Archival stopped
<<
Cause
Bug 4704334 - ''TKCRRSARC: (WARN) FAILED TO FIND ARCH FOR MESSAGE (MESSAGE:0X1)''
 
These messages are warning messages and are a consequence of the internal archive process spawning and releasing.
 
 
There can be different reasons for this message to appear, but it is in fact related to internal work.
 
 
 
Solution
These are only diagnostic messages and can be safely ignored. 
However, there are two options:
 
Option 1
 
Ignore the messages.
 
Option 2
 
Increase the log_archive_max_processes equal to/or greater than 10
 
*Testing information about Option 2
 
log_archive_max_processes=2 may still cause messages, and 4 may cause less.
Recommended setting is 10 or higher as testing has verified that messages disappeared completely at this setting.

oracle No Comments

FAL ARCHIVE FAILED

2009.11.01 10:39 上午 »Author: bosonmaster »
在主库有如下报错
ARCH: FAL archive failed. Archiver continuing
Sat Oct 31 16:28:37 2009
ORACLE Instance pdczh1 - Archival Error. Archiver continuing.
备库有下报错
Errors in file /u01/app/oracle/admin/dczh/udump/dczh1_rfs_15998.trc:
ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []
Sat Oct 31 16:31:52 2009
Errors in file /u01/app/oracle/admin/dczh/udump/dczh1_rfs_15880.trc:
ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []
 
在METALINK 386417.1
A firewall has been added to the network between the primary and standby sites or already exists.  The firewall may be Cisco-based and have a feature called 'fixup' enabled which may or may not be configured fully.
 
Database auditing may have also been enabled or is currently in use per the initialization parameter AUDIT_TRAIL.
 
CauseWhen auditing is enabled, queries or DML to the SYS.AUD$ table may trigger larger then normal TCP packets.  When these packets go through the firewall, the 'fixup' can possibly modify the packet incorrectly and cause it to be corrupted which then breaks Oracle Net.
 
SolutionSeveral workarounds are available which must be evaluated and tested individually based on the requirements of each environment.
 
Listed with the most commonly used at the top:
 
Turn off database auditing.
 
 
If auditing must be maintained and the 'fixup' feature cannot be disabled, work with the network administrators to evaluate the MTU for the firewall and size the Oracle TCP packets to be below the current setting. The SDU/TDU settings are configured via the Oracle Net files on both primary and standby.  See the References section below for related content.
 
 
Disable the 'fixup' feature and/or consult with the firewall vendor regarding patches/fixes to the feature.
 
 
Disable the firewall.

oracle No Comments

ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368]

2009.11.01 10:33 上午 »Author: bosonmaster »
在操作过程中，有如下报错
Errors in file /u01/app/oracle/admin/dczh/udump/dczh1_rfs_15830.trc:
ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []
Sat Oct 31 16:26:00 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[4]: Assigned to RFS process 15880
RFS[4]: Identified database type as 'physical standby'
RFS[4]: Archived Log: '/arc1/2_192_691352710.dbf'
RFS[4]: Archived Log: '/arc1/2_193_691352710.dbf'
RFS[4]: Archived Log: '/arc1/2_194_691352710.dbf'
这个问题出现备库就夯筑了，在METALINK也有下文字描述，最后只能SHUTDOWN AOBRT，产生的原因应该和12545错误有关，后来解决了12545问题，这个报错就没有出现过
The RSF process on a managed standby may raise an ORA-600 [KCRRRFSWDA.1]
or may hold onto global enqueues permanently preventing re-copying of
a log from the primary. This can happen if a problem occurs on the NET
connection between the primary and standby

oracle No Comments

Error 12545 connecting to pdczh for fetching gap sequence

2009.11.01 10:22 上午 »Author: bosonmaster »
在其恢复过程中，有如下错误，在主备设置好LOCAL_LISTENER解决，详细的看之前的文章
alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=10.18.6.184)(PORT=1521))'sid='czh1';
alter system set local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=10.18.6.185)(PORT=1521))'sid='czh2';
 
Error 12545 received logging on to the standby
FAL[client, MRP0]: Error 12545 connecting to pdczh for fetching gap sequence
Sat Oct 31 00:21:25 2009
Errors in file /u01/app/oracle/admin/dczh/bdump/dczh1_mrp0_1092.trc:
ORA-12545: Connect failed because target host or object does not exist
Sat Oct 31 00:22:05 2009
FAL[client]: Failed to request gap sequence
 GAP - thread 2 sequence 172-172
 DBID 742969478 branch 691352710
FAL[client]: All defined FAL servers have been attempted.

oracle No Comments

Warning: OS async I/O limit 128 is lower than recovery batch 1024

2009.11.01 10:18 上午 »Author: bosonmaster »
在启动恢复的时候，alert.log如下报错，看错误是和异步IO，有关了，检查了相关参数，发现有人忘了设置privgroup
创建 /etc/privgroup 添加如下内容
dba MLOCK RTSCHED RTPRIO
执行如下语句使其生效
 setprivgrp -f /etc/privgroup
设置完后，问题解决。
Warning: OS async I/O limit 128 is lower than recovery batch 1024
Sat Oct 31 00:16:25 2009
Errors in file /u01/app/oracle/admin/dczh/bdump/dczh1_ora_1134.trc:
Sat Oct 31 00:16:25 2009
Warning: OS async I/O limit 128 is lower than recovery batch 1024
Sat Oct 31 00:16:25 2009
Warning: OS async I/O limit 128 is lower than recovery batch 1024
Sat Oct 31 00:16:25 2009
Errors in file /u01/app/oracle/admin/dczh/bdump/dczh1_ora_1136.trc:
Sat Oct 31 00:16:25 2009
Warning: OS async I/O limit 128 is lower than recovery batch 1024
Sat Oct 31 00:16:25 2009
Waiting for all non-current ORLs to be archived...

oracle No Comments

Pages (64): « 1 2 3 4 5 6 » ... Last »

CopyRight ©2007 oralife.cn, All rights reserved.
联系站长bosonmaster(at)gmail.com|QQ联系:859358
Powered by WordPress
京ICP备07026883号