前回SQLServerのダウンタイムまたはデータ損失が発生したとき、何が起こりましたか？
これは、ダウンタイムやデータ損失に対処または制限する方法についての質問ではありません。私はそれについてすべて知っています。災害復旧に関するPASSポストコンの「ストーリー」セクションをまとめています。マイクロソフトでの日々よりも最近の印象的なストーリーをいくつか共有できるようにしたいと思います。過去3年間、いつでも私の腐敗デッキを提示しているのを聞いたことがあります。
ですから、これは一種の告白だと考えてください（私は赦免を提供することはできませんが:-)そしてもちろん、ここで語られるすべての話は、勇気があり、したいのでない限り、友人や同僚、または前の会社で起こりました'大騒ぎ。私は判断を下したり、答えを嘲笑したりせず、求められた場合にのみ洞察を提供します。
本当に、アイデアは誰もが間違いや失敗から学ぶことです。私が聞いた話の例として、 失敗と腐敗の悲しい話 を参照してください。
これがこのフォーラムで機能するかどうかはわかりませんが、試してみる価値はあります。
ありがとう！
PS私の汚職セッションを見たことがなく、話を聞いたことがない場合、それは昨年のTechEd IT Proでの＃2セッションであり、彼らはそれをビデオ録画しました：See TechEd：80分のビデオ腐敗サバイバルテクニックのプレゼンテーション 。ブログの投稿は、ダウンロードして遊ぶことができる多数の破損したデータベースとデモスクリプトにリンクしています（私たちのサイトには広告などはありません。情報だけです）。
古典的な「WHERE句を含めるのを忘れて、トランザクション内にいなかった」更新/削除ステートメント以外は？
ラボ環境では、1台のサーバー上のデータベースをオフラインにし続けました。 MDBファイルが存在していたドライブが消え、SQLが一時的に中断し、ドライブが再表示されたときに（通常は数分後に）データベースを手動でオンラインに戻す必要がありました。1週間の大部分を運用に費やしました。ドライブがなくなった理由を判断するためにみんな。これはSAN上のLUNであり、スイッチへの冗長パスがありました。
簡単に言うと、ファイバーケーブルがスイッチのポートに完全にクリックされておらず、最近のメンテナンス中にケーブルがずれていたことが判明しました。それらは、ラックドアとそれが閉じるくぼみの間の空洞に置かれました。ドアが閉まると、プラグが外れて接続が切断されるのに十分なだけケーブルが引っ張られました。ドアはロックされておらず、自由に揺れるだけでした。ラボのドアを開閉すると、空気の動きによってラックのドアが前後に揺れました。
私がいた小さな会社では、基本的なSharepointサービスサイトをロールアウトしたばかりでした。私たちは小さかったのですが、従業員は世界中にいたので、SharepointのWebアクセスとMS Officeの統合は素晴らしかったです（他のすべては吸い込まれましたが、それは別の話です）私たちはお金があまりなく、小さかったので、シンプルに保ちました、1つのSQL RAIDを備えたサーバーとRAIDを備えた1つのWebサーバー。約1週間と5ギガのプロジェクトデータがSQLボックスで電源に障害が発生しました。新しいものの配達を待っているダウンタイムの日がありました。バックアップを別のサーバーにロールバックすることもできましたが、SharePointを初めて使用したため、DR計画はまだ開発中であり、電源が到着するのを待つのと同じくらい、すべてを把握するのに時間がかかると考えました。 、そして新しい電源装置ができたらすぐにオンラインになり、フェールバックする必要がないことがわかっているので、SharePointを台無しにするリスクを冒さずに待つことを選択しました。
人為的エラーにより、2テラバイトのMS-SQLデータベースのすべてのインデックスが削除されました。彼らはすぐに気づき、インデックスを再構築することにしました。残念ながら、そのプロセスには48時間以上かかりました。後から考えると、テープから復元する方が簡単でした（そしてダウンタイムがはるかに少なくなりました）。
数年前、自動車金融会社で働いていたときに、展開中に1台のデータベースサーバーを停止しました。それは私が私の職業生活にかかわっている主要な失敗の1つですが、私はその問題からきしむようにきれいに出てきました。
SQL 2K（SP3）からSQL 2K（SP3）への一方向のトランザクションレプリケーションがありました。レプリケーション中にテーブルが含まれる場合は、デプロイメント中にレプリケーションを破棄して会社のポリシーとして再構築する必要があります。ある時点で、SP4にアップグレードすることが決定され、すべての製品サーバーに変更が加えられましたが、アップグレード後にレプリケーションは再構築されませんでした。
数週間後、私のプロジェクト（私はデータベース開発者であり請負業者でした）が展開の予定であり、展開をサポートするデータセンターにいます（通常、展開は深夜に行われます）。レプリケーションが停止し、プロジェクトの展開が成功し、レプリケーションの再構築が2時間後に失敗しました。 SCM担当者は、午前3時に完全なエラーメッセージを読まずに再起動しましたが、2時間後に再び失敗し、SLAに近づいています。午前5時にマネージャーに電話する必要があることはわかっていましたが、問題をすべてのレベル/グループにエスカレーションするために多くの電話がかけられました。
DBAグループが午前6時に問題を引き継ぎ、トラブルシューティングの手順から私は暗闇にさらされました。マネージャーは、スクリプトが失敗の原因であるかどうかを確認するために、2時間に3回私に尋ねました。私の頭は一線を画していた。 4人のProdDBAと2人のマネージャーがこの問題に熱心で、MSFTでチケットが発行されました。午後3時を過ぎても、実際に何が起こったのかを理解するまで問題は解決しませんでした。ある記事（表）では、列に一意のインデックスがありましたが、データ品質が良くありませんでした。 ''とnull値があり、残りの数百万のレコードは正当な値でしたが、一部のレガシーデータには疑問がありました。 SP4のアップグレード後、SQL Serverはサブスクライバー側で ''とnull値をnullに変換しようとしましたが、一意キー/インデックス違反のため失敗しました。ビジネスグループから高レベルの許可を得た後、不良データは削除され、私はもう1年間仕事を続けることができました。
教訓：アップグレードを行う前に、すべてのプログラムをテスト、テスト、テストします。