日期:2013-05-18  浏览次数:20633 次


 ORACLE中一些问题的处理方法

在ORACLE管理和使用中,难免出现一些问题。通常,ORACLE会显示错误标号和简短说明,我们可以依据显示的信息去处理问题。但有时显示的信息很少,处理起来有些麻烦。本文讨论了这样几个问题,依据一些材料和经验,提出了处理方法。

 

一、             ORA-00604 error occurred at recursive SQL level

这个信息表明,在数据库执行内部SQL语句时,发生了错误。比如,要往表中插入一行数据,但没有可扩展的空间。ORACLE于是去查寻,哪儿可以建立下一个扩展空间,它有多大小,但没有成功。普通在发生ORA-00604错误时,还伴随着其它的错误,例如:ORA-1547等。

首先,该当检查警告文件alertSID.log,查找有关ORA-600类的信息。

该错误最常见的缘由是数据库文件initSID.ora中的参数OPEN_CURSORS值太小。可以修正initSID.ora文件,OPEN_CURSORS的值普通为255。修正完后,宕下ORACLE,再重新启动。

还可以设置并启动数据库的事件跟踪功用。在initSID.ora中加上一行:

     event = "00604 trace name errorstack"

宕下并重新启动ORACLE,使这个事件跟踪参数起作用。这样,当再发生ORA-604错误时,有关信息就保存在TRACE文件中。

形成ORA-604错误的其它缘由可能有:

- initSID.ora中,参数DC_FREE_EXTENTS或ROW_CACHE_ENQUEUES太低。可以依据操作系统和数据库的情况,适当添加这两个参数的值,宕下并重新启动ORACLE。

- 运转超出空间(伴随ORA-1547错误)。这时,要对表空间添加新文件,即添加表空间的大小。

- 达到了MAX_EXTENTS(伴随ORA-1556错误)。如果这样,就要修正表,允许更多的扩展。请从技术手册中查找MAX_EXTENTS的最大值。如果曾经达到了最大值,必须用compress extents选项,把表卸出(export),再导入(import)数据库中。

 

二、ORA-03106 fatal two-task communication protocol error

这个信息表明,在ORACLE进行网络通信任务时,发生了错误。比如,客户使用程序使用SQL*NET访问服务器数据库时,不能进行,ORACLE显示ORA-03106错误。

首先,该当检查客户使用与数据库服务器之间的兼容性,这是ORA-03106错误中最常见的缘由。现已发现,Developer/2000 V1.3预版与ORACLE V8.0.5 for Digital UNIX不兼容;ORACLE V7.0.1.6 for ScoUNIX与ORACLE V8.0.5 for Digital UNIX不兼容,等等。再检查客户使用与数据库服务器之间的NLS(字符集)兼容性。前些年计算机上的中文字符集普通设置为ZHS16CGB231280,近几年普通设置为ZHS16GBK,英文操作系统下的设置普通为US7ASCII。最好在系统安装时,把字符集设置为同一种,这样也方便数据库之间数据的卸出和导入。

如果数据库链路不断不通,并显示ORA-03106错误,那么可能是SQL*NET的设置问题。要想使用数据库链路,双方数据库文件InitSID.ora中GLOBAL_NAMES的值该当是FALSE,服务器上的文件TNSNAMES.ORA中要有对方的数据库别名,该别名就是建立数据库链路时使用的别名。尤其在双机等组成的CLUSTER系统中,人们常常在TNSNAMES.ORA中只写入带无机器虚地址的数据库虚别名,而忘记写入带无机器真地址的数据库真别名。该当把实际使用所涉及到的数据库别名都写入TNSNAMES.ORA。

另外,InitSID.ora中OPEN_LINKS的值普通默认为4,在使用程序使用多个数据库链路时,需求适当添加该值。

还可以设置并启动SQL*NET的事件跟踪功用,获得发生ORA-03106错误时产生的有关信息,有针对性地处理问题。

在比较极端的情况下,该问题表明ORACLE所使用的共享内存段崩溃了。可能需求用abort选项宕下数据库,并释放所有的semaphores(UNIX下)。由于ORACLE使用semaphores来控制所有后台进程的同步。Semaphores也用来控制用户进程和影子进程之间的双任务通信。由于该种情况下牵涉的问题比较复杂,可以将整个机器系统宕下,再重新启动。

 

三、从ORACLE8卸出数据并导入ORACLE7中

从ORACLE7卸出的DMP文件,可以导入ORACLE8中;但从ORACLE8卸出的DMP文件,不能导入ORACLE7中。如果用ORACLE7的实用程序,也不能卸出ORACLE8的数据。这对使用多种版本ORACLE的用户是非常不方便的。

实际上,ORACLE8曾经考虑到这一点。在服务器目录$ORACLE_HOME/rdbms/admin 中,有个文件catexp7.sql,就是用来处理这个问题的。首先,在ORACLE8的服务器中,以SYS帐户登入ORACLE,接着运转这个catexp7.sql文件。ORACLE系统于是建立一些卸出视图,从而使得在卸出时,ORACLE8数据库仿佛是ORACLE7数据库。这时,就可以用ORACLE7实用程序直接卸出ORACLE8的数据,然后便可以顺利地导入ORACLE7中。

在用ORACLE7实用程序直接卸出ORACLE8的数据时,有些属于ORACLE8特性的东西卸不出来。具体的情况,可以参考有关的技术手册,比如《Oracle8 Utilities》。

 

四、ORA-27101 Shared Memory Realm Does Not Exist

在出现上述错误信息时,普通还伴有错误信息:ORA-01034: ORACLE not available。缘由是在同一个服务器上,使用了不同的ORACLE_HOME。该问题常常是在ORACLE8.1.7服务器版上出现的。

首先检查文件initSID.ora和listener.ora等,看ORACLE_SID和ORACLE_HOME设置的正确与否,ORACLE8.1.7能否用该参数值启动并运转。在UNIX环境中,字母大小写的意义是不一样的,这一点该当留意。如果ORACLE_HOME指向8.1.7版,而数据库是用8.1.6版或8.1.5版建立的,也可能出现该种错误信息。

在WINDOWS系统中,如果修正了机器名或IP地址,ORACLE8.1.7启动时使用的机器名或IP地址就不是真正的机器名或IP地址,就会出现该种错误。可以查看目录database下的文件oradim.log,依据内容确定缘由。

在涉及到域(DOMAIN)的服务器上,包括WINDOWS和UNIX,依据系统设置情况,可能需求在使用机器名时,后面添加域名。