Salah satu cara terbaik untuk mempelajari tentang bug di SQL Server adalah dengan membaca catatan rilis untuk Pembaruan Kumulatif dan Paket Layanan ketika mereka keluar. Namun, terkadang ini juga merupakan cara yang bagus untuk mempelajari tentang penyempurnaan SQL Server.
Pembaruan Kumulatif 6 untuk SQL Server 2014 Paket Layanan 1 memperkenalkan bendera pelacakan baru, 7471, yang mengubah perilaku penguncian tugas STATISTIKA PEMBARUAN di SQL Server (lihat KB #3156157). Dalam postingan ini, kita akan melihat perbedaan dalam perilaku penguncian dan di mana tanda jejak ini mungkin berguna.
Untuk menyiapkan lingkungan demo yang sesuai untuk posting ini, saya menggunakan database AdventureWorks2014 dan membuat tabel SalesOrderDetail versi yang diperbesar berdasarkan skrip yang tersedia di blog saya. Tabel SalesOrderDetailEnlarged diperbesar hingga berukuran 2 GB sehingga operasi UPDATE STATISTICS WITH FULLSCAN dapat dijalankan terhadap statistik yang berbeda pada tabel secara bersamaan. Saya kemudian menggunakan sp_whoisactive untuk memeriksa kunci yang dipegang oleh kedua sesi.
Perilaku tanpa TF 7471
Perilaku default SQL Server memerlukan kunci eksklusif (X) pada sumber daya OBJECT.UPDSTATS untuk tabel setiap kali perintah UPDATE STATISTICS dijalankan terhadap tabel. Anda dapat melihat ini di output sp_whoisactive untuk dua eksekusi bersamaan UPDATE STATISTICS WITH FULLSCAN terhadap tabel Sales.SalesOrderDetailEnlarged, menggunakan nama indeks yang berbeda untuk memperbarui statistik. Hal ini mengakibatkan pemblokiran eksekusi kedua dari STATISTIK PEMBARUAN hingga eksekusi pertama selesai.
Statistik PEMBARUAN [Penjualan].[SalesOrderDetailEnlarged] ([PK_SalesOrderDetailEnlarged_SalesOrderID_SalesOrderDetailID]) WITH FULLSCAN;
Statistik PEMBARUAN [Penjualan].[SalesOrderDetailEnlarged] ([IX_SalesOrderDetailEnlarged_ProductID]) DENGAN FULLSCAN;
Perincian sumber daya kunci berada di OBJECT.UPDSTATS mencegah pembaruan serentak beberapa statistik terhadap tabel yang sama. Peningkatan perangkat keras dalam beberapa tahun terakhir telah benar-benar mengubah potensi kemacetan yang umum terjadi pada implementasi SQL Server, dan seperti halnya perubahan telah dilakukan pada DBCC CHECKDB untuk membuatnya berjalan lebih cepat, mengubah perilaku penguncian STATISTIKA PEMBARUAN untuk memungkinkan pembaruan statistik secara bersamaan pada tabel yang sama dapat secara signifikan mengurangi periode pemeliharaan untuk VLDB, terutama jika terdapat kapasitas subsistem CPU dan I/O yang memadai untuk memungkinkan pembaruan serentak terjadi tanpa memengaruhi pengalaman pengguna akhir.
Perilaku dengan TF 7471
Perilaku penguncian dengan bendera pelacakan 7471 mengaktifkan perubahan dari memerlukan kunci eksklusif (X) pada sumber daya OBJECT.UPDSTATS hingga memerlukan kunci pembaruan (U) pada sumber daya METADATA.STATS untuk statistik tertentu yang sedang diperbarui, yang memungkinkan eksekusi bersamaan STATISTIK PEMBARUAN pada tabel yang sama. Output dari sp_whoisactive untuk UPDATE STATISTICS WITH FULLCAN yang sama dengan perintah trace flag yang diaktifkan ditunjukkan di bawah ini:
Statistik PEMBARUAN [Penjualan].[SalesOrderDetailEnlarged] ([PK_SalesOrderDetailEnlarged_SalesOrderID_SalesOrderDetailID]) WITH FULLSCAN;
Statistik PEMBARUAN [Penjualan].[SalesOrderDetailEnlarged] ([IX_SalesOrderDetailEnlarged_ProductID]) DENGAN FULLSCAN;
Untuk VLDB, yang menjadi tempat yang jauh lebih umum, ini dapat membuat perbedaan besar dalam waktu yang diperlukan untuk melakukan pembaruan statistik di seluruh server.
Saya baru-baru ini membuat blog tentang solusi pemeliharaan paralel untuk SQL Server menggunakan Service Broker dan skrip pemeliharaan Ola Hallengren sebagai cara untuk mengoptimalkan tugas pemeliharaan malam dan mengurangi waktu yang diperlukan untuk membangun kembali indeks dan memperbarui statistik pada server yang memiliki banyak kapasitas CPU dan I/O tersedia. Sebagai bagian dari solusi itu, saya memaksa urutan tugas antrian ke Service Broker untuk mencoba dan menghindari eksekusi bersamaan terhadap tabel yang sama untuk tugas membangun kembali/mengatur ulang indeks dan UPDATE STATISTICS. Tujuannya adalah untuk membuat pekerja sesibuk mungkin sampai akhir tugas pemeliharaan, di mana segala sesuatunya akan bersambung dalam eksekusi berdasarkan pemblokiran tugas bersamaan.
Saya melakukan beberapa modifikasi pada pemrosesan di pos itu untuk hanya menguji efek tanda jejak ini dengan pembaruan statistik bersamaan saja, dan hasilnya di bawah ini.
Menguji Kinerja Pembaruan Statistik Bersamaan
Untuk menguji kinerja hanya memperbarui statistik secara paralel menggunakan konfigurasi Service Broker, saya memulai dengan membuat statistik kolom pada setiap kolom di database AdventureWorks2014 menggunakan skrip berikut untuk menghasilkan perintah DDL yang akan dieksekusi.
GUNAKAN [AdventureWorks2014]GO SELECT *, 'DROP STATISTICS ' + QUOTENAME(c.TABLE_SCHEMA) + '.' + QUOTENAME(c.TABLE_NAME) + '.' + QUOTENAME(c.TABLE_NAME + '_' + c.COLUMN_NAME) + ';GOCREATE STATISTICS ' +QUOTENAME(c.TABLE_NAME + '_' + c.COLUMN_NAME) + ' ON ' + QUOTENAME(c.TABLE_SCHEMA) + '. ' + QUOTENAME(c.TABLE_NAME) + ' (' +QUOTENAME(c.COLUMN_NAME) + ');' + 'PERGI' DARI INFORMATION_SCHEMA.COLUMNS SEBAGAI CINNER GABUNG INFORMATION_SCHEMA.TABLES SEBAGAI t PADA c.TABLE_CATALOG =t.TABLE_CATALOG DAN c.TABLE_SCHEMA =t.TABLE_SCHEMA DAN c.TABLE_NAME =t.TABLE_NAMETABLE_' TABEL_NAMEWHE .DATA_TYPE <> N'xml';Ini bukan sesuatu yang biasanya ingin Anda lakukan, tetapi ini memberi saya banyak statistik untuk pengujian paralel dari dampak tanda jejak pada pembaruan statistik secara bersamaan. Alih-alih mengacak urutan di mana saya mengantri tugas ke Service Broker, saya malah hanya mengantri tugas seperti yang ada di tabel CommandLog berdasarkan ID tabel, cukup menambahkan ID satu per satu sampai semua perintah telah diantrekan untuk diproses.
GUNAKAN [master]; -- Kosongkan Command LogTRUNCATE TABLE [master].[dbo].[CommandLog]; MENYATAKAN @MaxID INT;PILIH @MaxID =MAX(ID) DARI master.dbo.CommandLog; SELECT @MaxID =ISNULL(@MaxID, 1) ---- Muat tugas baru ke dalam Command LogEXEC master.dbo.IndexOptimize @Databases =N'AdventureWorks2014', @FragmentationLow =NULL, @FragmentationMedium =NULL, @FragmentationHigh =NULL, @UpdateStatistics ='SEMUA', @StatisticsSample =100, @LogToTable ='Y', @Execute ='N'; MENYATAKAN @NewMaxID INTSELECT @NewMaxID =MAX(ID) DARI master.dbo.CommandLog; GUNAKAN msdb; MENYATAKAN @CurrentID INT =@MaxIDWHILE (@CurrentID <=@NewMaxID)BEGIN -- Memulai percakapan dan mengirim pesan permintaan DECLARE @conversation_handle UNIQUEIDENTIFIER; MENYATAKAN @message_body XML; MULAI TRANSAKSI; MULAI DIALOG @conversation_handle DARI LAYANAN [OlaHallengrenMaintenanceTaskService] KE LAYANAN N'OlaHallengrenMaintenanceTaskService' DI KONTRAK [OlaHallengrenMaintenanceTaskContract] WITH ENCRYPTION =OFF; SELECT @message_body =N''+CAST(@CurrentID AS NVARCHAR)+N' '; KIRIM DI CONVERSATION @conversation_handle JENIS PESAN [OlaHallengrenMaintenanceTaskMessage] (@message_body); KOMITMEN TRANSAKSI; SET @CurrentID =@CurrentID + 1;AKHIR SAAT ADA (PILIH 1 DARI OlaHallengrenMaintenanceTaskQueue WITH(NOLOCK))MULAI PENUNDAAN WAITFOR '00:00:01.000'END WAITFOR DELAY '00:00:06.000' SELECT DATEDIFF(ms, MIN(StartTime ), MAX(EndTime)) DARI master.dbo.CommandLog;GO 10Kemudian saya menunggu semua tugas selesai, mengukur delta waktu mulai dan waktu akhir eksekusi tugas, dan mengambil rata-rata sepuluh tes untuk menentukan peningkatan hanya untuk memperbarui statistik secara bersamaan menggunakan pengambilan sampel default dan pembaruan pemindaian penuh.
Hasil pengujian menunjukkan bahwa bahkan dengan pemblokiran yang terjadi di bawah perilaku default tanpa tanda jejak, pembaruan sampel statistik berjalan 6% lebih cepat dan pembaruan pemindaian penuh berjalan 16% lebih cepat dengan lima utas memproses tugas yang diantrekan ke Pialang Layanan. Dengan mengaktifkan tanda pelacakan 7471, pembaruan statistik sampel yang sama berjalan 38% lebih cepat dan pembaruan pemindaian penuh berjalan 45% lebih cepat dengan lima utas memproses tugas yang diantrekan ke Pialang Layanan.
Potensi Tantangan dengan TF 7471
Meskipun hasil pengujiannya meyakinkan, tidak ada di dunia ini yang gratis dan dalam pengujian awal saya ini, saya menemukan beberapa masalah dengan ukuran VM yang saya gunakan di laptop saya yang menimbulkan masalah beban kerja.
Saya awalnya menguji pemeliharaan paralel menggunakan VM 4vCPU dengan RAM 4GB yang saya siapkan khusus untuk tujuan ini. Saat saya mulai meningkatkan jumlah MAX_QUEUE_READERS untuk prosedur aktivasi di Service Broker, saya mulai mengalami masalah dengan RESOURCE_SEMAPHORE menunggu ketika tanda pelacakan diaktifkan, memungkinkan pembaruan statistik paralel pada tabel yang diperbesar di database AdventureWorks2014 saya karena persyaratan pemberian memori untuk setiap perintah UPDATE STATISTICS yang sedang berjalan. Ini dikurangi dengan mengubah konfigurasi VM ke 16GB RAM tetapi ini adalah sesuatu yang harus dipantau dan diperhatikan saat melakukan tugas paralel pada tabel yang lebih besar, untuk menyertakan pemeliharaan indeks, karena kekurangan pemberian memori juga akan memengaruhi permintaan pengguna akhir yang mungkin mencoba untuk mengeksekusi dan membutuhkan hibah memori yang lebih besar juga.
Tim produk juga telah membuat blog tentang tanda jejak ini dan dalam posting mereka mereka memperingatkan bahwa skenario kebuntuan dapat terjadi selama pembaruan statistik secara bersamaan sementara statistik juga sedang dibuat. Ini bukan sesuatu yang saya alami selama pengujian saya, tapi itu pasti sesuatu yang harus diperhatikan (Kendra Little memperingatkan tentang hal itu juga). Oleh karena itu, rekomendasi mereka adalah bahwa tanda pelacakan ini hanya diaktifkan selama pelaksanaan tugas pemeliharaan paralel dan kemudian harus dinonaktifkan untuk periode beban kerja normal.
Selamat menikmati!
