Discussion :

[Raphael1980]

Bonne rencontre,

Je ne suis pas sûr d’être au bon endroit mais on peut toujours essayer.

J’ai un nouveau client qui a un très gros problème avec une base de données. Celui-ci utilise SAP mais pour les petites sociétés et je me demande si ce n’est pas une base SAP justement…

Voici les informations :

Il y a un MS SQL et une base de données appelée « IXMetaSBOOEM.mdf» qui fait plus ou moins 14 MB et son équivalent en transaction LOG « IXMetaSBOOEM_log.ldf » qui fait plus de 112380MB.

Il ne faut pas être un géni pour se rendre compte qu’il y a un problème mais je ne sais pas comment résoudre ce souci. Mes connaissances en tant que DBA se limite à installer un serveur SQL, d’attacher des bases, de créer des user, etc.

Mes recherches sur google avec ce nom IXMetaSBOOEM.mdf ne m’ont rien donné du tout et pour finir, je ne sais toujours pas a quoi c’est lié.

Quelqu’un a une idée ?

Merci d’avance,
Raphaël.

[dily0403]

Bonjour,

Il te faut prévoir de sauvegarder régulièrement tes journaux de transaction.
Tu peux t'aider des plans de maintenance pour te faciliter la tâche...

Tu trouveras de nombreuses informations sur developpez.com autour des journaux de transactions SQL Server et comment les administrer...

Jetes un oeil par-ici : http://sqlpro.developpez.com/cours/sqlserver/log/

David

[elsuket]

Bonjour,

Les bases de données qu'implémente SQL Server comprennent par défaut deux fichiers :

- un fichier de données, qui porte par défaut l'extension .mdf
- un fichier du journal des transaction, qui porte par défaut l'extension .ldf

SQL Server n'est pas un SGBD "fichier", donc un fichier .mdf n'est pas une base de données .

Vous pouvez réduire le journal de transactions, car il est clair dans votre cas qu'il y a un problème.
Cela montre que votre base de données est en mode de restauration complet, et surtout que cette base de données n'est jamais sauvegardée ...
En effet dans le mode de restauration complet, lors de chaque sauvegarde de base de données, le journal des transaction est tronqué.
Donc après un certain temps de vie de la base de données, la taille de celui-ci varie très peu.

Avant de penser à réduire le journal des transactions, pensez d'abord à la façon dont cette base de données est accédée :

- seulement en lecture, ce qui semble être le cas, ou énormément de modifications ?
- quel intervalle de temps reste "acceptable" si vous perdiez des données lors d'un crash ? quelques minutes ? plusieurs mois ?

Vous trouverez la réponse à ces questions ici et ici

@++

[Raphael1980]

Merci à vous,

J'ai pu résoudre le problème de taille grâce à vos conseils.

Amicalement,
Raphaël.