เหตุใดบันทึกการทำธุรกรรมจึงยังคงเติบโตในโหมดการกู้คืนอย่างง่ายพร้อมการสำรองข้อมูลทุกคืน

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

รายละเอียด: ฉันมีฐานข้อมูลจำนวน ~ 500MB ใน SQL Server 2008 R2 ทั้งหมดในโหมดการกู้คืนที่เรียบง่าย (ไม่ใช่ตัวเลือกของฉัน) สำรองข้อมูลเต็มรูปแบบทุกคืนพร้อมแฟ้มข้อมูล ~ 200MB และไฟล์บันทึก ~ 300MB บันทึกจะไม่โตขึ้นเป็น 300MB ทันที แต่ค่อนข้างช้าในช่วงสองสามเดือน ไม่มีธุรกรรมใด ๆ เปิดอยู่อย่างน้อยตาม sp_who2 และการตรวจสอบกิจกรรม ถ้าฉันคลิกขวาที่ฐานข้อมูลและเลือกคุณสมบัติมันบอกฉันว่ามี ~ 50MB ฟรี โดยเฉพาะอย่างยิ่งหลังจากการสำรองข้อมูลไฟล์บันทึกทั้งหมดไม่ควรว่างหรือไม่ ในโหมด SIMPLE บันทึกไม่ควรฟรีตราบใดที่ไม่มีธุรกรรมเปิดอยู่

log_reuse_wait_descจากsys.databasesว่าพูดว่า "ไม่มีอะไร" ซึ่งขึ้นอยู่กับคำถามและคำตอบที่อ้างถึงข้างต้นบอกว่ามันไม่ควรรออะไรที่จะนำมาใช้ซ้ำพื้นที่

ถ้าฉันทำ 'DBCC SHRINKFILE' ไฟล์บันทึกจะลดลงเหลือ 1MB ดังนั้นจึงยินดีที่จะเรียกคืนพื้นที่ ฉันสามารถตั้งค่าบางอย่างที่ลดขนาดบันทึกเป็นประจำทุกสัปดาห์และทำให้ไม่สามารถควบคุมได้ แต่ฉันสับสนว่าทำไม SQL Server จะทำให้ฉันทำเช่นนั้น

ฉันสามารถเข้าใจได้ว่ามีการทำธุรกรรมที่บ้าที่ต้องการ 300MB เพื่อเข้าสู่ระบบ แต่เราไม่ได้ทำอะไรสุดขั้วเพียงแค่พื้นฐาน OLTP จากคำถาม / คำตอบของ Mike:

Simple Recovery Model - ดังนั้นด้วยการแนะนำข้างต้นจึงเป็นการง่ายที่สุดที่จะพูดคุยเกี่ยวกับ Simple Recovery model ก่อน ในรุ่นนี้คุณกำลังบอก SQL Server - ฉันใช้ได้กับคุณโดยใช้ไฟล์บันทึกการทำธุรกรรมของคุณเพื่อกู้คืนความผิดพลาดและเริ่มการกู้คืน (คุณไม่มีทางเลือกจริงๆ .. ค้นหาคุณสมบัติของกรดและควรทำให้เข้าใจได้อย่างรวดเร็ว) แต่เมื่อคุณไม่ ต้องการอีกต่อไปเพื่อวัตถุประสงค์ในการกู้คืนความผิดพลาด / เริ่มใหม่ไปข้างหน้าและนำไฟล์บันทึกมาใช้ซ้ำ

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

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

ฉันพลาดอะไรไป มีบางสิ่งที่ทำให้ SQL Server ไม่สามารถรับรู้ข้อมูลว่า "แข็ง" และเพิ่มการบันทึกหรือไม่

(แก้ไข) รายงานหลังจากดำเนินการ - AKA ความรู้เล็กน้อยเป็นอันตราย

หลังจากพบว่านี่เป็น "คำถามยอดนิยม" มันให้ความรู้สึกเหมือนฉันเป็นหนี้ถึงคำอธิบายของสิ่งที่เกิดขึ้นเมื่อ 7 เดือนที่แล้วและสิ่งที่ฉันเรียนรู้ที่จะช่วยคนอื่นให้มีความโศกเศร้าบ้าง

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

SELECT
    DB.name,
    MF.physical_name,
    MF.type_desc AS FileType,
    MF.size * 8 / 1024 AS FileSizeMB,
    fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
    mf.name LogicalName
FROM
    sys.master_files MF
    JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE   DB.name = 'yourdatabasename'

สิ่งนี้ยืนยันว่าภายใต้สถานการณ์ปกติเราใช้พื้นที่บันทึกน้อยมาก (20MB หรือน้อยกว่า) แต่สิ่งนี้นำไปสู่รายการที่สอง ...

ประการที่สองการรับรู้ของฉันเกี่ยวกับท่อนซุงที่เพิ่มขึ้นนั้นช้ามากเมื่อเวลาผ่านไป อย่างไรก็ตามในความเป็นจริงบันทึกการเติบโตอย่างรวดเร็วในคืนที่คนรับผิดชอบในการใช้แพทช์สำหรับแอปพลิเคชันบุคคลที่สามนี้กำลังใช้แพทช์ แพตช์ทำเป็นธุรกรรมเดียวดังนั้นขึ้นอยู่กับการแก้ไขข้อมูล 200MB ที่ต้องการบันทึก 300MB กุญแจสำคัญในการติดตามที่ลงมาคือแบบสอบถามจาก Aaron Bertrand ที่https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace

DECLARE @path NVARCHAR(260);

SELECT 
    @path = REVERSE(SUBSTRING(REVERSE([path]), 
    CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM    sys.traces
WHERE   is_default = 1;

SELECT 
   DatabaseName,
   [FileName],
    SPID,
    Duration,
    StartTime,
    EndTime,
    FileType = CASE EventClass 
       WHEN 92 THEN 'Data'
       WHEN 93 THEN 'Log'
    END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
    EventClass IN (92,93)
ORDER BY
    StartTime DESC;

นี่แสดงให้เห็นว่าบันทึกนั้นเพิ่มขึ้นในช่วงเย็นเมื่อลูกค้าไม่ได้ใช้ฐานข้อมูล นั่นนำไปสู่การสนทนากับผู้ชายที่ใช้แผ่นแปะและคำตอบของปริศนา

ขอขอบคุณอีกครั้งสำหรับคนที่ให้ความช่วยเหลือในการตอบฉัน

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

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

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

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

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

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

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

คุณเปิดใช้งานย่ออัตโนมัติบนฐานข้อมูลหรือไม่ และ / หรือคุณมีแผนการบำรุงรักษาตามกำหนดเวลาเพื่อสร้างดัชนีใหม่หรือไม่?

การย่อขนาดอัตโนมัติตามด้วยการบำรุงรักษาดัชนีจะสร้างปริมาณการบันทึกที่สำคัญ

การบำรุงรักษาดัชนีด้วยตัวเองจะทำให้ผลิตภัณฑ์มีปริมาณการบันทึกที่สำคัญหากมีปัญหาการออกแบบฐานข้อมูลเช่นดัชนีคลัสเตอร์บน GUID

 create table #dblog (Databasename varchar(100),
                     logsize float,
                     logspace%] float,
                     [Status] int)

 insert into #dblog
 EXEC ('DBCC sqlperf(logspace)') 

 select * from #dblog

 alter table #dblog 
 add [lgspace used GB] float;

 update #dblog 
 set [lgspace used GB ] = (logsize*[logspace%]/1024)

 update #dblog 
 set [logsize] =([logsize]/1024)

 alter table #dblog 
 drop column [Status];

 select * from #dblog

 drop table #dblog