ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > Oracle > 【BUG】ORA-19706和_external_scn_rejection_threshold_hours的前世今生

【BUG】ORA-19706和_external_scn_rejection_threshold_hours的前世今生

Oracle 作者：xysoul_云龙 时间：2016-10-28 11:16:35 0 删除 编辑

  最近这几天和几个客户一直在讨论一个最近爆发的ORA-19706的故障。在一个数据库访问另外一个数据库的时候出现了：


点击(此处)折叠或打开

  1. SQL>select * from tab@to10g2;
  2. select * from tab@to10g2
  3. *
  4. ERROR
  5. at
  6. line
  7.  1:
  8. ORA-19706: invalid SCN

 Rejected the attempt to advance SCN over limit by 13 hours worth to 0x0bd8.0000133b, by distributed transaction remote logon, remote DB: ORA10G.错误，在ALERT LOG中，也发现了一些报警信息：

通过MOS查到了这是SCN HEEADROOM的问题，我们暂且称之为SCN天花板。MOS的建议是下载并安装最新的PSU，并设置参数_external_scn_rejection_threshold_hours为24.刚开始的时候并没有搞明白这个参数具体的含义。确实设置这个参数后，问题就没有再出现了。不过随着关于这个问题讨论的深入，很多疑问又冒了出来。特别是周末时和美国ORACLE的一个哥们在MSN上聊到此事，那个哥们说是由于客户安装了CPU 2012 JAN安全补丁，才出现很多用户出现了ORA-19706的问题。回退了这个补丁，问题就解决了。而且这个问题在ORACLE内部讳莫如深，他们也不太清楚具体的原因是什么。 

《《《《本贴附件为各个版本的oracle公司提供的scnhealthcheck.sql，实际上各个版本（11g之前）的差异不是很大，部分打了补丁的11g的系统，每秒SCN增长阀值被加大为32K了》》》

今天正好没什么事，和几个DBA又讨论起这个问题，于是我仔细翻阅了一些资料。终于把整个故事都搞明白了。ORACLE的CPU 2012 JAN确实对SCN的算法做出了一系列的改进。这起源于INFOWORLD在2011年底发现的ORACLE的一个安全漏洞。关于这个安全漏洞的故事，可以参考http://www.infoworld.com/d/security/fundamental-oracle-flaw-revealed-184163-0?page=0,0 。这里我简单介绍一下这个故事：

