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

私が取り組んでいるシステムには、一時テーブルを利用する多くのストアドプロシージャとSQLスクリプトがあります。これらのテーブルを使用した後、削除することをお勧めします。 私の同僚の多く（ほとんど全員が私よりもはるかに経験豊富です）が通常これを行います： TRUNCATE TABLE #mytemp DROP TABLE #mytemp 私は通常DROP TABLE、スクリプトでシングルを使用します。 TRUNCATE直前に行う理由はありますDROPか？

100 sql-server  sybase  truncate 

残り2GBしかないため、この履歴テーブルを削除する必要があります。このテーブルは空になりましたが、データベースのディスク容量は解放されていません。また、データベースファイルは320GBです。

23 sql-server  sql-server-2012  truncate 

最後に、@ 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 

スペースが不足しています。エラーログを消去する安全な方法は何ですか？

17 sql-server  sql-server-2008-r2  disk-space  errors  truncate 

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

15 oracle  delete  ddl  truncate 

SQL Serverは、ストアドプロシージャ内で作成された一時テーブルをキャッシュし、プロシージャが終了してその後実行されるときにそれらの名前を変更するだけです。私の質問は、tempdbスペースがいつ解放されるかに関するものです。手順の最後でテーブルが切り捨てられることを読みました。これはセッションごとに処理されることをコメントで読んでおり、クリーンアップが必要かどうかについての質問がMSDNで回答されています。しかし、同じセッションで2回実行されない場合はどうでしょうか？ また、テーブルが範囲外になるとその領域を解放するバックグラウンドガベージコレクションプロセスがあることも聞いたことがあります。 それを作成するストアドプロシージャの最後で一時テーブルを切り捨てると、逆の期待にもかかわらず、truncateステートメントが使用されていない場合よりも、テーブルがtempdbでデータ用に使用するスペースがより速く解放されるようです。どうして？ そのような切り捨てステートメントを使用するかどうかの相対的なパフォーマンスへの影響はどうなりますか？SNAPSHOT分離を使用する場合、tempdbにストレスがかかることがよくあります。tempdbで使用されているスペースをできるだけ大きなtempテーブルからできるだけ早く解放すると、tempdbの不必要な増大を防ぐことができると思います。この潜在的なスペース節約は、パフォーマンスを犠牲にして実現されるでしょうか？ 以下に、問題を再現するためのコードを示します（主に@TheGameiswarから、いくつかの変更を加えたものです）。 SET NOCOUNT ON; GO ALTER PROC usp_test AS BEGIN IF object_id('tempdb..#temp') IS NOT NULL DROP TABLE #temp SELECT * INTO #temp FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused --SELECT SUM(user_object_reserved_page_count) AS [user object pages used] …

12 sql-server  stored-procedures  tempdb  temporary-tables  truncate 

私はTRUNCATEと呼ばれる巨大な（〜120Gb）テーブルを持っていますfiles： TRUNCATE files; VACUUM FULL files; テーブルサイズは0ですが、ディスク領域は解放されていません。失われたディスク容量を回収する方法はありますか？ 更新： 12時間後にディスク領域が解放されましたが、何も操作しませんでした。Ubuntu 8.04サーバーを使用しています。

12 postgresql  truncate  disk-space 

スナップショット分離とTRUNCATEに関して、私が予期していなかったこの動作に誰かが光を当てることができることを願っています。 データベース：スナップショット分離を許可= True; コミットされた読み取りスナップショットがオン= False。 手順1（長時間実行される複雑なSELECTのテーブルfooのコンテンツを多数の結合で置き換えます）： BEGIN TRAN; TRUNCATE TABLE foo; INSERT INTO foo SELECT...; COMMIT; 手順2（テーブルfooからの読み取り）： SET TRANSACTION ISOLATION LEVEL SNAPSHOT; SELECT * FROM foo; Procedure2の実行中にProcedure1が実行されている場合、Procedure2は、Procedure1が終了するまで（sp_WhoIsActiveに応じて）LCK_M_SCH_S待機で待機します。そして、Procedure2が完了すると、次の例外が発生します。 このトランザクションの開始以降、ステートメントによってアクセスされたオブジェクトが別の同時トランザクションのDDLステートメントによって変更されたため、データベース 'DatabaseName'でスナップショット分離トランザクションが失敗しました。メタデータはバージョン管理されていないため、許可されません。メタデータへの同時更新は、スナップショット分離と混在している場合、不整合を引き起こす可能性があります。 ただし、Microsoftでは、スナップショット分離では許可されていないDDLステートメントとしてTRUNCATEをリストしていません。http：//msdn.microsoft.com/en-us/library/bb933783.aspx 手順2がTRUNCATEの前にテーブルから最も最近コミットされたデータをすぐに返すか、または手順1によって保持されてから、テーブル。手伝ってくれますか？

10 sql-server  sql-server-2008-r2  truncate  snapshot-isolation 

MySQL5.5をマスター/スレーブレプリケーション（1マスター、2スレーブ）で実行しています。 週に1回実行して特定のテーブルを切り捨てるプロセスがあります。テーブルは大きくなく、数千のレコードしかありません。 何らかの理由で、TRUNCATE TABLEコマンドの実行に非常に長い時間がかかります（マスターとスレーブの両方で）。実行には約400Kミリ秒かかります!! スレーブで実行すると、マスターから遅れます。終了後TRUNCATE TABLE、すべてが正常に戻ります。 スレーブの1つはTRUNCATE TABLE専用スレーブであり、そのスレーブから読み取るプロセスがダウンしていたため、実行中に読み取りを受信しなかったことがわかっています。また、このスレーブでは、実行に同じ時間がかかりました。 これがテーブル構造です：http : //pastebin.com/qEQB4juR TRUNCATE TABLEをどのように高速化できるかについての考えはありますか？

9 mysql  replication  mysql-5.5  truncate 

TRUNCATEドロップする方法の違いは何ですか？ 私はそれがテーブル内のすべてのデータを削除すると思いますが、テーブル名をデータベースに保持し、そこでDROPすべてのデータとテーブルを削除します。これは正しいです ？

8 mysql  truncate  drop-table