Das neue Feature der Datenkompression des SQL Server 2008 zielt genau auf einen Nerv, der von jeden Admin zum Chiropraktiker treibt: Die Performance Bremse Nummer 1: Der Datenträgerzugriff (I/O Bremse).
Das Prinzip der Datacompression erschient relativ simpel. Man komprimiere die Daten und hat somit weniger Datenzugriff. Die Datacompression geht noch einen Schritt weiter: Die komprimierten Daten landen komprimiert im Speicher!
Fazit: Weniger HDD Zugriff..weniger RAM Verbrauch. Aber!! zu Lasten der CPU. Der SQL Server fungiert hier als Kanal für den Zugriff auf die Daten und ist verantwortlich für das transaparente Zugreifen (Lesen und Schreiben) der Daten. Das heißt, dass trotz Komprimierung keine T-SQL geändert werden müssten.
Die Komprimierung kann dabei auf Zeilen oder Seiten Niveau arbeiten. Tabellen, Indizes oder auch partitionierte Tabelle könne ebenfalls komprimiert werden. Allerdings nicht gleich die gesamte DB.
Zum testen folgendes Script:
Hier das Skript aus meinem Vortrag zum Thema SQL Server Datacompression:
create table T3
(
Id int not null
,Nr int not null
,Platzhalter nchar(400) null default ‚#‘
)
go–Irgendwelche 200.000 Zeilen einfügen
create table T4
(
Id int not null
,Nr int not null
,Platzhalter nchar(400) null default ‚#‘
)
go–Irgendwelche 200.000 Zeilen einfügen
–Schätzung der Kompression
sp_estimate_data_compression_savings dbo,t4,null,null, ‚page‘
go
sp_estimate_data_compression_savings dbo,t4,null,null, ‚row‘
go——–Komprimierung einschalten
ALTER TABLE [dbo].[T4] REBUILD PARTITION = ALL
WITH
(DATA_COMPRESSION = PAGE)–Test für vorher und nachher ..SQL Server Dienst evtl neu starten oder Speicherverbrauch beobachten
–Nachher
set statistics io on
set statistics time on
select * from T4 where id between 10 and 100000
–Vorher
set statistics io on
set statistics time on
select * from T3 where id between 10 and 100000–von 180 MB auf ca 3 MB Speicherverbrauch reduziert.