INTRODUCCION.- 

Muchas veces nos hemos encontrado cuando desarrollamos procedimientos almacenados la necesidad de poder crear una versión de uno previamente creado.

A la hora de versionar un procedimiento almacenado nos encontramos con diferentes problemas, como por ejemplo:

• Cómo normalizar y/o escribir el nombre de estas versiones V1, V2, fecha y un largo etcetera, por ejemplo, spCargaCliente, spCargaClienteV1.
 
• También existen otros problemas añadidos a la hora de hacer los scripts de creación de la base de datos donde tenemos, para mantener un seguimiento de los mismos, que seleccionar uno a uno todos los procedimientos almacenados con sus diferentes versiones.

PEQUEÑO TRUCO.-

Vamos a establecer un ejemplo, de cómo, SQL SERVER puede ayudarnos a organizarlos y cómo puede a la hora de crear el script sólo ver un procedimiento almacenado con sus diferentes versiones.

Lo primero vamos a crear un procedimiento almacenado simple:

CREATE PROCEDURE [dbo].[spVersion]
AS
BEGIN
    SELECT 'v1'
END

Si ejecutamos el procedimiento almacenado, por ejemplo, EXEC spVersion obtenemos el valor v1.

Ahora crearemos otro procedimiento con el mismo nombre pero esta vez vamos a añadir al nombre el signo ; y un número de versión, por ejemplo, el  (Inicialmente la versión 1 ya está reservada para la primera definición del procedimiento ).

CREATE PROCEDURE [dbo].[spVersion];2
AS
BEGIN
    SET NOCOUNT ON;

   SELECT 'v2'
END

Si ejecutamos el procedimiento EXEC spVersion volvemos a obtener el valor ‘v1’ y si ejecutamos el procedimiento EXEC spVersion;2 obtenemos el valor ‘v2’.

Si abrimos el SQL SERVER Management Studio y expandimos los procedimientos almacenados, vemos que sólo existe un procedimiento almacenado.

Y si accedemos a su definición veremos el siguiente resultado.

Lo cual nos permite ir realizando los diferentes versionados del procedimiento almacenado.

José Manuel Jurado Diaz.

Ingeniero de Soporte de SQL SERVER

Supongamos que nos encontramos en la siguiente situación:

En nuestro entorno tenemos montado Log shipping. Estamos utilizando logins de SQL Server, por lo que podemos tener usuarios huérfanos.

Queremos corregir este problema, pero no queremos romper el log shipping. ¿Qué podemos hacer?

Primero, vamos a entender que es un usuario de base de datos, que es un login, como se genera un usuario huérfano, y cuál es la relación entre un usuario de BD y un login:

¿Qué es un login?

Un login es una entidad que accede a la instancia de SQL Server. Esto puede ser un usuario de dominio, un usuario local del sistema, o un usuario de SQL Server. Con esto, podremos entrar a nivel de instancia, aunque no necesariamente a ninguna BD que este dentro de esta instancia.

Para acceder a una BD, tendremos que ser parte de alguno de los roles que otorgan acceso a las BD, o bien tener un usuario de BD mapeado a nuestro login.

¿Qué es un usuario de BD?

Un usuario de BD es la entidad que trabajara a nivel de BD, que puede tener ciertos privilegios a ciertos objetos dentro de esta misma BD.

¿Cuál es la posible relación entre un usuario de BD y un login?

Cuando se relacionan login y usuario, lo hacen a través de un identificador único, el SID. Este SID puede ser generado a nivel de dominio, a nivel de máquina, o bien a nivel de instancia.

Podréis encontrar más información en la siguiente URL:

http://msdn.microsoft.com/es-es/library/ms181127.aspx

Una vez visto esto, vamos a comprobar si tenemos usuarios huérfanos entre las instancias que trabajan en el logshipping:

Primero, comprobamos que en la instancia principal, nuestro Login “Orphaned”, tiene mapeado el usuario de BD:

Y comprobamos que el SID que une al usuario de BD “test”, y al login “Orphaned” es el mismo:

Por lo que, debido a cómo funciona “Log Shipping”, en la BD secundaria, tendremos este mismo SID asociado a nuestro usuario de BD, pero, nuestro login tendrá un diferente SID:

Es decir, que si rompemos el logshipping, veremos que nuestro login “Orphaned” no tendrá acceso a la BD “LogShipping_test”.

Si intento entrar con el login “Orphaned” dentro de la BD recién recuperada, recibiré el siguiente error:

Posibles soluciones para no romper el LogShipping:

Crear el login en la instancia secundaria con el mismo SID que la primaria, añadiendo la cláusula “SID”, y poniendo el mismo SID que el login de la instancia primaria:

En esta pantalla podemos observar que el login “Orphaned” ya tiene acceso a nuestra BD.

Esto es muy útil si, por cualquier razón, no podemos modificar el usuario de BD. Aunque, al borrar el login, cuando lo creemos, tendremos que darle todos los permisos que tuviese antes a nivel de instancia, y corregir cualquier otro mapeo de usuario que tenga.

Si pudiéramos modificar la BD, podremos lanzar el siguiente comando:

USE <database_name>;

GO

sp_change_users_login @Action='update_one', @UserNamePattern='<database_user>',

@LoginName='<login_name>';

GO

Un poco mas de información:

http://msdn.microsoft.com/es-es/library/ms175475(v=sql.105).aspx

Moisés Romero Senosiain – Microsoft Customer Support Services