Action:If the situation described in the next error on the stack can be corrected, do so; otherwise contact Oracle Customer Support.

　　ORA-00604: 递归某个SQL 层时出现错误

　　原因:在运行一条递归SQL语句(该语句将应用于对内部表或数据字典的操作)时，发生错误。

　　方案:如果上述描述的错误所在栈可以被修复，则修复并继续运行;否则，请联系Oracle客服。当然，那是Oracle官方的解决办法。我曾经记得有个高手总结了关于ORA-00604/ORA-04031问题的解决：

　　修改INIT.ora

　　添加

　　_db_handles_cached = 0

　　并重新启动数据库.

　　分析:ORA-00604这个信息表明，在数据库执行内部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)数据库中。

　　案例一:Oracle执行递归查询的时候出错

　　问题描述:我经常遇到ORA-00604 和ORA-01000(开启游标数量达到最大值)错误。然而，当我检查代码的时候，所有的结果集和语句对象都在最后的块中关闭了(我使用的是JDBC)。我执行的查询是一个Oracle递归查询(以这个开始并通过这个连接)。您能告诉我是哪里出现了问题，以及在什么样的情况下会出现上述的错误吗?

　　解决方案:可能是init.ora 文件中的open_cursors 参数值的设置太低了。这个参数的默认值是非常低的(50)。它应该设置为200或者更高。即使是你关闭了结果集，但是你并没有在JAVA代码中关闭SQL语句，就会导致这个问题。

　　如果设置为yes的话，那么确保你的活动连接池启用了(为了性能的原因)，否则设置为no。

　　请你的数据库 管理 员监视数据库，并看看使用V$OPEN_CURSORS 和 V$SYSSTAT数据字典视图的条目。

　　案例二:Exp出错的一个案例
　　问题描述:客户用的 Linux 系统，Redhat 企业 版(RHEL 3.0).数据库,安装的9iR2, 前一段时间升级过.现在的版本是9204.

　　客户准备要做Exp导出，以前一直系统没有空间.先给给系统扩了一些空间。Linux下的LVM还算比较好用。虽然文件系统用的是ext3 ,要暂时停机.

　　进行导出操作,不成功,发现系统报告错误:

　　EXP-00056: ORACLE error 942 encountered

　　ORA-00942: table or view does not exist

　　EXP-00000: Export terminated unsuccessfully
　　很多朋友可能对这个错误都很熟悉.

　　哦,对了,客户说是升级过数据库，首先猜测是不是升级有问题?毕竟在论坛上类似升级不成功的问题看过很多了.

　　执行$ORACLE_HOME/rdbms/admin/catpatch.sql 脚本.

　　同时要注意调大java_pool_size 和shared_pool_size这两个参数的大小,要不重新来就耽误时间了，不要犯低级错误

　　SQL>shutdown immediate;

　　SQL>startup migrate;

　　SQL>@?/rdbms/admin/catpatch.sql
　　之后查看Spool 出来的日志. 发现有编译错误，重新执行了第二次. 等待……之有这个时候我才想起才抱怨CPU不够快,内存不够大

　　这次Log没错误.不料想………………..用户连接报告错误:

　　ERROR at line 1:

　　ORA-00604: error occurred at recursive SQL level 1

　　ORA-04045: errors during recompilation/revalidation of LBACSYS.LBAC_EVENTS

　　ORA-06508: PL/SQL: could not find program unit being called

　　ORA-06512: at line 2

　　ORA-06508: PL/SQL: could not find program unit being called

　　ORA-06512: at line 2
　　发现connect / as sysdba 还是可以登陆进去的。

　　看来是 LBACSYS.LBAC_EVENTS的状态有点问题。联接进去，编译一下如何? 我的如意算盘是@?/rdbms/admin/utlrp.sql执行一下就没有问题了，不料根本没有用，错误依然。当时有些头晕，这系统还没有备份呢，看来有些麻烦了(心里暗地埋怨客户，一直不让备份，总说”等等再说”,作为一个DBA说话总不被重视也挺悲哀的不是? ，虽然我自己偷着有个备份，不过还是上次升级时候的呢)，赶紧上网Metalink查查，这里 网络 速度还不错 LBACSYS.LBAC_EVENTS 作为关键词，找到如下的信息:

　　The reason for this problem seems to be an Upgrade for Label-Security

　　even if it’s not installed. 　//Label security 没有安装，居然补丁去默认给升级?

