Menjelajahi Operasi Indeks Online Tingkat Partisi di SQL Server 2014 CTP1

SQL Server 2014 CTP1 memperkenalkan ekstensi ke opsi operasi online yang akan menjadi kabar baik bagi perusahaan yang menghosting database yang sangat besar yang memerlukan sedikit atau tanpa downtime.

Untuk mengatur konteks, bayangkan Anda menggunakan SQL Server 2012 Enterprise Edition untuk manajemen indeks online dan fitur partisi indeks dan Anda mencoba membangun kembali indeks berikut pada tabel yang dipartisi:

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = ALL
WITH (ONLINE= ON);

Menguji ini di SQL Server 2012, kami dapat membangun kembali semua partisi online tanpa kesalahan. Tetapi bagaimana jika kita ingin menentukan partisi tertentu daripada semua partisi?

ALTER INDEX [PK_FactInternetSales_SalesOrderNumber_SalesOrderLineNumber]
ON [dbo].[FactInternetSales]
REBUILD PARTITION = 1
WITH (ONLINE= ON);

Mencoba ini di SQL Server 2012 atau sebelumnya, Anda akan melihat pesan kesalahan berikut:

Tetapi mulai dengan SQL Server 2014 (mulai CTP1), operasi indeks partisi tunggal online sekarang didukung. Dan ini tentu saja merupakan masalah besar untuk skenario perawatan meja yang sangat besar di mana Anda lebih suka, atau memang harus memecah perawatan Anda secara keseluruhan menjadi bagian-bagian yang lebih kecil selama periode waktu tertentu. Anda mungkin juga ingin melakukan pemeliharaan tingkat partisi hanya untuk partisi yang benar-benar membutuhkannya – misalnya, partisi yang benar-benar melebihi tingkat fragmentasi tertentu.

Untuk menguji fungsionalitas SQL Server 2014 CTP1 ini saya menggunakan AdventureWorksDW2012 dengan versi FactInternetSales yang berisi 61.847.552 baris, dan dipartisi oleh kolom ShipDate.

Membangun kembali semua partisi online untuk tabel menggunakan PARTITION = ALL di lingkungan pengujian saya membutuhkan waktu 3 menit dan 23 detik. Mengenai durasi keseluruhan, pengujian saya adalah untuk indeks yang tidak terlalu terfragmentasi, jadi durasi 3 menit dan 23 detik mewakili durasi rata-rata selama beberapa pengujian. Juga perlu diingat bahwa saya tidak memiliki beban kerja bersaing yang berjalan pada saat itu, sehingga pembangunan kembali online terjadi tanpa harus bersaing dengan beban kerja signifikan lainnya terhadap indeks yang bersangkutan.

Bentuk rencana eksekusi kueri untuk pembangunan kembali indeks online menggunakan PARTITION = ALL adalah sebagai berikut:

Rencana eksekusi untuk membangun kembali semua partisi secara online

Perhatikan bahwa operasi diaktifkan secara paralel kecuali untuk operator Pemindaian Konstan. Dalam rencana eksekusi kueri, Anda dapat melihat 39 baris di referensi luar Pemindaian Konstan yang diteruskan ke operator Distribute Streams dan kemudian menggerakkan Loop Bersarang.

Pentingnya 39 baris? Kueri berikut memvalidasi jumlah partisi maksimum dari sys.dm_db_partition_stats . Untuk lingkungan pengujian saya, hasilnya adalah 39 untuk nomor partisi maksimum, cocok dengan apa yang saya lihat untuk baris aktual Pemindaian Konstan:

SELECT MAX([partition_number]) AS [max_partition_number]
FROM [sys].[dm_db_partition_stats]
WHERE [object_id] = OBJECT_ID('FactInternetSales');

Sekarang Anda juga akan melihat operator Sisipan Indeks Online di paket sebelumnya. Menghapus ONLINE = ON opsi dari ALTER INDEX REBUILD saya (menjadikannya operasi offline), dan menjaga PARTITION = ALL opsi, satu-satunya perubahan adalah memiliki operator "Indeks Sisipan" alih-alih "Sisipkan Indeks Online" dalam rencana eksekusi kueri - dan juga pengurangan durasi, di mana pengujian saya menunjukkan durasi eksekusi 1 menit dan 9 detik dibandingkan dengan online 3 menit 23 detik.

Saya kemudian menguji pembangunan kembali satu partisi secara online dengan 5.678.080 baris di dalamnya (ingat jumlah baris tabel total adalah 61.847.552 baris). Untuk pengujian ini, durasi keseluruhan memakan waktu tepat 1 menit dan memiliki bentuk rencana eksekusi kueri berikut:

Rencana eksekusi untuk pembangunan kembali secara online dari satu partisi

Pengamatan pertama adalah bahwa ini adalah rencana serial. Perhatikan juga bahwa saya mengatakan saya memilih satu partisi dari 39 asli, meskipun partisi tertentu itu mewakili ~ 9% dari baris dalam tabel secara keseluruhan. Perhatikan juga bahwa Pemindaian Konstan menunjukkan 1 baris, bukan 39, seperti yang saya harapkan.

Bagaimana dengan durasi satu partisi, pembangunan kembali offline? Di lingkungan pengujian saya, ini membutuhkan waktu 11 detik dibandingkan dengan pembangunan kembali online 1 menit. Bentuk rencana eksekusi kueri untuk pembuatan ulang offline dari satu partisi adalah sebagai berikut:

Rencana eksekusi untuk pembangunan kembali offline satu partisi

Perhatikan tidak ada Pemindaian Konstan atau proses Nested Loops yang terkait dan perhatikan juga bahwa paket ini sekarang memiliki operator paralel di dalamnya vs. paket serial sebelumnya, meskipun keduanya melakukan Pemindaian Indeks Clustered untuk 5.678.080 baris. Juga melakukan pencarian kata kunci "partisi" dalam teks rencana XML untuk operasi indeks paralel offline partisi tunggal tidak menghasilkan kecocokan - dibandingkan dengan rencana serial, operasi indeks partisi tunggal online yang memiliki Partitioned ="true" untuk Pemindaian Indeks Clustered dan Indeks Online Masukkan operator fisik.

Kembali ke eksplorasi utama…

Bisakah saya memilih beberapa, tetapi tidak semua partisi dalam satu eksekusi? Sayangnya tidak.

ALTER INDEX dan ALTER TABLE perintah memiliki PARTITION = ALL argumen dan kemudian PARTITION = <partition number> argumen, tetapi bukan kemampuan untuk membuat daftar beberapa partisi untuk satu operasi pembangunan kembali. Saya tidak mengeluh terlalu keras tentang ini, karena saya senang memiliki kemampuan untuk membangun kembali satu partisi online dan tidak terlalu rumit untuk menjalankan operasi sekali untuk setiap pembangunan kembali, namun dampak kumulatif terhadap durasi adalah sesuatu Saya ingin menjelajah lebih jauh.

Berapa lama waktu yang dibutuhkan untuk membangun kembali 39 partisi secara terpisah dan online versus PARTITION = ALL durasi 3 menit 23 detik?

Kita tahu bahwa manfaat dari pembangunan kembali online adalah kemampuan untuk tetap mengakses tabel atau indeks terkait selama operasi indeks. Namun sebagai imbalan atas operasi online itu, kami akan kehilangan keunggulan kinerja pembangunan kembali dibandingkan dengan pembangunan kembali offline. Dan yang ingin saya ketahui selanjutnya adalah bagaimana kinerja pembangunan kembali partisi satu per satu secara online versus PARTITION = ALL alternatif.

Menjalankan 39 operasi rekondisi terpisah (satu rekondisi untuk setiap partisi unik), total durasi eksekusi adalah 9 menit 54 detik dibandingkan dengan PARTITION = ALL yang memakan waktu 3 menit dan 23 detik, jadi jelas pendekatan sedikit demi sedikit secara kumulatif tidak secepat membangun kembali semua partisi secara online dalam satu pernyataan. Meskipun saya dapat melakukan satu partisi pada satu waktu, manfaat menyeluruh adalah kemampuan untuk memecah aktivitas pemeliharaan kami dari waktu ke waktu dan menjaga akses ke objek saat sedang dibangun kembali, tetapi jika Anda mencari pembangunan kembali yang lebih singkat jendela, opsi offline masih yang tercepat, diikuti oleh online untuk PARTITION = ALL dan kemudian di tempat terakhir, melakukan satu partisi pada satu waktu.

Tabel berikut merangkum perbandingan durasi – dan sekali lagi, pengujian ini didasarkan pada SQL Server 2014 CTP1 dan ukuran tabel yang sangat spesifik serta konfigurasi tamu VM, jadi lebih memperhatikan durasi relatif di seluruh pengujian daripada durasi itu sendiri:

Sekarang ada aspek lain untuk dijelajahi tentang hal ini juga. Hanya karena operasi sedang online tidak berarti tidak ada beberapa saat (atau lebih lama) di mana kunci masih dipegang pada objek yang ditargetkan. Operasi indeks masih memiliki perilaku penguncian untuk operasi online – dan SQL Server 2014 telah menyediakan opsi untuk ini juga yang akan saya jelajahi di pos terpisah.