本番データベースのデータを安全に修正する

バグが発生し、本番環境でデータを修正する必要がある場合があります。大企業の観点からこれを行う最も安全な方法は何ですか？役立つツールはありますか？この要件を推進するいくつかの考慮事項を以下に示します...

1. 誰がクエリを実行し、何を実行したかを記録する必要があります
2. 理想的には、関心のあるテーブルに対してクエリを実行するためのアクセスを短時間だけ許可する必要があります
3. クエリを実行しているものが何であれ、明示的な許可なしにSQLを長時間実行およびロックすることを許可しないために、クエリについてある程度の知識が必要です。
4. このプロセスは、DBに依存しないか、少なくともDB2、Oracle、およびSQL Serverを理解する必要があります。

私たちは、アドホックな製品修正クエリが「間違ったこと」を行うリスクを減らし、同時にプロセスにセキュリティ/音声を追加しようとしています。考えやアイデア？

本番データベースを手動で更新しないでください。

スクリプトを作成します。

トリプルチェックを行い、1人で3回行うのではなく、複数の人にそれを行わせます。

これらのスクリプトに変更後の検証クエリを含めます。

状況が許す限り、変更後の検証が実行された後、最後にロールバックされるトランザクション内の変更全体をテストします。結果に確信が持てたら、ロールバックをコミットに変更します。

それらのスクリプトをテストデータベースに対して悪心でテストします。

本番データベースに対してスクリプトを実行する前にバックアップを作成します。

スクリプトを実行します。

post-change-validationスクリプトを使用して、変更されたデータをチェック、検証、およびトリプルチェックします。

とにかく目視で確認してください。

何かがオフに思われる場合は、バックアップをオフにして復元します。

すべてが問題ないことを完全に確信し、関係する（ビジネス）マネージャーからサインオフするまで、変更されたデータを実動データとして続行しないでください。

Marjan Venemaによる回答は技術的に有効であり、可能な場合は従う必要があります。悲しいかな、Marjanは理論家、または物事をきれいに作るのが好きな純粋主義のデータベース管理者の観点から答えています。実際には、ビジネス上の制約により、物事をきれいに行うことができない場合があります。

次の場合を想像してください：

1. ソフトウェア製品にバグがあり、データベース内のデータの不整合と思われるものを検出すると動作を停止します。

2. アプリケーションのバグを潜在的に修正できるすべての開発者は到達不能であり、

3. 同社は現在、1時間あたり数千ドルを失っています（たとえば、6000ドル、1分あたり100ドルを意味します）。

4. このバグはいくつかのテーブルに影響を及ぼしていますが、そのうちの1つは巨大であり、スキーマではなくデータ自体のみに関係しています。

5. バグを回避するには、データを少し試してみてください。これには、削除と変更の両方が含まれます。

6. データベースが大きく、バックアップの取得または復元に3時間かかる場合がありますが、

7. 最後の完全バックアップは3週間前に取得されました。毎日の増分バックアップもあり、最後の毎日の増分バックアップは14時間前に行われました。

8. データベースのバックアップは信頼できると想定されています。最近を含め、厳しくテストされました。

9. 14時間のデータの損失は許容されませんが、1〜2時間のデータの損失は許容範囲です。

10. ステージング環境は最後に6か月前に使用されました。最新ではないようで、設定に時間がかかる場合があります。

11. データベースはMicrosoft SQL Server 2008 Enterpriseです。

物事を行うためのクリーンな方法は次のとおりです。

1. ステージング環境でバックアップを復元し、

2. そこに実験して、

3. 最終スクリプトを2回確認し、

4. 実動サーバーでスクリプトを実行します。

最初の一歩はあなたの会社に18000ドルかかります。3番目のステップを完璧に行えばリスクはかなり低くなりますが、極端なプレッシャーの下で作業するため、リスクははるかに高くなります。ステージングで完璧に機能するスクリプトが作成されてから、実稼働データベースが台無しになる場合があります。

代わりに、次のようにすることができます。

1. スナップショットを作成します（Microsoft SQL Serverはそれをサポートし、バックアップに1時間かかるデータベースのスナップショットを元に戻すには数秒かかります（作成するのに何もかかりません。他のデータベース製品もスナップショットをサポートすると思います）。

2. 実稼働データベースで直接実験し、何か問題が発生した場合はスナップショットに戻ります。

純粋主義者はクリーンな方法でデータベースを修正しますが、会社の2万ドル以上を無駄にしている間、時間のプレッシャーを考えると物事を台無しにするリスクがありますが、ビジネス上の制約を考慮したデータベース管理者はデータベースをある方法で修正しますこれにより、リスクを最小限に抑えながら（スナップショットのおかげで）迅速に実行できます。

