タグ付けされた質問 「delete」

ユーザーが気を変えて、削除されたレコードを回復できるように、Webアプリケーションに「削除解除」機能を実装したいと思います。これを実装する方法についての考えは？私が検討したいくつかのオプションは、実際に問題のレコードを削除し、別の監査テーブルに変更を保存するか、レコードを削除せず、ブールの「deleted」列を使用して削除済みとしてマークすることです。後者のソリューションでは、通常の状況で「削除された」レコードを無視するために追加のアプリケーションロジックが必要になりますが、アプリケーション側でレコードの回復を実装するのがはるかに簡単になります。

44 database-design  delete  audit 

SQL Server 2005を使用します。 where句のない巨大なDELETE FROMを実行しています。基本的にTRUNCATE TABLEステートメントと同等です-TRUNCATEの使用が許可されていないことを除きます。問題は、テーブルが巨大である-1000万行であり、完了するまでに1時間以上かかることです。以下なしで高速化する方法はありますか？ 切り捨ての使用 インデックスを無効化または削除しますか？ t-logはすでに別のディスクにあります。 どんな提案も歓迎します！

37 sql-server  performance  delete 

PostgreSQL 9.2には、約70個のテーブルを持つメインスキーマと、それぞれ30個のテーブルからなる可変構造のクライアントごとのスキーマを持つデータベースがあります。クライアントスキーマには、メインスキーマを参照する外部キーがあり、その逆はありません。 以前のバージョンから取得した実際のデータをデータベースに入力し始めたところです。メインスキーマの非常に中央のテーブルで一括削除を行う必要があったときに、DBは約1.5 GBに達しました（数週間で数十GBに達すると予想されています）。関係するすべての外部キーは、DELETE CASCADEでマークされます。 これに長い時間がかかることは驚きではありませんでしたが、12時間後には、最初からやり直してDBを削除し、移行を再開する方が良いことが明らかになりました。しかし、後でDBが稼働し、さらに大きくなったときにこの操作を繰り返す必要がある場合はどうなりますか？より高速な代替方法はありますか？ 中央テーブルから最も遠いテーブルから開始し、テーブルごとに依存する行を削除する依存テーブルを参照するスクリプトを書いたら、もっと速くなるでしょうか？ 重要な詳細は、いくつかのテーブルにトリガーがあることです。

30 postgresql  performance  delete  postgresql-9.2 

私の上司は昨日、SQL Serverデータベースのデータを削除した人を見つける方法を尋ねる顧客からの問い合わせがありました（それが重要な場合はエクスプレス版です）。 これはトランザクションログから見つけることができると思いました（切り捨てられていなかった場合）-これは正しいですか？もしそうなら、この情報を実際にどのように見つけ出しますか？

29 sql-server  transaction  delete  audit 

サーバー上のhdスペースの90％近くを占めるテーブルが1つあります。スペースを空けるために、いくつかの列をドロップすることにしました。しかし、スペースをOSに戻す必要があります。ただし、問題は、VACUUM FULLを実行し、テーブルのコピーを作成するための十分な空き領域がない場合にどうなるかわからないことです。 VACUUM FULLは使用すべきではないことを理解していますが、このシナリオでは最良の選択肢であると考えました。 任意のアイデアをいただければ幸いです。 PostgreSQL 9.0.6を使用しています

27 postgresql  delete  alter-table  database-size  vacuum 

私はPostgreSQLから大量の行を削除する最も効率的な方法は何だろうと思っています。このプロセスは、テーブルにデータ（挿入と削除のデルタ）を一括インポートするための毎日の定期的なタスクの一部になります。削除する行は数千、場合によっては数百万になる可能性があります。 1行に1つの主キーのファイルがあります。私が考えていた2つの選択肢は以下のようなものでしたが、PostgreSQLの内部について十分な知識がなく、十分な情報を得た上で最善の判断を下すことができません。 主キーを使用DELETEして、ファイル内の各行に対してクエリを実行しますWHERE（またはn、IN()句を使用してバッチで削除をグループ化します）。 COPYコマンドを使用して主キーを一時テーブルにインポートし、結合を使用してメインテーブルから削除する どんな提案でも大歓迎です！

23 postgresql  delete  bulk 

