ข้อผิดพลาด“ ช่วงเวลาหมดเวลาล็อคคำขอเกิน” เมื่อพยายามดูลำดับชั้นฐานข้อมูล

ฉันมีปัญหากับฐานข้อมูล

1. ฉันสามารถเรียกใช้แบบสอบถามพื้นฐานแม้จะช้ากว่าปกติมาก

2. เมื่อฉันพยายามที่จะดูต้นไม้ลำดับชั้นสำหรับตารางวิวหรือขั้นตอนใน SSMS วัตถุ Explorer lock request time out period exceededฉันได้รับ

3. รายงาน SSRS ของฉันที่ทำงานกับวัตถุในฐานข้อมูลนี้ไม่เสร็จสมบูรณ์อีกต่อไป

4. งานที่เกี่ยวข้องกับขั้นตอนการจัดเก็บในฐานข้อมูลนี้ยังไม่ได้ทำงาน

ฉันพยายามใช้sp_who2เพื่อค้นหาและฆ่าการเชื่อมต่อทั้งหมดในฐานข้อมูลอย่างไรก็ตามวิธีนี้ไม่ได้แก้ปัญหา

เกิดขึ้นที่นี่คืออะไร? ฉันจะแก้ไขปัญหานี้ได้อย่างไร

มันเกิดจากการย้อนกลับของธุรกรรม ต้องรีสตาร์ทเซิร์ฟเวอร์คลัสเตอร์ของฉันในที่สุด

ไม่รวมการพิจารณาของ Harware คุณอาจต้องเรียกใช้สคริปต์เพื่อตรวจสอบกิจกรรมที่ระงับเซสชัน SQL หนึ่งในสถานการณ์ทั่วไปที่ไม่ควรใช้Implicit transactions Optionใน SQL Server Management Studio

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

ขอบคุณหน้านี้ฉันUSEd tempdb และดำเนินการDBCC OPENTRANและได้ SPID ของการเชื่อมต่อกับ tempdb ที่เป็นสาเหตุของการล็อค จากนั้นฉันKILL <SPID number>จะฆ่ามัน

ไม่สง่างามมากและฉันสูญเสียข้อมูลทั้งหมดในตารางที่ฉันสร้างใน tempdb แต่นั่นก็โอเคในกรณีของฉัน

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

1. DB บนเซิร์ฟเวอร์นั้นใช้เพื่อเรียกใช้ SQL Server หรือไม่ ถ้าไม่กระบวนการอื่นอาจรบกวนโดยการขโมยเวลาโปรเซสเซอร์ที่มีค่า

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

3. แบนด์วิดท์เครือข่ายของเซิร์ฟเวอร์ DB มีขนาดเล็กเพื่อรองรับการถ่ายโอนข้อมูลในเวลาที่เหมาะสมหรือไม่

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

นี่อาจหมายถึงการใช้โปรเซสเซอร์ที่เร็วกว่าไดรฟ์ที่เร็วขึ้นหรือเพียงแค่ติดตั้ง RAM เพิ่มเติม

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

ฉันมีปัญหาเดียวกัน ฉันไปที่หน้าต่างการดำเนินการค้นหาและ; ROLLBACKคำสั่งที่พิมพ์และดำเนินการ

ดูเหมือนว่าบางชุดของคำสั่งที่ฉันถูกดำเนินการก่อนหน้านั้นที่ถือธุรกรรมเปิด โดยเฉพาะเพราะบางส่วนของพวกเขาที่คำสั่ง DDL เมื่อฉันออกย้อนกลับลำดับชั้นของวัตถุเริ่มทำงาน

ตามที่หลายคนชี้ให้เห็นแล้วมักจะมีการทำธุรกรรมที่ยาวนานและส่วนใหญ่ทำให้ฉันพลาดการใช้งาน SET IMPLICIT TRANSACTIONS ซึ่งฉันไม่ควรใช้เลย เพื่อดูว่าทำไมตรวจสอบบทความเชิงลึกของ Brent Ozar

อย่างไรก็ตามคุณสามารถรับรายการธุรกรรมที่ค้างอยู่ได้ยาวนานโดยใช้แบบสอบถามต่อไปนี้

SELECT
    [s_tst].[session_id],
    [s_es].[login_name] AS [Login Name],
    DB_NAME (s_tdt.database_id) AS [Database],
    [s_tdt].[database_transaction_begin_time] AS [Begin Time],
    [s_tdt].[database_transaction_log_bytes_used] AS [Log Bytes],
    [s_tdt].[database_transaction_log_bytes_reserved] AS [Log Rsvd],
    [s_est].text AS [Last T-SQL Text],
    [s_eqp].[query_plan] AS [Last Plan]
FROM
    sys.dm_tran_database_transactions [s_tdt]
JOIN
    sys.dm_tran_session_transactions [s_tst]
ON
    [s_tst].[transaction_id] = [s_tdt].[transaction_id]
JOIN
    sys.[dm_exec_sessions] [s_es]
ON
    [s_es].[session_id] = [s_tst].[session_id]
JOIN
    sys.dm_exec_connections [s_ec]
ON
    [s_ec].[session_id] = [s_tst].[session_id]
LEFT OUTER JOIN
    sys.dm_exec_requests [s_er]
ON
    [s_er].[session_id] = [s_tst].[session_id]
CROSS APPLY
    sys.dm_exec_sql_text ([s_ec].[most_recent_sql_handle]) AS [s_est]
OUTER APPLY
    sys.dm_exec_query_plan ([s_er].[plan_handle]) AS [s_eqp]
where [s_tdt].[database_transaction_begin_time] is not null
ORDER BY
    [Begin Time] ASC;

https://www.brentozar.com/archive/2018/02/set-implicit_transactions-one-hell-bad-idea/