1

J'essaie de comprendre comment SQL Server alloue et réserve de l'espace. Après avoir exécuté les exemples de l'article "Comment la conception de table peut-elle affecter les performances de votre serveur SQL?" [1], j'ai reçu les résultats [My 1.1] dérivant de ceux de l'article [1.1].
Pourquoi? Pourquoi dans un cas l'espace excessif est-il réservé/alloué (tous les cas dans [1]) mais pas dans un autre [Ma 1.1]?
(Notez que dans [1] dans les deux cas l'espace excessif est réservé, bien que sur mon ordinateur seulement dans un cas)comment le stockage est-il réservé par SQL Server? et comment l'annuler?

Comment l'espace est-il alloué, réservé par SQL Server?
Et comment puis-je le contrôler/gérer?

[1] ======
Comment la conception de la table peut-elle avoir un impact sur les performances de SQL Server?
http://sqlserver-training.com/how-table-design-can-impact-your-sql-server-performance

[Mon 1.1]
Mes résultats Diverger de [1] ci-dessous

name        rows reserved data  index_size unused 
---------------------------------- ----- --------- -------- ----------- --------- 
Fixed_Lenght_Row_Table_Optimised 10000 40008 KB 40000 KB 8 KB  0 KB 

[1.1] Résultats dans [1] détourner de la mine au-dessus

name        rows reserved data  index_size unused 
---------------------------------- ----- --------- -------- ----------- --------- 
Fixed_Lenght_Row_Table_Optimised 10000 40072 KB 40000 KB 8 KB  64 KB 

[1.2]
Résultats de [1] co concordant avec le mien

name         rows reserved data  index_size unused 
---------------------------------- ----- --------- -------- ----------- --------- 
Fixed_Lenght_Row_Table_Non_Optimised 10000 80072 KB 80000 KB 8 KB  64 KB 

Répondre

3

L'article dans le lien est au mieux douteux. Ne spécifie pas quelle version de SQL Server utiliser et quelles sont les différentes options activées/désactivées. Depuis SQL Server 2005, il y a un stockage de petites lignes pour les colonnes dépassant la limite de 8K (voir Table and Index Organization), il y a des options par ligne et hors ligne par défaut (voir sp_tableoption) et il y a beaucoup d'options de compression (row-level, page-level, Unicode).

Pour des informations précises, je m'en tenir à la documentation officielle du produit, à partir de Planning and Architecture (Database Engine). Pour une lecture plus digeste, achetez l'un des livres bien établis, comme Microsoft SQL Server 2008 Internals ou Inside Microsoft SQL Server 2005: The Storage Engine.

3

Cela a du sens: vous avez 64 Ko d'espace inutilisé. Vous verrez souvent des différences mineures dans l'espace réservé comme ceci

Je l'exécuterais aussi de cette façon aussi avec le 2ème paramètre. Il peut faire aucune différence

EXEC [sp_spaceused][1] 'Fixed_Lenght_Row_Table_Non-Optimised', 'true' 

Et puis de sp_spaceused

Lorsque vous laissez tomber ou reconstruire un grand index, ou laisser tomber ou tronquer grandes tables, le moteur de base de données diffère les désaffectations de page réelle et leurs verrous associés jusqu'à ce que la transaction soit validée. Les opérations de suppression différée ne libèrent pas immédiatement l'espace alloué.Par conséquent, les valeurs retournées par sp_spaceused immédiatement après la suppression ou troncature d'un objet volumineux peuvent ne pas refléter l'espace disque disponible. Pour plus d'informations sur les allocations différées , voir Dropping et Reconstruire des objets volumineux.

Enfin, aurez-vous des tables qui auront 4000 octets + lignes? Si vous voulez surcharger pour optimiser, je dirais que vous êtes prématuré ... faites juste que votre implémentation de la conception soit correcte (ce sont des étapes séparées)