データベースコンサルタントのノウハウちょい見せ

Oracle RDBMSなどのオラクル製品や各種インフラ技術(OS、ストレージ、ネットワーク)といった話題を取り上げます。著者は小田圭二、「門外不出のOracle現場ワザ」、「絵で見てわかるOracleの仕組み」、「絵で見てわかるOS/ストレージ/ネットワーク」などの著作もあります

ホーム > アーカイブ - 2008年08月

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
[ --/--/-- --:-- ] スポンサー広告 | トラックバック(-) | コメント(-)

データベース破壊というトラブル

データベース破壊とは、物理的にデータベースを構成するファイルが破壊されることです。ファイル自体が無くなってしまうケースから、ブロックという数KB程度の構造が破壊されるケース。1バイトや1ビットだけ破壊されてしまうケース、なぜかヌルで埋められてしまうケースなど多くの種類があります。データベース破壊では、データベース全体が起動しなくなるケースも多々あります。

結論から言うと、残念ながらデータベース破壊を100%避けることはできません。また、このインパクトは、他の障害と比べて桁違いなことが多いです。比較対象となる、業務アプリケーションのバグは、数も多いですし、料金計算の間違いなどは怖いです。しかし、データベースの障害は数は少ないけれども、一発のインパクトが大きい(データベースが起動できないなど)です。その最たるものが、この「データベース破壊」だと私は思います。

多数で構成される(そしてお互いの関与は最小限という特性を持つ)APサーバーは、不具合になっても1台程度の影響で済むでしょう。それに対して、DBサーバーは、データは1箇所(もしくはリレーションを持つ)という特性上、影響がシステム全体に広がりがちです。しかも、APサーバーのトラブルは最悪再起動すればなんとかなるはずですが、DBサーバーのデータベース破壊についてはそうは行きません。リカバリと呼ばれる作業を行うことになるため、最低でも数時間はかかると思ったほうがいいでしょう。

ところで、データベース破壊は、「メインフレームなら無い」と思うかもしれませんが、そんなこともありません。実際、いくつか聞いたことがあります。

さて、Oracle管理者への最低限のお勧めは、リカバリ手順を用意しておくことです。「制御ファイルの1つが壊れたときのリカバリ」「redoログファイルが壊れたときのリカバリ(不完全回復のケース)」「SYSTEM表領域などの管理用表領域が壊れたときのリカバリ」「業務データの表領域が壊れたときのリカバリ」あたりは用意しておきましょう。

それと、リカバリの練習はしておきましょう。リカバリもアーキテクチャの理解が必要な複雑な作業です。リカバリが必要な状況になった場合、初心者は絶対にパニックになります。自分のPCでも良いですから、壊す&直すを繰り返し、肌で実感しておくことが効果的です。

よく聞く、落とし穴その1は、リカバリできないバックアップです。システム稼動直後はバックアップとして機能していたけれども、データファイルなどの追加/ファイルの場所移動などによってバックアップとして機能しなくなっているケースがあります。

よく聞く、落とし穴その2は、制御ファイルやredoログファイルなどをバックアップからリストアしてしまうケースです。制御ファイルやredoログファイルは最新の管理データ/ログデータが格納されています。ここは基本的にリストア対象外です。気をつけましょう。

この記事のまとめです。
・リカバリ手順は用意できていますか?
・リカバリの練習はしましたか?
・制御ファイルやredoログファイルはリストアしません(例外除く)
・そのバックアップは本当にリカバリできるものですか?(最近、構成変更していませんか?)

「やばい!」という心当たりがある人は、いますぐ自分のシステムをチェックしてみましょう。

次回はリカバリの注意点(TIPS)についての紹介の予定です。
スポンサーサイト
[ 2008/08/31 22:29 ] DBA | TB(0) | CM(0)

Oracle上でトラブルになっているかどうか、カッコよく切り分けるためのテクニック

今回は主にOLTP系で使える、Oracleのトラブル切り分けテクニックの紹介です。

以後の説明に必要なため、まず、Oracleのアーキテクチャを説明します。Oracleには、接続処理用のリスナープロセスがあり、そのリスナープロセスが通信を受け付けて、その後サーバープロセスに引き渡します。サーバープロセスは、SQLを処理するプロセスです。SQLが処理されている間は、ずっと接続状態になっています。通常の設定(専用サーバー構成と言います)の場合、クライアント側の接続が切れない限り、対応するサーバープロセスも存在することになります。

