Les conséquences sur l'Arrêt d'un serveur

Lorsque SQL Server redémarre il essaie de recouvrir les donnés "commités"
dans le cache, par contre les transactions non commitées seront perdus (donc
il y'a perte de données), de plus la période de "recovery" peut prendre
beaucoup de temps, ce qui rend les BD non disponibles pour une longue
période.

De plus vos collègues doivent suivre les recommandations du constructeurs ;)
et les "bests practices" utilisés par les milliers de DBA dans le monde on
faisant un simple Backup, puis de sauvegarder le fichier backup au lieu des
fichiers *.mdf et *.ldf.

De plus le Backup permet de vider le journal des transactions, permet de
restaurer la BD si un problème survient "Point in time recovery" ...
Bref il y'a des centaines de raisons de ne pas arrêter le serveur et
d;utiliser un simple Backup/Restore.

Le lien suivant montre comment faire un backup sur un serveur MSDE
http://support.microsoft.com/kb/q241397/

"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23ql3B4$xFHA.736@tk2msftngp13.phx.gbl...

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont plus
bloqués et peuvent être déplacées, modifiées, supprimées, etc. Cela peut
mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier les
fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus
simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE

effectivement, ce que dit mohammed est plus que vrai !!!

la copie de fichier est une hérésie... lors du rattachement le pire est que la
période de recouvrement peut durer longtemps, alors que dans le cadre d'une
restoration suite à BACKUP dès que le RESTORE est fait, la base est dispo.

La sauvegarde par copie des fichiers constituant la base n'a pas été prévue par
MS et peut constituer une source de problème. Vous ne verrez nulle part dans la
documentation sur SQL Server qu'il faut procéder de la sorte.
De même, utiliser la marche arrière sur une voiture permet de conduire de Paris
à Lyon... Le constructeur de votre voiture vous le conseille t-il ???

De plus l'arrêt d'un serveur peut entraîner des problèmes. Un exemple parmi
d'autres : votre serveur peut ne plus redémarré si l'utilisateur du compte du
service SQL Server a été supprimé. En pratique on essaye de ne jamais arrêter un
serveur de données !

Il n'y a que les imbéciles qui ne changent pas d'avis !

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Nicolas MALESIC a écrit:

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont plus
bloqués et peuvent être déplacées, modifiées, supprimées, etc. Cela peut
mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier les
fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE

Merci pour vos réponses

J'en avais la conviction sans en avoir les arguments.

Je comprend le cheminement de leur reflexion qui est de dire que cela
fonctionne (sans s'inquiéter des conséquence possible, ni les chercher
d'ailleurs),
mais j'attendais un argument fort pour leur prouver que c'est Dangereux. Car
ce n'est pas le tout de dire que ce sera lent (pour une petite utilisation
ça passe), ou que ça ne se fait pas.
Je voudrais leur prouver par a + b.

Je pense que le meilleur argument est que le fichier log va grossir
indéfiniment que la base sera inutilisable.

Merci encore.


"Fred BROUARD" <brouardf@club-internet.fr> a écrit dans le message de news:
Ow63GHDyFHA.736@tk2msftngp13.phx.gbl...

effectivement, ce que dit mohammed est plus que vrai !!!

la copie de fichier est une hérésie... lors du rattachement le pire est
que la période de recouvrement peut durer longtemps, alors que dans le
cadre d'une restoration suite à BACKUP dès que le RESTORE est fait, la
base est dispo.

La sauvegarde par copie des fichiers constituant la base n'a pas été
prévue par MS et peut constituer une source de problème. Vous ne verrez
nulle part dans la documentation sur SQL Server qu'il faut procéder de la
sorte.
De même, utiliser la marche arrière sur une voiture permet de conduire de
Paris à Lyon... Le constructeur de votre voiture vous le conseille t-il
???

De plus l'arrêt d'un serveur peut entraîner des problèmes. Un exemple
parmi d'autres : votre serveur peut ne plus redémarré si l'utilisateur du
compte du service SQL Server a été supprimé. En pratique on essaye de ne
jamais arrêter un serveur de données !

Il n'y a que les imbéciles qui ne changent pas d'avis !

A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Nicolas MALESIC a écrit:

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont plus
bloqués et peuvent être déplacées, modifiées, supprimées, etc. Cela peut
mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier les
fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus
simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE

