Discussion :

[haffey2]

Bonjour,

Je ne sais pas si j'ai posté cette problématique au bonne endroit. Dans le cas contraire, je m'en excuse.

Dans le cadre de mon travail, j'ai une application qui fonctionne via 2 serveurs identiques. Ces deux serveurs sont redondant en cas de défaillance de l'un.
Ces serveurs fonctionnent ensemble depuis 4 ans environ. Récemment, nous avons constaté que le disque dur de l'un des serveurs était complètement plein (disque de 72Go).

J'ai donc comparé bêtement la taille des dossiers des deux serveurs et je me suis rendu compte que le problème venait d'un dossier " historian " dans Program file/MS SQL ... ect :

Sur le serveur plein, ce dossier fait 50 Go
Sur le serveur " normal ", ce dossier fait 1,5 Go

Alors pourquoi cette différence alors que ces deux serveurs fonctionnent de la même façon ? Je ne sais pas si cette base de données a grandi au fils des années ou si c'est la conséquence d'un bug plus récent ... J'avoue ne jamais avoir remarqué que le disque se remplissait.

Honnêtement, je n'y connais pas grand chose en base de données, du coup je suis un peu dépassé. J'aimerais avoir des avis et surtout des conseils pour éventuellement résoudre ce problème. Est il possible de réduire la taille de cette base de données ? Si oui comment ? Quelles sont les risques ?

D'avance merci

Florian

[joujousagem2006]

voir la résultat de ces deux requêtes

Code :

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

1
2
3
4
SELECT name, recovery_model_desc
   FROM sys.databases
      WHERE name = 'model' ;
GO

ainsi que la requête

Code :

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

dbcc sqlperf(logspace)

Votre serveur est en mode de réplication y a t'il des travaux sur votre database pendant la réplication

[SQLpro]

1) quelle version / édition de SQL Server ?
Version : 2000, 2005, 2008, 2008 R2, 2012, 2014 ???
Edition : Express, Developper, Standard, Enterprise, BI, SEB...

2) quelle méthode de "réplication" ?
Snapshot ? Transactionnelle ? Fusion ?
Ne s'agit-il pas d'une haute disponibilité ? (Mirroring ? AlWaysOn ???)

3) quel est le fichier qui présente la plus grosse différence et ou est-il situé ?

A +

[haffey2]

Tout d'abord merci pour la réactivité.

joujousagem2006 :

Je suis désolé, mais comme j'ai dit dans mon premier post, je n'ai aucune connaissance particulière en base de données, donc c'est du chinois pour l'instant ta réponse

SQLpro :

1) Donc j'utilise la version 2005. L'édition, j'ai cherché mais je ne l'ai pas trouvé. Peut être que la réponse est ici :



2) Réplication ? Qu'est ce que c'est ? C'est la méthode de partage des informations entre mes deux machines ? Encore une fois, ça non plus je ne sais pas. Comment puis je savoir ?

3) Le fichier qui présente la plus grosse différence s'appel historian. En fait, il fait 50Go sur le serveur plein contre seulement 102,4Mo sur l'autre.

[SQLpro]

Lancez ces 4 requêtes et donneze-nous l'intégralité des résultats :

Code :

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

1
2
3
4
5
6
7
8
9
SELECT @@VERSION;
 
SELECT database_id, name, recovery_model_desc
FROM   sys.databases;
 
SELECT database_id, mirroring_role_desc 
FROM sys.database_mirroring;
 
DBCC OPENTRAN;

A +

[haffey2]

Je n'ai jamais lancé de requête, donc je ne suis pas sûr du résultat :



Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)



C'est les résultats que vous attendiez ?

[pcaboche]

Donc en résumé :
- sur la base "historian", vous êtes en Recovery Model = FULL
- vous avez un fichier de transaction log (.ldf) de 50 Go

Juste par hasard, ça vous arrive de faire des backups de cette base ? (de manière planifiée, bien entendu)

[haffey2]

Donc en résumé :
- sur la base "historian", vous êtes en Recovery Model = FULL
- vous avez un fichier de transaction log (.ldf) de 50 Go

Juste par hasard, ça vous arrive de faire des backups de cette base ? (de manière planifiée, bien entendu)

Recovery Model = full, qu'est ce que ça veut dire exactement et comment vous le savez ?

