La fonction qui tue:

Dans un article précédent, nous avons couvert une fonction table valuée fort intéressante qui permet de relire à l’intérieur d’une sauvegarde de journal: fn_dump_dblog(). Nous allons nous en servir pour connaître cette fois l’identité du coupable. La table concernée par le DELETE est la table T1, il faut commencer par récupérer sa valeur de allocation_unit_id:

select allocation_unit_id from sys.allocation_units AU inner join sys.partitions P
on P.hobt_id = AU.container_id where P.object_id = object_id('T1')

allocation_unit_id
---------------------
72057594043301888

Ensuite, rechercher dans les backups transactionnels des opérations de suppression de lignes sur cet objet:

select [Current LSN] ,Operation ,[Transaction ID] ,AllocUnitId
from fn_dump_dblog(DEFAULT, DEFAULT,DEFAULT, DEFAULT,
'C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery.TRAN2.bak',
DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT) where Operation  = 'LOP_DELETE_ROWS' and AllocUnitId = 72057594043301888

Current LSN             Operation          Transaction ID AllocUnitId         
----------------------- ------------------ -------------- --------------------
00000025:00000032:0003  LOP_DELETE_ROWS    0000:00000a9d  72057594043301888   
00000025:00000032:0005  LOP_DELETE_ROWS    0000:00000a9d  72057594043301888   
00000025:00000032:0006  LOP_DELETE_ROWS    0000:00000a9d  72057594043301888   
00000025:00000032:0007  LOP_DELETE_ROWS    0000:00000a9d  72057594043301888   
00000025:00000032:0008  LOP_DELETE_ROWS    0000:00000a9d  72057594043301888   
...

On récupère le LSN de la transaction pour retrouver le BEGIN TRAN correspondant:  0000:00000a9d:

select [Current LSN] ,Operation ,[Transaction ID] ,AllocUnitId
 ,[Begin Time] ,[Transaction Name] ,[End Time] ,[Description]
 ,[Transaction SID]
from fn_dump_dblog(DEFAULT, DEFAULT,DEFAULT, DEFAULT,
'C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery.TRAN2.bak',
DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
where Operation  = 'LOP_BEGIN_XACT' and [Transaction ID] = '0000:00000a9d'

Current LSN             Operation                       Transaction ID AllocUnitId        
----------------------- ------------------------------- -------------- --------------------
00000025:00000032:0001  LOP_BEGIN_XACT                  0000:00000a9d  NULL                

 Begin Time               Transaction Name                  Description                                  
------------------------ --------------------------------- -----------------------------------------------
2011/10/05 15:21:50:510  tralalala                         tralalala;0x75a770d73d6bf54bb0dc07725254ae57    

Transaction SID
------------------------------------
0x75A770D73D6BF54BB0DC07725254AE57

Remarque intéressante, [Transaction SID] (en rouge) correspond au SID de l’utilisateur dans la base…

Le dénouement…

Il ne reste plus qu’à dégainer la requête sur sys.database_principals:

select name from sys.database_principals where sid = 0x75A770D73D6BF54BB0DC07725254AE57

name
-------------------
user1

A+Continuez votre lecture sur le blog :

• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Msg 2508, Level 16, State 1: the In-Row data %% for object %% is incorrect (David BAFFALEUF) [SQL Server]
• Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David BAFFALEUF) [SQL Server]
• How-To: réduire la taille du journal de transactions sur disque (David BAFFALEUF) [SQL Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]

Ici nous allons aborder le troisième mode BULK-LOGGED, ses avantages, inconvénients et contextes d’utilisation. Quelques rappels du post précédent:

BULK-LOGGED: c’est un mode à combiner avec le mode FULL. Dans ce mode, les opérations de modification de masse ne sont pas complètement journalisées, et l’impact de telles opérations sur le journal est limité. Le fait de changer de FULL à BULK-LOGGED ne modifie en rien ma façon de sauvegarder mes bases. En mode BULK-LOGGED, mes sauvegardes transactionnelles horaires continuent de s’exécuter sans problème. Très utile lorsqu’on lance notre réorganisation des indexes hebdomadaire car on gagne un temps fou.

Quelles sont ces opérations de modification de masse:

1. SELECT INTO
2. BCP IN / BULK INSERT
3. ALTER INDEX … REBUILD
4. Manipulation de champs de type TEXT:

On les appelle parfois par abus de langage opérations non loggées, le terme plus juste est minimallement loggées.

