【Oracle Database】2016年にサポートにお問い合わせをいただいたORAエラー TOP5

この記事は JPOUG Advent Calendar 2016 の9日目のエントリです。

11月17日にOracle Databaseのユーザ・グループ JPOUG のイベントで登壇させていただき、2016年にアシストサポートセンターにお問合わせを多くいただいたORAエラーのランキングを紹介しました。

お問合わせの多いエラー≒困っている方の多いエラーですので、エラー発生の防止や発生時の初動対応検討のお役に立てればと思い、本ブログでも紹介をさせていただきます。

以下の条件に合致したORAエラーのうち、お問い合わせの多かったTOP5を紹介します。

・接頭辞「ORA-」のみを対象とし「TNS-」や「RMAN-」などはカウントしない
・期間：2016年1月1日～10月31日
・お客様からのお問い合わせ（TEL/MAIL/弊社WEBサイト）の第一報でお伝えいただいたエラー番号のみ
　有効例：ORA-01578が発生しました
　無効例：エラーが発生しました
・第一報で複数のエラーをお伝えいただいた場合はそれぞれカウント
・エラー番号の"0"の有無は考慮しない。
　例：ORA-1とご連絡いただいた場合はORA-00001としてカウント

2016年(10月末まで)で最もお問合わせが多かったのはORA-00600でした。ORA-00600はエラーメッセージのとおり内部エラーですので、発生原因の調査は基本的にサポートで行うことになります。

エラー発生時には次のようなメッセージがアラートログに出力されていますので、アラートログとトレースファイル、インシデントファイル（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を利用可能な方はトラブルシューティング・ツールにログファイルをアップロードすることで、既存の不具合や事例に合致しているかを調べることが可能です。

参考資料： ORA-600 トラブルシューティング・ツール (ドキュメントID 2028577.1)

処理を実行しているプロセスがOSから例外を受け取った場合に発生するエラーです。こちらもORA-00600と同様に発生原因の調査は基本的にサポートで行うことになります。

ORA-00600／ORA-07445が発生し、サポートにお問い合わせをいただく際に原因の調査とあわせて「このエラーはどのような影響がありますか？」というご質問を多くいただきます。

ユーザプロセスでORA-00600／ORA-07445が発生した際は、基本的にはエラーを受けたプロセス（セッション）が実行していた処理が失敗します。バックグラウンドプロセスの場合は、エラーを受けたプロセスにより動作が異なります。

インシデントファイル内の"Current SQL statement for this session"という項目にエラー発生時に実行していたSQLが出力されていますので、こちらをご確認いただき、利用システムでどのような処理なのかをご確認ください。

なお、ORA-07445もトラブルシューティング・ツールがあるため、My Oracle Supportをご利用可能な方はこちらをご利用いただくことで容易に調査を行うことができます。

参考資料： ORA-7445 トラブルシューティング・ツール (ドキュメントID 2026907.1)

Oracle Databaseのプロセスが処理を行おうとした際に、要求したサイズのメモリをOSから獲得できなかった場合に発生します。空きメモリ不足に起因するため一度発生するとあらゆる処理がこのエラーで失敗することも多く、業務への影響が大きいエラーです。

弊社の事例ではOSやデータベースの再起動でメモリを解放するなど、お客様側で対処された後にサポートセンターにお問い合わせをいただくケースが多くを占めていました。

ORA-04030が発生した時には既にメモリが不足しています。予防の観点では、平時からOSコマンド(UNIX系ps、top／Windows系パフォーマンスモニタ、pslist)を利用して定期的にDBサーバ上で稼働しているプロセスの状態を監視しておき、メモリの使用率上昇のタイミングや時間帯などの傾向を捉えることが重要です。

また、Oracle Databaseのプロセスが原因でメモリを大量に使用していた場合、Enterprise Edition + Diagnostics Packのライセンスをお持ちの環境でActive Session History（ASH）が利用できる環境であれば、 DBA_HIST_ACTIVE_SESS_HISTORY から再起動後であっても「どのセッションがいつからメモリを使い始めたのか」を確認することができます。

