Discussion :

[NULL008]

bonjour a tous

Microsoft a pris la décision de supprimer la commande

Code :

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

BACKUP LOG ***** WITH TRUNCATE_ONLY

et ce ci depuis la version SQL server 2005

Qui a une idée par Quel instruction elle a été remplacer ?

car si j’exécute sur 2012 il m'affiche ce message d'erreur

Code :

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

1
2
Msg*155, Niveau*15, État*1, Ligne*1
'TRUNCATE_ONLY' n'est pas une option BACKUP reconnue.

merci

[Bernardos]

Bonjour,
Que veux tu faire? (j'ai bien peur de connaitre la réponse)
et pourquoi veux tu le faire?
Cordialement,

[SQLpro]

Aucune et à juste titre... Déjà exprimé dans un post précédent !
http://www.developpez.net/forums/d16...a/#post8765490

A +

Formez vous à SQL Server :

[mikedavem]

Bon aller juste pour le fun

En fait tu peux simuler le même comportement en faisant

Code :

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

BACKUP LOG mydb TO DISK = N'NUL'

Par contre effectivement bien garder en tête ce que tu penses solutionner avec cela

++

[NULL008]

j'ai mis en place une solution de mirroring entre deux instances , j'ai pas en parallèle un système du sauvegarde Fonctionnelles sur les deux instances

et vu que le mirroring capte les transactions au niveau du RAM

je cherche a faire vider juste le log pour ne plus avoir une saturation disque ou j'ai pas besoin de faire un vrai sauvegarde du log

cordialement

[Bernardos]

Bonjour,
donc tu es en mode de récupération "complet" avec du database miroring(qui impose forcément d'être en mode complet).
Je ne vois pas bien l’intérêt de ne pas faire des sauvegarde du journal de transaction.
Pourquoi ne veux tu pas les faire? pour économiser de la place?
Cordialement,

[NULL008]

j'ai plus d'espace disque

[Bernardos]

j'ai plus d'espace disque

Mauvaise raison
Je ne suis même pas sur que tu ne risques pas d'avoir des soucis avec ton miroir en faisant la commande de David.

ou n'as tu plus d'espaces? sur le serveur ou sur l'entierté de ton réseau?

As tu tant de transactions que ça?
N'y a t il pas moyen d'avoir de l'espace disque ailleurs sur le réseau?
N'y a t il pas un moyen de de récupérer de l'espace (compresser les sauvegardes)?
Cordialement,

[mikedavem]

Mauvaise raison
Je ne suis même pas sur que tu ne risques pas d'avoir des soucis avec ton miroir en faisant la commande de David.

Fonctionne très bien avec du mirroring et du AlwaysOn, je tiens à préciser

J'ai pour exemple un client qui a un RTO relativement faible (5 min) et un RPO relativement élevé (une restauration à la journée lui suffit en cas de problème).
Il n'a pas forcément besoin d'une restauration dans le temps et le volume de données est relativement stable (~= 10GB) alors que le volume transactionnel plutôt élevé (beaucoup d'INSERT + DELETE).

Dans cette optique nous avons mis en place une stratégie de sauvegarde sans avoir à finalement garder l'espace disque pour des backups logs car pas nécessaire dans la stratégie de restauration.

Ceci dit BACKUP .. TO DISK = 'NUL' n'est pas vraiment équivalent à BACKUP WITH TRUNCATE_ONLY. La documentation est plutôt claire sur le sujet et pour obtenir vraiment le même comportement on doit passer en mode SIMPLE, ce qui n'est pas envisageable avec du mirroring ou AlwaysOn et groupes de disponibilités.

++

[NULL008]

Et pour le log shipping Que pensez vous?

[mikedavem]

Pour le log-shipping l'histoire est différente car le mécanisme de réplication se base sur la sauvegarde des journaux de transactions pour répliquer les données.
Par conséquent un BACKUP TO DISK = 'NUL' aurait pour effet de casser le processus de réplication des données du principal vers le(s) secondaire(s)

++

[NULL008]

et si j'ai un cas de désynchronisation entre mes deux instances de mirroring et cette commande a été lancé

que se passe t il pour les transactions qui se sont déroulé pendant la période du coupure

comment je peut avoir une nouvelle point de synchro

[cristophe0071983]

alors la tu sera dans le merde

[mikedavem]

et si j'ai un cas de désynchronisation entre mes deux instances de mirroring et cette commande a été lancé
que se passe t il pour les transactions qui se sont déroulé pendant la période du coupure

Si ton miroir est déconnecté, ton journal ne pourra pas être vidé par une sauvegarde de log tant les transactions concernées ne sont pas répliquées (avec un log_reuse_wait_desc = DATABASE_MIRRORING).

++

[NULL008]

maintenant si je fait une bêtise et je lance un kill spid pour cette transaction qui est vu comme opération ouverte
Est ce que ce processus serai t'il tuer ?
Si oui normalement j'aurai plus un point de synchro et je doit récrée ma mirroring ?
N'hésitez pas à me corriger si je me trompe

[mikedavem]

maintenant si je fait une bêtise et je lance un kill spid pour cette transaction qui est vu comme opération ouverte
Est ce que ce processus serai t'il tuer

KILL = rollback de la transaction. Donc aucun souci.

++