[SQL SRV 2005] Quelques questions sur les jobs

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.

Bonjour,

Citation:

---

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

---

Non

Citation:

---

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.

Citation:

---

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 ?

Citation:

---

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)

++

Citation:

---

Envoyé par mikedavem

Bonjour,
Non

---

Cool, déjà une piste à éliminer

Citation:

---

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.

Citation:

---

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é.

Citation:

---

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 !

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

Citation:

---

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.

++

+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

Ce que vous oubliez de prendre en compte c'est que je ne suis absolument pas dba mais programmeur. Je ne m'occupe de cela que parce qu'il faut bien que qqn le fasse vu qu'on n'a pas de dba là où je bosse.

Du coup, je me sens plus à l'aise avec SSIS qu'avec du TSQL. Je ne connais même pas la syntaxe pour écrire une commade de backup. Avec SSIS, elle est écrite pour moi.

C'est pour cela que je passe par là.

Bonjour,

Programmeur ou DBA, il faut que vous sachiez de toute façon ce que fait SQL Server, et l'interface graphique, si elle facilite la tâche, ne dévoile rien de ce qui se passe.

L’instruction pour la sauvegarde complète d'une base de données est très simple :

Code:

---

1 2	BACKUP DATABASE maBaseDeDonnées TO DISK = 'C:\backup\mabase.bak'

---

Vous pouvez l'agrémenter de plusieurs options, précédées de WITH :

- COMPRESSION : disponible sous SQL Server 2008 R1 Enterprise et SQL Server 2008 R2 Standard et Enterprise, elle permet comme son nom l'indique de compresser un backup. Cela requiert plus de CPU, mais la sauvegarde s'effectue plus vite, et la taille du fichier est bien sûr réduite.

- CHECKSUM, ce qui permet à postériori de vérifier la validité du fichier de sauvegarde, avant de passer à la restauration. Si le backup est compressé, c'est de toute façon ce qui se passe

- Si vous voulez essayer d'optimiser le traitement, vous pouvez éventuellement jouer avec les options BLOCKSIZE, BUFFERCOUNT et MAXTRANSFERSIZE, mais je ne pense pas que vous en ayez besoin pour le moment ;)

Ce qui donne, en SQL dynamique :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

CREATE PROCEDURE maint_backup AS BEGIN SET NOCOUNT ON   DECLARE @sql nvarchar(max) , @cr nchar(2) = NCHAR(13) + NCHAR(10)   ;WITH DB AS ( SELECT name FROM sys.databases WHERE user_access_desc = 'MULTI_USER' AND state_desc = 'ONLINE' AND source_database_id IS NULL -- la base de données n'est pas une capture instantanée de base de données AND name <> 'tempdb' -- c'est la seule base de données système qu'on ne peut pas sauvegarder ) SELECT @sql = CASE WHEN @sql IS NULL THEN '' ELSE @sql + '; ' + @cr END + 'BACKUP DATABASE ' + name + @cr + 'TO DISK = ''C:\backup\' + name + '_' + REPLACE(CONVERT(char(10), GETDATE(), 111), '/', '_') + '.bak''' FROM DB   --PRINT @sql   EXEC (@sql) END

---

Vous appelez cette procédure stockée dans votre job, et vous cochez la case Include step output history dans la page Avancé de l'étape, de telle façon a voir ce qui s'est passé si le job plante.

@++ ;)

On peut aussi agrémenter le script avec la création des dossiers et sous dossiers où l'on veut sauvegarder les backups ;)

++

Alors justement, est-ce que tu ferais ça avec xp_cmdshell :aie: ou avec une procédure stockée CLR ?

@++ ;)

J'espère que cette question ne m'est pas adressée :oops:

C'est vrai qu'elle est un peu adressée à mikedavem, mais rien ne vous empêche de répondre ;)

@++ ;)

Non juste cette procédure stockée système : xp_create_subdir mais c'est vrai qu'elle n'est pas documentée si je ne m'abuse. Disons qu'elle a le mérite de ne pouvoir créer que des dossiers sans pouvoir utiliser xp_cmdshell qui peut en fonction des privileges du compte de service aller jusqu'à formater une partition. Par ailleurs pour xp_create_subdir, il faut être sysadmin pour pouvoir l'exécuter :-)

Après rien ne nous empêche d'utiliser xp_cmdshell avec un serveur proxy pour limiter l'impact sur le système de fichier.

Une procédure stockée CLR pourquoi pas mais l'implémentation est beaucoup plus complexe du coup mais reste sécurisée puisqu'on limite dans la procédure les actions possibles.

++

Si vous le dites ^^.

Par contre, je viens vers vous avec mon souci de job.

Comme expliqué précédemment, j'ai un job comprenant n+1 step. Les n premiers step effectue donc chacun un backup de leur DB respective et le dernier se charge de déplacer les fichiers *.bak vers un drive sur le réseau car je manque de place sur le serveur.

C'est ce dernier step qui me pose probème. Pour tous les .bak sauf un, tout ce passe sans problème. Le seul qui pose un souci, est un backup qui fait plus de 40 GB.

La taille peut-elle avoir un impact en terme de réussite ou d'échec sur ce genre d'opération ? J'ai plus de 2 TB de libre sur le répertoire de destination donc l'espace disque n'est pas la cause de l'échec du déplacement. Par contre, quand je le déplace "manuellement", cela prend plus de 70 minutes. D'où ma question initiale sur les timeouts à laquelle vous avez répondu par la négative.

Du coup, je recherche l'origine du problème.

Auriez-vous une piste à me donner ?

Merci d'avance,

Griftou.

Non la taille du backup ne pose pas souci pour votre étape.
Quel est l'erreur rencontré ? Avez-vous un message d'erreur explicite ?

Pareil pour votre étape de déplacement de vos backups ? Quelle commande utilisez-vous ? Avez-vous une erreur ?


++

Mes excuses, j'aurais du penser à aller regarder dans l'historique et fournir le message d'erreur directement. Cela m'aurait p-e même éviter de vous ennuyer une nouvelle fois.

Voici ce que je trouve dans l'historique du job :

Citation:

---

Executed as user: leUsernameQuiVaBien. Microsoft (R) SQL Server Execute Package Utility Version 9.00.5000.00 for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 5:18:41 Error: 2012-02-14 06:00:05.83 Code: 0xC002F304 Source: moving files File System Task Description: An error occurred with the following error message: "The specified network name is no longer available. ". End Error DTExec: The package execution returned DTSER_FAILURE (1). Started: 5:18:41 Finished: 6:00:06 Elapsed: 2484.16 seconds. The package execution failed. The step failed.

---

J'ai mis en gras la partie qui me semble intéressante.

Autre point étrange, quand je vais vérifier les répertoires sources et destinations, pour ce fichier là, je le trouve aux deux endroits. La taille du fichier sur le répertoire de destination est bien la même que le fichier d'origine mais j'imagine qu'il s'agit juste d'espace disque "réservé" mais qu'il n'y a rien dedans.

Serait-ce donc un problème au niveau réseau ?

Je vais aller m'entretenir avec les gars qui s'occupe de la partie hardware/technique ^^.

Si vous avez des suggestions, n'hésitez pas !

Griftou.

Bon et bien j'ai ma réponse...

Le serveur de destination redémarre chaque nuit vers 6:00 am. Manque de bol, mon job s'exécute pendant ce temps-là...

Je vais donc le déplacer de créneau horaire et tout devrait bien se dérouler.

Griftou.