Yang mana yang harus dipercaya?

Kami memecahkan masalah yang sudah berjalan lama dengan vendor. Perangkat lunak mereka memiliki kecenderungan untuk membeku dan berhenti bekerja sekali atau dua kali seminggu yang menyebabkan gangguan besar pada operasi kami. Mereka tidak dapat menentukan penyebabnya meskipun kami mengirimi mereka banyak GB log dan cadangan DB. Akhir-akhir ini mereka mulai menyarankan bahwa masalahnya ada pada pemeliharaan kita dan mungkin tidak dengan perangkat lunak mereka (meskipun tidak ada permintaan yang berjalan lama, tekanan CPU / RAM / IO atau bahkan deadlock ketika masalah terjadi). Secara khusus mereka mengatakan indeks kami adalah masalah.

Alat favorit mereka untuk digunakan adalah showcontig DBCC meskipun saya berpendapat hal itu sudah usang oleh MS. Mereka terobsesi dengan kerapatan pemindaian dan fragmentasi luas khususnya. Untuk menghilangkan alasan saya melembagakan beberapa pemeliharaan malam agresif yang membangun kembali indeks dengan kepadatan pemindaian <90% atau fragmentasi> 10%. Ini agak membuang mereka dari kerapatan pemindaian tetapi mereka tetap terpaku pada tingkat fragmentasi. Showcontig DBCC menunjukkan fragmentasi tingkat tinggi bahkan pada indeks yang dibangun kembali beberapa jam sebelumnya. Di bawah ini adalah hasil dari dbcc_showcontig dan sys.dm_db_index_physical_stats untuk tabel yang mereka tunjuk sebagai "kemungkinan masalah".

DBCC SHOWCONTIG

• Halaman Dipindai .................................. 1222108
• Perlu Dipindai ...................................: 152964
• Extent Switches ..................................... 180904
• Rata-rata Halaman per Extent ........................: 8.0
• Scan Density [Hitungan Terbaik: Hitungan Aktual] .......: 84.44% [152764: 180905]
• Fragmentasi Pemindaian Logis ..................: 3,24%
• Perpanjangan Pemindaian Yang Luas ...................: 35,97%
• Rata-rata Bytes Gratis per Halaman .....................: 692.5
• Rata-rata Kepadatan Halaman (penuh) .....................: 91,44%

sys.dm_db_index_physical_stats

index_type_desc      alloc_unit_type_desc     Avg_fragmentation_in_percent  page_count

CLUSTERED INDEX       IN_ROW_DATA          3.236803129  1222070

NONCLUSTERED INDEX    IN_ROW_DATA          0.680074642  48230

NONCLUSTERED INDEX    IN_ROW_DATA          0.093237195  48264

NONCLUSTERED INDEX    IN_ROW_DATA          0.03315856   48253

NONCLUSTERED INDEX    IN_ROW_DATA          0.194653248  48291

NONCLUSTERED INDEX    IN_ROW_DATA          0.393480436  58961

NONCLUSTERED INDEX    IN_ROW_DATA          0.23622292   64346

NONCLUSTERED INDEX    IN_ROW_DATA          0.041445623  48256

NONCLUSTERED INDEX    IN_ROW_DATA          0.701172007  59044

NONCLUSTERED INDEX    IN_ROW_DATA          0.216397724  53605

Haruskah saya peduli dengan indeks saya? Yang di atas tidak atipikal. MS DMV yang disukai akan muncul untuk menunjukkan itu baik-baik saja, tetapi vendor terjebak pada tingkat fragmentasi 35,97%. Saya menduga ini hanya mereka yang mati-matian berusaha menemukan sesuatu untuk disalahkan pada masalah perangkat lunak mereka, tetapi jika saya memiliki masalah aktual saya ingin mencoba dan memperbaikinya.

Perangkat lunak mereka memiliki kecenderungan untuk membeku dan berhenti bekerja sekali atau dua kali seminggu yang menyebabkan gangguan besar pada operasi kami. Mereka tidak dapat menentukan penyebabnya meskipun kami mengirimi mereka banyak GB log dan cadangan DB. ... Secara khusus mereka mengatakan indeks kami adalah masalah.

Oh, benar, kurasa aku pernah mendengar lelucon ini sebelumnya. Tidakkah terjadi seperti:

Seekor bebek berjalan ke bar dan berkata, "Aduh!" (hanya bercanda ;-) dan bartender berkata, "Apa yang akan kamu miliki?"

Bebek berkata, "Beri aku 3 jari vodka terkuat Anda."

Bartender itu berkata, hampir seolah-olah dia sedang bercanda, "Bukankah maksudmu 'bulu'?"

Bebek itu berkata, "Dengar, aku minta maaf kau bukan lagi penulis kepala untuk Everybody Loves Raymond , tapi ini hari yang berat, jadi bisakah kau menjadi sahabat dan membuat vodka?"

Bartender itu berkata, "Tentu, sobat. Tunggu sebentar."

Dia kembali sesaat kemudian, tampak sedikit kurang bahagia daripada ketika dia pergi, dan berkata kepada bebek, "Sepertinya kita semua keluar dari barang-barang bagus. Yang tersisa hanyalah Skyy. Apakah itu akan berhasil?"

