Aujourd'hui, nous avons migré vers AzureSQL V12. Ce soir, mon site est hors ligne en raison d'un problème persistant lié au message suivant:
ID de ressource: 3. La limite LoginLimit pour la base de données est 90 et a été atteinte. Voir ' http://go.Microsoft.com/fwlink/?LinkId=267637 ' pour obtenir de l'aide. (Microsoft SQL Server, erreur: 10928)
J'ai essayé ce qui suit:
Je ne parviens pas à me connecter à ma base de données via SSMS. Je reçois le même message d'erreur. Cela dure depuis des heures et mon site est complètement hors ligne, mais le nombre de connexions ne change pas.
J'ai besoin d'un moyen de déconnecter certaines de ces connexions pour pouvoir diagnostiquer le problème.
RÉSOLUTION: Finalement, après plusieurs heures passées au téléphone avec Microsoft, ils ne pouvaient pas accéder au serveur par des moyens conventionnels et devaient migrer la base de données vers un autre noeud avant que les connexions ne soient effacées.
Je ne sais toujours pas ce qui a causé cela au départ, mais nous avions migré de Web Edition vers le niveau Standard S0, puis mis à niveau la base de données de V11 à V12, et je pense que quelque chose a mal tourné.
J'aime les suggestions ci-dessous pour essayer CAD, et si le problème se reproduit, je vais essayer et faire rapport.
MISE À JOUR 2: Juste au cas où quelqu'un d'autre serait intéressé, il me semble, d'après les informations que j'ai reçues de Microsoft, qu'il y avait un problème avec les sauvegardes automatisées qui, d'une manière ou d'une autre, ont échoué et n'ont pas interrompu les connexions à la base de données. Si j'en entends plus, je publierai une mise à jour, mais dans l'intervalle, je suggérerais qu'il serait prudent de désactiver les tâches de sauvegarde que vous pourriez avoir avant de mettre à niveau/de modifier les niveaux de votre instance SQL Azure.
Pour voir les connexions existantes sur Azure SQL DB, j'utilise cette requête:
SELECT
c.session_id, c.net_transport, c.encrypt_option,
s.status,
c.auth_scheme, s.Host_name, s.program_name,
s.client_interface_name, s.login_name, s.nt_domain,
s.nt_user_name, s.original_login_name, c.connect_time,
s.login_time
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
ON c.session_id = s.session_id
--WHERE c.session_id = @@SPID;
--WHERE status = 'sleeping'
ORDER BY c.connect_time ASC
Pour tuer toutes les connexions sauf le mien (SPID) j'utilise cette requête:
DECLARE @kill varchar(8000) = '';
SELECT @kill = @kill + 'KILL ' + CONVERT(varchar(5), c.session_id) + ';'
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions AS s
ON c.session_id = s.session_id
WHERE c.session_id <> @@SPID
--WHERE status = 'sleeping'
ORDER BY c.connect_time ASC
EXEC(@kill)
Si ces connexions sont toujours bloquées et qu'elles n'ont pas expiré, vous pouvez utiliser la commande t-sql KILL pour les tuer.
Une autre option consiste à utiliser le CAD. Voir les détails ici sur MSDN .
Si aucune de ces options ne vous aide, veuillez m'envoyer par e-mail les détails de votre serveur et de votre base de données sur shantanu dot kurhekar à Microsoft dot com et je peux vous aider.
Vous pouvez utiliser une connexion administrateur DAC similaire à celle de SQL on premise et tuer les connexions lorsque les sessions sont épuisées. Vous pouvez trouver les détails @ http://www.sqlindepth.com/2015/05/diagnostic-connections-to-sql-db-v12-databases/
Une autre option moins connue ici, cette limite est basée sur le niveau sur lequel vous vous trouvez (S1, S2, P1, etc.) afin que vous puissiez monter d'un niveau pour obtenir un montant de connexion plus élevé qui vous aurait potentiellement permis de résoudre le problème.
Souvent, remonter un niveau comme celui-ci déplace également le nœud sur lequel vous vous trouvez, ce qui supprimerait également les connexions erronées.