Le Blog SQL Server d'ElSüket » sauvegarde

Sauvegardes cryptées et dans Azure avec SQL Server 2014

elsuket — Fri, 13 Jun 2014 02:28:29 +0000

Microsoft a publié un article que j’ai terminé d’écrire au début de ce mois sur ce sujet.

En plus du fonctionnement du cryptage des sauvegardes, j’y détaille les étapes pour :

Sauvegarder une base de données en cryptant le fichier de sauvegarde
Restaurer une base de données à partir d’une fichier de sauvegarde crypté
Réaliser des sauvegardes cryptées dans Azure
Restaurer une base de données à partir d’une sauvegarde cryptée stockée dans Azure

Finalement, j’y aborde l’impact des divers algorithmes de cryptage sur l’utilisation CPU et la taille des fichiers de sauvegarde.

L’article est en Anglais, et je vais le traduire en Français.

Bonne lecture !

Sauvegardes de bases de données et envoi d’email avec SQL Server Express

elsuket — Sun, 11 May 2014 10:01:01 +0000

Windows Server Update Services (WSUS) est une application qui permet de gérer et distribuer les patch que Microsoft publie pour ses produits. Elle est supportée par SQL Server Express (with Adanced Services), et de ce fait :

On ne dispose pas de l’Agent SQL Server
On ne peut pas utiliser des plans de maintenance pour gérer les sauvegardes
On ne peut pas envoyer d’emails
La compression des fichiers de backup, introduite avec SQL Server 2008, n’est pas prise en charge

Si donc on souhaite planifier les sauvegardes de base de données, et envoyer un email en cas d’échec, on peut :

Remplacer un job de l’Agent SQL Server par une tâche du Planificateur de Tâches de Windows
Écrire une procédure stockée d’assembly pour envoyer des emails

Cet article détaille les étapes à suivre pour ce faire.

Une procédure stockée d’assembly pour envoyer des emails

Si l’Agent SQL Server n’est pas disponible, l’intégration CLR l’est. Ainsi en quelques lignes de code C#, on peut envoyer des e-mails de façon assez similaire à ce qu’on peut faire sous les éditions non-Express de SQL Server avec la procédure stockée système msdb.dbo.sp_send_dbmail.

Pour créer une procédure stockée d’assembly sous Visual Studio 2012 ou ultérieur, il faut tout d’abord installer SQL Server Data Tools. Pour ce faire, vous pouvez lire ce billet. Notez qu’il n’est pas nécessaire d’avoir Visual Studio déjà installé.

Une fois Visual Studio démarré, il suffit de créer un nouveau projet à partir de la page de démarrage, ou bien de suivre File > New > Project, et de choisir un projet SQL Server :

Il faut faire attention à la version du framework .NET. Par exemple, si l’on souhaite que l’assembly soit exécutable par SQL Server 2008, il faut spécifier la version 3.5. Une fois que l’on a validé le tout par OK, nous pouvons ajouter une procédure stockée :

Comme je préfère C# à VB.NET, j’ai choisi une procédure stockée C#, mais si vous préférez VB.NET, rien ne s’y oppose. Notons que par défaut, le langage de la procédure stockée n’est pas pré-sélectionné.

Une fois que l’on a validé le tout par un clic sur Add, on peut écrire :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

using System;
using System.Net;
using System.Net.Mail;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;

public partial class StoredProcedures
{
[Microsoft.SqlServer.Server.SqlProcedure]
public static void spasb_mail_send (string sender, string recipients, string subject, string body)
{
SmtpClient mailServer = new SmtpClient("mail.myCompany.com");

MailMessage mail = new MailMessage(sender, recipients, subject, body);
mail.IsBodyHtml = true;

mailServer.Send(mail);
}
}

Ce qui, même pour l’ultra-débutant C# que je suis, est loin d’être complexe. Avant de builder le projet, il nous faut configurer l’assembly pour lui permettre d’accéder à des ressources externes, ce qui se fait après un clic-droit sur le projet, et choisi Properties (ou pour les aficionados du raccourci clavier, ALT + Entrée). Dans la page SQLCLR, nous commutons donc la liste déroulante Permission Level sur EXTERNAL_ACCESS. De la même façon, dans la page SQLCLR Build, nous commutons la liste déroulante Configuration sur Release, ce qui permet un léger gain de performances. Ce n’est pas très important dans notre cas, mais si l’assembly est plus complexe, cela peut le devenir.

