Azure Synapse Analytics'de ayrılmış SQL havuzu tablolarındaki dizinler
Öneriler ve Azure Synapse Analytics'teki ayrılmış SQL havuzunda tabloları dizine eklemeye yönelik örnekler.
Dizin türleri
Ayrılmış SQL havuzu kümelenmiş columnstore dizinleri, kümelenmiş dizinler ve kümelenmemiş dizinler ve yığın olarak da bilinen dizin dışı bir seçenek gibi çeşitli dizin oluşturma seçenekleri sunar.
Dizin içeren bir tablo oluşturmak için CREATE TABLE (ayrılmış SQL havuzu) belgelerine bakın.
Kümelenmiş columnstore dizinleri
Varsayılan olarak, ayrılmış SQL havuzu bir tabloda dizin seçenekleri belirtilmediğinde kümelenmiş bir columnstore dizini oluşturur. Kümelenmiş columnstore tabloları hem en yüksek veri sıkıştırma düzeyini hem de en iyi genel sorgu performansını sunar. Kümelenmiş columnstore tabloları genellikle kümelenmiş dizin veya yığın tablolarını daha iyi performans gösterir ve genellikle büyük tablolar için en iyi seçenektir. Bu nedenlerden dolayı, tablonuzun dizinini oluşturma konusunda emin olmadığınız durumlarda kümelenmiş columnstore en iyi başlangıç yeridir.
Kümelenmiş columnstore tablosu oluşturmak için WITH yan tümcesinde belirtin CLUSTERED COLUMNSTORE INDEX veya WITH yan tümcesini kapalı bırakın:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED COLUMNSTORE INDEX );
Kümelenmiş columnstore'un iyi bir seçenek olmadığı birkaç senaryo vardır:
- Columnstore tabloları varchar(max), nvarchar(max) ve varbinary(max) tablolarını desteklemez. Bunun yerine yığın veya kümelenmiş dizini göz önünde bulundurun.
- Columnstore tabloları, geçici veriler için daha az verimli olabilir. Yığın ve belki de geçici tabloları göz önünde bulundurun.
- 60 milyondan az satır içeren küçük tablolar. Yığın tablolarını göz önünde bulundurun.
Yığın tabloları
Verileri ayrılmış SQL havuzuna geçici olarak eklerken yığın tablosu kullanmanın genel süreci hızlandırdığını fark edebilirsiniz. Bunun nedeni yığınlara yapılan yüklemelerin tabloları dizine almaktan daha hızlı olması ve bazı durumlarda sonraki okumanın önbellekten yapılabilmesidir. Verileri yalnızca daha fazla dönüştürme çalıştırmadan önce hazırlamak için yüklüyorsanız, tabloyu yığın tablosuna yüklemek, verileri kümelenmiş columnstore tablosuna yüklemekten çok daha hızlıdır. Ayrıca, verileri geçici bir tabloya yüklemek, tabloyu kalıcı depolamaya yüklemekten daha hızlı yüklenir. Veri yüklendikten sonra daha hızlı sorgu performansı için tabloda dizinler oluşturabilirsiniz.
Küme columnstore tabloları, 60 milyondan fazla satır olduğunda en iyi sıkıştırmayı elde etmeye başlar. 60 milyondan az satır içeren küçük arama tablolarında daha hızlı sorgu performansı için HEAP veya kümelenmiş dizin kullanmayı göz önünde bulundurun.
Yığın tablosu oluşturmak için WITH yan tümcesinde HEAP belirtmeniz yeterlidir:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( HEAP );
Dekont
Yığın tablosunda sık sık , UPDATEveya DELETE işlemleri gerçekleştiriyorsanızINSERT, komutunu kullanarak ALTER TABLE bakım zamanlamanıza tablo yeniden oluşturmayı eklemeniz önerilir. Örneğin, ALTER TABLE [SchemaName].[TableName] REBUILD. Bu uygulama, parçalanmanın azalmasına katkıda bulunur ve okuma işlemleri sırasında performansın artmasına neden olur.
Kümelenmiş ve kümelenmemiş dizinler
Kümelenmiş dizinler, tek bir satırın hızla alınması gerektiğinde kümelenmiş columnstore tablolarını aşabilir. Aşırı hızda gerçekleştirmek için tek veya çok az satır araması gerektiren sorgular için kümelenmiş bir dizini veya kümelenmemiş ikincil dizini göz önünde bulundurun. Kümelenmiş dizin kullanmanın dezavantajı, yalnızca avantajlı sorguların kümelenmiş dizin sütununda yüksek seçmeli filtre kullanan sorgular olmasıdır. Diğer sütunlarda filtreyi geliştirmek için, diğer sütunlara kümelenmemiş dizin eklenebilir. Ancak, bir tabloya eklenen her dizin, yüklere hem alan hem de işlem süresi ekler.
Kümelenmiş dizin tablosu oluşturmak için WITH yan tümcesinde CLUSTERED INDEX değerini belirtmeniz yeterlidir:
CREATE TABLE myTable
(
id int NOT NULL,
lastName varchar(20),
zipCode varchar(6)
)
WITH ( CLUSTERED INDEX (id) );
Tabloya kümelenmemiş dizin eklemek için aşağıdaki söz dizimini kullanın:
CREATE INDEX zipCodeIndex ON myTable (zipCode);
Kümelenmiş columnstore dizinlerini iyileştirme
Kümelenmiş columnstore tabloları verileri segmentler halinde düzenler. Columnstore tablolarında en iyi sorgu performansına ulaşmak için segment kalitesinin yüksek olması çok önemlidir. Segment kalitesi, sıkıştırılmış satır grubu içindeki satır sayısıyla ölçülebilir. Segment kalitesi, sıkıştırılmış satır grubu başına en az 100 K satır bulunduğu ve satır grubu başına satır sayısı yaklaşımı 1.048.576 satır olarak performans kazandığında en uygun olandır. Bu, bir satır grubunun içerebileceği en fazla satırdır.
Aşağıdaki görünüm, satır grubu başına ortalama satırları hesaplamak ve en iyi durumdaki küme columnstore dizinlerini tanımlamak için sisteminizde oluşturulabilir ve kullanılabilir. Bu görünümdeki son sütun, dizinlerinizi yeniden oluşturmak için kullanılabilecek bir SQL deyimi oluşturur.
CREATE VIEW dbo.vColumnstoreDensity
AS
SELECT
GETDATE() AS [execution_date]
, DB_Name() AS [database_name]
, s.name AS [schema_name]
, t.name AS [table_name]
, COUNT(DISTINCT rg.[partition_number]) AS [table_partition_count]
, SUM(rg.[total_rows]) AS [row_count_total]
, SUM(rg.[total_rows])/COUNT(DISTINCT rg.[distribution_id]) AS [row_count_per_distribution_MAX]
, CEILING ((SUM(rg.[total_rows])*1.0/COUNT(DISTINCT rg.[distribution_id]))/1048576) AS [rowgroup_per_distribution_MAX]
, SUM(CASE WHEN rg.[State] = 0 THEN 1 ELSE 0 END) AS [INVISIBLE_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE 0 END) AS [INVISIBLE_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 0 THEN rg.[total_rows] ELSE NULL END) AS [INVISIBLE_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 1 THEN 1 ELSE 0 END) AS [OPEN_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE 0 END) AS [OPEN_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 1 THEN rg.[total_rows] ELSE NULL END) AS [OPEN_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 2 THEN 1 ELSE 0 END) AS [CLOSED_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE 0 END) AS [CLOSED_rowgroup_rows]
, MIN(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 2 THEN rg.[total_rows] ELSE NULL END) AS [CLOSED_rowgroup_rows_AVG]
, SUM(CASE WHEN rg.[State] = 3 THEN 1 ELSE 0 END) AS [COMPRESSED_rowgroup_count]
, SUM(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE 0 END) AS [COMPRESSED_rowgroup_rows]
, SUM(CASE WHEN rg.[State] = 3 THEN rg.[deleted_rows] ELSE 0 END) AS [COMPRESSED_rowgroup_rows_DELETED]
, MIN(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_MIN]
, MAX(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_MAX]
, AVG(CASE WHEN rg.[State] = 3 THEN rg.[total_rows] ELSE NULL END) AS [COMPRESSED_rowgroup_rows_AVG]
, 'ALTER INDEX ALL ON ' + s.name + '.' + t.NAME + ' REBUILD;' AS [Rebuild_Index_SQL]
FROM sys.[pdw_nodes_column_store_row_groups] rg
JOIN sys.[pdw_nodes_tables] nt ON rg.[object_id] = nt.[object_id]
AND rg.[pdw_node_id] = nt.[pdw_node_id]
AND rg.[distribution_id] = nt.[distribution_id]
JOIN sys.[pdw_table_mappings] mp ON nt.[name] = mp.[physical_name]
JOIN sys.[tables] t ON mp.[object_id] = t.[object_id]
JOIN sys.[schemas] s ON t.[schema_id] = s.[schema_id]
GROUP BY
s.[name]
, t.[name];
Görünümü oluşturduğunuza göre, 100 K'den az satıra sahip satır gruplarına sahip tabloları tanımlamak için bu sorguyu çalıştırın. Daha uygun segment kalitesi arıyorsanız 100 K eşiğini artırmak isteyebilirsiniz.
SELECT *
FROM [dbo].[vColumnstoreDensity]
WHERE COMPRESSED_rowgroup_rows_AVG < 100000
OR INVISIBLE_rowgroup_rows_AVG < 100000;
Sorguyu çalıştırdıktan sonra verilere bakmaya ve sonuçlarınızı analiz etmeye başlayabilirsiniz. Bu tabloda, satır grubu çözümlemenizde nelerin aranacakları açıklanmaktadır.
| Sütun | Bu verileri kullanma |
|---|---|
| [table_partition_count] | Tablo bölümlenmişse, daha yüksek Açık satır grubu sayısı görmeyi bekleyebilirsiniz. Dağılımdaki her bölümün teoride kendisiyle ilişkilendirilmiş açık bir satır grubu olabilir. Bunu analizinize dahil edin. Bölümlenmiş küçük bir tablo, sıkıştırmayı iyileştireceğinden bölümleme tamamen kaldırılarak iyileştirilebilir. |
| [row_count_total] | Tablo için toplam satır sayısı. Örneğin, sıkıştırılmış durumdaki satırların yüzdesini hesaplamak için bu değeri kullanabilirsiniz. |
| [row_count_per_distribution_MAX] | Tüm satırlar eşit olarak dağıtılırsa, bu değer dağıtım başına hedef satır sayısı olacaktır. Bu değeri compressed_rowgroup_count ile karşılaştırın. |
| [COMPRESSED_rowgroup_rows] | Tablo için columnstore biçimindeki toplam satır sayısı. |
| [COMPRESSED_rowgroup_rows_AVG] | Ortalama satır sayısı bir satır grubu için satır üst sınırından önemli ölçüde azsa, verileri yeniden sıkıştırmak için CTAS veya ALTER INDEX REBUILD kullanmayı göz önünde bulundurun |
| [COMPRESSED_rowgroup_count] | Columnstore biçimindeki satır gruplarının sayısı. Bu sayı tabloya göre çok yüksekse, sütun deposu yoğunluğunun düşük olduğunu gösteren bir göstergedir. |
| [COMPRESSED_rowgroup_rows_DELETED] | Satırlar columnstore biçiminde mantıksal olarak silinir. Sayı tablo boyutuna göre yüksekse, bölümü yeniden oluşturmayı veya dizini fiziksel olarak kaldırdığı için yeniden oluşturmayı düşünün. |
| [COMPRESSED_rowgroup_rows_MIN] | Bunu, columnstore'nuzdaki satır gruplarının değer aralığını anlamak için AVG ve MAX sütunlarıyla birlikte kullanın. Yük eşiğinin üzerindeki düşük bir sayı (bölüme hizalı dağıtım başına 102.400), veri yükünde iyileştirmelerin kullanılabilir olduğunu gösterir |
| [COMPRESSED_rowgroup_rows_MAX] | Yukarıdaki gibi |
| [OPEN_rowgroup_count] | Açık satır grupları normaldir. Tablo dağıtımı başına makul bir open satır grubu (60) bekleniyor olabilir. Aşırı sayılar bölümler arasında veri yüklenmesini önerir. Sağlam olduğundan emin olmak için bölümleme stratejisini bir kez daha denetleyin |
| [OPEN_rowgroup_rows] | Her satır grubunda en fazla 1.048.576 satır olabilir. Açık satır gruplarının şu anda ne kadar dolu olduğunu görmek için bu değeri kullanın |
| [OPEN_rowgroup_rows_MIN] | Açık gruplar, verilerin tabloya yüklendiğini veya önceki yükün bu satır grubuna kalan satırların üzerine taştığını gösterir. OPEN satır gruplarında ne kadar verinin oturduğunu görmek için MIN, MAX, AVG sütunlarını kullanın. Küçük tablolar için tüm verilerin %100'ünü alabilir! Bu durumda VERILERI columnstore'a zorlamak için ALTER INDEX REBUILD. |
| [OPEN_rowgroup_rows_MAX] | Yukarıdaki gibi |
| [OPEN_rowgroup_rows_AVG] | Yukarıdaki gibi |
| [CLOSED_rowgroup_rows] | Kapalı satır grubu satırlarına bir gizlilik denetimi olarak bakın. |
| [CLOSED_rowgroup_count] | Kapalı satır gruplarının sayısı, herhangi bir şekilde görülürse düşük olmalıdır. Kapalı satır grupları ALTER INDEX kullanılarak sıkıştırılmış satır gruplarına dönüştürülebilir... REORGANIZE komutu. Ancak bu normalde gerekli değildir. Kapalı gruplar, arka plan "tanımlama grubu taşıyıcı" işlemiyle otomatik olarak columnstore satır gruplarına dönüştürülür. |
| [CLOSED_rowgroup_rows_MIN] | Kapalı satır gruplarının doldurma oranı çok yüksek olmalıdır. Kapalı satır grubu için doldurma oranı düşükse columnstore için daha fazla analiz yapılması gerekir. |
| [CLOSED_rowgroup_rows_MAX] | Yukarıdaki gibi |
| [CLOSED_rowgroup_rows_AVG] | Yukarıdaki gibi |
| [Rebuild_Index_SQL] | Tablo için columnstore dizinini yeniden oluşturmak için SQL |
Dizin bakımının etkisi
Görünümdeki sütun Rebuild_Index_SQL , vColumnstoreDensity dizinlerinizi yeniden oluşturmak için kullanılabilecek bir ALTER INDEX REBUILD deyim içerir. Dizinlerinizi yeniden oluştururken, dizininizi yeniden oluşturan oturuma yeterli bellek ayırdığınızdan emin olun. Bunu yapmak için, bu tablodaki dizini yeniden oluşturma izinlerine sahip bir kullanıcının kaynak sınıfını önerilen en düşük değere yükseltin. Bir örnek için, bu makalenin devamında segment kalitesini artırmak için dizinleri yeniden oluşturma bölümüne bakın.
Sıralı kümelenmiş columnstore dizini olan bir tablo için tempdb ALTER INDEX REBUILD kullanarak verileri yeniden sıralar. Yeniden oluşturma işlemleri sırasında tempdb'i izleyin. Daha fazla tempdb alanına ihtiyacınız varsa veritabanı havuzunun ölçeğini büyütün. Dizin yeniden oluşturma işlemi tamamlandıktan sonra ölçeği yeniden azaltma.
Sıralı kümelenmiş columnstore dizini olan bir tablo için ALTER INDEX REORGANIZE verileri yeniden sıralamaz. Verileri yeniden sıralamak için kullanın ALTER INDEX REBUILD.
Sıralı kümelenmiş columnstore dizinleri hakkında daha fazla bilgi için bkz . Sıralı kümelenmiş columnstore diziniyle performans ayarlama.
Columnstore dizin kalitesinin düşük olmasının nedenleri
Düşük segment kalitesine sahip tablolar belirlediyseniz, kök nedeni belirlemek istiyorsunuz. Aşağıda düşük segment kalitesinin diğer bazı yaygın nedenleri yer almaktadır:
- Dizin oluşturulduğunda bellek baskısı
- Yüksek hacimli DML işlemleri
- Küçük veya karmaşık yük işlemleri
- Çok fazla bölüm var
Bu faktörler bir columnstore dizininin satır grubu başına en uygun 1 milyon satırdan önemli ölçüde daha az olmasına neden olabilir. Ayrıca, satırların sıkıştırılmış satır grubu yerine delta satır grubuna gitmesine de neden olabilir.
Dizin oluşturulduğunda bellek baskısı
Sıkıştırılmış satır grubu başına satır sayısı, satırın genişliği ve satır grubunu işlemek için kullanılabilir bellek miktarıyla doğrudan ilişkilidir. Satırlar columnstore tablolarına bellek baskısı altında yazıldığında, segment kalitesi düşebilir. Bu nedenle en iyi yöntem, columnstore dizin tablolarınıza yazılan oturuma mümkün olduğunca çok belleğe erişim vermektir. Bellek ve eşzamanlılık arasında bir denge olduğundan, doğru bellek ayırma yönergeleri tablonuzun her satırındaki verilere, sisteminize ayrılan veri ambarı birimlerine ve tablonuza veri yazan oturuma verebileceğiniz eşzamanlılık yuvalarının sayısına bağlıdır.
Yüksek hacimli DML işlemleri
Satırları güncelleştiren ve silebilen yüksek hacimli DML işlemleri columnstore'da verimsizliğe neden olabilir. Bu, özellikle satır grubundaki satırların çoğu değiştirildiğinde geçerlidir.
- Sıkıştırılmış satır grubundaki bir satırı sildiğinizde yalnızca ilgili satır mantıksal olarak silinmiş şekilde kabul edilir. Bölüm veya tablo yeniden oluşturulana kadar ilgili satır, sıkıştırılmış satır grubunda kalır.
- Satır eklemek, satırı delta satır grubu olarak adlandırılan bir iç satır deposu tablosuna ekler. Eklenen satır, delta satır grubu dolu olana ve kapalı olarak işaretlenene kadar columnstore'a dönüştürülmeyecek. Satır grupları en fazla 1.048.576 satır kapasitesine ulaştıktan sonra kapatılır.
- Columnstore biçimindeki bir satırı güncelleştirmek, mantıksal silme ve ardından ekleme olarak işlenir. Eklenen satır delta deposunda depolanabilir.
Bölüme hizalanmış dağıtım başına toplu 102.400 satır eşiğini aşan toplu güncelleştirme ve ekleme işlemleri doğrudan columnstore biçimine gider. Ancak, eşit bir dağıtım varsayarsak, bunun gerçekleşmesi için tek bir işlemde 6,144 milyondan fazla satır değiştirmeniz gerekir. Belirli bir bölüme hizalanmış dağıtımın satır sayısı 102.400'den azsa, satırlar delta deposuna gider ve satır grubunu kapatmak için yeterli satır eklenene veya değiştirilene veya dizin yeniden oluşturulduğundaya kadar orada kalır.
Küçük veya karmaşık yük işlemleri
Ayrılmış SQL havuzuna akan küçük yükler bazen karmaşık yükler olarak da bilinir. Bunlar genellikle sistem tarafından alınan neredeyse sabit bir veri akışını temsil ederler. Ancak, bu akış neredeyse sürekli olduğundan satır hacmi özellikle büyük değildir. Genellikle veriler columnstore biçimine doğrudan yükleme için gereken eşiğin altında değildir.
Bu gibi durumlarda, verileri önce Azure blob depolamaya almak ve yüklemeden önce birikmesine izin vermek genellikle daha iyidir. Bu teknik genellikle mikro toplu işlem olarak bilinir.
Çok fazla bölüm var
Dikkate alınması gereken bir diğer şey de bölümlemenin kümelenmiş columnstore tablolarınız üzerindeki etkisidir. Bölümlemeden önce ayrılmış SQL havuzu verilerinizi zaten 60 veritabanına böler. Bölümleme, verilerinizi daha da böler. Verilerinizi bölümlerseniz, kümelenmiş columnstore dizininden yararlanmak için her bölümün en az 1 milyon satıra ihtiyacı olduğunu düşünün. Tablonuzu 100 bölüme bölerseniz, kümelenmiş columnstore dizininden (60 dağıtım 100 bölüm 1 milyon satır) yararlanmak için tablonuzun en az 6 milyar satıra ihtiyacı vardır. 100 bölümlü tablonuzda 6 milyar satır yoksa, bölüm sayısını azaltın veya bunun yerine yığın tablosu kullanmayı göz önünde bulundurun.
Tablolarınız bazı verilerle yüklendikten sonra, en uygun kümelenmiş columnstore dizinleriyle tabloları tanımlamak ve yeniden oluşturmak için aşağıdaki adımları izleyin.
Segment kalitesini geliştirmek için dizinleri yeniden oluşturma
1. Adım: Doğru kaynak sınıfını kullanan kullanıcıyı tanımlama veya oluşturma
Segment kalitesini hemen geliştirmenin hızlı yollarından biri dizini yeniden oluşturmaktır. Yukarıdaki görünüm tarafından döndürülen SQL, dizinlerinizi yeniden oluşturmak için kullanılabilen ALTER INDEX REBUILD deyimini içerir. Dizinlerinizi yeniden oluştururken, dizininizi yeniden oluşturan oturuma yeterli bellek ayırdığınızdan emin olun. Bunu yapmak için, bu tablodaki dizini yeniden oluşturma izinlerine sahip bir kullanıcının kaynak sınıfını önerilen en düşük değere yükseltin.
Aşağıda, bir kullanıcıya kaynak sınıfını artırarak daha fazla bellek ayırma örneği verilmiştir. Kaynak sınıflarıyla çalışmak için bkz . İş yükü yönetimi için kaynak sınıfları.
EXEC sp_addrolemember 'xlargerc', 'LoadUser';
2. Adım: Daha yüksek kaynak sınıfı kullanıcısıyla kümelenmiş columnstore dizinlerini yeniden oluşturma
Artık daha yüksek bir kaynak sınıfı kullanan 1 . adımda (LoadUser ) kullanıcı olarak oturum açın ve ALTER INDEX deyimlerini yürütür. Bu kullanıcının, dizinin yeniden oluşturulmakta olduğu tablolar üzerinde ALTER iznine sahip olduğundan emin olun. Bu örneklerde columnstore dizininin tamamının nasıl yeniden derlenmesi veya tek bir bölümün nasıl yeniden derlenmesi gösterilmektedir. Büyük tablolarda, dizinleri tek seferde tek bir bölümü yeniden oluşturmak daha pratiktir.
Alternatif olarak, dizini yeniden oluşturmak yerine CTAS kullanarak tabloyu yeni bir tabloya kopyalayabilirsiniz. En iyi yol hangisidir? Büyük hacimli veriler için CTAS genellikle ALTER INDEX'ten daha hızlıdır. Daha küçük veri hacimleri için ALTER INDEX'in kullanımı daha kolaydır ve tabloyu değiştirmenizi gerektirmez.
-- Rebuild the entire clustered index
ALTER INDEX ALL ON [dbo].[DimProduct] REBUILD;
-- Rebuild a single partition
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5;
-- Rebuild a single partition with archival compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE_ARCHIVE);
-- Rebuild a single partition with columnstore compression
ALTER INDEX ALL ON [dbo].[FactInternetSales] REBUILD Partition = 5 WITH (DATA_COMPRESSION = COLUMNSTORE);
Ayrılmış SQL havuzunda dizini yeniden oluşturmak çevrimdışı bir işlemdir. Dizinleri yeniden oluşturma hakkında daha fazla bilgi için Columnstore Dizinleri Birleştirme ve ALTER INDEX bölümündeki ALTER INDEX REBUILD bölümüne bakın.
3. Adım: Kümelenmiş columnstore segment kalitesinin iyileştiğini doğrulama
Düşük segment kalitesine sahip tabloyu tanımlayan sorguyu yeniden çalıştırın ve segment kalitesinin iyileştiğini doğrulayın. Segment kalitesi iyileşmediyse, tablonuzdaki satırların fazla geniş olması olabilir. Dizinlerinizi yeniden oluştururken daha yüksek bir kaynak sınıfı veya DWU kullanmayı göz önünde bulundurun.
CTAS ve bölüm değiştirme ile dizinleri yeniden oluşturma
Bu örnekte, tablo bölümünü yeniden oluşturmak için CREATE TABLE AS SELECT (CTAS) deyimi ve bölüm değiştirme kullanılır.
-- Step 1: Select the partition of data and write it out to a new table using CTAS
CREATE TABLE [dbo].[FactInternetSales_20000101_20010101]
WITH ( DISTRIBUTION = HASH([ProductKey])
, CLUSTERED COLUMNSTORE INDEX
, PARTITION ( [OrderDateKey] RANGE RIGHT FOR VALUES
(20000101,20010101
)
)
)
AS
SELECT *
FROM [dbo].[FactInternetSales]
WHERE [OrderDateKey] >= 20000101
AND [OrderDateKey] < 20010101
;
-- Step 2: Switch IN the rebuilt data with TRUNCATE_TARGET option
ALTER TABLE [dbo].[FactInternetSales_20000101_20010101] SWITCH PARTITION 2 TO [dbo].[FactInternetSales] PARTITION 2 WITH (TRUNCATE_TARGET = ON);
CTAS kullanarak bölümleri yeniden oluşturma hakkında daha fazla bilgi için bkz . Ayrılmış SQL havuzunda bölümleri kullanma.
Sonraki adımlar
Tablo geliştirme hakkında daha fazla bilgi için bkz . Tablo geliştirme.