Oracle脚本停止静默工作，没有任何异常

我有一个Oracle脚本，需要一些时间来执行（合并/更新数百万行），它通过sqlplus执行，输出重定向到日志文件。脚本的执行并不一致，有时它在50分钟内成功运行，这对我们来说已经足够好了，但有时脚本从未停止，没有记录任何异常，日志文件仍然为空，sqlplus似乎被阻塞。在Oracle中运行查询后，我观察到它们突然消失（大约1小时后），就像有人在内部自动终止了事务或流程一样。未更新任何行。 我不是Oracle DBA，所以我不知道要检查什么才能了解那里发生了什么

我已经用一个使用合并指令的示例说明了我的问题，但是在许多其他脚本上遇到了这个问题（例如大量插入）。 共同点是，当脚本需要大量Oracle资源时，我可以更改脚本并对这一大规模更新进行更优化的版本，但我真的很想了解这里到底发生了什么，以及为什么在这个特定情况下我没有任何信息。 我已检查Windows事件日志，但未发现任何内容。 我不知道在甲骨文的什么地方搜索以了解发生了什么。我确信一定有一些内部日志，但我在Oracle管理方面的知识太有限，在这一点上我需要帮助

SET TIMING ON
SET SERVEROUTPUT ON SIZE unlimited
SET FEEDBACK OFF

DECLARE
    PROCEDURE SYMAG_MERGE_CUST_LASTACT 
    IS
        start_time number:= DBMS_UTILITY.get_time; 
        alter_time number; 
        merge_time number; 
        commit_time number; 
        end_time number;
    BEGIN

    -- Session settings 
    EXECUTE IMMEDIATE 'ALTER SESSION SET skip_unusable_indexes = true';
    EXECUTE IMMEDIATE 'ALTER TABLE CUSTOMERS nologging';
    EXECUTE IMMEDIATE 'ALTER SESSION ENABLE PARALLEL DML';
    EXECUTE IMMEDIATE 'ALTER SESSION FORCE PARALLEL DML';

    alter_time := DBMS_UTILITY.get_time;
    DBMS_OUTPUT.PUT_LINE('= Alter1: '||to_char((alter_time-start_time)/100)||'s ');

    MERGE /*+ first_rows parallel(C,8) parallel(SRC,8) */ INTO CUSTOMERS C
    USING (SELECT CST_CODE FROM CUSTOMERS WHERE STA_CODE <> 0) SRC ON (C.CST_CODE = SRC.CST_CODE)
    WHEN MATCHED THEN UPDATE SET CST_DATELASTACT = sysdate;

    merge_time := DBMS_UTILITY.get_time;
    DBMS_OUTPUT.PUT_LINE('= Merge: '||to_char((merge_time-alter_time)/100)||'s ');

    -- Commit 
    COMMIT;
    commit_time := DBMS_UTILITY.get_time;
    DBMS_OUTPUT.PUT_LINE('= Commit: '||to_char((commit_time-merge_time)/100)||'s ');

    -- Session settings restore
    EXECUTE IMMEDIATE 'ALTER SESSION SET skip_unusable_indexes = false';
    EXECUTE IMMEDIATE 'ALTER TABLE CUSTOMERS logging';

    end_time := DBMS_UTILITY.get_time;
    DBMS_OUTPUT.PUT_LINE('= Alter2: '||to_char((end_time-commit_time)/100)||'s ');
    DBMS_OUTPUT.PUT_LINE('----------------------------------------------------------');
    DBMS_OUTPUT.PUT_LINE('= Total time: '||to_char((end_time-start_time)/100)||'s ');

EXCEPTION   
    WHEN OTHERS THEN
        DBMS_OUTPUT.PUT_LINE('= Exception : ' || SQLCODE || ' - ' || SQLERRM);
        Rollback;
        DBMS_OUTPUT.PUT_LINE('= Rollback');
END;

BEGIN
    DBMS_OUTPUT.PUT_LINE('=== Start of script step 3-4(v2)');
    SYMAG_MERGE_CUST_LASTACT();
END;
/

EXIT;

---

[1] 如果没有更多信息，几乎不可能解决您的问题。请参阅，然后使用相关日志数据更新您的问题。[2] 另见。[3] 我认为您的问题可能更适合于。Oracle作业在没有任何消息的情况下中止的少数原因之一是由于ORA-600或ORA-7445错误，即后台进程突然死亡。发生这种情况时，警报日志中应该有一个条目。在目录

select value from v$diag_info，其中name='diag Trace'中，检查名为alert_DBNAME.log的文件希望该文件包含有关错误的更多详细信息。或者，如果您认为有其他原因导致进程或shell脚本死亡，您可能希望通过DBMS_调度程序运行代码。我已经用日志跟踪编辑了我的帖子（这可能表明oracle侦听器配置存在问题）。我仍然不明白为什么Oracle提出了一些异常（不管它们是什么），并且在我的脚本中没有发现任何异常，可能有错误，但我不知道它可能是什么。[1]如果没有更多信息，几乎不可能解决您的问题。请参阅，然后使用相关日志数据更新您的问题。[2] 另见。[3] 我认为您的问题可能更适合于。Oracle作业在没有任何消息的情况下中止的少数原因之一是由于ORA-600或ORA-7445错误，即后台进程突然死亡。发生这种情况时，警报日志中应该有一个条目。在目录
select value from v$diag_info，其中name='diag Trace'中，检查名为alert_DBNAME.log的文件希望该文件包含有关错误的更多详细信息。或者，如果您认为有其他原因导致进程或shell脚本死亡，您可能希望通过DBMS_调度程序运行代码。我已经用日志跟踪编辑了我的帖子（这可能表明oracle侦听器配置存在问题）。我仍然不明白为什么Oracle提出了一些异常（不管它们是什么），并且没有一个在我的脚本中被发现，可能有一些错误，但我不知道它可能是什么。
**Fatal NI connect error 12170.**

VERSION INFORMATION:
    TNS for Linux: Version 12.1.0.2.0 - Production
    Oracle Bequeath NT Protocol Adapter for Linux: Version 12.1.0.2.0 - Production
    TCP/IP NT Protocol Adapter for Linux: Version 12.1.0.2.0 - Production
Time: 21-AUG-2019 17:28:57
Tracing not turned on.
Tns error struct:
    ns main err code: 12535

TNS-12535: TNS:operation timed out
    ns secondary err code: 12560
    nt main err code: 505

TNS-00505: Operation timed out
    nt secondary err code: 110
    nt OS err code: 0
Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.126.84.228)(PORT=10686))
Wed Aug 21 17:45:36 2019