ฉันไม่ใช่ผู้เชี่ยวชาญ SQL และฉันนึกถึงความจริงทุกครั้งที่ฉันต้องทำอะไรบางอย่างที่นอกเหนือจากพื้นฐาน ฉันมีฐานข้อมูลทดสอบที่มีขนาดไม่ใหญ่มาก แต่มีการบันทึกธุรกรรมอย่างแน่นอน ฉันจะล้างบันทึกธุรกรรมได้อย่างไร

การทำล็อกไฟล์ให้เล็กลงควรสำรองไว้สำหรับสถานการณ์ที่พบการเติบโตที่ไม่คาดคิดซึ่งคุณไม่คาดว่าจะเกิดขึ้นอีก หากไฟล์บันทึกจะขยายขนาดเท่าเดิมอีกครั้งจะไม่สามารถทำได้โดยลดขนาดลงชั่วคราว ตอนนี้ขึ้นอยู่กับเป้าหมายการกู้คืนของฐานข้อมูลของคุณเหล่านี้คือการกระทำที่คุณควรดำเนินการ

ก่อนทำการสำรองข้อมูลเต็มรูปแบบ

อย่าทำการเปลี่ยนแปลงใด ๆ กับฐานข้อมูลของคุณโดยไม่ทำให้แน่ใจว่าคุณสามารถกู้คืนได้หากมีสิ่งผิดปกติเกิดขึ้น

หากคุณสนใจเกี่ยวกับการกู้คืนในเวลา

(และจากการกู้คืนแบบตรงเวลาหมายถึงคุณสนใจที่จะสามารถกู้คืนสิ่งอื่นนอกเหนือจากการสำรองข้อมูลเต็มรูปแบบหรือส่วนต่าง)

สันนิษฐานว่าฐานข้อมูลของคุณอยู่ในFULLโหมดการกู้คืน ถ้าไม่เช่นนั้นให้แน่ใจว่ามันเป็น:

ALTER DATABASE testdb SET RECOVERY FULL;

แม้ว่าคุณจะทำการสำรองข้อมูลเต็มรูปแบบเป็นประจำ แต่ไฟล์บันทึกจะขยายตัวและเติบโตขึ้นจนกว่าคุณจะทำการสำรองข้อมูลบันทึก - นี่คือเพื่อการป้องกันของคุณไม่จำเป็นต้องกินพื้นที่ดิสก์ของคุณโดยไม่จำเป็น คุณควรทำการสำรองข้อมูลบันทึกเหล่านี้ค่อนข้างบ่อยตามวัตถุประสงค์การกู้คืนของคุณ ตัวอย่างเช่นหากคุณมีกฎธุรกิจที่ระบุว่าคุณสามารถที่จะสูญเสียข้อมูลไม่เกิน 15 นาทีในกรณีที่เกิดภัยพิบัติคุณควรมีงานที่สำรองข้อมูลบันทึกทุก ๆ 15 นาที นี่คือสคริปต์ที่จะสร้างชื่อไฟล์ที่ประทับเวลาตามเวลาปัจจุบัน (แต่คุณสามารถทำได้ด้วยแผนการบำรุงรักษาและอื่น ๆ เพียงไม่เลือกตัวเลือกการย่อขนาดใด ๆ ในแผนการบำรุงรักษามันแย่มาก)

DECLARE @path NVARCHAR(255) = N'\\backup_share\log\testdb_' 
  + CONVERT(CHAR(8), GETDATE(), 112) + '_'
  + REPLACE(CONVERT(CHAR(8), GETDATE(), 108),':','')
  + '.trn';

BACKUP LOG foo TO DISK = @path WITH INIT, COMPRESSION;

โปรดทราบว่า\\backup_share\ควรอยู่ในเครื่องที่แตกต่างซึ่งแสดงถึงอุปกรณ์เก็บข้อมูลพื้นฐานที่แตกต่างกัน การสำรองข้อมูลเหล่านี้ไปยังเครื่องเดียวกัน (หรือไปยังเครื่องอื่นที่ใช้ดิสก์พื้นฐานเดียวกันหรือ VM อื่นที่อยู่บนโฮสต์ทางกายภาพเดียวกัน) ไม่ได้ช่วยคุณจริงๆเพราะถ้าเครื่องระเบิดคุณสูญเสียฐานข้อมูลของคุณและการสำรองข้อมูล ขึ้นอยู่กับโครงสร้างพื้นฐานเครือข่ายของคุณมันอาจเหมาะสมกว่าที่จะสำรองข้อมูลในเครื่องจากนั้นโอนไปยังตำแหน่งอื่นที่อยู่เบื้องหลัง ไม่ว่าในกรณีใดคุณต้องการนำเครื่องออกจากฐานข้อมูลหลักโดยเร็วที่สุด

