SCN固有成長率の調査

Written by on in Articles

公開日:10July2018著者:Bastiaan Bakカテゴリ:IT開発と運用

少し前に、Oracle12.2データベースのアラートファイルにSCN(システム変更番号)の固有成長率に関する警告がありました。 この状況は数週間以内に数回発生しました。

“警告：SCN固有の成長率は、過去60分間、システムのデフォルト16384/秒よりも一貫して
高くなっています。
現在のSCN固有成長率は25867/秒です。、zas200fffff！
現在のSCN値は46747726691、SCN互換値は1″

私の最初の反応は、Scnがコミットに関連しているため、データベースの負荷が非常に高いか、アプリケーションロジックを変更 別の可能性は、バッチコミットを使用するのではなく、更新のたびにコミットが行われたことでした。

思っていたよりも少し複雑になってしまった。 Scnとコミットの関係を見つけたいときはどこを見ますか？ そして、この警告はとにかくどのように深刻ですか？ このブログでは、私がこの問題を調査し、潜在的な影響を特定したさまざまな方法について説明します。警告ファイル内の警告に関する情報を最初に検索する場所は、Oracleサポートのwebサイトです。 私はいくつかの関連するメモを見つけました:

  • ORA-19706および関連するアラート・ログ・メッセージ(Doc ID1393360.1)
    このメモは、実際のメッセージがデータベース・バージョン12.2に固有であることを示唆していますが、古いバージ”
    これらのエントリのいずれかのようなアラートログ-メッセージが発生した場合は、ID1388639.1の指示に従って、Oracleサポートにサービス-リクエストをログに記録する
    「高SCN率」の問題をOracle Supportに報告するときに収集する証拠(Doc ID1388639.1)
  • このメモでは、サービス・リクエストのログ記録時に提供する情報について説明します。
  • システム変更番号(SCN)、ヘッドルーム、セキュリティおよびパッチ情報(Doc ID1376995.1)
    このメモでは、SCNの使用方法に関する詳細を説明します。 システム変更番号(SCN)は、Oracle Databaseによって使用される論理的な内部タイムスタンプです。 Scnは、データベース内で発生するイベントを順序付けします。 データベースでは、Scnを使用して変更を照会および追跡します。 トランザクションがコミットされると、データベースはこのコミットのSCNを記録します。Oracle Databaseで使用できるScnの数には上限があります。 制限は現在、281兆（2^48）のSCN値です。
    上限があることを考えると、特定のOracleデータベースが使用可能なScnを使い果たさないことが重要です。
    警告が発生したときも説明しています。 Oracle Databaseでは、1988年以降の秒数に16384を掛けた値に基づいて、データベースが現在使用できるScnの数の「超過しない」制限が計算されます。 これにより、Oracleデータベースでは時間の経過とともにScnが確実に配分されます。

この警告はどれくらい深刻ですか？

この警告は、過去60分間、2^14=16384Scn/秒のレートで発生します。
最大SCNは2^48=281.474.976.710.656です。

毎秒16348Scnの割合で、その最大値に達するまでに2^（48-14）秒、つまり544年かかります。 これは通常の状況では十分なはずですが、2^48の上限はデータベースが保存できる最大絶対値にすぎません。
この制限は、1988年以降の秒数にも関連している。 2^48の上限は、2532年（1988+544）の最大値です。 しかし、2018年には最大値は(2018-1988)*365*24*60*60*2^14 = 1.550.057.472.000.

警告は無視すべきではありません。 制限に達すると、ora-600エラーが発生しますが、絶対上限SCNに達すると、データベースは機能しなくなります。

良いニュースは、私たちの状況では、SCNの成長率はその特定の時間に毎秒25867であると警告していたので、その時間に私たちは限界に少し近づいた（25867-16384=9483）。 通常の成長率は16384よりも低いです。

Oracle Support

Oracle Supportに電話したところ、Oracle Developmentが現在この問題に取り組んでいると言われました。
Oracleサポートは、SCNヘッドルームが良好に見えることを確認しました。 AWRレポートに基づいて、Oracleサポートはコミット数が多いことに気付き、トランザクション-サイズを増やしてコミットするようにアプリケーシ

