SQL Server Leaked ธุรกรรม


9

ฉันมีฐานข้อมูลที่เข้าถึงได้โดยไคลเอนต์ประมาณ 50 คนผ่าน TDS ผ่าน TCP ซึ่งดูเหมือนจะไม่ปล่อยพื้นที่บันทึก จำนวนกระบวนการอยู่รอบ 50 ที่คาดไว้และบางกระบวนการค่อนข้างยาวนาน (> 120 วัน)

ขณะนี้ฐานข้อมูลมีพื้นที่บันทึก 40 gb (มีเพียง 14 gb data), 39 gb ฟรี เนื่องจากข้อ จำกัด ด้านพื้นที่บนไดรฟ์ฉันต้องการลดขนาดให้เหมาะสมกว่า (10gb-ish) เมื่อฉันดำเนินการDBCC SHRINKFILE('db_log', 10000)มันจะส่งคืนข้อผิดพลาดที่การใช้งานสิ้นสุดของบันทึก

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

ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE db SET MULTI_USER
GO

แต่สคริปต์ส่งคืนข้อความต่อไปนี้ซ้ำหลายร้อยครั้ง:

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

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

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

sys.dm_tran_active_transactionsกำลังแสดงธุรกรรม 18 รายการที่สมเหตุสมผลโดยมีวัตถุประสงค์ที่เข้าใจได้ sp_whoแสดงเฉพาะกระบวนการที่ฉันรับรู้


เวอร์ชันของ SQL Server:

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

รุ่นเซิร์ฟเวอร์:

Windows Server 2008 R2 x64 - Datacenter 4 vCPUs, หน่วยความจำ 16GB, ผ่านดิสก์สำหรับข้อมูลและบันทึก, ดิสก์ระบบปฏิบัติการคือ VHD

บน Hyper-V (Windows Server 2008 R2 SP1 x 64 Datacenter) Dual Intel X5650 (6 คอร์, 12 เธรดที่ 2.67GHz) หน่วยความจำ 72 GB

Hypervisor มีสาม VMs เท่านั้นและไม่แสดงการใช้ทรัพยากรสูง SQL Server VM แสดง ~ 40% CPU ภายใต้โหลดและฮิตแคช 99%


ฉันไม่ใช่ sql dba แต่คุณได้ทำการสำรองข้อมูลบันทึกหรือไม่? serverfault.com/questions/54958/…

@Ren ใช่ฉันควรพูดถึงแล้ว แต่ฐานข้อมูลมีการสำรองข้อมูลเต็มรูปแบบทุกวันและมีการสำรองข้อมูลบันทึกทุกหกชั่วโมง

สวัสดีมิทช์อาจไม่เกี่ยวข้องกับปัญหานี้ แต่จะไม่แปลกใจถ้าสิ่งนี้มีความรับผิดชอบ รุ่นของคุณคือ RTM (ปล่อยสู่การผลิต) Microsoft เช่นเดียวกับผู้ผลิตซอฟต์แวร์รายอื่น ๆ ทุกรายจะผลักดันให้เปิดตัวผลิตภัณฑ์รุ่นใหญ่ครั้งต่อไปพร้อมกับข้อบกพร่องจำนวนเล็กน้อยในผลิตภัณฑ์ [ลิงค์] microsoft.com/en-us/download/details.aspx?id=44271นี่คือลิงค์ไปยัง Service Pack ล่าสุดสำหรับ SQL 2008 R2 ดีที่สุดเพื่อให้เซิร์ฟเวอร์ของคุณทันสมัยเพื่อความปลอดภัยแก้ไขข้อผิดพลาด & เหตุผลด้านประสิทธิภาพ
DamagedGoods

คำตอบ:


4

มีคำสั่ง SQL ที่จะแสดงธุรกรรมเปิด (DBCC OPENTRAN)

http://msdn.microsoft.com/en-us/library/ms182792.aspx

แสดงข้อมูลเกี่ยวกับธุรกรรมที่เก่าที่สุดที่แอ็คทีฟและธุรกรรมที่ถูกแจกจ่ายและไม่จำลองแบบที่เก่าที่สุดหากมีภายในฐานข้อมูลที่ระบุ ผลลัพธ์จะปรากฏเฉพาะในกรณีที่มีธุรกรรมที่ใช้งานอยู่หรือหากฐานข้อมูลมีข้อมูลการจำลองแบบ


4

ไม่ว่าจะด้วยเหตุผลใดก็ตามดูเหมือนว่าไม่มีสิ่งใดที่เปิดล็อกไฟล์ เมื่อเรียกใช้การสำรองข้อมูลบันทึกหลายรายการ (> 10) จุดสิ้นสุดของบันทึกจะถูกนำออกใช้และการย่อขนาดอาจเกิดขึ้น ไม่แน่ใจว่าทำไม ... แต่มันได้ผล

backup log db to disk = '\\l-backup1\drop\2012-12-23_db_log.bak' with stats = 1
go 15
dbcc shrinkfile('db_log', 10240)
go

3

หากฉันเข้าใจคำถามของคุณถูกต้องคุณมีบันทึกการทำธุรกรรม 40Gb ฟรี 39Gb หรือไม่ บันทึกเป็นโครงสร้างแบบวงกลมประกอบด้วยไฟล์บันทึกเสมือนขนาดเล็กกว่า แต่ละครั้งที่ VLF เต็ม SQL จะเริ่มใช้ VLF ถัดไป (ไม่จำเป็นต้องอยู่ในลำดับเดียวกับ VLF ที่อยู่ในไฟล์) เมื่อคุณย่อขนาดไฟล์บันทึกมันจะปล่อยพื้นที่ว่างออกจากปลายบันทึก หากส่วนที่ใช้งานของบันทึกอยู่ท้ายที่สุดจะไม่มีช่องว่างถ้ามันอยู่ตรงกลางที่ใดที่หนึ่งคุณจะสามารถเรียกคืนพื้นที่บางส่วนได้เท่านั้น DBCC LOGINFO จะแสดง VLFs ทั้งหมดในบันทึกและสถานะที่แสดงว่า VLF ปัจจุบันมีบันทึกที่ใช้งานอยู่ ฉันเชื่อว่าสถานะ 2 เปิดใช้งานและ 0 ไม่ได้ใช้งาน ฉันแน่ใจว่า google สามารถให้ข้อมูลเพิ่มเติมหากจำเป็น

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

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

ข้อมูลเพิ่มเติมเกี่ยวกับ VLFs สามารถพบได้ในบล็อกโพสต์คิมเบอร์ลี Tripps ที่นี่


ขอบคุณสำหรับDBCC LOGINFOคำสั่งฉันไม่รู้ตัว ที่ถูกกล่าวว่าฉันตระหนักถึงโครงสร้างของบันทึกและไม่พิจารณาลดขนาดไฟล์อย่างไม่เจาะจง ดังที่กล่าวไว้เราใช้ล็อกประมาณ 1GB เป็นประจำในโครงสร้างการสำรองข้อมูลปัจจุบันของเราและฉันต้องการเรียกคืนพื้นที่ว่างบางส่วน ปัญหาคือว่าพื้นที่บันทึกที่ส่วนท้ายของบันทึกไม่ได้ถูกปล่อยออกมาแม้หลังจากรอหลายสัปดาห์ ในช่วงเวลานั้นฐานข้อมูลมีการสำรองข้อมูลจำนวนมากเต็มรูปแบบและการสำรองข้อมูลซึ่งทำให้ฉันเชื่อว่ามีบางสิ่งบางอย่างที่ป้องกันการวนรอบตามธรรมชาติ
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.