En una instancia de SQL Server 2014 con suficiente RAM y discos rápidos, hay más de 160 usuarios que tienen acceso a una base de datos. Por alguna razón que yo desconozco, ejecutar el comando DROP USER [username]
en esta base de datos toma hasta 5 segundos por usuario.
La reasignación de usuarios a los inicios de sesión y la restauración de sus permisos es muy rápida.
Dentro del contexto de actualizar las bases de datos DEV desde la producción, tengo que eliminar y volver a crear todos los usuarios de la base de datos. Entonces sí, es necesario eliminar los usuarios de la base de datos y recrearlos.
¿Cómo acelerar el DROP USER
comando?
Recuerde, tengo que ejecutarlo más de 160 veces para la instancia sobre la que estoy escribiendo.
Este es el SQL que estoy usando:
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
El problema no viene del cursor; Es lo real lo DROP USER
que toma hasta 5 segundos.
Usando sp_whoisactive
, el wait_type es NULL
.
No preste atención a la duración, la DROP
y CREATE USER
se ejecutan en un WHILE
bucle, por lo que dice más de un minuto.
Profiler muestra más de 125,000 lecturas para ejecutar DROP USER
.
Service Broker no está habilitado.
fuente
Respuestas:
La solución a este problema fue habilitar el agente de servicio en la base de datos como tal.
Después de habilitar el intermediario de servicios para la base de datos, los usuarios descartados fueron prácticamente instantáneos.
Kin preguntó si el agente de servicio estaba habilitado en un comentario anterior que me envió a buscar en la dirección correcta.
fuente
Esta no es una respuesta a la pregunta, sino un argumento para descartarla por completo.
Si entiendo correctamente tu comentario:
su objetivo es copiar datos de producción en un sistema de desarrollo y hacer que funcione con el mismo permiso que el de producción, utilizando los mismos nombres de usuario .
La ruta más rápida es clonar inicios de sesión sql desde el sistema de producción al sistema de desarrollo utilizando el procedimiento descrito por ms en este artículo de kb .
con el procedimiento definido por ms, el resultado es que puede restaurar las bases de datos en su servidor de desarrollo y el permiso funciona sin cambios.
Utilicé con éxito el procedimiento mencionado anteriormente para copiar un entorno de producción sql 2005 en entornos de prueba y desarrollo sql 2012.
Después de clonar a los usuarios, una simple restauración de la base de datos me llevó a un par de sistemas nuevos totalmente operativos con datos actualizados.
La gran ventaja de esa solución es que para actualizar los datos de desarrollo simplemente restaura la base de datos de producción y listo; tendrá que ajustar referencias, sinónimos y demás, pero los permisos no se romperán.
Aquí está el código del artículo, solo como referencia, pero consulte el artículo que tiene comentarios y detalles sobre la compatibilidad con versiones antiguas de SQL, detalles de cifrado de contraseña y otra información que puede ahorrarle un poco de dolor de cabeza al transferir los inicios de sesión a través de los servidores:
fuente
Un cursor similar a este debería funcionar
fuente