常駐先で、ORACLEデータベースの管理やってます。ORACLE Platinum10g、データベーススペシャリスト保有してます。データベースの話をメインにしたいです

前任者が残したもの

»

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

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

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

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

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

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

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


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

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

hikutugi.jpg

Comment(5)

コメント

湯二

以前のコラムで、イラスト描いてるのは誰ですか?という質問がありました。
描いてるのは私、ペンタブレット使って描いてます。
なかなか、鉛筆と違って描き辛いですね。
業務中に読みにくいかもしれませんが、勘弁してやってください。

abekkan

この話を読むと、昔データベースの管理をしていたころを思い出します。
謎のテーブルで名称が名前になっているのはまだ良心的じゃないですか。tempとかhogeとかはやめてほしいですね。
ちなみに私はダミーデータによく、ABEhを使っていました。ABE,BABA,EDAなどの名前は16進数で表記できるので便利です(笑)。

あと、イラストがいつもいい感じでコラムを盛り上げていますね!

ハリコフ

本番環境がEnterprise、開発環境がStandard。本番環境にPartitioning、当然、開発環境にはPartitioningが無い。ぶっつけ本番でパーティションの切り直しを実施したら、インデックスが無効可(UNUSABLE)。インデックスの再構築に半日。業務が止まって酷い目にあったってのはありました。

テストが出来ないのは辛いので、次のリプレース時にはPartitioningを止めて、大量のメモリを積んで性能を稼ごうかと思案中だったりします。

論理的な構成の違いより、物理的な構成の違いの方がまだましかなと。

湯二

abekkanさん。コメントありがとうございます。
abekkanさんのコラム、いつも読んでます。

DBAでしたか!
tempだと、システムっぽい名前だから消しにくいですね。
ダミーデータ作りも悩みますね。
私は、○○1から○○100とか、名前の後ろに番号付けただけの手抜きが多いです。

イラストは、空白を埋めるために描いてますね。
あと、殺伐としたくないので、笑いを取るためですね。

湯二

ハリコフさん、いつもコメントありがとうございます。

本番環境と開発環境で、Editionが違うというのは、まだお目にかかったことはないです。
本番では再現するけど、開発では再現しないといった、環境の違いで障害調査が進まないといった困ったことが起こりそうですね。
また、環境が違うのでリハーサルをしても意味がない、というか出来ない。
ハリコフさんの場合は、まさにそういったパターンですね。

なるほど、本番と開発で、論理的な構成が違うと、テストの意味がなさそうです。
表領域の構成、テーブルの構成、スキーマ構成が違うとか。
本番と同じコマンドで試せないのは致命的です。
その点、論理的な構成が同じで、物理的な構成が違うだけなら何とかなりそうです。
例えば、表領域の構成が同じで、サイズだけが異なるなら、本番と同等のコマンドが試せます。
(サイズのところは違うけど)

コメントを投稿する