結論

私は自分自身が純粋主義者であり、汚れた方法で物事を行うことは嫌いです。開発者として、変更したコードをリファクタリングし、リファクタリングできなかった困難な部分にコメントを付け、コードベースの単体テストを行い、コードレビューを行います。しかし、私はまた、あなたが物事をきちんと行い、翌日解雇される状況、または機能するクイックハックを行うことでリスクと経済的影響の両方を最小限に抑える状況も考慮します。

一部のIT担当者が、会社のために数千ドルの損失を引き起こしている一方で、クリーンさのためだけにクリーンに作業を行いたい場合、このIT担当者は自分の仕事について深い誤解を抱いています。

本番データベースのデータを安全に修正します。大企業の観点からこれを行う最も安全な方法は何ですか？役立つツールはありますか？

これは悪い習慣であり、より多くのデータの問題や問題への招待ゲートです。このアプローチを「クイックでダーティ」と説明するフレーズもあります。」ます。

本番サーバーで直接修正/更新を続けると、非常に危険です。これは、あなた/あなたの会社に大金（訴訟、悪い/汚いデータ、失われたビジネスなど）を犠牲にするからです。）を

ただし、バグが存在するため、修正する必要があります。事実上の業界標準は、上のパッチ/（デプロイメントスクリプト）を適用することであるステージング（PRODデータベースの最新のコピーとプリプロダクション環境）と修正を確認するために、データアナリスト/ QAをしましょう。同じスクリプトをバージョン管理する必要があります問題を回避するには、し、Prod環境に適用するます。

この関連記事で言及されているいくつかの優れたプラクティスがあります - ステージングデータベースの優れたプラクティス

見栄えの良い参照のセットは次のとおりです。

• 修正されたバグを本番環境にどれくらい早く取り込むことができますか？
• ソフトウェア開発コストのピラミッド
• テストとバグ修正にどれだけの時間を割り当てる必要があるか

ほとんどの組織では、ライブ環境でデータを更新する作業を常に行っていましたが、これは通常、DBAなどの肩書きを持つアクセス権を持つ小さなグループによって行われていました。更新は少数の人々のみが行うことができるため、少なくともデータに精通し、したがって問題のリスクを軽減する（排除はしない）可能性があります。

更新スクリプトを作成する人は、テストで（他の回答に従って）そうし、非技術者（システムを知っている人、および上級の権限を持つ人）から、機能が「再び」正しいように見える深刻なサインオフを取得します独自の妄想テストに加えて。スクリプトとデータは、実稼働に移行する前に、テスト時に別の技術者（多くの場合、私が言及したDBAの役割）によって個別に検証されます。結果は予測値と照合されます（すべてのシナリオで一意ですが、多くの場合、行数など）

私が働いていたある会社では、バックアップを取ることは現実的なオプションではありませんでしたが、更新されるすべての行は、更新前に参照用にテキストファイルに書き出され、誰もが参照する必要がある場合は更新後に再度行われました。スクリプトとこのデータは、適切に編成されたデータ変更ログに保存されました。

すべてのビジネスはユニークであり、一部のデータを更新する際のリスクは他のデータよりも明らかに大きいです。

人々がこれらの更新を行うためにフープを飛び越えなければならないプロセスを持つことにより、人々がこれを最後の手段として扱い、このようなものの周りに健全な「ダブルチェック、トリプルチェック」態度を作りたい文化を促進することを願っています。

他のサーバーに存在しないProdのデータを修正する必要がある場合があります。これはバグだけでなく、クライアントが送信したファイルからのデータのインポートが原因である可能性があります。これは、システムにハッキングした誰かが原因の問題によるものです。または、不正なデータ入力によって引き起こされた問題から。データベースが大規模であるか、時間が重要な場合、最新のバックアップを復元してdevで修正する時間がありません。

最初の防御（およびエンタープライズデータベースなしではできないもの）は監査テーブルです。これらを使用して、不正なデータ変更をバックアウトできます。さらに、データを以前の状態に戻し、監査されたデータを元に戻す必要があるずっと前に他のサーバーでテストするスクリプトを作成できます。唯一のリスクは、元に戻す正しいレコードを特定したことです。

次に、本番環境でデータを変更するすべてのスクリプトには、次のものが含まれている必要があります。

それらは明示的なトランザクション内にあり、TRY Catchブロックを持っている必要があります。