トラブルには、大きくいくつかのパターンがあります。「接続できない」、「接続できたけどエラーでSQL処理できない」「ハングになった」「スローダウンした」「そしてトラブルはDBではない」の5つです。
「接続できない」場合、listener.logというファイルを探しましょう。リスナープロセスと通信はできたものの、結果的に接続できなかったのであれば、このファイルにエラーが書いてあるはずです(パラメータでログをオフにしていない限り)

つぎに、「接続できたけどエラーでSQL処理できない」場合です。この場合は、alert.logファイルに書いてあるはずです。ただし、一部のメッセージは書かれていないかもしれません。念のため、アプリケーション側のエラーも確認しましょう。

「ハングになった」「スローダウンした」の判定は、非常にやっかいです。まず、一般ユーザーでDBMSにログインできるかどうか確認しましょう(特権ユーザーはログインできてしまうことがあるためです)。

次に、v$sysstatでSQL実行数を見てみましょう
SELECT to_char(sysdate, 'MMDDHH24MISS')||','||NAME||','||VALUE
FROM V$SYSSTAT
WHERE NAME = 'execute count';
これで起動してからの累積値が見られます。私の場合、これを数秒から数十秒おきに数回叩きます。この値の増加が30秒で数回や十数回程度であれば、処理が来ていないか、処理されていない可能性が高いと言えます(DBMSが自分で実行するSQLもあるため、多少は発生します)。なお、「処理されていない」と言い切るためには、普段の負荷を把握しておきましょう。

次は、処理中(ハング含む)かどうかです。次のSQLを実行します。
SELECT to_char(sysdate, 'MMDDHH24MISS')||','||COUNT(*)
FROM V$SESSION
WHERE TYPE!='BACKGROUND' and STATUS='ACTIVE';
STATUSが'ACTIVE'なサーバープロセスが多数居る場合、サーバープロセスまで処理が届いたけど、その後、結果が返っていない。つまり、「DBサーバーより先のどこかに問題があるらしい」ということです。

なお、このSQLを実行しているサーバープロセス自身もactiveとしてカウントされますので、値は最低でも1以上です。これがずっと1であれば、処理されていないか、処理されていても一瞬で終わっているということです。

上記2つのSQLの結果(実行数とアクティブ)の関係はつぎのようにマトリックスで考えるとよいでしょう。
        アクティブが少ない   アクティブが多い
SQL数 少ない 単にSQLがきていない  おそらく詰まっている(ハング or スローダウン)
SQL数 多い   うまく処理できている  おそらく処理量が多いだけ(※)


※:普段よりSQL実行数が多い場合、限界を超えて、ボトルネックになっている可能性があります。ただし、普段どおりのSQL実行数でもアクティブが多い場合には、何か問題ありでしょう。

私は、「トラブルだ! 切り分けろ!」となったとき、上記の情報をすぐに確認して、「DB問題ありません」もしくは「DBまで処理が来ていません」もしくは「DBかDBより先に問題があるようです」とすぐに答えるようにしていました。効果的なのは実証済みです。これが現場ではものすごく重宝されます。応用すると、処理が再開されたときも「処理数上がってます。DBまで処理が届きました!」とか、いろいろな場面で活用できます。皆さんが、トラブルシューティングにおいて、ヒーローになれるかもしれません♪

なお、例外はバッチ処理などの、少数のプロセスが長々と処理をするシステムです。その場合は、そのサーバープロセスを詳細に分析しないと何とも判断できません。
[ 2008/08/28 03:44 ] DBA | TB(0) | CM(0)

「面倒」を乗り越えるには?

前回、「私の経験では、タイミングを逃すと絶対にやりません」と紹介しました。でもみんな面倒なことは嫌なものです。この「面倒だ」を乗り越えるのは何でしょうか?

「まじめ」でしょうか?「上司の強制」でしょうか?

私の考えでは「痛み」だと思います。障害が起きたことによる「自分の痛み」「顧客の痛み」「関係者の痛み」、そういう「痛み」を経験しているかどうか。そしてそれを大事にできるかどうか。ではないでしょうか。

