Le Blog SQL Server d'ElSüket » DBCC

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.

Une procédure stockée pour connaître l’état des fichiers du journal des transactions

elsuket — Mon, 11 Feb 2013 05:12:22 +0000

Ha ! le fichier du journal des transactions, l’option de récupération, son grossissement, … et bien sûr la fameuse transaction restée ouverte qui a provoqué une explosion de la taille de celui-ci, allant jusqu’à remplir le volume disque qui l’héberge : tout autant de paramétrages et d’investigations fastidieuses.

Alors comme je n’aime pas beaucoup répéter plusieurs fois les mêmes opérations sans avoir un script, ou mieux, une procédure stockée sous la main, j’ai créé la suivante, dont voici le script de création :

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
206
207
208
209
210
211
212
213
214
215

USE master
GO

-----------------------------------------------------------------
-- Nicolas Souquet - 09/02/2013
-- LA PROCEDURE STOCKEE SUIVANTE EST DONNEE EN TANT QUE TELLE
-- SON UTILISATION ET SA MODIFICATION EST A VOS RISQUES ET PÉRILS
-----------------------------------------------------------------
CREATE PROCEDURE [dbo].[sp__log_space_get]
@_database_name sysname = NULL
AS
BEGIN
SET NOCOUNT ON

DECLARE @sql varchar(256)

-- Récupération de l'espace disque disponible
-- sur tous les volumes visibles par l'instance SQL Server
DECLARE @free_disk_space TABLE
(
drive_letter char(1) NOT NULL
, free_space_MB int NOT NULL
)

INSERT INTO @free_disk_space
EXEC master.dbo.xp_fixeddrives

-- Récupération de l'occupation des fichiers des journaux de transaction
-- de toutes les bases de données hébergées par l'instance SQL Server
DECLARE @dbcc_sqlperf_logspace TABLE
(
database_name sysname
, log_size float
, log_space_used_pct decimal (5,2)
, status tinyint
)
INSERT INTO @dbcc_sqlperf_logspace
EXEC ('DBCC SQLPERF(logspace)')

-- Récupération de la liste de tous les fichiers virtuels
-- du fichier du journal des transactions de toutes les bases de données
-- disponibles, hébergées par l'instance SQL Server
DECLARE @dbcc_loginfo TABLE
(
recovery_unit_id tinyint -- new column in SQL Server 2012
, fileid tinyint NOT NULL
, file_size bigint NOT NULL
, start_offset bigint NOT NULL
, f_seq_no bigint NOT NULL
, status tinyint NOT NULL
, parity tinyint NOT NULL
, create_LSN varbinary(max) NOT NULL
)

-- Cas où l'on souhaite réaliser l'audit du fichier du journal des transactions
-- de toutes les bases de données hébergées par l'instance SQL Server
-- Dans ce cas le paramètre d'entrée @_database_name est à NULL
IF @_database_name IS NULL
BEGIN
DECLARE @dbcc_loginfo_all_db TABLE
(
database_name varchar(128)
, log_file_id tinyint
, vlf_count smallint
)

-- Récupération de liste de toutes les bases de données disponibles
-- (pas une capture iOFFLINE, SINGLE_USER, ou ... SUSPECT ;))
INSERT INTO @dbcc_loginfo_all_db
(
database_name
, log_file_id
, vlf_count
)
SELECT D.name
, MF.file_id
, 0
FROM sys.databases AS D
INNER JOIN sys.master_files AS MF
ON D.database_id = MF.database_id
WHERE D.source_database_id IS NULL -- ce n'est pas une capture instantanée de base de données
AND D.state_desc = 'ONLINE' -- la base de données est disponible
AND D.user_access_desc = 'MULTI_USER' -- la base de données est à l'écoute de connexions utilisateur
AND MF.type_desc = 'LOG' -- le type de fichier est "journal des transactions"

-- Pour chaque base de données, récupération de la liste des fichiers virtuels
-- du fichier du journal des transactions pour toutes les bases de données disponibles
WHILE EXISTS
(
SELECT *
FROM @dbcc_loginfo_all_db
WHERE vlf_count = 0
)
BEGIN
SELECT TOP 1 @_database_name = database_name
FROM @dbcc_loginfo_all_db
WHERE vlf_count = 0

