DB Hiyerarşilerini Görmeye Çalışılırken “kilit isteği zaman aşımı süresi aşıldı” Hatası

Bir veritabanıyla ilgili sorunlar yaşıyorum.

1. Normalden çok daha yavaş da olsa temel sorgular çalıştırabilirim.

2. SSMS Nesne Gezgini'nde tablolar, görünümler veya yordamlar için hiyerarşi ağaçlarını görüntülemeye çalıştığımda alıyorum lock request time out period exceeded.

3. Bu veritabanındaki nesneler üzerinde çalışan SSRS raporlarım artık tamamlanmıyor.

4. Bu veritabanında saklı yordamlarla ilişkili işler de çalışmaz.

sp_who2Veritabanındaki tüm bağlantıları bulmak ve öldürmek için kullanmayı denedim , ancak bu sorunu çözmedi.

Burada neler oluyor? Bunu nasıl çözebilirim?

Bu, bir işlemin sürekli olarak geri alınmasından kaynaklanıyordu. Sonunda sunucu kümemi yeniden başlatmak zorunda kaldım

Harware dikkate alınmadan, belki de SQL Oturumunu saklayan faaliyetin ne olduğunu kontrol etmek için komut dosyasını çalıştırmanız gerekir, yaygın senaryolardan biri Implicit transactions OptionSQL Server Management Studio'da kullanılmaz.

Başka bir veritabanında (tempdb değil) çalışan bir komut dosyasından tempdb bir tablo oluşturduğu açık bir işlem başladığında bu sorunu var. İşlemi tamamladığımda, taahhüt tempdb'de oluşturduğum masadaki kilidi serbest bırakmadı.

Bu sayfa sayesinde , USEtempdb yürüttüm ve tempdb DBCC OPENTRANbağlantı kilidini neden SPID aldım. Sonra onu KILL <SPID number>öldüreceğim.

Çok zarif değil ve ben tempdb içinde oluşturmuştu tablodaki tüm bilgileri kaybetti, ama benim durumumda Tamam oldu.

Bu kadar çok şey olabilir, tüm sunabileceğim tek şey size bir cevaba doğru rehberlik edecek birkaç soru olabilir.

1. Sunucudaki DB, sadece SQL Server çalıştırmaya mı adanmıştır? Değilse, diğer işlemler değerli işlemci zamanını çalarak karışıyor olabilir.

2. DB sunucusunun belleği yetersiz mi? SQL Server, alabileceği her bir baytı ayırmaya çalışacaktır, ancak kapasitede ve sorgularınız yüklenmek için daha fazla veri gerektiriyorsa, basit belleklerin bile alabileceği süreyi önemli ölçüde artıran sanal bellek kullanmaya geri dönmelidir.

3. Verilerin zamanında aktarılması için DB sunucusunun ağ bant genişliği küçük mü?

Günün sonunda, SQL Server'ı barındırdığınız makinenin yapmaya çalıştığınız şey için boyutunun altında olduğu anlaşılıyor. Sonunda performansın radikal bir şekilde düştüğü donanım sınırlarına ulaşmış olmanız tamamen mümkündür. Bu durumda (yukarıdaki sorular bunu belirlemenize yardımcı olacaktır), DB'yi işlemeye çalıştığınız veri miktarı (ve sorguları) için uygun şekilde boyutlandırılmış bir sunucuya taşımak isteyeceksiniz.

Bu, daha hızlı işlemciler, daha hızlı sürücüler kullanmak veya yalnızca daha fazla RAM takmak anlamına gelebilir.

"SSMS Nesne Gezgini'nde tablolar, görünümler veya yordamlar için hiyerarşi ağaçlarını görüntülemeye çalıştığımda kilit isteği zaman aşımı süresi aşıldı."

Tamamen aynı sorunum vardı. Sorgu yürütme penceresine gittim ve; yazılan ve yürütülen ROLLBACKifade.

Bundan önce yürüttüğüm ifade serilerinden bazıları açık işlem gibi görünüyor. Özellikle, bazıları DDL ifadelerinin bulunduğu için. Geri alma işlemi gerçekleştirildikten sonra, nesne hiyerarşileri çalışmaya başladı.

Birçoğunun daha önce işaret ettiği gibi, genellikle uzun süren bir işlem var, çoğunlukla benim kullanılmamaları gereken Bayan IMPLICIT TRANSACTIONS ON kullanıldı. Brent Ozar'ın içgörüsel makalesine neden göz atmak için

Her neyse, aşağıdaki sorguyu kullanarak uzun süreli bekleyen işlemlerin bir listesini alabilirsiniz.

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/