　　解决方案:

　　shutdown immediate;

　　startup migrate;

　　alter view lbacsys.lbac$all_table_policies compile;

　　alter package lbacsys.lbac_events compile body;

　　shutdown immediate;

　　startup;
　　支持人员说这是个Bug.但是普通用户不可见. 不太放心，再找找，在Suse.com站点的Maillist也发现了一则类似的案例，看来还可以,心里有底了。

　　按照上面的执行，重新 检查 ，OK。

　　总结一下

　　其实是一个很没有技术含量的Case。首先以前升级的时候至少要测试一下Export是否可以(Export已经成为升级成功的一个标志了!) 其次,准备不够充分,早成了手忙脚乱.所幸不是关键系统,用户还可以容忍.Oracle 总说 微软 是个烂公司,其实他们才真的够栏.Bug多的不可胜数.

　　案例三:使用网络应用程序的时候出现递归SQL错误

　　问题描述:当我使用网络应用程序的时候，遇到了下面的这个错误。

　　ORA-00604: 递归SQL1级的时候出现错误。

　　ORA-04031: 无法分配4200字节的共享内存，”RBKS_BK_INFO”, “sga_heap”, “library cache”。

　　这些错误信息是什么意思?我该如何解决它们?它们是在应用程序里面还是数据库里面?

　　解决方案:您应该使用的是Oracle 8.1.7.4之前版本的Oracle。第一个错误信息告诉你Oracle针对你的行为执行的SQL 语句失败了。ORA-4031告诉你为什么它会失败。ORA-4031错误信息的意思是你没有获得足够的空闲空间。你可以增加你的SHARED_POOL_SIZE，重新启动数据库再拭一次。这个bug已经在后续的补丁包中修复了。如果你使用的不是这个版本，你可以应用一下补丁包。
　案例四:Sql_trace进行Oracle诊断案例
　　问题说明:很多时候，在我们进行数据库操作时，比如drop user,drop table等，经常会遇到这样的错误

　　ORA-00604: error occurred at recursive SQL level 1 .

　　这样的提示，很多时候是没有丝毫用处的.本案例就这一类问题提供一个思路及方法供大家参考.

　　1. drop user出现问题

　　报出以下错误后退出

　　ORA-00604: error occurred at recursive SQL level 1

　　ORA-00942: table or view does not exist .
　　关于 recursive SQL 错误

随着信息技术的发展与进步，医院信息系统的数据处理量和存储量会越来越大。各项业务系统运行的持续性、稳定性，业务数据的完整性、正确性、有效性，直接关系到医院的运营、管理与决策活动，这就要求对网络通信、服务器及存储设备等关键硬件设备，以及各种操作系统、数据库管理系统等软件的故障恢复进行整体的设计和部署。如果没有可靠实用的备份系统。任何一个环节发生故障和灾难，都会导致医院的业务活动无法正常进行，造成重要数据的丢失和破坏．给医院带来巨大损失．给广大患者带来不便。严重时更会带来重大的社会影响和政治影响尽管我们一再小心谨慎。但是。必然还会发生各种各样的故障甚至灾难。针对可能发生的故障或灾难。采取的唯一措施就是建立一套完整的备份与恢复方案。由于数据库管理系统是医院信息系统的核心。一旦发生故障或灾难，医院信息系统的运行恢复关键取决于数据库的恢复程度和时间。因此，数据库备份与恢复的必要性和重要性非同一般，我们的备份目标及原则应当保证在最短的时间内，尽可能完全地恢复数据。

2 备份方法的选择与比较

目前，军队医院全部使用“军卫一号”系统，后台数据库也都是采用Oracle数据库管理系统。备份方案除极少部分医院使用自购的第三方厂家的专用数据库备份软件外，绝大多数医院采用的是Oracle公司提供的物理备份机,费用较高，因此，本文不做评价。

Oracle公司提供的物理备份解决方案是其最传统的方案。

从早期版本开始，就是由数据库管理系统软件本身提供的。不必额外投资。可以降低成本；备份数据库服务器的配置可以低于在用数据库服务器，节省开销：此方案是定时备份数据库的有关文件及记录数据库变动情况的归档日志文件．一旦数据库需要恢复时，在备份的数据库有关文件基础上，应用备份的归档日志文件，使数据库恢复到所需要的时间点。本方案如果设置完整合理，具有较强的可靠性和可操作性。尤其是可以将数据库恢复到任意时间点，所以，既可以应对各种软硬件故障，还可以挽救软件或人为错误导致的数据丢失。正是因为具有以上这些特点，使得该解决方案成为多数医院数据库备份的首选。