Après un clic sur Build > Build Solution, nous pouvons aller chercher le fichier dll dans le dossier de la solution. Dans cet exemple, il s’agit de D:\SQLServer\Assemblies\SQLServerExpressDatabaseMail\SQLServerExpressDatabaseMail\bin\Debug, et le fichier est nommé SQLServerExpressDatabaseMail.dll.

De retour dans SQL Server Management Studio, une fois connecté à l’instance SQL Server Express, il est tout d’abord nécessaire d’activer la prise en charge de la CLR par cette dernière. Cela se fait sans redémarrage de l’instance, en quelques instruction :

1
2
3
4

EXEC sp_configure 'clr enabled', 1
GO
RECONFIGURE
GO

Il est maintenant requis de déclarer la base de données dans laquelle nous allons enregistrer la procédure stockée d’assembly comme « digne de confiance ». Ceci nous permet d’emprunter l’identité de SQL Server pour exécuter cette procédure qui va accéder à des ressources en dehors de la base de données : en l’occurrence, un serveur de mails (mais ce peut être le système de fichiers, un webservice, …). Là encore, une simple commande suffit :

1
2
3

ALTER DATABASE DBA
SET TRUSTWORTHY ON
GO

Nous devons maintenant enregistrer l’assembly dans la base de données, ce que l’on peut faire une fois que l’on a copié l’assembly dans un dossier de notre choix, sur le serveur hébergeant l’instance SQL Server Express / WSUS. Dans cet exemple, nous utilisons le dossier C:\SQLServer\.

1
2
3
4
5
6
7

USE DBA
GO

CREATE ASSEMBLY SQLServerExpressDatabaseMail
FROM 'C:\SQLServer\SQLServerExpressDatabaseMail.dll'
WITH PERMISSION_SET = EXTERNAL_ACCESS
GO

On peut vérifier l’enregistrement de l’assembly en interrogeant la vue système sys.assemblies. En ce point, on n’a plus besoin du fichier dll : le binaire de celle-ci est maintenant enregistré dans la base de données (de nom DBA dans cet exemple).
Créons maintenant la procédure stockée :

1
2
3
4
5
6
7

CREATE PROCEDURE dbo.spasb_mail_send
@_sender nvarchar(256)
, @_recipients nvarchar(256)
, @_subject nvarchar(256)
, @_body nvarchar(4000)
AS EXTERNAL NAME SQLServerExpressDatabaseMail.StoredProcedures.spasb_mail_send
GO

Et testons enfin :

1
2
3
4
5

EXEC dbo.spasb_mail_send
'it@myCompany.com'
, 'me@myCompany.com'
, 'Test Mail from Assembly Stored Procedure'
, 'Hey Hey !'

Une procédure stockée pour gérer les sauvegardes

Voici une procédure stockée générique qui permet de sauvegarder une base de données en particulier, ou toutes les bases de données hébergées par une instance SQL Server. Dans le second cas, les sauvegardes du fichier du journal des transactions n’est pas supportée. En revanche, on peut exécuter cette procédure stockée sur toutes les versions de SQL Server, à partir de 2005. Enfin, le cryptage des sauvegardes, introduit avec SQL Server 2014 n’est pas supporté non plus. Cela exige que quelques prérequis soient en place, et ceux-là sortent du cadre de cet article.

La procédure stockée d’assembly est référencée dans le bloc CATCH final : pour toute erreur, on envoie un email.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205

CREATE PROCEDURE dbo.databaseBackup_manage
@_backup_type varchar(12)
, @_database_name varchar(128) = NULL
, @_backup_server_network_path varchar(256)
, @_print_only bit = 0
AS
BEGIN
SET NOCOUNT ON

DECLARE @sql nvarchar(4000)
, @err_msg nvarchar(2048)
, @compression bit
, @checkum bit
, @mail_subject nvarchar(4000) = @@SERVERNAME + ' Backups'

