janvier
2011
Un article de zinzineti
La plus petite entité physique dans laquelle SQL SERVER stocke les données d’une table s’appelle page.
Chaque page de données occupe un espace de 8 kilo-octets (8192 octets) sur le disque dur.
96 octets sont réservés pour l’entête de la page afin de stocker des méta-données.
Et il reste donc (8192 – 96) = 8096 octets.
Des 8096 octets restants, SQL SERVER réserve :
8060 octets pour les données proprement dites (lignes des tables)
2 octets pour stocker les information sur l’état de la ligne (row status information)
2 octets pour stocker la longueur fixe de la ligne (length of the fixed length portion of the row)
2 octets pour stocker le nombre de colonnes de la table (number of columns)
1 bit (0,13 octet) par colonne NULL qu’il faut arrondir par excès pour avoir un nombre entier d’octet
2 octets pour stocker l’indicateur de fin de page (row-offset location )
2 octets pour stocker le nombre de colonne variable. Ces octets ne sont pas utiliser s’il n’y a pas de colonne variable dans la table.
Une page de données contient EXCLUSIVEMENT des données d’une même table
De façon standard une ligne d’une table ne peut donc pas excéder 8060 octets !
Démo
————-
create table T_test (col1 char(8000), col2 char(60))
Résultat
——–
Msg 1701, Level 16, State 1, Line 1
Creating or altering table ‘T_test’ failed because the minimum row size would be 8067, including 7 bytes of internal overhead. This exceeds the maximum allowable table row size of 8060 bytes.
SQL SERVER indique clairement qu’il ne peut pas créer la table T_test parce qu’il lui faut 8067 octets .
dont les 7 octets d’overhead. Pourquoi SQL SERVER ne nous parle pas des 2 octets pour stocker l’indicateur de fin de page (row-offset location ) et d’autres ?
Pour aller au-delà des 8060 octets on peut utiliser les types variables :
create table T_test (col1 varchar(8000), col2 varchar(60))
Mais cette façon de faire n’est pas une bonne pratique. Veuillez à ce que les lignes de vos tables n’excèdent pas 8060 octets.
Car le moteur de base de données SQL Server déclenche l’exception 511 et annule l’instruction en cours d’exécution dans les cas suivants :
–> L’instruction SELECT produit une ligne de résultats ou une ligne de table de travail intermédiaire excédant les 8060 octets.
–> L’instruction DELETE, INSERT ou UPDATE tente d’opérer une action sur une ligne excédant les 8060 octets.
————————————————————–
Auteur : Etienne ZINZINDOHOUE
————————————————————–
à quoi servent les 36 octets 8096 – 8060 ?
Les 36 octets restants sont utilisés comme suit :
2 octets pour stocker les information sur l’état de la ligne (row status information)
2 octets pour stocker la longueur fixe de la ligne (length of the fixed length portion of the row)
2 octets pour stocker le nombre de colonnes de la table (number of columns)
1 bit (0,13 octet) par colonne NULL qu’il faut arrondir par excès pour avoir un nombre entier d’octet
2 octets pour stocker l’indicateur de fin de page (row-offset location )
2 octets pour stocker le nombre de colonne variable. Ces octets ne sont pas utiliser s’il n’y a pas de colonne variable dans la table.
21 octets pour stocker le pointeur des colonnes dont la taille dépasse 8060 octets
….
Merci pour cet intéressant billet
8096 (page sans en-tête) – 8060 = 36 octets
A quoi servent ces 36 octets ? Il y en a 2 pour l’indicateur de fin de page de cette unique ligne, mais à part cela?
Beaucoup de sources sortent ce chiffre de 8060 octets maximum par ligne sans vraiment d’explication.