在Oracle7版本时，Oracle公司就提出了待用数据库的概念，并提供了Standby解决方案。到了Oracle8i，在Standby础上，完善、增强了其功能，并将此解决方案称之为DataGuard。该方案需要首先创建待用数据库， 实际上也是在用数据库的备份，然后通过不断地备份、复制及应用归档13志文件，保持其与在用数据库的同步，一旦数据库需要恢复时，只需要再同步少量归档13志文件即可立刻恢复，本方案与物理备份比较．其最大的好处就是可以在数据库发生故障时，在尽可能短的时间内恢复数据库，这对于数据库可用性要求高的应用尤为重要。

首先。由于DataGuard也是Oracle公司随数据库软件产品提供的， 同时待用数据库服务器的配置也可以低于主数据库服务器，所以也具有物理备份节约成本的特点；另外，该解决方案具有保持与在用数据库同步的特点，可以在较大程度上缩短数据库的恢复时间，对于医院信息系统7~24h不停顿的应用情况是难能可贵的；尽管待用数据库解决方案可以提供快速的恢复，但正是为了实现快速恢复，需要及时地同步待用数据库，而这种同步操作又是不可逆的，因此，使它具有一定的局限性。即无法恢复到任意时间点。例如：对于软件或人为错误导致的数据丢失，此方案无法挽救。针对以上特点，我们认为该方案不是医院数据库备份的唯一最佳方法。通常可以根据自己医院的应用及环境。考虑单独采用数据库物理备份或者待用数据库的方案。如果需要满足多种故障恢复需求时，可以采用二者结合使用的方案，效果会更佳。

当然，物理备份和DataGuard由于实现的原理和方法不同，在创建、维护、应用等方面也存在一些差异，由于所有的“军卫一号”用户对物理备份已经相当熟悉，因此，本文仅就同行关注的DataGuard做比较详细的描述。

3 Oracle8i的DataGuard原理及新特点

Oracle8i的DataGuard(在Oracle7时称为Standby)即指待用数据库。它是利用主数据库备份建立的一个数据库复制品。主数据库和待用数据库的同步是通过将来自主数据库的归档重做日志应用到待用数据库实现的。

采用Oracle8i的DataGuard待用数据库作为备份与恢复解决方案，具有以下特点：(1)待用数据库解决方案支持目前所有版本，包括目前使用的Oracle8．1．7，将来如果系统平台升级，无论是Oracle9i J~是Oraclel0g，都支持待用数据库解决方案，而且，随着版本的提高，该解决方案的功能也随之增强，性能也随之提高，具有很好的延续性。(2)自动化程度较高，减少管理及维护成本。Oracle8i的DataGuard可以通过SQL*Net将主站点生成的归档日志文件自动传输到待用站点，同时．还可以将来自主站点的归档日志自动应用到待用数据库。这些是Oracle7的Standby无法做到的，通常需要数据库管理员通过操作系统的脚本及数据库的命令来实现。(3)待用数据库解决方案的实现技术，与通常数据库物理备份相比较而言，最大的好处就是极大地缩短了数据库的恢复时间。(4)数据丢失少，由于该方案仅能应用归档日志，不能应用联机日志。因此，在极端的情况下。如果无法归档联机日志．可能会丢失联机日志文件中尚未归档的数据库改动内容。(5)本方案除了具有数据库的灾难恢复和防止坏数据的保护功能外，还可以只读方式打开待用数据库，不但可以临时提供影响主系统性能的查询统计等业务服务．降低主数据库服务器的性能负载，还可以对本方案的备份恢复进行常规测试，便于及时发现可能存在的问题并使之得到解决．这些也是Oracle7的Standby无法做到的，因为它不支持只读方式打开数据库，只能靠激活数据库来测试，又由于激活操作是不可逆的，所以，当需要临时使用待用数据库或恢复测试后，都需要重新建立环境，非常不方便。(6)当发生灾难时，可以将待用数据库激活，使其立即替代主数据库．为应用系统提供数据库的服务与支持。(7)在灾难备份与恢复的概念中，本方案属于不完全的数据级备份。因为只包含数据库中的数据，而医院应用的数据不但包括数据库中的数据，就目前“军卫一号”应用来说，还应当包括病历文件、输入法文件及应用程序，这些也是不容忽视的。(8)本方案不支持数据库任意时间点的恢复．因此．如果对数据库的恢复有更高要求的话，还需要增加其它备份方案。