SET @sql = 'DBCC LOGINFO (''' + @_database_name + ''')'

INSERT INTO @dbcc_loginfo
EXEC (@sql)

;WITH
CTE AS
(
SELECT fileid
, COUNT(*) AS vlf_count
FROM @dbcc_loginfo
GROUP BY fileid
)
UPDATE @dbcc_loginfo_all_db
SET vlf_count = C.vlf_count
FROM @dbcc_loginfo_all_db AS DLAD
INNER JOIN CTE AS C
ON DLAD.log_file_id = C.fileid
WHERE DLAD.database_name = @_database_name

DELETE FROM @dbcc_loginfo
END

-- Résultat final, avec addition de quelques détails
SELECT LS.database_name
, D.recovery_model_desc
, MF.name AS logical_name
, FDS.drive_letter AS transaction_log_file_stored_on
, FDS.free_space_MB AS volume_free_space_MB
, CAST(LS.log_size AS decimal(38,2)) AS transaction_log_file_size_MB
, LS.log_space_used_pct
, CAST((LS.log_space_used_pct / 100.0) * LS.log_size AS decimal(38,2)) AS log_used_size_MB
, CASE MF.is_percent_growth
WHEN 1 THEN CAST(MF.growth AS varchar(3)) + ' %'
ELSE CAST(MF.growth / 128 AS varchar(20)) + ' MB'
END AS growth
, D.log_reuse_wait_desc
, DLAD.vlf_count
, MF.physical_name
FROM sys.master_files AS MF
INNER JOIN @dbcc_sqlperf_logspace AS LS
ON LS.database_name = DB_NAME(MF.database_id)
INNER JOIN @free_disk_space AS FDS
ON FDS.drive_letter = LEFT(MF.physical_name, 1) COLLATE database_default
INNER JOIN sys.databases AS D
ON D.name = LS.database_name COLLATE database_default
INNER JOIN @dbcc_loginfo_all_db AS DLAD
ON DLAD.database_name = D.name COLLATE database_default
AND DLAD.log_file_id = MF.file_id
AND DLAD.database_name = DB_NAME(MF.database_id)
WHERE MF.type_desc = 'LOG'
AND D.source_database_id IS NULL
AND D.state_desc = 'ONLINE'
AND D.user_access_desc = 'MULTI_USER'
END
ELSE
BEGIN
-- Si la base de données que l'on souhaite auditer n'existe pas ==> exception
IF DB_ID(@_database_name) IS NULL
BEGIN
RAISERROR('The database named ''%s'' does not exist', 16, 1, @_database_name)
RETURN
END

-- récupération de la liste des fichiers virtuels
-- du fichier du journal des transactions de la base de données choisie
DECLARE @vlf_count int
SET @sql = 'DBCC LOGINFO (''' + @_database_name + ''')'

INSERT INTO @dbcc_loginfo
EXEC (@sql)

-- Résultat final, avec addition de quelques détails
;WITH
CTE AS
(
SELECT fileid
, COUNT(*) AS vlf_count
FROM @dbcc_loginfo
GROUP BY fileid
)
SELECT LS.database_name
, D.recovery_model_desc
, MF.name AS logical_name
, FDS.drive_letter AS transaction_log_file_stored_on
, FDS.free_space_MB AS volume_free_space_MB
, CAST(LS.log_size AS decimal(38,2)) AS transaction_log_file_size_MB
, LS.log_space_used_pct
, CAST((LS.log_space_used_pct / 100.0) * LS.log_size AS decimal(38,2)) AS log_used_size_MB
, CASE MF.is_percent_growth
WHEN 1 THEN CAST(MF.growth AS varchar(3)) + ' %'
ELSE CAST(MF.growth / 128 AS varchar(20)) + ' MB'
END AS growth
, D.log_reuse_wait_desc
, C.vlf_count AS VLF_count
, MF.physical_name
FROM sys.master_files AS MF
INNER JOIN @dbcc_sqlperf_logspace AS LS
ON LS.database_name = DB_NAME(MF.database_id)
INNER JOIN @free_disk_space AS FDS
ON FDS.drive_letter = LEFT(MF.physical_name, 1) COLLATE database_default
INNER JOIN sys.databases AS D
ON D.name = LS.database_name COLLATE database_default
INNER JOIN CTE AS C
ON C.fileid = MF.file_id
WHERE MF.type_desc = 'LOG'
AND LS.database_name = @_database_name
AND D.source_database_id IS NULL
AND D.state_desc = 'ONLINE'
AND D.user_access_desc = 'MULTI_USER'
END
END
GO

-- On marque la procédure stockée comme objet système
-- Dès lors, on pourra l'exécuter dans n'importe quel contexte de base de données
EXEC sp_ms_marksystemobject 'sp__log_space_get'

Elle donne un résultat comme le suivant :

à savoir :

– le nom de la base de données
– l’option de récupération de la base de données
– le nom logique du fichier du journal des transactions (utile pour un DBCC SHRINKFILE après que le journal ait explosé en taille)
– le volume sur lequel est hébergé le fichier du journal des transactions
– la quantité d’espace disque libre restant sur ce volume
– la taille actuelle du fichier du journal des transactions
– le pourcentage d’utilisation de ce fichier (taille occupée dans le fichier par rapport à la taille totale du fichier)
– la taille équivalente à ce pourcentage
– le paramètre de grossissement de ce fichier
– ce qui empêche actuellement la troncature de l’espace occupé dans ce fichier
– le chemin complet du fichier

On peut utiliser cette procédure stockée sous SQL Server 2005, 2008 et 2012.
Elle fonctionne également pour les bases de données ayant plusieurs fichiers du journal des transactions

Bonne gestion des fichiers du journal des transactions !

ElSüket