Discussion :

[thierryinfo2012]

bonjour

Pour des raison de sécurité l'administrateur système et sécurité ma demandé de désactivé le compte (sa)

Alors Tout mes job SQL sont configurer en Propriétaire avec le compte "SA"

ma question est la suivante:si je désactive le compte SA j'aurai t'il des erreurs d’exécution sur mes job

merci

[janlouk]

Oui, ils vont tous plantés
Vu qu'il a besoin de droits pour faire ses "actions". Retire le pilote d'une F1, ça ira tout de suite moins bien
Et il n'y a pas que les jobs, à voir aussi si sa n'est pas owner de certaines DB...

[Kropernic]

Ce n'est pas le compte du service sql server agent qui est utilisé pour exécuter les jobs ???

[thierryinfo2012]

le compte d’exécution est une Compte AD Qui a tout les accé ressource Système

[SQLpro]

Ce n'est pas le compte du service sql server agent qui est utilisé pour exécuter les jobs ???

Uniquement pour les jobs non SQL... genre commande système.

a +

[elsuket]

Bonjour,

Le compte sa est désactivé sur toutes les instances SQL Server que j'administre.
Quelques-unes ont des jobs, et tous ces jobs ont pour propriétaire est sa. Donc, ça fonctionne.

Ceci est du au fait que le propriétaire d'un job indique seulement qui peut l'exécuter.
Un job peut ne pas avoir de propriétaire, et dans ce cas, seul un utilisateur membre du rôle de serveur sysadmin peut l'exécuter.
Si on veut donc qu'un groupe Active Directory de DBAs puisse exécuter un jobs, on peut leur octroyer la propriété de ce job.
S'il n'est pas nécessaire qu'un utilisateur exécute un job, c'est à dire que le job ne s'exécute que suivant sa planification, alors on peut spécifier comme propriétaire sa, alors qu'il est désactivé, et/ou renommé.

@++

[janlouk]

Nicolas,
Tu viens de balayer toutes mes croyances, je n'avais jamais testé mais j'étais persuadé du plantage.
Désolé pour mon erreur.

[elsuket]

Pas de problème, on est là pour apprendre ...
Je t'avoue que tu m'as mis le doute, du coup j'ai testé pour vérifier.

@++

[janlouk]

Ceci est du au fait que le propriétaire d'un job indique seulement qui peut l'exécuter.

Mais alors, dans un sens, selon ma logique, je ne trouve pas "logique" que si le job peut être exécuté par sa, et que sa est désactivé. Je trouve ça bizarre que le job puisse encore être exécuté...

ps: heureusement, j'ai posé la question à mon collègue, et il pensait la même chose que moi

[elsuket]

Dans le cas des bases de données non-contenues, le fait que le login sa soit désactivé empêche simplement de se connecter à l'instance sous ce nom de login.
Cela n'empêche pas un membre du rôle se serveur sysadmin de l'utiliser une fois qu'il est authentifié et qu'il a été établi qu'il est bien membre de ce rôle de serveur.

L'avantage d'utiliser ce nom de login, bien qu'il soit désactivé, est qu'il est présent sur toute instance SQL Server.
Dès lors, un déplacement de base de données ou une copie de job se fait sans encombre.
Par ailleurs, si le propriétaire de la base de données est un groupe AD, ou pire, un utilisateur AD, le jour où l'on modifie le groupe ou désactive le compte d'utilisateur AD ... patatra !

@++

[olivtone]

L'avantage d'utiliser ce nom de login, bien qu'il soit désactivé, est qu'il est présent sur toute instance SQL Server.
Dès lors, un déplacement de base de données ou une copie de job se fait sans encombre.
Par ailleurs, si le propriétaire de la base de données est un groupe AD, ou pire, un utilisateur AD, le jour où l'on modifie le groupe ou désactive le compte d'utilisateur AD ... patatra !

@++

Je plussoie ce que tu dis, car cette mesaventure, m'est deja arrivée