综上所述．如果使用Oracle8i的DataGuard，可以达到的应用目标是灾难和软硬件故障恢复。以及补充的查询统计环境。为了进一步提高数据库的安全系数．我们还可以将待用数据库的物理放置与主数据库分开．即最好分别置于不同的建筑物中，实现同城的异地备份。在具体实施过程中，最好利用本方案的自动管理特性，减少复杂性和中间环节，提高系统的可靠性。

4 DataGuard实施过程与维护要点

在使用DataGuard之前，需要为其创建环境，通常需要单独准备一台服务器来安装待用数据库。如果机房、网络等条件具备。还可以将其放置在远离主数据库服务器存放的地方。建立待用数据库过程的简要步骤 如下：(1)做主数据库的备份：利用已经存在的备份也可以。即新旧或是否一致均可．因为可以利用归档日志进行恢复。(2)创建待用数据库的控制文件：连接主数据库，同时主数据库必须是归档方式及自动归档，使用专门的SQL命令，为待用数据库创建控制文件。(3)复制有关文件到待用数据库：需要复制的文件包括：数据文件备份、待用数据库控制文件及主数据库备份后生成的归档日志文件．使用操作系统命令进行拷贝，如果主数据库与待用数据库的路径不同，还需要使用专门的SQL命令或修改待用数据库的有关初始化参数来改变数据文件的路径。(4)配置网络文件：配置主数据库端的tnsnames．ora，为待用数据库创建服务名。以便日志文件自动归档到待用数据库：配置待用数据库的listener、ora满足监听服务请求，以便接收来自主数据库的归档日志文件。

(5)主数据库配置有关初始化参数：根据自动管理方式的要求，除一个本地归档目的地外，必须有一个带服务名的远地归档目的地，建议本地使用MANDATORY选项．远地可使用OPTIONAL选项，REOPEN选项可以在归档不成功时自动再次访问。(6)复制并编辑待用数据库的初始化参数文件：为待用数据库设置与主数据库不同的运行环境。(7)启动待用数据库的实例并加载数据库：执行具有待用数据库专门选项的STARTUP MOUNT命令。(8)应用归档日志到待用数据库：在待用数

据库创建过程中．待用数据库的数据改动情况肯定会滞后于主数据库，其中的差距通常称之为缝隙。在实行自动管理前，首先要填补这些缝隙．即先在主数据库执行归档．然后在待用数据库查询缝隙信息，再执行相应的手工应用。(9)启动归档日志的自动应用管理。

以上过程执行完毕，待用数据库环境就建立起来．以后就可以通过数据库管理系统进行自动同步了。当然，待用数据库建立之后，还存在备份的测试、特殊的维护、待用数据库激活，以及待用数据库的模式改变切换等情况。因此，还需要注意以下方面的问题：(1)由于主数据库物理结构的改变，可能会影响待用数据库，其中有些是由系统自动维护的，不需要数据库管理员人工干预，有些则不然，这时还需要数据库管理员进行简单的手工维护。(2)当主数据库发生故障，需要启用待用数据库时，可以将其激活，这个操作会使待用数据库永久地转换成一个主数据库，由于该操作是单向的，不可逆转，所以，启用后不能撤消，以后还需要创建新的待用数据库。(3)待用数据库需要定期进行测试，在测试时一定不要执行激活操作，只需以只读模式打开它即可，这时可以进行查询，保证待用数据库的数据确实根据来自主数据库的重做日志进行了相应的更新与同步。(4)利用待用数据库的只读模式，还有助于减少主数据库的查询负荷，尤其是大的统计查询，可以将这些访问操作转移到待用数据库端来。

刘宏波孟毅边玉森

沈阳军区第201医院信息科(111000)

“军卫1号”工程医生工作站子系统在使用过程中，难免有问题和错误出现，通过在日常维护工作中，对遇到的各类问题的积累，做了一下简单的归纳总结，下而我谈谈医生工作站子系统运行中的常见错误及处理方法．供同行商榷。

