database - 本番環境で発生した最悪のデータベース事故は何ですか？

Question

例：where句を追加するのを忘れたため、customerテーブルのすべての行を更新します。

それを実現し、同僚や顧客に報告するのはどのようなものでしたか？
学んだ教訓は何でしたか？

score 13 · Accepted Answer

私の最悪の過ちは

truncate table Customers
truncate table Transactions

ログインしている MSSQL サーバーがわかりませんでした。ローカルコピーを消去したかったのです...削除に約 0.5 秒よりもかなり長い時間がかかっていたときに、おなじみの "OH s ** t" が発生しました。目に見えて白く、私が今何をしたのか尋ねました。約 0.5 分後、サイトモニターが異常になり、サイトがダウンしているというメールが届き始めました。

学んだ教訓？絶対に必要な時間よりも長くライブ DB への接続を開いたままにしないでください。

バックアップからのデータの復元も午前 4 時までしかありませんでした。上司は私を気の毒に思い、夕食を買ってくれました...

score 8 · Accepted Answer

私は小さな e コマース会社で働いています。2 人の開発者と 1 人の DBA がいて、私は開発者の 1 人です。私は通常、運用データをその場で更新する習慣はありません。変更したストアドプロシージャがある場合は、それらをソース管理にかけ、正式な展開ルーチンをセットアップします。

とにかく、連絡先データベースの更新を必要としているユーザーが私のところに来て、多数の施設を一括更新しました。そこで、テスト環境で次のようなクエリを書きました。

update facilities set address1 = '123 Fake Street'
    where facilityid in (1, 2, 3)

そんな感じ。テストで実行し、3行更新しました。それをクリップボードにコピーし、本番SQLボックスのターミナルサービスに貼り付けて実行し、実行に5秒かかり、100000行を更新したので恐怖に見舞われました。どういうわけか、2 行目ではなく 1 行目をコピーしてしまい、CTRL+ V, CTRL+Eのように注意を払っていませんでした。

私の DBA はギリシャの年配の紳士で、おそらく私が会った中で最も不機嫌そうな人は興奮していませんでした。幸いなことに、バックアップがあり、ページが壊れることはありませんでした。幸運なことに、そのフィールドは実際には表示目的 (および請求/配送) のみです。

学んだ教訓は、コピーして貼り付けているもの、おそらく他のものにも注意を払うことでした。

score 6 · Accepted Answer

ジュニア DBA が行うことを意味するもの:

delete from [table] where [condition]

代わりに、次のように入力しました。

delete [table] where [condition]

これは有効な T-Sql ですが、基本的に where [condition] ビットを完全に無視し (少なくとも当時は MSSQL 2000/97 でした - どちらか忘れました)、テーブル全体を消去します。

それは楽しかった：-/

score 6 · Accepted Answer

約 7 年前、私は残業後にクライアントの DB の変更スクリプトを生成していました。ストアドプロシージャのみを変更しましたが、SQL を生成したときに、「スクリプト依存オブジェクト」をチェックしました。ローカルマシンで実行したところ、すべて正常に動作しているように見えました。クライアントのサーバーで実行したところ、スクリプトは成功しました。

次に、Web サイトをロードしましたが、サイトは空でした。恐ろしいことに、「スクリプト依存オブジェクト」設定はDROP TABLE、ストアドプロシージャが触れたすべてのテーブルに対して実行されました。

私はすぐに主任開発者と上司に電話して、何が起こったのかを知らせ、DB の最新のバックアップがどこにあるのかを尋ねました。他の 2 人の開発者が会議に出席し、バックアップシステムが整備されておらず、データを復元できないという結論に達しました。クライアントはウェブサイトのコンテンツ全体を失い、私が根本的な原因でした. その結果、クライアントに5000 ドルのクレジットが提供されました。

私にとっては素晴らしい教訓でした。今では、変更スクリプトを実行すること、および最初に DB をバックアップすることに細心の注意を払っています。私は今も同じ会社にいますが、バックアップやデータベーススクリプトに関するジョークが出るたびに、誰かが必ず有名な "DROP TABLE" 事件を持ち出します。

score 6 · Accepted Answer

効果のあるもの:

update email set processedTime=null,sentTime=null

本番のニュースレターデータベースで、データベース内のすべての電子メールを再送信します。

