Discussion :

[Avatar69]

Bonjour,

je me pose pas mal de question sur le principe même d'un LDF.

Sachant que ma base est sauvegardé chaque jours, que l'intégralité du serveur est sauvegardé aussi chaque jour.

Actuellement ma base fait environ 10 Go et mon LDF a une expansion folle que je réduit chaque jour.

Peut t'on limité un LDF a 1 Go et ne pas autorisé son augmentation sans risque ?

Le LDF sert-il encore a quelque chose de nos jours ?

Merci pour vos suggestions ou piste.

Cordialement

Thierry

[SQLpro]

le LDF (terme impropre) est le journal de transactions (JT). Sans journalisation des transactions pas de transaction. Donc pas de SGBD Relationnel. Il sert de filet de sécurité lorsque :
1) le serveur tombe en panne au milieu d'une écriture
2) rejouer des transactions passées pour retrouver une base à un temps, t dans le passé.

mais il va grossir indéfiniment si :
1) vous etes en mode de journalisation full ou bulk logged
2) vous n'avez pas mis en place de sauvegarde du JT

Commencez donc par faire une suvegarde du JT

A +

[Avatar69]

Re,

désolé de ne pas avoir préciser on est en mode SIMPLE déjà.

et je me retour avec un JT de 20 a 30 Go en quelque jours.

Après je sais pas si on parle de la même sauvegarde mais oui se fichier est sauvegardé chaque jour par la sauvegarde total du serveur et via une tache sauvegarde de base dans le SQL direct

thierry

[hmira]

Le LDF sert-il encore a quelque chose de nos jours ?

Je tiens à dire que j'étais ahuri de lire cette question !

Sans vouloir vous offusquer ! Ceux qui se posent encore cette question n'ont vraiment rien compris au fonctionnement des bases de données !

SQLPro vient vous donner des explications rapides fort utiles, mais vous feriez mieux de vous former à minima sur le fonctionnement des SGBD.

A+

[darkelend]

Re,
désolé de ne pas avoir préciser on est en mode SIMPLE déjà.

En mode SIMPLE, le journal de transaction est utilisé de la même façon qu'en mode FULL. La seule différence, c'est que le journal de transaction est vidé à chaque CHECKPOINT. Le mode SIMPLE indique seulement qu'on ne peut réaliser qu'une restauration simple (cad depuis la dernière sauvegarde complète ou diff)

[mikedavem]

En mode SIMPLE, le journal de transaction est utilisé de la même façon qu'en mode FULL

Ce n'est pas tout à fait vrai en réalité . Certains opérations peuvent être journalisées au minimum en mode de récupération simple

>> http://technet.microsoft.com/en-us/l...=sql.105).aspx

++

[SQLpro]

Re,

désolé de ne pas avoir préciser on est en mode SIMPLE déjà.

J'en doute très fort ! Comment obtenez vous cette info ? Quelle est le nom de votre base (pas du serveur...)

et je me retour avec un JT de 20 a 30 Go en quelque jours.

Après je sais pas si on parle de la même sauvegarde mais oui se fichier est sauvegardé chaque jour par la sauvegarde total du serveur et via une tache sauvegarde de base dans le SQL direct

thierry

La sauvegarde des fichiers du serveur n'est pas une méthode de sauvegarde d'une base de données dans le sens ou une base ce n'est pas un fichier.

La sauvegarde d'une base n'est pas non plus une sauvegarde du journal de transaction.

POUR LE POINT 1 (mode de récup de la base), faites la requête suivante et postez l'intégralité de la réponse :

Code :

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

1
2
SELECT name, recovery_model_desc
FROM   sys.databases

Indiquez nous quel est le nom de la base en question.

POUR LE POINT 2 (sauvegarde du JT), assurez vous de lancer régulièrement (au moins une fois par jour) la commande :

Code :

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

1
2
BACKUP LOG nom_de_ma_base
TO DISK = 'C:\repertoire de sauvegarde\nom_de_ma_base_20140924.TRN'