ตอนนี้เมื่อคุณมีการสำรองข้อมูลล็อกปกติแล้วมันควรจะมีเหตุผลที่จะทำให้ไฟล์บันทึกย่อมีขนาดเล็กลงกว่าที่เคยเป็นมาในตอนนี้ นี่ไม่ได้หมายถึงการรันSHRINKFILEซ้ำแล้วซ้ำอีกจนกว่าไฟล์บันทึกจะมีขนาด 1 MB - แม้ว่าคุณจะสำรองข้อมูลบันทึกเป็นประจำ แต่ก็ยังจำเป็นต้องรองรับผลรวมของธุรกรรมที่เกิดขึ้นพร้อมกัน เหตุการณ์ autogrow ของแฟ้มบันทึกมีราคาแพงเนื่องจาก SQL Server มีค่าเป็นศูนย์ (ไม่เหมือนกับไฟล์ข้อมูลเมื่อเปิดใช้งานการเริ่มต้นไฟล์ทันที) และธุรกรรมของผู้ใช้จะต้องรอในขณะที่เกิดเหตุการณ์นี้ขึ้น คุณต้องการที่จะทำกิจวัตรการหดตัวการเติบโตหดตัวให้น้อยที่สุดเท่าที่จะเป็นไปได้และแน่นอนว่าคุณไม่ต้องการให้ผู้ใช้จ่ายเงิน

โปรดทราบว่าคุณอาจต้องสำรองข้อมูลบันทึกสองครั้งก่อนที่จะทำการย่อขนาด (ขอบคุณ Robert)

ดังนั้นคุณต้องหาขนาดที่เหมาะสมสำหรับไฟล์บันทึกของคุณ ไม่มีใครที่นี่สามารถบอกคุณได้ว่าอะไรคือสิ่งที่โดยไม่รู้ตัวมากขึ้นเกี่ยวกับระบบของคุณ แต่ถ้าคุณมักจะลดขนาดแฟ้มบันทึกและมีการเติบโตอีกครั้งลายน้ำที่ดีน่าจะสูงกว่า 10-50% ที่ใหญ่ที่สุด . สมมติว่ามีขนาด 200 MB และคุณต้องการให้เหตุการณ์ autogrowth ที่ตามมาเป็น 50 MB จากนั้นคุณสามารถปรับขนาดล็อกไฟล์ด้วยวิธีนี้:

USE [master];
GO
ALTER DATABASE Test1 
  MODIFY FILE
  (NAME = yourdb_log, SIZE = 200MB, FILEGROWTH = 50MB);
GO

โปรดทราบว่าหากไฟล์บันทึกปัจจุบัน> 200 MB คุณอาจต้องเรียกใช้ไฟล์นี้ก่อน:

USE yourdb;
GO
DBCC SHRINKFILE(yourdb_log, 200);
GO

หากคุณไม่สนใจเกี่ยวกับการกู้คืนในเวลา

หากนี่คือฐานข้อมูลทดสอบและคุณไม่สนใจเกี่ยวกับการกู้คืนในเวลานั้นคุณควรตรวจสอบให้แน่ใจว่าฐานข้อมูลของคุณอยู่ในSIMPLEโหมดการกู้คืน

ALTER DATABASE testdb SET RECOVERY SIMPLE;

การวางฐานข้อมูลในSIMPLEโหมดการกู้คืนจะทำให้แน่ใจว่า SQL Server จะใช้บางส่วนของไฟล์บันทึกอีกครั้ง (โดยจะยกเลิกการทำธุรกรรมที่ไม่ใช้งาน) แทนการเติบโตเพื่อเก็บบันทึกการทำธุรกรรมทั้งหมด (เช่นFULLการกู้คืนจนกว่าจะสำรองข้อมูล) CHECKPOINTเหตุการณ์จะช่วยควบคุมการบันทึกและตรวจสอบให้แน่ใจว่ามันไม่จำเป็นต้องเติบโตเว้นแต่คุณจะสร้างกิจกรรม t-log จำนวนมากระหว่างCHECKPOINTs

ถัดไปคุณควรตรวจสอบให้แน่ใจว่าการเติบโตของบันทึกนี้เกิดขึ้นเนื่องจากเหตุการณ์ที่ผิดปกติ (เช่นการทำความสะอาดฤดูใบไม้ผลิประจำปีหรือสร้างดัชนีที่ยิ่งใหญ่ที่สุดของคุณใหม่) และไม่ได้เกิดจากการใช้งานปกติทุกวัน หากคุณลดขนาดไฟล์บันทึกให้เล็กลงอย่างน่าขันและ SQL Server ก็ต้องขยายเพิ่มอีกครั้งเพื่อรองรับกิจกรรมปกติของคุณคุณได้อะไรมาบ้าง คุณสามารถใช้ประโยชน์จากพื้นที่ว่างในดิสก์ที่คุณเพิ่มขึ้นชั่วคราวได้หรือไม่? หากคุณต้องการการแก้ไขทันทีคุณสามารถเรียกใช้สิ่งต่อไปนี้:

USE yourdb;
GO
CHECKPOINT;
GO
CHECKPOINT; -- run twice to ensure file wrap-around
GO
DBCC SHRINKFILE(yourdb_log, 200); -- unit is set in MBs
GO

มิฉะนั้นให้กำหนดขนาดและอัตราการเติบโตที่เหมาะสม ตามตัวอย่างในกรณีการกู้คืน ณ จุดเวลาคุณสามารถใช้รหัสและตรรกะเดียวกันเพื่อกำหนดขนาดไฟล์ที่เหมาะสมและตั้งค่าพารามิเตอร์ autogrowth ที่เหมาะสม

บางสิ่งที่คุณไม่ต้องการทำ

