Discussion :

[janlouk]

Bonjour à tous,

Nos backup se font via Redgate, pour la compression, sur SQL 2005.

J'ai activé IFI sur l'instance il y a presque 1 an. Avant hier, j'ai crée une DB qui est en SIMPLE (100 GB le .mdf et 1 GB le .ldf).

Elle n'est pas utilisée, elle est donc vide. Hier je remarque qu'elle ne fait plus que 4 mb le .mdf et 32 mb le .ldf. Je me suis dit, je suis fou, et je la repasse à 100 GB et rebelotte ce matin.

La DB model fait 4 Mb .mdf et 6 Mb .ldf

Malheureusement je n'ai pas une vue sur Redgate car nous ne gérons pas les backups (merci l'externalisation des services...). S'il y avait eu un shrink sur les db de l'instance, je devrais le remarquer que sur toutes mes DB qu'il y a 0% d'espace libre mais ce n'est pas le cas.

Ou alors, ces espaces sont remplis de 0 avant que j'ai activé l'IFI et pas celui de ma DB de 100 GB qui est vide car là j'avais activé l'IFI entre temps.

Je me fais bien comprendre ? Je ne sais pas du tout par où chercher. Et j'aimerais éviter d'ouvrir un ticket, qu'il aille en Pologne, qu'on me le remballe car on ne comprend pas ma question, que je réponde et hop on est parti pour 3 semaines avec un ticket clôturé sans aucune solution :-)

Merci pour vos idées.

Jean-Luc

[elsuket]

Salut Jean-Luc,

Si on est certains que Le logiciel de RedGate n'exécute pas de SHRINK, est-ce que la base n'aurait pas l'option AUTO_SHRINK à ON ?

Code :

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

1
2
3
4
SELECT	name
	, is_auto_shrink_on
FROM	sys.databases
WHERE	name = 'maDB'

Sinon il te faudra prendre une trace côté serveur pour voir ce qui provoque ce rétrécissement.

@++

[mikedavem]

Hello Jean-Luc,

Tu peux essayer de te servir de la trace par défaut SQL Server pour voir si quelqu'un exécute un SHRINK à la main ou si cela vient d'une routine auto comme l'explique Elsuket

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
declare @path nvarchar(4000);
 
select @path = [path] 
from sys.traces where id = 1
 
SELECT 
    TextData,
    HostName,
    ApplicationName,
	DatabaseName,
    LoginName, 
    StartTime,
	EventClass  
FROM fn_trace_gettable(@path, DEFAULT) 
WHERE (TextData LIKE '%SHRINKFILE%' -- manual shrink
OR EventClass IN (94, 95)) -- auto shrink log / data
	AND EventClass <> 175

PS : Une autre solution plus sauvage ... ah oui vous voulez jouer au shrink sauvage .. pas de souci je crée une table et je la remplis de 100GB de données pour bien réserver mon espace ... ok je sors


++

[janlouk]

Ok merci. Non "malheureusement" elle ne l'est pas en auto_shrink.

Bon, je créerai une trace et on verra. J'ai pas le choix...

Merci pour vos réponses.

[mikedavem]

N'oublie pas la trace par défaut qui est capable de te remonter ce genre d'information sans que tu aies à créer une trace additionnelle.

Bon courage

++

[janlouk]

N'oublie pas la trace par défaut qui est capable de te remonter ce genre d'information sans que tu aies à créer une trace additionnelle.

Bon courage

++

Pas sur de comprendre. La trace par defaut, tu veux dire, je crée une trace et je choisi juste comme filtre l'ID de ma DB et c'est tout. Je laisse les options par defauts ?

[mikedavem]

En fait depuis 2005, tu as déjà une trace par défaut qui tourne sur tous les serveurs SQL permettant d'auditer un certain nombre d'événements sans avoir à créer ses propres traces. (BOL). Je l'utilise beaucoup dans mes audits pour savoir rapidement si des auto shrink, auto grow ont été déclenché sur les bases de données par exemple.

Du coup dans ton cas je pense que tu peux déjà commencer par utiliser la trace par défaut avec le script que je t'ai donné pour savoir rapidement si quelqu'un a joué avec des shrinks manuels.
La trace par défaut possède l'id = 1 d'où le bout de code que je t'ai donné plus haut

Code :

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

1
2
3
4
5
6
declare @path nvarchar(4000);
 
select @path = [path] 
from sys.traces where id = 1
 
....

++