David Barbarin » Architecture

AAD user creation on behalf AAD Service Principal with Azure SQL DB

mikedavem — Sun, 02 Aug 2020 22:28:06 +0000

An interesting improvement was announced by the SQL AAD team on Monday 27th July 2020 and concerns the support for Azure AD user creation on behalf of Azure AD Applications for Azure SQL as mentioned to this Microsoft blog post.

In my company, this is something we were looking for a while with our database refresh process in Azure. Before talking this new feature, let me share a brief history of different considerations we had for this DB refresh process over the time with different approaches we went through. First let’s precise DB Refresh includes usually at least two steps: restoring backup / copying database – you have both ways in Azure SQL Database – and realigning security context with specific users regarding your targeted environment (ACC / INT …). But the latter is not as trivial as you may expect if you opted to use either a SQL Login / User or a Service Principal to carry out this operation in your process. Indeed, in both cases creating an Azure AD User or Group is not supported, and if you try you will face this error message:

‘’ is not a valid login or you do not have permission.

All the stuff (either Azure automation runbook and PowerShell modules on-prem) done so far and described afterwards meets the same following process:

First, we used Invoke-SQCMD in Azure Automation runbook with T-SQL query to create a copy of a source database to the target server. T-SQL is mandatory in this case as per documented in the Microsoft BOL because PROD and ACC or INT servers are not on the same subscription. Here a simplified sample of code:

...
$CopyDBCMD = @{
'Database' = 'master'
'ServerInstance' = $TargetServerName
'Username' = $SQLUser
'Password' = $SQLPWD
'Query' = 'CREATE DATABASE '+ '[' + $DatabaseName + '] ' + 'AS COPY OF ' + '[' + $SourceServerName + '].[' + $DatabaseName + ']'
}

Invoke-Sqlcmd @CopyDBCMD
...

But as you likely know, Invoke-SQLCMD doesn’t support AAD authentication and because SQL Login authentication was the only option here, it led us dealing with an annoying issue about the security configuration step with AAD users or groups as you may imagine.

Then, because we based authentication mainly on trust architecture and our security rules require using it including apps with managed identities or service principals, we wanted also to introduce this concept to our database refresh process. Fortunately, service principals are supported with Azure SQL DBs since v12 with access token for authentication by ADALSQL. The corresponding DLL is required on your server or if you use it from Azure Automation like us, we added the ADAL.PS module but be aware it is now deprecated, and I advise you to strongly invest in moving to MSAL. Here a sample we used:

...
$response = Get-ADALToken `
-ClientId $clientId `
-ClientSecret $clientSecret `
-Resource $resourceUri `
-Authority $authorityUri `
-TenantId $tenantName

...

$connectionString = "Server=tcp:$SqlInstanceFQDN,1433;Initial Catalog=master;Persist Security Info=False;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;"
# Create the connection object
$connection = New-Object System.Data.SqlClient.SqlConnection($connectionString)
# Set AAD generated token to SQL connection token
$connection.AccessToken = $response.AccessToken

Try {
$connection.Open()
...
}
...

But again, even if the copy or restore steps are well managed, we still got stuck with security reconfiguration, because service principals were not supported for creating AAD users or groups so far …

In the meantime, we found out a temporary and interesting solution based on dbatools framework and the Invoke-dbaquery command which supports AAD authentication (Login + Password). As we may not rely on service principal in this case, using a dedicated AAD account was an acceptable tradeoff to manage all the database refresh process steps. But going through this way comes with some disadvantages because running Invoke-dbaquery in a full Azure automation mode is not possible with missing ADALsql.dll. Workaround may be to use hybrid-worker, but we didn’t want to add complexity to our current architecture only for this special case. Instead we decided to move the logic of the Azure automation runbook into on-prem PowerShell framework which already include logic for DB refresh for on-prem SQL Server instances.

Here a simplified sample of code we are using:

...
Try {
# Connect to get access to Key Vault info
Connect-AzAccount | Out-Null

[String]$user = (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-SQLBCKUSER").SecretValueText
[System.Security.SecureString]$pwd = ConvertTo-SecureString (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-SQLBCKPWD").SecretValueText -AsPlainText -Force
[String]$SourceServerName = (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-NAME").SecretValueText
[String]$TargetServerName = (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-TARGETNAME").SecretValueText + '.database.windows.net'

# DB Restore will be performed in the context of dedicated AAD account
$pscredential = New-Object -TypeName System.Management.Automation.PSCredential($user, $pwd)

Write-Host "Restoring DB:$DatabaseName from Source Server: $SourceServerName to Target Server: $TargetServerName"

$Query = "CREATE DATABASE [$DatabaseName] AS COPY OF [$SourceServerName].[$DatabaseName]"
Invoke-DbaQuery `
-SqlInstance $TargetServerName `
-Database master `
-SqlCredential $pscredential `
-Query $Query `
-EnableException

# Wait for DB online and ready ...
# Code should be implemented for this check

Write-Output "Applying security configuration to DB: $DatabaseName on Server:$TargetServerName"

$Query = "
DROP USER [az_sql_ro];CREATE USER [az_sql_ro] FROM EXTERNAL PROVIDER;
"
Invoke-DbaQuery `
-SqlInstance $TargetServerName `
-Database $DatabaseName `
-SqlCredential $pscredential `
-Query $Query `
-EnableException

}
Catch {
Write-Host "Error encountered: $($_.Exception.Message)"
}
...

Referring to the PowerShell code above, in the second step, we create an AAG group [az_sql_ro] on behalf of the AAD dedicated account with the CLAUSE FROM EXTERNAL PROVIDER.

Finally, with the latest news published by the SQL AAD team, we will likely consider using back service principal instead of dedicated Windows AAD account. This Microsoft blog post explains in details how it works and what you have to setup to make it work correctly. I don’t want to duplicate what is already explained so I will apply the new stuff to my context.

Referring to the above blog post, you need first to setup a server identity for your Azure SQL Server as below:

Set-AzSqlServer `
-ResourceGroupName sandox-rg `
-ServerName a-s-sql02 `
-AssignIdentity

