เหตุใดจึงตัดทอนตาราง temp ที่ส่วนท้ายของโพรซีเดอร์ที่เก็บไว้ซึ่งสร้างพื้นที่ว่าง tempdb ให้เร็วขึ้น?


12

SQL Server แคชตาราง temp ที่สร้างขึ้นภายในโพรซีเดอร์ที่เก็บไว้และเปลี่ยนชื่อเพียงเมื่อโพรซีเดอร์สิ้นสุดลงและถูกเรียกใช้งานในภายหลัง คำถามของฉันเกี่ยวกับเมื่อมีการปล่อยพื้นที่ tempdb ผมเคยอ่านว่าตารางจะถูกตัดทอนในตอนท้ายของขั้นตอนที่ ฉันได้อ่านความคิดเห็นว่าสิ่งนี้ได้รับการจัดการในแต่ละช่วงและเห็นคำถามว่าจำเป็นต้องตอบคำถามเกี่ยวกับการล้างข้อมูลบน MSDNหรือไม่ แต่ถ้าหากมันไม่ถูกดำเนินการโดยเซสชั่นเดียวกันสองครั้ง?

ฉันเคยได้ยินว่ามีกระบวนการเก็บรวบรวมขยะในพื้นหลังที่ทำให้มีพื้นที่ว่างเมื่อตารางไม่อยู่ในขอบเขต

การตัดทอนตาราง temp ที่ส่วนท้ายของโพรซีเดอร์ที่เก็บไว้ซึ่งทำให้ดูเหมือนว่าพื้นที่ที่ตารางใช้ใน tempdb สำหรับข้อมูลที่จะเผยแพร่เร็วกว่าถ้าไม่มีการใช้คำสั่ง truncate แม้จะมีความคาดหวังที่ตรงกันข้าม ทำไม?

อะไรคือความสัมพันธ์ของประสิทธิภาพในการใช้งานหรือไม่ใช้คำสั่งตัดทอน เมื่อใช้การแยก SNAPSHOT, tempdb มักจะเครียดและฉันคิดว่าการปล่อยพื้นที่ที่ใช้ใน tempdb จากตาราง tempdb ขนาดใหญ่โดยเร็วที่สุดจะช่วยป้องกันไม่ให้ 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]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS BeforeTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;
 --   TRUNCATE TABLE #temp
    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS AfterTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;

END
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'before'
FROM tempdb.sys.dm_db_file_space_usage;

EXEC usp_test
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'final'
FROM tempdb.sys.dm_db_file_space_usage;
GO 40

บรรทัดที่ถูกใส่ความคิดเห็นถูกทิ้งไว้ให้ใส่ความคิดเห็นสำหรับการวิ่งบางอย่าง เมื่อTRUNCATEถูกใส่ความคิดเห็นจะใช้เวลาระหว่าง 2.25 ถึง 4.5 วินาทีก่อนผลลัพธ์ของtempdb.sys.dm_db_file_space_usageแบบสอบถาม (4472 หน้าเพิ่มเติมและใหญ่กว่า 34.9375 MB) ตรงกับผลลัพธ์ก่อนที่จะดำเนินการตามขั้นตอน เมื่อใช้บรรทัด (รวมถึงTRUNCATE) ยกเลิกการแสดงความคิดเห็นจะใช้เวลาประมาณ 0.11 - 0.9 วินาทีเท่านั้น ผลลัพธ์เหล่านี้มาจากระบบที่ใช้งานจริงโดยมีการเติบโตเล็กน้อยของข้อมูลในตารางต้นฉบับในระหว่างการทดสอบนี้

เอาต์พุตตัวอย่างพร้อมโค้ดที่ใส่เครื่องหมายคอมเม้นต์ (2.69 วินาทีจากรายการ "สุดท้าย" ครั้งแรก):

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:42.197

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.423

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.533

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.643

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.883

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.990

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.100

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.450

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.650

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.767

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.993

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.103

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.213

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.437

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.553

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.663

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.887

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:45.003

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:45.113