私はデータベースを継承しており、クリーンアップと高速化を目指しています。私は、30,000,000行を含むテーブルを持っています。その多くは、プログラマーに代わってエラーが原因で挿入されたジャンクデータです。最適化された新しいインデックスを追加する前に、テーブルをMyISAMからInnoDBに変換し、ジャンクデータを含む多くの行を削除しようとしています。 データベースはMySQL 5.0であり、サーバーへのルートアクセス権があります。最初にこれらのコマンドをAdminerで実行し、次にphpMyAdminで実行しましたが、どちらも同じ結果になりました。 私が実行しているコマンドは、 DELETE FROM `tablename` WHERE `columnname` LIKE '-%' 基本的に、ダッシュで始まるこの列のすべてを削除します-。 約3〜5分間実行され、プロセスリストを表示すると消えます。 それから走ります SELECT * FROM `tablename` WHERE `columnname` LIKE '-%' そして何百万もの行を返します。 削除ステートメントが完了しないのはなぜですか？ PS、MySQL 5.0が古くなっていることに気付いています。私は、DBをMySQL 5.6 w InnoDB（おそらくMariaDB 10 w XtraDB）に移行する作業を行っていますが、それが起こるまでは、DBをそのまま使用して答えを探しています。 - 編集が削除されました。回答を参照してください。

22 mysql  innodb  myisam  delete  mysql-5.0 

最後に、@ table変数と#tempテーブルのパフォーマンスを比較するためのテストスクリプトがあります。私はそれを正しく設定したと思います-パフォーマンスのタイミングはDELETE / TRUNCATEコマンドの外で取られます。私が得ている結果は次のとおりです（ミリ秒単位の時間）。 @Table Variable #Temp (delete) #Temp (truncate) --------------- -------------- ---------------- 5723 5180 5506 15636 14746 7800 14506 14300 5583 14030 15460 5386 16706 16186 5360 念のためGetDate()、バッチではなくステートメントの時点でCURRENT_TIMESTAMP（別名）が取得されることを示しているため、TRUNCATE / DELETEとSET @StartTime = CURRENT_TIMESTAMPステートメントの相互作用はありません。 select current_timestamp waitfor delay '00:00:04' select current_timestamp ----------------------- 2012-10-21 11:29:20.290 ----------------------- 2012-10-21 11:29:24.290 DELETEを使用してテーブルをクリアする場合、最初の実行と後続の実行の間のジャンプは非常に一貫しています。DELETEの理解に欠けているものは何ですか？これを何度も繰り返し、順序を交換し、成長を必要としないようにtempdbのサイズを調整しました。 CREATE TABLE …

20 sql-server  performance  sql-server-2012  delete  truncate 

restrictionsPostgreSQLデータベースで呼び出される小さな（〜10行）テーブルがあり、値が毎日削除および挿入されます。 restrictions_deletedから削除されるすべての行がrestrictions自動的に保存されるというテーブルが必要です。以来、restrictionsシリアルIDを有し、全く重複が存在しないであろう。 PostgreSQLでこのようなトリガーを作成するにはどうすればよいですか？

18 postgresql  trigger  delete  plpgsql 

私は、非常に大きな（1つのテーブルに5億行を超える1TBに近いデータ）Oracleデータベースバックエンドを持つアプリケーションを管理しています。データベースは実際には何もしません（SProcsもトリガーも何もしません）、それは単なるデータストアです。 毎月、2つのメインテーブルからレコードを削除する必要があります。パージの基準はさまざまで、行の経過時間といくつかのステータスフィールドの組み合わせです。通常、1か月あたり1,000〜5,000万行をパージします（インポートにより、週に約300〜500万行を追加します）。 現在、この削除は約50,000行のバッチで実行する必要があります（つまり、50000の削除、comit、50000の削除、コミット、繰り返し）。バッチ全体を一度にすべて削除しようとすると、データベースが約1時間応答しなくなります（行数によって異なります）。このようなバッチで行を削除することはシステム上で非常に大雑把であり、通常、1週間にわたって「時間の許す限り」それを行う必要があります。スクリプトを継続的に実行できるようにすると、ユーザーが受け入れられないパフォーマンスの低下を招く可能性があります。 この種のバッチ削除もインデックスのパフォーマンスを低下させ、最終的にデータベースのパフォーマンスを低下させる他の影響があると考えています。1つのテーブルに34個のインデックスがあり、インデックスデータのサイズは実際にはデータ自体よりも大きくなっています。 ITスタッフの1人がこのパージを行うために使用するスクリプトを次に示します。 BEGIN LOOP delete FROM tbl_raw where dist_event_date < to_date('[date]','mm/dd/yyyy') and rownum < 50000; exit when SQL%rowcount < 49999; commit; END LOOP; commit; END; このデータベースは 99.99999％増加している必要があり、年に一度だけ2日間のメンテナンスウィンドウがあります。 これらのレコードを削除するためのより良い方法を探していますが、まだ見つかっていません。助言がありますか？

