OVH Cloud OVH Cloud

Modèle ?

2 réponses
Avatar
Boris
Dans la certif, il est sugg=E9r=E9 de ne pas utiliser le=20
mod=E8le de r=E9cup=E9ration simple, car on ne pourrait=20
r=E9cup=E9rer qu'au point de la derni=E8re sauvegarde. Comprends=20
pas pourquoi, dans le mod=E8le complet =E9galement. E t en cas=20
de crash, de toutes fa=E7on il est probable que l'on ai plus=20
les journaux de transactions si les disques sont morts, on=20
a que notre .bak, non vraiment je comprends pas l'argument.
Je susspose de plus que dans la config id=E9ale je base=20
(mdf) ne doit pas etre sur le meme disque que le journal!

2 réponses

Avatar
Nicolas LETULLIER
Bonjour,

Il faut d'abord identifier les différents scénarios "catastrophe", qui ne se
limitent pas forcément à la perte pure et simple de tous les disques dur :
- Plantage machine/système simple.
- Plantage avec perte du/des disques contenant le système
- Plantage (ou pas) avec perte du/des disques contenant les données
- Plantage (ou pas) avec perte du/des disques contenant les journaux
- Erreur humaine ou logicielle (suppression des données)
- Vol/Perte du serveur
- etc etc etc...

A partir de là, le modèle de sauvegarde/récupération le plus sûr est
évidemment le modèle complet plutôt que le simple. D'ailleurs, pour revenir
sur la perte du journal des tranasactions, il faudra veiller à le mettre sur
un sous-sytème disque fiable et performant en écriture séquentielle
(généralement du RAID). Perdre tous les disques RAID 1 en même temps, c'est
pas de bol, mais tu en auras évidemment fait des backups ;-)

Sujet bien vaste qui nécessite de bien se pencher dessus...

Nicolas.


"Boris" a écrit dans le message de
news: 3ffd01c4ac7b$59614bc0$
Dans la certif, il est suggéré de ne pas utiliser le
modèle de récupération simple, car on ne pourrait
récupérer qu'au point de la dernière sauvegarde. Comprends
pas pourquoi, dans le modèle complet également. E t en cas
de crash, de toutes façon il est probable que l'on ai plus
les journaux de transactions si les disques sont morts, on
a que notre .bak, non vraiment je comprends pas l'argument.
Je susspose de plus que dans la config idéale je base
(mdf) ne doit pas etre sur le meme disque que le journal!
Avatar
Sylvain Lafontaine
Oui, vous avez raison, non seulement dans la configuration idéale on doit
mettre le journal sur un disque différent de la base pour augmenter les
chances de succès en cas pépin; mais aussi du point de vue performance car
cela va augmenter considérablement la vitesse de travail du SQL-Server.

Cependant, pour les machines n'ayant qu'un seul disque dur de libre, pour
les personnes ne sachant pas comment utiliser le journal pour faire une
récupération ou tout simplement parce que la quantité et la nature du
travail que vous faites dessus ne justifient pas une sécurité ou une
performance accrues; l'utilisation du modèle de récupération simple peut
être amplement justifiée.

S. L.

"Boris" wrote in message
news:3ffd01c4ac7b$59614bc0$
Dans la certif, il est suggéré de ne pas utiliser le
modèle de récupération simple, car on ne pourrait
récupérer qu'au point de la dernière sauvegarde. Comprends
pas pourquoi, dans le modèle complet également. E t en cas
de crash, de toutes façon il est probable que l'on ai plus
les journaux de transactions si les disques sont morts, on
a que notre .bak, non vraiment je comprends pas l'argument.
Je susspose de plus que dans la config idéale je base
(mdf) ne doit pas etre sur le meme disque que le journal!