Discussion :

[StringBuilder]

Bonjour,

J'ai un serveur sur lequel les bases de données ont été mal paramétrées à l'installation : tout est en mode goret dans le dossier d'installation de SQL Server.

J'ai donc monté un nouveau disque, créé dans le même filegroup (PRIMARY) un nouveau fichier un peu plus gros que le MDF actuel, et j'ai lancé les commandes suivantes :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
 
user PROD;
go
DBCC SHRINKFILE ('CRM', EMPTYFILE);
go
 
use master;
go
ALTER DATABASE PROD REMOVE FILE CRM;
go

Pour la première base, c'est passé comme une lettre à la poste : ça a patiné dans la semoule quelques dizaines de minutes, la base a bien été déplacée.

Seulement, pour la seconde base, voici l'erreur que j'obtiens lors du SHRINKFILE :

Msg*2555, Niveau*16, État*1, Ligne*1
Impossible de déplacer tout le contenu du fichier "CRM" vers d'autres emplacements pour terminer l'opération emptyfile.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.

Il reste 56 pages occupées. Lorsque je relance la commande, il reste toujours le même nombre de pages allouées.

D'où cela peut-il venir ?
J'aime bien le message d'erreur d'une commande administrateur qui demande à connecter l'administrateur...
Mon niveau de schizophrénie ne me permet pas de trouver une réponse à un problème dont je ne sais rien juste en me demandant à moi-même…

Faute de mieux j'ai réduit la taille du fichier à 2 Go (au lieu de 73 Go) et dégagé la croissance automatique…
Mais bon, si ce fichier inutile pouvait aller voir ailleurs si j'y suis, ça m'arrangerait un peu

[SQLpro]

décrit le stockage de ta base.

A +

[StringBuilder]

Rien de spécial.
Au départ, l'unique MDF était dans c:\program files\… (filegroup primary)

Ensuite, j'ai rajouté un filegroup "sans lob" et modifié une table pour que ses données soient dans "sans lob" et textimage_on primary.
sans lob est constitué d'un seul fichier.

J'ai donc créé un second fichier pour primary et pour sans lob, sur un autre disque.
Je les ai dimensionnés un peu plus grand que les fichiers actuels.

Puis j'ai fait un shrink EMPTYFILE sur sans_lob sans aucun problème

Mais pour primary ça plante à la fin avec le message que j'ai indiqué.

Est-ce que ça peut être lié à des transactions en cours qui ne seraient pas terminés ?
Ou au fait que primary soit utilisé par la clause textimage_on d'une table ?

[hmira]

Bonjour,

Essayez de procéder comme suit :

1 - Calculez la taille réellement utilisée par vos fichiers de données (SpaceUsed)
2 - Le cas échéant augmentez la taille du fichier de données (celui que vous voulez garder) pour faire en sorte qu'il puisse stocker l'ensemble de vos données (c.à.d. l'espace réellement utilisé, celui calculé à l'étape 1 ci-dessus)
3 - Désactivez la croissance automatique du fichier que vous voulez supprimer FILEGROWTH = 0

Code SQL :

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

1
2
ALTER DATABASE [PROD] MODIFY FILE ( NAME = N'CRM', FILEGROWTH = 0)
GO

4 - Réessayez à nouveau la commande SHRINKFILE, en deux temps :
. une première fois avec TRUNCATEONLY.
. et une deuxième fois avec EMPTYFILE.
5 - Si l'étape 4 ci-dessus est OK, alors lancez la commande REMOVE FILE

Code SQL :

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

1
2
ALTER DATABASE PROD REMOVE FILE CRM;
GO

A+

[StringBuilder]

Le fichier à supprimer faisait 73 Go
J'ai donc créé un nouveau fichier de 80 Go histoire d'avoir un peu de place d'avance.

Donc c'est pas un souci d'espace dans le fichier destination.

Si je passe par SSMS, il me propose de réduire le fichier initial à 2 Mo.
J'ai déjà bloqué l'agrandissement automatique dessus.
Je l'ai skrinké à 2 Go, 2 Mo me semblant ridicule.

Je vais essayer de faire un TRUNCATEONLY, c'est effectivement quelque chose que je n'ai pas testé.
Merci, je vous dis ce qu'il en est demain.

[iberserk]

Bonjour
Pourquoi ne pas simplement détacher puis rattacher tes fichiers de bases de données?

[hmira]

Bonjour iberserk,

Détacher puis attacher la base de données (et non les fichiers) n'apportera aucune solution au problème soulevé !
Tu confonds peut-être avec l'option FOR ATTACH_REBUILD_LOG (?) qui permet de créer et reconstruire, à la volée, le journal des transactions...

Notes que dans le cas présent, il s'agit de fichiers de données et aucune perte de données n'est tolérée. Et donc, il faudra, au préalable, déplacer les données utilisées d'un fichier de données vers un autre avant de pouvoir supprimer le dit fichier de données.

PS : A moins que tu voulais exprimer autre chose, une autre technique, que je n’ai pas bien saisie (?).

A+

[iberserk]

Bonjour Hmira.

Si tu relis attentivement le post initial le but était simplement (mais je peux avoir mal compris) de déplacer les bases dont les fichiers avait été placés par défaut sur le disque système.

Pour ce faire,StringBuilder a décidé de créer un nouveau filegroup sur un disque autre que le C, déplacé ses tables/indexes dessus et tente désormais de supprimer le filegroup initial du disque système.

Je réitère donc: un simple attach/detach aurait fait l'affaire.

Cordialement

[hmira]

Bonjour iberserk,

Maintenant je comprends mieux ton idée. Effectivement si le but initial (et on n’en est pas certain) était simplement de déplacer les fichiers d’un disque vers un autres, un simple Detach/Attach aurait très bien fait l’affaire.

Personnellement je ne suis pas très au clair sur les motivations et objectifs exacts de StringBuilder. En outre, il y a aussi, semble-il création d’un nouveau groupe de fichiers "sans lob" et création dans ce groupe d’un nouveau fichier etc.

Ce que j’ai compris c’est que StringBuilder s’est trouvé au final devant un problème, c.à.d. avec un fichier en trop, dans le groupe Primary. fichier qu’il a du mal à supprimer ! et dans cette situation un Detach/Attach ne permet pas de résoudre le problème, et c’est pour cela que j’ai réagis à ton message

Cordialement,

[StringBuilder]

Merci iberserk pour ton astuce.
Elle résout en effet pour moitié mon problème, à savoir déplacer le fichier en trop du disque système vers un disque plus approprié.

Cependant, comme le soulève hmira, il reste le souci du fichier "en trop". Je n'ai pas encore pris le temps de recréer la table sur un autre fichier pour pouvoir enfin libérer mon fichier en trop : c'est une base de donnée exploité un peu tout le temps, et j'attends donc une maintenance planifiée du serveur pour profiter de l'inactivité de la base pour le faire.