Haruskah saya menambahkan kompresi level halaman sebelum menambahkan kunci utama, atau setelahnya?

Situasi

• Gudang data di Sql Server 2008 Enterprise
• 36+ juta tumpukan (jangan tanya), dengan 60+ kolom
• 750k ditambahkan setiap bulan
• Tidak ada kunci primer yang ditentukan (Saya sekarang telah mengidentifikasi satu)
• Tidak ada kompresi

Apa yang saya pikirkan untuk dilakukan (dalam urutan ini)

• Tambahkan kompresi level halaman
• Tambahkan PK
• Tambahkan sejumlah indeks yang tidak berkerumun
• Lakukan ini secepat mungkin

Pertanyaan

• Pada akhirnya: Apakah saya menambahkan PK atau kompresi halaman terlebih dahulu? (Apakah itu penting?)
• Jika saya menambahkan kompresi terlebih dahulu ke tabel, apakah ada indeks kemudian mewarisi pengaturan kompresi tingkat tabel? Jawaban untuk pertanyaan khusus ini adalah "Tidak, kompresi tidak diwarisi", ditemukan di sini di dba.stackexchange

Apa yang saya condongkan saat ini

-- Add page level compression
alter table     dbo.TableName
rebuild with    (data_compression = page)
; 
go

-- Add primary key
alter table             dbo.TableName
add constraint          PK_TableName
primary key clustered   (<Columns>)
;
go

-- Add NC_IXs here
...
...

Ive melihat di sini (dokumentasi pembuatan PK) dan di sini (dokumentasi ALTER TABLE) , tetapi tidak dapat melihat sesuatu yang pasti tentang apakah indeks mewarisi pengaturan kompresi tabel atau tidak. Jawaban untuk pertanyaan khusus ini adalah "Tidak, kompresi tidak diwarisi", ditemukan di sini di dba.stackexchange

Indeks berkerumun sebenarnya adalah tabel. Dengan asumsi bahwa kunci utama Anda berkerumun maka saya akan membuat kunci utama yang dikelompokkan dengan kompresi tingkat halaman daripada mencoba melakukannya dalam dua langkah.

-- Add primary key
ALTER TABLE             dbo.TableName
ADD CONSTRAINT          PK_TableName
PRIMARY KEY CLUSTERED   (<Columns>)
WITH (DATA_COMPRESSION = PAGE)
;

Saya juga akan menyalin sekitar 100k baris ke tabel sementara (sementara fisik bukan #tentara) dan menjalankan beberapa tes. Coba jalankan kompresi terlebih dahulu, kunci berkerumun dulu, coba lakukan sebagai satu langkah. Lihat apa yang berjalan tercepat. Saya kira itu akan menjadi satu langkah pribadi :).

Either way, kompresi halaman akan mengocok data sekitar LOT. Saya akan memperkirakan melakukan kompresi pertama akan menghasilkan I / O keseluruhan kurang karena operasi pengelompokan akan membaca halaman terkompresi.