AWR

による調査アラートファイルの警告は、SCN固有の成長率がシステムのデフォルトよりも一貫して高くなっていることを示しました：最後の60分間、毎秒16384。 1時間の時間枠を見ている場合は、AWRレポートを開始するのに適した場所になる可能性があります。 時間ごとにスナップショットを作成するようにAWRが設定されています。AWRレポートでは、ユーザーのコミット数が毎秒210であることに気付きました。 はい、それは多くのコミットですが、このデータベースの通常の負荷とそれほど違いはありません。 また、コミットがSCNに関連している場合、1秒あたり16384よりもはるかに低くなります。

AWRレポートにはADDMの検出も含まれていました。COMMITおよびROLLBACK操作の実行中にイベント”log file sync”で待機すると、データベース時間が大幅に消費されました。 トランザクションのサイズを大きくすることで、コミット操作の数を減らすことができるように、アプリケーションロジックを調査します。
ADDMの検出でのコミットのこの削減は、Oracleサポートによっても提案されました。 私の視点からは、それは本当にそれほど高くはありませんでした。

より短い時間枠

AWRが原因を見つけるのを助けてくれなかったので、より短い時間枠を調査する必要がありました。 私はASHレポートを作成できるように、より具体的な時間枠を知りたいと思っていました。 ASHのデフォルトは15分です。
したがって、次の課題は、SCNの成長率が最も高い15分の時間枠を見つけることだった。
Doc ID1388639.1は、v$archived_logを照会することを提案しました。 このビューには、タイムスタンプやSCNなど、データベース上のすべてのログスイッチに関する情報が含まれています。 タイムスタンプをScnにマップすることはできますが、AWRレポートよりも優れているわけではありません。 この場合、logswitchのタイムスタンプです。

timestamp_to_scn関数の使用

より良い方法は、関数timestamp_to_scnを使用することです。 この関数は、現在のタイムスタンプと同様に、タイムスタンプに基づいてSCNを返します:

     
  1. SQL>dualからTIMESTAMP_to_scn(sysdate)を選択します。 ;
    2.  
  2.  
    3.  
  3. TIMESTAMP_TO_SCN(SYSDATE) 
    4.  
  4. -------------------------
    5.  
  5.  91903104563 
    6.  
  6.  
    7.  
  7. SQL> 
    8.

次のステップは、1988年以降の秒数に16,384を掛けた値に基づいて、一致するSCNと一致するSCNの上限とともにタイムスタンプのリストを作成することでした。

