SQL Server sıkıştırılmış dizinleri, veri sıkıştırması belirtmeden yeniden oluşturma sırasında sıkıştırılmış olarak kalır mı?


13

Birisi sayfa sıkıştırması ( ALTER INDEX IX1 REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE)) kullanarak SQL Server dizinlerini yeniden oluşturduktan sonra , sonraki yeniden oluşturmaların (belirli bir parçalanma eşiğini geçen bazı bakım komut dosyaları tarafından yapıldığı gibi) veri sıkıştırmasını tekrar belirtmesi gerekir mi? Aksi halde endeksler etkin bir şekilde açılır mı?

Yanıtlar:


22

Endeksler, yeniden oluşturulurken / yeniden düzenlenirken sıkıştırılmış kalır.

Tablo ve sıkıştırılmış dizin oluşturma

 CREATE TABLE DBO.TEST_INDX(id int, bla varchar(255));
 CREATE INDEX IX1 ON dbo.TEST_INDX(id)  WITH (DATA_COMPRESSION = PAGE);

Sıkışmayı Kontrol Et

 SELECT i.name, p.data_compression_desc 
 FROM sys.partitions P
 INNER JOIN sys.indexes I ON I.object_id = P.object_id AND I.index_id = P.index_id
 WHERE P.data_compression > 0 and I.name = 'IX1';

Sonuç

name    data_compression_desc
IX1     PAGE

Dizini yeniden oluştur

ALTER INDEX IX1 on  DBO.TEST_INDX rebuild 

Sıkışmayı Kontrol Et

 SELECT i.name, p.data_compression_desc 
 FROM sys.partitions P
 INNER JOIN sys.indexes I ON I.object_id = P.object_id AND I.index_id = P.index_id
 WHERE P.data_compression > 0 and I.name = 'IX1'

Sonuç

name    data_compression_desc
IX1     PAGE

Bunları devre dışı bırakmanın ve ardından yeniden oluşturmanın farklı bir sonucu vardır, çünkü devre dışı bırakma, dizin tanımını korurken dizini kaldırır.

alter index IX1 on  DBO.TEST_INDX DISABLE ;
alter index IX1 on  DBO.TEST_INDX REBUILD ;

Sonuç

name    data_compression_desc

Sıkıştırma kayboldu, dizin oluşturma komut dosyasını uyarlamadan SSMS aracılığıyla dizin bırakılırken ve oluşturulurken sıkıştırma tanımı da kaybolacaktır.

Neden?

Dizin oluşturma deyimi komut dosyası oluşturulurken data_compression seçeneği korunmadığından.

ancak, dizini devre dışı bırakırsak, sıkıştırmayla yeniden oluşturun ve ardından yeniden oluşturun:

alter index IX1 on  DBO.TEST_INDX DISABLE ;
alter index IX1 on  DBO.TEST_INDX REBUILD  WITH (DATA_COMPRESSION = PAGE);
alter index IX1 on  DBO.TEST_INDX REBUILD;

Sonuç

name    data_compression_desc
IX1 PAGE

Ola hallengren'in bakım çözümü ile yeniden yapılanmayı test etme

Parametreler test amacıyla değiştirilir.

MinNumberOfPages parametresi için gerekli olduğundan, bir sayfaya ulaşmak için bazı veriler ekleyin.

INSERT INTO dbo.TEST_INDX(id,bla)
VALUES(5,'test');
go 10 

Deyimi yazdırmak için index optimize proc'u yürütün.

EXECUTE dbo.IndexOptimize
@Databases = 'TestDB',
@FragmentationLow = 'INDEX_REBUILD_ONLINE',
@FragmentationMedium = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@Indexes = 'TestDB.DBO.TEST_INDX',
@Execute = 'N',
@MinNumberOfPages = 1;

Sonuç:

Command: ALTER INDEX [IX1] ON [TestDB].[dbo].[TEST_INDX] REBUILD WITH (SORT_IN_TEMPDB = OFF, ONLINE = ON, RESUMABLE = OFF)

Comment: ObjectType: Table, IndexType: NonClustered, ImageTex
t: No, NewLOB: No, FileStream: No, ColumnStore: No, AllowPageLocks: Yes, PageCount: 1, Fragmentation: 0
Outcome: Not Executed
Duration: 00:00:00
Date and time: 2019-01-09 14:48:12

Oluşturulan komutu yürütme

