Discussion :

[Kropernic]

Bonjour,

Je viens avec quelques questions pour lesquelles j'ai du mal à trouver des réponses satisfaisantes sur le net étant données mes faibles connaissances...

1° : Les jobs (ou les steps qu'ils contiennent) ont-ils des time-out ?

Je me pose cette question car j'ai un job composé de plusieurs steps. 13 pour être précis. Les 12 premiers backupent différentes DB et le 13 se charge de déplacer les fichiers .bak vers un autre serveur.
Tout semble avoir fonctionner correctement excepté pour le backup de la plus grande DB. La taille de ce fichier .bak est de 44GB. Par conséquent, le transfert d'un serveur à l'autre prend un temps assez important à s'effectuer. Cela peut-il poser problème ?

2° : Est-il possible de faire s’exécuter un step ou à défaut, un job en entier, par un autre user que le NT AUTHORITY\NetworkService ?

A ce sujet, il m'a semblé comprendre qu'il fallait aller dnas les propriétés du SQL SERVER AGENT > Job System et paramétrer "Job step proxy account". Mais je n'en suis pas du tout certain... (c'est à peine si je sais ce qu'est un proxy.) Mais quoi qu'il en soit, cette option est grisée chez moi.

Merci d'avance,

Griftou.

[mikedavem]

Bonjour,

1° : Les jobs (ou les steps qu'ils contiennent) ont-ils des time-out ?

Non

Tout semble avoir fonctionner correctement excepté pour le backup de la plus grande DB. La taille de ce fichier .bak est de 44GB. Par conséquent, le transfert d'un serveur à l'autre prend un temps assez important à s'effectuer. Cela peut-il poser problème ?

Pour le job lui même nom mais vous ne pouvez avoir un même job lancé qu'une seule fois en même. Cela signifique qui si votre job s'exécute en plus de temps que l'intervalle défini entre chaque exécution, la 2eme occurence du job sera en échec.

Je me pose cette question car j'ai un job composé de plusieurs steps. 13 pour être précis. Les 12 premiers backupent différentes DB et le 13 se charge de déplacer les fichiers .bak vers un autre serveur.

12 étapes pour 12 backups de bases ?

2° : Est-il possible de faire s’exécuter un step ou à défaut, un job en entier, par un autre user que le NT AUTHORITY\NetworkService ?

Oui en utilisant les proxy pour les étapes de type SSIS par exemple paramétrer directement le compte d'impersonnalisation pour les étapes de type TSQL. (dans les options avancées de l'étape)

++

[Kropernic]

Bonjour,
Non

Cool, déjà une piste à éliminer

Pour le job lui même nom mais vous ne pouvez avoir un même job lancé qu'une seule fois en même. Cela signifique qui si votre job s'exécute en plus de temps que l'intervalle défini entre chaque exécution, la 2eme occurence du job sera en échec.

La planification de ce job est prévue pour qu'il s'exécute une fois par jour à 5:00 am. Donc ce n'est pas le souci.

12 étapes pour 12 backups de bases ?

En effet, il y a 12 DB dont il faut faire le backup. J'ai réfléchi entre créer 12 jobs ou 12 steps et la 2e option m'a parue plus adéquate (p-e à tord). En créant 12 steps, je peux m'assurer qu'il n'y a pas 2 backups qui sont effectués en même temps. Cela n'aurait p-e aucune incidence mais j'ai des tendances paranoïaque à ce sujet ^^. Chaque step étant un package SSIS qui est implémenté pour envoyé un mail aussi bien à la réussite qu'à l'échec et ils sont configuré pour passer au step suivant quoi qu'il arrive. De cette manière, j'ai le détail de ce qui a réussi ou non dans ma boite e-mail et même si le backup n°3 rate, les suivants seront tout de même effectué.

Oui en utilisant les proxy pour les étapes de type SSIS par exemple paramétrer directement le compte d'impersonnalisation pour les étapes de type TSQL. (dans les options avancées de l'étape)

++

Je regarderai donc cela plus en profondeur lundi à la première heure.
Auriez-vous éventuellement de la documentation (tuto?) sous la main ? Si non, ce n'est rien, je tenterai de redemander à mon ami google maintenant que j'ai des mots clefs sur lesquels effectuer une recherche ^^


Merci !

[Ptit_Dje]

Voila pour le tuto
http://blog.developpez.com/dje/p1054...-un/#more10545

[mikedavem]

En effet, il y a 12 DB dont il faut faire le backup. J'ai réfléchi entre créer 12 jobs ou 12 steps et la 2e option m'a parue plus adéquate (p-e à tord). En créant 12 steps, je peux m'assurer qu'il n'y a pas 2 backups qui sont effectués en même temps. Cela n'aurait p-e aucune incidence mais j'ai des tendances paranoïaque à ce sujet ^^. Chaque step étant un package SSIS qui est implémenté pour envoyé un mail aussi bien à la réussite qu'à l'échec et ils sont configuré pour passer au step suivant quoi qu'il arrive. De cette manière, j'ai le détail de ce qui a réussi ou non dans ma boite e-mail et même si le backup n°3 rate, les suivants seront tout de même effectué.

Votre solution n'est pas très dynamique car si vous supprimez ou ajouter une base il faudra toucher à votre job. Perso, je ferai une seule procédure qui sauvegarder chaque base de données utilisateurs séquentiellement avec un job en cas d'échec que j'appelerai via une seule étape dans le job SQL. De cette manière je ne touche plus au job si mon nombre de BDD évolue.

Après choisir SSIS pour faire un backup et envoyer un email, c'est un choix mais perso je préfère utiliser du TSQL pour cela.

++

[dbaffaleuf]

+1

Il n'y a pas à priori de problème à backuper plusieurs bases en même temps, si le sous système IO le permet. Une des limitations techniques sur le nombre de bases sauvegardables en même temps est la mémoire allouée à chaque backup (allouée à l'extérieur du BP) et le nombre de workers alloués à l'opération ( (max worker threads - nb background threads) / 2). cf http://blogs.msdn.com/b/psssql/archi...taneously.aspx