INFOWORLD在一个测试中，发现ORACLE 11.2中存在一个BEGIN BACKUP的BUG,也就是当执行了ALTER DATABASE BEGIN BACKUP后，SCN会增长的超出正常水平，使数据库很快达到SCN的软限制(SCN HEADROOM），一旦达到了这个限制，数据库将无法正常处理事务，甚至严重时导致宕机。更有甚者，当SCN超过HEADROOM的时候，可能会导致数据库出现ORA-600 [2252]而无法启动数据库（当然ORACLE有很多保护机制，很少会出现超出的情况）。这个问题在INFOWORLD发现之前，ORACLE已经有所发现，就是Bug 12371955 - Hot Backup can cause increased SCN growth rate leading to ORA-600 [2252] errors [ID 12371955.8]。目前这个BUG已经解决，并且不会出现在11g之前的版本中。

INFOWORLD在发现这个问题后，在进一步的测试发现更严重的问题，就是DBLINK的SCN同步机制。为了实现分布式处理，ORACLE在多个库做DBLINK访问的时候，会将SCN进行同步，也就是将较高的SCN同步微参与DBLINK的两个库的SCN，执行DBLINK操作后，两个库的SCN就同步了。这个机制就可能把SCN增长异常传播到所有的数据库服务器上。也就是说，如果一个服务级别很低的报表服务器出现故障，可能会影响服务级别特别高的生产服务器。INFOWORLD把这个问题报告给了ORACLE，并一起进行了一系列的工作，于是在CPU 2012 JAN中出现了对这个DBLINK问题的补丁。在介绍这个补丁之前，我们先来了解一段ORACLE SCN的背景资料。

背景：ORACLE SCN的硬限制和软限制：ORACLE的SCN是由48位来表示的，因此最大值不能超过2的48次方，这就是ORACLE scn的硬限制。Oracle为了确保48位的SCN能够用足够长的时间（500年），于是对SCN做出了一个限制，就是每秒钟SCN最大增长不能超过16K，Oracle使用了一个十分简单的算法，就是以从1988年1月1日0点0分0秒为基准时间，到当前的秒钟数乘以16K，就是当前SCN的最大允许值这就是SCN HEADROOM。如果在某个时刻SCN达到了这个最大值，那么事务就无法提交，需要等到下一秒，这个HEAD ROOM又变大了，才能继续进行事务的提交。

关于这些背景资料请参考

NOTE:1376995.1 - Information on the System Change Number (SCN) and how it is used in the Oracle Database

NOTE:1393363.1 - Installing, Executing and Interpreting output from the "SCNhealthcheck.sql" script

NOTE:1388639.1 - Evidence to collect when reporting "high SCN rate" issues to Oracle Support

NOTE:1393360.1 - ORA-19706 and Related Alert Log Messages

对于INFOWORLD发现的问题，ORACLE采取了两个很重要的手段，一个是在11.2中，将SCN 每秒最大的增长量从16K加大为32K，第二个是引入了一个阀值，用于阻断有SCN HEADROOM问题的系统将故障传播到其他系统。这个修复包含在CPU 2012 JAN中，打了这个补丁后，我们可以设置一个参数_external_scn_rejection_threshold_hours。这个参数的含义是，当有一个系统和我进行DBLINK操作的时候，我需要检查他的SCN HEADROOM的值，如果这个系统的SCN HEADROOM的值小于这个参数所设置的小时数，那么我就拒绝这个DBLINK访问（如果DBLINK两端的数据库都打了补丁，设置了参数，这种检查是双向的），通过拒绝DBLINK访问，来避免错误被传播。

由于10G的这个补丁打了后，_external_scn_rejection_threshold_hours的缺省值是31天（31*24），是个十分大的值，因此很多系统打了这个补丁后，就出现ORA-19706错误了。而回退了这个补丁后，这方面的限制取消了，报错就没有了。不过隐患就出现了。

实际上这个问题包含两个方面，一方面是如何防止问题的发生，就是防止核心生产系统出现SCN增长异常的问题出现。目前发现的一系列BUG都已经得到了控制，包括那个INFOWORLD发现的BEGIN BACKUP的问题。还有bug13916709，这个补丁是为了修复另外一个SCN BUG而引发的。当一个长时间运行的SQL和DDL,job或者GATHER操作一起执行的时候，会引起CURSOR INVALIDATE，从而触发SCN异常增长。

另外一个方面是如何在某个系统发生故障的时候，阻止这个故障的传播。CPU 2012 JAN就是用来解决这个问题的，不过这个补丁也摆了一个乌龙，在10g上，新引入的参数的缺省值太大，需要设置为24，以避出现过多的ORA-19706。如果由于目前系统的SCN已经比较高了，设置为24还无法避免ORA-19706,可以尝试进一步减小这个参数。很多客户把这个参数减少为1，这样可以最大限度的减少ORA-19706，不过设置为1，存在一定的隐患，一旦系统遇到了一个人新的SCN增长过快的BUG,那么，可能我们都没有时间来解决这个问题，建议尽可能不要设置这么低。

事实上，ORACLE的这些补丁解决了一部分SCN异常增长的情况，也防止了异常增长的扩散，不过仅仅这些还是没有彻底解决这个问题。如果SCN HEADROOM的问题出现在一个核心系统上，那么哪怕它没有被扩散，那么核心系统业务受到影响也是无法容忍的。因此我们需要做的事情还更多，特别是如何发现SCN的异常增长，这就需要我们经常性的对数据库进行监控，并把SCN HEADROOM检查作为标准的健康检查项，定期进行检查。

Oracle发布了一个补丁：<a style="text-decoration:none;color:#1d58d1;" href="https://support.oracle.com/CSP/ui/flash.html#tab=PatchHomePage(page=PatchHomePage&id=gj46o799()),(page=PatchSearchResultsHome&id=gj46pr1y(search=Patch:13498243，这个补丁实际上包含的就是一个脚本scnhealthcheck.ql，通过这个脚本可以检查目前本系统的SCN HEADROOM(单位为天)，如果SCNHEADROOM大于62，那么说明这个系统没有SCN HEADROOM问题，如果小于62大于10，说明存在问题，不过还不致命。如果小于10，那么就说明问题十分严重，必须立即处理了。实际上这个脚本的核心是以下的SQL:

点击(此处)折叠或打开

  1. select

  3. version,

  5. to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME,

  7. ((((

  9. ((to_number(to_char(sysdate,'YYYY')) - 1988) * 12 * 31 * 24 * 60 * 60) +

  11. ((to_number(to_char(sysdate,'MM')) - 1) * 31 * 24 * 60 * 60) +

  13. (((to_number(to_char(sysdate,'DD')) - 1)) * 24 * 60 * 60) +

  15. (to_number(to_char(sysdate,'HH24')) * 60 * 60) +

  17. (to_number(to_char(sysdate,'MI')) * 60) +

  19. (to_number(to_char(sysdate,'SS')))

  21. ) * (16 * 1024)) - dbms_flashback.get_system_change_number)

  23. / (16 * 1024 * 60 * 60 * 24)

  25. ) indicator

  27. from v$instance

    28. 除了这个脚本外，我们还可以通过以下手段进行检查（以下建议来自于Doc ID 1393383.1）：

    1、 经常性检查"calls to kcmgas"系统调用的情况，并建立基线数据。这个指标可以从V$SYSSTATE去查找，也可以通过AWR查找历史数据（在AWR数据中查找历史统计数据的方法参考How to extract the historical values of a statistic from AWR Repository [ID 948272.1]）。也可以通过下面的脚本检查某个会话的情况：

    点击(此处)折叠或打开

    1. select sess.sid, stat.value, sess.sql_id, vsql.sql_text
    2. from v$sesstat stat, v$session sess, v$sql vsql
    3. where statistic# =
    4. (select statistic#from v$sysstatwhere name ='calls to kcmgas')
    5. and stat.sid = sess.sid
    6. and sess.sql_id = vsql.sql_id
    7. order by stat.value



2、  如果本机的这个调用很少，那么很可能故障是从别的机器传播过来的，如果要查找哪个远程服务器经常连接到某个数据库，可以通过下面的方法：A)对于已经打了补丁的系统，当SCN传播发生时，ALERT LOG中会有记录，可以通过ALERT LOG查找问题的系统。

Advanced SCN by 13238271 minutes worth to 0x0bd6.00000f21, by distributed transaction remote logon, remote DB: ORA10G.

 Client info : DB logon user SCOTT, machine gc, program sqlplus@gc (TNS V1-V3), and OS user oracle

 

3、  除了上面的脚本外，ORACLE官方还在How to handle "high SCN rate" Service Requests (Doc ID 1393383.1中提供了一个脚本，可以查找历史的SCN HEADROOM：


点击(此处)折叠或打开

  1. set numwidth 17
  2. set pages 1000
  3. alter sessionset nls_date_format='DD/Mon/YYYY HH24:MI:SS';
  4. SELECT tim, gscn,
  5.   round(rate),
  6.   round((chk16kscn - gscn)/24/3600/16/1024,1) "Headroom"
  7. FROM
  8. (
  9.  select tim, gscn, rate,
  10.   ((
  11.   ((to_number(to_char(tim,'YYYY'))-1988)*12*31*24*60*60) +
  12.   ((to_number(to_char(tim,'MM'))-1)*31*24*60*60) +
  13.   (((to_number(to_char(tim,'DD'))-1))*24*60*60) +
  14.   (to_number(to_char(tim,'HH24'))*60*60) +
  15.   (to_number(to_char(tim,'MI'))*60) +
  16.   (to_number(to_char(tim,'SS')))
  17.   ) * (16*1024)) chk16kscn
  18.  from
  19.  (
  20.    select FIRST_TIME tim , FIRST_CHANGE# gscn,
  21.           ((NEXT_CHANGE#-FIRST_CHANGE#)/
  22.            ((NEXT_TIME-FIRST_TIME)*24*60*60)) rate
  23.      from v$archived_log
  24.     where (next_time > first_time)
  25.  )
  26. )
  27. order by 1,2;
  28.   
  29.   
  30.   
  31. Rem
  32. Rem $Header: rdbms/admin/scnhealthcheck.sql st_server_tbhukya_bug-13498243/8 2012/01/17 03:37:18 tbhukya Exp $
  33. Rem
  34. Rem scnhealthcheck.sql
  35. Rem
  36. Rem Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved.
  37. Rem
  38. Rem NAME
  39. Rem scnhealthcheck.sql - Scn Health check
  40. Rem
  41. Rem DESCRIPTION
  42. Rem Checks scn health of a DB
  43. Rem
  44. Rem NOTES
  45. Rem .
  46. Rem
  47. Rem MODIFIED (MM/DD/YY)
  48. Rem tbhukya 01/11/12 - Created
  49. Rem
  50. Rem
  51. define LOWTHRESHOLD=10
  52. define MIDTHRESHOLD=62
  53. define VERBOSE=TRUE
  54. set verioff;
  55. set feedbackoff;
  56. set serverouton
  57. DECLARE
  58.  verbose boolean:=&&VERBOSE;
  59. BEGIN
  60.  For Cin (
  61.   select
  62.    version,
  63.    date_time,
  64.    dbms_flashback.get_system_change_number current_scn,
  65.    indicator
  66.   from
  67.   (
  68.    select
  69.    version,
  70.    to_char(SYSDATE,'YYYY/MM/DD HH24:MI:SS') DATE_TIME,
  71.    ((((
  72.     ((to_number(to_char(sysdate,'YYYY'))-1988)*12*31*24*60*60) +
  73.     ((to_number(to_char(sysdate,'MM'))-1)*31*24*60*60) +
  74.     (((to_number(to_char(sysdate,'DD'))-1))*24*60*60) +
  75.     (to_number(to_char(sysdate,'HH24'))*60*60) +
  76.     (to_number(to_char(sysdate,'MI'))*60) +
  77.     (to_number(to_char(sysdate,'SS')))
  78.     ) * (16*1024)) - dbms_flashback.get_system_change_number)
  79.    / (16*1024*60*60*24)
  80.    ) indicator
  81.    from v$instance
  82.   )
  83.  ) LOOP
  84.   dbms_output.put_line('-----------------------------------------------------'
  85.                         ||'---------' );
  86.   dbms_output.put_line('ScnHealthCheck' );
  87.   dbms_output.put_line('-----------------------------------------------------'
  88.                         ||'---------' );
  89.   dbms_output.put_line('Current Date: '||C.date_time );
  90.   dbms_output.put_line('Current SCN: '||C.current_scn );
  91.   if (verbose) then
  92.     dbms_output.put_line('SCN Headroom: '||round(C.indicator,2) );
  93.   end if;
  94.   dbms_output.put_line('Version: '||C.version );
  95.   dbms_output.put_line('-----------------------------------------------------'
  96.                         ||'---------' );
  97.   IF C.version > '10.2.0.5.0' and
  98.      C.versionNOT LIKE '9.2%' THEN
  99.     IF C.indicator>&MIDTHRESHOLD THEN
  100.       dbms_output.put_line('Result: A - SCN Headroom is good');
  101.       dbms_output.put_line('Apply the latest recommended patches');
  102.       dbms_output.put_line('based on your maintenance schedule');
  103.       IF (C.version < '11.2.0.2')THEN
  104.         dbms_output.put_line('AND set _external_scn_rejection_threshold_hours='
  105.                              ||'24 after apply.');
  106.       END IF;
  107.     ELSIF C.indicator<=&LOWTHRESHOLD THEN
  108.       dbms_output.put_line('Result: C - SCN Headroom is low');
  109.       dbms_output.put_line('If you have not already done so apply' );
  110.       dbms_output.put_line('the latest recommended patches right now' );
  111.       IF (C.version < '11.2.0.2')THEN
  112.         dbms_output.put_line('set _external_scn_rejection_threshold_hours=24 '
  113.                              ||'after apply');
  114.       END IF;
  115.       dbms_output.put_line('AND contact Oracle support immediately.' );
  116.     ELSE
  117.       dbms_output.put_line('Result: B - SCN Headroom is low');
  118.       dbms_output.put_line('If you have not already done so apply' );
  119.       dbms_output.put_line('the latest recommended patches right now');
  120.       IF (C.version < '11.2.0.2')THEN
  121.         dbms_output.put_line('AND set _external_scn_rejection_threshold_hours='
  122.                              ||'24 after apply.');
  123.       END IF;
  124.     END IF;
  125.   ELSE
  126.     IF C.indicator<=&MIDTHRESHOLD THEN
  127.       dbms_output.put_line('Result: C - SCN Headroom is low');
  128.       dbms_output.put_line('If you have not already done so apply' );
  129.       dbms_output.put_line('the latest recommended patches right now' );
  130.       IF (C.version >= '10.1.0.5.0' and
  131.           C.version <= '10.2.0.5.0' and
  132.           C.versionNOT LIKE '9.2%')THEN
  133.         dbms_output.put_line(', set _external_scn_rejection_threshold_hours=24'
  134.                              ||' after apply');
  135.       END IF;
  136.       dbms_output.put_line('AND contact Oracle support immediately.' );
  137.     ELSE
  138.       dbms_output.put_line('Result: A - SCN Headroom is good');
  139.       dbms_output.put_line('Apply the latest recommended patches');
  140.       dbms_output.put_line('based on your maintenance schedule ');
  141.       IF (C.version >= '10.1.0.5.0' and
  142.           C.version <= '10.2.0.5.0' and
  143.           C.versionNOT LIKE '9.2%')THEN
  144.        dbms_output.put_line('AND set _external_scn_rejection_threshold_hours=24'
  145.                              ||' after apply.');
  146.       END IF;
  147.     END IF;
  148.   END IF;
  149.   dbms_output.put_line(
  150.     'For further information review MOS document id 1393363.1');
  151.   dbms_output.put_line('-----------------------------------------------------'
  152.                         ||'---------' );
  153.  END LOOP;
  154. end;
  155. /


解决方式：

Oracle官方关于这个问题的解决方案中，还有两条，一是在今后的版本中将SCN扩展到64位，第二是今后的版本中可能进一步加大SCN HEADROOM为更大的值，因为目前已经出现了每秒超过16K个事务的系统. 
如果你的系统已经出现了问题，发现某台核心系统的SCN被传染了，想要找出是哪些系统和本机有DBLINK连接，可以通过两个方法，一是通过系统的LOGON触发器，记录LOGON的情况，二是通过LOGON审计，将LOGON审计数据写入DB，只要设置"AUDIT CREATE SESSION"审计，就可以通过下面的SQL查询到相关信息： 
select distinct "COMMENT$TEXT",userhost from aud$ where "COMMENT$TEXT" like '%DBLINK%';  

以下内容摘自Oracle公司给客户下发的SCN问题紧急处置方案中的内容

在《关于Oracle DB SCN 生成率过高的预警及处理建议》的文章中，我们已经提出SCN生产率过高的原因。作为oracle db的一种重要预警，我们建议对此作重点关注。在此，我们提出以下几点处理建议：

1.  在全系统内做SCN生成率的普查，看看各系统的SCN生成情况是否牵涉生成率过高的现象；

2.  发现SCN生成率过高的相关数据库，根据本指南及时进行修正处理；

3.  形成日常检查机制，每半月或者每月运行scnhealthcheck.sql，例行检查SCN的生成率情况；

4.根据相关数据库的dblink使用情况，形成dblink跟踪列表，便于日后检查SCN状态。列表内容包括源数据库名称、目标数据库名称、dblink名称、dblink用途，甚至包括关联对象等信息

方案一：安装PSU/CPU补丁修复方案

本方案主要针对以下数据库版本：

Oracle 10.2.0.5

Oracle 11.1.0.7

Oracle 11.2.0.2

Oracle 11.2.0.3

针对上述版本的数据库，oracle建议给数据库安装2012年4月发布的PSU，并在安装该PSU的基础上，安装补丁13916709。如果是集群架构，同时给集群软件最新安装PSU。《《《白鳝注：也可以直接安装2012年7月的PSU，这个PSU已经包含了13916709补丁的修复，如果觉得暂时无法升级PSU，那么也可以单独打13916709的独立补丁，这个补丁的目的是解决SCN异常增长的BUG》》》》》

?  10.2.0.5  数据库

对于版本为10.2.0.5的数据库， 建议安装2012年4月发布的PSU 13632743，并在安装PSU 13632743的基础上，安装补丁13916709。参数_external_scn_rejection_threshold_hours在2012年4月（包含2012年4月）以后发布的PSU/CPU中已经定义默认值为24，所以安装最新PSU补丁以后，不需要再设该参数。如果是集群架构，同时给集群软件安装PSU 9952245。

?  11.1.0.7  数据库

对于版本为11.1.0.7的数据库，建议安装2012年4月发布的PSU 13621679，并在安装PSU 13621679的基础上，安装补丁13916709。参数_external_SCN_rejection_threshold_hours在2012年4月（包含2012年4月）以后发布的PSU/CPU中已经定义默认值为24，所以安装最新PSU补丁以后，不需要再设该参??。如果是集群架构，同时给集群软件安装PSU 11724953。

?  11.2.0.2  数据库

对于版本为11.2.0.2的数据库，建议安装2012年4月发布的PSU 13696224，并在安装PSU 13696224的基础上，安装补丁13916709。如果是集群架构，同时给集群软件安装PSU 13696242。

?  11.2.0.3  数据库

对于版本为11.2.0.3的数据库，建议安装2012年4月发布的PSU 13696216，并在安装PSU 3696216的基础上，安装补丁13916709。如果是集群架构，同时给集群软件安装PSU 13696251。

 

《《白鳝注：10.2.0.4目前在PSU中也已经包含了13916709的修复。对于目前无补丁发布的版本，Oracle 10.2.0.1、Oracle 10.2.0.2、Oracle 10.2.0.3》》》

10.2.0.4版本解决方案

本方案针对数据库版本是Oracle 10.2.0.4。oracle为此提供两种修正方式：

?  方式一：紧急修复方案

采用前提：数据库SCN问题急需解决，但升级数据库版本从管理、业务应用、时间上都不适合。

方式建议程度：中

处理方式：保持数据库版本不变，安装2012年4月发布的PSU 12879933。在安装12879933之前，必须先安装9352164，这是安装10.2.0.4.4之后PSU的前提条件。如果是集群架构，同时给集群软件安装PSU 9294403。参数_external_SCN_rejection_threshold_hours在2012年4月（包含2012年4月）以后发布的PSU/CPU中已经定义默认值为24，所以安装???新PSU补丁以后，不需要再设该参数。

?  方式二：补丁集升级修复方案

采用前提：数据库SCN问题急需解决，安装最近补丁集，从管理、应用、时间上都比较适合，但数据库版本升级计划不能在短期内完成。

方式建议程度：中

 

处理方式：将数据库升级到10.2.0.5的版本，安装2012年4月发布的PSU 13632743，并在安装PSU 13632743的基础上，安装补丁13916709。如果是集群架构，同时给集群软件安装PSU 9952245。

《《白鳝注：对于其他未涉及版本，ORACLE为发出补丁包，ORACLE建议升级到上述已发补丁包的版本：

Oracle 9.2.0.1～9.2.0.8

Oracle 10.1.0.3～10.1.0.5

Oracle 11.1.0.6

Oracle 11.2.0.1

》》》

Oracle 11.2引入了一个新的隐含参数来控制每秒的SCN HEADROOM，11G的缺省值是32K 
Parameter                                Session Value 
---------------------------------------- ---------------------------------------- 
_max_reasonable_scn_rate                 32768

在网上看到一个查SCN增长速度的脚本，挺有用的


点击(此处)折叠或打开

  1. with t1as(
  2. select time_dp , 24*60*60*(time_dp - lag(time_dp) over (order by time_dp)) timediff,
  3.   scn - lag(scn) over(order by time_dp) scndiff
  4. from smon_scn_time
  5. )
  6. select time_dp , timediff, scndiff,
  7.        trunc(scndiff/timediff) rate_per_sec
  8. from t1
  9. order by 1
  10. /
  11. alter sessionset nls_date_format='DD-MON-YYYY HH24:MI:SS';
  12. col first_change# format 99999999999999999999
  13. col next_change# format 99999999999999999999
  14. select thread#, first_time, next_time, first_change# ,next_change#, sequence#,
  15.    next_change#-first_change# diff, round ((next_change#-first_change#)/(next_time-first_time)/24/60/60) rt
  16. from (
  17. select thread#, first_time, first_change#,next_time, next_change#, sequence#,dest_idfrom v$archived_log
  18. where next_time > sysdate-30 and dest_id=1
  19. order by next_time
  20. )
  21. order by first_time, thread#
  22. /

来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29487349/viewspace-2127269/ ，如需转载，请注明出处，否则将追究法律责任。

0
0
上一篇： 【RAC】由系统环境变量中"/"引起的空闲实例
下一篇： 【RAC】Oracle11g RAC 你不懂crs_*
请登录后发表评论 登录
全部评论
xysoul_云龙
专家姓名：杨云龙
主要从事Oracle数据库 DBA相关工作，其他操作系统、中间件等也有涉及，热衷分享。岁月老将至，如有幸在江湖中留点踪迹，也是欣慰。 【文盲筱烨】好读书爱运动的IT技术爱好者 微博：文盲筱烨 微信公众号：筱烨视点

注册时间：2014-02-15

  • 博文量
    412
  • 访问量
    1104535

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593