一次ORA-01041错误诊断

设计Oracle Form的时候编写程序单元时候遇到的，在网上找的，只要重新连接数据库就行了。

转自:http://book.51cto.com/art/201001/177547.htm

一次ORA-01041错误诊断

这也是协助别人解决的一个问题，其实这个错误并不是很复杂，不过让我感触比较多。我最开始收到的信息就是在访问数据库时出现了ORA-01041错误。

由于只有一个错误信息，诊断问题很困难。在我的进一步要求下，收到了错误的详细信息如下：

 
 
2006-7-3 12:13:30:  
ORA-01041: 内部错误，hostdef 扩展名不存在  
 SELECT * FROM ( SELECT ROWNUM as numrow, zz.* from ( SELECT 
ID, URL, MEMBER_TYPE , LAST_UPDATE_DATE FROM USR_MODULE  
where LAST_UPDATE_DATE-to_date('2006-06-21 09:19:52',  
'yyyy-mm-dd HH24:mi:ss')>0 ) zz WHERE ROWNUM < = 2000  )  
WHERE numrow >=1 

这个错误倒是不陌生。在一个SQLPLUS客户端连接到Oracle的过程中，Oracle数据库执行了关闭和启动的操作，且在关闭数据库时这个SQLPLUS的连接并没有退出。那么这个SQLPLUS客户端有很大的可能性会碰到这个ORA-1041错误。一旦出现了这个错误，无论使用什么用户进行重新连接都没有作用，必须退出SQLPLUS，再重新启动SQLPLUS才行。这说明SQLPLUS工具的状态已经不正确了。

仅仅有这点错误信息还是不够的，判断问题的原因还需要更多相关的信息，比如数据库的版本、平台，以及是在何种情况下出现了上面的错误。

因此我提出需要数据库的版本和操作系统的信息，最好将数据库的alert文件同时发送过来。

在等待回复的过程中，我在Metalink上查询了一些有关ORA-1041错误的信息。看看是否有其他未知的Bug会导致这个错误的产生。不过缺少数据库版本信息和平台信息，无法确定Oracle描述的Bug与当前的问题是否相符，因为绝大部分Bug都是在特定的版本、特定的平台上出现的。

直到我得到完整的错误日志文件才发现做了很多的无用功：根本没有必要去查询Metalink。

首先，这个错误信息不是记录在Oracle的alert文件中，而是在应用程序打印的日志信息里。其次，提供给我的错误只是整个错误文件中次数最多的错误，而并不是所有的错误信息。不但漏掉了其中的几个关键错误信息，而且导致问题产生的第一个错误也没有提及。

整理错误信息后，发现没有发给我的错误信息还包括：

ORA-12571: TNS: 包写入程序失败

ORA-03114: 未连接到Oralce

ORA-03113: 通信通道的文件结束

只须通过上面的这3个错误信息，马上就可以定位到问题。由于会话连接到Oracle的时间超过了交换器上空闲时间的设置，导致这个连接直接被交换器切断，使得应用程序处于不正常的状态，最终导致了上面的那个ORA-01041错误。

如果一开始就把完整的错误日志发送过来，问题可以很快解决。很多时候能否准确地定位问题完全取决于信息提供的是否准确和完整。

其实找出问题的最好方式是通过自己的提炼，能用一个简单的例子重现问题。如果这点无法做到或者很难做到，那么最起码应该提供充足的信息。这是定位、分析和解决问题的基础。如果错误日志中报了30多个错误，而你对其中一个进行分析，显然得到的结果也是片面的、不准确的。

在Metalink上能发现很多没有解决的问题，这些问题中有不少的状态都是"需要进一步的信息"。Oracle的技术支持在缺少关键信息时都无法确定问题，何况其他人了。