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

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

/***********************************
* @Author = BARBARIN DAVID        *
* @Date = 05/20/2011              *
* @Description =                  *
* Extract account privileges          *
* on SQL Server 2000, 2005  and 2008   *
***********************************/ 

– Drop temp tables if exists
IF EXISTS (SELECT * FROM tempdb.dbo.sysobjects WHERE id = OBJECT_ID(‘tempdb.dbo.#tlogin’))
  DROP TABLE #tlogin
IF EXISTS (SELECT * FROM tempdb.dbo.sysobjects WHERE id = OBJECT_ID(‘tempdb.dbo.#trole’))
  DROP TABLE #trole
IF EXISTS (SELECT * FROM tempdb.dbo.sysobjects WHERE id = OBJECT_ID(‘tempdb.dbo.#tuser’))
  DROP TABLE #tuser
CREATE TABLE #trole
(
DBName VARCHAR(50),
RoleName SYSNAME NULL,
UserName SYSNAME NULL,
ObjectType VARCHAR(100),
ObjectName SYSNAME NULL,
Permission SYSNAME NULL
)

– Create temp table for users
CREATE TABLE #tuser
(
DBName VARCHAR(50),
UserName SYSNAME,
ObjectType VARCHAR(100),
ObjectName SYSNAME NULL,
Permission SYSNAME NULL
)

– Create temp table for logins
CREATE TABLE #tlogin
(
LoginName SYSNAME,
SrvRoleName SYSNAME
)

IF (LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘9’
OR LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),2) = ’10’)

BEGIN
IF EXISTS (SELECT * FROM tempdb.dbo.sysobjects WHERE id = OBJECT_ID(‘tempdb.dbo.#tloginpermissions’))
  DROP TABLE #tloginpermissions
  — Create temp table  for logins permissions
CREATE TABLE #tloginpermissions
(
  LoginName SYSNAME,
  LoginTypeDesc SYSNAME,
  LoginPermission SYSNAME,
  LoginPermissionState SYSNAME
)
END

– Create temp tables for roles and user members
/* Extract Server Login  */
– SQL Server 2000
IF LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘8’
BEGIN
INSERT #tlogin
SELECT
  loginname AS login_name,
  ‘sysadmin’ AS role_name
FROM master..syslogins
WHERE sysadmin = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘securityadmin’
FROM master..syslogins
WHERE securityadmin = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘serveradmin’
FROM master..syslogins
WHERE serveradmin = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘setupadmin’
FROM master..syslogins
WHERE setupadmin = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘processadmin’
FROM master..syslogins
WHERE processadmin = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘diskadmin’
FROM master..syslogins
WHERE diskadmin = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘dbcreator’
FROM master..syslogins
WHERE dbcreator = 1
UNION ALL
SELECT
  loginname AS login_name,
  ‘bulkadmin’
FROM master..syslogins
WHERE bulkadmin = 1
ORDER BY login_name, role_name
END
– SQL Server 2005 or more
ELSE IF (LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘9’
         OR LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),2) = ’10’)
BEGIN
  INSERT #tlogin
  SELECT
   sp.name AS login_name,
   sp2.name AS role_name
  FROM sys.server_principals AS sp
  LEFT JOIN sys.server_role_members srm
   ON sp.principal_id = srm.member_principal_id
  LEFT JOIN sys.server_principals AS sp2
   ON sp2.principal_id = srm.role_principal_id
  WHERE sp.type IN (‘S’, ‘U’, ‘G’)
   AND sp2.name IS NOT NULL
  INSERT #tloginpermissions
  SELECT
   sp.name AS login_name,
   sp.type_desc AS [login_type],
   spm.permission_name,
   spm.state_desc
  FROM sys.server_principals AS sp
  INNER JOIN sys.server_permissions AS spm
   ON sp.principal_id = spm.grantee_principal_id
  WHERE sp.type IN (‘S’, ‘U’, ‘G’)
  ORDER BY sp.name, spm.permission_name
END

/* Extract Database Users Privileges */
– SQL Server 2000
IF LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘8’
BEGIN
    INSERT #tuser
    EXEC sp_msforeachdb
    ‘USE ?
     SELECT
      »? » AS database_name,
     u.name AS user_name,
     CASE o.xtype
      WHEN  »C » THEN  »CHECK constraint »
      WHEN  »D » THEN  »Default or DEFAULT constraint »
      WHEN  »F » THEN  »FOREIGN KEY constraint »
      WHEN  »L » THEN  »Log »
      WHEN  »FN » THEN  »Scalar function »
      WHEN  »IF » THEN  »Inlined table-function »
      WHEN  »P » THEN  »Stored procedure »
      WHEN  »PK » THEN  »PRIMARY KEY constraint (type is K) »
      WHEN  »RF » THEN  »Replication filter stored procedure »
      WHEN  »S » THEN  »System table »
      WHEN  »TF » THEN  »Table function »
      WHEN  »TR » THEN  »Trigger »
      WHEN  »U » THEN  »User table »
      WHEN  »UQ » THEN  »UNIQUE constraint (type is K) »
      WHEN  »V » THEN  »View »
      WHEN  »X » THEN  »Extended stored procedure »
     END AS ObjectType,
     o.name AS object_name,
     CASE pr.action
      WHEN 26 THEN  »REFERENCES »
      WHEN 193 THEN  »SELECT »
      WHEN 195 THEN  »INSERT »
      WHEN 196 THEN  »DELETE »
      WHEN 197 THEN  »UPDATE »
      WHEN 224 THEN  »EXECUTE »
     ELSE  »OTHERS »
    END AS permission_name
    FROM sysusers u
    INNER JOIN syspermissions p
     ON u.uid = p.grantee
    INNER JOIN sysobjects o
     ON p.id = o.id
    INNER JOIN sysprotects pr
     ON o.id = pr.id
      AND u.uid = pr.uid
    ORDER BY u.name, o.name’
END
– SQL Server 2005 or more
ELSE IF (LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘9’
        OR LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),2) = ’10’)
BEGIN
     PRINT ‘SQL SERVER 2008′
     INSERT #tuser
     EXEC sp_MSforeachdb ‘
     USE ?
     SELECT
       »? » AS database_name,
      p.name AS [user_name],
      pm.class_desc AS ObjectType,
      CASE pm.class
       WHEN 1 THEN o.name
       WHEN 3 THEN s.name
       WHEN 0 THEN DB_NAME()
      END object_name,
      pm.permission_name
      FROM sys.database_principals AS p
      INNER JOIN sys.database_permissions AS pm
       ON pm.grantee_principal_id = p.principal_id
      LEFT JOIN sys.objects AS o
       ON pm.major_id = o.object_id
      LEFT JOIN sys.schemas AS s
       ON pm.major_id = s.schema_id
      ORDER BY p.name, pm.class’
END

/* Extract role rights on databases */
– SQL Server 2000
IF LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘8’
BEGIN
PRINT ‘SQL SERVER 2000′
INSERT #trole
EXEC sp_MSforeachdb ‘
USE ?
SELECT
      »? » AS database_name,
     u.name AS role_name,
     u2.name AS user_name,
     CASE o.xtype
      WHEN  »C » THEN  »CHECK constraint »
      WHEN  »D » THEN  »Default or DEFAULT constraint »
      WHEN  »F » THEN  »FOREIGN KEY constraint »
      WHEN  »L » THEN  »Log »
      WHEN  »FN » THEN  »Scalar function »
      WHEN  »IF » THEN  »Inlined table-function »
      WHEN  »P » THEN  »Stored procedure »
      WHEN  »PK » THEN  »PRIMARY KEY constraint (type is K) »
      WHEN  »RF » THEN  »Replication filter stored procedure »
      WHEN  »S » THEN  »System table »
      WHEN  »TF » THEN  »Table function »
      WHEN  »TR » THEN  »Trigger »
      WHEN  »U » THEN  »User table »
      WHEN  »UQ » THEN  »UNIQUE constraint (type is K) »
      WHEN  »V » THEN  »View »
      WHEN  »X » THEN  »Extended stored procedure »
     END AS ObjectType,
     o.name AS object_name,
     CASE pr.action
      WHEN 26 THEN  »REFERENCES »
      WHEN 193 THEN  »SELECT »
      WHEN 195 THEN  »INSERT »
      WHEN 196 THEN  »DELETE »
      WHEN 197 THEN  »UPDATE »
      WHEN 224 THEN  »EXECUTE »
     ELSE  »OTHERS »
    END AS permission_name
    FROM sysusers u
    LEFT JOIN syspermissions p
     ON u.uid = p.grantee
    LEFT JOIN sysobjects o
     ON p.id = o.id
    LEFT JOIN sysprotects pr
     ON o.id = pr.id
      AND u.uid = pr.uid
    LEFT JOIN sysmembers m
     ON u.uid = m.groupuid
    LEFT JOIN  sysusers u2
     ON m.memberuid = u2.uid
    WHERE u.issqlrole = 1
    ORDER BY u.name, u2.name, o.name’
END
– SQL Server 2005 or more
ELSE IF (LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘9’
         OR LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),2) = ’10’)