L'argument majeur est que l'arret d'un serveur vide les caches SQL Server
Les performances seront ralenties au prochain redemarrage pendant un bon
moment.
Un autre argument majeur qui pourrait faire changer definitivement a tes
collegues est que Microsoft ne supporte que les bases de donnees qui ont ete
proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et non par
l'arret du serveur)

Tout le reste peut preter a discussion ....

--
Bien cordialement
Med Bouchenafa



"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23ql3B4$xFHA.736@tk2msftngp13.phx.gbl...

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont plus
bloqués et peuvent être déplacées, modifiées, supprimées, etc. Cela peut
mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier les
fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus
simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE

Salut Med

Quand tu dis que "Microsoft ne supporte que les bases de donnees qui ont ete
proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et non par
l'arret du serveur)", tu veux dire que Microsoft ne l'a pas prévue ou que
cela ne fonctionne pas.
Comment expliques-tu alors que cela fonctionne tout de même de remplacer des
fichiers MDF et LDF par une sauvegarde de ces même fichiers non détachés ?
C'est justement leur méthode et c'est bien parce que cela est possible
qu'ils le font.
De plus je lis assez souvent dans les posts que untel veut récupérer ses
bases alors que le serveur est planté, et donc que ses bases n'ont pas été
proprement détachés.

Attention, je ne suis pas entrain de les défendre mais plutôt à la recherche
de preuve.
Pour information, l'utilisation des bases de données chez nos clients peut
vous sembler être détournée puisque dans la plupart des cas, le poste de
travail est aussi celui qui fait office de serveur, mais quand il n'y a
qu'un seul poste il n'y a pas d'autre choix. Surtout, il n'y a pas de vrai
administrateur et donc les dérives peuvent vite arriver, comme le fait
d'arrêter le serveur tous les soirs ou pour effectuer les sauvegardes.
Je sais bien que c'est comme s'ils conduisaient en marche arrière jusqu'à
Paris mais ils ne connaissent que cela. A moi de leur fair découvrir les
autres vitesses.

Ton premier argument est bon et pour l'instant je ne retiendrai que
celui-là.

Je résume donc ici les arguments non discutable des problèmes de l'arrêt
d'un serveur :
- les transactions non commitées sont perdus
- le Backup permet de vider le journal des transactions qui sinon grossirait
indéfiniment
- le serveur peut ne plus redémarrer si l'utilisateur du compte du service
SQL Server a été supprimé
- les fichiers deviennent accessibles par l'explorateur à l'utilisateur non
averti et peuvent être renommés, déplacés, supprimés et conduire à la perte
potentielle des données
- le backup permet de restaurer la BD si un problème survient "Point in time
recovery"
- la période de "recovery" peut prendre beaucoup de temps, ce qui rend les
BD non disponibles pour une longue période
- l'arret d'un serveur vide les caches SQL Server, les performances seront
ralenties au prochain redémarrage pendant un bon moment


Cordialement
Nicolas

"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de news:
%23%23tCQfDyFHA.908@tk2msftngp13.phx.gbl...

L'argument majeur est que l'arret d'un serveur vide les caches SQL Server
Les performances seront ralenties au prochain redemarrage pendant un bon
moment.
Un autre argument majeur qui pourrait faire changer definitivement a tes
collegues est que Microsoft ne supporte que les bases de donnees qui ont
ete proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et
non par l'arret du serveur)

Tout le reste peut preter a discussion ....

--
Bien cordialement
Med Bouchenafa



"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23ql3B4$xFHA.736@tk2msftngp13.phx.gbl...

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont plus
bloqués et peuvent être déplacées, modifiées, supprimées, etc. Cela peut
mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier les
fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus
simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE

Bonjour,

Non supporté signifie "seulement" que si un problème apparait sur un serveur
SQL et que l'on a besoin de faire appel au supprot Microsoft, ceux ci auront
le droit de refuser de solutionner le problème (c'est non supporté) car
c'est une utilisation détournée de la fonction qui n'a pas été prévu et non
validé par le support (un peu comme l'utilisation d'huile végétales dans les
moteurs diésels :-)).

L'avantage d'un moteur de base de données relationnels comme SQL Server est
justement de pouvoir faire des sauvegrades à chaud de la base. Le fichier de
backup ainsi généré est beaucoup plus faible que la somme des fichiers MDF
et LDF. De plus, le backup au niveau d'un plan de maintenance SQL est
l'occasion d'effectuer d'autres opérations (vidage du journal des
transactions pour les transactions commitées, vérification de l'intégrité du
backup, ...).