最後の日のタイムスタンプとScnが表示されます:

     
  1.  sysdate-(rownum/24)datetimestampを選択します
    2.  
  2.  , timestamp_to_scn(sysdate-(rownum/24))SCN
    3.  
  3.  , ((sysdate-(rownum/24))-to_date('01-01-1988','DD-MM-YYYY')-to_date('01-01-1988','DD-MM-YYYY')' )) 
    4.  
  4.  * 24 * 60 * 60 * 16384 upper_lmt
    5.  
  5.  デュアルから
    6.  
  6.  rownumによる接続<= 24 
    7.  
  7. /
    8.  
     
  1. タイムスタンプSCN UPPER_LMT
    2.  
  2.  ------------------- -------------------- -------------------- 
    3.  
  3. 09-07-2018-13:23:39 95423916508 15780233527296 
    4.  
  4. 09-07-2018-12:23:39 95380086165 15780174544896 
    5.  
  5. 09-07-2018-11:23:39 95338871931 15780115562496 
    6.  
  6. 09-07-2018-10:23:39 95303437600 15780056580096 
    7.  
  7. 09-07-2018-09:23:39 95265573942 15779997597696 
    8.  
  8. 09-07-2018-08:23:39 95226645452 15779938615296 
    9.  
  9. 09-07-2018-07:23:39 95186822906 15779879632896 
    10.  
  10. 09-07-2018-06:23:39 95147382509 15779820650496 
    11.  
  11. 09-07-2018-05:23:39 95115474008 15779761668096 
    12.  
  12. 09-07-2018-04:23:39 95079712219 15779702685696 
    13.  
  13. 09-07-2018-03:23:39 95041469231 15779643703296 
    14.  
  14. 09-07-2018-02:23:39 95006499794 15779584720896 
    15.  
  15. 09-07-2018-01:23:39 94975060529 15779525738496 
    16.  
  16. 09-07-2018-00:23:39 94945771055 15779466756096 
    17.  
  17. 08-07-2018-23:23:39 94907451372 15779407773696 
    18.  
  18. 08-07-2018-22:23:39 94875158341 15779348791296 
    19.  
  19. 08-07-2018-21:23:39 94838756696 15779289808896 
    20.  
  20. 08-07-2018-20:23:39 94800190958 15779230826496 
    21.  
  21. 08-07-2018-19:23:39 94757984611 15779171844096 
    22.  
  22. 08-07-2018-18:23:39 94724548846 15779112861696 
    23.  
  23. 08-07-2018-17:23:39 94685506947 15779053879296 
    24.  
  24. 08-07-2018-16:23:39 94646644945 15778994896896 
    25.  
  25. 08-07-2018-15:23:39 94605003069 15778935914496 
    26.  
  26. 08-07-2018-14:23:39 94572205685 15778876932096 
    27.  
  27.  
    28.  
  28.  24 行が選択されています。 
    29.

現在のSCNは、現在の上限の約0,57％です。このアイデアに基づいて、過去3日間でScnの成長率が最も高い15分の時間枠を提供するクエリを作成しました。

毎分新しい時間枠が始まり、1日に1440分あるため、調査する時間枠は4320個あります。 それらのそれぞれについて、その15分の時間枠内でSCNの成長を計算する必要があります。

上位の結果のみを表示したいのですが、この場合は毎秒14000を超える速度の時間枠のみを表示します。

     
  1.  ALTER SESSION SET nls_date_format='MM/DD/YY HH24:MI' ;
    2.  
  2.  
    3.  
  3.  datelistを使用して
    4.  
  4.  ( select sysdate-(rownum/1440)-(15/1440)starttime--15分間隔
    5.  
  5.  , sysdate-(rownum/1440)endtime
    6.  
  6.  デュアルから
    7.  
  7.  rownumによる接続<= (3*1440) -- 3 daysの歴史
    8.  
  8. )
    9.  
  9.  スタートタイムを選択
    10.  
  10.  , 終了時間
    11.  
  11.  , timestamp_to_scn(endtime)-timestamp_to_scn(starttime)scngrowth
    12.  
  12.  , round((timestamp_to_scn(endtime)-timestamp_to_scn(starttime)) / 
    13.  
  13.  (((24*60*60)*(endtime-starttime))))scnrate
    14.  
  14.  datelistから
    15.  
  15.  ここで、round((timestamp_to_scn(endtime)-timestamp_to_scn(starttime)) / 
    16.  
  16.  (((24*60*60)*(endtime-starttime)))) >= 14000 
    17.  
  17.  4DESCによる順序
    18.  
  18. /
    19.  

     
  1. STARTTIME ENDTIME SCNGROWTH SCNRATE
    2.  
  2. -------------- -------------- -------------------- --------------------
    3.  
  3. 07/06/18 18:09 07/06/18 18:24 12761928 14180 
    4.  
  4. 07/07/18 05:20 07/07/18 05:35 12742537 14158 
    5.  
  5. 07/09/18 13:59 07/09/18 14:14 12705077 14117 
    6.  
  6. 07/09/18 12:57 07/09/18 13:12 12672507 14081 
    7.  
  7. 07/09/18 07:06 07/09/18 07:21 12654287 14060 
    8.

そのため、最後の3日間のSCN率（1秒あたりのSCN成長）が最も高い15分の時間枠（重複することもあります）が見つかりました。 そして、それらの時間枠でさえ、SCN率はまだ16384の下にあります。 今週の警告ファイルに警告はありません….

ASHレポートの実行

上記のクエリで使用した日付形式は、ASHレポートで使用されているものと同じであるため、開始時刻をコピー/貼り付けるだけです。 期間中は15分を入力します。

     
  1. SQL>@@OR ORACLE_HOME/rdbms/admin/ashrpt.sql
    2.  
  2.  
    3.  
  3. このワークロードリポジトリスキーマのASHサンプル
    4.  
  4. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    5.  
  5.  
    6.  
  6. 利用できる最も古い灰のサンプル:01-Jul-18 00:00:01 
    7.  
  7. 利用できる最も最近の灰のサンプル:09-Jul-18 14:18:58 
    8.  
  8.  
    9.  
  9.  
    10.  
  10. ASHレポートを生成する時間枠を指定します
    11.  
  11. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    12.  
  12. レポートの開始時刻を入力します:
    13.  
  13.  
    14.  
  14. -- 有効な入力形式:
    15.  
  15. -- 絶対開始時刻を指定するには:
    16.  
  16. -- ] HH24：ミ
    17.  
  17. -- 例: 02/23/03 14:30:15
    18.  
  18. -- 02/23 14:30:15
    19.  
  19. -- 14:30:15
    20.  
  20. -- 14:30
    21.  
  21. -- 相対的な開始時間を指定するには:('-'記号で始まります)
    22.  
  22. -- -みぃ
    23.  
  23. -- 例：-1:15（1時間15分）)
    24.  
  24. -- -25 (シスデート-25分)
    25.  
  25.  
    26.  
  26. デフォルトは-15分です
    27.  
  27. begin_timeの値を入力します: 07/06/18 18:09
    28.  
  28. レポート開始時間指定: 07/06/18 18:09
    29.  
  29.  
    30.  
  30. 開始時間から開始時間までの時間を分単位で入力します:
    31.  
  31. デフォルトはSYSDATE-begin_timeです
    32.  
  32. Enterキーを押して、現在の時刻まで分析します
    33.  
  33. 期間の値を入力します: 15 
    34.  
  34. 指定されたレポート期間: 15 
    35.  
  35.  
    36.  
  36.  レポート開始時刻として06-Jul-18 18:09:00を使用する
    37.  
  37.  レポートの終了時刻として06-Jul-18 18:24:00を使用する
    38.  
  38.  
    39.  
  39. レポート名の指定
    40.  
  40. ~~~~~~~~~~~~~~~~~~~~~~~
    41.  
  41. 既定のレポートファイル名はashrpt_1_0706_1824です。html。 この名前を使用するには, 
    42.  
  42. 続行するには<return>を押します。 
    43.  
  43. report_nameの値を入力します:
    44.  
  44.  
    45.  
  45.  レポート名ashrpt_1_0706_1824を使用します。html
    46.  
  46.  
    47.  
  47. すべてのユーザー入力の概要
    48.  
  48. -------------------------
    49.  
  49. 形式:HTML
    50.  
  50. DB Id: 2019395491 
    51.  
  51. インスト-ヌム: 1 
    52.  
  52.  開始時間:06-Jul-18 18:09:00
    53.  
  53.  終了時間:06-Jul-18 18:24:00
    54.  
  54. スロット幅:デフォルト
    55.  
  55. レポート対象: 0 
    56.  
  56. レポート名 : ashrpt_1_0706_1824.html
    57.