-- SQL Server 2005 ne supporte pas l'affectation directe de valeurs*
-- à des variables lors de la déclaration
SELECT @compression = 0

BEGIN TRY
-- Gestion de la compression des sauvegardes
IF
(
(
-- SQL Server 2008 Enterprise et Developer
CAST(SERVERPROPERTY('ProductVersion') AS varchar(32)) LIKE '10.0%'
AND
(
CAST(SERVERPROPERTY('Edition') AS varchar(64)) LIKE 'Enterprise%'
OR CAST(SERVERPROPERTY('Edition') AS varchar(64)) LIKE 'Developer%'
)
)
OR
(
-- SQL Server 2008 R2 Enterprise, Standard et Developer
-- Et toute version après celle-ci
(
CAST(SERVERPROPERTY('ProductVersion') AS varchar(32)) LIKE '10.50%'
OR CAST(REPLACE(LEFT(CAST(SERVERPROPERTY('ProductVersion') AS varchar(32)), 2), '.', '') AS tinyint) > 10
)
AND
(
CAST(SERVERPROPERTY('Edition') AS varchar(64)) LIKE 'Enterprise%'
OR CAST(SERVERPROPERTY('Edition') AS varchar(64)) LIKE 'Standard%'
OR CAST(SERVERPROPERTY('Edition') AS varchar(64)) LIKE 'Developer%'
)
)
)
BEGIN
SET @compression = 1
END

-- Vérifie que le chemin réseau commence par un double anti-slash
IF @_backup_server_network_path NOT LIKE '\\%'
BEGIN
SET @err_msg = 'The network path ' + @_backup_server_network_path + ' is not valid.'
RAISERROR(@err_msg, 16, 1)
END