• สำรองล็อกกับTRUNCATE_ONLYSHRINKFILEตัวเลือกแล้ว สำหรับTRUNCATE_ONLYตัวเลือกนี้เลิกใช้แล้วและไม่สามารถใช้งานได้ใน SQL Server เวอร์ชันปัจจุบันอีกต่อไป ประการที่สองหากคุณอยู่ในFULLรูปแบบการกู้คืนสิ่งนี้จะทำลายห่วงโซ่การบันทึกของคุณและต้องการการสำรองข้อมูลใหม่ที่สมบูรณ์

• ถอดฐานข้อมูลลบล็อกไฟล์และอีกครั้งแนบ ฉันไม่สามารถเน้นความอันตรายนี้ได้ ฐานข้อมูลของคุณอาจไม่กลับมามันอาจเกิดขึ้นในฐานะผู้ต้องสงสัยคุณอาจต้องเปลี่ยนกลับเป็นข้อมูลสำรอง (ถ้าคุณมี) และอื่น ๆ

• ใช้ "ฐานข้อมูลหดตัวเลือก" DBCC SHRINKDATABASEและตัวเลือกแผนการบำรุงรักษาที่จะทำเช่นเดียวกันคือแนวคิดที่ไม่ดีโดยเฉพาะถ้าคุณต้องการแก้ไขปัญหาบันทึกเท่านั้น กำหนดเป้าหมายไฟล์ที่คุณต้องการปรับและปรับแต่งอย่างอิสระโดยใช้DBCC SHRINKFILEหรือALTER DATABASE ... MODIFY FILE(ตัวอย่างด้านบน)

• หดล็อกไฟล์ 1 MB สิ่งนี้ดูน่าดึงดูดเพราะเฮ้, SQL Server จะให้ฉันทำในบางสถานการณ์และดูที่ว่างทั้งหมด! ยกเว้นว่าฐานข้อมูลของคุณจะอ่านอย่างเดียว (และคุณควรทำเครื่องหมายว่าเป็นการใช้ALTER DATABASE) สิ่งนี้จะนำไปสู่เหตุการณ์การเติบโตที่ไม่จำเป็นจำนวนมากอย่างแน่นอนเนื่องจากบันทึกจะต้องรองรับธุรกรรมปัจจุบันโดยไม่คำนึงถึงรูปแบบการกู้คืน อะไรคือประเด็นของการเพิ่มพื้นที่ว่างชั่วคราวเพื่อให้ SQL Server สามารถนำมันกลับมาช้าและเจ็บปวด?

• สร้างแฟ้มบันทึกที่สอง สิ่งนี้จะช่วยบรรเทาปัญหาชั่วคราวสำหรับไดรฟ์ที่เต็มดิสก์ของคุณ แต่มันก็เหมือนกับการพยายามแก้ไขปอดที่ถูกเจาะด้วยเครื่องช่วยฟัง คุณควรจัดการกับไฟล์บันทึกปัญหาโดยตรงแทนที่จะเพิ่มปัญหาอื่นที่อาจเกิดขึ้น นอกเหนือจากการเปลี่ยนเส้นทางกิจกรรมการทำธุรกรรมบางอย่างไปยังไดรฟ์อื่นแล้วไฟล์บันทึกที่สองไม่ได้ทำอะไรให้คุณจริงๆ (ต่างจากไฟล์ข้อมูลที่สอง) เนื่องจากไฟล์เพียงไฟล์เดียวเท่านั้นที่สามารถใช้ได้ในแต่ละครั้ง Paul Randal อธิบายว่าทำไมไฟล์บันทึกหลายไฟล์จึงสามารถกัดคุณในภายหลังได้

เป็นเชิงรุก

แทนที่จะย่อขนาดไฟล์บันทึกของคุณให้เล็กลงและปล่อยให้ autogrow อย่างต่อเนื่องในอัตราที่น้อยด้วยตัวเองตั้งค่าให้มีขนาดใหญ่พอสมควร (หนึ่งที่จะรองรับผลรวมของธุรกรรมที่เกิดขึ้นพร้อมกันที่ใหญ่ที่สุดของคุณ) การตั้งค่าเป็นทางเลือกเพื่อที่จะไม่ต้องเติบโตหลายครั้งเพื่อตอบสนองการทำธุรกรรมเดียวและเพื่อให้มันจะค่อนข้างหายากสำหรับมันจะต้องเคยเติบโตในระหว่างการดำเนินธุรกิจตามปกติ

การตั้งค่าที่แย่ที่สุดที่เป็นไปได้คือการเติบโต 1 MB หรือการเติบโต 10% ตลกมากสิ่งเหล่านี้เป็นค่าเริ่มต้นสำหรับ SQL Server (ซึ่งฉันได้ร้องเรียนและขอการเปลี่ยนแปลงที่ไม่มีประโยชน์ ) - 1 MB สำหรับไฟล์ข้อมูลและ 10% สำหรับไฟล์บันทึก อดีตมีขนาดเล็กเกินไปในวันนี้และอายุและหลังนำไปสู่เหตุการณ์ที่ยาวและนานขึ้นทุกครั้ง (พูดล็อกไฟล์ของคุณคือ 500 MB การเติบโตครั้งแรกคือ 50 MB การเติบโตครั้งต่อไปคือ 55 MB การเติบโตต่อไปคือ 60.5 MB ฯลฯ ฯลฯ - และใน I / O ที่ช้าเชื่อฉันคุณจะสังเกตเห็นความโค้งนี้)

