SQL Server har en systemlagrad procedur som heter sp_estimate_data_compression_savings , som låter dig kontrollera ett objekts storlek och dess uppskattade storlek med olika komprimeringsnivåer.
Om objektet redan är komprimerat kan du använda den här proceduren för att uppskatta dess storlek när det komprimeras igen.
Objekt kan komprimeras genom att använda rad-, sida-, columnstore- eller columnstore-arkivkomprimering.
Kompression kan utvärderas för hela tabeller eller delar av tabeller. Detta inkluderar heaps, klustrade index, icke-klustrade index, columnstore-index, indexerade vyer och tabell- och indexpartitioner.
Exempel
Här är ett exempel att visa.
EXEC sp_estimate_data_compression_savings @schema_name ='Warehouse', @object_name ='StockItemHoldings', @index_id =NULL, @partition_number =NULL, @data_compression ='ROW'; Resultat:
+--------------------+--------------+---------------- --+--------------------+-------------------------------- ------------------+-------------------------------------- ------------------+-------------------------------- --------------------+------------------------------------- --------------------------+| objektnamn | schemanamn | index_id | partitionsnummer | size_with_current_compression_setting(KB) | size_with_requested_compression_setting(KB) | sample_size_with_current_compression_setting(KB) | sample_size_with_requested_compression_setting(KB) ||-------------------+---------------------+-------- ----+--------------------+------------------------ --------------------+------------------------------------ ------------------+-------------------------------------- ----------------------+---------------------------- --------------------------|| Lagervaruinnehav | Lager | 1 | 1 | 32 | 8 | 40 | 16 |+--------------------+--------------+---------------- --+--------------------+-------------------------------- ------------------+-------------------------------------- ----------------+--------------------------------- ------------------+-------------------------------------- ------------------------+
För att rädda dig från att behöva göra för mycket sidledes rullning, här använder den återigen vertikal utmatning:
-[ RECORD 1 ]-------------------------objektnamn | StockItemHoldingsschema_name | Warehouseindex_id | 1partitionsnummer | 1size_with_current_compression_setting(KB) | 32size_with_requested_compression_setting(KB) | 8sample_size_with_current_compression_setting(KB) | 40sample_size_with_requested_compression_setting(KB) | 16
Kompressionsstorlekarna är i kilobyte (KB).
I det här fallet verkar det finnas en betydande fördel med att använda radkomprimering i den här tabellen. Den går från 32 KB till 8 KB. Detta förutsätter att det är en korrekt uppskattning.
När jag körde den föregående koden angav jag alla argumentnamn. Du kan också utelämna dessa namn och bara ange värdena.
Så här:
EXEC sp_estimate_data_compression_savings 'Warehouse', 'StockItemHoldings', NULL, NULL, 'ROW'; Hur som helst är resultatet detsamma.
Här är den igen, men den här gången anger jag PAGE istället för ROW som komprimeringstyp.
EXEC sp_estimate_data_compression_savings @schema_name ='Warehouse', @object_name ='StockItemHoldings', @index_id =NULL, @partition_number =NULL, @data_compression ='PAGE'; Resultat (med vertikal utdata):
-[ RECORD 1 ]-------------------------objektnamn | StockItemHoldingsschema_name | Warehouseindex_id | 1partitionsnummer | 1size_with_current_compression_setting(KB) | 32size_with_requested_compression_setting(KB) | 8sample_size_with_current_compression_setting(KB) | 40sample_size_with_requested_compression_setting(KB) | 16
I det här fallet ser siffrorna likadana ut, men du kan få väldigt olika siffror, beroende på dina uppgifter.
Kompressionstyper
@data_compression argument accepterar följande värden:
INGENRADSIDACOLUMNSTORECOLUMNSTORE_ARCHIVE
Dessa är de komprimeringsalternativ som är tillgängliga när du skapar/ändrar en tabell eller index.
COLUMNSTORE och COLUMNSTORE_ARCHIVE Alternativen är endast tillgängliga på columnstore-index (inklusive både icke-klustrade kolumnlager- och klustrade kolumnlagerindex).
@index_id Argument
Ibland kan dina resultat returnera flera rader för ett visst objekt, var och en med olika index_id .
Du kan begränsa det till ett specifikt index om du föredrar det. För att göra detta, ange index_id till @index_id argument.
Till exempel, när jag kör följande kod returneras åtta rader, var och en med olika index_id värden.
EXEC sp_estimate_data_compression_savings @schema_name ='Warehouse', @object_name ='StockItemTransactions', @index_id =NULL, @partition_number =NULL, @data_compression ='ROW'; Resultat:
+------------------------+---------------+------ ------+---------------------------+---------------------- -----------------------+-------------------------------- --------------------+------------------------------------ ------------------------+------------------------- ----------------------------+| objektnamn | schemanamn | index_id | partitionsnummer | size_with_current_compression_setting(KB) | size_with_requested_compression_setting(KB) | sample_size_with_current_compression_setting(KB) | sample_size_with_requested_compression_setting(KB) ||-----------------------------+---------------+---- ----------------------------+--------------------- --------------------------+------------------------ -----------------------+-------------------------------- --------------------------+----------------------- ------------------------------------|| StockItemTransactions | Lager | 2 | 1 | 5568 | 4120 | 4280 | 3168 || StockItemTransactions | Lager | 3 | 1 | 5184 | 3720 | 4264 | 3064 || StockItemTransactions | Lager | 4 | 1 | 5568 | 4224 | 4288 | 3256 || StockItemTransactions | Lager | 5 | 1 | 5528 | 4416 | 4280 | 3424 || StockItemTransactions | Lager | 6 | 1 | 5192 | 3456 | 4264 | 2840 || StockItemTransactions | Lager | 7 | 1 | 5192 | 3464 | 4264 | 2848 || StockItemTransactions | Lager | 9 | 1 | 5416 | 4456 | 4264 | 3512 || StockItemTransactions | Lager | 1 | 1 | 2720 | 9096 | 2720 | 9096 |+-----------------------+----------------- -----+---------------------+------------------------------- ----------------------+---------------------------- --------------------+------------------------------------- -----------------------+-------------------------------- ----------------------------+
Om vi ville begränsa den till bara en rad, kunde vi använda dess index_id .
Så här:
EXEC sp_estimate_data_compression_savings @schema_name ='Warehouse', @object_name ='StockItemTransactions', @index_id =1, @partition_number =NULL, @data_compression ='ROW'; Resultat:
+------------------------+---------------+------ ------+---------------------------+---------------------- -----------------------+-------------------------------- --------------------+------------------------------------ ------------------------+------------------------- ----------------------------+| objektnamn | schemanamn | index_id | partitionsnummer | size_with_current_compression_setting(KB) | size_with_requested_compression_setting(KB) | sample_size_with_current_compression_setting(KB) | sample_size_with_requested_compression_setting(KB) ||-----------------------------+---------------+---- ----------------------------+--------------------- --------------------------+------------------------ -----------------------+-------------------------------- --------------------------+----------------------- ------------------------------------|| StockItemTransactions | Lager | 1 | 1 | 2720 | 9096 | 2720 | 9096 |+-----------------------+----------------- -----+---------------------+------------------------------- ----------------------+---------------------------- --------------------+------------------------------------- -----------------------+-------------------------------- ----------------------------+
Du kan också använda @partition_number att göra samma sak med partitioner.
Mängden komprimering kan variera avsevärt
Mängden komprimering du får beror på data och typ av komprimering.
RAD komprimering, till exempel, tar bort onödiga bytes från kolumnvärdena genom att lagra dem i format med variabel längd. SIDA komprimering, å andra sidan, lagrar de upprepade värdena endast en gång per sida och ställer in pekaren från respektive kolumn på sidan.
Ibland kanske du upptäcker att komprimering av ett objekt inte alltid minskar dess storlek, och i vissa fall kan det faktiskt ökas dess storlek.
Detta kan hända om dina kolumner använder en datatyp som inte drar nytta av komprimering.
Radkomprimering minskar också metadataoverhead, men i vissa fall kan overheaden vara större än det gamla lagringsformatet.
Om din data inte får någon nytta av komprimering på grund av dess datatyp, är det troligt att omkostnaderna kommer att orsaka en ökning av lagringskraven snarare än en minskning.
Men variationer i komprimeringsstorlek kommer också att bero på faktiska data. Till exempel, om du har en char(10) kolumn, kommer komprimering att ta bort alla efterföljande utfyllnadstecken. Om du har många rader med efterföljande utfyllnadstecken bör du få ett bättre resultat än om du inte har några (eller få) rader med efterföljande utfyllnadstecken.
Hur uppskattar den komprimeringen?
När du kör sp_estimate_data_compression_savings tar den ett urval av data och läser sedan in den i en motsvarande tabell och index som skapats i tempdb . Tabellen eller indexet skapas i tempdb komprimeras sedan till den begärda inställningen och den uppskattade komprimeringsbesparingen beräknas.
Hur exakt är det?
Du kan få blandade resultat när du använder sp_estimate_data_compression_savings .
Låt oss göra ett litet test.
SELECT * INTO Warehouse.StockItemTransactions2FROM Warehouse.StockItemTransactions;EXEC sp_spaceused 'Warehouse.StockItemTransactions2'; Resultat (med vertikal utdata):
sp_spaceused lagrad procedur visar det faktiska diskutrymmet som används. I det här fallet använder data 15 800 KB diskutrymme.
Nu ska jag köra sp_estimate_data_compression_savings för att se vilka utrymmesbesparingar jag kommer att få om jag tillämpar komprimering på den tabellen.
EXEC sp_estimate_data_compression_savings @schema_name ='Warehouse', @object_name ='StockItemTransactions2', @index_id =NULL, @partition_number =NULL, @data_compression ='ROW'; Resultat (med vertikal utdata):
objektnamn | StockItemTransactions2schema_name | Warehouseindex_id | 0partitionsnummer | 1size_with_current_compression_setting(KB) | 15808size_with_requested_compression_setting(KB) | 9096sample_size_with_current_compression_setting(KB) | 15800sample_size_with_requested_compression_setting(KB) | 9096
Enligt dessa resultat kommer radkomprimering att minska dess storlek från 15 808 KB till en uppskattad storlek på bara 9 096 KB. Inte så illa.
Låt oss nu tillämpa radkomprimering på den här tabellen och kör sedan sp_spaceused igen.
ÄNDRA TABELL Warehouse.StockItemTransactions2REBUILD WITH (DATA_COMPRESSION =ROW);EXEC sp_spaceused 'Warehouse.StockItemTransactions2'; Resultat (med vertikal utdata):
Så det faktiska resultatet ligger mycket nära det uppskattade resultatet.
I det här fallet, sp_estimate_data_compression_savings gav en ganska exakt uppskattning av slutresultatet.
Låt oss köra sp_estimate_data_compression_savings en gång till, men med en komprimeringstyp av NONE .
EXEC sp_estimate_data_compression_savings @schema_name ='Warehouse', @object_name ='StockItemTransactions2', @index_id =NULL, @partition_number =NULL, @data_compression ='NONE'; Resultat:
objektnamn | StockItemTransactions2schema_name | Warehouseindex_id | 0partitionsnummer | 1size_with_current_compression_setting(KB) | 9096size_with_requested_compression_setting(KB) | 15808sample_size_with_current_compression_setting(KB) | 9096sample_size_with_requested_compression_setting(KB) | 15808
Detta berättar för oss vad som skulle hända om vi återgick till att använda ingen komprimering.
I det här fallet visar den oss exakt samma siffra (15 808 KB) som den visade oss innan komprimering som, som ni kommer ihåg, var ganska nära den faktiska storleken (15 800 KB) som returnerades av sp_spaceused procedur.
Så låt oss köra det igen och ta reda på det.
ÄNDRA TABELL Warehouse.StockItemTransactions2REBUILD WITH (DATA_COMPRESSION =NONE);EXEC sp_spaceused 'Warehouse.StockItemTransactions2'; Resultat (med vertikal utdata):
Så återigen, sp_estimate_data_compression_savings var nästan perfekt.
Detta är dock bara ett enkelt test. Andra tester kan ge uppskattningar som är långt borta. Jag har läst berättelser om sp_estimate_data_compression_savings ger väldigt felaktiga resultat, men jag har ännu inte upplevt det själv.
Därför verkar det som om sp_estimate_data_compression_savings kan ge en korrekt uppskattning i samma fall, och inte så mycket i andra.
Du måste bestämma hur mycket tillit du vill lägga på denna lagrade procedur. I vilket fall som helst bör du förmodligen köra ett test i din utvecklings- eller testmiljö innan du tillämpar komprimering i produktionen.