BEGIN
  PRINT ‘SQL SERVER 2008′
  INSERT #trole
      EXEC sp_MSforeachdb ‘
      USE ?
      SELECT
        »? » as database_name,
       dp.name AS role_name,
       dp2.name AS user_name,
       pm.class_desc AS ObjectType,
       CASE pm.class
        WHEN 1 THEN o.name
        WHEN 3 THEN s.name
        WHEN 0 THEN DB_NAME()
       END object_name,
       pm.permission_name
      FROM sys.database_principals AS dp
      LEFT JOIN sys.database_role_members AS rlm
       ON rlm.role_principal_id = dp.principal_id
      LEFT JOIN sys.database_principals AS dp2
       ON dp2.principal_id = rlm.member_principal_id
      LEFT JOIN sys.database_permissions AS pm
       ON dp.principal_id = pm.grantee_principal_id
      LEFT JOIN sysobjects AS o
       ON pm.major_id = o.id
     LEFT JOIN sys.schemas AS s
      ON pm.major_id = s.schema_id
     WHERE dp.type =  »R »’
END

/* Show permissions */
SELECT @@VERSION

– Logins and server roles
SELECT ‘Login and server roles’
SELECT *
FROM #tlogin

– Server permissions was introduced with SQL Server 2005
IF (LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),1) = ‘9’
    OR LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(50)),2) = ’10’)
BEGIN
SELECT ‘Server login permissions’
SELECT *
FROM #tloginpermissions
END

– Role permissions
SELECT ‘Role permissions with users’
SELECT *
FROM #trole

– User permissions
SELECT ‘User permissions’
SELECT * FROM #tuser

A noter que je n’ai pas réalisé de concaténation dans le cas où un login appartient à plusieurs rôles de serveur par exemple. Le but de cette extraction est de pouvoir facilement l?importer dans un fichier Excel.

Bon audit !!

David BARBARIN (Mikedavem)
MVP SQL Server

La seule possibilité qui s’offre à nous est donc de lier pour chaque base de données un utilisateur à un compte de connexion. Chaque utilisateur de base de données doit ensuite être configurer afin de pouvoir sauvegarder la base de données concernant. Pour cela il est possible d’utiliser l’instruction GRANT ou d’associer l’utilisateur au rôle fixe de bases de données db_backupoperator. La question qui se pose maintenant est comment faire cela automatiquement lorsqu’une base est créée ? Les triggers DDL peuvent être une solution dans notre cas.

Le script suivant effectue les actions suivantes après qu’une base de données soit créée :