18 oracle  oracle-11g  delete 

クライアントの同期の必要性のために、削除されたアイテムを追跡する必要があります。 一般に、トゥームストーンテーブルと、サーバーデータベースから行が削除されたときを追跡するトリガーを追加する方が基本ですか？元のテーブルを削除し、通常はビット型の列で削除済みとしてフラグを立てて、行が削除されたことと、削除が発生したときに追跡する別の列を示しますか？

17 delete 

これは以下のリンクで解決されたと思います-回避策は動作します-しかし、パッチは動作しません。Microsoftサポートと協力して解決します。 http://support.microsoft.com/kb/2606883 わかりましたので、誰かがアイデアを持っているかどうかを確認するためにStackOverflowに捨てたい問題があります。 これはSQL Server 2008 R2でのことに注意してください 問題：15000レコードのテーブルから3000レコードを削除すると、トリガーが有効な場合は3〜4分かかり、トリガーが無効な場合は3〜5秒しかかかりません。 テーブルのセットアップ メインとセカンダリと呼ばれる2つのテーブル。セカンダリには削除するアイテムのレコードが含まれているため、削除を実行するとセカンダリテーブルに参加します。deleteステートメントの前にプロセスが実行され、削除するレコードがセカンダリテーブルに入力されます。 ステートメントを削除： DELETE FROM MAIN WHERE ID IN ( SELECT Secondary.ValueInt1 FROM Secondary WHERE SECONDARY.GUID = '9FFD2C8DD3864EA7B78DA22B2ED572D7' ); このテーブルには多くの列と約14の異なるNCインデックスがあります。トリガーが問題であると判断する前に、さまざまなことを試しました。 ページロックをオンにします（デフォルトではオフになっています） 手動で収集された統計 統計の自動収集を無効にしました 検証済みのインデックスの健全性と断片化 テーブルからクラスター化インデックスを削除しました 実行計画を調査しました（インデックスの欠落として表示されるものはなく、実際の削除にかかるコストは70％で、レコードの結合/マージには約28％でした） トリガー テーブルには3つのトリガーがあります（挿入、更新、削除の各操作に1つ）。削除トリガーのコードを変更して、単に戻るようにした後、1つを選択して、トリガーされる回数を確認しました。操作全体で1回だけ起動します（予想どおり）。 ALTER TRIGGER [dbo].[TR_MAIN_RD] ON [dbo].[MAIN] AFTER DELETE AS SELECT 1 RETURN 要点をまとめると トリガーがオンの場合-ステートメントの完了には3〜4分かかります トリガーがオフの場合-ステートメントの完了には3〜5秒かかります …

17 sql-server  performance  sql-server-2008-r2  trigger  delete 

Postgresには古いレコードのエージングアウトをサポートする機能がありますか？ 2週間以上前のレコード（ログイベント）が自動的に削除される一種のキューとして、ロギングにPostgresを使用したいと思います。

15 postgresql  delete  queue 

インタビューの質問があります。これはインタビューの中で尋ねられました。私は質問に答えましたが、インタビュアーは私の答えにそれほど納得していませんでした。だから、誰でも私の理解で私を修正してください？ Q. TruncateがDDLであり、DeleteがDMLである理由 両方ともほぼ同じジョブを実行します（行を削除します） 回答 Truncateを使用している場合、undo-table-spaceに保存せずに、データによって割り当てられたスペース全体の割り当てを解除しています。ただし、削除の場合、すべてのデータをUNDO表スペースに入れてから、すべてのデータを削除します。 上記のベストアンサーを知っている人がいたら、説明してください。

15 oracle  delete  ddl  truncate 

PostgreSQL 9.3データベースに2つのテーブルがあります。テーブルにlink_replyは、which_groupテーブルを指すという名前の外部キーがありますlink_group。 link_group関連する行がlink_reply存在しない場所からすべての行を削除したい。基本的には十分に聞こえますが、私はそれに苦労しています。 これはこのように単純なものになりますか（機能しません）？ DELETE FROM link_group WHERE link_reply = NULL;

15 postgresql  join  postgresql-9.3  delete