อ่านเพิ่มเติม

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

โพสต์บล็อกที่ผมเขียนในปี 2009 เมื่อผมเห็นไม่กี่ "นี่เป็นวิธีที่จะหดตัวลงล็อกไฟล์" โพสต์สปริงขึ้น

โพสต์บล็อก Brent Ozar เขียนสี่ปีที่ผ่านมาชี้ไปยังแหล่งข้อมูลหลายในการตอบสนองไปยังบทความนิตยสาร SQL Server ที่ควรจะไม่ได้รับการตีพิมพ์

โพสต์บล็อกโดยพอล Randal อธิบายว่าทำไมการบำรุงรักษาเสื้อล็อกเป็นสิ่งสำคัญและเหตุผลที่คุณไม่ควรลดขนาดแฟ้มข้อมูลของคุณอย่างใดอย่างหนึ่ง

ไมค์วอลช์มีคำตอบที่ดีครอบคลุมบางส่วนของแง่มุมเหล่านี้มากเกินไปรวมทั้งเหตุผลที่คุณอาจจะไม่สามารถที่จะหดตัวล็อกไฟล์ของคุณทันที

-- DON'T FORGET TO BACKUP THE DB :D (Check [here][1]) 


USE AdventureWorks2008R2;
GO
-- Truncate the log by changing the database recovery model to SIMPLE.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY SIMPLE;
GO
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (AdventureWorks2008R2_Log, 1);
GO
-- Reset the database recovery model.
ALTER DATABASE AdventureWorks2008R2
SET RECOVERY FULL;
GO

จาก: DBCC SHRINKFILE (Transact-SQL)

คุณอาจต้องการสำรองข้อมูลก่อน

การปฏิเสธความรับผิด:โปรดอ่านความคิดเห็นด้านล่างอย่างระมัดระวังและฉันคิดว่าคุณได้อ่านคำตอบที่ยอมรับแล้ว อย่างที่ฉันพูดเกือบ 5 ปีที่แล้ว:

หากใครมีความคิดเห็นใด ๆ ที่จะเพิ่มสำหรับสถานการณ์เมื่อนี่ไม่ใช่ทางออกที่เพียงพอหรือดีที่สุดโปรดแสดงความคิดเห็นด้านล่าง

• คลิกขวาที่ชื่อฐานข้อมูล

• เลือกงาน→ลดขนาด→ฐานข้อมูล

• จากนั้นคลิกOK!

ฉันมักจะเปิดไดเรกทอรี Windows Explorer ที่มีไฟล์ฐานข้อมูลดังนั้นฉันจะเห็นผลทันที

จริง ๆ แล้วฉันก็ประหลาดใจมากที่งานนี้! โดยปกติแล้วฉันเคยใช้ DBCC มาก่อน แต่ฉันเพิ่งลองมาแล้วและมันก็ไม่ได้ลดขนาดลงเลยดังนั้นฉันจึงลองใช้ GUI (2005) และใช้งานได้ดีมาก - เพิ่มขึ้น 17 GB ใน 10 วินาที

ในโหมดการกู้คืนแบบเต็มอาจไม่ทำงานดังนั้นคุณต้องสำรองข้อมูลบันทึกก่อนหรือเปลี่ยนเป็นการกู้คืนแบบง่ายจากนั้นย่อขนาดไฟล์ [ขอบคุณ @onupdatecascade สำหรับสิ่งนี้]

-

PS: ฉันซาบซึ้งในสิ่งที่บางคนแสดงความคิดเห็นเกี่ยวกับอันตรายของสิ่งนี้ แต่ในสภาพแวดล้อมของฉันฉันไม่มีปัญหาในการทำสิ่งนี้ด้วยตัวเองโดยเฉพาะอย่างยิ่งเนื่องจากฉันทำการสำรองข้อมูลเต็มรูปแบบก่อนเสมอ ดังนั้นโปรดคำนึงถึงสภาพแวดล้อมของคุณและสิ่งนี้มีผลต่อกลยุทธ์การสำรองข้อมูลและความปลอดภัยของงานของคุณก่อนดำเนินการต่อ ทั้งหมดที่ฉันทำคือการชี้ให้คนอื่นเห็นคุณลักษณะที่ Microsoft จัดเตรียมไว้!

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

หากคุณลดขนาดไฟล์ลงคุณจะสูญเสียข้อมูลจำนวนมากซึ่งอาจเป็นเครื่องมือช่วยชีวิตในกรณีที่เกิดภัยพิบัติ บันทึกธุรกรรมประกอบด้วยข้อมูลที่มีประโยชน์มากมายที่สามารถอ่านได้โดยใช้เครื่องอ่านบันทึกธุรกรรมของบุคคลที่สาม (สามารถอ่านได้ด้วยตนเอง แต่ต้องใช้ความพยายามอย่างที่สุด)

บันทึกการทำธุรกรรมเป็นสิ่งที่จำเป็นเมื่อถึงเวลาที่ต้องกู้คืนดังนั้นอย่าเพิ่งโยนทิ้ง แต่ให้แน่ใจว่าคุณสำรองไว้ล่วงหน้า

