HP-UX B.11.23,Oracle 10.2.0.4企业版, A机与B机配置成集群,以RAC的方式同时运行在A机和B机上。 用PLSQL Developer执行存储过程DB link加载数据,每次执行大概3小时左右,但却每隔两小时左右断一次,导致数据加载失败。 问过oracle安装人员,没有超时设置。 
问过网管,防火墙没有特殊设置。 就这么小段: 
      INSERT INTO A_RCVED_PL_FLOW(RCVED_PL_ID,RCVED_AMT_ID,ITEM_CODE,PL_AMT,ORG_NO) 
      SELECT RCVED_PL_ID,RCVED_AMT_ID,ITEM_CODE,PL_AMT,ORG_NO 
      FROM A_RCVED_PL_FLOW@DB_EPM A 
      WHERE  EXISTS (SELECT 1 FROM A_RCVED_FLOW B WHERE A.RCVED_AMT_ID=B.RCVED_AMT_ID AND B.ORG_NO LIKE V_SUB_DEPT) 
      AND A.ORG_NO LIKE V_SUB_DEPT; 
      COMMIT; 记录数大概2400万
怎么解决啊? 

解决方案 »

  1.   

    把select出来的数据分段之后按段insert,commit
    再次中断了只需要重新处理中断时的分段数据
      

  2.   

    数据库是 不是不支持常时间事务啊。试每次 insert 1000 行 ,每次commit.
      

  3.   

    运行一下
    SHOW PARAMETER RESOURCE_LIMIT;看看有没有资源限制。如果有的话,把时间什么的调大点
      

  4.   

    SELECT * FROM dba_profiles;用这个SQL语句查询当前用户用到的profiles在出来的resource_name结果列中找到‘CONNECT_TIME’,‘IDLE_TIME’如果这个列值太小可以改大一点如  ALTER PROFILE PROFILE_NAME LIMIT CONNECT_TIME/IDLE_TIME UNLIMITED 我这里的UNLIMITED 是将它改为没有时间限制!CONNECT_TIME用于指定会话的最大连接时间,IDLE_TIME用于指定会话的最大空闲时间!profiles我们可以自定义创建如果没有自己创建的话那就是系统默认的,可以这样改ALTER PROFILE DEFAULT LIMIT CONNECT_TIME/IDLE_TIME UNLIMITED
      

  5.   

    我查了IDLE_TIME和CONNECT_TIME都是UNLIMITED。会不会是HP-UX B.11.23有连接时间限制啊。
      

  6.   

    你确认你查的IDLE_TIME和CONNECT_TIME都是UNLIMITED是你所边接的服务器端的而不是你本地数据库的!
      

  7.   

    先看服务器的sqlnet.ora文件中是否配置SQLNET.EXPIRE_TIME参数,可新增该参数,值单位为分钟。如不行,可试试putty工具,启用其中的“sending of null packets to keep session active”功能。
      

  8.   

    想起了EXPIRE_TIME应该是控制异常连接的,估计不行。你这个是OS问题,还是用第二个方法试试。
      

  9.   

    还有sql应该分批提交,告警日志有信息吗?你的UNDO够不够?
      

  10.   

    还没结贴?[分析]ORA-03113错误分析 
    http://www.chinaunix.net 作者:txfy  发表于:2003-12-30 08:58:23 fenng老大的作品,虽然fenng老大很少在本论坛发帖子,可是实际上可是个活跃于各大论坛的oracle高手,这篇03113错误分析,大家读读就会发现我说得不假,好像我上次还转过他的一篇单机装standby呵呵! 
    03113是一个很常见又不是很好解决的错误,大家看看吧! ORA-03113错误分析  版本历史  
    2003-5-22 v0.1 Created by Fenng ([email protected])  
    版权声明  
    转载请注明作者及出处  ----------------------  
    前言  
    ----------------------  
    每一个DBA在进行数据库管理的过程中不可避免的要遇到形形色色的错误(ORA-xxxx).有些错  
    误由于频繁出现、原因复杂而被DBA们戏称之为"经典的错误".其中ORA-3113 "end of file  
    on communication channel" 就是这样的一个.  我们可以简单的把这个错误理解为Oracle客户端进程和数据库后台进程连接中断.不过,导致  
    这个错误的原因实际上有很多种,对数据库设置不当、任何能导致数据库后台进程崩溃的行  
    为都可能产生这个错误.这个错误的出现还经常伴随着其它错误,比如说:ORA-1034 ORACLE  
    not available.  此外,该错误出现的场景复杂,可能出现在:  
    -- 启动的Oracle的时侯;  
    -- 试图创建数据库的时侯;  
    -- 试图对数据库进行连接的时侯;  
    -- 在客户端正在运行SQL/PL/SQL的时侯;  
    -- 备份/恢复数据库的时侯;  
    -- 其它一些情况下......  
    在论坛上也时常可以看到初级DBA对这个问题的求救.  
    在这里简单的对该问题进行一下整理.不当之处,请多指教!  -------------------------  
    错误原因种种  
    -------------------------  
    根据网络上大家反映的情况来看,错误原因大约有这些:  -- Unix核心参数设置不当  
    -- Oracle执行文件权限不正确/环境变量问题  
    -- 客户端通信不能正确处理  
    -- 数据库服务器崩溃/操作系统崩溃/进程被kill  
    -- Oracle 内部错误  
    -- 特定SQL、PL/SQL引起的错误  
    -- 空间不够  
    -- 防火墙的问题  
    -- 其它原因  在开始解决问题之前,作如下几件事情:  1、 回忆一下在出现错误之前你都做了什么操作,越详细越好;  
    2、 查看background_dump_dest目录中的alertSID.log文件也是你要做的事情;  
    3、 Google一下,在互联网上有很多信息等着你去发现,不要什么都问别人.当然,  
    如果你找到了一些对你非常有帮助的东西――这篇文档就不用看了,别耽误你的时间,呵呵.  ---------------------------------------------------------------------  
    Unix核心参数设置不当/ init参数设置不当  
    ---------------------------------------------------------------------  
    如果数据库在安装过程中没有设定正确的操作系统核心变量,可能在安装数据库文件的时侯  
    没甚么问题,在创建数据库的时侯常常会出现03113错误.和此有关的另一个原因是init.ora  
    参数文件中的processes参数指定了不合理的值,启动数据库导致错误出现(当然这个归根到  
    底也是核心参数的问题).  这个错误信息一般如下:  ORA-03113: end-of-file on communication channel  
    ORA-01034: ORACLE not available  
    ORA-27101: shared memory realm does not exist  解决办法有两个:  
    1修改核心参数,加大相应核心参数的值(推荐);  
    2减小init.ora参数的Processes的值.  需要注意的是:  
    SEMMSL必须设定为至少要10 + 进程数的最大值.  
    SEMMNS 也依赖于每个数据库上的进程参数值.  -------------------------------------------------------------------------------  
    注:  
    这个错误类型只在Unix平台上出现.在Windows上如果processes的值过大,则会出现:  
    ORA-00068: invalid value 24200001 for parameter max_rollback_segments, must be  
    between 2 and 65535 /* 此时指定的参数值超过了65535 */  
    或者  
    ORA-27102: out of memory /* 小于65535的一个大参数值 */  
    我的软件环境:  
    Windows 2000 Version 5.0 Service Pack 3, CPU type 586  
    ORACLE RDBMS Version: 8.1.7.0.0.  
    -------------------------------------------------------------------------------  
    在特定平台上更改核心参数可能会有差别,请参考Oracle  
    Technet(http://otn.oracle.com)上的安装文档.对特定Unix平台的安装文档也有对核心参  
    数意义的解释.  Init.ora中的参数如果设置不当,会产生该错误.有经验表明:shared_pool_size设置过小会  
    出现错误,此外timed_statistics=true的设置也会带来问题.  ------------------------------------------------------------------------  
    Oracle执行文件权限不正确/环境变量问题  
    ------------------------------------------------------------------------  
    这个问题只出现在Unix平台上.常见情况是有的时侯管理员为了方便而使用Unix  
    的tar命令处理过的压缩包进行的安装,或者是系统管理员指定了额外的OS用户也可以管理数  
    据库却没有指定正确的环境变量.  Oracle执行文件在$ORACLE_HOME/bin目录下,如果出现问题,应该用如下Unix类似命令来纠正  
    :  chmod 7755 $ORACLE_HOME/bin/oracle  有的时侯要对Oracle进行relink操作.  
    在Unix上通过cp拷贝安装的时候,常常会出现环境变量的问题,和个别执行程序连接问题.LD_  
    LIBRARY_PATH如果设置的不正确会导致问题,在这种情况下,需要对Oracle进行relink.如果  
    可执行文件oralcle被破坏,也要对其relink.  如果安装了并行服务器选项而Distributed Lock  
    Manager没有安装或正确运行也会导致错误.  --------------------------------------------  
    客户端通信不能正确处理  
    --------------------------------------------  
    SQL*Net驱动器的问题:  
    如果使用的版本比较低的驱动器,请更换到新版本的驱动.SQL*Net  
    的驱动没有连接到Oracle可执行文件会导致错误.  检查网络是否通畅  Windows平台的常见问题:  
    在Windows平台创建数据库的时侯,如果出现该问题可以考虑用如下的方法:  
    首先检查本地网络设置.查看网络上是否有同名的结点或有冲突的IP.如果问题依旧,可以保  
    守的用下面的方法:  
    1. 禁用网卡:将本地连接状态改为禁用;  
    2. 将sqlnet.ora文件打开(以记事本形式)将nts验证注释掉:  
    #SQLNET.AUTHENTICATION_SERVICES= (NTS).  
    3. 创建数据库;  
    4. 创建成功后,恢复本地连接.  ----------------------------------------------------------------------------  
    数据库服务器崩溃/操作系统崩溃/进程被Kill  
    ----------------------------------------------------------------------------  
    在连接过程中,如果Oracle数据库的服务器崩溃或者数据库所在的操作系统崩溃,就会出现这  
    个错误.Oracle  
    Server崩溃的原因可能因为主要后台进程死掉.被错误的进行了Kill操作.如果是这个原因还  
    是比较容易解决的.此外,和OS有关的应用程序存在内存泄漏(或者有病毒)的时侯也会导致Or  
    acle后台程序问题.  推荐排错办法:  
    1、 查看应用软件相关进程是否正常运行;  
    2、 查看有无内存泄漏;  
    3、 查杀病毒;  
    4、 确定系统管理员没有进行误操作;  
    5、 确定无黑客入侵行为.  
    6、 其它不确定因素......  ------------------------------------  
    Oracle 内部错误/ Bug  
    ------------------------------------  
    如果查看background_dump_dest目录中的alert.log发现有无ora-600等错误,可以到Metalin  
    k站点上查看具体信息及其解决方案.一般情况下要打软件补丁.  
    特定SQL、PL/SQL引起的错误  
    尝试把SQL进行分开执行,也可以用SQL_TRACE来进行跟踪,找到导致问题的SQL语句:  
    在SQLPlus下:  
    ALTER SESSION SET SQL_TRACE TRUE;  SQL语句中的非法字符和不合理的处理结果偶尔会带来问题.  ------------------------  
    系统空间不够  
    ------------------------  
    任何时侯都要确保数据库系统有足够的空间.如果 USER_DUMP_DEST  
    和BACKGROUND_DUMP_DEST没有剩余空间的话,会导致此问题.此外,如果打开了审计,AUDIT目  
    录要由足够的空间.如果激活了Trace的话,Trace目录要由足够的空间.  Dave Wotton的文档表明,在对表进行插入数据的时侯,如果文件超过了2G  
    (而文件系统有2G限制),会导致该问题.  -------------------------  
    防火墙的问题  
    -------------------------  
    如果数据要通过防火墙,请联系系统管理员,询问是否对数据库数据进行了过滤或者是突然禁  
    止了通行端口.如本地安装有个人防火墙,请检查本地设置.  
     
     
      

  11.   

    我们这边半个小时一断...DBLINK那边做了限制..
    分段插入吧~ 试着分批INSERT
      

  12.   

    我现在都是远程登陆利用shell脚本调用存储过程,最慢的一张表用两个半小时也就导完了