ORACLEデータベース理想的な対応と現実的な対応の比較

データベースが停止すると、業務システムが使えなくなります。
データベースが停止する原因とは？
ORACLEの場合、以下の原因が考えられます。

・ORACLE自体のバグ
・アプリ自体の問題
・システムの使われ方が変わった
・作業ミス
・設計ミス
・ユーザー操作ミス
・サーバ、ディスクの老朽化

上記の項目一つ一つについて、理想的な対策があります。
ただ、コストの関係やその現場のやり方があり、現実的な対策を採用することが多いです。
現実的な対策は、不十分な面もあるので、なるべく理想に寄せる努力をしています。
実際に行っている対策を、いくつか紹介します。

※凡例
◎に理想的な対策を書いてます。
●に実際やった現実的な対策を書いてます。

■ORACLE自体のバグ
ORACLE製品自体のバグによる障害。
処理のスローダウンから、ハングするものまで大小さまざま。

◎理想
既知のバグなら事前に調査して、速やかにパラメータを変更したり、個別パッチを当てたりする。
●現実
24時間無停止のシステムだと、上記のような対策をすぐに行うことが難しいです。
計画停止のタイミングで、対策を行います。
世界初のようなレアなバグを引き当てることがあり、こういった場合は個別パッチが無いため、どうしようもありません。
ORACLE社が個別パッチなり、回避策を提供してくれるまで、待つしかありません。

■アプリ自体の問題
アプリのプログラムの作りが悪く、それが原因でORACLEの障害を引き起こす場合。
例)
・SQLがバインド化されていないため、多種類のSQL解析結果が共有プールを圧迫して、メモリ不足を起こす。
・commitをまめに行わったために、UNDO表領域がいっぱいになる。
・SQLで不要なソートや結合が指定されていて、PGAや一時表領域を大量に使用した結果、領域不足になる。
・デッドロックを引き起こすような処理がある。
これらが頻発し、データベース停止につながります。

◎理想
開発担当者にプログラムを、以下の観点で見直してもらう。
・SQL文がバインド化されてるか。
・確定処理(commit,rollback)のタイミング。
・SQL文で不要なソートや結合が無いか。
・デッドロックになるような処理が無いか。
そして、データベース管理者が、ソースコードレビューにも参加し、DBアクセス周りを特に注意深く確認する。
●現実
皆、時間が無いので、見直されなくなることが多いです。
データベース管理者も、レビューに参加する時間が無く、見逃している部分があります。
上記のようなことを考慮して、共有プール、一時表領域、UNDO上領域などのリソースを大きめに設計します。

■システムの使われ方が変わった
お客さんの使い方は、時間の流れとともに変わります。
ある日を境に、或いは徐々にといった具合に。
使用する人数が増えたり、ある機能とある機能を同時に使いだしたり、データの参照頻度が変わったり、データ量が増えたりなど。
全てデータベースに影響します。
それがもとで、ディスクやメモリがいっぱいになったり、ORACLEのバグを引き起こしたりということもあります。
また、データ量が増えたことにより、一時表領域・UNDO表領域やアーカイブログ出力領域が当初の設計では足りなくなることがあります。

◎理想
システムの使われ方が変化させるようなイベントを抑えて置く。
常にメモリ、ディスク、CPUの使用量の情報を取得し、DBサーバの動きを観察する。
少しでも、普段と異なる動きが見られた場合は、調査をする。
●現実
常に情報を取得し、分析する時間が無い。
各種リソースは多めにとって、変化を許容できるようにする。

■作業ミス
開発データベースを停止するつもりが、接続先を間違えて、本番データベースを停止してしまったなど、人手による作業ミス。
資材を取り違えて、間違ったSQLを実行しデータを破壊してしまうことも。

◎理想
本番と開発環境につながる端末を分ける。
本番と同等の開発環境を用意し、リハーサルを本番と同じ手順で行えるようにする。
本番作業は実行者と確認者のペアで作業する。
ミスしたときのことを考えて、データのバックアップを取っておく。
●現実
本番と開発環境につながる端末を分けています。
本番作業は実行者と確認者のペアで作業を行っています。
なるべく本番で行う作業を、事前にリハーサルできるように同等に近い開発環境を用意しています。
ミスしたときのことを考えて、バックアップを取っておきますが、作業時間の制約があるため、部分的なところだけに限られること
があります。
(例えば、スキーマ全体取りたいけど、時間が掛かるので、データ変更するテーブルだけに絞るとか。)

■設計ミス
データベースの設計について抜けがあり、設計を元に構築したデータベースが、メモリ、ディスク不足を引き起こす。

◎理想
常に業務と連係して設計を行う。
業務設計で、データ件数、トランザクション数、など変更があれば、情報の提供を受けて、再設計する。
●現実
常に業務と連係できる時間が無いです。
そのため、当初、業務にヒアリングしたパラメータで設計してそのまま構築しています。
システムテストなどで、本番同等の使い方をして、各種リソースの使用量を実測し、設計、構築に反映しています。
また、各種パラメータを大きめに設計してデータベースを構築します。

■まとめ
ディスク容量については、データ件数やレコード長からある程度、正確に見積もれます。
ただそれも、設計時点のパラメータであり、実際に使われ出すとデータ件数はもっと多かったり、思い通りにいかないことが多い。
また、メモリに関しては、共有プールやバッファキャッシュなどを正確に見積もる式というのは存在しません。
各環境でOS、サーバ、ディスク、メモリ、CPUやトランザクション数、そしてデータ量などが異なるので公式として定義することが
できないのだと思います。
このように、データベースの各種パラメータは、ぴたりと正確な値を見積もることが難しい。
また、お客さんの使い方が変われば、正確にに見積もった値では、許容出来ないことだってあります。

そういったことを踏まえて、ほとんどの障害対策は、リソースに余裕を持たせて、急激な変化や不測の事態に対応するというものになりました。
設計、構築している側からすると、実測したり、計算で出した値に、安全率という形で余裕を持たせてます。
これは、予測がつかない部分(ORACLEの明かされてない仕様や、細かいシステムの使われ方)を補うためです。