นี่คือโพสต์หลายแห่งที่ผู้คนใช้ข้อมูลที่เก็บไว้ในบันทึกธุรกรรมเพื่อให้การกู้คืนสำเร็จ:

• วิธีดูบันทึกธุรกรรมใน SQL Server 2008

• อ่านไฟล์บันทึก (* .LDF) ใน SQL Server 2008

USE DATABASE_NAME;
GO

ALTER DATABASE DATABASE_NAME
SET RECOVERY SIMPLE;
GO
--First parameter is log file name and second is size in MB
DBCC SHRINKFILE (DATABASE_NAME_Log, 1);

ALTER DATABASE DATABASE_NAME
SET RECOVERY FULL;
GO

คุณอาจได้รับข้อผิดพลาดที่มีลักษณะเช่นนี้เมื่อคำสั่งดำเนินการด้านบน

“ ไม่สามารถย่อขนาดไฟล์ล็อก (ชื่อไฟล์บันทึก) เนื่องจากไฟล์บันทึกแบบลอจิคัลที่อยู่ท้ายไฟล์ใช้งานอยู่ "

นี่หมายความว่า TLOG ถูกใช้งานอยู่ ในกรณีนี้ลองดำเนินการนี้หลายครั้งในแถวหรือหาวิธีลดกิจกรรมฐานข้อมูล

นี่คือที่เรียบง่ายและงดงามมากและอาจเป็นอันตราย วิธี

1. สำรองฐานข้อมูล
2. แยกฐานข้อมูล
3. เปลี่ยนชื่อไฟล์บันทึก
4. แนบฐานข้อมูล
5. ไฟล์บันทึกใหม่จะถูกสร้างขึ้นใหม่
6. ลบไฟล์บันทึกที่เปลี่ยนชื่อ

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

หากคุณไม่ใช้บันทึกธุรกรรมเพื่อคืนค่า (เช่นคุณสำรองข้อมูลเต็มรูปแบบเท่านั้น) คุณสามารถตั้งค่าโหมดการกู้คืนเป็น "ง่าย" และบันทึกธุรกรรมจะหายไปในไม่ช้าและไม่เคยเติมให้เต็ม

หากคุณใช้ SQL 7 หรือ 2000 คุณสามารถเปิดใช้งาน "ตัดทอนล็อกออนจุดตรวจสอบ" ในแท็บตัวเลือกฐานข้อมูล สิ่งนี้มีผลเหมือนกัน

สิ่งนี้ไม่ได้รับการแนะนำในสภาพแวดล้อมการผลิตอย่างชัดเจนเนื่องจากคุณจะไม่สามารถกู้คืนสู่เวลาได้

เทคนิคนี้ที่ John แนะนำไม่แนะนำเนื่องจากไม่มีการรับประกันว่าฐานข้อมูลจะแนบโดยไม่มีไฟล์บันทึก เปลี่ยนฐานข้อมูลจากเต็มเป็นแบบธรรมดาบังคับใช้จุดตรวจสอบและรอสักครู่ SQL Server จะล้างข้อมูลบันทึกซึ่งคุณสามารถย่อขนาดโดยใช้ DBCC SHRINKFILE

คำตอบส่วนใหญ่ที่นี่จะถือว่าคุณไม่จำเป็นต้องใช้ไฟล์บันทึกธุรกรรมจริง ๆ แต่ถ้าฐานข้อมูลของคุณใช้FULLโมเดลการกู้คืนและคุณต้องการเก็บสำรองข้อมูลของคุณไว้ในกรณีที่คุณต้องการกู้คืนฐานข้อมูลอย่าตัดทอนหรือลบ ล็อกไฟล์ตามที่หลายคำตอบแนะนำไว้

การกำจัดไฟล์บันทึก (ผ่านการตัดทอนลบทิ้งลบ ฯลฯ ) จะทำให้ห่วงโซ่การสำรองข้อมูลของคุณเสียหายและจะป้องกันไม่ให้คุณกู้คืนสู่จุดใด ๆ ได้ตลอดเวลานับตั้งแต่การสำรองข้อมูลเต็มความแตกต่างหรือการทำธุรกรรมครั้งล่าสุดของคุณ หรือมีการสำรองข้อมูลส่วนต่าง

จากบทความ Microsoft ในBACKUP

เราขอแนะนำว่าคุณไม่ควรใช้ NO_LOG หรือ TRUNCATE_ONLY เพื่อตัดทอนบันทึกธุรกรรมด้วยตนเองเพราะสิ่งนี้จะทำลายห่วงโซ่การบันทึก จนกว่าการสำรองฐานข้อมูลเต็มหรือส่วนต่างถัดไปฐานข้อมูลจะไม่ได้รับการป้องกันจากความล้มเหลวของสื่อ ใช้การตัดทอนบันทึกแบบแมนนวลในกรณีพิเศษเท่านั้นและสร้างการสำรองข้อมูลทันที

เพื่อหลีกเลี่ยงปัญหานี้ให้สำรองไฟล์บันทึกของคุณไปยังดิสก์ก่อนลดขนาด ไวยากรณ์จะมีลักษณะดังนี้:

BACKUP LOG MyDatabaseName 
TO DISK='C:\DatabaseBackups\MyDatabaseName_backup_2013_01_31_095212_8797154.trn'

