データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は「2016年のORAエラー問い合わせ数ランキング」を紹介します。
2016年11月17日にOracle Databaseのユーザーグループ「JPOUG」のイベントで登壇させていただき、2016年にアシストのサポートセンターに問い合わせを多く頂いたORAエラーのランキングを紹介しました。
問い合わせが多いエラーとは、すなわち、困っている方の多いエラーに近しいといえます。エラー発生の防止や発生時の初動対応検討のお役に立てればと思い、本記事でも紹介をさせていただきます。
ランキングは、以下の条件で集計しました。
1位は「ORA-00600」でした。ORA-00600はエラーメッセージの通り内部エラーですので、発生原因の調査は基本的にサポートで行うことになります。
エラー発生時には、次のようなメッセージがアラートログに出力されています。アラートログとトレースファイル、インシデントファイル(Oracle Database 11gR1以降の場合)をサポートセンターに送付してください。
Wed Aug 03 14:22:12 2016 Errors in file C:\ORACLE\diag\rdbms\v12102\v12102\trace\v12102_ora_5028.trc (incident=36449): ORA-00600: 内部エラー・コード, 引数: [qkaffsindex1], [], [], [], [], [], [], [], [], [], [], [] Incident details in: C:\ORACLE\diag\rdbms\v12102\v12102\incident\incdir_36449\v12102_ora_5028_i36449.trc
なお、My Oracle SupportにログインできるOracleユーザーには、ログファイルをアップロードすることで既存の不具合や事例に合致しているかを調べられるトラブルシューティングツールもあります。My Oracle Supportにて、以下の文字列で検索してください。
2位の「ORA-07445」は、処理を実行しているプロセスがOSから例外を受け取った場合に発生するエラーです。こちらも1位のORA-00600と同様に、発生原因の調査は基本的にサポートで行うことになります。
ORA-00600やORA-07445が発生してサポートに問い合わせを頂いた際には、原因の調査依頼とともに「このエラーはどのような影響がありますか?」という質問も多く頂くので、併せて解説します。
ユーザープロセスでこれらのエラーが発生すると、基本的にはエラーを受けたプロセス(セッション)が実行していた処理が失敗します。
一方のバックグラウンドプロセスの場合は、エラーを受けたプロセスにより動作が異なります。インシデントファイル内の「Current SQL statement for this session」という項目に、エラー発生時に実行していたSQLが出力されています。こちらを参照し、利用システムでどのような処理なのかを確認してください。
なお、ORA-07445もORA-00600と同様にトラブルシューティングツールがあります。My Oracle Supportにて、以下の文字列で検索してください。
3位の「ORA-04030」は、Oracle Databaseのプロセスが処理を行おうとした際に、要求したサイズのメモリをOSから獲得できなかった場合に発生します。主にサーバの空きメモリ不足に起因します。一度発生するとあらゆる処理が失敗することも多いため、業務への影響が大きいエラーです。
弊社のサポートセンターには、OSやデータベースの再起動を行ってメモリを解放するなど、お客さま側で初期対処された後で問い合わせをいただくケースが多くを占めていました。
まず、ORA-04030が発生した段階で既にシステムのメモリが不足しています。これを予防するには、平時からOSコマンド──UNIX系はpsやtop、Windows系はパフォーマンスモニターやPsListを利用して、定期的にデータベースサーバ上で稼働しているプロセスの状態を監視し、メモリの使用率上昇のタイミングや時間帯などの傾向を捉えておくことが重要です。
また、Oracle Databaseのプロセスが原因でメモリを大量に使用していた場合は、「Enterprise Edition+Diagnostics Pack」のライセンスを持ち、かつ「Active Session History(ASH)」が利用できる環境であれば、システムアクティビティーにおけるメモリ内のアクティブなセッションの履歴を残す「DBA_HIST_ACTIVE_SESS_HISTORY」から、(仮に再起動後であっても)「どのセッションが、いつからメモリを使い始めたのか」といった情報を確認できます。
情報がなければ原因調査が難しくなる可能性が高いので、ライセンスの都合でASHが利用できない環境では、「V$SESSION/V$PROCESS」の情報を定期的に取得するようにしましょう。
Copyright © ITmedia, Inc. All Rights Reserved.