ALTER INDEX [IX1] ON [TestDB].[dbo].[TEST_INDX] REBUILD WITH (SORT_IN_TEMPDB = OFF, ONLINE = ON, RESUMABLE = OFF)

Sıkıştırma korunur

name    data_compression_desc
IX1 PAGE

Bir bakım planıyla yeniden inşayı test etme (ola'nın çözümü için şiddetle tartışırım)

Dizinleri yeniden oluştur

resim açıklamasını buraya girin

Test tablosunu seçin

resim açıklamasını buraya girin

Bazı test parçalanma seviyeleri ekleyin.

resim açıklamasını buraya girin

Parçalanmaya devam etmek için bazı değerler ekleyin

INSERT INTO dbo.TEST_INDX(id)
SELECT id from TEST_INDX
go 4

Parçalanma yüzdesini kontrol edin

SELECT 
I.[name] AS  INDX ,
IPS.avg_fragmentation_in_percent,
IPS.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), object_id('[dbo].[TEST_INDX]'), NULL, NULL, NULL) AS IPS
INNER JOIN sys.indexes AS I ON I.[object_id] = IPS.[object_id]
AND IPS.index_id = I.index_id
WHERE IPS.database_id = DB_ID()
and I.name = 'IX1'

Sonuç

INDX    avg_fragmentation_in_percent    page_count
IX1 66,6666666666667    3

Planı çalıştır

resim açıklamasını buraya girin

Buradaki ilginç kısım, plan raporuna bakıldığında, DATA_COMPRESSION = PAGEseçeneğin oluşturulan REBUILDkomuta eklenmiş olmasıdır !

Command:USE [TestDB]
GO
ALTER INDEX [IX1] ON [dbo].[TEST_INDX] REBUILD PARTITION = ALL WITH (PAD_INDEX = ON, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, RESUMABLE = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 80, DATA_COMPRESSION = PAGE)

Parçalanma:

INDX    avg_fragmentation_in_percent    page_count
IX1 0   2

Sıkıştırma:

name    data_compression_desc
IX1 PAGE

Sıkıştığım 3 veritabanının tüm sıkıştırmalarını kaybettiğini ve onu yeniden uygulamak zorunda olduğumu fark ettiğimde size rastladım. Bu çalışmanın bir parçası olarak, sonuçlarınızı test ettim ve onayladım, ancak bunun nasıl olduğu hakkında hiçbir fikrim yok. Karşılaştığım diğer tek olasılık, dizinler devre dışı bırakılırsa, yeniden oluşturulduğunda sıkıştırmayı kaybetmeleri. ETL ekibimiz için durum böyle görünmüyor. Ben de SQLServerCentral bu soruyu sordum: sqlservercentral.com/Forums/2017336/Databases-Lost-Compression Tamamen bunun nasıl olduğu için bir kayıp.
Marvel

Merhaba @Marvel, başka bir süreç veritabanlarında dizinleri yeniden yaratmış olabilir? Örneğin, bazı uygulamalar bıraktıkları ve sayısız dizin oluşturdukları 'yükseltmeler' yaparlar. Ancak kimsenin daha fazla ayrıntı olmadan açık bir açıklama yapabileceğini sanmıyorum. Bir dahaki sefere, dizin oluşturma tarihini bulabilir ve yeniden oluşturuldukları yerde bulabilir (örneğin, bu bağlantıdaki sorgu ile: stackoverflow.com/questions/7579932/… . Aksi takdirde her zaman bir soru olarak sorabilirsiniz, ancak daha fazla bilgi vermeniz gerektiğini düşünüyorum
Randi Vertongen

1
Teşekkürler Randi! Veritabanlarında SCHEMA_OBJECT_CHANGE_GROUP denetimi ayarladım, ancak bu kesinlikle günlükleri daha hızlı ayrıştırmamda bana yardımcı olacak. Zaten suçlulardan birini buldum - veritabanlarının sahibi, sıkıştırmayı isteyen kişi tabloları ve dizinleri sürekli değiştiriyor. Yeni tablolar oluşturduğu ve eski verileri taşıdığı ve yeni dizinler oluşturduğu zaman sıkıştırmanın kaybolmasına neden olacağını fark etmiyordu. :( Ben onun tablolar ve dizinleri oluşturmak için doğru bir şekilde ona vermiş ben ancak o sadece suçlu olduğunu düşünmüyorum ben onun e bu yaptığını düşünemiyorum..
Marvel
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.