DBCC SHRINKFILE (N'MyDatabaseName_Log', 200)

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

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

จาก10 ตำนานที่สำคัญที่สุดบันทึกธุรกรรม SQL Server :

ความเชื่อ: SQL Server ของฉันไม่ว่าง ฉันไม่ต้องการสำรองข้อมูลบันทึกธุรกรรม SQL Server

หนึ่งในการดำเนินงานที่เข้มข้นที่สุดใน SQL Server คือการเติบโตอัตโนมัติของไฟล์บันทึกธุรกรรมออนไลน์ โดยการไม่สำรองข้อมูลบันทึกธุรกรรมบ่อยเพียงพอบันทึกธุรกรรมออนไลน์จะเต็มและจะต้องเติบโต ขนาดการเติบโตเริ่มต้นคือ 10% ฐานข้อมูลมีจำนวนมากขึ้นความรวดเร็วของการบันทึกธุรกรรมออนไลน์จะเพิ่มขึ้นหากการสำรองข้อมูลบันทึกธุรกรรมไม่ได้สร้างการสำรองข้อมูลบันทึกธุรกรรม SQL Server ไม่ได้บล็อกการบันทึกธุรกรรมออนไลน์ แต่มีเหตุการณ์การเติบโตอัตโนมัติ สามารถบล็อกกิจกรรมทั้งหมดในบันทึกธุรกรรมออนไลน์

จากMyth Log ธุรกรรม :

ความเชื่อ: การหดตัวของบันทึกเป็นประจำเป็นการฝึกบำรุงรักษาที่ดี

FALSE การเติบโตของบันทึกมีราคาแพงมากเพราะก้อนใหม่จะต้องเป็นศูนย์ กิจกรรมการเขียนทั้งหมดจะหยุดบนฐานข้อมูลนั้นจนกว่าการทำ zeroing จะเสร็จสิ้นและหากการเขียนดิสก์ของคุณช้าหรือขนาด autogrowth มีขนาดใหญ่หยุดชั่วคราวอาจมีขนาดใหญ่และผู้ใช้จะสังเกตเห็น นั่นเป็นเหตุผลหนึ่งว่าทำไมคุณต้องการหลีกเลี่ยงการเติบโต หากคุณลดขนาดไฟล์บันทึกมันจะเพิ่มขึ้นอีกครั้งและคุณเพียงแค่สูญเสียการทำงานของดิสก์ในเกมลดขนาดและขยายอีกครั้งโดยไม่จำเป็น

ขั้นแรกให้ตรวจสอบรูปแบบการกู้คืนฐานข้อมูล โดยค่าเริ่มต้น SQL Server Express Edition จะสร้างฐานข้อมูลสำหรับรูปแบบการกู้คืนอย่างง่าย (ถ้าฉันไม่เข้าใจผิด)

สำรองข้อมูลชื่อฐานข้อมูลด้วย Truncate_Only:

DBCC ShrinkFile(yourLogical_LogFileName, 50)

SP_helpfile จะให้ชื่อไฟล์บันทึกแบบลอจิคัลแก่คุณ

อ้างถึง:

กู้คืนจากบันทึกธุรกรรมเต็มรูปแบบในฐานข้อมูล SQL Server

หากฐานข้อมูลของคุณอยู่ในรูปแบบการกู้คืนแบบเต็มและหากคุณไม่ได้ทำการสำรองข้อมูล TL ให้เปลี่ยนเป็น SIMPLE

ใช้DBCC ShrinkFile ({logicalLogName}, TRUNCATEONLY)คำสั่ง หากนี่คือฐานข้อมูลทดสอบและคุณพยายามบันทึก / เรียกคืนพื้นที่นี่จะช่วยได้

โปรดจำไว้ว่าบันทึกของ TX มีขนาดขั้นต่ำ / คงที่ซึ่งจะเติบโตได้ ขึ้นอยู่กับรุ่นการกู้คืนของคุณคุณอาจไม่สามารถย่อขนาดล็อกได้ - หากเป็นแบบเต็มและคุณไม่ได้ทำการสำรองข้อมูลล็อก TX ไว้ไฟล์บันทึกนั้นจะไม่สามารถหดได้ - มันจะเติบโตตลอดไป ถ้าคุณไม่จำเป็นต้องสำรองบันทึก TX, เปลี่ยนรูปแบบการกู้คืนของคุณจะง่าย

และจำไว้ว่าห้ามลบไฟล์ log (LDF) ไม่ว่าในกรณีใด ๆ ! คุณค่อนข้างจะมีฐานข้อมูลเสียหายทันที ปรุง! ทำ! ข้อมูลสูญหาย! หากปล่อยให้ "ไม่ทำการซ่อมแซม" ไฟล์ MDF หลักอาจเสียหายอย่างถาวร

ไม่เคยลบบันทึกธุรกรรม - คุณจะสูญเสียข้อมูล! ข้อมูลบางส่วนของคุณอยู่ใน TX Log (ไม่ว่าจะอยู่ในรูปแบบการกู้คืน) ... หากคุณแยกและ "เปลี่ยนชื่อ" ไฟล์บันทึก TX ที่ลบส่วนหนึ่งของฐานข้อมูลของคุณได้อย่างมีประสิทธิภาพ

