Sur une instance SQL Server 2014 avec suffisamment de RAM et de disques rapides, plus de 160 utilisateurs ont accès à une base de données. Pour une raison inconnue pour moi, l'exécution de la commande DROP USER [username]
dans cette base de données prend jusqu'à 5 secondes par utilisateur.
Le remappage des utilisateurs aux connexions et la restauration de leurs autorisations est très rapide.
Dans le contexte de l'actualisation des bases de données DEV à partir de la production, je dois supprimer et recréer tous les utilisateurs de base de données. Alors oui, il est nécessaire de supprimer les utilisateurs de la base de données et de les recréer.
Comment accélérer la DROP USER
commande?
Rappelez-vous, je dois l'exécuter plus de 160 fois pour l'instance sur laquelle j'écris.
Voici le SQL que j'utilise:
DECLARE drop_user_cur CURSOR FOR
SELECT name FROM #drop_users
OPEN drop_user_cur
FETCH NEXT FROM drop_user_cur INTO @user
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'use [' + @db_name + '] DROP USER [' + @user + ']'
BEGIN TRY
print @sql
EXECUTE(@sql)
END TRY
BEGIN CATCH
print 'ERREUR : ' + @sql
END CATCH
FETCH NEXT FROM drop_user_cur INTO @user
END
CLOSE drop_user_cur
DEALLOCATE drop_user_cur
Le problème ne vient pas du curseur; c'est le réel DROP USER
qui prend jusqu'à 5 secondes.
En utilisant sp_whoisactive
, le wait_type est NULL
.
Ne faites pas attention à la durée, le DROP
et CREATE USER
étaient exécutés en WHILE
boucle, c'est pourquoi cela en dit plus d'une minute.
Le profileur affiche plus de 125 000 lectures à exécuter DROP USER
.
Service Broker n'est pas activé.
la source
Réponses:
La résolution de ce problème activait le courtier de services sur la base de données.
Après avoir activé Service Broker pour la base de données, les utilisateurs de suppression étaient pratiquement instantanés.
Kin a demandé si le courtier de services était activé dans un commentaire précédent qui m'a envoyé chercher dans la bonne direction.
la source
ce n'est pas une réponse à la question mais un argument pour la rejeter complètement.
Si je comprends bien votre commentaire:
votre objectif est de copier les données de production sur un système de développement et de les faire fonctionner avec les mêmes autorisations que celles de production, en utilisant les mêmes noms d'utilisateur .
Le chemin le plus rapide consiste à cloner des connexions sql du système de production vers le système de développement en utilisant la procédure décrite par ms dans cet article kb .
avec la procédure définie par ms, le résultat est que vous pouvez restaurer les bases de données sur votre serveur de développement et que l'autorisation fonctionne sans modifications.
J'ai utilisé avec succès la procédure mentionnée ci-dessus pour copier un env de production sql 2005 sur les environnements test & dev sql 2012.
Après le clonage des utilisateurs, une simple restauration de la base de données m'a conduit à une paire de nouveaux systèmes pleinement opérationnels avec des données à jour.
L'énorme avantage de cette solution est que pour actualiser les données de développement, vous venez de restaurer la base de données de production et c'est tout; vous devrez ajuster les références, les synonymes et autres, mais les autorisations ne seront pas rompues.
Voici le code de l'article, juste pour référence, mais veuillez vous référer à l'article qui contient des remarques et des détails sur la compatibilité avec les anciennes versions de SQL, les détails de cryptage des mots de passe et d'autres informations qui peuvent vous éviter des maux de tête lors du transfert des connexions entre les serveurs:
la source
Un curseur similaire à celui-ci devrait fonctionner
la source