ผลลัพธ์ตัวอย่างพร้อมโค้ดที่ไม่ได้คอมเม้น (0.11 วินาทีจากรายการ "สุดท้าย" ครั้งแรก):

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:39.807

user object pages used user object space in MB                 BeforeTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

user object pages used user object space in MB                 AfterTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:40.160

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:40.270

คำตอบ:


12

การตัดทอนตาราง temp ที่ส่วนท้ายของโพรซีเดอร์ที่เก็บไว้ซึ่งทำให้ดูเหมือนว่าพื้นที่ที่ตารางใช้ใน tempdb สำหรับข้อมูลที่จะเผยแพร่เร็วกว่าถ้าไม่มีการใช้คำสั่ง truncate แม้จะมีความคาดหวังที่ตรงกันข้าม ทำไม?

หากตารางชั่วคราวมีขนาดใหญ่พอ ( เกิน 128 extents ) การยกเลิกการจัดสรรหน้าฟิสิคัลจะถูกเลื่อนออกไปและดำเนินการโดยงานระบบเบื้องหลัง สิ่งนี้เป็นจริงไม่ว่าจะใช้อย่างชัดเจนTRUNCATE TABLEหรือไม่ก็ตาม

ความแตกต่างเพียงอย่างเดียวคือรายละเอียดการใช้งานเล็กน้อย เกิดความชัดเจนTRUNCATE TABLEในการสร้างงานที่มีตัวจับเวลาสั้นกว่างานปล่อยเลื่อนที่เลื่อนออกไป (เหมือนกัน) ที่สร้างโดยการล้างตารางชั่วคราว:

โทรสแต็คเพราะคนชอบพวกเขา

ไม่ว่าจะโดยอุบัติเหตุหรือการออกแบบก็เป็นสิ่งที่ทุกคนคาดเดา แน่นอนว่ามันอาจเปลี่ยนแปลงได้ตลอดเวลาเนื่องจากรายละเอียดระดับนี้ไปไกลกว่าพื้นที่ผิวผลิตภัณฑ์ที่รองรับ

หากคุณปิดใช้งานการเลื่อนที่เลื่อนออกไปทั่วโลกด้วยการตั้งค่าสถานะการสืบค้นกลับ (ส่วนใหญ่) ที่ไม่มีเอกสาร:

DBCC TRACEON (671, -1);

... การจัดสรรคืนจะดำเนินการพร้อมกันในทั้งสองกรณีและคุณจะไม่เห็นความแตกต่างในเวลา

อะไรคือความสัมพันธ์ของประสิทธิภาพในการใช้งานหรือไม่ใช้คำสั่งตัดทอน เมื่อใช้การแยก SNAPSHOT, tempdb มักจะเครียดและฉันคิดว่าการปล่อยพื้นที่ที่ใช้ใน tempdb จากตาราง tempdb ขนาดใหญ่โดยเร็วที่สุดจะช่วยป้องกันไม่ให้ tempdb เติบโตอย่างไม่จำเป็น การประหยัดพื้นที่ที่มีศักยภาพนี้จะมาพร้อมกับประสิทธิภาพหรือไม่

ฉันสงสัยอย่างจริงจังว่าสิ่งนี้จะสร้างความแตกต่างได้มากเช่นกัน หากtempdbมีขนาดที่เหมาะสมกับความต้องการสูงสุดของปริมาณงานของคุณไม่ว่าการปล่อยแบบเลื่อนที่เกิดขึ้นจะเกิดขึ้นหลังจากหนึ่งวินาทีหรือสามวินาทีก็ตาม งานเดียวกันเสร็จแล้ว มันเป็นเพียงความแตกต่างเล็กน้อยในเวลา

ในทางกลับกัน: หากคุณรู้สึกสะดวกสบายในการใช้TRUNCATE TABLEกับตารางชั่วคราวเมื่อสิ้นสุดขั้นตอนการจัดเก็บของคุณ ฉันไม่ได้ตระหนักถึงข้อเสียของการทำเช่นนี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.