Qu'est-ce qu'un journal des transactions ?
Il existe une exigence dans les systèmes de bases de données relationnelles selon laquelle les transactions doivent être durables. C'est "D" dans les propriétés ACID des transactions. Le système doit s'assurer qu'en cas de plantage soudain, la transaction peut être rejouée. SQL Server répond à cette exigence en capturant toutes les transactions dans un fichier physique appelé fichier journal des transactions .
Essentiellement, chaque fois qu'une transaction est validée, SQL Server enregistre les modifications produites par cette transaction dans un journal des transactions. Même si la transaction n'a pas été conservée dans le fichier de données, elle est disponible dans le journal des transactions et peut être rejouée en cas de plantage soudain.
Modèles de récupération et journaux de transactions
SQL Server fonctionne selon trois modèles de récupération :complète, enregistrée en masse et simple.
En mode de récupération complète, TOUTES les transactions sont enregistrées. Ainsi, la base de données peut être entièrement récupérée en cas de plantage. Cela signifie également que la sauvegarde de la base de données peut être restaurée à un moment précis si la transaction ou la sauvegarde associée est disponible. Sous les modes de récupération complète et en masse, les journaux de transactions sont tronqués chaque fois qu'une sauvegarde de journal est exécutée.
En mode de récupération simple, TOUTES les transactions sont toujours enregistrées. Cependant, l'opération du journal des transactions est tronquée chaque fois que la base de données exécute le point de contrôle.
Un point de contrôle se produit lorsque SQL Server écrit des tampons modifiés dans le fichier de données. Les tampons sales sont des pages essentielles stockées en mémoire qui ont été modifiées par des transactions, telles que l'état en mémoire ne correspond pas à l'état sur le disque. Cependant, nous n'en discuterons pas ici. En mode de récupération simple, SQL Server capture toutes ces modifications dans le journal des transactions pour les conserver jusqu'à ce qu'elles soient persistantes.
La structure du journal des transactions
Le journal des transactions est un fichier physique visible sur la couche du système d'exploitation du serveur sur lequel la base de données SQL Server est hébergée. Chaque base de données possède un journal des transactions, mais il est possible d'en configurer davantage. Le fait est que le fait d'avoir plusieurs journaux SQL de transaction n'apporte aucun avantage en termes de performances. SQL Server écrit dans le journal des transactions de manière séquentielle - un fichier doit être plein avant que le fichier suivant ne soit utilisé. Cependant, plusieurs fichiers se trouvant sur des disques séparés peuvent vous sauver la mise si le premier fichier est plein.
En interne, le fichier journal des transactions est une série de fichiers journaux virtuels. La taille et le nombre de ces fichiers ont un impact sur le temps nécessaire pour sauvegarder la base de données ou la mettre en ligne. Il est toujours judicieux de dimensionner correctement le journal des transactions et de s'assurer que les paramètres de croissance automatique correspondent au niveau d'activité attendu. Ensuite, les croissances de fichiers ne se produiront pas trop souvent.
Qu'est-ce qui fait grossir le journal ?
Commençons par créer une petite base de données en utilisant le code de la liste 1. Le fichier de données fait 4 Mo, le fichier journal fait 2 Mo pour commencer. Vos bases de données de production n'atteindraient jamais cette taille, en particulier avec la pratique populaire de la pré-allocation . Nous avons choisi ces tailles uniquement à des fins de démonstration.
-- Listing 1: Create a Small Database
create database tranlogexperiment
on primary
( name = N'tranlogexperiment', filename = N'C:\MSSQL\Data\tranlogexperiment.mdf', size = 4MB , FILEGROWTH = 1024KB )
log on
( name = N'Test1_log', filename = N'E:\MSSQL\Log\Test1_log.ldf' , size = 2MB , FILEGROWTH = 1024KB );
go
Dans cette base de données, nous créons une seule table pour les autres instructions du langage de manipulation de données (DML) (Liste 2).
-- Listing 2: Create a Table
use tranlogexperiment
go
create table txn_log (
ID int
, FName varchar(50)
, LName varchar(50)
, CountryCode char (2)
)
En exécutant le code de la liste 3, nous vérifions et vérifions ce que nous avons fait.
-- Listing 3: Check Recovery Model and File Sizes
select name, recovery_model_desc, log_reuse_wait_desc from sys.databases where name='tranlogexperiment';
select DB_NAME(database_id) [Database Name]
, type_desc [Database Name]
, name [Logical file Name]
, physical_name [Physical file Name]
, size*8/1024 [File Size (MB)]
, growth*8/1024 [File Growth (MB)]
from sys.master_files where database_id=DB_ID('tranlogexperiment');
Faites attention à la taille du fichier colonne. Nous procédons à l'appel de la croissance du journal des transactions en exécutant INSERT et DELETE 100 000 fois (Liste 4).
-- Listing 4: Create a Small Table
use tranlogexperiment
go
insert into txn_log values (1, 'Kenneth','Igiri', 'NG');
delete from txn_log where ID=1;
go 100000
Le listing 4 insère une seule ligne dans le txn_log table et supprime la même ligne, en répétant cette action 100 000 fois.
Dans l'ensemble, la table n'augmente pas en raison de cette activité, mais le journal des transactions augmente considérablement. Lorsque nous répétons la requête dans le Listing 3 après avoir exécuté l'instruction DML du Listing 4, nous voyons combien le journal des transactions a augmenté :
Le journal des transactions est passé de 4 Mo à 40 Mo en raison de cette activité, même si la taille du fichier de données n'a pas été modifiée. Cela nous montre clairement que la taille du journal des transactions a peu à voir avec la taille des données. L'impact sur la taille provient de l'activité (DML) qui se produit sur la base de données.
Comment gérons-nous les journaux de transactions ?
Les administrateurs de base de données qui gèrent des instances sur site de SQL Server d'installations IaaS doivent sauvegarder régulièrement les journaux de transactions. Il est utile d'avoir les configurations de reprise après sinistre telles que Log Shipping ou AlwaysOn AG . De telles configurations effectuent les sauvegardes automatiquement.
En mode de récupération complète, une sauvegarde du journal SQL Server tronquera les parties du journal des transactions qui ne sont plus nécessaires pour la récupération. La troncation du journal supprime les fichiers journaux virtuels inactifs. De cette façon, il libère de l'espace dans les journaux de transactions pour une réutilisation.
Le code du Listing 6 montre la taille du journal des transactions et la quantité d'espace libre dont nous disposons.
-- Listing 6: Change Recovery Model
USE [tranlogexperiment]
GO
SELECT DB_NAME() AS [Database Name],
name AS [Logical File Name],
type_desc,
size/128.0 AS [Current Size (MB)],
size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS [Free Space (MB)]
FROM sys.database_files
WHERE type IN (0,1);
Nous pouvons également réduire le journal des transactions physique en utilisant le code du Listing 7. Avant de réduire, assurez-vous d'avoir une sauvegarde du journal des transactions. En production, il est préférable de planifier les sauvegardes des journaux pour éviter une croissance physique incontrôlée des fichiers journaux et garantir la préservation des données. Avec l'option de récupération après sinistre comme Log Shipping ou AlwaysOn AG configuré, ceci est déjà accordé.
Nous pouvons interroger le log_reuse_wait_desc colonne sur sys.databases vue du catalogue pour déterminer les conditions qui empêchent la réduction du journal des transactions. Notez que nous avons interrogé cette colonne dans le Listing 3.
Ces conditions peuvent être un point de contrôle en attente, une sauvegarde du journal en attente, une sauvegarde ou une restauration en cours, une transaction active de longue durée et des activités similaires dans la base de données.
-- Listing 7: Change Recovery Model
USE [tranlogexperiment]
GO
DBCC SHRINKFILE (N'Test1_log' , 0, TRUNCATEONLY)
GO
Nous utilisons le code du Listing 8 pour sauvegarder la base de données. Dans notre cas particulier, nous devons d'abord effectuer une sauvegarde complète car les sauvegardes de journaux font toujours référence à une sauvegarde complète. La "dernière" sauvegarde complète démarre la chaîne lorsqu'il s'agit de la restauration ponctuelle.
-- Listing 8: Backup Transaction Log
backup database tranlogexperiment to disk='tranlogexperiment.bkp';
backup log tranlogexperiment to disk='tranlogexperiment_log.trn';
Lors de l'exécution d'une base de données en mode de récupération simple, le journal des transactions est tronqué à chaque point de contrôle . Dans ce mode, les sauvegardes de journaux ne sont pas possibles.
L'emplacement du fichier journal des transactions doit être correctement dimensionné pour prendre en charge les transactions de longue durée qui se produisent occasionnellement. Sinon, le journal des transactions peut encore remplir l'espace disque. La figure 4 montre ce qu'il advient du journal en interne lorsqu'une sauvegarde est effectuée. Notez que le fichier physique fait toujours 40 Mo, mais nous avons maintenant environ 37 Mo d'espace libre.
Que se passe-t-il en mode de récupération simple ?
Maintenant, définissons le tranlogexperiment base de données en mode de récupération simple.
-- Listing 9: Change Recovery Model
use master
go
alter database tranlogexperiment set recovery simple;
Lorsque nous exécutons le code présenté précédemment dans le Listing 4, nous obtenons un comportement légèrement différent.
La figure 6 montre la croissance du journal des transactions en mode de récupération simple lorsque nous exécutons le code du listing 4. La taille du fichier journal physique n'est que de 15 Mo. C'est moitié moins que ce qu'il était sous le modèle de récupération complète plus tôt. Notez également l'espace libre de 11,5 Mo.
Cela signifie-t-il qu'il y a eu moins de croissance du journal ?
Non. La figure 7 montre que pendant l'exécution de la session, notre serveur SQL a également effectué plusieurs points de contrôle . Cela a tronqué le journal et a donné de la place aux transactions pour reprendre la croissance du journal à intervalles réguliers.
Conclusion
Le journal des transactions est un composant extrêmement important d'une base de données SQL Server. Cela a un impact sur tout ce qui nécessite ou repose sur la récupération - sauvegardes, restaurations, reprise après sinistre, etc. Vous pouvez également enregistrer l'activité de la base de données.
Dans cet article, nous avons discuté de la nature du journal des transactions, des aspects de sa gestion correcte et démontré le comportement de DML dans les bases de données avec les modes de récupération complète ou simple en place. Cependant, il y a beaucoup plus à apprendre sur le journal des transactions. Les entrées dans les références seraient un bon point de départ pour vous.
Référence s
- Journal des transactions
- Bases de données et stockage SQL Server
Lire aussi
Importance du journal des transactions dans SQL Server
