SQL Server 2008 - Partisi dan Indeks Clustered

Jadi saya perkenalkan dengan mengatakan saya tidak memiliki kendali penuh atas desain db saya, jadi banyak aspek dari sistem saat ini tidak dapat diubah untuk keperluan skenario ini.

Komentar tentang bagaimana kita harus memikirkan kembali aspek-aspek desain mungkin benar tetapi tidak membantu :)

Saya memiliki tabel yang sangat besar, kira-kira 150 bidang lebar dan sekitar 600m baris, yang menggerakkan sejumlah besar proses. Ini berada dalam situasi gudang data sehingga kami tidak memiliki pembaruan / sisipan APAPUN di luar proses pemuatan terjadwal, sehingga sangat terindeks.

Keputusan telah dibuat untuk mencoba mempartisi tabel ini, dan saya memiliki beberapa kekhawatiran tentang pengindeksan tabel dipartisi. Saya tidak punya pengalaman dengan mempartisi, jadi masukan atau tautan apa pun dihargai. Saya tidak dapat menemukan secara spesifik apa yang saya cari di BOL atau msdn.

Saat ini kami klaster pada bidang yang kita sebut IncidentKeyyang merupakan varchar(50)dan tidak unik - kita bisa memiliki antara 1-100 catatan dengan sama IK(tidak ada komentar menyenangkan). Kami sering mendapatkan data baru pada IncidentKeycatatan lama sehingga tidak berurutan juga.

Saya mengerti saya harus memasukkan bidang partisi saya IncidentDate,, di kunci indeks berkerumun saya agar partisi berfungsi dengan benar. Saya pikir itu akan terjadi IncidentKey, IncidentDate.

Pertanyaannya adalah, bagaimana mekanisme indeks berkerumun bekerja pada kunci 2 bagian dalam tabel dipartisi, jika catatan dalam partisi "baru" harus sebelum rekaman dalam partisi "lama" dalam indeks berkerumun?

Misalnya, saya punya 5 catatan:

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

Jika saya mendapatkan catatan baru untuk ABC123, 2/1/2011itu harus dalam indeks berkerumun SEBELUM XYZ999, 1/1/2010 . Bagaimana cara kerjanya?

Saya mengasumsikan fragmentasi dan petunjuk, tetapi saya tidak dapat menemukan info tentang penyimpanan fisik dan konfigurasi indeks berkerumun non-dipartisi pada tabel dipartisi dengan kunci dua bagian.

Tabel yang dipartisi benar-benar lebih mirip kumpulan tabel individual yang dijahit menjadi satu. Jadi Anda dalam contoh pengelompokan oleh IncidentKeydan partisi oleh IncidentDate, mengatakan bahwa fungsi partisi membagi tabel menjadi dua partisi sehingga 1/1/2010 di partisi 1 dan 7/1/2010 adalah partisi dua. Data akan diletakkan di disk sebagai:

Partition 1:
IncidentKey    Date
ABC123        1/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010

Partition 2:
IncidentKey    Date
ABC123        7/1/2010
XYZ999        7/1/2010

Pada level rendah sebenarnya ada dua, rowset yang berbeda. Adalah pemroses kueri yang memberikan ilusi satu tabel dengan membuat rencana yang mencari, memindai, dan memperbarui semua rowset secara bersamaan, sebagai satu kesatuan.

Setiap baris dalam indeks yang tidak berkerumun akan memiliki kunci indeks yang berkerumun yang sesuai dengan itu, katakan ABC123,7/1/2010. Karena kunci indeks berkerumun selalu berisi kolom kunci pemartisian, mesin akan selalu tahu di partisi (rowset) apa dari indeks berkerumun untuk mencari nilai ini (dalam hal ini, dalam partisi 2).

Sekarang setiap kali Anda berurusan dengan mempartisi, Anda harus mempertimbangkan apakah indeks NC Anda akan selaras (indeks NC dipartisi persis sama dengan indeks berkerumun) atau tidak selaras (indeks NC adalah non-partisi, atau dipartisi berbeda dari indeks berkerumun) . Indeks yang tidak selaras lebih fleksibel, tetapi mereka memiliki beberapa kelemahan:

• indeks yang tidak selaras membutuhkan sejumlah besar memori untuk paket kueri tertentu
• indeks yang tidak selaras mencegah operasi sakelar partisi yang efisien

Menggunakan indeks yang selaras memecahkan masalah-masalah ini, tetapi membawa serangkaian masalah sendiri, karena opsi fisik, desain penyimpanan ini, beriak ke dalam model data:

• indeks selaras berarti batasan unik tidak lagi dapat dibuat / diberlakukan (kecuali untuk kolom partisi)
• semua kunci asing yang mereferensikan tabel dipartisi harus menyertakan kunci pemartisian dalam relasi (karena kunci pemartisian, karena penyelarasan, di setiap indeks), dan ini pada gilirannya mengharuskan semua tabel yang mereferensikan tabel dipartisi mengandung nilai kolom kunci pemartisian. Pikirkan Pesanan -> OrderDetails, jika Pesanan memiliki OrderID tetapi dipartisi oleh OrderDate, maka OrderDetails harus mengandung tidak hanya OrderID, tetapi juga OrderDate, agar dapat mendeklarasikan batasan kunci asing dengan benar.

Efek ini saya temukan jarang disebut pada awal proyek yang menyebarkan partisi, tetapi ada dan memiliki konsekuensi serius.

Jika Anda berpikir indeks yang selaras adalah kasus yang jarang atau ekstrim, maka pertimbangkan ini: dalam banyak kasus landasan ETL dan solusi pemartisian adalah pergantian cepat dalam tabel pementasan. Beralih dalam operasi membutuhkan indeks yang selaras.

Oh, satu hal lagi: semua argumen saya tentang kunci asing dan efek riak menambahkan nilai kolom partisi ke tabel lain berlaku sama untuk bergabung .

Ketika indeks berkerumun memiliki beberapa partisi, setiap partisi memiliki struktur B-tree yang berisi data untuk partisi spesifik itu. Misalnya, jika indeks berkerumun memiliki empat partisi, ada empat struktur B-tree; satu di setiap partisi. Ref. Struktur Indeks Berkelompok

Panduan Khusus untuk Indeks Partisi

Anda dapat membangun kembali partisi tertentu dari indeks yang dipartisi.

misalnya

ALTER INDEX IX_TransactionHistory_TransactionDate
ON Production.TransactionHistory
REBUILD Partition = 5;
GO