変更前の状態を確認した後、変更をロールバックするために使用できるテストモードが必要です。変更が正しいことを確認するために、変更が行われる前から選択されたステートメントがあり、変更後に1つ実行される必要があります。スクリプトは、処理された行数が表示されることを確認する必要があります。この事前設定の一部は、断片を確実に完了させるテンプレートに設定されています。変更用のテンプレートは、修正を記述する時間を節約するのにも役立ちます。

変更または更新するデータが大量にある場合は、バッチごとにコミットするバッチで実行するスクリプトの作成を検討してください。100万件のレコードを修正している間、システム全体をロックアップしたくありません。修正するデータが大量にある場合は、実行前にDBAまたはパフォーマンスチューニングに慣れている人がスクリプトを確認し、可能な限り営業時間外に実行するようにしてください。

次に、本番環境で何かを変更するすべてのスクリプトがコードレビューされ、ソース管理に入れられます。それらのすべて-例外なく。

最後に、開発者はこれらのスクリプトを実行しないでください。これらは、dbasまたは構成管理グループによって実行される必要があります。どちらも持っていない場合、技術リード以上の人だけが製品を実行する権利を持つべきです。prodで物事を実行する人が少ないほど、問題の追跡が容易になります。スクリプトは、単純に実行されるように作成する必要があります。ハイライト部分はなく、一度に1ステップずつ実行します。where句を強調表示するのを忘れたときに、人々を困らせることが多い強調表示の要素です。

実稼働データベースの実行中にデータを何度も更新しました。上記の回答に同意します。これは決して標準的な操作手順ではないということです。

それはまた高価です（お互いの肩越しに見て、おそらく2つまたは3つについて話し合うでしょう）

そして、黄金律：常にselectステートメントを作成して、update / delete / insertステートメントを実行する前に何が行われるかを示します

チーム内の他の2人によって施行されている黄金律！

re：MainMaの答え...

ソフトウェア製品にバグがあり、データベース内のデータの不整合と思われるものを検出すると動作を停止します。

• それが「バグ」だとどうしてわかるのですか？データは、ソフトウェア製品開発者がレイアウトした規則に従って矛盾しています。

アプリケーションのバグを潜在的に修正できるすべての開発者は到達不能であり、

同社は現在、1時間あたり数千ドルを失っています（たとえば、6000ドル、1分あたり100ドルを意味します）。

• 明らかに、100ドル/分の損失は、有能な開発者が間違いを修正し、データベースの復元を支援するために戻ることを保証するために、会社の経営者にとって十分に重要ではありません。

このバグはいくつかのテーブルに影響を及ぼしていますが、そのうちの1つは巨大であり、スキーマではなくデータ自体のみに関係しています。

• すべてのデータベースの問題は、スキーマを「懸念」します。この問題を解決する方法は、スキーマの設計方法によって決まります。

バグを回避するには、データを少し試してみてください。これには、削除と変更の両方が含まれます。

• それがステージングデータベースの目的です。実稼働環境の完全なオンラインバックアップを作成した直後に、実稼働データベースから「破損した」データを再入力する必要がある場合があります。

データベースが大きく、バックアップの取得または復元に3時間かかる場合がありますが、

• その後、問題を分析し、修正スクリプトを開発し、テストし、開発者や他のDBAが支援するDBAとともにそれらを改良しながら実行できるように、すぐに開始することをお勧めします。

最後の完全バックアップは3週間前に取得されました。毎日の増分バックアップもあり、最後の毎日の増分バックアップは14時間前に行われました。

• 少なくとも毎日フルオンラインバックアップがありませんか？あなたはめちゃくちゃです。しかし、あなたはおそらくそれに慣れています。上記で開始した完全バックアップが実行されているのは良いことです。管理者は、毎日のオンラインバックアップで回避できたコストを毎分確保するようにしてください。

データベースのバックアップは信頼できると想定されています。最近を含め、厳しくテストされました。

• 優れた！その後、データベースを複数回復元する必要がない場合があります。

14時間のデータの損失は許容されませんが、1〜2時間のデータの損失は許容範囲です。

• 説明したシナリオでは、すべての賭けはオフになっています。これは「情報災害管理」状況です。この間、管理者が行うべき良いことは、将来のバックアップとリカバリの手順とリソースで回避できるコストを文書化することです。

ステージング環境は最後に6か月前に使用されました。最新ではないようで、設定に時間がかかる場合があります。

• バックアップシステムがオンラインバックアップをサポートしている場合（つまり、バックアップ中にデータベースが完全に動作する場合）、バックアップの速度低下を回避するのに十分なハードウェアリソースがある場合は、抽出を実行してステージングデータベースを同時に再配置できます。

データベースはMicrosoft SQL Server 2008 Enterpriseです。

• これらすべてを行うのは難しいが、不可能ではない。がんばろう！