Database Support Blog

shutdownを正常に終わらせる方法について

Oracle Databaseのシャットダウンは処理が終了するまで待機するため、意図しない処理が実行されていたりセッションが残留しているために、完了せずにタイムアウトしてしまうことがあります。

静的パラメータの設定変更やメモリの解放など、シャットダウンを行う機会は必ずありますので、その際にシャットダウンがタイムアウトしてしまうといった障害を防ぐために、事前に確認する方法を紹介します。

shutdownコマンドについて

はじめにshutdownコマンドの種類や、待機する理由について説明します。

shutdownコマンドの種類

shutdownコマンドにはいくつかオプションがあります。一般的には以下の2点が使用されます。

・normal(デフォルト)
- 新規接続は受けつけません。
- 接続されているユーザが切断されるまで待機します。

・immediate
- 新規接続は受けつけず、新規トランザクションも開始できません。
- コミットされていないトランザクションは、全てロールバックされます。
- 接続されているユーザの切断を待機せず、全て切断します。

参考情報

Oracle® Database管理者ガイド 12cリリース1 (12.1) B71301-04
https://docs.oracle.com/cd/E49329_01/server.121/b71301/start.htm#i1006572

shutdownコマンドが待機する理由

shutdown normalは、バックグラウンドプロセスを除くセッションが全て切断されるまで待機します。
shutdown immediateの場合は既存の接続を全て切断しますが、SQLを実行中などのアクティブなセッションが存在すると待機します。

セッションが残っていることが原因でシャットダウンを待機している場合、アラートログには以下のような出力がされます。

 
    Wed Mar 22 04:19:12 2017
    Shutting down instance (normal)
    Stopping background process SMCO
    Shutting down instance: further logons disabled
    Wed Mar 22 04:19:13 2017
    Stopping background process CJQ0
    Stopping background process QMNC
    Stopping background process MMNL
    Stopping background process MMON
    License high water mark = 3
    Wed Mar 22 04:24:15 2017
    Active process 7628 user 'SYSTEM' program 'ORACLE.EXE (SHAD)' ★
    SHUTDOWN: waiting for logins to complete.
 

Oracle Databaseではshutdownコマンドの待機が1時間と決まっているため、この状態のまま1時間が経過するとORA-01013が発生し、シャットダウンがタイムアウトして失敗します。

またシャットダウン実行中は新規の接続を受けつけないため、Oracleのビューでセッションがどのような処理を実行しているか確認することができません。

そのため、shutdownコマンドを実行する前には、現在実行中の処理を予め確認しておくことをおすすめします。

事前に確認する情報

シャットダウンを正常に完了させるためには、事前にアクティブなセッションを確認しておく必要があります。
以下に確認方法を記載します。

まずはV$SESSIONから、接続しているユーザや実行中のSQLを確認します。
SQL_IDが表示されている場合は、現在SQLを実行中です。

 
    SQL> SELECT
      2    sid,
      3    serial#,
      4    username,
      5    status,
      6    machine,
      7    program,
      8    sql_id
      9  FROM v$session WHERE username IS NOT NULL;
 
           SID    SERIAL# USERNAME         STATUS   MACHINE              PROGRAM              SQL_ID
    ---------- ---------- ---------------- -------- -------------------- -------------------- -------------
             5          3 SYS              ACTIVE   ACE\B1401-02-25-W    sqlplus.exe          g8rmsag585tpv
           131         15 SCOTT            INACTIVE ACE\B1401-02-25-W    sqlplus.exe
           197          5 SCOTT            ACTIVE   ACE\B1401-02-25-W    sqlplus.exe          44ff5y395s8na
 

上記は、実行ユーザ(SID:5)を含む3セッションが接続されています。
このままではshutdownコマンドが待機してしまうため、オプションにより異なりますがそれぞれ対処が必要です。

・SID:5でshutdown normalを実行する場合
 SID:131とSID:197のどちらも接続を切断する必要があります。

・SID:5でshutdown immediateを実行する場合
 ステータスがINACTIVEのSID 131は強制的に切断されるため対処は不要です。
 しかし、SID:197がSQL_ID:44ff5y395s8naのSQLを実行しているため、この処理の完了を待つか手動で停止する必要があります。

 
   SQL> SELECT
      2      sql_text
      3  FROM
      4      v$sqltext
      5  WHERE
      6      SQL_ID='44ff5y395s8na';
 
    SQL_TEXT
    ----------------------------------------------------------------
    update test set col = '2' where col='1'
 

停止しても問題ない処理であれば、予め停止しておいてshutdownコマンドを実行しましょう。

 
SQL> ALTER SYSTEM KILL SESSION '&SID,&SERIAL#' IMMEDIATE;
 

まとめ

今回は、セッションが残存している影響でシャットダウンが待機しないよう予め確認する方法をご紹介しました。

シャットダウンが完了しないというお問い合わせをいただくことはよくありますがshutdownコマンドを実行後にご連絡いただくことが多く、原因のセッションを特定できない場合があります。

ご案内した方法で予めセッション情報をご確認いただけば、Oracle Databaseを停止する前に対処できますので、ぜひご確認をお願いします。

筆者情報

アシスト北海道

紹介文


■本記事の内容について
 本記事に記載されている製品およびサービス、定義及び条件は、特段の記載のない限り本記事執筆時点のものであり、予告なく変更になる可能性があります。あらかじめご了承ください。

■商標に関して
 ・Oracle®、Java、MySQL及びNetSuiteは、Oracle、その子会社及び関連会社の米国及びその他の国における登録商標です。
 ・Amazon Web Services、AWS、Powered by AWS ロゴ、[およびかかる資料で使用されるその他の AWS 商標] は、Amazon.com, Inc. またはその関連会社の商標です。
  文中の社名、商品名等は各社の商標または登録商標である場合があります。

関連している記事

  • EDB
  • PostgreSQL
2025.11.19

今さら聞けない!?WALアーカイブのベストプラクティス

PostgreSQL開発に多く貢献しているEnterpriseDB社による WALアーカイブ設定に関するベストプラクティスをご紹介します。

  • EDB
  • PostgreSQL
2025.04.16

PostgreSQLの拡張機能「system_stats」のご紹介

EDB社が提供するPostgreSQLの拡張機能「system_stats」はPostgreSQL ユーザーがパフォーマンス問題に取り組む際の非常に強力なツールになります。SQLクエリでOS情報を取得できるため、DBエンジニアにとってはパフォーマンスの監視が格段に簡単になります。テストした結果をご紹介します。

  • EDB
  • PostgreSQL
2025.03.10

意外な落とし穴!アプリケーション⇒DBデータ型によるパフォーマンス影響

PostgreSQLのオプティマイザがインデックスを適切に使用できない理由は様々ですが、本記事ではJDBC⇔PostgreSQL間でデータ型の不一致がインデックスの使用にどういった悪影響を及ぼすかを見ていきます

ページの先頭へ戻る