Utilisateur de sauvegarde

Version imprimable

16/11/2008, 00h55
Sanvean

Utilisateur de sauvegarde
Bonjour,

J'essaie d'automatiser la sauvegarde physique et logique de mes bases avec un compte dédié à ceci afin de limiter les risques, compte que je nomme "opr".

J'arrive avec ce compte à faire la sauvegarde logique sans problème. Par contre, pour la sauvegarde physique, j'aurais souhaité attribuer à opr les droits d'exécuter sp_detach_db et sp_attach_db. Or, je me heurte à ce refus :

"L'utilisateur 'opr' n'est pas autorisé à exécuter DBCC detachdb pour la base de données 'AdventureWorks'."

Je précise que j'ai préalablement exécuté ces commandes :
Code:

1 2 3 4 5 USE master GRANT EXECUTE ON sys.sp_attach_db TO opr GO GRANT EXECUTE ON sys.sp_detach_db TO opr GO
Je ne vois pas que rajouter de plus... une idée ?

Merci de votre aide.
17/11/2008, 09h11
SQLpro

Vous ne pouvez pas manipuler des privilèges pour les objets systèmes. Pour faire ceci vous devez jouer sur les rôles pré établis de serveur ou bien trouver le bon privilège niveau serveur qui permet d'activer cette commande.

Enfin, l'utilisation de sp_detach est à déconseiller fortement dans le cadre d'une sauvegarde par copie des fichiers de la base. Ceci en effet vide le cache ce qui revient à faire perdre la mémoire à SQL Server et oblige à faire toutes les requêtes par lecture du disque et recompile toute les requêtes, procédures stockées, etc...
Bref, c'est le moyen le plus sûr de pourrir les performances de votre serveur !

A +
17/11/2008, 09h58
Sanvean

Bonjour,

Merci pour votre réponse.

Si le détachement et le rattachement des bases joue sur les performances de SQL Server, comment pourrais-je faire une copie physique de mes bases sans altérer les performances ? En arrêtant / redémarrant le service ?

Je souhaite faire une copie physique pour faire une sauvegarde sur bande quotidiennement.

Merci.
17/11/2008, 10h51
SQLpro

Citation:

Si le détachement et le rattachement des bases joue sur les performances de SQL Server, comment pourrais-je faire une copie physique de mes bases sans altérer les performances ? En arrêtant / redémarrant le service ?

C'est pire encore puisque vous perdez la mise en cache de toutes les bases de données.

La seule manière de sauvegarder proprement les bases de données et de lancer la commande BACKUP DATABASE ... ce qui produit un fichier de sauvegarde que vous pouvez véhiculer ou bon vous semble.
C'est aussi simple que cela !

A +
17/11/2008, 11h08
Sanvean

Pour le Backup Database, c'est en cours d'automatisation.

Par contre, d'un point de vue performances, j'ai l'impression que ça ne fait pas trop de différence sur mon serveur...

- SQL Server 2005, pour Microsoft Dynamics CRM 4.0
- 25 utilisateurs au total (3 à 4 simultanés maxi, peut-être)

Vu le peu de requêtes, est-ce que un détachement ou un arrêt du service pourrait être contraignant d'un point de vue performances pour les utilisateurs ?

Merci !
18/11/2008, 09h05
SQLpro

Citation:

Vu le peu de requêtes, est-ce que un détachement ou un arrêt du service pourrait être contraignant d'un point de vue performances pour les utilisateurs ?

Je n'arrête pas de vous le dire !

Et puis quel en serait l'intérêt ? Cette manœuvre à tire de sauvegarde est stupide

A +
19/11/2008, 16h50
WOLO Laurent

Qu'est ce que vous repprochez vraiment à

Code:

backup Database ou Log
21/11/2008, 09h16
Fabien Celaia

Sur le fond, je rejoins mes collègues Wolo Laurent et SQLPro.