トラブルの現場で、目の前で、何億円というお金が消えていくのを呆然と見ているしかできない自分。「どうするんだ」と怒られながら、大したことができなかった自分。普段はベンダーを怒っている情シスの人が、エンドユーザーから怒られてひたすら謝っている姿・・・そんな経験の有無ではないでしょうか。
#私はそんなにカッコよくないのです。失敗の数なら負けません^^;

これらを経験していれば、「面倒だ」なんて簡単には言えなくなります。必要性があれば、徹夜も「まあしゃないか」となると思います。

また、そういう経験をして、かつ、それでもこの業界で元気にやっているのであれば、未然防止やトラブル経験を生かすのは義務だと思います。

たしかに未然防止は面倒なものです。でも、この気持ちを思い出したら少しはできないでしょうか。

私も後悔が残るトラブルシューティングもありますが、「社内に失敗情報(トラブル情報)を共有すること」「IT業界に協力すること」「プロとして自分のスキルを磨くこと」で自分に納得しています(自己満足です)。そして、これがこのブログや記事、書籍を書く理由の1つです。

さて、こんなのを繰り返していると未然防止はできるかもしれませんが、つぶれてしまいます。数回後くらいに、つぶれないための考え方を書きたいと思います。
2回連続だと、重くなってしまうので、次はちょっとテーマを変えます。
[ 2008/08/24 19:39 ] DBA | TB(0) | CM(0)

トラブルから何かを得る(トラブルに備える)

痛い目を見たあと、あなたは忘れますか? それとも・・・?
一流の人は、いざというときに備えて鍛えておくものだそうです。
#私もできていないので他人事のように書いています^^;

私が好きな失敗学などを読んでも、きちんとトラブルを反省して、再発防止につなげるとか、日々の小さな失敗に気づくことで、大きなトラブルを防ぐことが書かれています。実際に統計的に調べてみても、障害の原因は、他のシステムで過去に起きた障害の原因と同じことが多いです。そういう意味では、ITの業界はコスト削減要求が強く(?)、このような取り組みは後回しなのかもしれません。

今回は、私の周りで行われている取り組みをいくつか紹介します。

・トラブルに備えたスクリプト集を作る。
 火消しとして「これは便利だ」と思うスクリプト集を作って、仲間内に公開したりしています。トラブルの現場でマニュアルなどを見ながらSQLを作っているようではカッコ悪いです。

・トラブル対応用のスクリプトや仕組みを設置する
 許可を得るのが大変ですが、検知やトラブル対応の仕組みを設置するのもお勧めです。検知は以前紹介した「閾値でアクティブ数を監視するようなもの」がよいでしょう。代表的な分析についてはスクリプトを作って、半自動で行えるようにしておくと、いざというときにスムーズに対応できます。

・各社のナレッジベースを活用する
 ボリュームが多いのが難点ですが、大手DBベンダーはナレッジベースが充実しているはずです。もし手間ひまがかけられるのであれば、ナレッジベースを調べて、現在の設定の総チェックをするのがお勧めです。大抵はそこまでの時間は無いでしょうから、何かを変更するときに、該当しそうなトラブル情報が無いかどうかだけでも調査することをお勧めします。また、トラブル発生時にナレッジベースを調べる癖をつけておくこともお勧めです。

・未然防止に生かす
 判明した設計や設定の注意事項は、チェックリストなどの形で横展開するとよいでしょう。あるシステムで発生した問題が、隣のシステムでも起きてしまうようでは怒られます。また追加開発で、トラブルが再発してしまうこともあるでしょう。そのため、チェックリスト化して未然防止を仕組み化するのがお勧めです。ただし、バグを避けるための回避策の採用はあまりお勧めしません。基本的には、集積パッチによる対策をとるべきです。これは、回避策や隠しパラメータを多用した結果、別のトラブルになっているケースがあるためです。バグはパッチで防ぐのが基本です。
#チェックリストの弱点は、盲目的にチェックリストを信じる人が出てくることと、アーキテクチャを軽視するようになることでしょうか。現場が「チェックリストを通ったからそれで良い」と考えるようになると危険です。

・Oracleのエンタープライズマネージャなどの製品を導入する
 たとえば、Oracleであれば、トラブル時の切り分けや監視などを行うオプション製品もあります。Diagnostic Packは、診断のためのオプションです。性能問題やハングのような事象に効果的です。一般的なユーザーには便利なオプションです。

