Especificar conexión en Management Studio T-SQL Query


9

Cuando agrego usuarios son roles a servidores de base de datos, a menudo uso la función "Script this action" de la GUI. Luego solo voy a "Conexión :: Cambiar conexión" para hacer lo mismo en mis otros servidores.

¿Hay alguna forma de especificar la conexión en la acción programada para que no tenga que hacer ese segundo paso Cambiar conexión?

Respuestas:


12

No hay forma de hacer esto como parte de un script desde SSMS, pero tiene dos opciones.

Una cosa que puede hacer es usar el modo SQLCMD y el comando :: connect para tener un script que se conectará a múltiples servidores y ejecutará el script. Esto funciona bien si guarda el script para el usuario y usa el comando: r para cargar el script desde un archivo.

Otra cosa que puede hacer es configurar un Servidor de administración central y luego ejecutar su script en varios servidores a la vez.


1
"Servidor de administración central". ah, eso es lo que no uso actualmente ...
gbn

Sí, es una joya escondida para cosas como esta, mucho mejor que los scripts SQLCMD.
SQLRockstar

2

En realidad, es posible desde T-SQL, pero debe cumplir con un cierto conjunto de condiciones y saltar algunos obstáculos.

  • Primero, debe habilitar las consultas remotas (OPENDATASOURCE / OPENROWSET) en el servidor desde el que se ejecutarán las consultas.
  • En segundo lugar, debe asegurarse de que los servidores de destino tengan habilitado el acceso remoto.
  • En tercer lugar, deberá hacer un uso intensivo del SQL dinámico para poder "inyectar" código T-SQL en el motor de la base de datos del servidor de destino que se ejecutará.

Aquí hay un script de muestra que le permitirá aprovechar el CMS para automatizar las tareas de SQL.

/**********************************************************************/

/* Global change password script                                      */

/*                                                                    */

/* This script changes the password for a SQL login on all servers    */

/* managed by a Central Management Server. It assumes that the login  */

/* exists on all servers, and that all servers are SQL 2005 or later. */

/**********************************************************************/

DECLARE @nServer NVARCHAR (128) -- Variable to hold the instance name retrieved from the CMS

DECLARE @nSQL NVARCHAR (4000)   -- Variable to hold dynamic SQL

DECLARE @ServerFetch INT        -- Variable to hold the fetch status. In SQL 2005, the @@FETCH_STATUS

                                -- variable is scoped at the system level, so if another process is also

                                -- using a cursor the @@FETCH_STATUS variable will be set according to

                                -- that operation. This allows us to store a persistent value.


DECLARE curServer CURSOR LOCAL STATIC FOR  -- Declare the cursor with the LOCAL and STATIC options, and

                                           -- retrieve the list of server names from the Central Management

                                           -- Server. The value in the [sysmanagement_shared_server_groups_internal]

                                           -- table is user-defined; for purposes of this example we have

                                           -- created a group named "SQL2008".

    SELECT DISTINCT

    s.server_name AS 'ServerName'

    FROM OPENDATASOURCE ('SQLOLEDB', 'Data Source = CMS1\Management; Integrated Security = SSPI').msdb.dbo.sysmanagement_shared_server_groups_internal g

    INNER JOIN OPENDATASOURCE ('SQLOLEDB', 'Data Source = CMS1\Management; Integrated Security = SSPI').msdb.dbo.sysmanagement_shared_registered_servers_internal s ON g.server_group_id = s.server_group_id

    WHERE g.name = 'SQL2008'

    ORDER BY s.server_name

OPEN curServer

FETCH FIRST FROM curServer INTO @nServer       -- Retrieve the first row

SET @ServerFetch = @@FETCH_STATUS              -- Store the status of the fetch operation

WHILE @ServerFetch = 0                         -- If the fetch was successful, we enter the loop. Otherwise

                                               -- execution passes to the statement following the END statement.

    BEGIN

    -- Build the dynamic SQL to alter the password for the SQL login.

    SET @nSQL = 'EXEC OPENDATASOURCE (''SQLOLEDB'', ''Data Source = ' + @nServer

        + '; Integrated Security = SSPI'').master.dbo.sp_executesql N''ALTER LOGIN SQLLogin WITH PASSWORD = ''''<enterStrongPasswordHere>'''''

    -- Execute the dynamic SQL.

    EXEC sp_executesql @nSQL

    FETCH NEXT FROM curServer INTO @nServer    -- Retrieve the next row.

    SET @ServerFetch = @@FETCH_STATUS          -- Store the status of the fetch operation.

    END

CLOSE curServer        -- Close the cursor.

DEALLOCATE curServer   -- Remove the cursor from memory.

1

No. Solo la base de datos por USE Database. Una conexión no es programable.

SSMS 2008 (?) Y otras herramientas ofrecen la capacidad de "ejecutarse en múltiples servidores". Lo siento, no uso esta función en mi rol actual, así que no tengo este problema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.