Quel est l'intérêt de faire une sauvegarde physique ? Aucun !
La capacité d'attacher et de détacher une base doit se faire à bon escient (par exemple pour changer de serveur).

La sauvegarde "à froid" su MS-SQL n'a aucun intérêt sinon.
22/11/2008, 21h14
Sanvean

Bonsoir,

Désolé du temps de réponse, mais je ne vous avais pas oublié.

Déjà, merci beaucoup pour vos interventions.

J'ai un peu discuté de tout cela avec mes collègues, orientés Oracle, qui coupent les bases chaque nuit et font une sauvegarde physique des fichiers.

Pour situer le contexte, nous travaillons pour l'administration, nos applications sont utilisées par des clients répartis dans toute la France.

La raison qu'ils invoquent est un gain de temps au cas où il faudrait remonter une base à un état antérieur, ou une reconstruction suite à une panne système / changement de machine. L'autre raison se résume à une expression : "ceinture et bretelles". Pour eux, mieux vaut avoir trop de moyens de retour en arrière que pas assez.

Il est vrai que pour travailler également sur Oracle, les dumps à remonter prennent beaucoup de temps, les bases étant assez lourdes. En clair : quand je remonte un dump, j'ai le temps d'aller faire chauffer le café...

Maintenant, dans mon cas, la base SQL Server est très légère (250 Mo pour l'ensemble des fichiers data & logs, bases système comprises), avec très peu de connexions. Le besoin de raccourcir les temps d'interruption est donc beaucoup moins critique.

Je suis conscient qu'il n'est pas forcément nécessaire de disposer des fichiers physiques pour reconstituer une base de données. Disons que pour le moment, n'étant pas trop à l'aise dans ce domaine (disons que je n'ai pas encore eu l'occasion de tester toutes les manières d'avoir une base ou un moteur SQL cassé), c'est plus un souci de sécurité.

Maintenant, si la perte du cache peut avoir des conséquences sur l'utilisation quotidienne de l'application faisant appel à SQL Server (MS Dynamics CRM), je crois que le mieux à faire serait que je remonte le système sur un serveur d'essai, afin de simuler une perte physique : de cette façon, ça pourra peut-être me prouver à moi-même que je peux dans tous les cas me passer des fichiers physiques, et que les backups sont suffisants.

Merci encore.
24/11/2008, 11h20
SQLpro

Citation:

font une sauvegarde physique des fichiers.

C'est une abbération... Ont-ils déjà procédé à une restauration avec ce principe ?
L'arrêt d'un serveur possède deux inconvénients :
1) il ne garantie pas la consistance logique des fichiers indépendamment
2) le serveur perd toute la mise en cache.

Expliquons :
1) pas de consistance logique des fichiers.
Le fermeture d'une base, comme la fermeture du serveur est une opération d'urgence qui peut être réalisé même si des transactions n'ont pas été finalisées.
Dans ce cas si le fichier du journal est détruit, la base peut être irrémédiablement perdue.

2) les données des bases sont mise en cache afin d'accélérer les performances. Un SGBDR travaille en principe exclusivement en RAM. Le fait d'arrêter une base ou pire d'arrêter le serveur fait perdre la mise en cache.
Ceci a des conséquences catastrophique sur les performances.

A ces données, je dirais qu'aucun de vos administrateur n'a de réelles compétence en matière de DBA !

A +
28/11/2008, 13h20
Sanvean

Citation:

Envoyé par SQLpro

A ces données, je dirais qu'aucun de vos administrateur n'a de réelles compétence en matière de DBA !

N'exagérons rien...

J'ai tenté la recréation d'une base à partir d'un fichier .bak, c'est OK. J'en conclus qu'effectivement, une copie de fichiers mdf & ldf n'est pas plus rapide.

Ne me reste plus qu'à vérifier que les droits des comptes utilisateurs soient bien conservés lors d'une recréation du système.

Merci.