"Batas waktu permintaan batas waktu terlampaui" Kesalahan Saat Mencoba Melihat Hierarki DB

Saya mengalami masalah dengan database.

1. Saya dapat menjalankan kueri dasar, meskipun jauh lebih lambat dari biasanya.

2. Ketika saya mencoba untuk melihat hierarki pohon untuk tabel, tampilan, atau prosedur di SSMS Object Explorer, saya dapatkan lock request time out period exceeded.

3. Laporan SSR saya yang berjalan pada objek dalam database ini tidak lagi selesai.

4. Pekerjaan yang terkait dengan prosedur yang tersimpan di database ini juga tidak berjalan.

Saya mencoba menggunakan sp_who2untuk menemukan dan membunuh semua koneksi pada database, namun ini belum menyelesaikan masalah.

Apa yang terjadi disini? Bagaimana saya bisa menyelesaikan ini?

Itu disebabkan oleh kemunduran transaksi yang terjadi terus-menerus. Harus akhirnya me-restart cluster server saya

Tidak termasuk pertimbangan Harware, mungkin Anda perlu menjalankan skrip untuk memeriksa aktivitas apa saja yang menahan Sesi SQL, salah satu skenario umum adalah tidak menggunakan Implicit transactions Optiondalam SQL Server Management Studio.

Saya mendapatkan masalah ini ketika saya memulai transaksi eksplisit di mana saya membuat tabel di tempdb dari skrip yang berjalan di database lain (bukan tempdb). Ketika saya melakukan transaksi, komit tampaknya tidak melepaskan kunci di atas meja yang saya buat di tempdb.

Berkat halaman ini , saya melakukan USEtempdb dan mengeksekusi DBCC OPENTRANdan mendapatkan SPID dari koneksi ke tempdb yang menyebabkan kunci. Lalu aku KILL <SPID number>akan membunuhnya.

Tidak terlalu anggun, dan saya kehilangan semua informasi di tabel yang saya buat di tempdb, tapi itu tidak masalah bagi saya.

Ada begitu banyak hal yang bisa saya tawarkan adalah beberapa pertanyaan untuk membantu membimbing Anda menuju sebuah jawaban.

1. Apakah DB pada server didedikasikan untuk hanya menjalankan SQL Server? Jika tidak, proses lain mungkin mengganggu dengan mencuri waktu prosesor yang berharga.

2. Apakah server DB pada dasarnya kehabisan memori? SQL Server akan berusaha untuk mengalokasikan setiap byte tunggal yang bisa, tetapi jika itu pada kapasitas dan permintaan Anda memerlukan lebih banyak data untuk dimuat maka harus mundur untuk menggunakan memori virtual, yang secara radikal meningkatkan jumlah waktu bahkan pertanyaan sederhana mungkin diperlukan.

3. Apakah bandwidth jaringan server DB menjadi kecil untuk menangani transfer data tepat waktu?

Pada akhirnya, sepertinya mesin yang Anda hosting SQL Server di bawah ukuran untuk apa yang Anda coba lakukan. Sangat mungkin bahwa Anda akhirnya mencapai batas perangkat keras di mana kinerja menurun secara radikal. Jika ini masalahnya (pertanyaan di atas akan membantu Anda menentukan hal itu) maka Anda ingin memindahkan DB ke server yang berukuran tepat untuk jumlah data (dan kueri) yang Anda coba proses.

Ini bisa berarti menggunakan prosesor yang lebih cepat, drive yang lebih cepat, atau hanya menginstal lebih banyak RAM.

"Ketika saya mencoba untuk melihat hierarki pohon untuk tabel, tampilan, atau prosedur di SSMS Object Explorer, saya mendapatkan batas waktu permintaan batas waktu terlampaui."

Saya memiliki masalah yang persis sama. Saya pergi ke jendela eksekusi permintaan dan; ROLLBACKpernyataan diketik dan dieksekusi .

Sepertinya beberapa rangkaian pernyataan yang saya jalankan sebelum itu, mengadakan transaksi terbuka. Secara khusus, karena beberapa dari mereka di mana pernyataan DDL. Setelah saya mengeluarkan rollback, hierarki objek mulai berfungsi.

Seperti yang sudah ditunjukkan oleh banyak orang, biasanya ada transaksi yang tahan lama, sebagian besar karena saya ketinggalan menggunakan SET TRANSAKSI IMPLICIT ON, yang seharusnya tidak digunakan sama sekali. Untuk mengetahui alasannya, periksa artikel berwawasan Brent Ozar

Bagaimanapun, Anda bisa mendapatkan daftar transaksi tertunda yang bertahan lama menggunakan kueri berikut.

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/