Version imprimable
Bonjour,
Nous avons un problème d'insertion dans notre base de données SQL Server 2000. Sur une table, et seulement une, il était impossible de faire une insertion ce matin. J'ai supprimé quelques lignes dans cette même table et après les insertions ont de nouveaux fonctionnés.
Dans cette table nous stockons beaucoup d'informations. En gros elle représente 80% de la taille de notre base.
Quelle pourrait être la cause de ce problème ??
Cette table est sur un groupe de fichier. Est ce qu'il reste de l'espace de disponible dans ce groupe de fichier?
Comment est ce que je peux vérifier si la table se situe au niveau de ce groupe dans SQL Server ?
En fait la question, c'est plutot, comment savoir s'il reste de l'espace disponible au niveau de ce groupe de fichier ?
Bonjour,
Je viens de publier ceci ;)
Cela signifie surtout que vos fichiers n'ont pas été configurés pour croître automatiquement et qu'ils ont été mal dimensionnés à la création de la base de données.
Pour changer ce comportement :
Où :Code:
2
3
4
5
6
7
- nombreDeMB représente la taille future de votre fichier de données
- nombreDeMBPourCroissance représente la taille de laquelle sera agrandie votre fichier si la base de données a besoin de plus d'espace pour stocker les données.
Notez qu'une croissance augmente vos chances de fragmentation de votre fichier de données, entraînant une perte de performances.
@++ ;)
J'ai modifié la taille du groupe de fichier.
Cela semble fonctionner !
Maintenant j'ai deux questions:
- La première, est ce que le journal de transaction à un impact sur la taille du groupe de fichier ?
- La deuxième, comment optimiser au mieux la taille de ce groupe de fichier ??
Pour le moment, j'ai définit la taille à 50Gb avec une croissance de 50% !
Si je comprends bien ... La taille de ma base correspond à la taille du groupe de fichier !
Ce que je ne comprends pas, c'est cette fameuse stratégie d'optimisation de croissance automatique. Pourquoi, la base n'a pas grandit automatiquement de 50% si l'espace disponible n'était plus suffisant ?
Bonjour,Citation:
Envoyé par Pfeffer
Il peut y avoir plusieures raisons, à savoir si l'espace disque était disponible pour une telle croissance et aussi si la taille maximum du fichier n'était pas dépassée. En effet on peut limiter le grossissement du fichier à une certaine limite.
Quand à votre stratégie de grossissment, préférez utiliser une taille en MB plutot qu'un pourcentage. De ce fait vous pourrez mieux controler la croissance de votre fichier.
Dans votre cas, une croissance de 50% vous fera grandir votre fichier de 25GB la prochanie fois. Ce qui portera votre fichier à 75GB. L'étape suivante vous fera grossir votre fichier de 37.5 GB.
Je pense qu'une croissance de 5GB à la fois devrait être suffisante. Après, je ne connais pas la volumétrie des données insérées dans votre base de donnée de manière quotidienne, ce qui doit être pris en considération lors de la définition de la croissance automatique de votre fichier.
5GB de croissance me paraît excessif. Cela risque d'engendrer des problèmes de timeout sur certaines transactions. Personnellement je ne dépasse pas les 1GB en production ...
Ca dépend de la version du SGBD, à partir de 2005, il réserve l'espace sans mettre des 0 partout, ce qui a un effet quasi instantané.
[EDIT]
Je viens de voir que l'on était sur 2000 dans ce topic, j'adhère à la remarque de Mikedavem.
Autant pour moi :)
Bonjour,
De la documentation là-dessus stp :)Citation:
Ca dépend de la version du SGBD, à partir de 2005, il réserve l'espace sans mettre des 0 partout, ce qui a un effet quasi instantané.
@++ ;)
No souci
Un petit lien ;)
Quoi ?! Tu ne me crois pas sur parole ?! 8O
Tu as bien raison ;)
Je ne savais plus trop la terminologie utilisée pour cette amélioration mais j'ai finalement retrouvé l'info, c'est "instant file initialization":
http://msdn.microsoft.com/en-us/libr...5(SQL.90).aspx
Bonne journée
Si si je te crois, mais je souhaitais juste savoir exactement comment ça fonctionne ... j'aime bien savoir :)
@++ ;)