score 4 · Accepted Answer

一度も終了しない更新カーソルを書くことができました。2M 以上の行テーブル。この 16 コア、8 GB の RAM (2002 年に!) ボックスが実際に (ブルースクリーンの種類の) 停止するまで、ロックはエスカレートしてエスカレートしました。

score 3 · Accepted Answer

update Customers set ModifyUser = 'Terrapin'

where句を忘れました-かなり無実ですが、5000人以上の顧客がいるテーブルでは、私の名前はしばらくの間すべてのレコードに表示されます...

教訓：トランザクションのコミットとロールバックを使用してください！

score 3 · Accepted Answer

Oracleクラスター上の破壊されたノードを修正しようとしていました。

ストレージ管理モジュールに問題があったため、別のノードから構成を再インストールしてコピーする目的で、アンインストールボタンをクリックしました。

うーん、クラスター全体にアンインストールボタンが適用されていることがわかったので、システム内のすべてのノードからストレージ管理モジュールを元気に削除しました。

本番クラスター内のすべてのノードをクラッシュさせます。また、どのノードにもストレージマネージャーがないため、起動しませんでした。

バックアップに関する興味深い事実は次のとおりです...最も古いバックアップはオフサイトでローテーションされ、データベース上の最も古いファイルが何であるかを知っていますか？システムのインストール時に設定された構成ファイル。

そのため、オフサイトの担当者にそのテープを使って宅配便を送ってもらう必要があり、数時間後、すべてを再インストールして実行しました。これで、インストールファイルと構成ファイルのローカルコピーが保持されます。

score 2 · Accepted Answer

私はテスト DB で作業していると思っていたので (明らかにそうではありませんでした)、「テスト」が終了したら、スクリプトを実行してすべてのデータを、使用する標準のテストデータにリセットしました... ああ!
幸いなことに、これはバックアップが行われているデータベースで発生したため、私が何か間違ったことをしたことがわかった後、元のデータベースを簡単に戻すことができました.

しかし、この事件は、私が働いていた会社に、本番環境とテスト環境を実際に分離することを教えてくれました。

score 2 · Accepted Answer

制御不能になったすべての SQL ステートメントを覚えているわけではありませんが、1 つの教訓が得られました。可能であれば、トランザクション内で実行してください (大きなログファイルに注意してください!)。

本番環境では、可能であれば、昔ながらの方法で進めます。

メンテナンスウィンドウを使用する
バックアップ
変更を実行する
確認
何か問題が発生した場合に復元する

かなりクールではありませんが、一般的には機能しており、この手順を他の誰かに与えて、あなたが当然の睡眠をとっている夜勤中に実行することさえ可能です:-)

score 2 · Accepted Answer

私はあなたが提案したことを正確に行いました。最後に「where ID = 5」を追加するのを忘れたため、顧客ドキュメントを保持するテーブルのすべての行を更新しました。それは間違いでした。

しかし、私は頭が良くて妄想的でした。私はいつか台無しになることを知っていました。「開始トランザクション」を発行しました。ロールバックを発行し、テーブルが正常であることを確認しました。

そうではありませんでした。

本番環境で学んだ教訓: 多くの理由で MySQL で InnoDB テーブルを使用したいという事実にもかかわらず...トランザクションを尊重しない数少ない MyISAM テーブルの 1 つを見つけることができず、ロールできないことを確認してください。戻る。どのような状況でも MySQL を信用しないでください。習慣的に「開始トランザクション」を発行することは良いことです。最悪のシナリオ (ここで起こったこと) でさえ、何も害はなく、InnoDB テーブルで私を保護していたでしょう。

バックアップからテーブルを復元する必要がありました。幸いなことに、毎晩バックアップがあり、データが変更されることはほとんどなく、テーブルは数十行あるため、ほぼ瞬時に処理されました。参考までに、InnoDB 以外のテーブルがまだ存在していることを誰も知らなかったので、ずっと前に変換したと思っていました。この落とし穴に注意するように私に言った人は誰もいませんでした。私の上司もまったく同じことをしたでしょう (where 句を入力する前に Enter キーを押すのが早すぎた場合)。

score 1 · Accepted Answer

