大きなデータベースで誤ったデータ更新を回避するために従うべきプラクティスは何ですか？

実稼働展開の前の一般的なアドバイスは、最初にDBをバックアップすることです。このように、新しい更新に潜在的なデータ損失または論理データ破損につながる可能性のある問題がある場合、古いレコードを比較して修正するためのバックアップがまだあります。

ただし、DBサイズが数GBになるまでこれはうまく機能します。DBのサイズが大きくなると、バックアップの完了に長い時間がかかります。コード展開の論理的な問題による論理データの破損を回避するために、このような状況で従うべきベストプラクティスは何ですか？

私たちのソフトウェアアップグレードのために顧客のために運用データベースの更新を定期的に処理した人として、エラーを最小限に抑える最善の方法は、できるだけ簡単に更新を行うことだと言います。

特定のレコードではなく、すべてのレコードに変更を実行できる場合は、望ましいです。

つまり、状態の変更が必要なレコードのIDのリストが提供されている場合、プログラムのコンテキストで更新が行われている理由を自問する必要があります。更新する必要がある10個のレコードのうち、テーブルには 10個の要素しかない可能性があります。したがって、概念的にはすべてのレコードの状態を更新するだけかどうかを自問する必要があります。

挿入できる場合は、それが望ましいです。

レコードを追加する行為は自己完結型です。これにより、レコードを追加することによる副作用は1つしかありません。それは、以前には存在しなかったレコードの存在です。したがって、存在しないはずのレコードを追加しない限り、問題はないはずです。

削除を回避できる場合は、それが望ましいです。

削除を実行している場合は、バックアップなしでは回復できないデータを削除します。可能であれば、物理的にレコードを削除するのではなく、状態を変更してレコードを無効にできるようにデータを整理してください。過剰なデータはパーティションに入れることも、問題がないことが確認できたら後で削除することもできます。

一貫した更新ポリシーを使用します。

レコードを更新する必要がある場合、次のいずれかが発生する可能性があります。

1. あなたの記録は存在しません。
2. レコードは存在しますが、すでに変更されています。
3. あなたの記録が存在し、変更が必要です。

計画どおりに進まない場合の行動方針を決定するポリシーが必要です。簡単にするために、特定のテーブルだけでなく、全面的に一貫性を保ち、このタイプのあらゆる状況でこのポリシーを適用する必要があります。これにより、後でデータを簡単に回復できるようになります。一般に、私のポリシーは、後で再実行できるようにスクリプトを記述することです。スクリプトが失敗した場合、適切な調整を行って再実行できることを知っておくと便利ですが、最適なポリシーを自由に選択できます。

バックアップ

これは、実稼働環境で更新を実行する前にバックアップを実行することを決して許しません！バックアップがあっても、バックアップを使用しなければならないのは失敗だと思います。最悪の場合でも、データを失う可能性はありません。

結論

常に自分のやり方でできるとは限りません。テーブルスキーマはユーザーが決定することはほとんどないため、実行が予想される更新の種類は複雑でリスクが高くなります。ただし、問題について何か言いたいことがある場合は、これらのポイントが重要なリスクなしに簡単に更新を行うため、これらのポイントを念頭に置いておくと役立ちます。

がんばろう！

その時点で、スナップショットをサポートする商用グレードのDBシステムを使用する必要があります（オラクルはFlashbackと呼んでいます）-それはまさにそのためのものです。

とにかくバックアップの概念が必要であることを覚えておいてください-データが増えても、バックアップが難しくなるので、バックアップを落とすわけではありません。まったく逆です。たとえば、自動フェイルオーバーを使用したレプリケーションに基づいた、ある種の連続バックアップが必要です。

これは大規模な領域です-したがって、この質問はかなり短い順序で閉じられますが、私の頭の一番上ではありません（yugeデータベースの元DBAとして）：

マート/リポジトリ

更新用の個別のデータベースと、全員が使用する個別のデータベースがある場合、リスクを軽減できます。その後、さまざまなチェックが行われた後に、あるDBから別のDBにデータをコピーするだけです。マート/リポジトリは、それが時々記述される方法ですが、プライマリ/セカンダリ、マスター/スレーブなどがあります。

ソースコード

変更できるものすべてについて、データの更新方法に関連するソースコードを用意します。これらの数はDBごとに異なりますが、ユーザー、ロール、データフィード、コードモジュールなどごとに1つある場合があります。

作成/更新日

問題が発生した場所を追跡するときに非常に役立つのは、すべての行のデータを作成および更新することです。次に、更新された行が一目でわかります。

ETL

データベースの更新がデータファクトリの一部として参加する場合、フラットファイルから以前のヴィンテージを復元できる場合があります。

バックアップ

もちろん、完全バックアップには多くのスペースが必要ですが、通常のシナリオでは、完全バックアップを定期的に（たとえば、毎週）実行し、部分的なバックアップをより頻繁に（毎日など）実行します。

ポイントインタイムリカバリ

使用しているRDBMSに応じて、一部のポイントインタイムリカバリがサポートされます。これにより、良好な状態が判明した時点までロールバックできます。ただし、これには大量のストレージが必要であり、どれだけ前に戻りたいかによって増加します。

監査

監査テーブルを作成すると、行を更新したユーザー（またはその対象）がわかります。これにより、調査の開始点として適切です。

歴史

一部の重要なテーブルでは、必要に応じてデータを復元できるように、更新時に適切な行のコピーが取得されます。

データ検証

データが保存される前に、基本的なデータ型チェックに加えて、データの基本的な検証チェックが実行されていることを確認します。

参照整合性

参照整合性は特効薬ではありませんが、データが適切に構造化されていることを確認するのに役立ちます。

多くの場合、「1回限りの」更新を行う場合、実稼働環境のバックアップを取り、テストサーバーに復元します。次に、一連のテストを作成し、ワンショットを実行します。テストによりデータが変更されたことを確認し、更新が成功することを確信し、期待どおりにデータを変更します。これは、ドライランまたは試運転と呼ばれます。これを行うことをお勧めします。

これにより、誰もがワンショットが成功するという良い感覚が得られます。データは試用日から更新されるため、100％を保証することはできませんが、自信と成功要因を高めます。これにより、本番環境のコピーを使用しているために発生する問題についての本当のアイデアも得られます。何らかの理由で更新が失敗した場合、必要に応じて復元の前にいつでもバックランに進むことができますが、ドライランの問題を見つけて修正する必要があります。

データベース全体を取得できない場合（本当に大きい場合）、より小さいサンプルサイズをエクスポートして、実際のデータに対して更新（小さなドライラン）を実行してみてください。テストが可能な限り完全であることを保証するために、可能であればデータセット全体を使用することをお勧めします。