Dado el sistema de seguridad que utiliza SQL Server, en el que un inicio de sesión a nivel de instancia está enlazado con un usuario de base de datos para cada base de datos a las que el inicio de sesión necesita acceder,  es común que cuando movemos o copiamos bases de datos entre instancias nos encontremos con usuarios huérfanos. Internamente SQL Server trabaja con un SID de inicio de sesión, por lo que crear un inicio de sesión con el mismo nombre en la instancia de destino no es la solución.  ¿Cómo lo resolvemos?

En el caso de que se trata de inicio de sesión de SQL, disponemos de un procedimiento almacenado que nos permitirá realizar esa operación sp_change_users_login. En el siguiente ejemplo, obtendremos un informe de los usuarios huérfanos:

EXEC sp_change_users_login 'Report'

Después podemos utilizar la opción ‘Auto_Fix’ para que resuelve esos usuarios huérfanos, asociándolos a un inicio de sesión con el mismo nombre o creando un nuevo inicio de sesión si es necesario, como muestra el siguiente ejemplo:

EXEC sp_change_users_login 'Auto_Fix', 'test', NULL, 'Pa$$w0rd'

En el caso de que estemos trabajando con Inicios de Sesión de Windows, no podremos utilizar este procedimiento. Si esos inicios de sesión no existen podemos importarlos de la instancia inicial, tal y como indica el artículo de mi anterior post. En caso de que ya existan, tenemos dos opciones. La buena es que los SID correspondan en ambos servidores. Si eso es así, no tendremos usuarios huérfanos. El problema lo tendremos en el caso de que los logins existan con un SID diferente. Eso lo dejaremos para el siguiente post.

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

You May Also Like

Carga de Slowly Changing Dimensions y tabla de Hechos con atributos de Tipo 2 (Parte 2 de 3)

Este es el segundo post de la serie en el que explicaremos como cargar nuestra tabla de Hechos a partir de una dimensión con atributos de Tipo 2, usando dos maneras diferentes, una de ellas será mediante un componente “Look Up” con caché parcial y la otra opción será usando un componente “Merge Join” con un “Conditional Split” para seleccionar el registro que se encuentra en el rango de fechas correcto. Para mas información sobre qué es un atributo de Tipo 2 y sobre como cargar la dimensión que usaremos en este ejemplo puedes consultar el primer post de la serie.