- Création d’un utilisateur dans la base de données nouvellement créée (nom identique à celui du compte de connexion qui lui est associé)
- Ajout du nouvel utilisateur au rôle fixe de bases de données db_backupoperator

Ce script peut bien entendu être amélioré ou modifié selon le contexte. Le but ici est simplement d’en montrer la trame principale.

CREATE TRIGGER TR_backupoperator
ON ALL SERVER
AFTER CREATE_DATABASE
AS

SET NOCOUNT ON;

DECLARE @user VARCHAR(100);
DECLARE @sql VARCHAR(1000);
DECLARE @xml_event XML;

SET @xml_event = EVENTDATA();
SET @user = ‘user';

SELECT @sql =
    ‘USE ‘ +
    CONVERT(SYSNAME, @xml_event.query(‘data(/EVENT_INSTANCE/DatabaseName)’)) + ‘; CREATE USER ‘ + @user +
    ‘ FOR LOGIN ‘ + @user + ‘; EXEC sp_addrolemember  »db_backupoperator »,  »’ + @user +  »';'; 

BEGIN TRY   
    EXEC(@sql);
END TRY
BEGIN CATCH
    PRINT ‘The database can »t be created due to the following issue :';
    PRINT ERROR_MESSAGE();
END CATCH;

Je tiens quand même à préciser que ce genre de méthode, bien que pratique, doit être utilisée avec parcimonie. En effet, dans des environnements où les données peuvent être sensibles, il n’est pas rare de vouloir isoler une base de données par rapport à une autre. Dans ce cas le fait de donner le droit de sauvegarde sur l’ensemble du serveur à un compte de connexion peut compromettre la sécurité des données car celui-ci peut avoir accès complet aux données de l’instance.

David BARBARIN (Mikedavem)
MVP SQL Server

>> http://msdn.microsoft.com/fr-fr/sqlserver/gg574334

David BARBARIN (Mikedavem)
MVP SQL Server

Commençons par créer une table T_TEST :

CREATE TABLE T_TEST
(
id SMALLINT NOT NULL,
texte1 CHAR(50) NOT NULL
);

Insérons ensuite une ligne de données :

INSERT T_TEST VALUES (1, REPLICATE(‘T’, 25));

Dans un premier temps nous utiliserons une vue système sys.system_internals_partition_columns. Cette vue permet de visualiser les métas données de bas niveau du moteur SQL Server. Cette vue est bien entendu réservée à un usage interne et leur compatibilité n’est pas garantie pour les versions futures de SQL Server. Vous trouverez une liste des vues ici.

Le script suivant permet de visualiser les informations d’offsets des colonnes de la table T_TEST :

SELECT
    C.name AS column_name,
    C.column_id,
    PC.max_inrow_length,
    PC.system_type_id,
    PC.leaf_offset
FROM sys.system_internals_partition_columns PC
INNER JOIN sys.partitions AS P
ON P.partition_id = PC.partition_id
INNER JOIN sys.columns AS C
ON C.column_id = PC.partition_column_id
  AND C.object_id = P.object_id
WHERE P.object_id = OBJECT_ID(‘T_TEST’);

Le résultat est le suivant :

La colonne id est stocké sur 2 octets (SMALLINT = 2 octets) et commence au 4ème octet. La colonne texte1, quant à elle, est stocké sur 50 octets (CHAR(50) = 50 octets) et commence au 6ème octet (longueur de la colonne id + offset de départ). La longueur totale d’une ligne fait donc 56 octets pour le moment.

Augmentation de la longueur d’une colonne

Réduisons la longueur de la colonne id en changeant son type en INT. Le stockage d’une colonne de type INT prend 4 octets.

ALTER TABLE T_TEST
ALTER COLUMN id INT;
GO

Regardons l’impact au niveau interne à l’aide de notre script :

On constate tout d’abord que la colonne id ne commence plus à l’offset 4 mais à l’offset 56. Ensuite, on remarque que la longueur de la colonne a bien changé (mx_inrow_length = 4). Que sont devenus les données présentes tout à l’heure à l’offset 4 ? Vérifions le à l’aide des commandes DBCC IND et DBCC PAGE :

DBCC IND (‘Internales’, ‘T_TEST’, -1);
GO

C’est la page 153 qui nous intéresse ici.

DBCC TRACEON(3604);
GO
DBCC PAGE(‘Internales’, 1, 153, 3);

01 : status bits A
00 : status bits B
00 3C : Longueur de la portion fixe de la ligne de données. (003C correspond à 60 en décimal)
00 01 : Valeur de la colonne id avant changement (correspond à 1 en décimal sur 2 octets qui correspondent au type SMALLINT)
20 20 20 20 … 54 54 54 54 : Valeur de la colonne text1 (en prenant les valeurs ASCII on retrouve bien la chaîne : TTTTTTTTTTTTTTTTTTTTTTTTT)
00 00 00 01 : Valeur de la colonne id après changement (correspond à 1 en décimal sur 4 octets qui correspondent bien au type INTEGER)
00 03 : Nombre de colonnes (3 colonnes : id (avant modification) + texte1 + id (après modification))
00 : Matrice des NULL (Dans ce cas pas de colonnes NULL)

>> Lorsqu’une colonne voit sa longueur augmentée, SQL Server ne remplace pas cette colonne avec la nouvelle longueur mais crée une nouvelle colonne avec la nouvelle longueur. L’ancienne colonne est toujours présente mais n’est plus visible. Par conséquent, la longueur de la ligne de données augmente. On passe dans notre cas d’une longueur de 56 octets à une longueur de 60 octets.

Réduction de la longueur d’une colonne

Prenons maintenant le cas inverse et réduisons la longueur de la colonne id en changeant le type de données à SMALLINT.

ALTER TABLE T_TEST
ALTER COLUMN texte1 CHAR(25);
GO

