Archive for ‘数据库’ Category
一客户RAC两节点报如下错误：
ORA-00600: 内部错误代码, 参数: [17285], [0x2A97446380], [4294967295], [0x1DD7B1238], [], [], [], []
ORA-02055: 分布式更新作业失败; 必须执行回退作业
ORA-02055: 分布式更新作业失败; 必须执行回退作业
ORA-00604: 递归 SQL 层次 1 发生错误
ORA-03113: 通讯信道上出现 EOF
oracle RAC出问题时我们往往需要查看其log和trace文件，那么这些log及trace存在哪里呢？下图就是一个log目录结构示意图，较直观的显示了log存放的地方：
客户环境：Linux+ oracle 10.2.0.2+RAC
现象：客户端用sqlplus连接统一服务名时报ORA-12545错误。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
我们先看ORA-12545错误是什么：
[ oracle @orac1 udump]$ oerr ora 12545
12545, 00000, “Connect failed because target host or object does not exist”
// *Cause: The address specified is not valid, or the program being
// connected to does not exist.
// *Action: Ensure the ADDRESS parameters have been entered correctly; the
// most likely incorrect parameter is the node name. [...]
今年6月Gartner公司发布了2007年主流数据库市场分析报告，根据该报告(见下图)，我们可以看到 oracle 继续以48.6%的份额遥遥领先。
Note: Others include InterSystems (0.82%), Hitachi (0.81%), Fujitsu (0.68%), MySQL (0.33%), Ingres (0.23%), Pervasive Software (0.15%) and EnterpriseDB (0.05%).
像之前遇到的分布式事务报错的问题，我们可能很想知道这个transaction对应的sql及user是什么，那怎么办呢？
我们先看看transaction id的组成：
4.10.878948
其中：4 = rbs#(回滚段编号) ,10 = slot#(事务槽编号), 878948 = wrap#(序号)
原文：http://www.oracleblog.cn/working-case/how-to-deal-with-distributed-transaction/
作者：小荷
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
分布式事务，简单来说，是指一个事务在本地和远程执行，本地需要等待确认远程的事务结束后，进行下一步本地的操作。如通过dblink update远程数据库的一行记录，如果在执行过程中网络异常，或者其他事件导致本地数据库无法得知远程数据库的执行情况，此时就会发生in doublt的报错。此时需要dba介入，且需要分多种情况进行处理。
分布式事务在commit提交时候，会经历3个阶段：
1.PREPARE PHASE：
1.1 决定哪个数据库为commit point site。（注，参数文件中commit_point_strength值高的那个数据库为commit point site）
1.2 全局协调者（Global Coordinator）要求所有的点（除commit point site外）做好commit或者rollback的准备。此时，对分布式事务的表加锁。
1.3 所有分布式事务的节点将它的scn告知全局协调者。
1.4 全局协调者取各个点的最大的scn作为分布式事务的scn。（eygle在这篇文章中也测试过）
一客户数据库alert log经常报如下错误：
Wed Dec 17 14:31:16 2008
Errors in file / oracle /admin/pnbrw/bdump/pnbrw1_reco_16950.trc:
ORA-03113: end-of-file on communication channel
Wed Dec 17 14:31:16 2008
Errors in file / oracle /admin/pnbrw/bdump/pnbrw1_reco_16950.trc:
ORA-02019: connection description for remote database not found
Wed Dec 17 14:36:06 2008
Thread 1 advanced to log sequence 236582
Current log# 2 seq# 236582 mem# 0: /PNBRW_D00/system/redo02.log
Wed Dec 17 14:38:46 2008
Errors in file [...]
前几天在solaris中安装 oracle 10g时出现如下错误：
Checking monitor:must be configured to display at least 256 colors
Failed <<<< >>>Could not execute auto check for display colors using command
/usr/openwin/bin/xdpyinfo. Checks if the DISPLAY variable is set.
这其实是一个很简单的问题，但当初不知道怎么回事，居然被它折腾了半天，看来岁月不饶人呀:)
在将 oracle RAC从10.2.0.1升级到10.2.0.2时遇到两个问题：
1.在apply到remote node做relink时出现warning信息：
In function `lcdprm’:: warning: the `gets’ function is dangerous and should not be used.
经查，该warning信息是 oracle 的一个bug：4762656，可忽略，在11g中修复。
可查看Metalink Note: 356363.1 获得更详细信息。
2.起第二节点时，ASM启动正常，但instance报如下错误：
SQL> startup
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file ‘+RAC_DISK/RACDB/spfileRACDB.ora’
ORA-17503: ksfdopn:2 Failed to open file +RAC_DISK/RACDB/spfileRACDB.ora
ORA-03113: end-of-file on communication channel
这个错误的原因是 oracle 在打第二节点时没有正确更新libknlopt.a。
最近客户数据库的alert.log中经常出现该错误，原因和解决方法如下（摘自Ningoo）：
这个错误跟 oracle 监听的一个参数有关：SQLNET.INBOUND_CONNECT_TIMEOUT
这个参数从9i开始引入，指定了客户端连接服务器并且提供认证信息的超时时间，如果超过这个时间客户端没有提供正确的认证信息，服务器会自动中止该连接请求，同时会记录试图连接的IP地址和ORA-12170: TNS:Connect timeout occurred错误。
这个参数的引入，主要是防止DoS攻击，恶意攻击者可以通过不停的开启大量连接请求，占用服务器的连接资源，使得服务器无法提供有效服务。在10.2.0.1起，该参数默认设置为60秒
但是，这个参数的引入也导致了一些相关的bug。比如：