Lorsqu’une de ces opérations minimalement loggée est exécutée, seules les allocations de pages sont journalisées, mais elles seules ne suffisent pas à restaurer l’intégralité de mon reindex ou de mon select into en cas de crash. C’est pourquoi pour permettre de restaurer ces données modifiées, la sauvegarde embarque avec elle les pages de données allouées lors de l’opération.

Pour le vérifier, on se propose de comparer sous les deux modes de récupération FULL et BULK_LOGGED, deux opérations minimalement loggées :

1. Un SELECT INTO d’une table de 2,6 millions de lignes dans une table d’archive.
2. Le rebuild d’un index clusterisé sur une table de 2,6 millions de lignes.

Dans chaque cas, nous allons mesurer plusieurs choses :

1. Le temps d’exécution de l’opération.
2. L’impact sur le journal de transactions (en Mb).
3. L’impact sur la taille de ma sauvegarde de transaction (en Mb).

1) En mode de récupération FULL :

Pour pouvoir exécuter la sauvegarde du journal à l’issue de chaque opération, il faut commencer par exécuter une sauvegarde complète (voir article précédent) :

ALTER DATABASE CAPDATA SET RECOVERY FULL

BACKUP DATABASE CAPDATA TO DISK='C:\YUKON\BACKUP\CAPDATA.bak'
WITH init, stats

Ensuite on va vérifier que l’on part sur un journal vide :

dbcc sqlperf(logspace)

Database Name        Log Size (MB) Log Space Used (%) Status
----------------------------------------------------------------------------------------------
CAPDATA            49,99219      2,951633           0

Le journal fait 50Mb, il est vide (2%). On peut donc lancer le SELECT INTO :

set statistics time on
select * into PIECEAPPARTEMENT2 from PIECEAPPARTEMENT

 SQL Server parse and compile time: 

 CPU time = 0 ms, elapsed time = 48 ms.

  SQL Server Execution Times:

 CPU time = 7641 ms, elapsed time = 57673 ms.

 (2644317 row(s) affected)

Quelle est la taille du journal ?

dbcc sqlperf(logspace)

Database Name        Log Size (MB) Log Space Used (%) Status
----------------------------------------------------------------------------------------------

CAPDATA             97,55469       93,43568            0

Il est passé de 50 à 97 Mb, et il est plein. Sauvegardons la transaction pour le vider :

BACKUP LOG CAPDATA TO DISK='C:\YUKON\BACKUP\CAPDATA.trn' with init, stats

(…)

BACKUP LOG successfully processed 11592 pages in 25.525 seconds (3.720 MB/sec).

11592 * 8192 ~= 93 Mb, soit la taille de ma transaction dans mon journal. Normal. Une fois la sauvegarde effectuée, on repart sur un journal vide. On peut donc lancer immédiatement le REBUILD de l’index sur PIECEAPPARTEMENT :

ALTER INDEX PK_PIECEAPPARTEMENT ON PIECEAPPARTEMENT REBUILD WITH (SORT_IN_TEMPDB = ON)

 SQL Server Execution Times:

 CPU time = 11828 ms, elapsed time = 66788 ms.

A nouveau le journal est plein et si je le sauvegarde encore, la taille du fichier sera égale à la taille de ma transaction.

dbcc sqlperf(logspace)

 Database Name      Log Size (MB)     Log Space Used (%)    Status

----------------------------------------------------------------------------------------------

CAPDATA             97,55469          92,42763               0

2) En mode de récupération BULK_LOGGED :

Même scénario mais cette fois la base est passée en mode de récupération BULK_LOGGED, et mon journal est vide. Pour partir sur la même enveloppe initiale, et ne pas fausser les résultats pour le SELECT INTO, je vais réduire la taille de mon journal à sa taille de départ (50Mb) :

dbcc shrinkfile('CAPDATA_log01',50)

DbId   FileId       CurrentSize MinimumSize UsedPages    EstimatedPages

------ ----------- ----------- ----------- ----------- --------------

6      2        6400           6400        6400          6400

Et je lance le SELECT INTO :

SQL Server Execution Times:

 CPU time = 8235 ms, elapsed time = 24353 ms.

 (2644317 row(s) affected)

Déjà, il a mis deux fois moins de temps. Voyons voir la situation du journal :

dbcc sqlperf(logspace)

 Database Name Log Size (MB) Log Space Used (%) Status

----------------------------------------------------------------------------------------------

CAPDATA       49,99219      3,073722             0

Quasiment rien n’a été utilisé !! Non seulement l’enveloppe n’a pas bougé mais en plus mon journal est toujours quasiment vide. J’en profite pour regarder ce qui se trouve dans ces 3% de journal utilisé:

