Comprender el tamaño de almacenamiento de 'tiempo' en SQL Server

El primer byte de un datetime2 value almacena la precisión del valor, lo que significa el almacenamiento real requerido para un datetime2 El valor es el tamaño de almacenamiento indicado en la tabla anterior más 1 byte adicional para almacenar la precisión. Esto hace que el tamaño máximo de un datetime2 valor 9 bytes:1 byte almacena precisión más 8 bytes para el almacenamiento de datos con la máxima precisión.

Y el datetime2 El tipo de datos funciona exactamente de la misma manera con respecto a los ejemplos anteriores. En otras palabras, solo informa el byte adicional cuando se convierte a varbinary .

Por lo tanto, el byte adicional mencionado en la documentación de Microsoft también parece aplicarse al tiempo. .

Sin embargo, el tamaño de almacenamiento real de su tiempo los valores dependerán de dónde se almacenen los datos.

Datos almacenados en una base de datos

Cuando una columna de base de datos tiene un tipo de hora , su precisión se especifica en el nivel de columna:no a nivel de datos. En otras palabras, se especifica una vez para toda la columna. Esto tiene sentido, porque cuando define una columna como time(7) , sabe que todas las filas serán time(7) . No hay necesidad de gastar valiosos bytes reafirmando ese hecho en cada fila.

Cuando examinas un tiempo valor como está almacenado en SQL Server, verá que es el mismo que el varbinary resultado, pero sin la precisión.

A continuación se muestran ejemplos que muestran cómo tiempo Los valores se almacenan en SQL Server.

En estos ejemplos, creo una base de datos con varios time(n) columnas, y luego use COL_LENGTH() para devolver la longitud de cada columna, en bytes. Luego inserto valores en esas columnas, antes de usar DBCC PAGE para comprobar el tamaño de almacenamiento que cada vez el valor ocupa el archivo de la página.

Crear una base de datos:

CREATE DATABASE Test;

Crear una tabla:

USE Test;

CREATE TABLE TimeTest (
    t0 time(0),
    t1 time(1),
    t2 time(2),
    t3 time(3),
    t4 time(4),
    t5 time(5),
    t6 time(6),
    t7 time(7)
    );

En este caso, creo ocho columnas, una para cada escala definida por el usuario que podemos usar con time(n) .

Ahora podemos verificar el tamaño de almacenamiento de cada columna.

Longitud en Bytes usando COL_LENGTH()

Utilice COL_LENGTH() para verificar la longitud (en bytes) de cada columna:

SELECT 
  COL_LENGTH ( 'TimeTest' , 't0' ) AS 't0',
  COL_LENGTH ( 'TimeTest' , 't1' ) AS 't1',
  COL_LENGTH ( 'TimeTest' , 't2' ) AS 't2',
  COL_LENGTH ( 'TimeTest' , 't3' ) AS 't3',
  COL_LENGTH ( 'TimeTest' , 't4' ) AS 't4',
  COL_LENGTH ( 'TimeTest' , 't5' ) AS 't5',
  COL_LENGTH ( 'TimeTest' , 't6' ) AS 't6',
  COL_LENGTH ( 'TimeTest' , 't7' ) AS 't7';  

Resultado:

+------+------+------+------+------+------+------+------+
| t0   | t1   | t2   | t3   | t4   | t5   | t6   | t7   |
|------+------+------+------+------+------+------+------|
| 3    | 3    | 3    | 4    | 4    | 5    | 5    | 5    |
+------+------+------+------+------+------+------+------+

Entonces, una vez más, obtenemos el mismo resultado que la documentación indica que obtendremos. Esto es de esperar, porque la documentación establece explícitamente "Longitud de columna (bytes)", que es exactamente lo que estamos midiendo aquí.

Recuerda, esto es antes insertamos cualquier dato. Las propias columnas determinan la precisión (y, por lo tanto, el tamaño de almacenamiento) de cualquier dato que se inserte, y no al revés.

Utilice la PÁGINA DBCC para comprobar los datos almacenados

Ahora insertemos datos, luego usemos DBCC PAGE para encontrar el tamaño de almacenamiento real de los datos que almacenamos en cada columna.

Insertar datos:

DECLARE @t time(7) = '10:15:30.1234567';
INSERT INTO TimeTest ( t0, t1, t2, t3, t4, t5, t6, t7 )
SELECT @t, @t, @t, @t, @t, @t, @t, @t;

Ahora selecciona los datos (solo para comprobarlo):

SELECT * FROM TimeTest;

Resultado (usando salida vertical):

t0 | 10:15:30
t1 | 10:15:30.1000000
t2 | 10:15:30.1200000
t3 | 10:15:30.1230000
t4 | 10:15:30.1235000
t5 | 10:15:30.1234600
t6 | 10:15:30.1234570
t7 | 10:15:30.1234567

Como era de esperar, los valores usan la precisión que se especificó previamente en el nivel de columna.

Tenga en cuenta que mi sistema muestra ceros finales. El tuyo puede o no hacerlo. Independientemente, esto no afecta la precisión o exactitud real.

Ahora, antes de usar DBCC PAGE() , necesitamos saber qué PagePID pasarle. Podemos usar DBCC IND() para encontrar eso.

Encuentra el PID de la página:

DBCC IND('Test', 'dbo.TimeTest', 0);

Resultado (usando salida vertical):

