Bonjour à tous.
J'ai un souci qui est le suivant: (SQL SERVER sous w2000 server)
Un traitement batch, qui s'exécute de nuit effectue les opérations
suivantes:
1- Arret SQL Server (pour "éjecter" les utilisateurs qui auraient
oublié de couper leurs applications):
2- Sauvegarde de plusieurs BDD...
3- Redémarrage SQL Server et traitements d'extraction de bases
externes vers SQL Server.
Aléatoirement, ce traitement se "plante" sur une ou plusieurs BDD au
moment de la sauvegarde avec le message suivant (dans les logs):
<b>udopen: erreur du système d'exploitation 32(Le processus ne peut
pas accéder au fichier car ce fichier est utilisé par un autre
processus.) lors de la création ou de l'ouverture de l'unité physique
G:\Microsoft SQL Server\MSSQL\data\xxxxxx_ita_Log.LDF</b>
(pas toujours sur la même base!!!)
Ensuite SQL Server redémarre, et les traitements s'exécutent, mais
j'ai un autre "plantage" dans les traitements car la base en question
est toujours utilisée par un "autre processus" que je n'arrive pas à
identifier...
Donc mes questions sont les suivantes:
1- Comment puis-je identifier quel processus "bloque" un fichier d'une
base SQL Server
2- Existe t'il un moyen de réellement "libérer" les bases de données
avant un tel traitement de sauvegarde (l'arrêt de SQLServer ne suffit
pas!!!)
>-----Message d'origine----- - Il n'est pas nécessaire d'arrêter SQL pour faire un backup. .
Pas pour faire un backup au sens SQL du terme. Notez qu'une simple copie de fichier ne suffira pas forcément à remettre en route une base...
ldelhome
Merci à tous de vos réponses...
L'arrêt de SQL sert uniquement à "éjecter" les utilisateurs qui travaillent sur les produits utilisant SQL Server...
Mais nous avons trouvé la cause de l'erreur, c'était une inversion dans le timing d'exécutuin des opérations, en fait le service était arrêté après...
Nous sommes obligés de faire cet arrêt/redémarrage car nos sauvegardes utilisent le plan de maintenance SQL Server, et donc il faut bien que les bases soient "libérées"...
Merci quand même LD
Merci à tous de vos réponses...
L'arrêt de SQL sert uniquement à "éjecter" les utilisateurs qui
travaillent sur les produits utilisant SQL Server...
Mais nous avons trouvé la cause de l'erreur, c'était une inversion
dans le timing d'exécutuin des opérations, en fait le service était
arrêté après...
Nous sommes obligés de faire cet arrêt/redémarrage car nos sauvegardes
utilisent le plan de maintenance SQL Server, et donc il faut bien que
les bases soient "libérées"...
L'arrêt de SQL sert uniquement à "éjecter" les utilisateurs qui travaillent sur les produits utilisant SQL Server...
Mais nous avons trouvé la cause de l'erreur, c'était une inversion dans le timing d'exécutuin des opérations, en fait le service était arrêté après...
Nous sommes obligés de faire cet arrêt/redémarrage car nos sauvegardes utilisent le plan de maintenance SQL Server, et donc il faut bien que les bases soient "libérées"...
Merci quand même LD
Patrice
Il y a tout de même quelque chose de pas clair dans tout cela...
La sauvegarde SQL Server crée un fichier distinct de sauvegarde sans avoir à interrompre l'exploitation des bases. C'est ce fichier qui est à sauvegarder via l'OS alors qu'il semble ici que l'on ait besoin d'accéder aux fichiers de "travail" de SQL Server pour les sauver directement ?
Voir peut-être le chapitre sur la sauvegarde dans la doc SQL Server...
Patrice
--
"LDELHOME/BABOLAT" a écrit dans le message de news:
Merci à tous de vos réponses...
L'arrêt de SQL sert uniquement à "éjecter" les utilisateurs qui travaillent sur les produits utilisant SQL Server...
Mais nous avons trouvé la cause de l'erreur, c'était une inversion dans le timing d'exécutuin des opérations, en fait le service était arrêté après...
Nous sommes obligés de faire cet arrêt/redémarrage car nos sauvegardes utilisent le plan de maintenance SQL Server, et donc il faut bien que les bases soient "libérées"...
Merci quand même LD
Il y a tout de même quelque chose de pas clair dans tout cela...
La sauvegarde SQL Server crée un fichier distinct de sauvegarde sans avoir à
interrompre l'exploitation des bases. C'est ce fichier qui est à sauvegarder
via l'OS alors qu'il semble ici que l'on ait besoin d'accéder aux fichiers
de "travail" de SQL Server pour les sauver directement ?
Voir peut-être le chapitre sur la sauvegarde dans la doc SQL Server...
Patrice
--
"LDELHOME/BABOLAT" <ldelhome@babolat.com> a écrit dans le message de
news:c850d6a4.0409230146.5b42ff3e@posting.google.com...
Merci à tous de vos réponses...
L'arrêt de SQL sert uniquement à "éjecter" les utilisateurs qui
travaillent sur les produits utilisant SQL Server...
Mais nous avons trouvé la cause de l'erreur, c'était une inversion
dans le timing d'exécutuin des opérations, en fait le service était
arrêté après...
Nous sommes obligés de faire cet arrêt/redémarrage car nos sauvegardes
utilisent le plan de maintenance SQL Server, et donc il faut bien que
les bases soient "libérées"...
Il y a tout de même quelque chose de pas clair dans tout cela...
La sauvegarde SQL Server crée un fichier distinct de sauvegarde sans avoir à interrompre l'exploitation des bases. C'est ce fichier qui est à sauvegarder via l'OS alors qu'il semble ici que l'on ait besoin d'accéder aux fichiers de "travail" de SQL Server pour les sauver directement ?
Voir peut-être le chapitre sur la sauvegarde dans la doc SQL Server...
Patrice
--
"LDELHOME/BABOLAT" a écrit dans le message de news:
Merci à tous de vos réponses...
L'arrêt de SQL sert uniquement à "éjecter" les utilisateurs qui travaillent sur les produits utilisant SQL Server...
Mais nous avons trouvé la cause de l'erreur, c'était une inversion dans le timing d'exécutuin des opérations, en fait le service était arrêté après...
Nous sommes obligés de faire cet arrêt/redémarrage car nos sauvegardes utilisent le plan de maintenance SQL Server, et donc il faut bien que les bases soient "libérées"...
