Discussion :

[Bernardos]

Bonjour,
[D'abord je met 2017 mais je ne suis pas sur que ce soit la version concernée]
Je reviens vers vous (après une longue absence) pour une question plutôt intrigante.
Je discutais avec une personne des modes de récupération et sauvegarde du journal de transaction.
et là ...surprise . il m'affirme que après avoir sauvegarder le journal des transactions, il faut faire faire un truncate parce que sinon on ne sait pas restaurer...
je dois avouer que je ne suis même pas sur de savoir de quoi il parlait... vu que le with_truncate only n'existe plus (sauf erreur de ma part)
Quelqu'un pourrait m'éclairer sur le sujet... que ce soit dans un sens ou dans l'autre.
Merci d'avance,

[hmira]

Bonjour,

Votre collègue vous a raconté n'importe quoi !

La commande BACKUP LOG WITH TRUNCATE_ONLY n'est plus supportée ! C'était une commande hyper dangereuse !!! Elle permettait de vider le contenu du journal des transactions sans le sauvegarder réellement !!! Certaines personnes, y compris certains DBA (ou pseudo DBA) ne comprenant absolument rien au fonctionnement de SQL Server, abusaient de cette fonctionnalité. Ils tronquaient le journal sans sauvegarde, puis effectuaient un Shrink file du journal des transactions, ce qui, en cas de problème, rendait impossible toute restauration à un point donnée dans le temps !
Maintenant, on peut toujours faire les mêmes bêtises, mais pour cela, Microsoft oblige désormais les ignares à ce qu'ils passent du mode complet au mode simple pour tronquer le journal sans sauvegarde et pouvoir ensuite effectuer un Shrink file !!!

A+

[Boubou2020]

Bonjour,

Maintenant, on peut toujours faire les mêmes bêtises, mais pour cela, Microsoft oblige désormais les ignares à ce qu'ils passent du mode complet au mode simple pour tronquer le journal sans sauvegarde et pouvoir ensuite effectuer un Shrink file !!!

A+

Où faire

Code :

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

BACKUP LOG  xxsxxx  TO DISK = N'nul'

[hmira]

Où faire

Code :

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

BACKUP LOG  xxsxxx  TO DISK = N'nul'

C'est exact !

Ceci dit, j'espère que votre script ne sera pas vu, ne sera lu, ne tombera pas dans les mains des personnes qui ne mesurent pas l'impact réel de cette commande dangereuse.

De mon point de vue, Microsoft devrait interdire les commandes avec DISK='NUL:' pour la sauvegarde des journaux de transactions, sinon on retombe presque dans les mêmes travers que BACKUP LOG WITH TRUNCATE_ONLY, c.à.d. une impossibilité totale de restaurer la base à un point donné dans le temps !

A+

[Boubou2020]

C'est exact !

Ceci dit, j'espère que votre script ne sera pas vu, ne sera lu, ne tombera pas dans les mains des personnes qui ne mesurent pas l'impact réel de cette commande dangereuse.

De mon point de vue, Microsoft devrait interdire les commandes avec DISK='NUL:' pour la sauvegarde des journaux de transactions, sinon on retombe presque dans les mêmes travers que BACKUP LOG WITH TRUNCATE_ONLY, c.à.d. une impossibilité totale de restaurer la base à un point donné dans le temps !

A+

pour avoir shrinker un log saturé (besoin pour récupérer d'espace disque)

la commande

Code :

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

BACKUP log xxxx  TO DISK = 'NUL'

est équivalent a l'instruction

Code :

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

alter database ****  set recovery simple

[SQLpro]

Pour information, il y a la très célèbre commande de sauvegarde vers COM1, COM2, etc...

Code :

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

BACKUP LOG Ma_Base TO DISK = 'COM1'

Alors que :

Code :

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

BACKUP LOG Ma_Base TO DISK = 'COMi'

Fonctionne parfaitement !

A +

[SQLpro]

...il m'affirme que après avoir sauvegarder le journal des transactions, il faut faire faire un truncate parce que sinon on ne sait pas restaurer...

Rien à voir....
Si je dois comprendre il fait une sauvegarde transactionnelle :
BACKUP LOG ...
Suivi d'une troncation du journal :
DBCC SHRINKFILE ....

Les commandes étant distincte et séparées elles n'ont rien à voir l'une avec l'autre et cette affirmation n'a aucun sens....

A +