Nous travaillons sur la migration de notre bibliothèque de packages SSIS de SQL Server 2008 hébergé sur Physical Windows Server 2003 sur SQL Server 2012 hébergé sur Virtual Windows Server 2012. Les nouveaux packages que nous déployons à l'aide de votre déploiement de projet vers un catalogue de services d'intégration. Les paquets importent des données dans une autre base de données SQL Server 2012 sur un serveur/instance séparé.
Il semble que nous obtenons une erreur "échec de la connexion" lorsque le package tente d'exécuter plusieurs opérations SQL simultanées par rapport à la même base de données cibles SQL Server 2012.
[~ # ~] old [~ # ~ ~] (où ça marche)
[~ # ~] nouveau [~ # ~ ~] (où nous obtenons parfois l'erreur)
Une erreur inhabituelle se produit pour certains packages dans le nouvel environnement:
DTS_E_OLEDBERROR
An OLEDB error has occurred
Error code: 0x80040E4D
An OLEDB record is available.
Source: "Microsoft SQL Server Native Client 11.0"
HResult: 0x80040E4D
Description: "Login failed for user 'MyUser'"
Dans la base de données cible SQL Log, nous avons cette entrée:
Source: Logon, Message: Login failed for user 'MyUser'. Reason: Password did not match that for the login provided. [CLIENT: {IP addr. for SSIS DB server}]
tandis que cela semble coupé et séché, il ne raconte pas toute l'histoire.
Tout d'abord, nous double-vérifié les chaînes de connexion de base de données sur le package SSIS. Les packages ont des gestionnaires de connexion de base de données dont les propriétés de connexion sont liées aux paramètres de projet, qui sont à son tour liées aux variables d'environnement dans les catalogues de services d'intégration.
Nous avons vérifié que les packages sont exécutés à l'aide de l'environnement correct.
En outre, Opérations SQL utilisant le même gestionnaire de connexion fonctionnent Fine menant à l'erreur!
Le facteur commun dans toutes les erreurs semble être que lorsque plusieurs opérations SQL simultanées se produisent à l'aide du même gestionnaire de connexion de base de données, nous obtenons cette erreur "Échec de la connexion".
Lorsque nous refloyons une partie défaillante d'un package pour exécuter des opérations de base de données une à la fois au lieu de simultanément, l'erreur disparaît.
Ces forfaits ont fonctionné correctement dans SSIS 2008 ciblant une base de données SQL Server 2008, en cours d'exécution sur des serveurs physiques Windows Server 2003.
Lorsque nous exécutons les nouveaux packages SSIS 2012 de Visual Studio contre la même base de données cible (SQL 2012 sur Virtual Windows Server 2012), nous ne rencontrons pas l'erreur.
Cela nous conduit à croire que cela a quelque chose à voir avec la manière dont ils sont déployés et courent dans le catalogue des services d'intégration, mais nous ne pouvons pas comprendre ce qui ne va pas. Voici où nous pourrions utiliser une aide.
Ici, c'est: la connexion à l'échec en question était une connexion SQL Server. Voici comment nous avons configuré les propriétés SQL Connection Manager pour les environnements anciens, nouveaux et développeurs:
ServerName
- MyServer
InitialCatalog
- MyDB
UserName
- MyUser
Password
- ***********
ConnectionString
- Data Source=MyServer;User Id=MyUser;Initial Catalog=MyDB;Provider=SQLNCLI11;Persist Security Info=True;Auto Translate=False;
Bien que cela fonctionnait parfaitement sur l'ancien environnement SQL 2008, et ce n'était pas un problème de Visual Studio, il n'a pas échoué lors des opérations de base de données simultanées à partir du catalogue de services d'intégration SQL 2012, mais a commencé à travailler lorsque nous avons ajouté Password=******
à la chaîne de connexion.
ConnectionString
- Data Source=MyServer;User Id=MyUser;Password=********;Initial Catalog=MyDB;Provider=SQLNCLI11;Persist Security Info=True;Auto Translate=False;
Il semblerait que si une deuxième connexion simultanée est ouverte lors de l'environnement d'exécution du catalogue de services d'intégration SQL 2012, seule la chaîne de connexion elle-même (de la connexion initiale?) Est consultée, pas Password
ou d'autres propriétés constitutives de le gestionnaire de connexion. Par conséquent, Password
doit être dans la chaîne de connexion.
Cela fonctionnait en effet mais seulement une fois, car il ne sauverait pas le mot de passe, même avec des informations de sécurité persistantes = true; J'ai fini par utiliser un compte d'utilisateur Windows pour vous connecter et basculer la sécurité du package à s'appuyer sur les rôles SQL Server et cela a fonctionné.