मैं जिस सिस्टम पर काम करता हूं उसमें बहुत सारी संग्रहीत प्रक्रियाएं और SQL स्क्रिप्ट हैं जो अस्थायी तालिकाओं का उपयोग करती हैं। इन तालिकाओं का उपयोग करने के बाद उन्हें गिराना अच्छा अभ्यास है।
मेरे कई सहकर्मी (जिनमें से लगभग सभी मेरे मुकाबले बहुत अधिक अनुभवी हैं) आमतौर पर ऐसा करते हैं:
TRUNCATE TABLE #mytemp
DROP TABLE #mytemp
मैं आमतौर पर DROP TABLEअपनी स्क्रिप्ट में सिंगल का उपयोग करता हूं।
क्या किसी के TRUNCATEतुरंत पहले ऐसा करने का कोई अच्छा कारण है DROP?
जवाबों:
TRUNCATEऔर DROPव्यवहार और गति में लगभग समान हैं, इसलिए एक TRUNCATEसे पहले ही सही DROPकरना अनावश्यक है।
नोट: मैंने यह उत्तर एक SQL सर्वर के नजरिए से लिखा था और यह माना कि यह Sybase पर समान रूप से लागू होगा। ऐसा प्रतीत होता है कि यह पूरी तरह से मामला नहीं है ।
नोट: जब मैंने पहली बार इस उत्तर को पोस्ट किया था, तो कई अन्य उच्च श्रेणी के उत्तर दिए गए थे - जिसमें तत्कालीन स्वीकार किए गए उत्तर भी शामिल थे - जिसमें कई झूठे दावे किए गए थे जैसे: TRUNCATEलॉग नहीं किया गया है; TRUNCATEवापस नहीं लुढ़का जा सकता; TRUNCATEसे तेज है DROP; आदि।
अब जब इस धागे को साफ कर दिया गया है, तो जिन खंडों का अनुसरण किया गया है, वे मूल प्रश्न के अनुकूल हो सकते हैं। मैं उन्हें इन मिथकों को खत्म करने के लिए दूसरों के संदर्भ के रूप में यहां छोड़ देता हूं।
अनुभवी डीबीए के बीच भी लोकप्रिय झूठ के कुछ जोड़े हैं - जो इस TRUNCATE-then-DROPपैटर्न को प्रेरित कर सकते हैं । वो हैं:
TRUNCATEलॉग नहीं किया गया है, इसलिए इसे वापस नहीं लाया जा सकता है।TRUNCATEसे तेज है DROP।मुझे इन झूठों पर पलटवार करना चाहिए। मैं एक SQL सर्वर के नजरिए से इस खंडन को लिख रहा हूं, लेकिन मैं जो कुछ भी यहां कहता हूं वह समान रूप से Sybase पर लागू होना चाहिए।
TRUNCATEएक लॉग ऑपरेशन है, इसलिए इसे वापस रोल किया जा सकता है । बस इसे एक लेनदेन में लपेटें।
USE [tempdb];
SET NOCOUNT ON;
CREATE TABLE truncate_demo (
whatever VARCHAR(10)
);
INSERT INTO truncate_demo (whatever)
VALUES ('log this');
BEGIN TRANSACTION;
TRUNCATE TABLE truncate_demo;
ROLLBACK TRANSACTION;
SELECT *
FROM truncate_demo;
DROP TABLE truncate_demo;
हालाँकि, ध्यान दें कि यह Oracle के लिए सही नहीं है । हालांकि Oracle के पूर्ववत और फिर से कार्य करने से लॉग इन और संरक्षित है, TRUNCATEऔर अन्य DDL स्टेटमेंट को उपयोगकर्ता द्वारा वापस नहीं लाया जा सकता है, क्योंकि Oracle के सभी डीडीएल बयानों के तुरंत पहले और बाद में निहित हैं ।
TRUNCATEपूरी तरह से लॉग इन करने के विपरीत, न्यूनतम रूप से लॉग इन किया गया है। इसका क्या मतलब है? तुम TRUNCATEएक मेज कहो । लेन-देन लॉग में प्रत्येक हटाए गए पंक्ति को डालने के बजाय, TRUNCATEबस उन डेटा पृष्ठों को चिह्नित करें , जिन पर वे रहते हैं। इसलिए यह इतना तेज है। यही कारण है कि आप TRUNCATEलॉग रीडर का उपयोग करके लेन-देन लॉग से तालिका तालिका की पंक्तियों को पुनर्प्राप्त नहीं कर सकते हैं । आप पाएंगे कि डीललॉक्ड डेटा पृष्ठों के संदर्भ हैं।
इससे तुलना करें DELETE। यदि आप DELETEकिसी तालिका में सभी पंक्तियों को रखते हैं और लेन-देन करते हैं, तो भी, सिद्धांत रूप में, लेन-देन लॉग में हटाए गए पंक्तियों को ढूंढें और उन्हें वहां से पुनर्प्राप्त करें। ऐसा इसलिए है क्योंकि DELETEप्रत्येक नष्ट की गई पंक्ति को लेन-देन लॉग में लिखा जाता है। बड़ी तालिकाओं के लिए, यह इसे बहुत धीमा कर देगा TRUNCATE।
TRUNCATE, DROPएक न्यूनतम रूप से लॉग किया गया ऑपरेशन है। इसका मतलब है कि DROPवापस भी लुढ़का जा सकता है। इसका मतलब यह भी है कि यह ठीक उसी तरह काम करता है जैसे कि TRUNCATE। अलग-अलग पंक्तियों को हटाने के बजाय, DROPउपयुक्त डेटा पृष्ठों को असंबद्ध के रूप में चिह्नित करता है और इसके अतिरिक्त तालिका के मेटाडेटा को हटाए गए के रूप में चिह्नित करता है ।क्योंकि TRUNCATEऔर DROPठीक उसी तरह काम करते हैं, वे एक दूसरे के समान तेज दौड़ते हैं। इसे करने से पहले किसी तालिका को TRUNCATEटोकने का कोई मतलब नहीं DROPहै। यदि आप मुझ पर विश्वास नहीं करते हैं तो इस डेमो स्क्रिप्ट को अपने विकास उदाहरण पर चलाएँ ।
मेरे स्थानीय मशीन पर एक गर्म कैश के साथ, मेरे द्वारा प्राप्त परिणाम इस प्रकार हैं:
table row count: 134,217,728
run# transaction duration (ms)
TRUNCATE TRUNCATE then DROP DROP
==========================================
01 0 1 4
02 0 39 1
03 0 1 1
04 0 2 1
05 0 1 1
06 0 25 1
07 0 1 1
08 0 1 1
09 0 1 1
10 0 12 1
------------------------------------------
avg 0 8.4 1.3
तो, 134 मिलियन पंक्ति तालिका के लिए दोनों DROPऔर TRUNCATEप्रभावी ढंग से समय नहीं लेते हैं। (पहले या दो मिनट के लिए एक ठंडे कैश पर उन्हें लगभग 2-3 सेकंड लगते हैं ।) मेरा यह भी मानना है कि TRUNCATEतत्कालीन DROPऑपरेशन के लिए उच्च औसत अवधि मेरे स्थानीय मशीन पर बदलाव लोड करने के लिए जिम्मेदार है और इसलिए नहीं कि संयोजन किसी तरह जादुई रूप से एक है व्यक्तिगत संचालन की तुलना में बदतर परिमाण का क्रम। वे सब के बाद, लगभग एक ही बात कर रहे हैं।
यदि आप इन कार्यों के लॉगिंग ओवरहेड के बारे में अधिक विस्तार से रुचि रखते हैं, तो मार्टिन के पास इसका सीधा स्पष्टीकरण है।
TRUNCATEतब परीक्षण करना DROPबनाम बनाम DROPसीधे सीधे पता चलता है कि पहले दृष्टिकोण में वास्तव में थोड़ी वृद्धि हुई लॉगिंग ओवरहेड है, इसलिए यह हल्के से काउंटर उत्पादक भी हो सकता है।
व्यक्तिगत लॉग रिकॉर्ड को देखने से पता चलता है कि TRUNCATE ... DROPसंस्करण DROPइन अतिरिक्त प्रविष्टियों को छोड़कर संस्करण के समान है ।
+-----------------+---------------+-------------------------+
| Operation | Context | AllocUnitName |
+-----------------+---------------+-------------------------+
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysallocunits.clust |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrowsets.clust |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrscols.clst |
| LOP_COUNT_DELTA | LCX_CLUSTERED | sys.sysrscols.clst |
| LOP_HOBT_DDL | LCX_NULL | NULL |
| LOP_MODIFY_ROW | LCX_CLUSTERED | sys.sysallocunits.clust |
| LOP_HOBT_DDL | LCX_NULL | NULL |
| LOP_MODIFY_ROW | LCX_CLUSTERED | sys.sysrowsets.clust |
| LOP_LOCK_XACT | LCX_NULL | NULL |
+-----------------+---------------+-------------------------+
इसलिए TRUNCATEपहला संस्करण विभिन्न सिस्टम टेबलों के लिए कुछ अपडेट करते हुए थोड़े प्रयास को समाप्त करता है
rcmodifiedसभी तालिका स्तंभों के लिए अद्यतन करेंsys.sysrscolsrcrowsमेंsysrowsetspgfirst, pgroot, pgfirstiam, pcused, pcdata, pcreservedमेंsys.sysallocunitsये सिस्टम टेबल की पंक्तियाँ केवल तब समाप्त हो जाती हैं जब अगले स्टेटमेंट में टेबल को हटा दिया जाता है।
TRUNCATEबनाम द्वारा किए गए लॉगिंग का पूर्ण विराम नीचे DROPहै। मैंने DELETEतुलना के प्रयोजनों के लिए भी जोड़ा है।
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| | | | Bytes | Count |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| Operation | Context | AllocUnitName | Truncate / Drop | Drop Only | Truncate Only | Delete Only | Truncate / Drop | Drop Only | Truncate Only | Delete Only |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| LOP_BEGIN_XACT | LCX_NULL | | 132 | 132 | 132 | 132 | 1 | 1 | 1 | 1 |
| LOP_COMMIT_XACT | LCX_NULL | | 52 | 52 | 52 | 52 | 1 | 1 | 1 | 1 |
| LOP_COUNT_DELTA | LCX_CLUSTERED | System Table | 832 | | 832 | | 4 | | 4 | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | System Table | 2864 | 2864 | | | 22 | 22 | | |
| LOP_DELETE_ROWS | LCX_MARK_AS_GHOST | T | | | | 8108000 | | | | 1000 |
| LOP_HOBT_DDL | LCX_NULL | | 108 | 36 | 72 | | 3 | 1 | 2 | |
| LOP_LOCK_XACT | LCX_NULL | | 336 | 296 | 40 | | 8 | 7 | 1 | |
| LOP_MODIFY_HEADER | LCX_PFS | Unknown Alloc Unit | 76 | 76 | | 76 | 1 | 1 | | 1 |
| LOP_MODIFY_ROW | LCX_CLUSTERED | System Table | 644 | 348 | 296 | | 5 | 3 | 2 | |
| LOP_MODIFY_ROW | LCX_IAM | T | 800 | 800 | 800 | | 8 | 8 | 8 | |
| LOP_MODIFY_ROW | LCX_PFS | T | 11736 | 11736 | 11736 | | 133 | 133 | 133 | |
| LOP_MODIFY_ROW | LCX_PFS | Unknown Alloc Unit | 92 | 92 | 92 | | 1 | 1 | 1 | |
| LOP_SET_BITS | LCX_GAM | T | 9000 | 9000 | 9000 | | 125 | 125 | 125 | |
| LOP_SET_BITS | LCX_IAM | T | 9000 | 9000 | 9000 | | 125 | 125 | 125 | |
| LOP_SET_BITS | LCX_PFS | System Table | 896 | 896 | | | 16 | 16 | | |
| LOP_SET_BITS | LCX_PFS | T | | | | 56000 | | | | 1000 |
| LOP_SET_BITS | LCX_SGAM | Unknown Alloc Unit | 168 | 224 | 168 | | 3 | 4 | 3 | |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
| Total | | | 36736 | 35552 | 32220 | 8164260 | 456 | 448 | 406 | 2003 |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
परीक्षण एक डेटाबेस में पूर्ण पुनर्प्राप्ति मॉडल के साथ 1,000 पंक्ति तालिका प्रति पृष्ठ एक पंक्ति के साथ किया गया था। रूट इंडेक्स पेज और 3 इंटरमीडिएट लेवल इंडेक्स पेज के कारण तालिका कुल 1,004 पृष्ठों की खपत करती है।
इन पेजों में से 8 मिश्रित पेजों में सिंगल पेज आवंटन हैं, जो 125 यूनिफॉर्म एक्सटेंशन में वितरित शेष हैं। 8 एकल पृष्ठ डी-आवंटन 8 LOP_MODIFY_ROW,LCX_IAMलॉग प्रविष्टियों के रूप में दिखाई देते हैं। 125 सीमा के रूप में LOP_SET_BITS LCX_GAM,LCX_IAM। इन दोनों ऑपरेशनों को भी संबंधित PFSपेज पर अपडेट की आवश्यकता होती है इसलिए संयुक्त 133 LOP_MODIFY_ROW, LCX_PFSप्रविष्टियां। तब जब तालिका को वास्तव में मेटाडेटा गिरा दिया जाता है, इसके बारे में विभिन्न सिस्टम तालिकाओं से निकालने की आवश्यकता होती है इसलिए 22 सिस्टम टेबल LOP_DELETE_ROWSलॉग प्रविष्टियाँ (नीचे के रूप में हिसाब)
+----------------------+--------------+-------------------+-------------------+
| Object | Rows Deleted | Number of Indexes | Delete Operations |
+----------------------+--------------+-------------------+-------------------+
| sys.sysallocunits | 1 | 2 | 2 |
| sys.syscolpars | 2 | 2 | 4 |
| sys.sysidxstats | 1 | 2 | 2 |
| sys.sysiscols | 1 | 2 | 2 |
| sys.sysobjvalues | 1 | 1 | 1 |
| sys.sysrowsets | 1 | 1 | 1 |
| sys.sysrscols | 2 | 1 | 2 |
| sys.sysschobjs | 2 | 4 | 8 |
+----------------------+--------------+-------------------+-------------------+
| | | | 22 |
+----------------------+--------------+-------------------+-------------------+
नीचे पूरी स्क्रिप्ट
DECLARE @Results TABLE
(
Testing int NOT NULL,
Operation nvarchar(31) NOT NULL,
Context nvarchar(31) NULL,
AllocUnitName nvarchar(1000) NULL,
SumLen int NULL,
Cnt int NULL
)
DECLARE @I INT = 1
WHILE @I <= 4
BEGIN
IF OBJECT_ID('T','U') IS NULL
CREATE TABLE T(N INT PRIMARY KEY,Filler char(8000) NULL)
INSERT INTO T(N)
SELECT DISTINCT TOP 1000 number
FROM master..spt_values
CHECKPOINT
DECLARE @allocation_unit_id BIGINT
SELECT @allocation_unit_id = allocation_unit_id
FROM sys.partitions AS p
INNER JOIN sys.allocation_units AS a
ON p.hobt_id = a.container_id
WHERE p.object_id = object_id('T')
DECLARE @LSN NVARCHAR(25)
DECLARE @LSN_HEX NVARCHAR(25)
SELECT @LSN = MAX([Current LSN])
FROM fn_dblog(null, null)
SELECT @LSN_HEX=
CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 1, 8),2) AS INT) AS VARCHAR) + ':' +
CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 10, 8),2) AS INT) AS VARCHAR) + ':' +
CAST(CAST(CONVERT(varbinary,SUBSTRING(@LSN, 19, 4),2) AS INT) AS VARCHAR)
BEGIN TRAN
IF @I = 1
BEGIN
TRUNCATE TABLE T
DROP TABLE T
END
ELSE
IF @I = 2
BEGIN
DROP TABLE T
END
ELSE
IF @I = 3
BEGIN
TRUNCATE TABLE T
END
ELSE
IF @I = 4
BEGIN
DELETE FROM T
END
COMMIT
INSERT INTO @Results
SELECT @I,
CASE
WHEN GROUPING(Operation) = 1 THEN 'Total'
ELSE Operation
END,
Context,
CASE
WHEN AllocUnitId = @allocation_unit_id THEN 'T'
WHEN AllocUnitName LIKE 'sys.%' THEN 'System Table'
ELSE AllocUnitName
END,
COALESCE(SUM([Log Record Length]), 0) AS [Size in Bytes],
COUNT(*) AS Cnt
FROM fn_dblog(@LSN_HEX, null) AS D
WHERE [Current LSN] > @LSN
GROUP BY GROUPING SETS((Operation, Context,
CASE
WHEN AllocUnitId = @allocation_unit_id THEN 'T'
WHEN AllocUnitName LIKE 'sys.%' THEN 'System Table'
ELSE AllocUnitName
END),())
SET @I+=1
END
SELECT Operation,
Context,
AllocUnitName,
AVG(CASE WHEN Testing = 1 THEN SumLen END) AS [Truncate / Drop Bytes],
AVG(CASE WHEN Testing = 2 THEN SumLen END) AS [Drop Bytes],
AVG(CASE WHEN Testing = 3 THEN SumLen END) AS [Truncate Bytes],
AVG(CASE WHEN Testing = 4 THEN SumLen END) AS [Delete Bytes],
AVG(CASE WHEN Testing = 1 THEN Cnt END) AS [Truncate / Drop Count],
AVG(CASE WHEN Testing = 2 THEN Cnt END) AS [Drop Count],
AVG(CASE WHEN Testing = 3 THEN Cnt END) AS [Truncate Count],
AVG(CASE WHEN Testing = 4 THEN Cnt END) AS [Delete Count]
FROM @Results
GROUP BY Operation,
Context,
AllocUnitName
ORDER BY Operation, Context,AllocUnitName
DROP TABLE T
ठीक है, मैंने कुछ बेंचमार्क करने का प्रयास किया है जो किसी भी "वार्म कैशिंग" पर भरोसा नहीं करते हैं ताकि उम्मीद है कि वे एक अधिक यथार्थवादी परीक्षण करेंगे (यह भी पोस्टग्रैस का उपयोग करके, यह देखने के लिए कि क्या यह अन्य पोस्ट किए गए उत्तरों की समान विशेषताओं से मेल खाता है) :
एक बड़े-ईश डेटाबेस के साथ 9.3.4 का उपयोग करते हुए मेरे बेंचमार्क, (उम्मीद है कि राम कैश में फिट नहीं होने के लिए पर्याप्त बड़े):
इस परीक्षण DB स्क्रिप्ट का उपयोग करना: https://gist.github.com/rdp/8af84fbb54a430df8fb0
10M पंक्तियों के साथ:
truncate: 1763ms
drop: 2091ms
truncate + drop: 1763ms (truncate) + 300ms (drop) (2063ms total)
drop + recreate: 2063ms (drop) + 242ms (recreate)
100 मीटर पंक्तियों के साथ:
truncate: 5516ms
truncate + drop: 5592ms
drop: 5680ms (basically, the exact same ballpark)
तो इससे मैं निम्नलिखित को कम करता हूं: ड्रॉप "के बारे में" जितना तेज (या तेज) ट्रंकट + ड्रॉप (कम से कम पोस्टग्रेज के आधुनिक संस्करणों के लिए) है, हालांकि, अगर आप भी घूमने और मेज को फिर से बनाने की योजना बनाते हैं, तो आप इस प्रकार हैं अच्छी तरह से एक सीधी ट्रंकट करते हुए छड़ी करें, जो एक ड्रॉप + रीक्रिएट (समझ में आता है) से तेज है। FWIW।
नोट 1: https://stackoverflow.com/questions/11419536/postgresql-truncation-speed/11423886#11423886 (कहता है कि पोस्टग्रेस 9.2 में पिछले संस्करणों की तुलना में अधिक तेज गति हो सकती है)। हमेशा की तरह, अपनी विशेषताओं को देखने के लिए अपने स्वयं के सिस्टम के साथ बेंचमार्क।
नोट 2: ट्रंकट को पोस्टग्रेज में वापस रोल किया जा सकता है, यदि लेनदेन में: http://www.postgresql.org/docs/8.4/static/sql-truncate.html
नोट 3: छोटे टेबल के साथ ट्रंकट, कभी-कभी हटाए जाने की तुलना में धीमा हो सकता है: https://stackoverflow.com/questions/11419536/postgresql-truncation-speed/11423886##2323886
कुछ ऐतिहासिक परिप्रेक्ष्य जोड़ना ...
टेबल को छोड़ने के लिए कई सिस्टम टेबल को अपडेट करने की आवश्यकता होती है, जिसके परिणामस्वरूप आमतौर पर एकल ट्रांजेक्शन में इन सिस्टम टेबल में बदलाव करने की आवश्यकता होती है (सोचें "ट्रान शुरू करें, syscolumns हटाएं, sysobjects हटाएं, कमिट करें")।
इसके अलावा 'ड्रॉप टेबल' में शामिल टेबल के साथ जुड़े सभी डेटा / इंडेक्स पेजों की डील करने की जरूरत है।
कई, कई, कई साल पहले ... अंतरिक्ष के सौदे की प्रक्रिया को लेनदेन में शामिल किया गया था जो सिस्टम तालिकाओं को भी अपडेट करता था, शुद्ध परिणाम यह था कि आवंटित पृष्ठों की संख्या जितनी अधिक होगी, उतने अधिक समय तक कहा गया पृष्ठों, लंबे समय तक। लेन-देन (सिस्टम तालिकाओं पर) खुला छोड़ दिया गया था, और इस प्रकार (सिस्टम तालिकाओं पर) अवरुद्ध करने का एक बड़ा मौका अन्य प्रक्रियाओं को बनाने की कोशिश कर रहा था / विशेष रूप से पुराने allpages के साथ टेम्पेड में ड्रॉप टेबल बनाने के लिए == पेज-स्तर लॉकिंग और टेबल पर संभावित -लेवल लॉक एस्केलेशन)।
सिस्टम तालिकाओं पर विवाद को कम करने के लिए उपयोग की जाने वाली एक प्रारंभिक विधि (सिस्टम की तालिकाओं पर ताले लगे हुए समय को कम करने के लिए सिस्टम तालिकाओं पर विवाद को कम करने के लिए थी, और ऐसा करने के लिए एक / अपेक्षाकृत आसान तरीका डेटा / इंडेक्स पेजों को छोड़ने से पहले हटाना था। टेबल।
जबकि truncate tableपुनःआवंटन नहीं करता है सभी डेटा / सूचकांक पृष्ठों, यह सब लेकिन एक 8-पेज (डेटा) हद पुनःआवंटन करता है, एक और 'हैक' तब तालिका छोड़ने से पहले सभी अनुक्रमितों को छोड़ना था (हाँ, sysindexes पर अलग txn लेकिन ड्रॉप टेबल के लिए एक छोटा txn)।
जब आप समझते हैं (फिर से, कई, कई साल पहले) वहाँ सिर्फ एक 'tempdb' डेटाबेस थी, और कुछ अनुप्रयोगों बनाया हैवी कि एकल 'tempdb' डेटाबेस का उपयोग करते हैं, किसी भी 'हैक्स' में सिस्टम टेबल पर विवाद को कम कर सकता 'टेम्पर्डब' लाभ के थे; समय के साथ हालात सुधरे हैं ... कई अस्थायी डेटाबेस, सिस्टम टेबलों पर रो-लेवल लॉक करना, बेहतर डीललैशन के तरीके, आदि।
इस बीच का उपयोग truncate tableकोड में छोड़ दिया है, तो कुछ भी चोट नहीं करता है।
यह उन तालिकाओं के लिए TRUNCATE करने के लिए समझ में आता है जिनके पास विदेशी चाबियाँ हैं। हालांकि, अस्थायी तालिकाओं के लिए बस डीआरओपी पर्याप्त है
इसका मतलब यह truncateहै कि तालिका में हर चीज को सरलता से हटा दिया जाए और (डेटा स्टोर इंजन पर आधारित कुछ तकनीकी बारीकियों में थोड़ा अंतर हो सकता है) - भारी लॉगिंग को छोड़ देना, आदि।
drop tableपरिवर्तन होते ही सभी परिवर्तन लॉग होते हैं। तो, कम से कम प्रवेश करने और बेकार प्रणाली मंथन को कम करने के लिए, मुझे संदेह होगा कि एक बहुत बड़ी तालिका पहले छंटनी की जा सकती है, फिर गिरा दी गई।
truncate लेन-देन में लपेटा जा सकता है (जो सबसे सुरक्षित विकल्प होगा), जो निश्चित रूप से आपको ऑपरेशन वापस करने की अनुमति देगा।