Après chacun fait ce qu'il veut mais pour moi les risques sont trop grand
d'interrompre le moteur juste pour faire de la copie de données
(interruption de service, risque de non redémarrage, pertes de transactions,
...)

----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France

"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23DKoxhLyFHA.3180@TK2MSFTNGP14.phx.gbl...

Salut Med

Quand tu dis que "Microsoft ne supporte que les bases de donnees qui ont
ete proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et
non par l'arret du serveur)", tu veux dire que Microsoft ne l'a pas prévue
ou que cela ne fonctionne pas.
Comment expliques-tu alors que cela fonctionne tout de même de remplacer
des fichiers MDF et LDF par une sauvegarde de ces même fichiers non
détachés ?
C'est justement leur méthode et c'est bien parce que cela est possible
qu'ils le font.
De plus je lis assez souvent dans les posts que untel veut récupérer ses
bases alors que le serveur est planté, et donc que ses bases n'ont pas été
proprement détachés.

Attention, je ne suis pas entrain de les défendre mais plutôt à la
recherche de preuve.
Pour information, l'utilisation des bases de données chez nos clients peut
vous sembler être détournée puisque dans la plupart des cas, le poste de
travail est aussi celui qui fait office de serveur, mais quand il n'y a
qu'un seul poste il n'y a pas d'autre choix. Surtout, il n'y a pas de vrai
administrateur et donc les dérives peuvent vite arriver, comme le fait
d'arrêter le serveur tous les soirs ou pour effectuer les sauvegardes.
Je sais bien que c'est comme s'ils conduisaient en marche arrière jusqu'à
Paris mais ils ne connaissent que cela. A moi de leur fair découvrir les
autres vitesses.

Ton premier argument est bon et pour l'instant je ne retiendrai que
celui-là.

Je résume donc ici les arguments non discutable des problèmes de l'arrêt
d'un serveur :
- les transactions non commitées sont perdus
- le Backup permet de vider le journal des transactions qui sinon
grossirait indéfiniment
- le serveur peut ne plus redémarrer si l'utilisateur du compte du service
SQL Server a été supprimé
- les fichiers deviennent accessibles par l'explorateur à l'utilisateur
non averti et peuvent être renommés, déplacés, supprimés et conduire à la
perte potentielle des données
- le backup permet de restaurer la BD si un problème survient "Point in
time recovery"
- la période de "recovery" peut prendre beaucoup de temps, ce qui rend les
BD non disponibles pour une longue période
- l'arret d'un serveur vide les caches SQL Server, les performances seront
ralenties au prochain redémarrage pendant un bon moment


Cordialement
Nicolas

"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de news:
%23%23tCQfDyFHA.908@tk2msftngp13.phx.gbl...

L'argument majeur est que l'arret d'un serveur vide les caches SQL Server
Les performances seront ralenties au prochain redemarrage pendant un bon
moment.
Un autre argument majeur qui pourrait faire changer definitivement a tes
collegues est que Microsoft ne supporte que les bases de donnees qui ont
ete proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et
non par l'arret du serveur)

Tout le reste peut preter a discussion ....

--
Bien cordialement
Med Bouchenafa



"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23ql3B4$xFHA.736@tk2msftngp13.phx.gbl...

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont plus
bloqués et peuvent être déplacées, modifiées, supprimées, etc. Cela peut
mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier
les fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus
simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE

Merci pour ces précisions, je crois que j'ai maintenant toutes les infos que
je recherchais.

Nicolas

"Philippe T [MS]" <ptrotin@online.microsoft.com> a écrit dans le message de
news: OG$%233tRyFHA.1168@TK2MSFTNGP15.phx.gbl...

Bonjour,

Non supporté signifie "seulement" que si un problème apparait sur un
serveur SQL et que l'on a besoin de faire appel au supprot Microsoft, ceux
ci auront le droit de refuser de solutionner le problème (c'est non
supporté) car c'est une utilisation détournée de la fonction qui n'a pas
été prévu et non validé par le support (un peu comme l'utilisation d'huile
végétales dans les moteurs diésels :-)).

L'avantage d'un moteur de base de données relationnels comme SQL Server
est justement de pouvoir faire des sauvegrades à chaud de la base. Le
fichier de backup ainsi généré est beaucoup plus faible que la somme des
fichiers MDF et LDF. De plus, le backup au niveau d'un plan de maintenance
SQL est l'occasion d'effectuer d'autres opérations (vidage du journal des
transactions pour les transactions commitées, vérification de l'intégrité
du backup, ...).