# Check server identity
Get-AzSqlServer `
-ResourceGroupName sandox-rg `
-ServerName a-s-sql02 | `
Select-Object ServerName, Identity

ServerName Identity
---------- --------
a-s-sql02 Microsoft.Azure.Management.Sql.Models.ResourceIdentity

Let’s have a look at the server identity

# Get identity details
$identity = Get-AzSqlServer `
-ResourceGroupName sandox-rg `
-ServerName a-s-sql02

$identity.identity

PrincipalId Type TenantId
----------- ---- --------
7f0d16f7-b172-4c97-94d3-34f0f7ed93cf SystemAssigned 2fcd19a7-ab24-4aef-802b-6851ef5d1ed5

In fact, assigning a server identity means creating a system assigned managed identity in the Azure AD tenant that’s trusted by the subscription of the instance. To keep things simple, let’s say that System Managed Identity in Azure is like to Managed Account or Group Managed Account on-prem. Those identities are self-managed by the system. Then you need to grant this identity the Azure AD « Directory Readers « permission to get rights for creating AAD Users or Groups on behalf of this identity. A PowerShell script is provided by Microsoft here a sample of code I applied in my context for testing:

...
Try {
$DatabaseName = "test-DBA"

# Connect to get access to Key Vault info
Connect-AzAccount | Out-Null

[String]$user = (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-SQLBCKAPPID").SecretValueText
[System.Security.SecureString]$pwd = ConvertTo-SecureString (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-SQLBCKAPPSECRET").SecretValueText -AsPlainText -Force
[String]$SourceServerName = (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-NAME").SecretValueText
[String]$TargetServerName = (Get-AzKeyVaultSecret -VaultName $KeyvaultName -Name "AZSQL-TARGETNAME").SecretValueText + '.database.windows.net'

# DB Restore will be performed in the context of dedicated AAD account
$pscredential = New-Object -TypeName System.Management.Automation.PSCredential($user, $pwd)

$adalPath = "${env:ProgramFiles}\WindowsPowerShell\Modules\Az.Profile.7.0\PreloadAssemblies"
# To install the latest AzureRM.profile version execute -Install-Module -Name AzureRM.profile
$adal = "$adalPath\Microsoft.IdentityModel.Clients.ActiveDirectory.dll"
$adalforms = "$adalPath\Microsoft.IdentityModel.Clients.ActiveDirectory.WindowsForms.dll"
[System.Reflection.Assembly]::LoadFrom($adal) | Out-Null
$resourceAppIdURI = 'https://database.windows.net/'

# Set Authority to Azure AD Tenant
$authority = 'https://login.windows.net/' + $tenantId

$ClientCred = [Microsoft.IdentityModel.Clients.ActiveDirectory.ClientCredential]::new($clientId, $clientSecret)
$authContext = [Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext]::new($authority)
$authResult = $authContext.AcquireTokenAsync($resourceAppIdURI,$ClientCred)
$Tok = $authResult.Result.CreateAuthorizationHeader()
$Tok=$Tok.Replace("Bearer ","")

Write-host "Token generated is ..."
$Tok
Write-host ""

Write-Host "Create SQL connectionstring"
$conn = New-Object System.Data.SqlClient.SQLConnection

$conn.ConnectionString = "Data Source=$TargetServerName;Initial Catalog=master;Connect Timeout=30"
$conn.AccessToken = $Tok

Write-host "Connect to database and execute SQL script"
$conn.Open()

Write-Host "Check connected user ..."
$Query = "SELECT USER_NAME() AS [user_name];"
$command = New-Object -TypeName System.Data.SqlClient.SqlCommand($Query, $conn)
$Command.ExecuteScalar()
$conn.Close()

Write-Host "Restoring DB:$DatabaseName from Source Server: $SourceServerName to Target Server: $TargetServerName"

$conn.ConnectionString = "Data Source=$TargetServerName;Initial Catalog=master;Connect Timeout=30"
$conn.AccessToken = $Tok
$conn.Open()
$Query = "DROP DATABASE IF EXISTS [$DatabaseName]; CREATE DATABASE [$DatabaseName] AS COPY OF [$SourceServerName].[$DatabaseName]"
$command = New-Object -TypeName System.Data.SqlClient.SqlCommand($Query, $conn)
$command.CommandTimeout = 1200
$command.ExecuteNonQuery()
$conn.Close()

# Wait for DB online and ready ...
# Code should be implemented for this check

Write-Output "Applying security configuration to DB: $DatabaseName on Server:$TargetServerName"

$conn.ConnectionString = "Data Source=$TargetServerName;Initial Catalog=$DatabaseName;Connect Timeout=30"
$conn.AccessToken = $Tok
$conn.Open()
$Query = 'CREATE USER [az_sql_ro] FROM EXTERNAL PROVIDER;'
$command = New-Object -TypeName System.Data.SqlClient.SqlCommand($Query, $conn)
$command.ExecuteNonQuery()
$conn.Close()

}
Catch {
Write-Output "Error encountered: $($_.Exception.Message)"
}
...

Using service principal required few changes in my case. I now get credentials of the service principal (ClientId and Secret) from Azure Key Vault instead of the AAD dedicated account used in previous example. I also changed the way to connect to SQL Server by relying on ADALSQL to get the access token instead of using dbatools commands. Indeed, as far as I know, dbatools doesn’t support this authentication way (yet?).

The authentication process becomes as follows:

My first test seems to be relevant:

This improvement looks promise and may cover broader scenarios as the one I described in this blog post. This feature is in preview at the moment of this write-up and I hope to see it coming soon in GA as well as a potential support of preferred PowerShell framework DBAtools

See you!

Quand l’économie d’énergie dans le bios ne fait pas bon ménage avec les performances de SQL Server

mikedavem — Sun, 08 Jan 2012 18:40:07 +0000

Il y a quelques temps j’avais écrit un billet sur les power plans de Windows et l’impact que cela pouvait avoir sur SQL Server. Il y a quelques temps j’ai pu l’observer chez un de mes clients qui souffraient de problèmes de performances de requêtes après avoir acheté un nouveau serveur. Voici ce que nous avons pu voir en comparant deux configurations serveurs différentes.

Je précise que seule la configuration des processeurs nous intéresse ici car les performances des requêtes ne dépendaient pas d’un manque de mémoire (l’ensemble de la base tenait en mémoire avec 130Go de mémoire totale et 10Go de données) ou des performances disques. Les plans d’exécutions utilisés après analyse étaient strictement les mêmes. Cependant une différence au niveau du temps CPU a été relevé (après avoir utilisé les options de statistiques SET STATISTICS IO et SET STATISTICS TIME) Une requête de référence ayant été prise pour comparaison voici les résultats de temps d’exécution sur chaque serveur (en désactivant le parallélisme) :

Serveurs	Processeurs	Temps CPU requête
Serveur 1	Processeurs Intel Xeon X7460 @2.66GHz	12344 ms
Serveur 2	Processeurs Intel Xeon X7560 @2.27Ghz	21892 ms

En regardant sur le site du constructeur on peut vite remarquer qu’à priori les processeurs (Intel Xeon X7560) devraient donner des résultats au moins similaires aux processeurs (Intel X7460) voir plus (en utilisant l’outil de comparaison du site).

Le temps CPU multiplié pratiquement par deux m’a donc incité à utiliser l’outil CPU-Z pour voir les caractéristiques réelles des processeurs sur chaque serveur.

Sur le serveur 1 : Intel Xeon X7460 @ 2.66Ghz

Sur le serveur 2 : Intel Xeon X7560 @ 2.27Ghz

On remarque rapidement que la vitesse réelle des processeurs n’est pas celle annoncée sur les spécifications du constructeur pour le serveur 2. Le ratio est donc de 2.27Ghz / 1.064Ghz soit environ 2. Curieusement on observe le même ratio entre la vitesse des requêtes et la vitesse des processeurs. La modification des power plans pour les performances n’avait visiblement rien changé. Après avoir investigué dans le BIOS on a pu voir que les options d’économies étaient activés. Après avoir réglé ce souci nous nous sommes retrouvés sur des temps d’exécutions plus bas pour le serveur 2 (de l’ordre de 10 000 ms). Enjoy !!

David BARBARIN (Mikedavem)
MVP SQL Server

Locked pages in memory, Instant File Initialization et SID de service SQL

mikedavem — Thu, 17 Nov 2011 21:52:29 +0000

Locked pages in memory et Instant File Initialization sont deux options de performance utilisés fréquemment avec SQL Server. Pour rappel la première option d’empêcher la pagination du buffer pool de SQL Server par le système d’exploitation et la deuxième permet de réduire considérablement les temps d’allocation de fichier en supprimant la phase de remplissage de zéro des fichiers de bases de données. Ceci n’est valable uniquement que pour les fichiers de données SQL Server. Pour bénéficier de ces deux options de performances il faut octroyer au compte de service SQL Server les privilèges nécessaires. Cependant dans beaucoup de littérature et très certainement par habitude, c’est le compte de domaine utilisé par le service SQL qui bénéficie de ces privilèges dans la plupart des cas. Mais qu’en est-il avec l’apparition des SID de service ?

Avant la version 2008 de SQL Server on avait gère le choix entre pouvoir octroyer ces droits soit au compte de domaine ou au groupe prédéfini créé pendant l’installation d’une installation SQL Server de la forme SQLServerMSSQLUser$[servername]$MSSQLServer pour une instance par défaut. Dans le premier cas lorsque l’on change de compte utilisateur il faudra penser à paramétrer le nouveau compte utilisé avec les privilèges nécessaires. Dans l’autre cas cette gymnastique n’est plus nécessaire mais par définition l’ensemble des membres potentiels du groupe concerné pourront bénéficier de ce privilège. Cela peut être bien entendu problématique.

Depuis SQL Server 2008 (et Windows 2008) on a vu l’apparition des SID de services qui permettent de créer une identité propre de service. L’avantage bien entendu est qu’il est possible d’utiliser directement cet identifiant pour isoler les ressources utilisées par une instance SQL. Une autre utilisation moins répandue est d’octroyer les privilèges cités plus hauts directement à l’identité du service SQL d’une instance donnée.

Pour savoir si cela fonctionne nous avons selon l’option de performance des outils à disposition. Pour le verrouillage de page en mémoire il suffit d’utiliser la commande DBCC MEMORYSTATUS alors que pour Instant File Initialization on pourra utiliser les traces flag 3004 et 3605. L’activation de ces traces flag permettent de pouvoir lire les informations d’initialisation de fichier directement dans le journal d’erreur SQL.

Test 1 : compte de domaine utilisateur classique sans privilèges

Pour les pages verrouillés en mémoire :

Pour Instant File Initialization :

USE [master]
GO

CREATE DATABASE [TEST] ON PRIMARY
( NAME = N’TEST’, FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST.mdf’ , SIZE = 2048MB , MAXSIZE = UNLIMITED)
LOG ON
( NAME = N’TEST_log’, FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_log.LDF’ , SIZE = 100MB , MAXSIZE = 2048GB)
GO

L’idée ici est de créer une base de données et de visualiser ensuite les événements générés dans le journal d’erreur SQL. On peut voir avec l’activation des traces flag 3004 et 3605 dans les options de démarrage de démarrage du service SQL (-T3004; -T3605) les informations relatives à l’initialisation des fichiers et de leur remplissage par des 0 (Zeroing …). On constate que les 2 types de fichiers sont concernés dans ce premier cas.

Test 2 : paramétrage du SID de service SQL avec les privilèges nécessaires pour l’activation de nos 2 options de performances. Pour la prise en compte des deux options il faudra redémarrer l’instance SQL Server.

Pour le verrouillage de pages en mémoire :

On vérifie à nouveau avec DBCC MEMORYSTATUS :

Pour Instant File Initialization :

On recrée ensuite notre base de données avec le même script que précédemment :

USE [master]
GO

DROP DATABASE [TEST]
GO

CREATE DATABASE [TEST] ON PRIMARY
( NAME = N’TEST’, FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST.mdf’ , SIZE = 2048MB , MAXSIZE = UNLIMITED)
LOG ON
( NAME = N’TEST_log’, FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_log.LDF’ , SIZE = 100MB , MAXSIZE = 2048GB)
GO

Vous remarquerez au passage que le temps de création de la base a nettement diminué (du moins c’est le cas chez moi). On vérifie à nouveau dans le journal d’erreur SQL :

On constate cette fois que seul le fichier journal est concerné (ce qui est normal comme expliqué plus haut).

CQFD !!!

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Cluster : Comment paramétrer le nom des 2 nœuds en majuscule !

mikedavem — Wed, 21 Sep 2011 21:41:27 +0000

Ce post s’adresse surtout aux maniaques du travail bien fait . Lorsque l’on configure un cluster Windows il arrive bien souvent que le nom d’un des 2 noeuds soit en minuscule. Bien que cela n’ait pas d’incidence (enfin il y avait bien quelques cas où cela posait problème comme par exemple l’installation du service pack 3 de SQL Server 2005 en cluster) on peut vouloir avoir nos deux noms en majuscule dans la console de gestion du cluster.

Plaçons le décor :

Le nom du deuxième noeud est effectivement en minuscule. Pourtant après avoir ajouter plusieurs fois le nom du deuxième noeud en majuscule rien ne change !!

Avant :

Après :

Après avoir vérifié tout ce qu’il était possible de vérifier (entrée DNS, objet d’ordinateur, attributs de l’objet d’ordinateur etc …) le constat était le suivant : tous les noms associés au nom du deuxième noeud était bien en majuscule. Alors comment faire pour entrer le nom de ce dernier en majuscule ?

Il faut tout simplement entrer le nom par l’utilitaire en ligne de commande cluster.exe de la façon suivante :

> cluster.exe /cluster : [clustername] /addnode /node: [nodename]

Le résultat est le suivant :

Et voilà le travail !!

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server agent : Propriétaires de travaux, comptes de service et proxies

mikedavem — Thu, 15 Sep 2011 19:56:45 +0000

J’ai déjà eu plusieurs fois à répondre à la question suivante : Sous quel contexte utilisateur s’exécute un travail SQL Server ? Est ce qu’il utilise le compte de service du compte de l’agent ou bien le contexte de son propriétaire ?

La réponse est : cela dépend du contexte (cela aurait été trop facile sinon :D).

Prenons un exemple simple pour bien comprendre :

Un job SQL Server avec comme propriétaire un compte de connexion test_login sans privilèges particuliers. Le job en question est constitué de 2 étapes :

une étape TSQL avec la requête SELECT SYSTEM_USER
une étape de type cmdExec qui exécute un « dir E:\*.* »

On exécute le job et on peut faire le constat suivant :

Le job s’exécute dans le contexte du propriétaire du job (Executed as user:test_login). Cependant la 2ème étape est en erreur mais cela reste logique. En effet pour exécuter une commande de type cmdExec il faut soit faire partir du rôle sysadmin soit utiliser un compte de proxy qui est autorisé à exécuter une telle commande.

Nous allons donc dans ce 2ème test ajouter le compte de connexion test_user au rôle de serveur sysadmin et exécuter à nouveau notre job. Voici le résultat :

Cette fois-ci le job s’est exécuté sans problème mais le plus intéressant est le contexte qui a été utilisé ici. L’utilisateur concerné est en réalité le compte de service de l’agent SQL Server (TESTLLAB2\sql2k8svcaccount). Comme vous le savez sans doute ce compte de service est sysadmin sur l’instance SQL Server. Donc quand un compte de connexion est sysadmin c’est le compte de service de l’agent SQL qui est utilisé.

Bien entendu on ne peut pas élever les privilèges d’un compte de connexion uniquement pour qu’il puisse exécuter une commande de type cmdExec. Une bonne pratique est d’utiliser un compte de proxy associé à un credential qui sera autorisé à initier des ordres de type cmdExec. C’est ce que nous allons faire ici. Après exécution du job voici le résultat :

On peut remarquer que le contexte utilisé lors de la 1ère étape est bien celui attendu : test_login qui est, pour rappel, le propriétaire de notre job. Comme nous avons paramétré un compte de proxy (TESTLLAB2\proxycmdexec)pour l’exécution de la 2ème étape c’est le contexte de ce dernier qui est utilisé.

Voilà pour la démonstration !!

David BARBARIN (Mikedavem)
MVP SQL Server

SQL Server et Service SID

mikedavem — Mon, 22 Aug 2011 14:30:54 +0000

Le modèle de sécurité de SQL Server a évolué au cours des différentes versions. Chaque version de SQL Server a amené son lot de nouveautés en même temps que les versions de Windows sur lequel il repose. Avec la venue de Windows Vista, Seven ou Server 2008 il est apparu la notion de SID pour les services Windows. Depuis SQL Server 2008 il est possible d’utiliser cette fonctionnalité offerte par les nouvelles versions du système d’exploitation. Mais qu’est ce que un SID exactement ? A quoi cela peut bien servir ? Quels sont les avantages ?

Faisons tout d’abord un bon en arrière avec les version 2000 et 2005 de SQL Server. Avec SQL Server 2000 le paramétrage d’un compte de service pour SQL Server donnait lieu à la création d’un login SQL correspondant appartenant au rôle de serveur sysadmin. Les droits nécessaires sont octroyés comme Log On As A Service, Replace a Process-Level Token etc… mais ce n’est pas le cas des ACL des fichiers et dossiers. SQL Server 2005 apporte une réponse ce problème en introduisant des groupes prédéfinis créés lors de l’instance (SQLServer2005MSSQLUser$InstanceName pour le moteur SQL Server par exemple). Ces groupes permettent une administration beaucoup plus simple des comptes de services. Les ACL sont configurées directement pour les groupes concernés. Le compte de service concerné n’est plus qu’à être ajouté en tant que membre du groupe Windows adéquate.

Mais dans les deux cas, c’est le contexte de sécurité du compte ou du groupe Windows qui est utilisé, ce qui ne permet pas une isolation complète des ressources dédiés à une instance SQL Server. En effet imaginez qu’une instance SQL Server utilise un compte de service A et que plusieurs autres applications utilisent ce même compte de service A. Cela signifierait que ces dernières pourraient donc avoir accès aux ressources de notre instance SQL Server. Prenons un 2ème exemple où deux instances SQL Server cohabitent sur le même serveur. Si ces deux instances utilisent le même compte de service cela signifie qu’elles ont accès mutuellement à leurs ressources. Dans un contexte de sécurisation ce n’est pas vraiment ce que l’on veut.

Dans le schéma qui suit les flèches rouges représentent les accès potentiels non désirés. On voit ici que l’utilisation d’un même compte de domaine en tant que compte de service par différentes applications comme SQL Server ou des applications métiers peut vite engendrer des problèmes d’accès aux ressources. Chaque application peut avoir accès aux ressources des autres. Hors tout le monde le sait, beaucoup d’attaques se produisent par le biais des services Windows.

Comment régler ce problème ? Au final, nous voulons que seul le service d’une application ait accès à ses ressources. Nous ne voulons pas utiliser de contexte utilisateur mais un contexte « de service ». C’est ce que propose Microsoft à partir des versions Windows Vista, Seven ou Server 2008. Chaque service possède son propre (et unique) identifiant appelé SID. C’est cet identifiant qui sera directement utilisé pour paramétrer les différentes ACL des ressources concernées. L’avantage est ici est certain : on n’utilise plus l’identifiant du compte utilisateur mais l’identifiant du service pour avoir accès aux ressources. L’utilisation d’un compte utilisateur pour deux instances SQL Server ne posera plus de problème dans ce cas car au final c’est le SID des différents services SQL Server qui seront utilisés pour avoir accès aux ressources nécessaires. Il en va de même pour les services concernant le moteur SQL et l’agent SQL.

Sous SQL Server cela se traduit par l’appariation de deux comptes de connexion (pour une instance par défaut) :

NT SERVICE\MSSQLSERVER pour le moteur SQL
NT SERVICE\SQLSERVERAGENT pour l’agent SQL Server

Ces 2 comptes font parti du rôle de serveur sysadmin.

On retrouve notre SID dans les ACL (A noter aussi que l’on peut retrouver le groupe Windows SQLServer2005MSSQLUser créé par SQL Server lors de l’installation. Le SID fait automatiquement parti de ce groupe) :

Pour une instance nommée :

A noter que :

Il n’existe plus de compte de connexion associé aux groupes Windows du type SQLServerMSSQLUser$… alors que dans la version 2005 ceux-ci étaient présents et faisaient parti du rôle de serveur sysadmin
Tous les services qui concernent de près ou de loin SQL Server ne peuvent pas utiliser de SID. Par exemple avec SQL Server 2008 et 2008 R2 le service SQL Writer n’utilise pas de SID. Avec SQL Server Denali (CTP3) il semblerait que ceci ne soit plus vrai. On peut facilement le vérifier avec la commande suivante :

sc qsidtype [servicename]

La sortie de cette commande peut donner les résultats suivants :

None (0x0) – the service will not have a per-service SID. This is the default configuration for a service
Unrestricted (0x1) – the service has a per-service SID
Restricted (0x3) – the service has a per-service SID and a write-restricted token.

L’utilisation des SID pour les services SQL permettent une délimitation et une isolation beaucoup plus marquée des ressources propres à chaque instance SQL Server. Encore un grand pas en avant dans le domaine de la sécurité !

David BARBARIN (Mikedavem)
MVP SQL Server

Fragmentation des indexes et fragments : quesako ?

mikedavem — Mon, 25 Jul 2011 20:56:50 +0000

Pour ceux qui utilisent la DMV sys.dm_db_index_physical_stats depuis la version 2005 de SQL Server ont certainement vu une colonne nommée fragment_count. La documentation Microsoft nous donne la description suivante : Nombre de fragments dans le niveau feuille d’une unité d’allocation IN_ROW_DATA. J’ai déjà eu pas mal de questions à ce sujet car même avec la description fournie nous pouvons avoir du mal à visualiser ce que cette colonne représente exactement et quelle peut être la relation avec la fragmentation des indexes.

Tout d’abord une définition : un fragment est en réalité une séquence de pages physique contigüe. Un index possède au minimum un fragment et il peut y avoir autant de fragments que de pages dans le pire des scénarios. Pourquoi le pire des scénarios ? Nous le découvrirons un peu plus tard mais pour le moment nous prendrons l’exemple suivant :

CREATE TABLE T
(
id INT IDENTITY(1,1),
texte VARCHAR(100)
);

– Index cluster
CREATE UNIQUE CLUSTERED INDEX PK_id
ON T
(
id
);

INSERT T (texte) VALUES (REPLICATE(‘T’, 100))
GO 100

Nous avons donc une table relativement simple avec un index cluster. On remplit la table avec 100 lignes de données ce qui représente environ 10Ko à la louche … autant dire que notre index ne sera composé que de quelques pages. Vérifions le :

SELECT
OBJECT_NAME(object_id) AS [object_name],
index_id,
avg_fragmentation_in_percent,
avg_page_space_used_in_percent,
avg_fragment_size_in_pages AS page_per_fragment,
fragment_count,
page_count,
record_count
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID(‘T’), NULL, NULL, ‘DETAILED’);

… qui donne

Effectivement nous avons trois pages dont une page racine et deux pages de niveau feuille qui composent l’index cluster (index_id = 1). J’ai également ajouté les colonnes fragment_count et avg_fragment_size_in_pages. On constate que pour le niveau feuille il existe deux fragments pour deux pages et que la fragmentation de l’index est de 50%. Si deux fragments existent cela signifie que les pages composants le niveau feuille ne se suivent pas physiquement. On peut le vérifier avec la commande DBCC IND. Ici nous nous intéresserons uniquement qu’au niveau feuille de l’index.

CREATE TABLE T_DBCC_IND
(
ID INT IDENTITY(1,1) PRIMARY KEY,
PageFID TINYINT,
PagePID INT,
IAMFID TINYINT,
IAMPID INT,
ObjectID INT,
IndexID TINYINT,
PartitionNumber TINYINT,
PartitionID BIGINT,
iam_chain_type VARCHAR(30),
PageType TINYINT,
IndexLevel TINYINT,
NextPageFID TINYINT,
NextPagePID INT,
PrevPageFID TINYINT,
PrevPagePID INT
);
INSERT INTO T_DBCC_IND
EXEC (‘DBCC IND (test, T, 1)’);

SELECT *
FROM T_DBCC_IND
WHERE IndexLevel IS NOT NULL;

… qui donne le plan d’allocation de pages suivant :

On constate effectivement que les numéros de pages ne se suivent pas. On peut le représenter schématiquement de la manière suivante :

Quelle est le lien avec la fragmentation ? Définissons d’abord ce qu’est la fragmentation. La documentation en ligne donne l’explication suivante concernant la fragmentation logique :

Pourcentage de pages hors service dans les pages de feuilles d’un index. Une page non ordonnée est une page pour laquelle la page physique suivante allouée à l’index n’est pas la page désignée par le pointeur de page suivante dans la page feuille actuelle.

Autant dire que cette explication reste plutôt abscons … Je préfère la définition suivante :

La fragmentation logique représente le nombre de pages dont la page suivante annoncée dans la page IAM (donc le plan d’allocation) ne se trouve pas dans la même portion de fragment.

Nous sommes bien dans ce cas car la page 201 ne se trouve pas dans le même fragment que la page 206. Pour aller de la page 201 à 206 nous devons passer sur un fragment différent pour un lire un total de deux pages. Nous pouvons en déduire la formule suivante :

Fragmentation = (Nb de fragments – 1) / Nb de pages

Dans notre cas nous aurons :

Fragmentation = (2 – 1) / 2 = 50%

On peut vérifier notre raisonnement en ajoutant un jeu de données supplémentaire :

INSERT T (texte) VALUES (REPLICATE(‘T’, 100))
GO 1000

En utilisant la DMV sys.dm_db_index_physical_stats nous pouvons constater que le nombre de pages à bien évidement augmenté.

Le nombre de fragments est maintenant égale à trois avec 16 pages pour le niveau feuille. En utilisant la formule ci-dessus la fragmentation est de (3 – 1) / 16 soit 12.5% .. On peut vérifier par la commande DBCC IND le nombre de fragments :

On retrouve trois fragments composés de la manière suivante :

Fragment 1 : page 201
Fragment 2 : {page 206 à page 211}
Fragment 3 : {page 336 à page 344}

Donc pour aller de la page 201 (niveau feuille) à la page 344 il faudra passer par 2 fragments :

Ajoutons encore quelques données à notre table T.

INSERT T (texte) VALUES (REPLICATE(‘T’, 100))
GO 1000

L’état de notre index cluster est le suivant :

Le nombre de fragments n’a pas augmenté. Le nombre de pages est passé de 16 à 31 soit 15 pages supplémentaires. La fragmentation a diminué puisque le ratio fragments / pages a également diminué. Le plan d’allocation de pages est devenu le suivant :

Aller un dernier petit calcul de fragmentation :

Fragmentation = (3 – 1) / 32 soit 6.25%

Vous aurez donc compris que plus le ratio fragment / pages est petit mieux c’est. Ce ratio évolue lorsque la table (et donc l’index) est mis à jour. Mais ceci fera certainement l’objet d’un autre billet

David BARBARIN (Mikedavem)
MVP SQL Server

Connaître le gain de compression d’une table avec SQL Server

mikedavem — Tue, 19 Jul 2011 20:36:33 +0000

Vous avez identifié une table candidate à la compression ? mais vous voulez savoir quelle sera la meilleure méthode de compression ROW ou PAGE. SQL Server met à disposition une procédure stockée sp_estimate_data_compression_savings. Cependant l’exécution de cette dernière permet seulement de savoir le taux de compression pour l’une ou pour l’autre méthode pour une seule partition d’une table à la fois. Le script suivant permet de connaître pour une table donnée quelle est la meilleure méthode de compression à utiliser pour l’ensemble des partitions d’une table sachant qu’une table non partitionnée possède une seule partition.

Petite précision : il se peut que le résultat du script affiche un gain négatif. Ceci est parfaitement normal car la compression peut être contre bénéfique dans certains cas. En effet le nouveau format de page utilisé dans ce cas requiert des octets de gestion supplémentaire. Si le gain de compression est nulle alors on perd tout l’intérêt de la compression et on se retrouve avec un nombre de pages supérieure qu’à l’état initial.

DECLARE @object_id INT;
SET @object_id = OBJECT_ID(‘monschema.maTable’);

DECLARE @i INT = 1;
DECLARE @max INT;

IF EXISTS (SELECT * FROM tempdb.sys.objects WHERE [object_id] = OBJECT_ID(‘tempdb..#_estimate_data_compression_savings’))
DROP TABLE #_estimate_data_compression_savings;

– Work table for compression
CREATE TABLE #_estimate_data_compression_savings
(
id INT IDENTITY(1,1),
[object_name] SYSNAME,
[schema_name] SYSNAME,
index_id INT,
partition_number INT,
partition_compression VARCHAR(50) NULL,
partition_value VARCHAR(50) NULL,
[size_with_current_compression_setting(KB)] INT,
[size_with_requested_compression_setting(KB)] INT,
[sample_size_with_current_compression_setting(KB)] INT,
[sample_size_with_requested_compression_setting(KB)] INT,
[data_compression] VARCHAR(10) NULL
);

– Table for the concerned object
DECLARE @table_compression TABLE
(
id INT IDENTITY(1,1),
[schema_name] SYSNAME,
[object_name] SYSNAME,
index_id INT,
partition_number INT,
partition_compression VARCHAR(50),
partition_value SQL_VARIANT
);

INSERT @table_compression ([schema_name], [object_name], index_id, partition_number, partition_compression, partition_value)
SELECT
s.name,
o.name,
p.index_id,
p.partition_number,
p.data_compression_desc,
pv.value
FROM sys.partitions AS p
INNER JOIN sys.objects AS o
ON p.[object_id] = o.[object_id]
INNER JOIN sys.schemas AS s
ON s.[schema_id] = o.[schema_id]
LEFT JOIN sys.partition_range_values AS pv
ON pv.boundary_id = p.partition_number
WHERE o.[object_id] = @object_id
AND index_id < 2; — Table heap or with clustered index
SELECT @max = MAX(id)
FROM @table_compression;

DECLARE @schema_name SYSNAME;
DECLARE @object_name SYSNAME;
DECLARE @index_id INT;
DECLARE @partition_number INT;
DECLARE @partition_compression VARCHAR(50)
DECLARE @partition_value SQL_VARIANT;

WHILE @i <= @max
BEGIN

SELECT
@schema_name = [schema_name],
@object_name = [object_name],
@index_id = index_id,
@partition_number = partition_number,
@partition_compression = partition_compression,
@partition_value = partition_value
FROM @table_compression
WHERE id = @i;

INSERT #_estimate_data_compression_savings ([object_name], [schema_name], index_id, partition_number, [size_with_current_compression_setting(KB)],
                                             [size_with_requested_compression_setting(KB)], [sample_size_with_current_compression_setting(KB)],
                                             [sample_size_with_requested_compression_setting(KB)])
EXEC sp_estimate_data_compression_savings @schema_name, @object_name, @index_id, @partition_number, ‘PAGE';
UPDATE #_estimate_data_compression_savings
SET [data_compression] = ‘PAGE’,
partition_value = CAST(@partition_value AS VARCHAR(50)),
partition_compression = @partition_compression
WHERE id = SCOPE_IDENTITY()
INSERT #_estimate_data_compression_savings ([object_name], [schema_name], index_id, partition_number, [size_with_current_compression_setting(KB)],
                                             [size_with_requested_compression_setting(KB)], [sample_size_with_current_compression_setting(KB)],
                                             [sample_size_with_requested_compression_setting(KB)])
EXEC sp_estimate_data_compression_savings @schema_name, @object_name, @index_id, @partition_number, ‘ROW';
UPDATE #_estimate_data_compression_savings
SET [data_compression] = ‘ROW’,
partition_value = CAST(@partition_value AS VARCHAR(50)),
partition_compression = @partition_compression
WHERE id = SCOPE_IDENTITY()
SET @i += @i;
END

– Show result
;WITH estimate_data_compression_with_page
AS
(
SELECT
[schema_name],
[object_name],
index_id,
partition_number,
partition_value,
partition_compression,
[data_compression],
CASE [size_with_current_compression_setting(KB)]
   WHEN 0 THEN 0
   ELSE (1 – CAST([size_with_requested_compression_setting(KB)] * 1.
            / [size_with_current_compression_setting(KB)] AS DECIMAL(5,2))) * 100
END AS ratio_size_compressed,
[size_with_current_compression_setting(KB)],
[size_with_requested_compression_setting(KB)],
CASE [sample_size_with_current_compression_setting(KB)]
   WHEN 0 THEN 0
   ELSE (1 – CAST([sample_size_with_requested_compression_setting(KB)] * 1.
            / [sample_size_with_current_compression_setting(KB)] AS DECIMAL(5,2))) * 100
END AS ratio_sample_compressed,
[sample_size_with_current_compression_setting(KB)],
[sample_size_with_requested_compression_setting(KB)]
FROM #_estimate_data_compression_savings
WHERE [data_compression] = ‘PAGE’
),
estimate_data_compression_with_row
AS
(
SELECT
[schema_name],
[object_name],
index_id,
partition_number,
[data_compression],
CASE [size_with_current_compression_setting(KB)]
   WHEN 0 THEN 0
   ELSE (1 – CAST([size_with_requested_compression_setting(KB)] * 1.
            / [size_with_current_compression_setting(KB)] AS DECIMAL(5,2))) * 100
END AS ratio_size_compressed,
[size_with_current_compression_setting(KB)],
[size_with_requested_compression_setting(KB)],
CASE [sample_size_with_current_compression_setting(KB)]
   WHEN 0 THEN 0
   ELSE (1 – CAST([sample_size_with_requested_compression_setting(KB)] * 1.
            / [sample_size_with_current_compression_setting(KB)] AS DECIMAL(5,2))) * 100
END AS ratio_sample_compressed,
[sample_size_with_current_compression_setting(KB)],
[sample_size_with_requested_compression_setting(KB)]
FROM #_estimate_data_compression_savings
WHERE [data_compression] = ‘ROW’
)
SELECT
P.[schema_name],
P.[object_name],
P.index_id,
P.partition_number,
P.partition_compression,
P.partition_value,
CASE WHEN P.ratio_size_compressed < R.ratio_size_compressed THEN ‘ROW : ‘ + CAST(R.ratio_size_compressed AS VARCHAR(8)) + ‘ %’
      WHEN P.ratio_size_compressed > R.ratio_size_compressed THEN ‘PAGE : ‘ + CAST(P.ratio_size_compressed AS VARCHAR(8)) + ‘ %’
      ELSE ‘ROW OR PAGE : ‘ + CAST(P.ratio_size_compressed AS VARCHAR(8)) + ‘ %’
END AS preferred_method_compression,
CASE WHEN P.ratio_size_compressed < R.ratio_size_compressed THEN R.[size_with_current_compression_setting(KB)]
      WHEN P.ratio_size_compressed > R.ratio_size_compressed THEN P.[size_with_current_compression_setting(KB)]
      ELSE P.[size_with_current_compression_setting(KB)]
END AS [size_with_current_compression_setting(KB)],
CASE WHEN P.ratio_size_compressed < R.ratio_size_compressed THEN R.[size_with_requested_compression_setting(KB)]
      WHEN P.ratio_size_compressed > R.ratio_size_compressed THEN P.[size_with_requested_compression_setting(KB)]
      ELSE P.[size_with_requested_compression_setting(KB)]
END AS [size_with_current_compression_setting(KB)],
CASE WHEN P.ratio_size_compressed < R.ratio_size_compressed THEN R.[sample_size_with_current_compression_setting(KB)]
      WHEN P.ratio_size_compressed > R.ratio_size_compressed THEN P.[sample_size_with_current_compression_setting(KB)]
      ELSE P.[sample_size_with_current_compression_setting(KB)]
END AS [sample_size_with_requested_compression_setting(KB)],
CASE WHEN P.ratio_size_compressed < R.ratio_size_compressed THEN R.[sample_size_with_requested_compression_setting(KB)]
      WHEN P.ratio_size_compressed > R.ratio_size_compressed THEN P.[sample_size_with_requested_compression_setting(KB)]
      ELSE P.[sample_size_with_requested_compression_setting(KB)]
END AS [sample_size_with_requested_compression_setting(KB)]
FROM estimate_data_compression_with_page AS P
INNER JOIN estimate_data_compression_with_row AS R
ON P.[schema_name] = R.[schema_name]
AND P.[object_name] = R.[object_name]
   AND P.index_id = R.index_id
    AND P.partition_number = R.partition_number;

Bonne compression !!

David BARBARIN (Mikedavem)
MVP SQL Server

Déplacer les données et les index d’une base de manière équitable dans plusieurs fichiers

mikedavem — Tue, 31 May 2011 21:18:04 +0000

Suite à une discussion sur le forum je me permets une billet sur comment déplacer les données et index d’une base de données de façon équitable dans plusieurs fichiers d’un même groupe de fichiers. Cette opération peut s’avérer utile dans bien des cas. Un exemple simple est l’ajout d’un axe physique disque sur lequel on veut ajouter un fichier de données et répartir équitablement celles-ci pour bénéficier par la suite de l’algorithme de réparation de SQL Server.

La question est comment réaliser cette opération ?

La première solution à laquelle on peut penser en premier est d’ajouter un ou plusieurs fichiers dans groupe de fichiers et de reconstruire les index. On peut supposer qu’à ce moment le moteur va répartir les données de manière équitable sur tous les fichiers du groupe. Vérifions le …

Pour cela nous prendrons une base de données avec 2 groupes de fichiers :

Le groupe PRIMARY avec un seul fichiers de données et qui accueillera les tables
Le groupe INDEX avec un seul fichiers de données et qui accueillera les index non cluster

CREATE DATABASE [TEST_MOVE_DATA] ON PRIMARY
( NAME = N’TEST_MOVE_DATA’,
FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA.mdf’ ,
SIZE = 1048576KB ,
FILEGROWTH = 1024KB ),
FILEGROUP [INDEX]
( NAME = N’TEST_MOVE_DATA_index’,
FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA_index.ndf’ ,
SIZE = 1048576KB ,
FILEGROWTH = 1024KB )
LOG ON
( NAME = N’TEST_MOVE_DATA_log’,
FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA_log.ldf’ ,
SIZE = 20160KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO

ALTER DATABASE [TEST_MOVE_DATA] SET RECOVERY SIMPLE;
GO

Nous créerons ensuite une table ayant les caractéristiques suivantes …

USE TEST_MOVE_DATA
GO

CREATE TABLE test
(
col1 INT IDENTITY(1,1) PRIMARY KEY,
col2 CHAR(200),
col3 VARCHAR(200)
);

… avec le jeu de données suivant

INSERT test (col2, col3) VALUES (REPLICATE(‘T’, 200), REPLICATE(‘X’, 200));
GO 2000000

… et un index cluster qui résidera sur le groupe de fichiers [INDEX]

CREATE NONCLUSTERED INDEX IDX_TEST
ON test
(
col2, col3
) ON [INDEX];

Commençons par ajouter un deuxième fichier au groupe de fichiers [PRIMARY] ayant la même taille que le fichier existant :

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_DATA_2′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA_2.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [PRIMARY];

Le script suivant permet de voir l’espace occupé par les données et l’espace libre restant pour chaque fichier de données de la base concernée :

SELECT
    mf.file_id,
    mf.type_desc,
    mf.name AS [filename],
    fg.name AS groupename,
    mf.physical_name,
    mf.size * 8 AS size_KB,
    FILEPROPERTY(mf.name, ‘spaceused’) * 8 AS free_KB,
    (mf.size – FILEPROPERTY(mf.name, ‘spaceused’)) * 8 AS used_KB
FROM sys.master_files AS mf
INNER JOIN sys.filegroups AS fg
ON mf.data_space_id = fg.data_space_id
WHERE mf.database_id = DB_ID(‘TEST_MOVE_DATA’)
AND mf.type_desc = ‘ROWS’
ORDER BY fg.name, mf.name;

Le résultat est le suivant :

Le nouveau fichier TEST_MOVE_DATA_2 n’est pour le moment pas utilisé. Reconstruisons maintenant l’index cluster.

EXEC sp_helpindex ‘test';
GO
– Index name : PK__test__357D0D3E7F60ED59

ALTER INDEX PK__test__357D0D3E7F60ED59
ON test REBUILD;

Vérifions à nouveau l’espace utilisé dans les deux fichiers du groupe PRIMARY :

Le premier fichier du groupe PRIMARY possède 33% des données alors que le deuxième en possède 77%. La reconstruction d’index ne permet pas dans ce premier cas de répartir les données uniformément dans les 2 fichiers. Il faut savoir que le premier fichier du groupe PRIMARY contient les données des tables systèmes et celles-ci ne peuvent pas être déplacés. En ajoutant deux autres fichiers au groupe PRIMARY et en reconstruisant l’index on peut remarquer que les données sont répartis uniformément sur ces derniers.

Essayons la même chose avec le groupe INDEX et reconstruisons l’index non cluster :

Les données sont relativement bien réparties sur l’ensemble des fichiers

Une deuxième solution qui a été également évoquée consiste à ajouter deux fichiers supplémentaires dans un même groupe et de vider les données du premier fichier en espérant que celles-ci soient répartis équitablement dans ces derniers. Seulement il y a deux inconvénients majeurs dans cette méthode : si le groupe de fichiers concerné est le groupe PRIMARY une erreur sera générée si l’on essaie de vider le premier fichier. En effet les données des objets systèmes ne peuvent pas être déplacés. De plus une opération de ce type risque d’augmenter la fragmentation des index dans le cas où elle ne concerne pas le premier fichier du groupe PRIMARY .

Nous pouvons le vérifier. Récupérons d’abord l’état de fragmentation de l’index non cluster avant cette opération.

SELECT
    DB_NAME(database_id) AS database_name,
    index_id,
    index_type_desc,
    avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(), OBJECT_ID(‘test’), NULL, NULL, DEFAULT);

qui donne le résultat suivant :

Ajoutons ensuite deux fichiers au groupe INDEX :

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_DATA_index_2′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA_index_2.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [INDEX]

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_DATA_index_3′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA_index_3.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [INDEX]

et vidons le 1er fichier à l’aide de la commande SHRINK et de l’option EMPTYFILE

DBCC SHRINKFILE(TEST_MOVE_DATA_2, EMPTYFILE);

On peut constater que la répartition n’est pas uniforme …

… et que la fragmentation est importante dans le cas présent

Une autre solution consiste à créer un groupe de fichiers à part et de transvaser les données d’un groupe

ALTER DATABASE TEST_MOVE_DATA
ADD FILEGROUP DATA2

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_DATA2′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA2.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [DATA2]

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_DATA3′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_DATA3.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [DATA2]

ALTER DATABASE TEST_MOVE_DATA
ADD FILEGROUP INDEX2

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_INDEX2′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_INDEX2.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [INDEX2]

ALTER DATABASE TEST_MOVE_DATA
ADD FILE ( NAME = N’TEST_MOVE_INDEX3′,
           FILENAME = N’C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\TEST_MOVE_INDEX3.ndf’ ,
           SIZE = 1048576KB ,
           MAXSIZE = UNLIMITED)
TO FILEGROUP [INDEX2]

L’opération consiste à reconstruire les index dans les nouveaux groupes de fichiers. Pour cela il faut utiliser cette fois-ci l’instruction CREATE INDEX et l’option DROP_EXISTING. C’est la seule instruction qui permet de cibler un groupe de fichiers.

CREATE UNIQUE CLUSTERED INDEX PK__test__357D0D3E7F60ED59
ON test
(
col1
)
WITH (DROP_EXISTING = ON)
ON [DATA2];

CREATE NONCLUSTERED INDEX IDX_TEST
ON test
(
col2, col3
)
WITH (DROP_EXISTING = ON)
ON [INDEX2];

Voyons comment les données ont été réparties dans les nouveaux groupes de fichiers :

Enfin il reste la méthode de créer une base de données à côté et d’y transférer les données … sur ce coup je vous laisse tenter l’aventure

Résumons :

Peu importe la méthode utilisée, pour répartir les données de façon équitable il faut avant tout les créer avec la même taille pour que l’algorithme de répartition du moteur puisse opérer de manière optimale.
Les données du premier fichier du groupe PRIMARY ne peuvent être que partiellement déplacées du fait de l’existence des objets systèmes
Le déplacement des données via l’instruction SHRINKFILE est à proscrire dans ce cas car elle ne préserve pas l’état de fragmentation des index d’une part et ne répartit uniformément les données d’autre part

Bon déplacement de données !!

David BARBARIN (Mikedavem)
Elève ingénieur CNAM Lyon

Configuration de SQL Browser avec un compte de domaine dans une délégation Kerberos avec SSAS en instance nommée

mikedavem — Sun, 29 May 2011 20:45:14 +0000

Lorsque l’on effectue une installation de SQL Server par défaut, on se retrouve bien souvent avec le compte prédéfini NT AUTORITHY\LOCALSERVICE comme compte de service pour le service SQLBrowser et cela convient bien dans la plupart des scénarios. Cependant je suis tombé dans un cas où un compte de domaine était nécessaire pour ce service pour pouvoir paramétrer correctement la délégation Kerberos avec une instance nommée SSAS. On retrouve dans la documentation en ligne Microsoft les informations de sécurité nécessaires au bon fonctionnement du service SQLBrowser dans ce contexte sauf que …

… ça ne fonctionne pas. Nous nous retrouvons avec le message d’erreur suivant en voulant se connecter à l’instance nommée SSAS :

En lançant SQLBrowser manuellement via une fenêtre de commande avec l’option -c dans le contexte du compte de service Windows on peut voir que l’erreur suivante :

On voit ici que SQLBrowser ne sera pas capable de rediriger les requêtes à l’instance nommée SSAS car le service redirecteur n’a pu démarrer correctement. En cherchant dans les KB Microsoft je n’ai pas eu grand chose sur cette erreur. Aux grands maux les grands remèdes je prend l’initiative d’utiliser l’utilitaire sysinternals procmon de Microsoft (d’ailleurs un de mes collègues a eu l’idée bien avant moi ) et celui-ci m’a permis de voir que SQLBrowser tentait d’accéder en écriture sur le dossier C:\Program Files\Microsoft SQL Server\90\Shared\ASCONFIG et que ce type d’accès était donc refusé.

Paramétrons les accès demandés sur ce dossier. Pour cela plusieurs façons de faire :

- Ajouter le compte de service utilisé par SQL Browser avec un accès en lecture / écriture / modification sur le dossier ASCONFIGAjouter le compte de service utilisé par SQL Browser dans le groupe – – SQLServer2005SQLBrowser$User$instanceName et paramétrer pour ce dernier les droits nécessaires sur le dossier ASCONFIG

Tentons un redémarrage du service SQLBrowser via une fenêtre de commande avec l’option -c toujours dans le contexte du compte de domaine …

… Ok plus aucun message d’erreur … le service SQLBrowser semble pouvoir rediriger les requêtes vers l’instance nommée SSAS. Nous sommes sur la bonne voie !!! Nous pouvons redémarrer le service SQLBrowser normalement via la console de gestion de configuration SQL server et voir si la connexion à l’instance nommée SSAS fonctionne :

Tout fonctionne correctement à présent. Tout cela pour dire qu’il existe une coquille dans la documentation Microsoft. En effet si l’on s’y réfère voici les droits à appliquer aux différents dossiers pour le compte de service SQLBrowser :

Le service SQL Browser doit également posséder le droit de modification sur ce dossier.

Bon paramétrage !!

David BARBARIN (Mikedavem)
MVP SQL Server