สำหรับผู้ที่ลบบันทึก TX คุณอาจต้องการเรียกใช้คำสั่ง checkdb สองสามคำสั่งและแก้ไขความเสียหายก่อนที่คุณจะสูญเสียข้อมูลมากขึ้น

ตรวจสอบบล็อกโพสต์พอล Randal ในหัวข้อมากนี้คำแนะนำดี

นอกจากนี้โดยทั่วไปแล้วอย่าใช้ shrinkfile กับไฟล์ MDF เพราะอาจทำให้ข้อมูลของคุณเสียหายได้ ตรวจสอบส่วนคำแนะนำที่ไม่ดีของเขาสำหรับข้อมูลเพิ่มเติม ("ทำไมคุณไม่ควรย่อขนาดไฟล์ข้อมูลของคุณ")

ตรวจสอบเว็บไซต์ของ Paul - เขาครอบคลุมคำถามเหล่านี้มาก เมื่อเดือนที่แล้วเขาเดินผ่านปัญหาเหล่านี้หลายเรื่องในซีรีย์Myth A Day ของเขา

วิธีตัดทอนไฟล์บันทึก:

• สำรองฐานข้อมูล
• แยกฐานข้อมูลโดยใช้ Enterprise Manager หรือดำเนินการ: Sp_DetachDB [DBName]
• ลบไฟล์บันทึกธุรกรรม (หรือเปลี่ยนชื่อไฟล์ในกรณี)
• แนบฐานข้อมูลอีกครั้งโดยใช้: Sp_AttachDB [DBName]
• เมื่อแนบฐานข้อมูลแล้วไฟล์บันทึกธุรกรรมใหม่จะถูกสร้างขึ้น

ในการลดขนาดไฟล์บันทึก:

• บันทึกสำรอง [DBName] ด้วย No_Log

• ย่อขนาดฐานข้อมูลโดย:

  การใช้ตัวจัดการองค์กร: - คลิกขวาที่ฐานข้อมูล, งานทั้งหมด, ลดขนาดฐานข้อมูล, ไฟล์, เลือกไฟล์บันทึก, ตกลง

  ใช้ T-SQL: - Dbcc Shrinkfile ([Log_Logical_Name])

คุณสามารถค้นหาชื่อโลจิคัลของไฟล์บันทึกได้โดยการรัน sp_helpdb หรือค้นหาคุณสมบัติของฐานข้อมูลใน Enterprise Manager

ประสบการณ์ของฉันในเซิร์ฟเวอร์ SQL ส่วนใหญ่ไม่มีการสำรองข้อมูลของบันทึกธุรกรรม การสำรองข้อมูลเต็มรูปแบบหรือการสำรองข้อมูลส่วนต่างเป็นวิธีปฏิบัติทั่วไป แต่การสำรองข้อมูลบันทึกธุรกรรมเป็นสิ่งที่ไม่ค่อยมี ดังนั้นไฟล์บันทึกธุรกรรมจะเติบโตตลอดไป (จนกว่าดิสก์จะเต็ม) ในกรณีนี้รูปแบบการกู้คืนควรตั้งค่าเป็น " ง่าย " อย่าลืมแก้ไขฐานข้อมูลระบบ "model" และ "tempdb" ด้วย

การสำรองข้อมูลของฐานข้อมูล "tempdb" ไม่สมเหตุสมผลดังนั้นรูปแบบการกู้คืนของฐานข้อมูลนี้ควร "ง่าย" เสมอ

1. ทำการสำรองไฟล์ MDB
2. หยุดบริการ SQL
3. เปลี่ยนชื่อไฟล์บันทึก
4. เริ่มบริการ

(ระบบจะสร้างไฟล์บันทึกใหม่)

ลบหรือย้ายไฟล์บันทึกที่ถูกเปลี่ยนชื่อ

มันเกิดขึ้นกับฉันที่ไฟล์บันทึกฐานข้อมูลมีขนาด 28 GB

คุณจะทำอย่างไรเพื่อลดสิ่งนี้ ที่จริงแล้วล็อกไฟล์คือข้อมูลไฟล์ที่เซิร์ฟเวอร์ SQL เก็บไว้เมื่อมีการทำธุรกรรม สำหรับธุรกรรมที่ดำเนินการกับเซิร์ฟเวอร์ SQL จะจัดสรรหน้าให้เหมือนกัน แต่หลังจากเสร็จสิ้นการทำธุรกรรมเหล่านี้จะไม่ได้รับการปล่อยตัวในทันทีโดยหวังว่าอาจมีธุรกรรมที่เข้ามาเหมือนกัน สิ่งนี้ช่วยเพิ่มพื้นที่ว่าง

ขั้นตอนที่ 1: ครั้งแรกเรียกใช้คำสั่งนี้ในแบบสอบถามฐานข้อมูลสำรวจจุดตรวจสอบ

ขั้นตอนที่ 2: คลิกขวาที่ฐานข้อมูลงาน> สำรองเลือกชนิดสำรองเป็นบันทึกธุรกรรมเพิ่มที่อยู่ปลายทางและชื่อไฟล์เพื่อเก็บข้อมูลสำรอง (.bak)

ทำซ้ำขั้นตอนนี้อีกครั้งและในเวลานี้ให้ชื่อไฟล์อื่น

