SQL Server Agent : The given key was not present in the dictionary

Bonjour à toutes et tous,

Mon problème de la semaine est le suivant : Nous avons installé un nouveau serveur SQL sur un serveur virtualisé. Ceci pour remplacer un serveur physique existant, le serveur virtualisé le remplacera.
Nous avons restauré les bases, remis en place les catalogues Intégration Services, les packages SSIS fonctionnent correctement etc. sauf que quand je refais les jobs de l'agent SQL Server pour ordonnancer mes packages comme sur l'ancien, le job se lance bien mais par contre je n'ai aucun log ni historique sur le travail de l'agent et j'ai ce message là :

Code:

---

1 2 3 4 5 6 7 8 9 10

The given key was not present in the dictionary. (mscorlib)   ------------------------------ Emplacement du programme*:   à System.Collections.Generic.Dictionary`2.get_Item(TKey key) à Microsoft.SqlServer.Management.SqlManagerUI.LogMemoryStorage.AddRowNumberToSourceIndex(Int32 rowNumber) à Microsoft.SqlServer.Management.SqlManagerUI.LogMemoryStorage.InitializeStorage() à Microsoft.SqlServer.Management.SqlManagerUI.LogMemoryStorage.Initialize() à Microsoft.SqlServer.Management.SqlManagerUI.LogAggregator.DelegateAggregationWorkImplementation(ILogDataStorage storage)

---

Nous avons un Windows Server 2012 R2 virtualisé et un SQL SERVER SP3 (11.0.6248)

J'ai découvert qu'il y avait déjà un bug ayant le même message d'erreur qui devait être réglé via le SP2. Donc en toute logique ce message d'erreur ne doit pas venir d'un bug.
Pour info le message que j'ai trouvé sur cet "ancien" bug : https://connect.microsoft.com/SQLSer...onary-mscorlib

Avez vous une idée de comment récupérer les logs et historiques de l'agent ?

Merci d'avance pour vos idées et solutions.

Depuis SQL Server 2012, Microsoft conseille d'installer aussi les CU même si on ne rencontre pas de problème.

Tu peux peut-être déjà installer le CU8 pour le SP3 et voir si ça règle ton problème.

Bonjour janlouk,

Etant néophyte et autodidacte dans l'administration de SQL Server, ma première question est : Mais qu'est ce donc que ce CU ?
Sinon je vais regarder par là, merci pour l'idée.

Je reviens pour le résultat.

EDIT : Ahhh Cumulative Update ! Ben je me coucherais moins bète ce soir ! :D

La CU8 SP3 à été installé, tout s'est bien déroulée. Mais par contre cela n'a pas réglé le problème.

Auriez vous installé votre serveur par copie d'une VM ?

A +

Bonjour,

Ce n'est pas moi qui ai installé le serveur mais, c'est le client qui l'a installé, mais effectivement, c'est une hypothèse plus que probable, oui.

C'est ce qu'il faut éviter...

Recommencez l'installation depuis le début, sans copier une VM.

A +

Merci pour votre analyse. C'est effectivement pas impossible.

Malheureusement, moi j'arrive après la bataille et le serveur est déjà "en eau". Donc je vais voir si on ne peut pas carrément tout réinstaller, mais ça m'étonnerait très fort que cela soit possible.

Le problème vient d’où exactement ? Est-il possible de le régler à postériori ?

Le problème vient probablement du calcul d'une valeur de clef de registre qui n'est pas conforme.

Afin de distinguer ce qui peut venir d'un service et d'un autre, les installations diffèrent, pour les clefs de registre, par des calculs lors du processus d'installation. En squeezant le processus d'installation ou en le faisant partiellement à la manière d'un clonage (ce qui n'est pas une bonne pratique) vous obérez la qualité de l'installation.

A +

Ok,

Oui et donc aller mettre les mains dans les clés de registres ne me réjouit pas du tout...

Et bien merci pour les explications. Je met en "résolu" pour le moment, mais si un lecteur futur de ce sujet à plus d'explications et de solutions sous le coude, qu'il n'hésite pas à le compléter par un petit message.

++

Nouvelle information.

Mon client à bien installé un Windows sur une nouvelle VM, et n'a pas copié un template de VM avec un Windows déjà installé dessus. Donc mauvaise piste.
Et ça ne touche bien que les logs / historique de l'Agent SQL