・実は、Oracleの11gから障害時のログ出力が変わりました。ADR(Automatic Diagnostic Repository)と呼ばれる仕組みにより、各種ログが包括的に出力されます。これを解説しだすと長いので、興味のある方は次のWebサイトなどで学ぶとよいでしょう。 http://www.atmarkit.co.jp/fdb/rensai/ora_admin/02/oraadmn2-1.html 注:@ITの記事です。

「この記事のように、失敗を生かすことが必要だ」と思ったあなたは、きっと大きなトラブルを経験したばかりでしょう。のど元過ぎれば熱さを忘れます。善はいそげです。今のうちにやってしまいましょう!!! 私の経験では、タイミングを逃すと絶対にやりません^^;
[ 2008/08/19 23:29 ] DBA | TB(0) | CM(0)

トラブルのときに見かける人間模様

今回は大きなシステムトラブルのときに見られる人間模様の紹介です。十人十色ですし、各社のカラーもありますから、必ずこういう人が居るわけではないのですが、次のような人を見かけることがあります。

仕切りたがるけれども実力が伴わない人。とくに役職が上の人に居がちです。特徴は「質問が多いこと」「ポイントをつかめていないので指示の効率が悪いこと」「どうでもよい詳細を知りたがること」です。居るだけで、何もしないのであれば、まだ許せます。問題は、「何かを言わないと気がすまない」ことです(人間そんなものです・・・)。現場が解決策を出したとして、「これはXXだろう。XXXは大丈夫なのか。ベンダーとして保障するんだろうな? XXXに影響がでたらとゆるさんぞ」といった形で、些細なことを気にして、結果的にトラブル解決を遅くするケースです。

・自分の尻尾を追いかける犬タイプ

犬は、自分の尻尾を追いかけて、ぐるぐると回ってしまうことがあります。トラブルの現場でも、似たような人を見かけることがあります。あたふたとあわてふためく人。ミスが多いという特徴があります。「XXがトラブルになりました。XXXが原因かもしれません。あれっ、でもXXXはXXXのはずだなあ。そういえば、XXXを確認したほうがいいかもしれない。あれっ、ああ、そうか・・・あっ、でも・・・・」「まず、落ち着け」「すみません・・・」こういう人が、やるべきことや課題を忘れて、目の前のできごとに振り回されると、本来やるべきことができず、なかなかトラブルが収束しないことがあります。こういう人が言う事実確認は以前も紹介した傍証をとると良いでしょう。

・非常時しか燃えないタイプ

トラブルが起こるまでは、寝ているかのようにパフォーマンスが優れませんが(本当に寝ている人も居ます)、トラブルが起きると、目が爛々と輝いて、ものすごいスキルを発揮する人です。私もこのタイプなんでしょう・・・

・するどい一撃ができるタイプ

静かにしているが、ここぞというポイントでクリティカルな質問や指摘をする人もいます。こういう指摘は簡単にできるものではありません。普段発言しないからと言って、メンバーからはずしたりせず、トラブル対応のメンバーに入れるようにしましょう。

・ぽつんと居る人

私が面白いなあと思うのは、この「ぽつんと居る人」です。トラブル時、私は大体余裕がないため、ちらちらっとしか見ることはできませんが、こういう人が、何かできないかなあと思って、復旧予定アナウンスなどをメンテしてくれたりします。会議で「XXXをやろう。だいたい3時間くらいかかるね」と話をして、作業にとりかかると、なぜか告知のページに「復旧予定は3時間後」などと載ったりするのです。愛すべき役割だと私は思います。

・ユーザーとしてジャッジができる人

私は「当時最善であった」といえるのであれば、仕方ないではないかと思います。ただ、「当時最善であった」と言うためには、日々の修行(例:アーキテクチャの理解など)も要りますし、トラブルの時も、手を尽くす必要があります。「成功することが分かっている対策案」に「了承」をするのがジャッジではありません。「ユーザーとしてジャッジができる人」とは、「関係者が手をつくしても、XXとXXXは分からない。でも、業務復旧を最優先してこのタイミングで判断する。こういう理由で、この策を最善と判断する。みんなついて来い」というリーダーシップのある人です。このリーダーシップがトラブルを解決すると私は思います。ベンダーとしても、こういう人が居る場合、安心できます。

なお、今回登場している人物像は、共通するキャラクターであるため、具体名はありません。
[ 2008/08/17 02:22 ] DBA | TB(0) | CM(0)