Regardons l’impact au niveau interne à l’aide de notre script :

La longueur de la colonne texte1 a bien changé (max_inrow_length = 25) mais l’offset de la colonne id reste inchangé. Celui-ci est toujours égale à 56. Le stockage de la colonne texte1 n’a en fait pas changé. Il est toujours de 50 octets (leaf offset colonne texte1 = 56 –  leaf offset colonne id = 6).

>> Lorsque la longueur d’une colonne est diminuée, SQL Server ne réduit pas le stockage en réalité. Un contrôle est simplement réalisé sur la longueur des données (colonne max_inrow_length).

Comme vous pouvez le constater, l’impact sur le stockage interne est tout autre de ce que l’on pense à priori. Il est important de savoir que l’augmentation de la longueur d’une colonne a un fort impact sur le stockage interne et qu’à l’inverse aucun espace de stockage n’est récupéré. La seule façon de remettre tout ça en ordre est de créer ou reconstruire l’index cluster de la table.

Bonne modification de colonnes !!!

David BARBARIN (Mikedavem)
Elève ingénieur CNAM
MVP SQL Server

De plus, il peut exister plusieurs exécutions d’une même requête ou procédure dans une trace profiler mais avec des paramètres différents. Une question peut alors se poser : comment connaître les durées et consommations globales des différents modèles de requêtes (indépendamment de la valeur des paramètres utilisés) et pouvoir ainsi mettre l’accent sur l’optimisation de certains modèles de requêtes ?

Lors de mon dernier audit, j’ai également dû répondre à la problématique suivante : le serveur de bases de données comportait plusieurs instances SQL Server. Dans un tel cas, comment connaitre le ratio entre la consommation d’une requête exécutée sur une instance et celle de l’ensemble des instances présentes sur ce même serveur ? Cela peut être utile pour cibler les requêtes ou procédures les plus consommatrices à l’échelle du serveur et pour lesquelles il est utile de revoir la conception.

Le script suivant permet de répondre aux deux problématiques décrites ci-dessus.

Ce script est divisé en plusieurs parties :

- Création d’une fonction SQL qui permettra de concevoir les modèles de requêtes en fonction des requêtes exécutés dans la trace profiler.
- Création d’une table temporaire de travail pour effectuer les analyses nécessaires
- Import des données du ou des fichiers de trace profiler
- Analyse des différentes consommations de requêtes

Script :

/****************************************************************
* @Auteur = BARBARIN DAVID (Mikedavem)                         *
* @Description =                                               *
* Analyse des fichiers de trace                                *
* Eléments du script :                                         *
* – Fonction dbo.SQLSig : Génération des patterns de requêtes  *
* – #Workload : Table de travail pour les analyses de requêtes *
****************************************************************/

USE tempdb;
GO

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

* Fonction de génération des modèles de requêtes                 *

* Paramètres d’entrée :                                          *

* – @p1 : Requête ou procédure                                   *

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

IF EXISTS (SELECT * FROM sys.sql_modules

           WHERE object_id = OBJECT_ID(‘dbo.SQLSig’))

    DROP FUNCTION dbo.SQLSig;

GO

– Création de la fonction de traitement des patterns

CREATE FUNCTION dbo.SQLSig

(@p1 NVARCHAR(MAX))

RETURNS NVARCHAR(MAX)

WITH SCHEMABINDING

AS

– Fonction réalisée par la Team SQL Server Customer Advisory

– Auteur = Stuart Ozer

BEGIN

DECLARE @pos INT;

DECLARE @mode CHAR(10);

DECLARE @maxlength INT;

DECLARE @p2 NVARCHAR(MAX);

DECLARE @p2i NVARCHAR(MAX);

DECLARE @currchar CHAR(1);

DECLARE @nextchar CHAR(1);

DECLARE @p2len INT;   

SET @maxlength = LEN(RTRIM(SUBSTRING(@p1, 1, 4000)));

SET @pos = 1;

SET @p2i =  »;

SET @p2 =  »;

SET @p2len = 0;

SET @currchar =  »;

SET @nextchar =  »;

SET @mode = ‘command';

– Modification David BARBARIN (pour prendre en compte sp_executesql)

IF (PATINDEX(‘%sp_executesql%’, @p1)) > 0

BEGIN

    SET @pos = PATINDEX(‘% »,@%’,@p1) + 2;

    SET @p2i = SUBSTRING(@p1, 1, PATINDEX(‘% »,@%’,@p1) + 1);

    SET @p2 =  SUBSTRING(@p1, PATINDEX(‘% »,@%’,@p1) + 2, LEN(@p1));

END

WHILE (@pos <= @maxlength)

BEGIN

  SET @currchar = SUBSTRING(@p1, @pos, 1);

  SET @nextchar = SUBSTRING(@p1, @pos + 1, 1);

  IF @mode = ‘command’

  BEGIN

   SET @p2 = LEFT(@p2, @p2len) + @currchar;

   SET @p2len = @p2len + 1;

   IF @currchar IN (‘,’,'(‘,’ ‘,’=’,'<‘,’>’,’!’)

       AND @nextchar BETWEEN ‘0’ AND ‘9’

   BEGIN

    SET @mode = ‘number';

    SET @p2 = LEFT(@p2, @p2len) + ‘#';

    SET @p2len = @p2len + 1;

   END

   IF @currchar =  » »

   BEGIN

    SET @mode = ‘literal';

    SET @p2 = LEFT(@p2, @p2len) + ‘# »';

    SET @p2len = @p2len + 2;

   END

  END

  ELSE IF @mode = ‘number’ AND @nextchar IN (‘,’,’)’,’ ‘,’=’,'<‘,’>’,’!’)

   SET @mode = ‘command';

  ELSE IF @mode = ‘literal’ AND @currchar =  » »

   SET @mode = ‘command’

  SET @pos = @pos + 1;