1 启动中COMSRVR．EXE文件不可丢失医生工作站保存提交医嘱后，护士工作站没有信号提示声发出，需人为通知护士有新开医嘱。这是由于护士工作站客户端启动中的COMSRVR．EXE文件丢失，我们在护士工作站文件夹中找到这一文件，复制、粘贴到启动中，医生工作站的错误即可消失。

2 使用版本的一致性问题

医生工作站保存提交医嘱时，提示与护士工作站通信失败，查出护士站计算机名出错。这是由于医生工作站和护士工作站版本不匹配造成的，在更新医护站的版本时，要注意相互一致，不要一个皈本高，一个皈本低，这将会导致上述错误的发生。

3 WORD文档剪切板的记忆功能不可忽视医生工作站中，医生的病程记录偶有内容更改的现象。例如，微机中A病人的病历内容变成了B病人的病历内容，这是由于WORD文档的剪切板在作怪，剪切板有保存记忆功能，有时难免给操作者造成误导，这就要求工作人员保存病历之前先看清楚内容再操作，并且用完工作站要记得随手关闭工作站．而不要最小化，以免误操作而带来麻烦。

4 操作系统的顺序和规范化操作

医生进入医生工作站时，系统提示执行了非法操作，导致医生进不去工作站。这是系统操作者对转科或退院病人处理不当所致，正确的操作方法是：医生工作站先把病^、资料移出，然后再由护士站办理出院或转科。反之，如果护士站先移出．则造成上述结果。处理这种问题的方法有多种，其一是系统维护人员处理，打开MR—ON—LINE表，对退院病人删除该条记录，对转科病人直接修改医生用户名即可。其二临床科室可自行进行处理，护士可把病人暂调回护士工作站，先让医生对其处理后，再由护士工作站进行操作，但这种方法如处理不当，会导致统计数据的不准确，所以建议用第一种方法。

5 医生工作站偶尔对新入院病人或转科病人有接收不到的现象这种原因是在转接过程中，工作人员操作不当所致。对于转科病人，他的操作规程是：由转出科室医生站移出，再由转出科室护士站办理转科，而后转入科室护士站办理移人，转入后待护士在病人基本信息中选取医生姓名后，最后通知医生移人，按上述方法操作，将会避免错误的发生。修改方法是用PB打开表MR—ON—LINE (联机病历描述表)．修改病人ID号对应的医生用户名和病人状态即可。

6 医生将未出院病历误提交或移出的问题

用PB先打开MR—ON—LINE表，是空的状态，追加～条记录，有记录存在，对其对应的ID号进行修改，把病人状态一项改为在院，输入经治医生的用户名，后用PB打开表MR—INDEX．看看MR—STATUS字段内容是O (打开)还是C (关闭)状态． 如果是C (关闭)状态， 则改成O (打开)状态．否则，再继续写的病历无法保存，这是一个特别应该注意的问题。

7 激活WORD出错的现象

医生的病历，有时会出现激活WORD出错的现象，一旦出现这种现象，病历将很难恢复。这是由于有些输入法和WORD冲突的原因，建议工作人员关闭病历模板之前先切换到英文状态下，这样可以降低错误的发生率8 医生工作站子系统调不出来的问题

学习病历是常用的功能之一，但偶尔有调不出来的现象。这有两种原因，① 医生调用的学习病历看完后没有及时的移出：② 是医生写完的病历没有进行提交操作．而是移出病历或其他非法操作造成。这首先要求我们用完学习病历要时移出，以免影响别人的使用，其次是要按医生工作站操作规程的规定，正确提交出院病人病历。

9 医生、护士工作站的操作失误

医生工作站中医生管理的病人不在自己工作站中，在远项中选择显示全科病人时，该病人存在，且病人名字后注释经治医生的姓名。这种现象主要是医生对转科病人操作不当，造成信息丢失：另一种原因是护士站操作失误，护士站病人信息中的医生姓名和MR—ON—LINE中医生名不符．修改病人信息中的医生姓名和MR—ON—LINE表中的医生用户名一一致即可。

10 护士站逐条转抄医嘱，必须正确执行

医生保存提交的医嘱，护士转抄保存时失败 这是医生下达医嘱过程中个别医嘱内部信息出错，导致护士全部提取医嘱转抄保存失败，这种错误通过后台开表处理非常烦琐，效果也不是很好。最简单的办法是护士站逐条转抄医嘱，正确的医嘱会正常执行， 对于内部出错的医嘱会出现错误提示，通知医生作废此医嘱，重新下达即可。