トラブルシューティングのコツ その4

今回は現場のためのTIPS集です。特にDB管理を仕事としている人、インフラエンジニアにとって有効な方法を解説します。

まずシステムが処理できているか、できていないかを確認できる手段の準備です。しかも、日ごろから使えるものです。Oracleのv$sysstatビューにはexecute countがあり、そのビューにはインスタンス起動後のSQL実行数がカウントアップされています。その数値がいつもどおりに増えていれば、SQLの処理数(ほぼ業務処理量)としてはいつもどおりと言えるはずです。累積値は見づらいので差分を自動的に計算するスクリプトを仕込むとよいでしょう。

もう1つはDBサーバー上でつまっているかどうかの確認となる、処理中のSQL数確認です。これはOracleであれば「v$sessionの各セッションが
Activeというステータスか」でおおむね確認できます。DBサーバー上で詰まれば、処理中(Active)のままになりますから、どんどんActiveなセッションが積みあがっていきます。このActiveなセッションが積みあがるという現象は、APサーバーのスレッドなどでも使えます。このようにAPサーバーやDBサーバーでの処理数やActive状況を把握すると、どこがおかしいのか手早く確認できます。うまく閾値監視の仕組みをつくれば、トラブルから数十秒で検知できます(いくつかの過去実績もあります)。

次は再起動のためのスクリプトを用意しておくことです。特にクラスタ構成の場合には、クラスタやネットワークのアドレスの切り替え、業務処理の再開まで含めたスクリプトが必要です。現実問題として、原因不明時に一番効果が高いのは、再起動やクラスタの切り替えだからです。

これで駄目だとすると、原因追求が必要なトラブルということになります。サポート窓口に連絡すること、および、ベンダーが提供しているナレッジの検索が有効なはずです。現場でのコツは、何らかの方法でメッセージをすぐに伝える(取り出せる)方法の用意です。セキュリティ上、本番機のログを簡単には持ち出せない会社が多いと思いますが、緊急時用の手段は残しておくべきです。画面を見て、メモして、それを他の画面で入力するという現場もありますが、あまりにももったいないです。

最後は、アーキテクチャの知識を持つことです。「言うは易し」であることは承知の上ですが、トラブルシューティングするために、アーキテクチャの知識は役に立ちます。たとえば起動しないというトラブルが起きたとして、アーキテクチャと起動の順序を知っていれば、どの段階まで進んでいるのか、原因はどこら辺にあるのかがわかります。エラーがおきても、「このエラー箇所はXXXのはずだ」「XXXとXXXが関係するから、そこをチェックしよう」といったように対処を進めることができます。

まだまだトラブルシューティングのコツは続きます。
[ 2008/08/14 00:18 ] DBA | TB(0) | CM(0)

トラブルシューティングのコツ その3

トラブル対応では、何に時間がとられると思いますか?
実は、確認や調査、リトライ(何度も試す)、オペレーションの事前準備に時間がとられます。

たとえば、システムで処理ができなくなったとします。
皆さん、どうしますか? 調査するポイントが決まっていない場合、
試行錯誤しますよね? 本当に使えないのか、紛糾したりしませんか?
やみくもにサーバーやソフトを再起動したりしませんか?

まず、外部からシステムにアクセスしてシステムが生きているか確認することをお勧めします。携帯や通信カードを使って、一度インターネットを継由するようにアクセスしてみて、サービスが生きているかどうか確認する方法です。エンドユーザーと同じ経路でシステムが使えるかどうか確認できるため、目の前のサーバーがトラブルになっていた場合でも、かなり有効です。

ここでポイントです。時刻を記録します。理想は秒までですが、
分まででもかまいません。あとで、お客様や上長、監督官庁に報告する場合などにものすごく役に立ちます。

さて、DBが起動しないというトラブルだったとします。皆さん、起動のコマンドを叩いてみますよね? 成功しなかったとしても、もう一度やってみますよね?駄目ならOSを再起動したりしませんか? 最近、何を変更したかを思い出してみて元に戻して起動を試みたりしませんか? またはエラーメッセージから見てデータベースを構成しているファイルをちょっといじって起動を試みたりしませんか? このようなことをするため、DBが起動しないトラブルでも、最初の起動しないという確認だけでも1時間や2時間かかってしまいます。
この話をすると、お客様の上層部の認識(うちの現場はすぐに対応できるはずだ)と大きなずれがあることがわかります。

