ORACLEデータベースの運用を引き継ぐ際の注意点

データベースを前任者から引き継ぎ、しばらく運用すると、前任者の色んな痕跡があることに気付きます。
障害のもとになるものもありました。
今にして思えば、事前に把握しておけば、対策が取れて障害を防げたというものも。
今回は、そういった引継ぎについてのお話です。

■歴代管理者が作った謎のテーブル
開発環境のデータベースにて、謎のテーブルを多数発見。
例)
・takahashi
・yamada
・tanaka

名称から、検証用として作成したテーブルだと思いました。
何となく不要なのはわかりますが、ちょっと消しづらい。
ですが、あればあったで、ディスク容量の無駄遣いです。
残された開発担当の方に、必要かどうか聞いても「分からない」という回答。
開発環境なので、えいやっ、と思い切って削除しました。
そうすると、実はこのテーブルを参照して動くツール(開発環境独自のもの)がありました。
そのツールが動かなくなったことに気付いた開発者の方に、怒られてしまいました。

■日次バックアップがダンプファイル
1日1度のバックアップが夜中の2時というシステムがありました。
そのバックアップがexpコマンドによるダンプファイルでした。
　※ORACLEは、expまたはexpdpコマンドでダンプファイル形式の論理バックアップが取得可能です。
論理ということは、物理的な破損からの復旧時には使用できません。
この場合、新しいディスクを用意して、データベースを再構築するところからの復旧になります。
その日の夜中2時に取得したダンプファイルが最新なので、データベースが壊れる直前まで戻すことが出来ないということです。
　※どう頑張ってリカバリしても、夜中2時の時点が最新の状態です。
お客さんと話し合って、アーカイブログを使用したホットバックアップの方法に直しました。

■開発環境と本番環境の構成が異なる
開発環境は、コストの制約があり、メモリ・CPU・ディスクは本番同等でなくとも、
ORACLE関連の設定は本番同等というミニサイズ環境が理想です。
　※あくまでORACLEからの観点です。
ミニですが、本番同等の環境でリハーサルを行うことで、本番作業のミスを減らすことをできます。
しかし、コストの関係で、ORACLEに関しても同じ環境にできなかった場合があります。
例えば、本番と開発の表領域構成が違うとか。
今までで一番大きな差異は、開発環境はシングル構成で、本番環境はRAC構成だったというものでした。
本番環境用の手順書を、開発環境でのリハーサルで使用しましたが、開発環境用に読み替える部分が多すぎて、
流れの確認にしかなりませんでした。
本番当日の一発勝負になったことを覚えています。

■メモリ不足でハング、設計書が無い
共有プールが不足して、新規接続を受け付けなくなり、遂にはデータベースがダウンしたことがあります。
引き継いだデータベースには、共有プールの設定値に関する根拠資料がありませんでした。
なぜ今の値になっているのかを、お客さんに説明するのに困りました。
とりあえず、復旧が優先だったので共有プールの値を増やすにしても、どれくらい増やせばいいか検証できる環境もありません。
えいやっ、で大きめの値を設定し、決まった時間に監視する日々が始まりました。

■監査ログでディスクがいっぱいに
ORACLEはバージョンアップする度に、デフォルトセキュリティが強化される傾向にあります。
11gでは、監査テーブルに大量のログを出力するようにデフォルト設定されています。
それを知らずに運用していたデータベースを引き継ぎました。
そしたら、ある日、表領域の閾値超過お知らせが届きました。
調査すると、監査ログテーブルが存在する表領域の使用率が80%を超えていました。
3時間ごとに使用率が1%ずつ上昇しています。
設計書には監査ログを残すことについて書かれていません。
このままだと、ディスクがいっぱいになりデータベースがダウンします。
急ぎで、その監査ログのデータを削除し、監査ログを出力しない設定にしました。
自分が引き継ぐORACLEのバージョンを把握していれば防げる問題ではありました。
　※「aud$　肥大」で検索すると分かります。

■まとめ
引き継いだデータベースが安定稼働しているからと言って、油断できません。
いつ何時、発火するか分からない時限装置が、どこかに仕掛けられているかもしれません。
　※前任者は仕掛けたつもり何て無いけど。
引き継いだデータベースは、引き継いだ時点で、半年以上再起動せず稼働していますか？
定期的に再起動をしてきたようなデータベースは、これから半年以上無停止で動作するとどうなるか考えておいたほうがいいです。
ずーっと稼働してないと発生しないような問題も多いからです。

引き継ぎは、設計書を用いて行われることがありますが、設計書だけだと、今のデータベース状態が分かりません。
また、設計書には記載されていないことも多いです。
　※先に環境への対応をして、後で設計書に記載しようとして忘れた、とか。
引き継がれる人は時間が取れるなら、実際の環境を覗いてみて下さい。
問題ありそうなところを見つけ、訊きたいところを洗い出しましょう。