END

RETURN @p2i + @p2;

END;

GO

/******************************************************************
* Création de la table de travail pour les analyses              *
******************************************************************/
IF EXISTS(SELECT * FROM tempdb.sys.objects
          WHERE object_id = OBJECT_ID(‘tempdb.dbo.#workload’))
    DROP TABLE #workload;

CREATE TABLE #workload
(
ServerName VARCHAR(50),
TextData VARCHAR(MAX),
DatabaseName VARCHAR(100),
ApplicationName VARCHAR(100),
Duration INT,
Reads INT,
Writes INT,
CPU INT,
Template AS dbo.SQLSig(TextData) PERSISTED,
CheckSum_Template AS CHECKSUM(dbo.SQLSig(TextData)) PERSISTED
);
GO

– Création index cluster sur la table de travail
CREATE CLUSTERED INDEX idx_clust_workload
ON #workload
(
CheckSum_Template
);
GO

/******************************************************************
* Import des données des fichiers de trace                       *
* Paramètres d’entrée :                                          *
* – @path_trc : Chemin du fichier de trace à importer            *
******************************************************************/
DECLARE @path_trc VARCHAR(100);
SET @path_trc = ‘path_fichier_trace';

INSERT INTO #workload (ServerName, TextData, DatabaseName, ApplicationName, Duration, Reads, Writes, CPU)
SELECT ServerName, TextData, DatabaseName, ApplicationName, Duration, Reads, Writes, CPU
FROM fn_trace_gettable(@path_trc, NULL);
GO

/******************************************************************
* Requête d’analyse par pattern des données du fichier de trace  *
* Paramètres de tri : @classement                                *
* = reads    = Classement IO lectures                            *
* = writes   = Classement IO écritures                           *
* = CPU      = Classement par consommation CPU                   *
* = Duration = Classement par durée d’exécution                  *
******************************************************************/

DECLARE @classement VARCHAR(10)
SET @classement = ‘duration'; — Type de classement : duration, cpu, reads or writes

WITH total_workload_by_server_checksum_template
AS
(
    SELECT
        CheckSum_Template,
        ServerName,
        COUNT(*) AS nb_executions,
        SUM(CAST(duration AS BIGINT)) AS total_duration_by_template_server,
        SUM(CAST(CPU AS BIGINT)) AS total_cpu_by_template_server,
        SUM(CAST(Reads AS BIGINT)) AS total_reads_by_template_server,
        SUM(CAST(Writes AS BIGINT)) AS total_writes_by_template_server
    FROM #workload
    GROUP BY ServerName, CheckSum_Template
),
total_workload_total_servers
AS
(
     SELECT
        W.*,
        W.total_duration_by_template_server * 100.0 / S.duration_total_server AS percent_duration_template_server,
        W.total_cpu_by_template_server * 100.0 / S.total_cpu_total_server AS percent_cpu_template_server,
        W.total_reads_by_template_server * 100.0 / S.total_reads_server AS percent_reads_template_server,
        W.total_writes_by_template_server * 100.0 / S.total_writes_server AS percent_writes_template_server,
        W.total_duration_by_template_server * 100.0 / T.duration_total AS percent_duration_total,
        W.total_cpu_by_template_server * 100.0 / T.cpu_total AS percent_cpu_total,
        W.total_reads_by_template_server * 100.0 / T.reads_total AS percent_reads_total,
        W.total_writes_by_template_server * 100.0 / T.writes_total AS percent_writes_total
     FROM total_workload_by_server_checksum_template AS W
     INNER JOIN
     (
        SELECT
            ServerName,
            SUM(CAST(duration AS BIGINT)) AS duration_total_server,
            SUM(CAST(CPU AS BIGINT)) AS total_cpu_total_server,
            SUM(CAST(Reads AS BIGINT))  AS total_reads_server,
            SUM(CAST(Writes AS BIGINT)) AS total_writes_server
        FROM #workload
        GROUP BY ServerName
     ) AS S
     ON S.ServerName = W.ServerName
     CROSS JOIN
     (
        SELECT
            SUM(CAST(duration AS BIGINT)) AS duration_total,
            SUM(CAST(CPU AS BIGINT)) AS cpu_total,
            SUM(CAST(Reads AS BIGINT)) AS reads_total,
            SUM(CAST(Writes AS BIGINT))  AS writes_total
        FROM #workload
     ) AS T
),
rank_template_workload_by_type
AS
(
SELECT
    *,
    RANK() OVER(ORDER BY percent_duration_total DESC) AS rank_duration,
    RANK() OVER(ORDER BY percent_cpu_total DESC) AS rank_cpu,
    RANK() OVER(ORDER BY percent_reads_total DESC) AS rank_reads,
    RANK() OVER(ORDER BY percent_writes_total DESC) AS rank_writes,
    RANK() OVER(ORDER BY percent_duration_template_server DESC) AS rank_duration_server,
    RANK() OVER(ORDER BY percent_cpu_template_server DESC) AS rank_cpu_server,
    RANK() OVER(ORDER BY percent_reads_template_server DESC) AS rank_reads_server,
    RANK() OVER(ORDER BY percent_writes_template_server DESC) AS rank_writes_server
FROM total_workload_total_servers
)
SELECT
W.ServerName,
W.Template,
R.nb_executions,
R.percent_duration_total,
R.percent_duration_template_server,
R.percent_cpu_total,
R.percent_cpu_template_server,
R.percent_reads_total,
R.percent_reads_template_server,
R.percent_writes_total,
R.percent_writes_template_server,
R.total_duration_by_template_server AS total_Duration,
R.total_cpu_by_template_server AS total_CPU,
R.total_reads_by_template_server AS total_Reads,
R.total_writes_by_template_server AS total_Writes,
W.TextData,
W.Duration,
W.CPU,
W.Reads,
W.Writes
FROM #workload AS W
INNER JOIN rank_template_workload_by_type AS R
ON W.CheckSum_Template = R.CheckSum_Template
AND W.ServerName = R.ServerName
–Récupération des requêtes les plus consommatrices (>= 5%)
WHERE (@classement = ‘duration’ AND R.percent_duration_total >= 5)
OR (@classement = ‘cpu’ AND R.percent_cpu_total >=5)
  OR (@classement = ‘reads’ AND R.percent_reads_total >= 5)
   OR (@classement = ‘writes’ AND R.percent_writes_total >= 5)
ORDER BY CASE @classement
          WHEN ‘duration’ THEN R.rank_duration
          WHEN ‘cpu’ THEN R.rank_cpu
          WHEN ‘reads’ THEN R.rank_reads
          WHEN ‘writes’ THEN R.rank_writes
         END,
         CASE @classement
          WHEN ‘duration’ THEN R.rank_duration_server
          WHEN ‘cpu’ THEN R.rank_cpu_server
          WHEN ‘reads’ THEN R.rank_reads_server
          WHEN ‘writes’ THEN R.rank_writes_server
         END,
         CASE @classement
          WHEN ‘duration’ THEN W.Duration
          WHEN ‘cpu’ THEN W.CPU
          WHEN ‘reads’ THEN W.Reads
          WHEN ‘writes’ THEN W.writes
         END DESC;

Remarque :

La fonction de traitement des requêtes pour générer les modèles associés peut poser un problème si le fichier de trace à important est trop important. Par habitude, je préfère importer plusieurs fichiers de trace à volumétrie moyenne qu’un seul gros fichier à la fois.

Bon audit de trace !

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

Revenons un bref instant sur les VLF (Virtual Log Files). Un VLF est l’unité de travail pour le journal des transactions. Sa taille est déterminée par SQL Server en fonction de la taille totale du journal des transactions et de sa valeur d’incrément. A la création d’une base de données, le nombre de VLF d’un fichier journal est toujours compris entre 2 et 16. Nous pouvons le vérifier en créant une base de données nommée test_jnl avec le script suivant :

USE [master];
GO

IF  EXISTS (SELECT name FROM sys.databases WHERE name = N’test_jnl’)
DROP DATABASE test_jnl;
GO

CREATE DATABASE test_jnl
ON  PRIMARY
( NAME = N’test’, FILENAME = N’E:\MSSQLSERVER\MSSQL10.MSSQLSERVER\MSSQL\DATA\test.mdf’ ,
  SIZE = 10MB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB)
LOG ON
( NAME = N’test_log’, FILENAME = N’F:\MSSQLSERVER\test_log.LDF’ ,
  SIZE = 576KB , FILEGROWTH = 0),
( NAME = N’test_log_2′, FILENAME = N’F:\MSSQLSERVER\test_log_2.ldf’ ,
  SIZE = 5MB , MAXSIZE = 2048GB , FILEGROWTH = 0)
GO

Le script précédent créé une base de données composée d’un fichier de données de 10MB et de deux fichiers journaux. Le premier possède une taille de 576KB et l’accroissement automatique est désactivé. Le deuxième fichier possède une taille de 5MB avec un accroissement automatique également désactivé.

Nous pouvons voir le nombre de VLF créé pour chaque fichier journal à l’aide de la commande DBCC LOGINFO :

DBCC LOGINFO(‘test_jnl’);

qui donne le résultat suivant :

Le 1er fichier (FileId=2) est composé de 2 VLF tandis que le 2ème fichier est composé, quant à lui, de 4 VLF. Une colonne intéressante est la colonne status. Celle-ci nous indique si un VLF est libre (valeur 0) ou utilisé (valeur 2).

Créons à présent une table nommée test :

USE test_jnl;

CREATE TABLE test
(
id INT NOT NULL,
texte VARCHAR(50) NOT NULL
);

Effectuons une sauvegarde de la base de données test_jnl pour avoir un point de référence servant aux LSN des transactions du journal. La base de données est en mode de récupération complet.

BACKUP DATABASE test_jnl TO DISK = ‘F:\MSSQLSERVER\BACKUP\TEST_JNL.BAK';
GO

Insérons une première ligne de données dans la table test :

INSERT test VALUES (1, REPLICATE(‘T’, 50));

Le jeu de données suivant pourra être joué plusieurs fois afin de pouvoir observer le remplissage du journal et l’utilisation des VLF :

INSERT test
SELECT * FROM test;

Voici le résultat de la commande DBCC LOG après avoir joué le script d’insertion de données avec un total de 1024 lignes :

Le 2ème VLF du premier fichier est maintenant utilisé (status = 2). Continuons le remplissage de la table en jouant à nouveau le script d’insertion. Voici maintenant le résultat de la commande DBCC LOG après l’insertion de 2048 lignes de données :

Continuons encore à remplir la table test avec notre script d’insertion. Après l’insertion de 8192 lignes de données le message d’erreur suivant apparaît pour indiquer que le journal des transactions est plein.

Msg 9002, Niveau 17, État 2, Ligne 1
Le journal des transactions de la base de données ‘test_jnl’ est plein. Pour savoir pourquoi il est impossible de réutiliser de l’espace dans le journal, consultez la colonne log_reuse_wait_desc dans sys.databases.

Nous avons limité la croissance des 2 fichiers journaux en désactivant leur expansion automatique. Ceci explique pourquoi notre journal des transactions est plein. Regardons l’état des VLF :

On constate que tous les VLF sont utilisés (status=2), ce qui confirme une nouvelle fois le message d’erreur précédent.

On constate après cette série de test que le remplissage du journal s’effectue toujours de manière séquentielle et dans un seul fichier à la fois. SQL Server considère le journal des transactions comme un conteneur unique même lorsque celui-ci est composé de plusieurs fichiers. Un seul VLF est utilisé à la fois. Il en va de même pour les fichiers : le 1er fichier journal est d’abord utilisé. Lorsque celui-ci est rempli, SQL Server passe au 2ème fichier et ainsi de suite si d’autres fichiers existent. Nous n’avons pas d’écritures parallèles. C’est la raison pour laquelle qu’il est inutile de multiplier les fichiers journaux pour des raisons de performances.

Nous avons vu précédemment le cas où la taille de chaque fichier était limitée, sans possibilité d’accroissement. Mais que se passe t’il maintenant lorsque nous autorisons l’expansion automatique de ces fichiers ? Le script suivant initialise le paramètre FILEGROWTH de chaque fichier journal à 10%.

ALTER DATABASE test_jnl
MODIFY FILE (NAME = test_log, FILEGROWTH = 10%);
GO
ALTER DATABASE test_jnl
MODIFY FILE (NAME = test_log_2, FILEGROWTH = 10%);
GO

Continuons à remplir la table test avec la requête suivante :

INSERT test
SELECT TOP 10 * FROM test;

Voici maintenant le résultat de la commande DBCC LOG après l’insertion des 10 lignes de données dans la table test :

Un nouveau VLF a été alloué pour le 1er fichier (FileId=2). Après une autre série d’insertion de données dans la table test, on peut remarquer ceci :

Le VLF précédemment alloué au 1er fichier est utilisé et plein. SQL Server doit donc à nouveau allouer d’autres VLF et il le fait maintenant sur le deuxième fichier. 2 nouveaux VLF sont alloués dans le 2ème fichier.

On continue toujours une série d’insertion de données dans la table test. L’état des VLF est maintenant le suivant :

Les VLF alloués au deuxième fichier ont été utilisés et une nouvelle allocation de VLF est effectuée mais dans le premier fichier.

Vous l’aurez compris, lorsqu’aucune limitation d’expansion de fichier n’est paramétrée, SQL Server alloue et utilise les VLF des fichiers tour à tour. Encore une fois, il n’y a pas d’écriture parallèle dans les fichiers journaux. Chaque fichier est utilisé l’un après l’autre.

Avec la requête suivante on peut voir l’ordre d’utilisation des fichiers et de leur VLF :

USE test_jnl;

IF EXISTS (SELECT * FROM tempdb.sys.objects AS o WHERE o.object_id = OBJECT_ID(‘tempdb.dbo.#t’))
DROP TABLE #t;

CREATE TABLE #t
(
FileId INT,
FileSize BIGINT,
StartOffset INT,
FSeqNo INT,
STATUS TINYINT,
Parity INT,
CreateLSN NUMERIC(38)
);
INSERT INTO #t
EXEC(‘DBCC LOGINFO( »test_jnl »)’);
SELECT
*
FROM #t
ORDER BY FSeqNo;

Le résultat est le suivant :

On retrouve ce que l’on a vu précédemment. Le premier fichier journal (FileId = 2) a été utilisé suivi du 2ème fichier journal. Après avoir autorisé l’auto-expansion des fichiers journaux, un nouveau VLF a été alloué et utilisé pour le premier fichier. Enfin, une nouvelle allocation de VLF a été réalisée pour le second fichier. Vous pouvez faire le tester pour voir si la future allocation s’effectue bien dans le premier fichier journal.

David BARBARIN (Mikedavem)
Elève ingénieur CNAM
MVP SQL Server

Tout d’abord il est important de préciser qu’il n’est absolument pas nécessaire de reconstruire une configuration log-shipping lorsqu’il s’agit de déplacer des fichiers de bases de données en général. En effet, le log-shipping est indépendant de la topologie des fichiers de bases de données. Dans ce billet nous prendrons simplement l’exemple des fichiers journaux d’une base mais la manipulation reste la même pour n’importe quel type de fichier.

1- Dans le cas d’une base sur le primaire les étapes à suivre sont les suivantes :

- Arrêter le job de sauvegarde du journal de la base de données concernée
- Détacher la base de données avec la procédure stockée système sp_detach
- Déplacer le(s) fichier(s) journaux concerné(s)
- Rattacher la base de données concernée avec la procédure stockée système sp_attach
- Réactiver le job de sauvegarde du journal de la base de données concernée

2- Dans le cas d’une base de données sur le secondaire, la manipulation est un peu différente car la base de données est dans un mode de fonctionnement différent (NORECOVEY ou STANDBY). Par conséquent, on ne peut pas utiliser les procédures stockées systèmes permettant de détacher et de rattacher une base de données. Les étapes à suivre dans ce cas sont les suivantes :

- Si la base de données est en mode de fonctionnement STANDBY, il faut la passer en mode NORECOVERY.
- Arrêter les jobs de copie et de restauration des fichiers journaux pour la base de données concernée
- Utiliser la commande ALTER DATABASE MODIFY FILE (NAME = logicalName, FILENAME = ‘filePath’)
- Arrêter le secondaire (instance)
- Déplacer les fichiers journaux concernés dans le chemin défini avec la commande ALTER DATABASE
- Redémarrer le secondaire (instance)
- Vérifier les nouveaux emplacements de fichier à l’aide de la DMV sys.master_files
- Si la base de données était en mode de fonctionnement STANDBY, il faudra exécuter la commande RESTORE DATABASE avec l’option STANDBY
- Réactiver les jobs de copie et de restauration des journaux de la base de données concernée

Bon déplacement de fichiers !!

David BARBARIN (Mikedavem)
Elève ingénieur CNAM LYON
MVP SQL Server

On prendra comme exemple une table nommée Person.Address de la base de données bien connue AdventureWorks. Nous voulons satisfaire la requête suivante :

USE AdventureWorks;
GO

SELECT
    AddressLine1,
    AddressLine2,
    City,
    StateProvinceID,
    PostalCode
FROM Person.Address
WHERE PostalCode BETWEEN N’98000′ and N’99999′;

Pour cela nous allons créé deux index :

- Un index non cluster classique :

– Index non cluster classique
CREATE INDEX IX_Address_PostalCode    
ON Person.Address (PostalCode,AddressLine1, AddressLine2, City, StateProvinceID);
GO

- Un index non cluster avec colonnes incluses :

– Index non cluster avec colonnes incluses
CREATE INDEX IX_Address_PostalCode_Included      
ON Person.Address (PostalCode)      
INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);
GO

Je vous laisse vérifier via le plan d’exécution si ces 2 index permettent de satisfaire à la requête ci-dessus sans passer par l’index cluster de la table.

Regardons maintenant la taille de chaque index créé via la DMV sys.dm_db_index_physical_stats :

SELECT
    i.name,
    SUM(ips.page_count * 8. / 1024) AS size_in_kb
FROM sys.dm_db_index_physical_stats(DB_ID(‘AdventureWorks’), OBJECT_ID(‘Person.Address’), NULL, NULL, ‘DETAILED’) AS ips
INNER JOIN sys.indexes AS i
ON i.index_id = ips.index_id
AND i.object_id = ips.object_id
  AND i.name LIKE ‘IX_Address_PostalCode%’
GROUP BY i.name;

qui donne le résultat suivant :

La requête suivante donne plus de détails sur les 2 index créées :

SELECT
    i.index_id,
    i.name,
    i.type_desc,
    ips.index_depth,
    ips.page_count,
    ips.record_count
FROM sys.dm_db_index_physical_stats(DB_ID(‘AdventureWorks’), OBJECT_ID(‘Person.Address’), NULL, NULL, ‘DETAILED’) AS ips
INNER JOIN sys.indexes AS i
ON i.index_id = ips.index_id
AND i.object_id = ips.object_id
  AND i.name LIKE ‘IX_Address_PostalCode%';

qui donne le résultat suivant :

Première constatation :

L’index non cluster (1.67 Ko) est plus volumineux que l’index non cluster avec colonnes incluses (1.65 Ko). Un niveau supplémentaire existe pour l’index non cluster classique. (3 contre 2 pou l’index non cluster avec colonnes incluses).

Pour comprendre cette différence il va falloir regarder en détails chaque type de page de chaque index à l’aide des commandes habituelles DBCC IND et DBCC PAGE.

1- Pour les pages racines de chaque type d’index :

- Index non cluster classique :

DBCC IND (‘AdventureWorks’, ‘Person.Address’, 6);
GO
– Root : 11568
DBCC TRACEON(3604);
GO
– Index IX_Address_PostalCode
DBCC PAGE(‘AdventureWorks’, 1, 11570, 3);
GO

qui donne le résultat suivant :

La page racine comporte toutes les colonnes qui composent l’index. Ceci est le comportement attendu pour un index non cluster classique. Nous retrouvons également les pointeurs vers les pages suivantes ainsi que les signets vers la clés de l’index cluster (AddressID).

- Index non cluster avec colonnes incluses :

DBCC IND (‘AdventureWorks’, ‘Person.Address’, 7);
GO
– Root : 11632
– Index IX_Address_PostalCode_Included
DBCC PAGE(‘AdventureWorks’, 1, 11632, 3);
GO

qui donne le résultat suivant :

Ici nous n’avons que la colonne qui compose directement l’index non cluster. Les colonnes incluses, quant à elles, ne sont pas présentes. Nous retrouvons comme pour un index non cluster classique les pointeurs vers les pages suivantes ainsi que les signets vers la clés de l’index cluster (AddressID).

2- Pour les pages de niveaux feuilles de chaque type d’index : (Il suffit de prendre n’importe quel ID de page au niveau 0).

- Index non cluster classique

On retrouve un schéma classique d’un contenu de page de niveau feuille. Il n’existe évidemment plus de pointeurs de page car nous sommes au niveau feuille.

- Index non cluster avec colonnes incluses

Nous avons exactement la même structure de contenu de page au niveau feuille pour un index non cluster avec colonnes incluses. Pour ce dernier, nous avons cette fois ci toutes les colonnes composants l’index plus les colonnes incluses.

Voilà, nous avons donc vu les différentes notoires qu’il existait entre un index non cluster classique et un index non cluster avec colonnes incluses. Pour ce dernier seul les pages de niveau feuilles hébergent l’ensemble des colonnes de l’index (clé(s) d’index + colonnes incluses), ce qui explique une quantité de stockage plus faible. Dans le cas des tables très volumineuses cela peut être très intéressant car le stockage de l’index sera considérablement réduit et la mise à jour d’une des colonnes incluses n’impactera que le niveau feuille de cet index.

Bien sûr la question qui se pose logiquement par la suite est la suivante : dans ce cas pourquoi ne pas utiliser uniquement des index non cluster avec colonnes incluses ? Je répondrais par ceci : il ne faut pas oublier une règle de base qui stipule qu’un index doit être le plus court possible. En effet, avec un index avec colonnes incluses, même s’il est possible de dépasser la limite des 900 octets, il est cependant déconseiller d’inclure un trop grand nombre de colonnes. La raison en est simple : plus vous ajoutez de colonnes dans votre index plus il faudra de pages pour pouvoir héberger les données de ces mêmes colonnes bien que celles-ci se situent uniquement au niveau feuille. Il y aura donc forcément plus de pages à parcourir pour pouvoir lire les données et selon le cas il risque d’y voir plus de split de pages lors des insertions ou mises à jour de données. Vous l’aurez compris les performances I/O risquent d’être impactées. La création d’un tel index doit, à mon sens, faire l’objet d’une étude approfondie !!!

David BARBARIN (Mikedavem)
Elève ingénieur CNAM
MVP SQL Server