select Operation, COUNT(*) nr_records, SUM([Log Record Length]) totalsize

from ::fn_dblog(null,null) 

group by Operation order by COUNT(*) desc

Operation                       nr_records  totalsize

------------------------------- ----------- -----------

LOP_SET_FREE_SPACE              11111       577772

LOP_SET_BITS                    5650        328272

LOP_MODIFY_ROW                  1570        138852

LOP_COUNT_DELTA                 33          6864

LOP_BUF_WRITE                   31          59512

LOP_INSERT_ROWS                 27          4068

LOP_ROOT_CHANGE                 5           480

LOP_BEGIN_XACT                  4           432

LOP_HOBT_DELTA                  4           256

LOP_COMMIT_XACT                 4           208

LOP_LOCK_XACT                   3           120

LOP_HOBT_DDL                    2           72

LOP_PREP_XACT                   1           68

LOP_END_CKPT                    1           136

LOP_FORMAT_PAGE                 1           84

LOP_BEGIN_CKPT                  1           96

LOP_CREATE_ALLOCCHAIN           1           40

L’opérateur logique LOP_SET_FREE_SPACE est typiquement un opérateur d’allocation, qui met à jour la page PFS du fichier de donnée et indique quels sont les pages qui ne sont plus libres pour de futures allocations car elles ont été utilisées par le SELECT INTO. Si je lance la sauvegarde de mon journal :

Processed 149 pages for database 'CAPDATA', file 'CAPDATA_log01' on file 1.

BACKUP LOG successfully processed 11277 pages in 28.242 seconds (3.270 MB/sec).

La sauvegarde fait 90Mb alors qu’il n’y a que 1,5Mb de transactions dans mon journal, parce qu’elle embarque les pages de données allouées par le SELECT INTO.

Exécutons maintenant le rebuild de l’index :

ALTER INDEX PK_PIECEAPPARTEMENT ON PIECEAPPARTEMENT REBUILD WITH (SORT_IN_TEMPDB = ON)

 SQL Server Execution Times:

 CPU time = 11594 ms, elapsed time = 48860 ms.

48 secondes au lieu de 66, et dans le journal:

dbcc sqlperf(logspace)

 Database Name   Log Size (MB)     Log Space Used (%) Status

----------------------------------------------------------------------------------------------

CAPDATA         49,99219           5,8515             0

Et la sauvegarde de journal fait 91 Mb, loin des 5% utilisés. Là encore, les pages de données créées lors du rebuild sont embarquées dans la sauvegarde.

Conclusion: en mode BULK_LOGGED, pour pouvoir restaurer une opération minimalement loggée, le BACKUP LOG est obligé de prendre avec lui les pages de données allouées dans l’opération. Ici, on ne voit pas de différence de taille des sauvegardes de journal entre les modes FULL et BULK_LOGGED, mais si en plus des opérations minimalement loggées, j’ai des ordres de modifications standards type INSERT/DELETE,UPDATE, la taille de ma sauvegarde va croître (et le temps de sauvegarde avec) en BULK_LOGGED et dépasser la taille d’une sauvegarde en mode FULL. Donc attention à l’espace disponible sur les disques de sauvegardes le week end pendant la reorg !

David B.

Continuez votre lecture sur le blog :

• Scripting et SMO (suite): scripter les objets directement en T-SQL (David BAFFALEUF) [SQL Server]
• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]
• Règles d’installation de base (épisode 2) (David BAFFALEUF) [SQL Server]
• How-To: réduire la taille du journal de transactions sur disque (David BAFFALEUF) [SQL Server]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]

Dans ce premier épisode:

1. Qu’implique le passage de SIMPLE à COMPLET.
2. Que devient mon journal en mode COMPLET si je ne le sauvegarde pas régulièrement.

Le mode de récupération (recovery model en anglais) est une propriété de base de données qui va préciser pour celle-ci deux choses essentielles:

1. Le recyclage de l’espace consommé par les transactions validées dans son journal de transactions.
2. La possibilité ou non de pouvoir sauvegarder ces transactions validées.

Il existe trois modes de récupération: FULL, SIMPLE et BULK-LOGGED.

FULL: c’est le mode par défaut. Dans ce mode, toutes les transactions sont journalisées, même les opérations de modifications de masse (CREATE INDEX, BULK INSERT ou bcp.exe, SELECT INTO, et les opérations sur les champs TEXT). Dès l’instant où il y a eu au moins une sauvegarde complète sur la base, les transactions validées restent dans le journal. La seule façon de recycler l’espace occupé par ces transactions est de lancer régulièrement une sauvegarde du journal. Les transactions validées sont sauvegardées dans un fichier et sont alors supprimées du journal * .

