যে সিস্টেমে আমি কাজ করি সেখানে প্রচুর সঞ্চিত পদ্ধতি এবং এসকিউএল স্ক্রিপ্ট রয়েছে যা অস্থায়ী সারণী ব্যবহার করে। এই টেবিলগুলি ব্যবহার করার পরে সেগুলি ফেলে দেওয়া ভাল অনুশীলন।
আমার অনেক সহকর্মী (প্রায় সবাই আমার চেয়ে অনেক বেশি অভিজ্ঞ) সাধারণত এটি করেন:
TRUNCATE TABLE #mytemp
DROP TABLE #mytemp
আমি সাধারণত DROP TABLEআমার স্ক্রিপ্টগুলিতে একটি একক ব্যবহার করি।
এর TRUNCATEআগেই তাত্ক্ষণিকভাবে করার জন্য কোনও ভাল কারণ আছে DROP?
উত্তর:
TRUNCATEএবং DROPআচরণ এবং গতিতে প্রায় অভিন্ন, সুতরাং একটি TRUNCATEআগে ডান কাজ DROPকরা কেবল অপ্রয়োজনীয়।
দ্রষ্টব্য: আমি একটি এসকিউএল সার্ভারের দৃষ্টিকোণ থেকে এই উত্তরটি লিখেছি এবং ধরে নিয়েছি এটি সিবাজে সমানভাবে প্রযোজ্য হবে। দেখা যাচ্ছে এটি পুরোপুরি নয় ।
দ্রষ্টব্য: আমি যখন এই উত্তরটি প্রথম পোস্ট করলাম তখন তত্ক্ষণাত স্বীকৃত উত্তর সহ আরও বেশ কয়েকটি উচ্চ রেটযুক্ত উত্তর ছিল - যা বেশ কয়েকটি মিথ্যা দাবি করেছে যেমন: TRUNCATEলগ হয় নি; TRUNCATEফিরে ঘূর্ণিত করা যাবে না; TRUNCATEতুলনায় দ্রুত DROP; প্রভৃতি
এখন যেহেতু এই থ্রেডটি পরিষ্কার হয়ে গেছে, প্রত্যাবর্তনকারী খণ্ডনগুলি মূল প্রশ্নের তুলনায় স্পর্শকাতর বলে মনে হতে পারে। অন্যদের এই রূপকথার কাহিনীটি অনুসন্ধান করার জন্য একটি রেফারেন্স হিসাবে আমি তাদের এখানে রেখেছি।
বেশ কয়েকটি জনপ্রিয় মিথ্যাচার রয়েছে - অভিজ্ঞ ডিবিএর মধ্যেও বিস্তৃত - যা এই TRUNCATE-then-DROPপ্যাটার্নটিকে অনুপ্রাণিত করেছিল । তারা হ'ল:
TRUNCATEলগ করা হয়নি, সুতরাং এটি আবার ঘুরিয়ে দেওয়া যায় না।TRUNCATEতুলনায় দ্রুত DROP।আমাকে এই মিথ্যাগুলি প্রত্যাখ্যান করুন। আমি এই এসকিউএল সার্ভারের দৃষ্টিকোণ থেকে এই প্রত্যাখ্যানটি লিখছি, তবে আমি এখানে যা কিছু বলি তা সাইবেসের জন্যও সমানভাবে প্রযোজ্য।
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;
মনে রাখবেন, তবে, যে এই হল সত্য নয় ওরাকল জন্য । যদিও ওরাকল এর পূর্বাবস্থায় ফেরানো কার্যকারিতা দ্বারা লগ ইন এবং সুরক্ষিত, TRUNCATEএবং অন্যান্য ডিডিএল স্টেটমেন্টগুলি ব্যবহারকারীর কাছে ফিরিয়ে আনা যায় না কারণ ওরাকল সমস্ত ডিডিএল স্টেটমেন্টের অবিলম্বে এবং পরে নিখুঁত প্রতিশ্রুতি জারি করে ।
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 |
+-------------------+-------------------+--------------------+------------------+-----------+---------------+-------------+------------------+-----------+---------------+-------------+
প্রতি পৃষ্ঠায় এক সারি সহ এক হাজার সারি টেবিলের বিপরীতে পুরো পুনরুদ্ধার মডেল সহ একটি ডাটাবেসে পরীক্ষা করা হয়েছিল। রুট ইনডেক্স পৃষ্ঠা এবং 3 টি মাঝারি স্তর সূচক পৃষ্ঠাগুলির কারণে সারণীটি মোট 1,004 পৃষ্ঠা গ্রাস করে consu
এই পৃষ্ঠাগুলির মধ্যে 8 টি মিশ্র এক্সটেন্টগুলিতে একক পৃষ্ঠার বরাদ্দ যা বাকি 12 টি ইউনিফর্ম এক্সেটেন্টে বিতরণ করা হবে। 8 টি একক পৃষ্ঠার ডি-বরাদ্দগুলি 8 LOP_MODIFY_ROW,LCX_IAMলগ এন্ট্রি হিসাবে প্রদর্শিত হবে । হিসাবে 125 ব্যাপ্তি deallocations 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 পোস্টগ্রেস ব্যবহার করে (আশা করি র্যাম ক্যাশে ফিট না করার পক্ষে যথেষ্ট বড়):
এই পরীক্ষার ডিবি স্ক্রিপ্ট ব্যবহার: https://gist.github.com/rdp/8af84fbb54a430df8fc0
10M সারি সহ:
truncate: 1763ms
drop: 2091ms
truncate + drop: 1763ms (truncate) + 300ms (drop) (2063ms total)
drop + recreate: 2063ms (drop) + 242ms (recreate)
100M সারি সহ:
truncate: 5516ms
truncate + drop: 5592ms
drop: 5680ms (basically, the exact same ballpark)
সুতরাং এ থেকে আমি নিম্নলিখিত বিষয়গুলিকে গুরুত্ব দিচ্ছি: ড্রপ "ট্রান্সকেট + ড্রপ" (যেমন কমপক্ষে পোস্টগ্রাসের আধুনিক সংস্করণগুলির জন্য) হিসাবে "প্রায়" দ্রুত (তবে কমপক্ষে পোস্টগ্রাসের আধুনিক সংস্করণগুলির জন্য) তবে আপনি যদি টেবিলটি ঘুরিয়ে ফিরিয়ে নিয়ে যাওয়ার পরিকল্পনাও করেন তবে আপনি সম্ভবত একটি সোজা কাটা কাটা, যা একটি ড্রপ + রেজিটেট (তাত্পর্যপূর্ণ) তুলনায় দ্রুত stick 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#11423886
কিছু historicalতিহাসিক দৃষ্টিকোণ যুক্ত করা হচ্ছে ...
একটি টেবিল ফেলে দেওয়ার জন্য বেশ কয়েকটি সিস্টেম সারণী আপডেট করা প্রয়োজন, যার ফলস্বরূপ সাধারণত একক লেনদেনে এই সিস্টেমের টেবিল পরিবর্তন করা প্রয়োজন (মনে করুন "ট্রান শুরু করুন, সাইকোলোমগুলি মুছুন, সিসোবজেক্টগুলি মুছুন, প্রতিশ্রুতিবদ্ধ করুন")।
'ড্রপ টেবিল'-এ অন্তর্ভুক্ত হ'ল টেবিলের সাথে সম্পর্কিত সমস্ত ডেটা / সূচী পৃষ্ঠাগুলি হ্রাস করা প্রয়োজন।
অনেকগুলি, বহু বছর আগে ... স্থান নির্ধারণের প্রক্রিয়াটি লেনদেনে অন্তর্ভুক্ত ছিল যা সিস্টেম টেবিলগুলিও আপডেট করেছিল; নেট ফলাফলটি বরাদ্দকৃত পৃষ্ঠাগুলির সংখ্যা যত বেশি, পৃষ্ঠাগুলি হ্রাস করতে যত বেশি সময় লেগেছিল তত দীর্ঘতর লেনদেন (সিস্টেম টেবিলগুলিতে) উন্মুক্ত রেখে দেওয়া হয়েছিল, এবং এইভাবে টেম্পডবিতে টেবিলগুলি তৈরি / ড্রপ করার চেষ্টা করা অন্যান্য প্রক্রিয়াগুলি (সিস্টেম টেবিলগুলিতে) ব্লক করার আরও বেশি সম্ভাবনা রয়েছে (বিশেষত পুরানো allpages == পৃষ্ঠা-স্তরের লকিং এবং টেবিলের সম্ভাব্যতাগুলির সাথে খারাপ) -ব্যাধি লক বৃদ্ধি)।
সিস্টেম টেবিলগুলিতে বিতর্ক হ্রাস করার জন্য প্রথম দিকের পদ্ধতিটি (তখন ফিরে যাওয়ার) পদ্ধতিটি ছিল টেবিলগুলি সিস্টেম টেবিলগুলিতে রাখা সময়টি হ্রাস করা এবং এটি করার একটি সহজ উপায় (অপেক্ষাকৃত) সহজ উপায় হ'ল ডেটা / সূচী পৃষ্ঠাগুলি ছাড়ার আগে টেবিল.
যদিও সমস্ত ডেটা / সূচী পৃষ্ঠাগুলি অপসারণ truncate tableকরে না , এটি একটি 8-পৃষ্ঠার (ডেটা) পরিমাণ ব্যতীত সমস্তকে হ্রাস করে; অন্য 'হ্যাক' এর পরে টেবিলটি ফেলে দেওয়ার আগে সমস্ত সূচী ফেলে দেওয়া হয়েছিল (হ্যাঁ, সিসিনডেক্সে আলাদা আলাদা টেক্সএন তবে ড্রপ টেবিলের জন্য একটি ছোট টেক্সএন)।
যখন আপনি বিবেচনা (আবার, অনেক, অনেক বছর আগে) শুধু একক 'tempdb' ডাটাবেসের ছিল, এখন আর কিছু অ্যাপ্লিকেশন তৈরি হেভি যে একক 'tempdb' ডাটাবেস-এর ব্যবহার কোনো 'হ্যাক' করে সিস্টেম টেবিলের উপর বিবাদের কমাতে পারে 'টেম্পডিবি' উপকারী ছিল; সময়ের সাথে সাথে উন্নতি হয়েছে ... একাধিক অস্থায়ী ডাটাবেস, সিস্টেম টেবিলগুলিতে সারি-স্তরের লক করা, আরও ভাল বিলোপ পদ্ধতিগুলি ইত্যাদি
এর মধ্যে truncate tableকোডের মধ্যে রেখে দিলে ব্যবহারের কোনও ক্ষতি হয় না।
বিদেশী কী রয়েছে এমন টেবিলগুলির জন্য ট্রানসেট করা বোধগম্য। তবে অস্থায়ী টেবিলের জন্য কেবল ড্রপই যথেষ্ট
এর বিন্দুটি truncateহ'ল সরল এবং অকাট্যভাবে টেবিলের সমস্ত কিছু সরিয়ে ফেলা (ডেটা স্টোর ইঞ্জিনগুলির উপর ভিত্তি করে কিছু প্রযুক্তিগত বৈশিষ্ট্য কিছুটা আলাদা হতে পারে) - ভারী লগিং এড়ানো ইত্যাদি ipping
drop tableসমস্ত পরিবর্তন লগ হিসাবে পরিবর্তন করা হচ্ছে। সুতরাং, ন্যূনতম লগিং করতে এবং অকেজো সিস্টেমের মন্থকে কমাতে, আমি সন্দেহ করব যে একটি খুব বড় টেবিলটি প্রথমে কেটে যাবে, পরে বাদ দেওয়া হবে।
truncate কোনও লেনদেনের মধ্যে আবৃত থাকতে পারে (যা সবচেয়ে নিরাপদ বিকল্প হতে পারে) যা অবশ্যই আপনাকে অপারেশনটি ফিরিয়ে আনতে দেয়।