Auswirkung des Änderns von Datentypen bei aktivierter Zeilenkomprimierung

Das Unternehmen, für das ich arbeite, verfügt über einige SQL Server-Datenbanken mit Tabellen mit + - 500.000.000 Zeilen. Wir führen Enterprise-Editionen von SQL Server 2008R2 und 2014 aus.

Big Data-Typen

Wenn ich mir die verwendeten Datentypen in der größten Tabelle ansehe, sehe ich viele BIGINT-Spalten. Ich untersuchte die Daten in diesen Spalten mit einem Skript von Thomas Larock und schrieb selbst die Werte MIN () und MAX (). Ich kam zu dem Schluss, dass Daten in diesen BIGINT-Spalten problemlos in INT- oder sogar SMALLINT / TINYINT-Spalten angepasst werden können. (Ich bin mir bewusst, dass einige Spalten in Zukunft möglicherweise den Bereich BIGINT benötigen, daher ändere ich nicht blind alle Datentypen, ohne vorher mit den Entwicklern zu sprechen.)

Beim Vergleich der möglichen Einsparungen beim Ändern der Datentypen scheint die Tabelle halb so groß zu sein wie derzeit (ohne Berücksichtigung von Indizes und anderen Tabellen). Diese Zahlen sind ohne Datenkomprimierung.

REIHEN-Komprimierung

In der großen Tabelle ist die ROW-Komprimierung aktiviert. Ich frage mich, welche tatsächlichen Auswirkungen das "Verkleinern" der Spaltendatentypen haben könnte, wenn man bedenkt, dass bei der ROW-Komprimierung nur die benötigten Bytes verwendet werden . Wenn beispielsweise ein Wert in 1 Byte gespeichert werden kann, dauert die Speicherung nur 1 Byte.

Aktuelle Frage

Würde es helfen, Datentypen zu verkleinern, damit die ROW-Komprimierung weniger Ressourcen verbraucht? Oder ist es sicher zu sagen, dass es keinen Unterschied zwischen den Datentypen BIGINT, INT oder SMALLINT gibt, da die ROW-Komprimierung aktiviert ist?

Da die Dokumentation, die Sie bereits haben, Status verknüpft hat, verwendet die ROW-Komprimierung nur die benötigten Bytes. Sobald die ROW-Komprimierung verwendet wird, sind die CPU-Zyklen, die zum Konvertieren von / nach int oder bigint verwendet werden, dieselben: Ich würde mir darüber keine Sorgen machen.

Übrigens, wenn Sie nicht sicher sind, ob int / bigint einen Einfluss auf die Datenbankgröße hat oder nicht (hat es nicht), können Sie sich mit einem schnellen und schmutzigen Repro selbst davon überzeugen:

USE tempdb;
GO

CREATE TABLE SomeTable (
    SomeColumn bigint
)
GO

ALTER TABLE [dbo].[SomeTable] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = NONE);

INSERT INTO SomeTable 
SELECT TOP 10000000 ROW_NUMBER() OVER (ORDER BY(SELECT NULL))
FROM sys.all_columns AS A1
CROSS JOIN sys.all_columns AS A2;
GO

-- Rebuild the heap, so that pages compact nicely
ALTER TABLE dbo.SomeTable 
REBUILD 
WITH 
(
    MAXDOP = 1, 
    ONLINE = OFF,
    FILLFACTOR = 100,
    PAD_INDEX = OFF
);
GO

SELECT SUM(page_count)
FROM sys.dm_db_index_physical_stats(
        DB_ID(),
        OBJECT_ID('SomeTable'),
        DEFAULT,
        DEFAULT,
        'detailed'
    ) AS ips;


-- 21009 pages used


ALTER TABLE [dbo].[SomeTable] REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = ROW);
GO


SELECT SUM(page_count)
FROM sys.dm_db_index_physical_stats(
        DB_ID(),
        OBJECT_ID('SomeTable'),
        DEFAULT,
        DEFAULT,
        'detailed'
    ) AS ips;

-- 13587 pages used


ALTER TABLE SomeTable ALTER COLUMN SomeColumn int;

-- Rebuild the heap, so that pages compact nicely
ALTER TABLE dbo.SomeTable 
REBUILD 
WITH 
(
    MAXDOP = 1, 
    ONLINE = OFF,
    FILLFACTOR = 100,
    PAD_INDEX = OFF
);
GO


SELECT SUM(page_count)
FROM sys.dm_db_index_physical_stats(
        DB_ID(),
        OBJECT_ID('SomeTable'),
        DEFAULT,
        DEFAULT,
        'detailed'
    ) AS ips;

-- 13587 pages used (same as bigint)