ขั้นตอนที่ 3: ตอนนี้ไปที่ฐานข้อมูลคลิกขวาบนฐานข้อมูล

ภารกิจ> ย่อส่วน> ไฟล์เลือกประเภทไฟล์เป็นแอคชันบันทึกย่อเนื่องจากปล่อยพื้นที่ที่ไม่ได้ใช้

ขั้นตอนที่ 4:

ตรวจสอบไฟล์บันทึกของคุณตามปกติใน SQL 2014 ซึ่งสามารถพบได้ที่

C: \ Program SQL Server \ MSSQL12.MSSQL2014EXPRESS \ MSSQL \ DATA SQL Server \ MSSQL12

ในกรณีของฉันมันลดลงจาก 28 GB เป็น 1 MB

ลองสิ่งนี้:

USE DatabaseName

GO

DBCC SHRINKFILE( TransactionLogName, 1)

BACKUP LOG DatabaseName WITH TRUNCATE_ONLY

DBCC SHRINKFILE( TransactionLogName, 1)

GO 

ฐานข้อมูล→คลิกขวาคุณสมบัติ →ไฟล์→เพิ่มไฟล์บันทึกอื่นที่มีชื่อแตกต่างกันและกำหนดเส้นทางเช่นเดียวกับไฟล์บันทึกเก่าที่มีชื่อไฟล์ที่แตกต่างกัน

ฐานข้อมูลจะรับไฟล์บันทึกที่สร้างขึ้นใหม่โดยอัตโนมัติ

1. สำรองฐานข้อมูล
2. แยกฐานข้อมูล
3. เปลี่ยนชื่อไฟล์บันทึก
4. แนบฐานข้อมูล (ในขณะที่แนบลบออกเปลี่ยนชื่อเป็น. ldf (ไฟล์บันทึกข้อมูล) เลือกแล้วลบออกโดยกดปุ่มลบ)
5. ไฟล์บันทึกใหม่จะถูกสร้างขึ้นใหม่
6. ลบไฟล์บันทึกที่เปลี่ยนชื่อ

วิธีนี้จะใช้งานได้ แต่ขอแนะนำให้สำรองข้อมูลของฐานข้อมูลของคุณก่อน

คำตอบอื่น ๆ ไม่ได้ผลสำหรับฉัน: มันเป็นไปไม่ได้ที่จะสร้างจุดตรวจสอบในขณะที่ db ออนไลน์อยู่เพราะบันทึกธุรกรรมเต็ม (แดกดัน) อย่างไรก็ตามหลังจากตั้งค่าฐานข้อมูลเป็นโหมดฉุกเฉินฉันสามารถลดขนาดไฟล์บันทึกได้:

alter database <database_name> set emergency;
use <database_name>;
checkpoint;
checkpoint;
alter database <database_name> set online;
dbcc shrinkfile(<database_name>_log, 200);

ตัวอย่าง:

DBCC SQLPERF(LOGSPACE)

BACKUP LOG Comapny WITH TRUNCATE_ONLY

DBCC SHRINKFILE (Company_log, 500)

DBCC SQLPERF(LOGSPACE)

คำตอบอัพเดทเล็กน้อยสำหรับ MSSQL 2017 และใช้สตูดิโอจัดการเซิร์ฟเวอร์ SQL ฉันไปจากคำแนะนำเหล่านี้เป็นส่วนใหญ่https://www.sqlshack.com/sql-server-transaction-log-backup-truncate-and-shrink-operations/

ฉันมีการสำรองฐานข้อมูลล่าสุดดังนั้นฉันจึงสำรองบันทึกธุรกรรม จากนั้นฉันก็สำรองข้อมูลอีกครั้งเพื่อการวัดที่ดี ในที่สุดฉันย่อขนาดไฟล์ล็อกและเพิ่มจาก 20G เป็น 7MB ซึ่งสอดคล้องกับขนาดของข้อมูลของฉัน ฉันไม่คิดว่าบันทึกธุรกรรมได้รับการสำรองไว้ตั้งแต่ตอนนี้ติดตั้งเมื่อ 2 ปีที่แล้ว .. ดังนั้นให้วางงานนั้นลงในปฏิทินดูแลทำความสะอาด

บันทึกธุรกรรม DB ลดขนาดให้เล็กสุด :

1. สำรอง: บันทึกธุรกรรม
2. ลดขนาดไฟล์: บันทึกธุรกรรม
3. สำรอง: บันทึกธุรกรรม
4. ลดขนาดไฟล์: บันทึกธุรกรรม

ฉันทำการทดสอบกับ DB จำนวนมาก: ลำดับนี้ใช้ได้ลำดับงานนี้

มันมักจะแคบลง 2MB

หรือโดยสคริปต์:

DECLARE @DB_Name nvarchar(255);
DECLARE @DB_LogFileName nvarchar(255);
SET @DB_Name = '<Database Name>';               --Input Variable
SET @DB_LogFileName = '<LogFileEntryName>';         --Input Variable
EXEC 
(
'USE ['+@DB_Name+']; '+
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2) ' +
'BACKUP LOG ['+@DB_Name+'] WITH TRUNCATE_ONLY ' +
'DBCC SHRINKFILE( '''+@DB_LogFileName+''', 2)'
)
GO