稼働環境外

とあるシステムを導入したときの話です。
そのお客様では新しい電算棟にマシンルームの準備をしている最中でした。
しかしマシンの納期等の都合から先行してシステム構築を行いました。
構築作業は無事終わり、テストが開始されました。

構築検収の数週間後、電話で問い合わせがあり、バックアップが失敗しているとのことでした。
そこで各種ログを調査しましたが容量は足りていますし、エラーはハードウェアのものと思われました。

Diag情報等々色々取り寄せましたがどうも埒があかなかったのですが、
ふと気になったのでマシンルームの建設状況はどうか聞いてみました。
入退館の扉が完成し、動き始めているが空調はまだ動かしていないとのこと。
そこでマシン付近の温度を調べてもらったところ、稼働保証温度域を超えていました。

もちろん本番稼働時は空調が効くのでそのようなことはないと思いますし、
本番稼働後同じエラーは発生していません。

たとえデータベースエンジニアとはいえ、マシン付近の環境にも気を配らなければならない、
そんな教訓をこの事例から学びました。

フェイルオーバー発生

ずいぶん昔の話ですが。

第一報はフェイルオーバーが発生したので、業務継続の確認と原因調査を行えというもの。
こう言うと語弊がありますが、割とよくあるお話。

定番の調査方法はOSやクラスタのログ、データベースのログの採取、解析を行い、
原因を特定していきます。

動作している環境から定番の資料を送ってもらいましたがどうもちぐはぐな状態です。
必要なログがなかったり、動いているはずのモジュールが動いていなかったり。
多分資料を取ったサーバを間違ったのだろうと連絡しても、どうも間違いは無いらしい。

仕方ないのでまずもらった資料で該当すると思われる時間帯を調べると
OSのシャットダウンが発生していました。
その時間帯の状況をお聞きすると、まさにフェイルオーバーしているころだと。

よく考えました。どうもおかしいので。

引っ張っても仕方ないので結論だけ。
人力フェイルオーバーでした。

何でもOSを強制停止して、その後別筐体へストレージを結線しなおし、起動したと（！）
その後稼働しているサーバのログをもらいましたがどうやら業務自体は無事に動いているようでした。
フェイルオーバーとは言ったものの、クラスタウェアでの制御ではなく、コールドスタンバイだったようです。

このときは今でも仕方なかったと思ってはいます。
しかし、先入観に縛られず、何が起きているか環境の様子を聞くという基本を大事にする、
そんな教訓を忘れないようにする時々思い返すエピソードです。

バックアップが・・・！！

データベースの仕事をやっているとたまに出くわすデータ破壊。
主に理由はストレージの故障（特にコントローラ周り）がメインですが、
そのときに大切なのがバックアップ。
普段からバックアップは「ちゃんと」運用していますか？

この「ちゃんと」はとても難しいというお話。

とある重要データを扱うシステム。
最もRDBMSに入っているデータで重要でないものの方が珍しい訳で。
当然バックアップ運用が組み込まれていました。
やり方はよくあるオンラインバックアップをテープライブラリに吸い上げる方式。
幸い安定稼働し続け、ユーザさんには迷惑をかけることなく動いていました。

が、ある日。
そのデータベースが使っていたディスクが多重障害にはまってしまい、ファイルシステムが壊れました。
救えたデータもあったようですがシステム系ファイルが致命的な状態に陥っています。
そこで管理者はバックアップからの戻しを決意しました。

とは言っても手順も標準化されており、スクリプトベースで戻すことができるはずです。
リストア作業を続けています・・・！？
何度戻しても何度リカバリをかけても問題となっているデータベースファイルの
ヘッダが壊れている！！

何が問題なんだろうと管理者は以下のことを行いました。
1.戻したデータファイルの中身をバイナリダンプしてみる
2.バックアップソフトが残しているログファイルを読む

1の結果から確かにおかしなデータがあちこちに書き込まれているようでデータファイルは
正常ではないことがわかりました。
一方2ではテープの読み書きでのエラーは一切起こっていなかったのです。
ですがさっきまで安定稼働していたデータベースとは全く違うデータが
テープには保存されていたのです。

そこでまず取りかかったのがデータ復旧。
そのときは本当にラッキーで、数日前たまたま開発データベース作成のためにデータを
CSV形式でエクスポートしてあったのです。
そこでデータベースを作り直して数日前のデータを入れ、失われた文は帳票から直接再投入しました。
これでデータベースは正常可動可能となりました。

一方でなぜバックアップファイルが壊れていたのか。
これはハードウェアの専門家を入れ協議した結果、テープの寿命であることがわかりました。
実は安定可動時期が長すぎて、その間塩漬け状態となっており、テープの交換がされていませんでした。
正確にはクリーニングテープは交換していたのですが、肝心のデータ用テープは寿命を越えていたのです。

＜教訓＞
メディアの寿命もちゃんとバックアップ運用で考慮に入れよう
時々でいいからバックアップを違う環境に戻してみて正常性を確認しよう
バックアップは戻してみないと正しいかどうかがわからない！

SQL Serverを使っていればverify onlyでの確認も出来ますが、何より確実な方法はバックアップを
戻してデータの中身を確認することです。もちろん普段からdbcc checkdbは実行しておきましょう。
可能であれば1日1回、実行しておきましょう
データの整合性を維持するには地道な努力が必要なのです。

http://msdn.microsoft.com/ja-jp/library/ms188902.aspx
http://technet.microsoft.com/ja-jp/library/ms176064.aspx

アプリケーションが遅かった

2つのデータベースに接続するアプリケーションがありました。
同じ処理をするのですが、片方だけがどうも遅い。
セオリー通り、ロックや実行計画を取得しましたが同じ。
データも同じ。。。。

2時間悩みました。

結局妙案は思いつかず、ふとマシンラックの後ろでぼーっとしていたところ、
あるルータのリンクアップの色が違ったのです。
全部GigaBitで動いているはずなのですが1つだけ色が100MBps。
DBサーバ側はGigaでリンクアップしていたのにクライアント側は100M。
冗長化されていたので許可をもらって抜き差ししたところ、Gigaでリンクアップ！

問題となっていた遅延が解消しました。
どうやらリンクアップの速度が違うとネゴシエーションに時間がかかるらしいです。
（ここの部分技術的に裏付けは取っておりません。ご了承ください。）

思わぬ落とし穴でした。
ネットワークパケットを見るか、一度再起動をすれば良かったかもしれません。
なぜ100Mでリンクアップしていたかは謎です。もしかしたらケーブルの接触不良だったかもしれません。

本当にあった事例

これから気が向いたとき？に経験した事例みたいなものを紹介しようと思います。
フェイクがいくつか入ることになるので細かいつながりがおかしいときがあるかもしれませんがご了承ください。
もし私の正体？に気がついた関係者の方、そっとしておいていただけますと幸いです。