そのため、2日連続で、修飾されたwhere句がなかったために、削除しようとした1行ではなく、データのテーブル全体が消去されました。
管理スタジオのオプションをすべて上下させてきましたが、確認オプションが見つかりません。私は他のデータベースのための他のツールがそれを持っていることを知っています。
20889 次
10 に答える
17
最初に WHERE 句を使用して SELECT ステートメントを記述し、それを実行して、DELETE コマンドが削除する行を実際に確認することをお勧めします。次に、同じ WHERE 句で DELETE を実行します。同じことが UPDATE にも当てはまります。
于 2008-11-11T16:33:56.940 に答える
13
[ツール] > [オプション] > [クエリの実行] > [SQL Server] > [ANSI] の下で、[暗黙的なトランザクション] オプションを有効にできます。これは、[トランザクションの開始] コマンドを明示的に含める必要がないことを意味します。
これの明らかな欠点は、コミット (またはロールバック) を最後に追加するのを忘れる可能性があることです。さらに悪いことに、同僚はデフォルトですべてのスクリプトの最後にコミットを追加します。
馬を水に導くことができます...
念のため、何かを実行する前に(DB のサイズに応じて)常にアドホック バックアップを作成することをお勧めします。
于 2008-11-11T16:24:28.423 に答える
5
ステートメントBEGIN TRANSACTIONを実行する前に、を使用してみてください。DELETE
COMMIT次に、またはROLLBACK同じを選択できます。
于 2008-11-11T16:15:35.807 に答える
3
まず、これが監査テーブルの目的です。誰がすべてのレコードを削除したかがわかっている場合は、データベース権限を制限するか、パフォーマンスの観点からそれらを処理することができます。私のオフィスでこれをした最後の人は現在保護観察中です。彼女が再びそれをするならば、彼女は手放されるでしょう。本番データにアクセスでき、害を及ぼさないようにすることがその1つである場合、あなたには責任があります。これは、技術的な問題であると同時にパフォーマンスの問題でもあります。人々がばかげた間違いを犯さないようにする方法を見つけることは決してできません（データベースには、id = 100のテーブルaを削除するのか、テーブルaを削除するのかを知る方法がなく、ほとんどの人が確認を自動的にヒットします）。このコードを実行する人々に責任があることを確認し、彼らが何をすべきかを思い出すのを助けるためのポリシーを導入することによってのみ、それらを減らすことを試みることができます。
他の人は、これが起こらないようにするために私たちが行うことの種類を提案しました。クエリウィンドウから実行している削除にselectを常に埋め込み、意図したレコードのみが削除されるようにします。データを変更、挿入、または削除する本番環境のすべてのコードは、トランザクションに含める必要があります。手動で実行している場合は、影響を受けるレコードの数が表示されるまで、ロールバックまたはコミットを実行しません。
埋め込み選択を使用した削除の例
delete a
--select a.* from
from table1 a
join table 2 b on a.id = b.id
where b.somefield = 'test'
しかし、これらの手法でさえ、すべての人的エラーを防ぐことはできません。データを理解していない開発者は、selectを実行しても、削除するレコードが多すぎることを理解していない可能性があります。トランザクションで実行すると、システムのコミットまたはロールバックを忘れてシステムをロックするときに、他の問題が発生する可能性があります。または、メッセージボックスに確認があった場合に確認を押すのと同じように、トランザクションに入れても、考えずにコミットを押す場合があります。最善の予防策は、このようなエラーから迅速に回復する方法を用意することです。監査ログテーブルからのリカバリは、バックアップからのリカバリよりも高速になる傾向があります。さらに、誰がエラーを起こし、どのレコードが影響を受けたかを正確に知ることができるという利点があります（テーブル全体を削除しなかったが、where句が間違っていて、いくつかの間違ったレコードを削除した可能性があります）。
ほとんどの場合、本番データをその場で変更しないでください。変更のスクリプトを作成し、最初にdevで確認する必要があります。次に、prodで行う必要があるのは、一度に1つずつ小さな部分を強調表示して実行するのではなく、変更を加えずにスクリプトを実行することだけです。現在、現実の世界では、これを常に修正できるとは限りません。たとえば、重要なデータが削除されたために顧客がログインできない場合など、今すぐ修正する必要がある製品でのみ壊れたものを修正している場合があります。このような場合、最初に開発で問題を再現し、次に修正を書き込む余裕がない場合があります。この種の問題が発生した場合は、prodで直接修正する必要があり、dbasまたはデータベースアナリストのみ、または通常prodのデータを担当する構成マネージャーなどが開発者ではなく修正を行う必要があります。
于 2008-11-11T18:45:59.450 に答える
3
SSMS 2005 では、Tools|Options|Query Execution|SQL Server|ANSI ... check でこのオプションを有効にできますSET IMPLICIT_TRANSACTIONS。将来の接続の更新/削除クエリに影響を与えるには、コミットが必要です。
現在のクエリについては、[クエリ] | [クエリ オプション] | [実行] | [ANSI] に移動し、同じボックスをオンにします。
このページには、SSMS 2000 を使用している場合の手順も記載されています。
他の人が指摘しているように、これは根本的な原因に対処しません。作成するすべての新しいクエリの最後に COMMIT を貼り付けるのは、最初にクエリを実行するのと同じくらい簡単です。
于 2008-11-11T16:29:07.340 に答える
2
そのため、2 日連続で、修飾された where 句がなかったため、削除しようとしていた 1 行ではなく、データのテーブル全体が消去されました。
おそらく唯一の解決策は、誰かを他の誰かに置き換えることです; )。そうでなければ、彼らは常に回避策を見つけるでしょう
最終的にその人物のデータベース アクセスを制限し、where 句で使用されるパラメーターを受け取るストアド プロシージャを提供し、そのストアド プロシージャを実行するためのアクセスを許可します。
于 2008-11-11T18:28:19.297 に答える
2
そのため、常に次のことを行う必要があると私は信じています。
1 本番環境にデプロイする前に開発データベースでテストされたストアド プロシージャを使用する
2 削除前のデータを選択
3 インタビューとパフォーマンス評価プロセスを使用するスクリーン開発者:)
4 削除する/しないデータベース テーブルの数に関する基本的なパフォーマンス評価
5 本番データを有毒であるかのように扱い、非常に恐れる
于 2008-11-11T16:25:52.713 に答える
1
ロックダウン:
REVOKEすべてのテーブルに対する削除権限。
監査トリガーと監査テーブルを入れます。
パラメータ化された削除 SP を作成し、必要に応じて実行する権限のみを付与します。
于 2008-11-11T18:59:18.847 に答える
1
彼らが WHERE 句を入れられるようになるまで、最高の Trogdor と Burninate を着用してください。
最良のアドバイスは、テスト時にトランザクションを使用するためにデータベースをいじっているマケティマックを取得することです。「おっと」の瞬間を防ぐのに大いに役立ちます。警告は、コミットまたはロールバックするように指示する必要があることです。これは、DB が少なくとも 1 回はロックされることが確実であるためです。
于 2008-11-11T16:27:49.743 に答える
0
SQL への raw アクセスを提供せずに、ユーザーが必要とする結果を提供する方法はありませんか? 少なくとも「WHERE」用の別の入力ボックスがあれば、デフォルトで「WHERE 1 = 0」などに設定できます。
トランザクションのジャーナリングからこれらを取り消す方法もあるに違いないと思います。しかし、おそらくすべてをロールバックしてから、致命的なミスの後に発生したものを選択的に再適用する必要があります。
別の厄介なオプションは、トリガーを作成して、すべての DELETE (おそらく最小レコード数を超える) をログ テーブルに書き込むことです。
于 2008-11-11T18:55:04.830 に答える