-- Ajoute l'anti-slash à la fin du chemin réseau, le cas échéant
SELECT @_backup_server_network_path = @_backup_server_network_path + CASE
WHEN CHARINDEX('\', REVERSE(@_backup_server_network_path)) > 1 THEN '\'
ELSE ''
END

IF @_database_name IS NOT NULL
BEGIN
--------------------------------------------------
-- Sauvegarde d'une base de données en particulier
--------------------------------------------------
IF NOT EXISTS
(
SELECT *
FROM sys.databases
WHERE name = @_database_name
)
BEGIN
SET @err_msg = 'La base de données ''' + @_database_name + ''' n''existe pas.'
RAISERROR(@err_msg, 16, 1)
END

IF NOT EXISTS
(
SELECT *
FROM sys.databases
WHERE name = @_database_name
AND state_desc = 'ONLINE'
AND user_access_desc = 'MULTI_USER'
AND source_database_id IS NULL -- La base de données n'est pas un snapshot
AND database_id 2 -- La base de données n'est pas TempDB
)
BEGIN
SET @err_msg = 'La base de données ''' + @_database_name + ''' n''est pas disponible ou est une capture intantanée.'
RAISERROR(@err_msg, 16, 1)
END

-- Vérifie le type de backup
IF @_backup_type NOT IN('FULL', 'DIFFERENTIAL', 'LOG')
BEGIN
SET @err_msg = 'The backup type ''' + @_backup_type + ''' is invalid.'
RAISERROR(@err_msg, 16, 1)
END

SET @sql = 'BACKUP ' + CASE
WHEN @_backup_type IN ('FULL', 'DIFFERENTIAL') THEN 'DATABASE '
WHEN @_backup_type = 'LOG' THEN 'LOG '
END + @_database_name
+ ' TO DISK = ''' + @_backup_server_network_path + REPLACE(@@SERVERNAME, '\', '_') + '\' + @_database_name + '_' + @_backup_type + '_'
+ REPLACE(REPLACE(CONVERT(char(19), GETDATE(), 120), ':', '-'), ' ', '_') + '.bak'''
+ ' WITH ' + CASE @_backup_type
WHEN 'DIFFERENTIAL' THEN 'DIFFERENTIAL, '
WHEN 'FULL' THEN 'INIT, '
ELSE ''
END + CASE @compression WHEN 1 THEN 'COMPRESSION, ' ELSE '' END
+ 'CHECKSUM'

IF @_print_only = 1
BEGIN
PRINT @sql
END
ELSE
BEGIN
BEGIN TRY
EXEC sp_executesql @sql
END TRY
BEGIN CATCH
SET @err_msg = @_database_name + ' | ' + ERROR_MESSAGE()
RAISERROR(@err_msg, 16, 1)
END CATCH
END
END
ELSE
BEGIN
--------------------------------------------------------
-- Sauvegarde de toutes les bases de données disponibles
--------------------------------------------------------
IF @_backup_type = 'LOG'
BEGIN
SET @err_msg = 'On ne prend pas une sauvegarde du fichier du journal des transactions de toutes les bases de données.'
RAISERROR(@err_msg, 16, 1)
END

DECLARE @database_list TABLE
(
database_name varchar(128)
)

INSERT INTO @database_list
(
database_name
)
SELECT REPLACE(name, ' ', '') -- Certaines bases de données ne respectent pas la convention de nommage SQL ANSI.
FROM sys.databases
WHERE source_database_id IS NULL -- La base de données n'est pas un snapshot
AND state_desc = 'ONLINE'
AND user_access_desc = 'MULTI_USER'
AND database_id 2 -- On exclut TempDB

WHILE EXISTS
(
SELECT *
FROM @database_list
)
BEGIN
SELECT TOP 1 @_database_name = database_name
FROM @database_list

SET @sql = 'BACKUP DATABASE ' + @_database_name
+ ' TO DISK = ''' + @_backup_server_network_path + REPLACE(@@SERVERNAME, '\', '_') + '\' + @_database_name + '_' + @_backup_type + '_'
+ REPLACE(REPLACE(CONVERT(char(19), GETDATE(), 120), ':', '-'), ' ', '_') + '.bak'''
+ ' WITH ' + CASE @_backup_type
WHEN 'DIFFERENTIAL' THEN 'DIFFERENTIAL, '
WHEN 'FULL' THEN 'INIT, '
END + CASE @compression WHEN 1 THEN 'COMPRESSION, ' ELSE '' END
+ 'CHECKSUM'

IF @_print_only = 1
BEGIN
PRINT @sql
END
ELSE
BEGIN
BEGIN TRY
EXEC sp_executesql @sql
END TRY
BEGIN CATCH
SET @err_msg = @_database_name + ' | ' + ERROR_MESSAGE()
RAISERROR(@err_msg, 16, 1)
END CATCH
END

DELETE FROM @database_list
WHERE database_name = @_database_name
END
END
END TRY
BEGIN CATCH
-- Envoie un email en cas d'erreur
EXEC dbo.spasb_mail_send
@_sender = 'it@myCompany.com'
, @_recipients = 'it@myCompany.com'
, @_subject = @mail_subject
, @_body = @err_msg
END CATCH
END

Remplacer l’Agent SQL Server par le Planificateur de Tâches de Windows

Nous voilà à l’étape finale : prendre des sauvegardes de base de données régulièrement. Pour ce faire, on peut tout à fait utiliser le Planificateur de Tâches de Windows : en effet, on peut appeler l’utilitaire en ligne de commandes SQLCMD (la documentation, l’utilisation, et un exemple), qui permet d’interagir avec une instance SQL Server. Cet outil permet de passer en paramètre un script, d’exécuter une requête, mais surtout d’enregistrer la sortie dans un fichier. Cette dernière fonctionnalité facilite la tâche d’investigation sur l’échec d’exécution de code.

Une fois l’application Planificateur de Tâches démarrée, on créé une tâche assez simplement :

Une fois passé la première page ou nous nommons la tâche, un clic sur Next nous amène à la planification. Pour Windows Server Update Services, on peut estimer qu’une sauvegarde complète par jour est suffisante. Évidemment, cela varie avec la criticité de l’application. Nous spécifions donc une exécution quotidienne :

Nous planifions l’exécution à minuit et une minute :

Et nous choisissons de démarrer une application :

Dans la saisie texte Program / Script, nous spécifions l’invite de commandes. En ce qui concerne les arguments, nous écrivons :

Pour SQL Server 2008 :
"C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLCMD.EXE"
Pour SQL Server 2012 :
"C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SQLCMD.EXE"
Pour SQL Server 2014 :
"C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\110\Tools\Binn\SQLCMD.EXE"

En ce qui concerne les arguments, nous passons :

sqlcmd -E -S WSUS -i "C:\SQLServer\WSUSBackup.sql" -o "C:\SQLServerBackup\FullBackupLog.txt"

Attention, la casse des options est importante.

-E pour spécifier une connexion approuvée
-S : l’instance SQL Server à laquelle on souhaite se connecter
-i : le chemin et le nom du fichier de script T-SQL
-o : le fichier qui capturera les libellés des messages d’information, d’avertissement ou d’erreurs, le cas échéant

Ce qui donne :

Un clic sur Next nous offre une fenêtre de résumé, et on peut valider le tout. Si l’on souhaite ajouter des planifications ou modifier d’autres options pour cette tâche, il suffit de cocher la case Open the Properties dialog for this task when I click Finish.

Nous créons ensuite un fichier WSUSBackup.sql dans un répertoire C:\SQLServer\ sur la machine qui héberge l’application WSUS. Ce fichier appelle la procédure stockée DBA.dbo.databaseBackup_manage comme suit :

EXEC DBA.dbo.databaseBackup_manage 'FULL', NULL, '\\monPartageDeBackup\', 0

Et voilà nos sauvegardes de base de données en place.

Utiliser PowerShell pour supprimer les fichiers de sauvegardes trop anciens

Dans la liste des actions de la tâche que nous venons de créer, nous pouvons en ajouter une qui aura :

Pour programme : powershell
Pour arguments : -file "C:\SQLServer\DeleteOldBackupFiles.ps1"

Le fichier DeleteOldBackupFiles.ps1 contient la commande suivante, qui supprime tous les fichiers créés il y a plus de 7 jours, y compris dans les sous-dossiers du partage de backup (-Recurse) :

Get-ChildItem '\\monPartageDeBackup\' -Recurse | Where {$_.CreationTime -lt (Get-Date).AddDays(-7)} | Remove-Item -Force

Par défaut, PowerShell ne permet pas l’exécution de scripts. Pour l’autoriser, il faut démarrer l’interface PowerShell, et exécuter Set-ExecutionPolicy RemoteSigned (en accord avec votre Administrateur Systèmes !).

Retenons également que les statistiques de colonne et d’index de la base de données supportant WSUS ne sont pas maintenues. Ce sera probablement suffisant pour générer une lenteur après quelques mois d’exploitation, dont votre Administrateur Systèmes vous demandera l’origine

ElSüket.

Vous êtes sûr d’avoir les BACKUP avec CHECKSUM parce que vous utilisez l’option COMPRESSION ? Vérifiez une seconde fois !

elsuket — Sun, 26 May 2013 13:32:34 +0000

Après avoir vu comment compresser toutes les sauvegardes de base de données dès SQL Server 2008, il est intéressant de trouver comment activer l’option CHECKSUM de l’instruction BACKUP.

A ce sujet, la documentation indique :

Indique que l’opération de sauvegarde vérifie dans chaque page les informations de somme de contrôle et de page endommagée, si elles sont activées et disponibles, et génère une somme de contrôle pour l’ensemble de la sauvegarde. Ceci est le comportement par défaut pour une sauvegarde compressée.

Vérifions donc si cela est vrai : nous allons créer une base de données de test, et nous allons corrompre une de ses pages afin de vérifier le comportement de la sauvegarde. En effet, l’option CHECKSUM permet de détecter la corruption de données au moment de la sauvegarde. Cela permet en plus de ne pas se retrouver dans l’inconfortable situation de devoir restaurer une base de données à partir d’un fichier de sauvegarde corrompu.

La vérification de l’intégrité des pages au niveau de la base de données

Par défaut, lorsqu’on crée une nouvelle base de données sous SQL Server 2005 et suivants, la vérification de l’intégrité des pages lues à partir du disque se fait à l’aide d’une somme de contrôle. Celle-ci est calculée à partir du contenu de la page, puis écrite dans l’en-tête de celle-ci au moment de l’écriture sur disque. Lorsque la page est ensuite lue à partir du disque, la somme de contrôle est recalculée, puis comparée à celle qui est dans l’en-tête de la page : si les valeurs sont identiques, alors la page est intègre; à l’inverse, on obtient l’erreur 824, qui est écrite à la fois dans les journaux de SQL Server et dans le journal d’événements de Windows.
Enfin lorsqu’on restaure une base de données qui a été créée sous une version antérieure à 2005, il est important de changer cette option de TORN_PAGE_DETECTION à PAGE_VERIFY, car la première est conservée par défaut. L’option TORN_PAGE_DETECTION stocke deux bits pour chaque secteur de 512 octets de toute page, dont la taille est 8192 octets. De la même façon, ces 16 * 2 bits sont stockés dans l’en-tête de la page, et comparés à la relecture de la page. Comme cette option est moins stricte que CHECKSUM, il est donc recommandé d’utiliser cette dernière option.

Le test

Nous créons donc la base de données sous SQL Server 2012, puis nous vérifions l’option du contrôle de l’intégrité des pages :

1
2
3
4
5
6
7
8
9
10

CREATE DATABASE TEST_CHECKSUM;
GO

USE TEST_CHECKSUM
GO

SELECT name
, page_verify_option_desc
FROM sys.databases
WHERE name = 'TEST_CHECKSUM'

Nous créons ensuite une table dans cette base de données, à laquelle nous ajoutons une ligne :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

USE TEST_CHECKSUM
GO

CREATE TABLE test_backup_checksum
(
id tinyint IDENTITY
, nom varchar(16)
)
GO

INSERT INTO dbo.test_backup_checksum (nom)
VALUES ('test_checksum')
GO

SELECT *
FROM dbo.test_backup_checksum

Nous forçons ensuite l’écriture des pages sur disque, à l’aide de l’instruction CHECKPOINT, puis nous vidons le cache de données, de sorte que la prochaine fois que nous exécuterons une requête sur cette table, ses pages seront lues à partir du disque, à l’aide de l’instruction DBCC DROPCLEANBUFFERS.

N.B. : N’exécutez JAMAIS une instruction non-documentée sur une base de données qui sert une charge de production. Si tel devait être le cas, je ne peux en aucun cas être tenu pour responsable des conséquences. Vous devez limiter strictement l’usage de cette instruction aux environnements de test.

1
2
3
4
5

CHECKPOINT
GO

DBCC DROPCLEANBUFFERS
GO

L’instruction DBCC IND, ou la DMF sys.dm_db_database_page_allocations

Encore deux options d’exploration de la mécanique interne de SQL Server, qui permettent de lister les pages d’une table ou d’un index, et qui ne sont pas documentées. Voici le prototype d’utilisation de ces deux alternatives :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

DBCC IND ('TEST_CHECKSUM', 'dbo.test_backup_checksum', 1) -- le dernier argument est l'index id
GO

SELECT allocated_page_file_id
, allocated_page_page_id
, allocated_page_iam_file_id
, allocated_page_iam_page_id
, object_id
, index_id
, partition_id
, allocation_unit_type_desc AS iam_chain_type
, page_type_desc
, page_level
, rowset_id
, next_page_file_id
, next_page_page_id
, previous_page_file_id
, previous_page_page_id
FROM sys.dm_db_database_page_allocations
(
DB_ID('TEST_CHECKSUM')
, OBJECT_ID('dbo.test_backup_checksum')
, 0 -- index id : 0 pour un tas, 1 pour un index cluster, plus grand pour un index non-cluster
, NULL -- partition id
, 'DETAILED' -- niveau de détail
)
WHERE is_allocated = 1;

On remarque tout de suite que la DMF produit bien plus d’informations que l’instruction DBCC (nous ne donnons pas ici toutes les colonnes), et que ses arguments sont similaires à la DMF sys.dm_db_index_physical_stats.

Voyons donc ce que contient la page 272, puisque c’est elle qui contient les données (page_type_desc = DATA_PAGE) :

1
2
3
4
5
6
7
8

-- Activation de la sortie de la commande DBCC
DBCC TRACEON (3604)
GO

-- DBCC PAGE ([database_name_or_id], [file_id], [page_id], [option])
-- option = 0 montre seulement l'en-tête de la page
DBCC PAGE ('TEST_CHECKSUM', 1, 272, 0);
GO

Nous obtenons :

PAGE: (1:272)

BUFFER:

BUF @0x000000027407BB80

bpage = 0x00000002649F4000 bhash = 0x0000000000000000 bpageno = (1:272)
bdbid = 8 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 33295 bstat = 0x9
blog = 0x2121215a bnext = 0x0000000000000000

PAGE HEADER:

Page @0x00000002649F4000

m_pageId = (1:272) m_headerVersion = 1 m_type = 1
m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8200
m_objId (AllocUnitId.idObj) = 84 m_indexId (AllocUnitId.idInd) = 256
Metadata: AllocUnitId = 72057594043432960
Metadata: PartitionId = 72057594039042048 Metadata: IndexId = 0
Metadata: ObjectId = 245575913 m_prevPage = (0:0) m_nextPage = (0:0)
pminlen = 5 m_slotCnt = 1 m_freeCnt = 8069
m_freeData = 121 m_reservedCnt = 0 m_lsn = (30:345:30)
m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0
m_tornBits = 1209479828 DB Frag ID = 1

Si nous nous en référons à la documentation donnée par Paul Randal, nous avons bien :

– m_flagBits = 0x8200, qui indique que l’intégrité de la page est vérifiée par somme de contrôle
– m_tornBits est la somme de contrôle de cette page

Nous allons maintenant mettre la base de données hors-ligne, puis éditer le fichier de données avec un éditeur hexadécimal, de façon à vérifier si SQL Server vérifie bien la somme à la lecture de la page :

1 2	ALTER DATABASE SET OFFLINE GO

En ce qui concerne la lecture en hexadécimal, j’utilise le logiciel Hex Editor XVI32. Une fois l’outil ouvert en tant qu’administrateur, il suffit de chercher la chaîne que nous avons ajouté comme ligne dans la table, en suivant le menu Search / Find :

Un clic sur le bouton OK nous amène directement à l’emplacement, où l’on est alors libre de changer la chaîne, où j’ai changé le « k » en « d », puis sauvé le fichier :

Nous remettons la base de données en ligne :

1
2
3

ALTER DATABASE TEST_CHECKSUM
SET ONLINE
GO

Aucun problème. Exécutons un SELECT * FROM dbo.test_backup_checksum. Nous obtenons le message suivant :

Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xf9ec3284; actual: 0xfe6c3284). It occurred during a read of page (1:228) in database ID 7 at offset 0x000000001c8000 in file ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TEST_CHECKSUM.mdf’. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

Prenons maintenant une sauvegarde de cette base de données, avec COMPRESSION, mais sans spécifier l’option CHECKSUM :

1
2
3
4

BACKUP DATABASE TEST_CHECKSUM
TO DISK = 'F:\SQLServer2012\TEST_CHECKSUM.bak'
WITH COMPRESSION
GO

Aucun problème : nous obtenons :

Processed 280 pages for database ‘TEST_CHECKSUM’, file ‘TEST_CHECKSUM’ on file 1.
Processed 3 pages for database ‘TEST_CHECKSUM’, file ‘TEST_CHECKSUM_log’ on file 1.
BACKUP DATABASE successfully processed 283 pages in 0.468 seconds (4.709 MB/sec).

Voyons ce que contient la table d’historique des sauvegardes :

1
2
3
4
5
6
7

SELECT user_name
, backup_start_date
, recovery_model
, has_backup_checksums
, is_damaged
FROM msdb.dbo.backupset
WHERE database_name = 'TEST_CHECKSUM'

On obtient un résultat similaire avec l’instruction RESTORE HEADERONLY (colonnes HasBackupChecksums et IsDamaged toutes deux à zéro) :

1 2	RESTORE HEADERONLY FROM DISK = 'F:\SQLServer2012\TEST_CHECKSUM.bak'

Le fichier de sauvegarde ne dispose pas de la somme de contrôle, et n’est pas marqué comme endommagé. Pourtant nous avons bien corrompu le fichier de données, et nous ne pouvons pas lire la table que nous avons peuplé auparavant !

Voyons ce que produit la même instruction, avec l’option CHECKSUM :

1
2
3
4

BACKUP DATABASE TEST_CHECKSUM
TO DISK = 'F:\SQLServer2012\TEST_CHECKSUM_CC.bak'
WITH COMPRESSION, CHECKSUM
GO

Msg 3043, Level 16, State 1, Line 1
BACKUP ‘TEST_CHECKSUM’ detected an error on page (1:228) in file ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TEST_CHECKSUM.mdf’.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Voyons maintenant la même instruction, seulement avec l’option CHECKSUM :

1
2
3
4

BACKUP DATABASE TEST_CHECKSUM
TO DISK = 'F:\SQLServer2012\TEST_CHECKSUM_CHK.bak'
WITH CHECKSUM
GO

Nous obtenons la même erreur. Si nous interrogeons de nouveau la table d’historique des sauvegardes pour cette base de données, nous ne trouvons que le premier backup, dont on sait qu’il est corrompu. Pourtant nous n’avons (presque) aucun moyen de le savoir, car ni cette table, ni l’instruction RESTORE HEADERONLY ne permettent de vérifier que le fichier est bien intègre. On peut cependant vérifier les journaux de SQL Server à l’aide de la procédure stockée étendue xp_readerrorlog, où l’on trouve :

Détecter la corruption le plus tôt possible

Une des premières choses à faire après avoir réalisé une installation fraîche de SQL Server est d’ajouter une liste d’alertes de l’Agent SQL Server, qui enverront un mail dès la détection d’un problème de corruption. Ceci nécessite le paramétrage de Database Mail, et la mise en place d’un opérateur SQL Agent. Voici le code qui permet d’ajouter l’alerte :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

-------------------------------
-- Nicolas Souquet - 26/05/2013
-------------------------------
DECLARE @i smallint = 823
, @alert_name sysname

DECLARE @operator_name sysname = 'monOperateur'

WHILE @i <= 825
BEGIN
SELECT @alert_name = 'Message ' + CAST(@i AS char(3))

EXEC msdb.dbo.sp_add_alert
@name = @alert_name
, @message_id = @i
, @severity = 0
, @enabled = 1
, @delay_between_responses = 0
, @include_event_description_in = 1
, @job_id = N'00000000-0000-0000-0000-000000000000'

EXEC msdb.dbo.sp_add_notification
@alert_name = @alert_name
, @operator_name = @operator_name
, @notification_method = 1

SET @i = @i + 1
END

L’erreur qui nous intéresse est la 824, mais les erreurs 823 et 825 sont importantes aussi. Pour trouver leur signification, il suffit d’interroger la vue système sys.messages :

1
2
3
4

SELECT *
FROM sys.messages
WHERE message_id BETWEEN 823 AND 825
AND language_id = 1036 -- Français

On peut faire de même avec l’erreur n° 3043, qui est celle que l’on obtient lors de la sauvegarde.

Activer CHECKSUM pour toutes les sauvegardes

Cela devrait aussi faire partie de la checklist d’installation de SQL Server, d’autant que c’est d’une simplicité enfantine : il suffit d’activer le drapeau de trace n° 3023 :

1	DBCC TRACEON (3023, -1)

Après avoir exécuté cette instruction, si nous ré-exécutons maintenant la commande suivante :

1
2
3
4

BACKUP DATABASE TEST_CHECKSUM
TO DISK = 'F:\SQLServer2012\TEST_CHECKSUM.bak'
WITH COMPRESSION
GO

Nous obtenons l’erreur que nous avions obtenue lorsque nous avions ajouté l’option CHECKSUM :

Msg 3043, Level 16, State 1, Line 1
BACKUP ‘TEST_CHECKSUM’ detected an error on page (1:228) in file ‘C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\TEST_CHECKSUM.mdf’.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.

Ceci est très pratique :

– Si l’on prend les sauvegardes de base de données à l’aide de plans de maintenance, il est impossible de spécifier que l’on souhaite avoir la somme de contrôle;
– Si l’on code une procédure stockée qui s’en charge, cela évite d’avoir à l’ajouter dans le code.

D’autre part si la compression des sauvegardes est activée au niveau de l’instance, on n’a plus qu’a se soucier de la sauvegarde elle-même !

Bonnes sauvegardes et intégrité de pages à tous !

ElSüket.