AWRでのSCNの検出

AWRレポートには現在のSCNに関する情報はあまり表示されていませんでしたが、どこで見つけるか知っていれば、成長率に関する情報が

“インスタンスアクティビティ統計”の下には、”kcmgasへの呼び出し”の数を見つけることができます。 Oracleのドキュメントでは、これは”新しいSCNを取得するためのルーチンkcmgasへの呼び出しの数”として説明されています。AWRレポートの1秒あたりのこれらのコールの値は、timestamp_to_scn関数で計算されたSCNレートに非常に近い値です。V SES SESSTATビュー v$SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー v.SESSTATビュー

V SES SESSTATを使用して、高いSCN率を引き起こすセッションを見つけることができます。 また、特定のアクションのSCN数への影響をテストすることもできます。たとえば、他のセッションでも使用されている大きなテーブルでselectを実行すると、セッションはkcmgasに対してさらに7回の呼び出しを行います。 したがって、私のクエリはより高いSCNを引き起こします。 これは、SCNも使用するデータベースの読み取り一貫性が原因です。

     
  1. SQL>接続<ユーザー>/<パス>@<サービス> 
    2.  
  2. 接続されています。 
    3.  
  3. SQL>sesを選択します。値
    4.  
  4.  v$sesstat sesから
    5.  
  5.  , v$statname stat
    6.  
  6.  どこstat。統計#=ses.統計#
    7.  
  7.  そしてses。sid IN(v$mystatからsidを選択します) 
    8.  
  8.  そしてstat。name='kcmgasへの呼び出し' 
    9.  
  9. /
    10.  
  10.  
    11.  
  11.  値
    12.  
  12. --------------------
    13.  
  13.  2 
    14.  
  14.  
    15.  
  15. SQL>mybigtableからCOUNT(*)を選択します;
    16.  
  16.  
    17.  
  17.  カウント(*) 
    18.  
  18. --------------------
    19.  
  19.  12198814 
    20.  
  20.  
    21.  
  21. SQL>sesを選択します。値
    22.  
  22.  v$sesstat sesから
    23.  
  23.  , v$statname stat
    24.  
  24.  どこstat。統計#=ses.統計#
    25.  
  25.  そしてses。sid IN(v$mystatからsidを選択します) 
    26.  
  26.  そしてstat。name='kcmgasへの呼び出し' 
    27.  
  27. /
    28.  
  28.  
    29.  
  29.  値
    30.  
  30. --------------------
    31.  
  31.  9 
    32.  
  32.  
    33.  
  33. SQL> 
    34.

