Augmenter l'espace réservé à une table

Bonjour,

je ne sais pas si cette question a déjà été posée, mais je n'ai trouvé que des réponses expliquant comment augmenter la taille de la base de données.
Or, ce que je voudrais, c'est augmenter la taille d'une table.

Je m'explique : lorsque je génère sur ma base le rapport "Utilisation du disque par table", je vois une colonne "Réservé (Ko)", suivi des colonnes indiquant l'espace utilisé par les données, par l'index, et l'espace libre.
Est-il possible d'augmenter la taille réservée à une table?

Je suis SQLServer 2012, Microsoft SQL Server Management Studio 11.0.2100.60.

Merci d'avance pour votre aide.

Non, étant donné qu'une table n'est pas un fichier.
En fait toutes les tables et index sont mis dans le fichier de la base (ou les fichiers s'il y en a plusieurs), SQL Server répartissant de manière automatique et équitable entre les différentes fichiers. Ensuite il se sert des espaces vide dans le fichier pour stocker les segments de table et s'il y a lieu il agrandit le fichier (ce qui est généralement préjudiciables aux performances).
C'est pourquoi tout ce que vous avez lu concerne l'augmentation de la taille de la base, car l'augmentation de la taille d'une table n'a aucun sens dans SQL Server !

A +

Merci pour ces informations.
Donc ayant encore de l'espace disponible dans la base, le fichier pourra "grossir" au besoin ? Ou je dois tout de même augmenter l'espace alloué à la base de données?

Bonjour,

Le fichier grossit suivant la spécification de l'incrément de fichier et la limitation de sa taille.

Pour voir la valeur de ces paramètres, dans SQL Server Management Studio (SSMS) :

Pressez F8 pour afficher l'explorateur d'objets s'il n'est pas déjà affiché
Connectez-vous à l'instance hébergeant la base de données, puis dans l'explorateur d'objets, ouvrez le nœud de l'instance
Faites un clic-droit sur la base de données > Properties
Dans la fenêtre qui s'affiche, choisissez dans le menu de gauche la page Files
La colonne Initial Size vous donne la taille actuelle du fichier. La colonne Autogrowth vous indique la taille de l'incrément qui sera alloué lorsque le fichier sera plein. Maxsize vous indiquera si la taille maximale du fichier n'est limitée que par la taille du disque (Unlimited) ou à l'inverse une taille maximale en Mo. Si vous voulez changer ces paramètres, il suffit de cliquer sur le bouton ellipse pour ce faire, et de valider le tout par OK une fois terminé.

En ce qui concerne les fichiers de données, l'idéal est de les tailler à la création de la base, de façon à ce qu'ils ne soient jamais fragmentés.
S'il venaient à grossir, il faut veiller à octroyer au compte de service qui exécute SQL Server le droit Perform Volume Maintenance Task : celui ci permet d'allouer l'incrément quasiment immédiatement. A l'inverse, les transactions doivent attendre que l'incrément soit entièrement mis à zéro pour pouvoir continuer leur exécution, ce qui peut être catastrophique. Si ce droit n'est pas déjà octroyé, il faudra redémarrer le service SQL Server. Il est possible d'octroyer ce droit facilement à l'installation de SQL Server 2016 : il y a une coche réservée à cet effet dans la page de spécification de l'emplacement par défaut des fichiers.

Ce droit ne vaut que pour le fichier de données. En ce qui concerne le fichier du journal des transactions, il faut veiller là aussi à bien le tailler dès la création de la base de données. Suivant son utilisation, cela varie, en général, entre 10 et 30% de la taille allouée aux fichiers de données. Par expérience et habitude, lors de la création de la base, je lui spécifie toujours un fichier d'un Go, puis je le fais grossir jusqu'à la taille voulue par incréments d'un Go. En effet, le fichier du journal des transactions est découpé en morceaux qu'on appelle journaux virtuels (Virtual Log Files, VLFs). Le moteur marque pour réutilisation l'espace du journal des transactions d'un VLF une fois que toutes les transactions qu'il reflète sont terminées ... et il est possible qu'une transaction occupe plusieurs VLFs.

Suivant la taille de l'incrément, un nombre particulier de VLF est décidé par le moteur (et il n'y a aucun moyen de changer ce comportement)

Jusqu'à SQL Server 2012 inclus, c'était : jusqu'à 64Mo, 4 VLF - entre 64Mo et 1Go, 8 VLFs - Plus d'1Go : 16 VLFs
A partir de SQL Server 2014, c'est : Si la taille de l'incrément est plus petite que 1/8 de la taille actuelle du fichier du journal des transactions : 1 VLF dont la taille est celle de l'incrément. Sinon, on revient à la règle qui valait jusqu'à SQL Server 2012.

Donc si l'on crée une base de données en spécifiant un fichier du journal des transactions de 64Go, on aura 16 VLFs de 4Go, ce qui est assez énorme. A l'inverse, si on a trop de VLFs, cela ralentit légèrement les sauvegardes de base de données, mais aussi les restaurations et les récupérations. Avez des incréments d'un Go, on a des VLFs de 128Mo, ce qui est assez raisonnable, et que je trouve être la bonne balance. Pour connaître le nombre de VLF, il suffit d'exécuter l'instruction DBCC LOGINFO : elle retourne une ligne par VLF, avec les caractéristiques de chacun, notamment leur taille.

Tout ça pour dire que ça a l'air simple comme ça, mais il faut bien faire attention quand on crée une base de données ;)

@++ ;)

Merci énormément pour cette réponse plus que détaillée qui m'a vraiment été utile.

Je n'ai pas créé cette base, je reprends le projet de mon prédécesseur, donc je n'ai pas pu allouer la taille à la création.

Bonne fin de journée à tous, je passe la discussion en résolu.