情報がなければ原因を調べることが難しくなる可能性も高いため、ライセンス上ASHが利用できない環境では、V$SESSION／V$PROCESSの情報を 定期的に取得 するようにしましょう。

自動実行ジョブが失敗した場合に発生するエラーで、原因は付随するエラーを確認します。事例ではマテリアライズド・ビューの自動リフレッシュのジョブが失敗しているケースが多く見られました。

マテリアライズド・ビューには様々な制限がありますので、作成の際には データ・ウェアハウス・ガイド のマニュアルをご参照ください。

新規接続時に SQLNET.INBOUND_CONNECT_TIMEOUT で指定した時間（デフォルト60秒）以内にユーザ認証が完了できなかった場合、ORA-03136がアラートログに出力されます。

ORA-03136は一般的に以下のような理由で発生します。

・DBサーバが悪意のあるクライアントからデータベースへの接続要求を受けた場合
・DBサーバが接続要求を受け取った後、クライアント側の処理に時間がかかった場合
・DBサーバが接続要求を受け取った後、クライアントとDBサーバ間のネットワーク通信上に問題があり時間がかかった場合
・パスワードの入力ミス等で認証処理が失敗した状態で、セッションが切断されない状態が続いた場合
・DBサーバの負荷が高く、時間がかかった場合

原因究明に至っている弊社の事例では、多くのケースが"DBサーバの負荷が高く、時間がかかった場合"に合致していました。しかし、DBサーバの負荷情報を定期的に取得されていない場合には原因の特定に至らず「次回再現時に備えて情報取得」となってしまうケースも少なくありません。

ORA-04030と同様ですが、日頃からDBサーバのリソースを監視しておくことで、エラー発生のタイミングや傾向を捉えることが重要です。

6位～10位までは以下のとおりです。ORA-04031やORA-29280、ORA-01555など、初期化パラメータの設定に起因しているエラーが多いことが特徴です。

運用を続けている環境ではデータ量の増加や構成の変更などに伴い、運用開始時に設定したパラメータが適切でない可能性もあります。AWRやSTATSPACKといったデータベースの稼働統計を利用し、現在のパラメータが適切かどうかの見直しを定期的に行うことで、トラブルを未然に防ぐことができるかもしれません。

お客様からサポートセンターにいただいたお問合わせは、サポートエンジニアが調査をする際の貴重なナレッジとして蓄積されます。2016年も非常に多くのお客様にサポートセンターをご利用いただきました。大変感謝しております。

Database Support Blog、今年のOracle Database記事は本稿で最後となりますが、今後もアシストではサポート事例やサポート対応で得た情報を積極的に公開することで、データベースを利用されている方に還元できればと思っております。

それでは、少し早いですがHappy Holidays and Happy New Year！

2021年 18日目
Oracle Databaseのサポート対応で依頼することの多いファイルとコマンド
https://www.ashisuto.co.jp/db_blog/article/jpoug-oracledb-logfiles-command.html

2020年 17日目
Oracle Databaseバージョンアップ後の性能劣化で試したい暫定対処
https://www.ashisuto.co.jp/db_blog/article/jpoug-vup-temp-solution.html

2019年 24日目
【Oracle Database】DMLリダイレクションで一歩進んだ Active Data Guard の使い方（19c新機能）
https://www.ashisuto.co.jp/db_blog/article/20191224_ADG_REDIRECT_DML.html

2019年 20日目
【Oracle Database Cloud】"超"現実的に考える！Oracle CloudへのDB移行ガイド
https://www.ashisuto.co.jp/db_blog/article/20191220_cloud.html

2017年 14日目
Oracle Database 12cR2へのアップグレード後に発生するORA-01017
https://www.ashisuto.co.jp/db_blog/article/201712-ora-01017.html

2015年 15日目
パフォーマンスダウンを「再現待ち」にしないための準備
https://www.ashisuto.co.jp/db_blog/article/20151215_oracle_pfmdwn.html

筆者情報

• 大野 高志

サービス事業部 サポートセンター

2007年にアシスト入社後、Oracle Databaseのサポート業務に従事。現在はサポート業務の傍ら、未解決のトラブルを一つでも多く減らせるよう、サポートセンターに蓄積されているノウハウを社内外に伝える活動を行っている。