私に起こった最悪の事態は、本番サーバーがHDのすべてのスペースを消費することでした。SQL Serverを使用していたので、データベースファイルを確認し、ログが約10 Gbであったことを確認したので、ログファイルを切り捨てたいときにいつも行うことを実行することにしました。ログファイルを削除してから、再度添付しました。ログファイルが適切に閉じられていない場合、この手順は機能しないことを理解しています。そのため、mdfファイルが作成され、ログファイルは作成されません。ありがたいことに、私はMicrosoftサイトにアクセスし、データベースをリカバリとして復元して別のデータベースに移動する方法を入手しました。

score 1 · Accepted Answer

ライブデータベースを削除して削除しました。

教訓：SQLを理解していることを確認し、何かに触れる前に必ずバックアップしてください。

score 1 · Accepted Answer

これは私には起こりませんでした。私が片付けなければならなかった私たちの顧客だけです。

彼らは、RAID5 ディスクアレイ上で実行されている SQL サーバーを持っていました。これは、光るディスクステータスインジケータを備えた優れたホットスワップドライブです。緑 = 良い、赤 = 悪い。

彼らのドライブの 1 つが緑から赤に変わり、(赤) 不良ドライブを抜いて交換するように言われた天才は、代わりに (緑) 良いドライブを取り出します。まあ、これはraidセットを完全にダウンさせることはできませんでした-数分間、ある程度読み取り可能な（赤）vs使用できない（緑）を選択しました..間違いに気づき、この間に書き込まれたデータブロックを元にドライブを交換した後ディスクの同期が失われたため、時間はぎこちなくなりました）... 24時間連続でメタプログラムを作成して、読み取り可能なデータを回復し、バックアップして実行していた中規模のスキーマを再構築しました。

この話の教訓は次のとおりです... RAID5 を使用しない、常にバックアップを維持する、誰を雇うかに注意する。

私は一度、お客様の実稼働システムで重大なミスを犯しました。幸いなことに、なぜコマンドの実行に時間がかかるのか疑問に思っていたときに、自分が行ったことに気づき、世界が終わる前にキャンセルしました。

この話の教訓には、何かを変更する前に常に新しいトランザクションを開始し、結果が期待どおりであることをテストしてから、トランザクションをコミットすることが含まれます。

一般的な観察として、多くのクラスの rm -rf / type エラーは、スキーマに外部キー制約を適切に定義し、「CASCADE」というラベルの付いたコマンドから遠ざけることで防ぐことができます。

score 1 · Accepted Answer

私は Oracle の REDO ログファイル (用語? それはずっと前のことです) を理解していないことを発見し、紙のチケットから手動で再入力する必要があった 1 週間の取引データを失いました。

明るい兆しがありました。入力に費やした週末に、取引入力画面の使いやすさについて多くのことを学び、その後劇的に改善されました。

score 1 · Accepted Answer

ほとんどの人にとって最悪のシナリオは本番データの損失ですが、夜間のバックアップを実行したり、DR サイトにデータを複製したりしていないのであれば、得られるものすべてに値します!

@ T-SQL のキースさん、FROM キーワードは DELETE のオプションではありませんか? これらのステートメントは両方ともまったく同じことを行います...

score 1 · Accepted Answer

where 句を追加するのを忘れたため、customer テーブルのすべての行を更新しています。

まさにそれでした :| . すべてのユーザーのパスワード列を、コンソールに入力したサンプル文字列に更新しました。最悪だったのは、本番サーバーにアクセスしていて、これを行ったときにいくつかのクエリをチェックしていたことです。その後、私の先輩は古いバックアップを元に戻さなければならず、本当に不満を抱いている何人かの顧客からの電話に対応しなければなりませんでした。もちろん、delete ステートメントを使用したこともありますが、それについては話したくありません ;-)

score 1 · Accepted Answer

テーブル T_DAT_STORE の切り捨て

T_DAT_STORE は、私が働いている部門のファクトテーブルでした。開発データベースに接続していたと思います。幸いなことに、その日まで使用されていなかった毎日のバックアップがあり、データは 6 時間で復元されました。

それ以来、切り詰める前にすべてを修正し、定期的にマイナーテーブルのバックアップ復元を依頼して、バックアップがうまく機能していることを確認しています (バックアップは私の部門では行われていません)。

database - 本番環境で発生した最悪のデータベース事故は何ですか？

18 に答える 18

Related

Reference