SCNとcommit rate

をV$SESSTATと比較すると、現在データベースに接続されているすべてのセッションの統計情報を照会できます。 このようにして、高いSCN率を担当するセッションを見つけることができます。 これをそのセッションのコミット率と比較することができます。

以下のクエリの結果は、私たちのデータベース上で高いSCN率は主にバックグラウンドプロセスによって引き起こされたことを示しました。 ほとんどのユーザーセッションでは、高いSCNレートと高いコミットレートの間に関係があります。

     
  1.  sesを選択します。シド
    2.  
  2.  , デコード(ses.ユーザー名、NULL、'background'、'user')session_type
    3.  
  3.  , (sysdate-logon_time)* 24 * 60 * 60 connect_seconds
    4.  
  4.  , sstat1.値SCN#
    5.  
  5.  , sstat2.値コミット#
    6.  
  6.  , ラウンド(sstat1.値/((sysdate-logon_time) * 24 * 60 * 60),2) scn_rate
    7.  
  7.  , ラウンド(sstat2.値/((sysdate-logon_time) * 24 * 60 * 60),2) commit_rate
    8.  
  8.  v$sesstat sstat1から
    9.  
  9.  , v$sesstat sstat2
    10.  
  10.  , v$statname sn1
    11.  
  11.  , v$statname sn2
    12.  
  12.  , v$セッションses
    13.  
  13.  ここで、sstat1。統計#=sn1.統計#
    14.  
  14.  およびsstat2。統計#=sn2.統計#
    15.  
  15.  およびsn1。name='kcmgasへの呼び出し' 
    16.  
  16.  とsn2.name ='ユーザーコミット' 
    17.  
  17.  そしてses。sid=sstat1.シド
    18.  
  18.  そしてses。sid=sstat2.シド
    19.  
  19.  ご注文は6日前までにお願いします。
    20.  
  20. /
    21.  
  21.  
    22.  
  22.  SID SESSION_TY CONNECT_SECONDS SCN#COMMIT#SCN_RATE COMMIT_RATE
    23.  
  23. ---------- ---------- --------------- ---------- ---------- ---------- -----------
    24.  
  24.  8478 459572 214506344 0 466.75 0 
    25.  
  25.  7551 背景452395 209729934 0 463.6 0 
    26.  
  26.  3776 背景290389 133863489 0 460.98 0 
    27.  
  27.  8496 背景121201 55685740 0 459.45 0 
    28.  
  28.  8729 背景286773 128180386 0 446.98 0 
    29.  
  29.  12009 背景290392 128867329 0 443.77 0 
    30.  
  30.  13173 背景196775 87268032 0 443.49 0 
    31.  
  31.  12004 背景103166 45681480 0 442.8 0 
    32.  
  32.  8735 背景275980 121563094 0 440.48 0 
    33.  
  33.  3096 背景430810 185436599 0 430.44 0 
    34.  
  34.  8027 背景95990 40912187 0 426.21 0 
    35.  
  35.  7529 背景193218 81367643 0 421.12 0 
    36.  
  36.  2370 背景527978 219521415 0 415.78 0 
    37.  
  37.  14604 背景283216 117052382 0 413.3 0 
    38.  
  38.  14132 背景113965 46586388 0 408.78 0 
    39.  
  39.  7552 背景294009 119775077 0 407.39 0 
    40.  
  40.  13172 182423 73865595 0 404.91 0 
    41.  
  41.  14592 背景74414 29767705 0 400.03 0 
    42.  
  42.  3802 背景268804 107486102 0 399.87 0 
    43.  
  43.  9910 背景117582 46596720 0 396.29 0 
    44.  
  44.  12021 背景49182 19321676 0 392.86 0 
    45.  
  45.  974 背景160816 59996495 0 373.08 0 
    46.  
  46.  12723 背景74450 25455559 0 341.91 0 
    47.  
  47.  3310 背景193215 65915175 0 341.15 0 
    48.  
  48.  12963 49179 15687084 0 318.98 0 
    49.  
  49.  6111 背景3584090 1031139557 0 287.7 0 
    50.  
  50.  6829 ユーザー303 1267 1123 4.18 3.71 
    51.  
  51.  9665 ユーザー904 1845 1691 2.04 1.87 
    52.  
  52.  8022 ユーザー898 1677 1520 1.87 1.69 
    53.  
  53.  3323 ユーザー898 1406 1260 1.57 1.4 
    54.  
  54.  2839 ユーザー7503 10822 9813 1.44 1.31 
    55.  
  55.  11060 ユーザー3892 5334 4781 1.37 1.23 
    56.  
  56.  13184 ユーザー1765 2359 2038 1.34 1.15 
    57.  
  57.  9199 ユーザー898 1135 935 1.26 1.04 
    58.  
  58.  2130 ユーザー8105 9548 8518 1.18 1.05 
    59.  
  59.  11525 ユーザー898 1054 944 1.17 1.05 
    60.  
  60.  6130 ユーザー3895 4453 4199 1.14 1.08 
    61.  
  61.  8012 ユーザー7503 8576 7774 1.14 1.04 
    62.  
  62.  4497 ユーザー898 962 882 1.07.98
    63.  
  63.  5201 ユーザー7220 7551 6226 1.05.86
    64.  
  64.  11317 ユーザー12906 13371 11997 1.04.93
    65.  
  65.  
    66.  
  66.  
    67.  
  67.  1979 行が選択されています。 
    68.

結論

SCNには制限があるため、アラートファイルで警告が見つかった場合は、問題を調査する必要があります。 問題が見つかった場合は、Oracle Supportで作業する必要があります。 情報をアップロードすることで、現在のSCNと最大SCNの間に十分なスペースがあるかどうかを確認できます。

問題は、12371955のようなバグが原因で発生する可能性があります：ホットバックアップは、SCNの成長率が増加し、ORA-600エラー（Doc ID12371955.8）につながる可能性があります。

Scnの高成長がある正確な瞬間を見つけたい場合は、タイムスタンプをScnに変換する必要があります。 関数SCN_TO_TIMESTAMPおよびTIMESTAMP_TO_SCNを使用して、最良の結果を得ることができます。

高いコミット率は常にユーザープロセスに関連していますが、Scnはバックグラウンドプロセスにも関連しています。 コミットしないセッションでも、SCNに影響を与える可能性があります。

bastiaan Bak

著者についてBastiaan Bak

DBAは15年以上の経験を持っています。 複数のモジュールが付いているさまざまな枝の経験。 を含む: Oracleデータベース、Oracle RAC、Oracle EBS、およびPL/SQL。

コメントを残す

メールアドレスが公開されることはありません。