Bebek melompat di atas meja, meraih bartender di kerah dengan satu sayap (entah bagaimana), menarik pisau dari, yah, di suatu tempat dengan sayap lainnya, dan berkata, agak lambat, lembut, tapi jelas, "I. Will . Potong. Kamu. "

Bartender itu, yang panik, berkata, "Hei, man, ini databasenya. Itu lambat. Tidak merespons."

Bebek itu, agak bingung apakah harus mengakhiri bartender atau tidak - di sini, sekarang - menggonggong dengan marah, "Basis data? Apa yang kau bicarakan?"

Bartender, yang sekarang terisak, berkata, "Saya tidak tahu ... Apakah ada pemblokiran yang terjadi? ... Itu hanya apa yang kita katakan .... Bisakah Anda mencoba membangun kembali indeks atau sesuatu? .. Anda tahu, kapan kita tidak tahu harus berkata apa lagi ... mungkin kita harus menambahkan lebih banyak memori ke server ... Anda pikir itu akan membantu? ... semua orang tahu bahwa kode aplikasi cepat dan database adalah leher botol .. .. Hei, saya telah mendengar tentang database NoSQL ini yang merupakan <air-quotes> skala web </air-quotes> dan biasanya Open Source sehingga bebas, dan seperti, Twitter, Google, dan Facebook semua menggunakan hal itu karena basis data relasional sedang dalam perjalanan keluar. "

Dan dengan itu, bebek itu telah mengambil keputusan ...........

Hmm. Yah, percayalah, ini jauh lebih lucu dalam bahasa Hongaria asli.

Tapi tetap saja, mengapa reaksi awal dari begitu banyak orang, ketika sebuah sistem melambat, hanya berasumsi bahwa itu adalah database? Seolah-olah kode aplikasi tidak dapat ditulis dengan mengerikan, atau hanya memiliki beberapa bug? Hal-hal yang semakin lambat tentu bisa menjadi basis data. Tapi hanya mengunci / membeku? Itu tidak mengejutkan saya sebagai masalah khusus basis data.

Apa yang dilakukannya suara seperti ini mungkin beberapa kode aplikasi yang tidak benar melepaskan sumber daya eksternal (soket jaringan, menangani sistem file, dll). Jika kita berbicara tentang aplikasi .NET, kadang-kadang pengembang lupa dengan benar Dispose()objek yang telah dikaitkan sumber daya yang tidak dikelola. Misalnya: membuka SqlConnectionobjek. Anda tidak mendapatkan jumlah yang tidak terbatas. Jadi jika mereka ingin melihat dalam database maka boleh saja. Tapi mungkin, pada saat sistem macet, lihatlah:

SELECT sdec.*, '---' AS [---], sdes.*
FROM sys.dm_exec_connections sdec
INNER JOIN sys.dm_exec_sessions sdes
        ON sdes.session_id = sdec.session_id

Jika kode mereka tidak merilis koneksi, maka itu seharusnya cukup jelas jika ada terlalu banyak koneksi, terutama jika banyak dari mereka memiliki waktu idle yang lama.

Dan mungkin hal ini sudah diperiksa dan tidak diungkapkan dalam Pertanyaan. Tetapi bagi saya itu agak aneh karena mereka begitu fokus pada indeks dan fragmentasi. Tentu, ada masalah parameter sniffing yang terkadang menyebabkan satu, atau mungkin beberapa, Prosedur Tersimpan untuk mengambil waktu BENAR-BENAR, tetapi mengunci seluruh aplikasi? Saya tidak membelinya, terutama jika Anda tidak melihat permintaan yang sedang berjalan dan menghabiskan banyak sumber daya atau kunci atau waktu saat ini terjadi.

Jadi, "yang harus dipercaya?" Tentunya bukan vendor ini ;-).

Satu hal yang dapat Anda tinjau untuk melihat apakah indeks Anda perlu direorganisasi atau dibangun kembali, adalah menggunakan kueri ini:

declare @strBD nvarchar(50)

set @strBD = N'Tu_BD';

select table = OBJECT_NAME(object_id, database_id)
    ,index = index_id
    ,Index_Type = index_type_desc
    ,Logic_Frag = avg_fragmentation_in_percent
    ,Action = case 
        when avg_fragmentation_in_percent < 30.0
            then 'ALTER INDEX REORGANIZE'
        else 'ALTER INDEX REBUILD WITH (ONLINE = ON)'
        end
from sys.dm_db_index_physical_stats(DB_ID(@strBD), null, null, null, 'LIMITED');

Ganti @strBDdengan your database name.

Menurut hasil, silakan lanjutkan sebagaimana dinyatakan dalam https://msdn.microsoft.com/en-us/library/ms189858(v=sql.110).aspx . Tautan ini untuk SQL Server versi 2012; silakan pilih versi yang tepat untuk melanjutkan dengan benar.

Seperti yang dikomentari seseorang, lebih baik memberi tahu vendor Anda tentang ulasan dan perbaikan, di luar "masalah fragmentasi". Mungkin mengidentifikasi beberapa permintaan dan rencana eksekusi dengan tangkapan SQL Profiler.