Qu'est-ce qui provoquerait un ## MS_PolicyEventProcessingLogin ## orphelin?

Ce matin, j'ai remarqué que mon journal SQL se remplissait du message suivant:

Le proc activé '[dbo]. [Sp_syspolicy_events_reader]' exécuté sur la file d'attente 'msdb.dbo.syspolicy_event_queue' affiche ce qui suit:
'Impossible d'exécuter en tant que principal de la base de données car le principal "## MS_PolicyEventProcessingLogin ##" n'existe pas, ce type de le principal ne peut pas être usurpé de l'identité ou vous n'avez pas la permission.

L'exécution de ce qui suit a EXEC sp_change_users_login 'report'révélé que la connexion était en fait orpheline.

J'ai pu le réparer en exécutant ce qui suit comme recommandé dans ce message MSDN .

EXEC sp_change_users_login 
    'Auto_Fix', '##MS_PolicyEventProcessingLogin##', 
    NULL, 'fakepassword'

Mais la question demeure: qu'est-ce qui aurait pu rendre ce principal orphelin en premier lieu? La recherche sur Google et la recherche révèlent que d' autres ont eu ce problème, mais je n'ai pas encore trouvé de description de la cause. Rien de notable à ma connaissance ne s'est produit au moment où l'erreur a commencé à apparaître.

Nous avons déplacé l'ensemble du serveur vers un modèle de stockage SAN l'été dernier, nous avons tout restauré (y compris msdb) lors de ce déménagement, mais c'était il y a des mois. Ce n'est que quelque chose de récent qui a rendu le symptôme manifeste car il n'apparaît pas dans le journal plus tôt qu'il y a quelques semaines.

Nous avons mis à niveau deux serveurs (de SQL 2000) vers SQL 2008R2 à l'aide d'une mise à niveau sur place. Nous avons commencé à obtenir ces messages dans les journaux SQL après la mise à niveau. Nous n'avons pas modifié cela ni aucun autre identifiant ou utilisateur pendant le processus de mise à niveau.

Je suppose que le processus de mise à niveau a laissé deux comptes ( ##MS_PolicyEventProcessingLogin##et ##MS_PolicyTsqlExecutionLogin##) orphelins.

EXEC sp_change_users_login 'Auto_Fix', '<User Name>' résolu ce problème.

Causes typiques: quelqu'un abandonne la connexion (pensant qu'il nettoie les mauvaises connexions) ou restaure l'une des bases de données système.

Il est difficile de deviner ce que c'était après coup, cependant. Dans les bases de données utilisateur, vous pouvez parcourir les journaux de transactions pour effectuer une rétro-ingénierie, mais vous ne pouvez pas effectuer de sauvegardes de journaux pour le maître, vous n'avez donc pas de chance.

Je pense que vous avez restauré msdb, mais vous aviez une nouvelle base de données master.