Archive for 十一月 1st, 2009

rac datagurad相关的几篇不错文档

星期日, 十一月 1st, 2009

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_DataGuardNetworkBestPractices.pdf

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10g_RACPrimarySingleInstancePhysicalStandby.pdf

http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gR2_RACPrimaryRACLogicalStandby.pdf

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

星期日, 十一月 1st, 2009
产生该问题的原因就是log_archive_max_processes 参数设置太小引起的,默认的是2,在10GR最大可以增加到30,我修改为10,问题就解决了,在METALINK375229.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.

FAL ARCHIVE FAILED

星期日, 十一月 1st, 2009
在主库有如下报错
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 existsThe 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 packetsWhen 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 standbySee 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.

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

星期日, 十一月 1st, 2009
在操作过程中,有如下报错
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

Error 12545 connecting to pdczh for fetching gap sequence

星期日, 十一月 1st, 2009
在其恢复过程中,有如下错误,在主备设置好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.