web-dev-qa-db-fra.com

Spécifiez la connexion dans la requête de gestion Studio T-SQL

Lorsque l'ajout d'utilisateurs sont des rôles aux serveurs DB, j'utilise souvent la fonction "script cette action" de l'interface graphique. Je passe ensuite à "Connexion :: Changer de connexion" pour faire la même chose sur mes autres serveurs.

Y a-t-il une façon de spécifier la connexion dans l'action scriptée afin que je n'ai pas à faire cette deuxième étape de changement de changement?

sql-server-2008ssms
9
Kyle Brandt

Aucun moyen de le faire dans le cadre d'un script de SSMS, mais vous avez deux options.

Une chose que vous pouvez faire est d'utiliser le mode SQLCMD et la commande :: Connect pour avoir un script qui se connecte à plusieurs serveurs et exécutera le script. Cela fonctionne bien si vous enregistrez le script pour l'utilisateur et utilisez la commande: R pour charger le script à partir d'un fichier.

Une autre chose que vous pouvez faire est de configurer un serveur de gestion central, puis d'exécuter votre script contre plusieurs serveurs à la fois.

12
SQLRockstar

En réalité, il est possible de se situer à partir de T-SQL, mais vous devez rencontrer un certain ensemble de conditions et de jumpt à travers quelques cerceaux.

  • Premièrement, vous devez activer les requêtes distantes (OpenDatasource/OpenRowset) sur le serveur à partir de laquelle les requêtes seront exécutées.
  • Deuxièmement, vous devez vous assurer que les serveurs cibles ont un accès à distance activé.
  • Troisièmement, vous devrez utiliser une forte utilisation de SQL dynamique de sorte que vous puissiez "injecter" le code T-SQL dans le moteur de base de données du serveur cible à exécuter.

Voici un exemple de script qui vous permettra de tirer parti de la CMS d'automatiser les tâches 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.
2
Dave

Non. Seule la base de données par USE Database. Une connexion n'est pas scriptable.

SSMS 2008 (?) Et d'autres outils offrent la possibilité de "exécuter plusieurs serveurs". Désolé, je n'utilise pas cette fonctionnalité dans mon rôle actuel, je n'ai donc pas ce problème.

1
gbn