Après chacun fait ce qu'il veut mais pour moi les risques sont trop grand
d'interrompre le moteur juste pour faire de la copie de données
(interruption de service, risque de non redémarrage, pertes de
transactions, ...)

----------------------------------------------------------------------
Philippe TROTIN - Microsoft Service France

"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23DKoxhLyFHA.3180@TK2MSFTNGP14.phx.gbl...

Salut Med

Quand tu dis que "Microsoft ne supporte que les bases de donnees qui ont
ete proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et
non par l'arret du serveur)", tu veux dire que Microsoft ne l'a pas
prévue ou que cela ne fonctionne pas.
Comment expliques-tu alors que cela fonctionne tout de même de remplacer
des fichiers MDF et LDF par une sauvegarde de ces même fichiers non
détachés ?
C'est justement leur méthode et c'est bien parce que cela est possible
qu'ils le font.
De plus je lis assez souvent dans les posts que untel veut récupérer ses
bases alors que le serveur est planté, et donc que ses bases n'ont pas
été proprement détachés.

Attention, je ne suis pas entrain de les défendre mais plutôt à la
recherche de preuve.
Pour information, l'utilisation des bases de données chez nos clients
peut vous sembler être détournée puisque dans la plupart des cas, le
poste de travail est aussi celui qui fait office de serveur, mais quand
il n'y a qu'un seul poste il n'y a pas d'autre choix. Surtout, il n'y a
pas de vrai administrateur et donc les dérives peuvent vite arriver,
comme le fait d'arrêter le serveur tous les soirs ou pour effectuer les
sauvegardes.
Je sais bien que c'est comme s'ils conduisaient en marche arrière jusqu'à
Paris mais ils ne connaissent que cela. A moi de leur fair découvrir les
autres vitesses.

Ton premier argument est bon et pour l'instant je ne retiendrai que
celui-là.

Je résume donc ici les arguments non discutable des problèmes de l'arrêt
d'un serveur :
- les transactions non commitées sont perdus
- le Backup permet de vider le journal des transactions qui sinon
grossirait indéfiniment
- le serveur peut ne plus redémarrer si l'utilisateur du compte du
service SQL Server a été supprimé
- les fichiers deviennent accessibles par l'explorateur à l'utilisateur
non averti et peuvent être renommés, déplacés, supprimés et conduire à la
perte potentielle des données
- le backup permet de restaurer la BD si un problème survient "Point in
time recovery"
- la période de "recovery" peut prendre beaucoup de temps, ce qui rend
les BD non disponibles pour une longue période
- l'arret d'un serveur vide les caches SQL Server, les performances
seront ralenties au prochain redémarrage pendant un bon moment


Cordialement
Nicolas

"Med Bouchenafa" <com.hotmail@bouchenafa> a écrit dans le message de
news: %23%23tCQfDyFHA.908@tk2msftngp13.phx.gbl...

L'argument majeur est que l'arret d'un serveur vide les caches SQL
Server
Les performances seront ralenties au prochain redemarrage pendant un bon
moment.
Un autre argument majeur qui pourrait faire changer definitivement a tes
collegues est que Microsoft ne supporte que les bases de donnees qui ont
ete proprement sauvegardees par BACKUP ou detachees par sp_detach_Db(et
non par l'arret du serveur)

Tout le reste peut preter a discussion ....

--
Bien cordialement
Med Bouchenafa



"Nicolas MALESIC" <nmalesic@segilog.com> wrote in message
news:%23ql3B4$xFHA.736@tk2msftngp13.phx.gbl...

Bonjour à tous,

J'aimerais convaincre mes collègues du danger d'arrêter le serveur pour
faire des sauvegardes, mais je n'y parviens pas.
Je pense que l'arrêt du serveur est dangereux car les bases ne sont
plus bloqués et peuvent être déplacées, modifiées, supprimées, etc.
Cela peut mener à la perte totale de la base.
Ce à quoi me répondent mes collègues est que si on ne fait que copier
les fichiers MDF et LDF pour sauvegarde, puis on redémarre le serveur,
l'intégrité n'est pas altérée. De plus, ils me disent que c'est plus
simple.

Pouvez-vous infirmer ou confirmer mon sentiment ?

Nicolas

PS : Serveurs MSDE