A +

[darkelend]

Ce n'est pas tout à fait vrai en réalité . Certains opérations peuvent être journalisées au minimum en mode de récupération simple

>> http://technet.microsoft.com/en-us/l...=sql.105).aspx

++

Effectivement, en mode simple comme en Bulk-logged, certaines opérations sont moins couteuses (en terme d'écriture dans le JT). Je suis allé trop vite pour répondre

[Avatar69]

Re,

l’ensemble de mes bases sont bien mode récupération SIMPLE

master SIMPLE
tempdb SIMPLE
model SIMPLE
msdd SIMPLE
BIJOU SIMPLE
C_MODEL SIMPLE
TRAVAIL SIMPLE

Je n'ai pas mis toutes les bases.

concernant les sauvegardes cela se fait via un plan de maintenance dans sqlserver.

@HMIRA
quand je dis 'de nos jour' ....

je sais que le LDF sert comme la si bien dit SQL Pro à
1) le serveur tombe en panne au milieu d'une écriture
2) rejouer des transactions passées pour retrouver une base à un temps, t dans le passé.

Ce que je voulais dire c'est que dans mon cas je gère une cinquantaine de serveur avec des bases SQL dont certaine on plusieurs centaine de millions d’enregistrements et je n'ai JAMAIS eu de crash serveur ni de crash de base je n'ai JAMAIS eu besoin de remonter une base totalement ou a un instant T et ce depuis plus de 9 ans (je croise les doigts que cela continue)
Les seuls bases que je restore sont des copies de mes bases de travail pour faire des test avant mis en exploitation

Thierry

[hmira]

Re,
@HMIRA
quand je dis 'de nos jour' ....

je sais que le LDF sert comme la si bien dit SQL Pro à
1) le serveur tombe en panne au milieu d'une écriture
2) rejouer des transactions passées pour retrouver une base à un temps, t dans le passé.

Ce que je voulais dire c'est que dans mon cas je gère une cinquantaine de serveur avec des bases SQL dont certaine on plusieurs centaine de millions d’enregistrements et je n'ai JAMAIS eu de crash serveur ni de crash de base je n'ai JAMAIS eu besoin de remonter une base totalement ou a un instant T et ce depuis plus de 9 ans (je croise les doigts que cela continue)
Les seuls bases que je restore sont des copies de mes bases de travail pour faire des test avant mis en exploitation

Même avec ces arguments, vous ne pouvez vous dispenser du journal des transactions. En effet, le caractère ACID des transactions ne peut être assuré sans l'existence du journal des transaction, et tout particulièrement la Durabilité .
La validation effective durables des transactions sont synchrones, signalent la réussite de la validation (COMMIT) et restituent le contrôle au client uniquement lorsque les enregistrements de journal pour la transaction ont été écrits sur le disque.
Les validations de transactions durables différées sont asynchrones et signalent la réussite de la validation (COMMIT) avant que les enregistrements du journal pour la transaction ne soient écrits sur le disque.
Le renforcement des entrées du journal des transactions sur le disque est requis pour qu'une transaction soit durable. Les transactions durables différées deviennent durables lorsque les entrées du journal des transactions sont vidées sur le disque.

A+

[SQLpro]

concernant les sauvegardes cela se fait via un plan de maintenance dans sqlserver.

Vous ne répondez toujours pas aux questions.... Mais passons, puisque vos bases sont en simple, la situation devrait être de pouvoir réduire les journaux.

Si votre journal n'arrive pas à se réduire, il est possible qu'une transaction soit active depuis des lustres.

lancez la commande DBCC OPENTRAN dans le contexte de la base fautive et voyez si vous avez une transaction qui dure depuis trop longtemps. SI tel est le cas, annulez_là avec un KILL de la session fautive.

A +

[Avatar69]

Merci pour toutes vos réponses et le temps que vous y avez passé

Bonne journée

Thierry