-[ RECORD 1 ]-------------------------
PageFID         | 1
PagePID         | 308
IAMFID          | NULL
IAMPID          | NULL
ObjectID        | 1541580530
IndexID         | 0
PartitionNumber | 1
PartitionID     | 72057594043236352
iam_chain_type  | In-row data
PageType        | 10
IndexLevel      | NULL
NextPageFID     | 0
NextPagePID     | 0
PrevPageFID     | 0
PrevPagePID     | 0
-[ RECORD 2 ]-------------------------
PageFID         | 1
PagePID         | 384
IAMFID          | 1
IAMPID          | 308
ObjectID        | 1541580530
IndexID         | 0
PartitionNumber | 1
PartitionID     | 72057594043236352
iam_chain_type  | In-row data
PageType        | 1
IndexLevel      | 0
NextPageFID     | 0
NextPagePID     | 0
PrevPageFID     | 0
PrevPagePID     | 0

Esto devuelve dos registros. Estamos interesados ​​en el PageType de 1 (el segundo registro). Queremos el PagePID de ese registro. En este caso, el PagePID es 384 .

Ahora podemos tomar ese PagePID y usarlo en lo siguiente:

DBCC TRACEON(3604, -1);
DBCC PAGE(Test, 1, 384, 3);

Ahora mismo estamos interesados ​​principalmente en la siguiente parte:

Slot 0 Column 1 Offset 0x4 Length 3 Length (physical) 3

t0 = 10:15:30                       

Slot 0 Column 2 Offset 0x7 Length 3 Length (physical) 3

t1 = 10:15:30.1                     

Slot 0 Column 3 Offset 0xa Length 3 Length (physical) 3

t2 = 10:15:30.12                    

Slot 0 Column 4 Offset 0xd Length 4 Length (physical) 4

t3 = 10:15:30.123       

Slot 0 Column 5 Offset 0x11 Length 4 Length (physical) 4

t4 = 10:15:30.1235                  

Slot 0 Column 6 Offset 0x15 Length 5 Length (physical) 5

t5 = 10:15:30.12346                 

Slot 0 Column 7 Offset 0x1a Length 5 Length (physical) 5

t6 = 10:15:30.123457                

Slot 0 Column 8 Offset 0x1f Length 5 Length (physical) 5

t7 = 10:15:30.1234567                                                                      

Entonces obtenemos el mismo resultado que los estados de documentación. Esto sugeriría que la precisión no se almacena con los valores.

Podemos confirmarlo examinando los datos reales.

Los valores de tiempo reales se almacenan en esta parte del archivo de página:

Memory Dump @0x0000000423ADA060

0000000000000000:   10002400 42900095 a205d459 384b8233 02f31603  ..$.B..•¢.ÔY8K‚3.ó..
0000000000000014:   167ae51e dc00c1f6 34990887 a311fc55 080000    .zå.Ü.Áö4..‡£.üU...

Podemos extraer los valores de tiempo reales eliminando algunas cosas. Una vez eliminado, permanecerá lo siguiente:

42900095 a205d459 384b8233 02f31603
167ae51e dc00c1f6 34990887 a311fc55

Estos dígitos hexadecimales contienen todos nuestros datos de tiempo, pero no la precisión . Sin embargo, están organizados en fragmentos de 4 bytes, por lo que debemos reorganizar los espacios para obtener los valores individuales.

Aquí está el resultado final. Coloqué cada valor de fecha/hora en una nueva línea para una mejor legibilidad.

429000
95a205
d45938
4b823302
f3160316
7ae51edc00
c1f6349908
87a311fc55

Esos son los valores hexadecimales reales (menos la precisión ) que obtendríamos si convertimos el tiempo valor a varbinary . Así:

SELECT 
  CONVERT(VARBINARY(16), t0) AS 't0',
  CONVERT(VARBINARY(16), t1) AS 't1',
  CONVERT(VARBINARY(16), t2) AS 't2',
  CONVERT(VARBINARY(16), t3) AS 't3',
  CONVERT(VARBINARY(16), t4) AS 't4',
  CONVERT(VARBINARY(16), t5) AS 't5',
  CONVERT(VARBINARY(16), t6) AS 't6',
  CONVERT(VARBINARY(16), t7) AS 't7'
FROM TimeTest;

Resultado (usando salida vertical):

t0 | 0x00429000
t1 | 0x0195A205
t2 | 0x02D45938
t3 | 0x034B823302
t4 | 0x04F3160316
t5 | 0x057AE51EDC00
t6 | 0x06C1F6349908
t7 | 0x0787A311FC55

Esa consulta produce el mismo resultado, excepto que cada valor se ha antepuesto con la precisión.

Aquí hay una tabla que compara los datos reales del archivo de página con los resultados de CONVERT() operación.

Entonces podemos ver que el archivo de la página no almacena la precisión, pero el resultado convertido sí lo hace.

Resalté las partes de fecha y hora reales en rojo. También eliminé el 0x prefijo de los resultados convertidos, de modo que solo se muestren los datos de fecha/hora reales (junto con la precisión).

También tenga en cuenta que el hexadecimal no distingue entre mayúsculas y minúsculas, por lo que el hecho de que uno use minúsculas y el otro use mayúsculas no es un problema.

Conclusión

Al convertir una hora valor a varbinary , necesita un byte adicional para almacenar la precisión. Necesita la precisión para interpretar la porción de tiempo (porque esto se almacena como un intervalo de tiempo, cuyo valor exacto dependerá de la precisión).

Cuando se almacena en una base de datos, la precisión se especifica una vez en el nivel de columna. Esto parece lógico, ya que no es necesario agregar la precisión a cada fila cuando todas las filas tienen la misma precisión de todos modos. Eso requeriría un byte adicional para cada fila, lo que aumentaría innecesariamente los requisitos de almacenamiento.