Non nous n'avons jamais fait de backup sur cette base.

Je me demande quelles sont les informations à l’intérieur de cette base. En fait nous avons un logiciel de supervision de réseau tramways qui reçoit un certain nombre d’événement par jour (date, heure, lieu, événement). L'historique de ces événements ne nous intéresse pas, nous n'avons besoin qu'un d'un mois d'archivage. Si cette base contient tout nos événements depuis 4 ans, les informations qu'elle contient sont en grande parti sans intérêt pour nous.

Je me pose donc une question bête, mais est ce qu'il est possible de supprimer bêtement ce fichier " historian " de 50Go et de le remplacer par le fichier " historian " de 100Mo de l'autre serveur en faisant un simple copié collé ?

[pcaboche]

Recovery Model = full, (...) comment vous le savez ?

Parce que je sais lire...

Non nous n'avons jamais fait de backup sur cette base.

En fait nous avons un logiciel de supervision de réseau tramways...

Plusieurs millions dans un réseau tramways, et personne qui s'y connait un minimum en administration de bases de données...
Le jour où vous aurez un problème, vous irez pleurer.

Je me pose donc une question bête, mais est ce qu'il est possible de supprimer bêtement ce fichier " historian " de 50Go et de le remplacer par le fichier " historian " de 100Mo de l'autre serveur en faisant un simple copié collé ?

Non, surtout pas (et en plus, SQL Server ne vous laissera pas faire sans résistance...).

[haffey2]

Effectivement je pourrai demander de l'aide dans mon entreprise, le problème c'est que j'obtiendrai une réponse dans 6 mois et que d'ici là, mes problèmes auront probablement évolués. Dans les grosses entreprises, c'est pas simple.

Du coup j'essaye de me débrouiller, le but pour moi c'est :

- De comprendre pourquoi cette BDD est énorme tandis que celle sur l'autre serveur est tout petite

- De savoir quelles sont les informations dans cette base de données

- Et le plus important : de résoudre mon problème, donc de réduire la taille de cette BDD.

[pcaboche]

- De comprendre pourquoi cette BDD est énorme tandis que celle sur l'autre serveur est tout petite

Faites des recherches sur :
- la différence entre fichiers .ldf et .mdf
- les différents Recovery Models (en particulier Full et Simple)
- le lien entre Recovery Model et Backups

- De savoir quelles sont les informations dans cette base de données

Voir :
- la différence entre fichiers .ldf et .mdf

- Et le plus important : de résoudre mon problème, donc de réduire la taille de cette BDD.

Si vous ne savez pas, vous ne touchez pas.

À ce niveau là, c'est le DBA qui a mal fait son boulot (et ça devrait lui prendre 5 minutes à corriger). C'est pas au Technicien de maintenance de mettre son nez là dedans.

[haffey2]

À ce niveau là, c'est le DBA qui a mal fait son boulot (et ça devrait lui prendre 5 minutes à corriger). C'est pas au Technicien de maintenance de mettre son nez là dedans.

Le DBA doit être à l'autre bout du monde à l'heure qu'il est. Même si j'arrive un jour à mettre la main dessus, je n'obtiendrai aucune aide de sa part. C'est donc au Technicien de maintenance de se démerder.

Je ne dis pas que c'est simple, mais je ne pense pas que ce soit impossible d'apprendre.

[pcaboche]

Je ne dis pas que c'est simple, mais je ne pense pas que ce soit impossible d'apprendre.

Si vous voulez apprendre, c'est là :

Faites des recherches sur :
- la différence entre fichiers .ldf et .mdf
- les différents Recovery Models (en particulier Full et Simple)
- le lien entre Recovery Model et Backups

Si vous qu'on vous fournisse une solution parce que votre boite fait des économies de bouts de chandelles et n'est pas foutue d'avoir un DBA pour s'occuper de ses données, ça coûte plus cher.

[SQLpro]

Je me pose donc une question bête, mais est ce qu'il est possible de supprimer bêtement ce fichier " historian " de 50Go et de le remplacer par le fichier " historian " de 100Mo de l'autre serveur en faisant un simple copié collé ?

Votre question est effectivement navrante de bêtise. C'est le meilleurs moyen de flinguer définitivement votre base.

