Discussion :

[benfadhelj]

Bonjour j'ai une base en prod avec une taille réservée 23 giga, il reste que 1 giga pour data avec un autogrothw de 10%.
A votre avis je la laisse faire son autogrothw ou je modifie la taille initiale du fichier (je le met a 26 giga)? Est ce que ca peut impacter la performance le manque d'espace unitilse ?
Sachant que j'ai bien de l'espace disque et que son dernier auto grothw date de 1 mois.
Si il est préférable d'augmenter manuellement la taille du fichier quels sont les bonnes pratiques et précautions à prendre.
Merci

[licardentaistor]

tout dépend de l'activité de la base de données....

[SQLpro]

Il faut provisionner les fichiers de données pour une exploitation de 3 à 5 années, afin d'éviter toute opération de croissance en pleine production. De même pour le journal de transaction, le tailler à 30% des données.

De plus une croissance de 10 % est particulièrement immonde. En effet, si ton fichier est gros (mettons 1 To) 10% cela fait 100 Go.
SQL Server utilise des disques virtuels interne pour stocker ses données. Tu vois des fichiers mais en fait ce sont des volumes (équivalent aux volumes UNIX/LINUX)...

SQL Server (comme IBM BD2 ou Oracle Database) est doté d'un OS interne qui squeeze l'OS système (Windows ou Linux) en effectuant directement les tâches de gestion de la mémoire (cache des données, des procédures, des métadonnées, …), de gestion des threads (lancement des processus, parallélisation des requêtes, planification du time-sharing, …) comme des lectures et écritures physiques (création de volume de stockage , formatage interne, lectures physiques, écritures physique, …). Le nom de cet OS interne est SQL Operating System, abrégé en SOS (ça ne s’invente pas !).

C'est pour cela que vous avez notamment un rôle de serveur intitulé "diskadmin"

SQL Server de Microsoft est l’héritier directe de Sybase SQL Server (1986), premier SGBD Relationnel client serveur qui a été réalisé sous UNIX. Son stockage est donc constitué de volume UNIX doté d’un formatage interne en 64 Ko découpé en blocs de 8 k (pages de tables ou d’index).
Les fichiers de SQL Server sont en fait l’équivalent de volumes UNIX… De ce fait, les opérations d’accroissement, comme de réductions sont complexes, lourdes, longues et pénalisent fortement les performances des IOs.

Il faut donc absolument provisionner le stockage et ne jamais réduire.

Pour "voir" les volumes associés à une base la requête suivantes peut être utilisé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT DB_NAME() AS DBNAME, physical_name, type_desc, size/128.0 AS TOTAL_VOLUME_MB,
       FILEPROPERTY(name, 'SpaceUsed') /128.0 AS USED_VOLUME_MB
FROM   sys.database_files AS mf;

A +

[benfadhelj]

C'est une base prod importante de notre activité j'ai peur que ca impacte les performances en même temps je me dis elle fera son autogrothw

[benfadhelj]

Il faut provisionner les fichiers de données pour une exploitation de 3 à 5 années, afin d'éviter toute opération de croissance en pleine production. De même pour le journal de transaction, le tailler à 30% des données. [...]

Merci pour tous ces détails.
Donc vous me conseillez d'augmenter la taille du fichier data et d'éviter l'autogrowth pendant la prod.

Y a-t-il des précautions à prendre à part que ça soit hors prod bien sûr ? Il n'y a aucun risque normalement ?

[SQLpro]

Merci pour tous ces détails.
Donc vous me conseillez d'augmenter la taille du fichier data et d'éviter l'autogrowth pendant la prod.

Y a-t-il des précautions à prendre à part que ça soit hors prod bien sûr ? Il n'y a aucun risque normalement ?

Juste ne pas saturer les disques !

A +