どのログを見れば良いか把握していますか? 「へえー。こんなログがあるんだ」と思っているようでは迅速な調査はできません。どんな情報がどのログファイルに出るのかは事前に確認しておきましょう。
ログの監視という意味では、運用監視ソフトを使うべきです。監視ソフトは広く使われていますが、監視ソフトが対象としないログファイルの存在、およびメッセージです。たとえば、Oracleクラスタソフトに対応していない監視ソフトではログファイルに対応していないはずです。また、Oracleに対応している監視ソフトであっても、キーワードの引っ掛け方が、”ORA-”で始まるものだけとなっているため、”WARNING”といったメッセージはひっかからないのです。

では、時間を短縮するにはどうすれば良いのでしょうか? まずは、対応手順書を作りましょう。どのようなトラブルを想定し、それに対してどのように対応するのかという一連の手順書です。お勧めは、エラーの検知から、切り分け、対応までがつながるものです。

ただ、対応手順書は3つの理由から使われにくいと思います。
1つ目は、メンテされない手順書で、実質的に使えなくなっているケースです。
2つ目は、訓練をしていないため、そのとおりに動けない/動くのに時間がかかるケースです。
そして、3つ目は人の心理です。トラブルのとき、人は普段使い慣れている道具に無意識に頼るのです。トラブルで慌てているときに、普段気にもかけていない対応手順書の存在を思い出せるでしょうか? また、ページをめくっていちいち理解しようと思うでしょうか? このような事情により、せっかく作っていた現場でも対応手順書を使っていなかったトラブル現場をいくつも知っています。

このような話は、他所のことで、うちはまともだから大丈夫と思っているとしたら大違いです。有名大規模システムですらこのような状況なのです。
「ではどうすれば?」については、完全な解はないと思いますが、役に立つTIPSを次回ご紹介します。
[ 2008/08/10 14:41 ] DBA | TB(0) | CM(0)

トラブルシューティングのコツ その2

今回のテーマは「信頼される火消し」です。

外部からの飛び入り火消しという想定で話をします。
自プロジェクト以外で大トラブルが起きてしまい、
急に声がかかったという想定です。
ただでさえ難しいトラブル対応に、部外者というハンディが
ついている状況です。「何しにきたの?」という目線や
「事情も知らないくせに、言いたいことを言うんだろ?」という
言外のメッセージが痛い状況です。

アプリケーションについては、作成したベンダーしか
手が出せませんが、インフラは違います。インフラに関する
知識があれば、外部の人間でも火消しとして活躍する余地はあります。

私はインフラの火消しに求められる姿勢(とコツ)は、次のとおりだと思っています。
・情報提供から入ること
・進んでいるという感覚を持たせること
・仕切れること(課題を整理できること)
・選択肢をいくつか提示し、選んでもらうこと

外部から駆けつけて、まず行うべきは「情報をできるだけ集めること」
ではありません。まずは可能な範囲での信頼を得ること、および、
「こいつはできそうだ」という評価を得ることです。

関係者がかけずり回っている中、「情報をくれくれ」と言っても
迷惑になるだけです。それよりは、すでに現場に存在するデータや
状況証拠から「XXXという事象が起きているので、原因はXXかXXのはずです」
とか、「XXXというデータがあるので、XXXXが疑われます」という形で
すでにトラブルシューティングしている人に協力すべきです。
私は、この情報提供による協力を拒否されたことがありません。
情報を提供されることについては、人はリスクを感じないからでしょう。
機会があったらやってみてください。

次は、「進んでいるという感覚を持たせること」です。
トラブルの現場は、混乱し、紛糾しているものです。そんな中、
全体像を描き、「これは終わった、次はこれをやればいい」とか
「この可能性は無くなった」といったように話を進められる人は
救いの神様に見えます。筆者は昔、
「この製品はこういうアーキテクチャなので、このデータ(グラフ)の形と、
このデータを合わせると、こういうように現象のつじつまが合いますよ」と
情報提供をしたところ、担当者の顔がぱっと明るくなり、「なるほど、
なぞが1つ解けました!」となったことがあります。
このように「進んでいるという感覚を持たせる」と、信頼を得ることができます。

