【Oracle Database】2016年「ORAエラー」サポート問い合わせ数ランキング:データベースサポート最前線の現場から(4)(1/2 ページ)
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は「2016年のORAエラー問い合わせ数ランキング」を紹介します。
2016年11月17日にOracle Databaseのユーザーグループ「JPOUG」のイベントで登壇させていただき、2016年にアシストのサポートセンターに問い合わせを多く頂いたORAエラーのランキングを紹介しました。
問い合わせが多いエラーとは、すなわち、困っている方の多いエラーに近しいといえます。エラー発生の防止や発生時の初動対応検討のお役に立てればと思い、本記事でも紹介をさせていただきます。
ランキングは、以下の条件で集計しました。
- 接頭辞「ORA-」のみを対象とし「TNS-」や「RMAN-」などはカウントしない
- 期間は、2016年1月1日〜10月31日
- お客さまからの問い合わせ(電話/メール/弊社Webサイト)の第一報で伝えて頂いたエラー番号のみを対象とする。有効例:「ORA-01578が発生しました」/無効例:「エラーが発生しました」
- 第一報で複数のエラーを伝えていただいた場合は、それぞれをカウントする
- エラー番号の「0」の有無は考慮しない。例:ORA-1と伝えていただいた場合は、ORA-00001としてカウントする
1位 ORA-00600: 内部エラー・コード, 引数: [string]...
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にて、以下の文字列で検索してください。
- ORA-600 トラブルシューティング・ツール
2位 ORA-07445: 例外が検出されました: コア・ダンプ [string]...
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にて、以下の文字列で検索してください。
- ORA-7445 トラブルシューティング・ツール
3位 ORA-04030: stringバイトを割り当てようとしてプロセス・メモリーが不足しました
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.
関連記事
- 【Oracle Database】忘れていませんか? 「アラートログ調査」に必要な、たった3つのキホン
データベース管理システムの運用でトラブルが発生したらどうするか。データベースサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は基本編として「アラートログの調査で押さえるべき3つのポイント」を解説します。【Oracle Database 12c対応版】 - Oracle運用の基本「ログ」を理解しよう
本連載では、Oracle Database運用の鍵となるトラブル対処法について紹介していきます。第1回、第2回では情報収集の要となるログについて見ていきます。ログの出力情報は10gと11gとでは大きく異なる点がありますので、それぞれについても確認しておきましょう。 - カーソル・エラーとオブジェクトの問題切り分け
Oracleデータベースの運用管理者は、突発的に直面するパフォーマンス障害にどうやって対処したらよいか。本連載は、非常に複雑なOracleのアーキテクチャに頭を悩ます管理者に向け、短時間で問題を切り分け、対処法を見つけるノウハウを紹介する。対象とするバージョンはOracle8から9iまでを基本とし、10gの情報は随時加えていく。(編集局) - IF文のネスト地獄から抜け出せるMERGE文