SIMPLE: dans ce mode, le recyclage des transactions validées est la responsabilité du checkpoint. En plus de flusher sur disque les pages de données modifiées dans le cache de données, le checkpoint supprime les transactions validées du journal sans les sauvegarder. Conséquence de celà, je n’ai pas la possibilité de sauvegarder mes transactions en mode SIMPLE. Je ne pourrai exécuter que des sauvegardes complètes ou différentielles (ou de fichier en lecture seule).

BULK-LOGGED: c’est un mode à combiner avec le mode FULL. Dans ce mode, les opérations de modification de masse (citées plus haut) ne sont pas complètement journalisées, et l’impact de telles opérations sur le journal est limité. Le fait de changer de FULL à BULK-LOGGED ne modifie en rien ma façon de sauvegarder mes bases. En mode BULK-LOGGED, mes sauvegardes transactionnelles horaires continuent de s’exécuter sans problème. Très utile lorsqu’on lance notre réorganisation des indexes hebdomadaire car on gagne un temps fou.

Note: Attention à ne pas confondre mode de récupération FULL et sauvegarde FULL.

Pour retrouver le mode de récupération d’une base:

SELECT DATABASEPROPERTYEX('maBase','RECOVERY') as RECOVERYMODE

Pour changer le mode d’une base:

ALTER DATABASE maBase SET RECOVERY [ FULL | SIMPLE | BULK_LOGGED ]

1) Première remarque: il faudra obligatoirement (re)lancer une sauvegarde complète avant de sauvegarder le journal:
- Quand je créé ma base.
- Quand je passe de SIMPLE à FULL.

La sauvegarde de transaction a besoin d’un numéro de transaction (LSN pour Log Sequence Number) de référence pour savoir à partir de quelle transaction commencer sa sauvegarde. Lorsqu’il n’y a pas eu d’autre sauvegarde de transactions avant elle, comme c’est le cas quand je passe de SIMPLE à FULL ou quand je viens de créer ma base, elle se base sur le LSN de fin de la dernière sauvegarde complète dans le même mode. Le fonctionnement précis de la sauvegarde à chaud fera l’objet d’un autre article prochainement.

Pour le mettre en évidence, créons-nous une petite base CRASHTEST:

CREATE DATABASE CRASHTEST

on PRIMARY

(NAME='CRASHTEST_data',

FILENAME='F:\KATMAI\MSSQL10.KATMAI\MSSQL\DATA\CRASHTEST_data.mdf',

SIZE=100MB, MAXSIZE=500MB)

LOG ON

(NAME='CRASHTEST_log',

FILENAME='F:\KATMAI\MSSQL10.KATMAI\MSSQL\DATA\CRASHTEST_log.ldf',

SIZE=50MB,
MAXSIZE=500MB)

Vérifions son mode de récupération:

SELECT DATABASEPROPERTYEX('CRASHTEST','RECOVERY') as RECOVERYMODE

RECOVERYMODE
---------------------------------------------------------
FULL

Créons une petite transaction et essayons de la sauvegarder:

use CRASHTEST

create table TABLE1 (A numeric identity, B varchar(5000))

insert into TABLE1 values (replicate('b',5000))

backup log CRASHTEST to disk='C:\CRASHTEST.log1.trn' with init, stats

Msg 4214, Level 16, State 1, Line 1

BACKUP LOG cannot be performed because there is no current database backup.

J’ai donc effectivement besoin d’avoir une sauvegarde complète pour initialiser ma chaîne:

backup database CRASHTEST to disk='C:\CRASHTEST.1.bak' with init, stats

Processed 152 pages for database 'CRASHTEST', file 'CRASHTEST_data' on file 1.
100 percent processed.
Processed 1 pages for database 'CRASHTEST', file 'CRASHTEST_log' on file 1.
BACKUP DATABASE successfully processed 153 pages in 0.266 seconds (4.711 MB/sec).

OK, je retente de sauvegarder mon log:

backup log CRASHTEST to disk='C:\CRASHTEST.log1.trn' with init, stats

100 percent processed.

Processed 6 pages for database 'CRASHTEST', file 'CRASHTEST_log' on file 1.

BACKUP LOG successfully processed 6 pages in 0.161 seconds (0.283 MB/sec).

Même problème lorsque je passe de SIMPLE à FULL:

ALTER DATABASE CRASHTEST set RECOVERY SIMPLE

ALTER DATABASE CRASHTEST set RECOVERY FULL