次は、「仕切れること(課題を整理できること)」です。
ある程度、信頼を得たあとは、全体としてトラブルシューティングを
進められるかという壁にぶつかります。たとえば、インフラのトラブルで
あってもアプリ部隊の協力が必要なケースは多くあります。
むだにミーティングを繰り返してもらちはあきません。
「全体像はこうだ。だからXXさんがこれを調査して、XXさんがこれを調査する。
1時間後に全員集合。解散!」と、このように仕切ってしまいましょう。
なお、課題が複数ある場合は、全ての課題が進むように整理してあげましょう。
あとになって「やばい。XXという課題を忘れてた!」という事態を防ぐためです。

最後は、「選択肢をいくつか提示し、選んでもらうこと」です。
めでたく原因がわかり、対策をうつことになったとします。
もしくは、原因がわからないけれども、暫定策をうつことになった
とします。その場合に必要なのは、メリットだけではなく、リスクも含めて、
いくつか案をユーザーに提示して選んでもらうことだと思います。
これはユーザーの立場に立つと、「ベストを尽くした。自分たちで
コントロールした」ということになりますし、ベンダーの立場に
立つと、「きちんと説明した上で、関係者の合意の上で進めた」という
枠組みを作ることでもあります。
つまり、両者のアカウンタビリティ(説明責任)を満たすことになります。
皆さん(関係者)の身を守ることにもつながります。

トラブル時には、役職といった上下関係はゆらぎます。
そして、実力勝負になります。つまり、若手でも
実力があれば、意見も通りますし、活躍することもできます。


若手だけれども、大きな仕事をしたいという人は
火消しを目指してみるのもいいかもしれません。
[ 2008/08/05 21:02 ] DBA | TB(0) | CM(0)

トラブルシューティングのコツ その1

火消しとして、数多くのシステムトラブルを見てきました。
新聞に載るようなもの(載ったもの)も多く見てきました。

トラブルにおいてすべての情報が集まるとは限りません。
また、伝言ゲームのように情報が伝えられた結果、正しくない情報に
振り回される現場も多いです。
「XXXがエラーになったかも」 -> 「XXXがエラーになったに違いない」
-> 「XXXがエラーになった。なんとかしろ」という具合です。

トラブル時にパニックになる人たちもいます。
そういう人たちは、やるべきことを忘れてしまったり、
情報を誤認識したり、伝え間違えたりします。

また、事実だけを伝える人ばかりではなく、”感想”や”疑い”なども
伝えてしまいます。きっと言いたいんだと思います。

仮に情報が正しく伝えられていたとしても、
複数の原因と思われる候補が見えることもあります。

では、どのような点を注意してシューティングするのが良いのでしょう?
私はトラブル時の情報の見極めについては、次がポイントだと思っています。
・本来の担当者であり、事実に基づいて言っているか?
・傍証はあるか?
・どれが原因だとすると、他の原因も引き起こすか?


「本来の担当者であり、事実に基づいて言っているか?」
 これは伝言ゲームを防ぐこと、および”感想”や”疑い”を取り除くためです。

「傍証はあるか?」
 照らし合わせることにより、おかしいかどうかが判ります。

「どれが原因だとすると、他の原因も引き起こすか?」
 複数の原因候補が存在することも多くありますが、まったく独立したトラブルがたまたま複数ということはまずありません。何かが何かを起こしたと考えるのが、妥当です。仮にこの推理が外れたとしても、第一の候補を対処したことになるため、トラブルシューティングとしては一歩前進です。

たとえば、システムがスローダウンしたとして、次のような原因候補が見つかったとします。皆さんならどうしますか?

候補1:SQLのレスポンスが悪くなった
候補2:OSのページング回数が大きく増えた

こういうときに、SQLのレスポンスが悪くなったからといって、
ページング(メモリ要求に関係します)が増えるわけないよな。
でも、ページングが増えるとOS上の処理が遅くなるから、その
結果、SQLが遅くなることはアーキテクチャ上ありえるよな。と
考えます。


システムトラブルシューティングのコツは数多くあるので、
何回か続けて書いてみようと思います。
[ 2008/08/01 22:48 ] DBA | TB(1) | CM(0)
プロフィール

odakeiji

