La majorité du temps… Non! Elles se connectent sur un serveur et un port, retourné la plupart du temps par le Browser SQL Server dans le cas d’une instance nommée.
Il n’est pas rare de voir l’utilisation de CNames pour référencer un serveur spécifique pour une application. Un nom logique pour gagner la flexibilité de changer de serveur facilement en déplacant le pointeur du CName.
C’est bien mais… On traine malheureusement toujours le nom de l’instance ou le port de l’instance comme un boulet dans la configuration de l’application.

Reformulons maintenant ceci:

Elles se connectent sur un serveur et un port, retourné la plupart du temps par le Browser SQL Server dans le cas d’une instance nommée.

comme ceci:

Elles se connectent sur une combinaison adresse IP/Port (un socket), par défaut sur le port 1433, ou questionnent le browser pour connaitre le port de l’instance si 1433 ne répond pas ou si l’on a une instance nommée.

Cette reformulation prend du sens si l’on considère qu’un serveur peut répondre à 1 ou N adresses IP et qu’une instance SQL peut être configurée pour écouter sur une ou plusieures adresses IP/Port également.
Voici donc comment se débarrasser du nom de l’instance dans les chaines de connection des applications en quelques étapes:
– Demandez, par instance SQL Serveur, une IP dédiée (Voyez avec votre admin network!)
– Ajoutez l’IP dédiée à votre instance SQL aux propriétés IP de la carte réseau de votre serveur. (Control Panel -> Network and Internet -> Network and Sharing Center -> Local Area Connection -> Properties -> Internet Protocol Version 4 (TCP/IPv4) -> Properties -> Advanced -> Add)

– Configurer les propriétés TCP/IP de votre instance SQL via SQL Server Configuration Manager:
Listen All -> No
IP 1: Active Yes, Enabled Yes, IP address – l’adresse IP dédiée pour votre instance, TCP Dynamic Port Rien, TCP Port 1433


– Créez un a-record pointant vers votre adresse IP dédiée.
– Utilisz ce a-record dans vos applications pour vous connecter à votre instance.

Voila, le tour est joué.
Si vous souhaitez déplacer une base de données d’une instance à une autre pour une application en particulier (i.e: server1\instance1 vers server2\instance2), changez uniquement la reférence du a-record pour pointer vers l’IP de la nouvelle instance, plus besoin de modifier le nom de l’instance ou le port de celle-ci dans la connection string de votre application.
C’est un peu comme créer de simuler des instances par défaut avec des instances nommées.

D’un point de vue administration, vous pouvez toujours avoir des instances nommées et continuer comme avant

Outre le fait d’utiliser un alias DNS ou un trick du genre référencer le nom du serveur par 127.0.0.1, il est possible de contourner cette limitation.

Il suffit de modifier la stored procedure [msdb].[dbo].[sp_sysmanagement_add_shared_registered_server] comme ceci:

USE [msdb]
GO
/****** Object:  StoredProcedure [dbo].[sp_sysmanagement_add_shared_registered_server]    Script Date: 1/30/2012 7:18:04 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[sp_sysmanagement_add_shared_registered_server]
    @name sysname,
    @server_group_id INT,
    @server_name sysname,
    @description NVARCHAR(2048) = N'',
    @server_type INT,
    @server_id INT OUTPUT
AS
BEGIN
    DECLARE @retval INT
 
    EXECUTE @retval = sp_sysmanagement_verify_shared_server_type @server_type
 
    IF (@retval <> 0)
        RETURN(1) -- Failure
     
    IF( (@server_group_id IS NULL) OR  
        (@server_group_id NOT IN (SELECT sg.server_group_id FROM msdb.dbo.sysmanagement_shared_server_groups_internal sg)))
    BEGIN
        RAISERROR (35001, -1, -1)
        RETURN (1)
    END
 
    IF EXISTS (SELECT * FROM [msdb].[dbo].[sysmanagement_shared_server_groups_internal]  sg  
                WHERE @server_group_id = sg.server_group_id AND @server_type <> sg.server_type)
    BEGIN
        RAISERROR (35002, -1, -1)
        RETURN (1)
    END    
 
    IF (@server_name IS NULL)
    BEGIN
        RAISERROR(14618, -1, 1, '@server_name')
        RETURN(1)    
    END
 
    set @server_name = LTRIM(@server_name)
    set @server_name = RTRIM(@server_name)
 
    -- Disallow relative names
    IF ('.' = @server_name) OR
        (1 = CHARINDEX(N'.\', @server_name)) OR
        (1 = CHARINDEX(N'LOCALHOST\', UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS))) OR
        (UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS) = 'LOCALHOST') OR
        (UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS) = '(LOCAL)')
    BEGIN
        RAISERROR (35011, -1, -1)
        RETURN (1)
    END
 
    -- Autorize to register the CMS instance
    --IF (UPPER(@@SERVERNAME collate SQL_Latin1_General_CP1_CS_AS) = UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS))
    --BEGIN
    --    RAISERROR (35012, -1, -1)
    --    RETURN (1)
    --END
 
    INSERT INTO [msdb].[dbo].[sysmanagement_shared_registered_servers_internal]
        (server_group_id, name, server_name, description, server_type)
    VALUES
        (@server_group_id, @name, @server_name, @description, @server_type)
         
    SELECT @server_id = SCOPE_IDENTITY()
    RETURN (0)
END

Vous remarquerez que le bout de code suivant a été commenté:

    -- Autorize to register the CMS instance
    --IF (UPPER(@@SERVERNAME collate SQL_Latin1_General_CP1_CS_AS) = UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS))
    --BEGIN
    --    RAISERROR (35012, -1, -1)
    --    RETURN (1)
    --END

Je ne garanti en aucun cas les potentiels effets de bord pouvant survenir.
Encore une fois la règle est de tester!

Si vous optez pour cette solution, pensez aussi à mettre à jour la procédure suivante, celle d’update d’un serveur avec le code ci-dessous:

USE [msdb]
GO
/****** Object:  StoredProcedure [dbo].[sp_sysmanagement_update_shared_registered_server]    Script Date: 1/31/2012 9:02:06 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER PROCEDURE [dbo].[sp_sysmanagement_update_shared_registered_server]
    @server_id INT,
    @server_name sysname = NULL,
    @description NVARCHAR(2048) = NULL
AS
BEGIN
    IF (@server_id IS NULL)
    BEGIN
        RAISERROR (35006, -1, -1)
        RETURN(1)
    END
     
    IF NOT EXISTS (SELECT * FROM [msdb].[dbo].[sysmanagement_shared_registered_servers_internal] WHERE server_id = @server_id)
    BEGIN
        RAISERROR (35007, -1, -1)
        RETURN(1)
    END
 
    IF (@server_name IS NULL)
    BEGIN
        SET @server_name = (select server_name FROM [msdb].[dbo].[sysmanagement_shared_registered_servers_internal] WHERE server_id = @server_id)
    END
 
    set @server_name = LTRIM(@server_name)
    set @server_name = RTRIM(@server_name)
 
    -- Disallow relative names
    IF ('.' = @server_name) OR
        (1 = CHARINDEX(N'.\', @server_name)) OR
        (1 = CHARINDEX(N'LOCALHOST\', UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS))) OR
        (UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS) = 'LOCALHOST') OR
        (UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS) = '(LOCAL)')
    BEGIN
        RAISERROR (35011, -1, -1)
        RETURN (1)
    END
 
    --IF (UPPER(@@SERVERNAME collate SQL_Latin1_General_CP1_CS_AS) = UPPER(@server_name collate SQL_Latin1_General_CP1_CS_AS))
    --BEGIN
    --    RAISERROR (35012, -1, -1)
    --    RETURN (1)
    --END
 
    UPDATE [msdb].[dbo].[sysmanagement_shared_registered_servers_internal]
        SET server_name = ISNULL(@server_name, server_name),
            description = ISNULL(@description, description)
    WHERE
        server_id = @server_id
    RETURN (0)
END

Bon hack,
Dje

Trouvant la méthode assez compliquée par rapport à ce qu’il est réalisable au niveau du GUI, je me suis posé la question « Comment automatiser ce que le GUI fait ? ».

Premier reflexe: SQL Profiler… Caramba! On ne voit rien passer.

Second reflexe (toujours moins naturel celui-la): Powershell !

Pre-requis:
La session powershell doit être ouverte sur le serveur ou le CMS tourne – ou en utilisant du remote powershell (pas teste).
Le snappin/module (2008/2012) sqlps doit être chargé.

En regardant un peu la documentation, on peut remarquer que sqlps, au travers du provider SqlServer, permet de naviguer au travers des serveurs enregistrés.

#Liste des providers
Get-PSProvider
#Liste des "folders" du provider SQLSERVER
set-location SQLSERVER:
ls

Pour naviguer on fera comme pour naviguer dans une arborescence de file system:

cd .\SQLRegistration #Serveurs enregistrés
cd '.\Central Management Server Group' #CMS (cd pouvez taper cd <tab> et powershell completera la ligne pour vous)
cd .\%2E%5CSQL11 #le nom de mon CMS qui est literalement .\SQL11 - Vive le trick ci-dessus (cd <tab>) pour retrouver le bon nom ;)
ls #presente la liste de serveurs/groupes presents à la racine du CMS

Maintenant regardons les méthodes existantes pour l’objet dans lequel nous nous trouvons ainsi que de quelle classe est cet objet (si vous débutez avec le powershell et que ceci vous semble bizarre… C’est normal … Ou pas… En tout cas c’est l’effet que ca m’a fait ^^):

Get-Item . | Get-Member

On peut voir que le nom de la classe (TypeName) de l’objet est Microsoft.SqlServer.Management.RegisteredServers.ServerGroup et une méthode appelée export!

C’est cette methode qui va nous servir à réaliser l’export.

Voici le script permettant de réaliser cet export (n’oubliez pas les pré-requis! et pensez à changer les valeurs des variables ;)):

$CMSPath = 'SQLSERVER:\SQLRegistration\Central Management Server Group\%2E%5CSQL11' #Location of the Central Management server to be exported
$exportFile = 'C:\Powershell\CMS\cms.xml' #Path of the export file
 
set-location $CMSPath
(get-item .).export($exportFile, 'None')

Maintenant, pour l’import, même principe en utilisant cette fois ci la méthode… import … Je suis sur que vous l’aviez déjà deviné ;):

$CMSPath = 'SQLSERVER:\SQLRegistration\Central Management Server Group\%2E%5CSQL11' #Location of the Central Management server where to import
$importFile = 'C:\Powershell\CMS\cms.xml' #Path of the file to import
 
set-location $CMSPath
(get-item .).import($importFile)

Voila !

Complétez les différentes informations:
Le crédential name sera le nom de votre crédential – Vous pouvez ici définir ce que vous voulez
Le champ identiy correspond au compte que vous souhaitez utiliser au format (domaine\username)
Le mot de passe correspond au mot de passe du compte défini au niveau du champ identity
Cliquez ensuite sur OK

Voici votre nouveau credential de créé:

Maintenant que vous avez un credential tout frais prêt à être utilisé, déployez l’agent SQL Serveur et faites un clic droit sur Proxies -> new proxy:

Complétez le formulaire de la manière suivante:
Proxy name sera le nom de votre proxy – Vous pouvez ici définir ce que vous voulez
Crédential name est le nom logique de votre crédential précedemment créé
Cochez la case SQL Server Integration Service Package – cela spécifie que votre proxy est autorisé à exécuter des pacakages SSIS. Vous pourriez faire de même pour exécuter des commandes OS en cochant Operating System (CmdExec)
Cliquez sur OK

Maintenant que vous avez un proxy créé, mappé sur un credential, il reste à définir au niveau de l’étape de votre job SQL Serveur exécutant votre package SSIS que cette étape doit être réalisée en utilisant ce proxy:
Ouvrez votre job
Ouvrez le step de cotre job exécutant le package SSIS
Au niveau du champ « Run as », sélectionnez votre proxy
Cliquez OK

Et voilà, le tour est joué!

On peut l’étendre facilement pour l’utiliser sur un serveur distant l’autorisant grace au paramètre -ComputerName de l’alias gwmi:
(Au passage un peu de cosmétique pour spécifier la mesure des volumes et une petite information intéressante, la taille du block de disque)

Allons un peu plus loin et faisons maintenant la meme chose, sur un ensemble de serveurs listés dans un fichier:
Au passage, un petit filtre pour ne prendre que les disques durs locaux.

Continuons un peu le chemin, ca devient dur de s’imaginer lire toute une console du listing des volumes de tous nos serveurs:
Ajoutons un fichier de sortie nommer comme avec le nom du serveur au format .csv:

Terminons avec un bout de code a sauvegarder dans un fichier de type .ps1 auquel on peut passer 2 arguments: le nom du fichier de serveur et le path de sortie:

Soit le fichier VolumeInfoOutFileParam.ps1, l’appel se fait de la manière suivante:

Que faire avec cela ?

Voici 2 exemples:

Exporter le résultat d’une query dans un fichier csv:

Invoke-Sqlcmd -ServerInstance "WIN-QDRSKD4G3GP\SQL11" -Database Volume -Query "select * from volumetest" | export-csv "c:\temp\extract_ps.csv"
Ce que j’apprécie grandement, c’est la simplicité d’écriture.
Ce bout de code peut être placé tel quel dans le step d’un job de l’agent SQL Server (de type PowerShell) et être exécuté sans problème.

Ci-dessous un extrait du fichier généré:

#TYPE System.Data.DataRow
« id », »UniqueID »
« 1 », »9ea1edd1-0163-43c8-a12c-036329425f3f »
« 2 », »1b30db32-bf16-4eb6-9cb5-52abfde676d9″
« 3 », »cb568ce5-a853-48f2-95a5-63b84da0e137″

Vous remarquerez la première ligne, mentionnant le type de l’objet ayant ete exporté. Cela provient de la fonction export-xml qui permet de typer les objets exportés permettant par la suite de les réimporter tout en conservant les propriétés de l’objet source.
La seconde étant le nom des colonnes de la table exportée.
Et ensuite les différentes lignes exportées au format .csv.

Coté performances par contre il ne faut pas être pressé malheureusement!!!
Rien à voir avec BCP!
Voici la comparaison de vitesse pour une extraction via BCP et utilisant Invoke-Sqlcmd pour un volume de plus ou moins 150Mo:

On ne l’utilisera donc pas pour des exports massifs au quotidien si l’on souhaite de la vitesse.
Par contre pour un export one shot vite fait, si la volumétrie n’est pas trop importante, pourquoi pas!
Passons à l’exemple suivant..

Utiliser la commande dans un script:

Dans les billets précédents, je regardais comment extraire les informations des volumes de serveurs en se servant du powershell et de WMI.
Je me suis posé la question – et si la liste de serveurs provenait d’une table ?
Et voici la réponse:

La dessus, j’ouvre SSMS et j’effectue un petit test (le code ci-dessous n’est pas l’original ;)):

– Ah ben oui ! Tu as raison. Tu viens de casser un mythe, j’y croyais dur comme fer!

Comme on peut le voir ci-dessus, un full backup effectué sans l’option with copy_only ne casse pas une chaine de transaction log backup.
On remarquera qu’un backup du transaction log avec l’option with copy_only non plus.

Par contre, un transaction log backup effectué et manquant (restore session 3 – le fichier c:\temp\test.trn4) provoque bien une rupture de la chaine.
L’erreur générée étant:
Msg 4305, Level 16, State 1, Line 10
The log in this backup set begins at LSN **********************, which is too recent to apply to the database. An earlier log backup that includes LSN **********************, can be restored.
Msg 3013, Level 16, State 1, Line 10
RESTORE DATABASE is terminating abnormally.

On remarquera aussi que le fait de switcher le recovery modele de la base de données en simple puis de le repasser en full rompt également la chaine des transaction logs backup.
L’erreur étant maintenant différente:
Msg 4312, Level 16, State 1, Line 11
This log cannot be restored because a gap in the log chain was created. Use more recent data backups to bridge the gap.
Msg 3013, Level 16, State 1, Line 11
RESTORE DATABASE is terminating abnormally.

I want to share here 2 exemples I will definitively use:

Defining a Sharepoint Service account role which include both security administrator role and dbcreator role:

Defining a profiler user role:

I’m pretty sure there’s a bunch of other roles which can be usefull, like a linked server manager role, and I’m glad to see this new feature available!

Pour ce faire nous allons tout d’abord nous servir de la commande getsid dans une fenetre CMD comme ceci:
getsid \\ServerName (AD)Group/User \\ServerName (AD)User/Group
Exemple: getsid \\Server1 GroupeDeveloppeur \\Server1 UtilisateurX

Cette commande va retourner le SID attribue sur le Server1 pour le groupe GroupeDeveloppeur et l’utilisateur UtilisateurX.

La definition des permissions sur les journaux d’evenement se fait au niveau de la registry de windows, au niveau de la clef:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\{LogName} -> customSD
Ou LogName est le nom du fichier log sur lequel on veut attribuer des permissions specifiques.

On va ajouter a la valeur contenue dans customSD la chaine suivante:
({TypePermission};;{Acces};;;{SID})
Ou:
{TypePermission} est soit A pour autoriser soit D pour refuser l’acces.
{Acces} est la valeur en hexadecimal des acces que l’on souhaite autoriser ou refuser bases sur les valeurs suivantes:
1 – Lecture
2 – Ecriture
4 – Effacement.

Soit pour autoriser l’acces en lecture a l’utilisateur ayant un SID de 1-2-3456 pour le journal MonJournal, on va aller dans la base de registre au niveau de la clef HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\MonJournal et rajouter a la valeur de CustomSD:
(A;;0x1;;;1-2-3456)