backup log CRASHTEST to disk='C:\CRASHTEST.log2.trn' with init, stats

Msg 4214, Level 16, State 1, Line 1
BACKUP LOG cannot be performed because there is no current database backup.

2) SAUVEGARDEZ VOS TRANSACTIONS !

C’est un problème que l’on retrouve chez beaucoup de clients: grands comptes, PME… Il y a toujours chez eux au moins une base de données en mode de récupération FULL dont le journal n’a JAMAIS été sauvegardé. Ce n’est pas étonnant en un sens puisque FULL est le mode par défaut pour toutes les bases créées par l’utilisateur. Le résultat est un fichier LDF qui fait 80 Gb parce qu’il contient une année ou deux de transactions validées, sauvegardées dans des backup FULL depuis belle lurette, mais on le répète, en mode FULL, il n’y a qu’une sauvegarde de journal qui permet de recycler l’espace occupé par des transactions validées.

Reprenons notre base CRASHTEST, et créons un peu de volumétrie…

USE CRASHTEST

declare @cpt int

set @cpt=1

while(@cpt<=50000)

begin

insert into TABLE1 values (replicate('b',5000))

set @cpt=@cpt+1

end

go

…et vérifions quelle est la situation du journal à l’issue:

DBCC SQLPERF(LOGSPACE)

Database Name       Log Size (Mb)    Log Space Used (%)      Status
------------------  ---------------  ----------------------  --------
(...)               (...)            (...)                   (...)
CRASHTEST           253,3047         97,07731                0

Il a plus que quadruplé de volume et il est plein.

Pour récupérer l’espace sur le disque, il faudra faire un DBCC SHRINKFILE en mode TRUNCATEONLY.
Si je lance le DBCC SHRINKFILE tout de suite:

DBCC SHRINKFILE(’CRASHTEST_log’,'TRUNCATEONLY’)

Dbid        Fileid        CurrentSize        MinimumSize    UsedPages         EstimatedPages
---------   ----------- ----------------  ---------------- ---------------   ------------------
8           2            31680            6400             31680             6400

31680*8192Kb = 247,5 Mb, autant dire que presque rien n’a été fait. Celà vient du fait que le TRUNCATEONLY tronque la taille du fichier jusqu’au dernier extent alloué.
Comme mon journal est plein, le dernier extent alloué est précisément à la fin du fichier.

Donc il faut commencer par vider ce journal: je sauvegarde ma transaction :

backup log CRASHTEST to disk='C:\CRASHTEST.log3.trn' with init, stats, compression

go

100 percent processed.

Processed 31461 pages for database 'CRASHTEST', file 'CRASHTEST_log' on file 3.

BACKUP LOG successfully processed 31461 pages in 16.391 seconds (15.723 MB/sec).

Dans mon journal…

DBCC SQLPERF(LOGSPACE)

Database Name        Log Size (Mb)    Log Space Used (%)      Status
------------------   ---------------  ----------------------  --------
(...)                (...)            (...)                   (...)
CRASHTEST            247,4922         4,201521                 0

Je retrouve mon enveloppe à 247,5Mb, et cette fois elle est bien vide. Je vais pouvoir ramener mon log à sa taille d’origine:

DBCC SHRINKFILE(’CRASHTEST_log’,'TRUNCATEONLY’)

Dbid        Fileid        CurrentSize        MinimumSize    UsedPages         EstimatedPages
---------   ----------- ----------------  ---------------- ---------------   ------------------
8           2            6400               6400            6400              6400

Attention, si je choisis de rester en mode FULL, je devrai programmer des sauvegardes de transactions (à travers le SQL Agent par exemple).

Dans le cas où ce journal fait plusieurs dizaines de Gb, je choisis de le vider en passant la base en mode SIMPLE:

ALTER DATABASE CRASHTEST SET RECOVERY SIMPLE

Un checkpoint initié dès la fin de l’ALTER se chargera de vider le contenu du journal, et il ne restera plus qu’à faire le SHRINKFILE.

A suivre l’effet du BULK-LOGGED sur la taille du journal…

[ David B. ]

Continuez votre lecture sur le blog :

• SQLDIAG (épisode 1) (David BAFFALEUF) [SQL Server]
• Journées SQL Server à Paris les 12 et 13 décembre 2011 ! (David BAFFALEUF) [SQL Server]
• Abonnez-vous au blog de la CapData team ! (Cédric PEINTRE) [GénéralMySQLOracleSQL ServerSybase]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• Consistence des écritures avec SATA (David BAFFALEUF) [Operating SystemSQL Server]