Les bases de données transactionnelles comme SQL Server ou oracle c'est pas des fichiers que l'on substitue bêtement de l'un à l'autre. Ils contiennent des points de synchronisation spécifique à chaque base et serveur !

1) Vous devez procéder IMPÉRATIVEMENT à une sauvegarde FULL et une sauvegarde LOG de votre base à fréquence régulière. Par exemple une fois par jour (BACKUP DATABASE ... puis BACKUP LOG ....)

2) Ensuite, SI ET SEULEMENT SI, vous avez procédé au 1) alors vous pourrez réduire ce fichier de journal de transaction en appliquant une commande DBCC SHRINKFILE ....

A +

[haffey2]

Donc comment je dois comprendre ça ? Que dans mon cas, puisque je n'ai jamais fait de backup, il est trop tard pour faire quoique ce soit ?

Et que puis je faire sur mon 2em serveur pour ne pas que ça se reproduise ?

[pcaboche]

Donc comment je dois comprendre ça ?

Comprendre ? Jusqu'ici t'as pas fait le moindre effort pour essayer de comprendre d'où vient le problème, donc arrête de dire des conneries ou ça va mal se passer...

Si tu veux comprendre, tu fais des recherches.

Si tu veux pas faire l'effort, tu fais ce que dit SQLpro, sans poser de question. S'il arrive un pépin, c'est pour ta pomme.

Si tu veux faire ni l'un ni l'autre, tu te payes les services d'un professionnel qui sait ce qu'il fait.

Capisce ?

Et que puis je faire sur mon 2em serveur pour ne pas que ça se reproduise ?

Tu fais ce que dit SQLpro, sur le deuxième serveur, sans poser de question.

[janlouk]

Florian,

Fait ce que SQLpro te dit dans son message #14 pour résoudre ton problème très rapidement, ensuite tu apprendras à mettre en place un plan de maintenance.

Le plus important c'est de le résoudre tout de suite et tu peux faire confiance à Frédéric les yeux fermés pour résoudre ton problème.

[janlouk]

J'ignore si tu vas devoir t'occuper désormais des bases de données, mais regarde ici et tu apprendras ce qu'est le mirroring, la réplication... http://www.datacrossroad.be/category/tutos/

Va voir aussi sur Youtube les vidéos de Anas Belabbes (DynIT), lire le blog de SQLpro et de bien autres ici (regarde les liens des blogs sur mon site).

Et ici tu as un tuto pour faire un backup, tu vas beaucoup apprendre et c'est plus facile quand c'est en vidéo :

[aieeeuuuuu]

Bonjour,

Que dans mon cas, puisque je n'ai jamais fait de backup, il est trop tard pour faire quoique ce soit ?

Non.

1/
Si aucune sauvegarde n'a jamais été effectuée sur cette base, et si vous ne vous souciez aucunement de la pérennité de vos données, si risquer de perdre l'ensemble vos données ne vous pose aucun souci particulier (et seulement dans ce cas), alors vous pouvez directement réduire la taille de ce fichier de log :

Code :

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

DBCC SHRINKFILE (N'NomDuFichierDeLog' , 0)

Pour obtenir le nom du fichier de log :

Code :

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

1
2
3
SELECT	name
FROM		sys.database_files
WHERE	type_desc = 'LOG'

Je le répète : ATTENTION, ce n'est pas sans conséquences...

2/ Dans tous les autres cas, suivez les conseils qui vous ont été donnés plus haut.

[haffey2]

Comprendre ? Jusqu'ici t'as pas fait le moindre effort pour essayer de comprendre d'où vient le problème, donc arrête de dire des conneries ou ça va mal se passer...

Si tu veux comprendre, tu fais des recherches.

Bon je crois qu'on s'est mal compris ...
Des recherches, j'en ai fait et j'en fait encore. Mais comprend que c'est quelque chose de nouveau pour moi. Chaque manip, chaque terme est une nouveauté. Si tu ne veux pas m'aider, pas de problème, ne m'aide pas. Mais garde ton arrogance pour toi. Quant à tes menaces ... j'en rigole dans ma barbe


Janlouk, aieeeuuuuu et SQLpro : merci beaucoup pour les infos, je vais regarder à tout ça et je vais suivre vos conseils.