Author:odakeiji
小田圭二 日本オラクルのテクノロジーソリューションコンサルティング統括本部においてデータベースのコンサルタントをしている。今までのキャリアでは、社内教育部隊で、データベースやOS、ネットワークを教える経験を5年ほど積んだり、コンサル部門で主にDB(インフラ含む)のコンサルを10年程度経験した。また、コンサルタントとして、主に大規模ミッションクリティカルシステムを担当。社内では”火消し”とも呼ばれ、システムトラブルの火消しをいくつも担当していたこともある。
ポリシーは、「OracleもOS上で動くアプリケーションにすぎない。だから、OS、ストレージ、ネットワークを学ぶべき。アーキテクチャから考えろ」。
スキル面の興味は、アーキテクチャ、DBA、インフラ技術、教育、コンサル手法など。
本ブログのポリシーは「週に1回、DBAやインフラ担当者の役に立つ記事を書きたい」です(守れるだけ、守りたい・・・・)
なお、本ブログにおいて示されている見解は、私自身の見解であって、オラクルの見解を必ずしも反映したものではありません。ご了承ください。

私の主な著書の紹介です。もしよかったら、お役立てください。他にもオライリーなどがあります

●「絵で見てわかるOS/ストレージ/ネットワーク データベースはこう使っている」小田圭二 著
私のポリシーである”DBMSもOSの動くアプリケーションに過ぎない”に基づいて、OSとDBMSの関係、ストレージとDBMSの関係、ネットワークとDBMSの関係、を解説した珍しい書籍です。DBを学んでひと段落したら、DB使いもインフラ全体を意識しなければなりませんが、そのような人にお勧めです。企業ユーザー向けのIT本としては、2008年度翔泳社No1だとか(最後は出版社談)。

●「絵で見てわかるOracleの仕組み」 小田圭二 著
教育に携わる者としての私の思い「丸暗記するな。アーキテクチャを知るべき。絵で説明すべき」を具体化した、Oracleの入門書です。Oracle初心者向きですが、Oracleの基礎となる部分の動きを解説しているため、バージョンに依存せずに何年先でも使えます。逆に、本書の内容を理解せずに、ひたすら丸暗記すると応用力が身につきません。この本を読むだけで何かできるようになるわけではありませんが、アーキテクチャを身につけて、本当の技術力を身につける第一歩として欲しいと思っています。

●「44のアンチパターンに学ぶDBシステム」 小田圭二 著
本書は、企業のDBシステムの設計/構築から運用管理、プロジェクト管理までの各フェーズにおけるトラブル(失敗)事例について、アンチパターン(べからず集)とその回避策/防止策として解説するものです。チェックリストとして使っていただいても構いません。分かっていてもアンチパターンは避けられないことも多いものです(政治とか)。そういう方には、同じ仲間は多いのだなと再認識していただくための一服の清涼剤としていただければと思います。

●「門外不出のOracle現場ワザ」 小田圭二 他 著
一番最初に出た本です。結構とがった内容を扱っています。
・パフォーマンス分析の考え方(私の担当)
・性能テストや障害テストの仕方、設計の注意点(主に私が執筆)
・コストベースオプティマイザ(10gベース)のアーキテクチャ
・コネクションプーリング
最新のOracleの内容は含んでいませんが、今でも性能の考え方やオプティマイザの考え方は使えるはずです。オプティマイザをここまで解説している本を私は知りません。

●「続・門外不出のOracle現場ワザ」 小田圭二 他 著
「続」の名前の通り、次に出た本です。ちょっと尖り過ぎたかもしれません^^; でも本当に使う内容を選んだつもりです。一流になりたい・他の人と差をつけたい人にお勧めでしょうか。
・性能の良いSQLの書き方
・文字化けの仕組み
・障害(特に性能やハング)の分析・対応方法(私が執筆)
・障害をリアルタイムに分析・対処する方法(私が執筆)
・オプティマイザの使い方ノウハウ
・アップグレードのノウハウ

●「データベース」小田圭二 他 著
私にしては堅い本です。なんせ、共同執筆者が大御所の國友義久先生です。階層型DBMS、ネットワーク型DBMS、リレーショナル型DBMS、XMLDBMS、OO(オブジェクト指向)DBMS、DBMSの持つ機能、DBMSのセキュリティ、データベースの著作権、監査、モデリング、正規化といった内容を網羅しており、深い記述は無いものの、DB技術全体を抑えるのに向いている一冊です。ある程度技術力がついたエンジニアの方が、DB全体を振り返りたい(勉強したい)というときの最初の1冊としてお勧めです。



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。