Un petit mot pour vous dire que je serai présent aux Techdays le mercredi 8 février avec Christophe Laporte (blog|twitter) et François Jehl (blog) sur les stands GUSS et SQL Server pour répondre à toutes vos questions entre 2 sessions.

Venez nombreux !!

David B.Continuez votre lecture sur le blog :

• Journées SQL Server 12/13 décembre (suite) (David BAFFALEUF) [SQL Server]
• Journées SQL Server à Paris les 12 et 13 décembre 2011 ! (David BAFFALEUF) [SQL Server]
• Repérer un package SSIS lors de son exécution (Louis HOCHBERG) [SQL Server]
• Modifier la Collation d’une base SQL 2005 (Louis HOCHBERG) [SQL Server]
• Réunion GUSS le 1er juillet ! (David BAFFALEUF) [SQL Server]

Ce fut l’occasion aussi de permettre aux MVP et aux personnes du support (EE, PFE) de se rencontrer. On a eu la chance également de pouvoir échanger avec Jean-Yves Devant, responsable de la partie Réplication + Change tracking + CDC au niveau du dev à Redmond. La rencontre a été immortalisée dans le hall principal de MS (Merci à Marc Biarnes):

Les sessions sont presque toutes disponibles en webcast , ainsi que les deux keynotes (1 et 2). Quelques unes des sessions que je vous recommande sur la partie  moteur:

• Philippe Geiger (MVP): SQL Server: ses fonctionnalités méconnues donc indispensables.
• Pascal Belaud (MS): Always On
• Arian Papillon : Réussir sa migration avec SQL Server 2008 R2 ou SQL Server 2012.
• Jean-Yves Devant (MS): Synchronisation des données / réplication
• Christophe Laporte (MVP,MCM): Server Core et Virtualisation.
• Frédéric Pichaud (MS): Optimisation et Troubleshooting.
• Frédéric Brouard (MVP): Contraintes et performances
• David Barbarin (MVP): Sécurité dans SQL Server 2012
• Et ma session sur le moteur XE ici.

A+Continuez votre lecture sur le blog :

• Journées SQL Server à Paris les 12 et 13 décembre 2011 ! (David BAFFALEUF) [SQL Server]
• Techdays !!! (David BAFFALEUF) [SQL Server]
• Repérer un package SSIS lors de son exécution (Louis HOCHBERG) [SQL Server]
• Checkpoint not complete: Comment limiter les alertes liées à la journalisation (Louis PROU) [Oracle]
• Msg 2508, Level 16, State 1: the In-Row data %% for object %% is incorrect (David BAFFALEUF) [SQL Server]

Nous serons une petite vingtaine de MVP, consultants et intervenants MS pour évoquer différents sujets autour du moteur relationnel et de la BI, et des nouveautés de la version 2012 qui sort l’année prochaine.

Je présenterai une session sur les XEvents en Denali CTP3 le lundi matin et serai présent sur le salon les deux jours. Ce sera surtout l’occasion de se rencontrer et d’échanger autour de SQL Server. Tous les détails sur le planning des sessions et l’organisation sont sur le site du GUSS.

Alors à très bientôt !

David B.

Continuez votre lecture sur le blog :

• Journées SQL Server 12/13 décembre (suite) (David BAFFALEUF) [SQL Server]
• Réunion GUSS le 1er juillet ! (David BAFFALEUF) [SQL Server]
• Techdays !!! (David BAFFALEUF) [SQL Server]
• Repérer un package SSIS lors de son exécution (Louis HOCHBERG) [SQL Server]
• Oracle, les Rpms plus de souci avec YUM (Thierry GASCARD) [Oracle]

use mabase ;

create table #ftsDDL (catalogname sysname, objname sysname, objtype varchar(20),
colname sysname, type_column_id sysname NULL, langid int, indexname sysname,
changetracking varchar(10), stoplistname sysname)

insert into #ftsDDL
select FTC.name 'Catalog Name', T.name 'Object name', 'Table' 'Object Type',
C.name 'colname', FTIC.type_column_id, FTIC.language_id, I.name 'UQIndexName',
FTI.change_tracking_state_desc, STP.name
from sys.fulltext_indexes FTI
inner join sys.fulltext_catalogs FTC on FTC.fulltext_catalog_id = FTI.fulltext_catalog_id
inner join sys.tables T on FTI.object_id = T.object_id
inner join sys.indexes I on I.object_id = T.object_id
inner join sys.fulltext_index_columns FTIC on FTIC.object_id = FTI.object_id
inner join sys.columns C on C.column_id = FTIC.column_id and C.object_id = FTI.object_id
inner join sys.fulltext_stoplists STP on STP.stoplist_id = FTI.stoplist_id
where I.is_unique = 1 and I.type = 1
and FTIC.type_column_id is NULL

	 UNION 

select FTC.name 'Catalog Name', V.name 'Object name', 'Indexed View' 'Object Type',
C.name 'colname', FTIC.type_column_id, FTIC.language_id, I.name 'UQIndexName',
FTI.change_tracking_state_desc, STP.name
from sys.fulltext_indexes FTI
inner join sys.fulltext_catalogs FTC on FTC.fulltext_catalog_id = FTI.fulltext_catalog_id
inner join sys.views V on FTI.object_id = V.object_id
inner join sys.indexes I on I.object_id = V.object_id
inner join sys.fulltext_index_columns FTIC on FTIC.object_id = FTI.object_id
inner join sys.columns C on C.column_id = FTIC.column_id and C.object_id = FTI.object_id
inner join sys.fulltext_stoplists STP on STP.stoplist_id = FTI.stoplist_id
where I.is_unique = 1 and I.type = 1
and FTIC.type_column_id is NULL
order by 1;

with cte as
 (select p1.catalogname, p1.objname, (select colname
 +case
when p2.type_column_id is NULL then '' else ' TYPE COLUMN *put type column here*' end+
' language '+cast(p2.langid as char(5))+','
from #ftsDDL p2 where p1.objname = p2.objname FOR XML PATH ('') ) as 'Columns',
p1.indexname, p1.changetracking, p1.stoplistname from #ftsDDL p1 group by catalogname,
objname, indexname, changetracking, stoplistname
)

select 'CREATE FULLTEXT INDEX ON '+objname+'('+substring(Columns,1,len(Columns)-1)+
') KEY INDEX ['+indexname+'] on ['+catalogname+'] WITH CHANGE_TRACKING '+changetracking+
', STOPLIST = ['+stoplistname+']' from cte;

drop table #ftsDDL;

/*

CREATE FULLTEXT INDEX ON V_ContentItmListGermany(abstr language 1031 ,desc language 1031 ,
subt language 1031 ,title language 1031 ) KEY INDEX [UI_V_ContentItmsListGermany]
on [Catalog_1] WITH CHANGE_TRACKING AUTO, STOPLIST = [SYSTEM]

CREATE FULLTEXT INDEX ON V_GenAtttGermany(blob language 1031 ) KEY INDEX [UI_V_GenAtttGermany]
on [Catalog_1] WITH CHANGE_TRACKING AUTO, STOPLIST = [SYSTEM]

CREATE FULLTEXT INDEX ON V_GenAttachmentDe(blob TYPE COLUMN *put type column here*
language 1031 ) KEY INDEX  [UI_V_GenAttachmentDe] on [Catalog_LanDe]
WITH CHANGE_TRACKING AUTO, STOPLIST = [SYSTEM]

CREATE FULLTEXT INDEX ON V_GenAtttUS(blob language 1033 ) KEY INDEX [UI_V_GenAtttUS]
on [Catalog_2] WITH CHANGE_TRACKING AUTO, STOPLIST = [SYSTEM]

CREATE FULLTEXT INDEX ON V_GenAttachmentEn(blob TYPE COLUMN *put type column here*
language 1033 ) KEY INDEX  [UI_V_GenAttachmentEn] on [Catalog_LanEn]
WITH CHANGE_TRACKING AUTO, STOPLIST = [SYSTEM]

CREATE FULLTEXT INDEX ON V_GenAtttFrance(blob language 1036 ) KEY INDEX [UI_V_GenAtttFrance]
on [Catalog_3] WITH CHANGE_TRACKING AUTO, STOPLIST = [SYSTEM]

*/

Les indexes FTS, contraitement aux catalogues ne peuvent pas être scriptés directement dans SSMS. Evidemment il faudra recréer les catalogues avant. Attention, si des colonnes indexées sont de type varbinary(max) ou image, il faudra préciser le nom de la colonne qui stocke l’extension (cf http://msdn.microsoft.com/en-us/library/ms187317.aspx) à la place de *put type column here*
(je ne peux pas les deviner)

Petite note intéressante, dans le cas de ce client, les indexes FTS étaient créés sur des vues indexées, d’où l’UNION entre les indexes liés à sys.tables et ceux liés à sys.views dans la table temporaire. Et pour transposer et concaténer les colonnes de l’index sur une ligne on utilise la technique avec FOR XML PATH( ») dans la CTE.

A+

ContentItmListGermany

Continuez votre lecture sur le blog :

• 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]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]
• Fragmentation sur des tables stockées en S-GAM (David BAFFALEUF) [SQL Server]

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]

Le problème inhérent à ce genre de restauration, c’est qu’on ne sait pas exactement jusqu’où restaurer. Lorsque votre collègue vous dit qu’il a supprimé accidentellement les données de la table principale vers 13h45, c’est assez vague comme réponse. Si vous restaurez à 13h44, que fait-on des transactions validées entre 13h44 et le moment précis où le delete a été exécuté ? Il faut jouer avec RESTORE LOG WITH STOPAT, STANDBY pour déterminer le point dans le temps où les données ne sont plus dans la table. Milliseconde par milliseconde ? Bof bof bof…

L’alternative est d’utiliser des marques de transactions:

BEGIN TRAN MiseAJourProduits
GO
DELETE FROM PRODUITS -- WHERE ID_PRODUIT = @id_produit (aïeuuu)
GO
...
COMMIT TRAN MiseAJourProduits
GO

Dès lors il est possible de restaurer avant la transaction qui pose problème en utilisant l’option STOPBEFOREMARK de RESTORE LOG:

RESTORE LOG maBASE FROM DISK='C:\UTRECHT\MSSQL.1\MSSQL\Backup\maBase.20110712.trn'
WITH RECOVERY, STOPBEFOREMARK = 'MiseAJourProduits'
GO

Seul problème, c’est à l’initiative du développeur de le faire, or la plupart du temps les transactions sont non marquées, je ne vous parle même pas des progiciels…

Fiat lux:

J’ai longtemps regretté l’absence d’un outil built-in tel que LogMiner pour pouvoir lire le contenu d’un backup log, et pouvoir effectuer une restauration précise à la transaction près. En effet,  STOPATMARK / STOPBEFOREMARK permettent d’utiliser une syntaxe telle que :

RESTORE LOG ... WITH STOPBEFOREMARK = 'lsn:<LSN number>'.

Seulement voilà, comment connaître les différentes transactions embarquées dans un backup log ? fn_dblog() permet d’obtenir cette information sur le journal lui-même, mais quid des backups…

Et il y a quelques jours, je joue avec OPENROWSET() et là je tombe sur une fonction système non-documentée dans la base resource : fn_dump_dblog(). En lisant le nom, l’émotion m’étreint. Le souffle court, je jette un coup d’oeil au source de la fonction:

create function sys.fn_dump_dblog  
 (  
    @start    nvarchar (25) = NULL,  
    @end      nvarchar (25) = NULL,  
    @devtype  nvarchar (260) = NULL, -- NULL(DISK) | DISK | TAPE | VIRTUAL_DEVICE  
    @seqnum   Int         = 1,  
    @fname1   nvarchar (260) = NULL,  
    @fname2   nvarchar (260) = NULL,  
    @fname3   nvarchar (260) = NULL, 
    ...
    @fname64   nvarchar (260) = NULL  
 )  
returns table  
as  
 return select  
     [Current LSN],  [Operation],  [Context],  [Transaction ID],   [Tag Bits],  
     [Log Record Fixed Length],  [Log Record Length],   [Previous LSN],  
     (...)
     from OpenRowset (DBLog, @start, @end, @devtype, @seqnum,  
     @fname1,  @fname2,  @fname3,  @fname4,  @fname5, 
     (...)
     @fname62,  @fname63,  @fname64)

En lisant le paramètre @devtype j’avale mon sandwich indien poulet-curry de travers. Ça fait dix mois que je bosse sur un provider OLEDB qui permette de lire dans un backup full (un peu l’équivalent de l’Archive Database Access sous Sybase ASE), et là je découvre qu’il existe une fonction qui fait la même chose sur les backups log. Depuis la 2005 RTM. Argl.

Et puis en gouglant un peu, je tombe sur cet article de Dimitri Furman, une personne de MS Consulting Services à New-York qui décrit brièvement la fonction et ses arguments. Je ne peux pas résister, il va falloir tester ça.

Scénario de test:

On va donc créer une base de démo, peupler une table et supprimer des intervalles de valeurs en les entrelaçant de backup logs. On arrive à une suppression par erreur, et on souhaite remonter les données juste à la transaction d’avant, sachant que les transactions ne sont pas marquées.

/*************************************************************************************
 Obj:       DEMO RESTAURATION SUITE A ERREUR MANUELLE
            UTILISATION DU MODE STANDBY POUR EFFECUTER UN POINT-IN-TIME RECOVERY
 Aut:       dbaffaleuf@capdata
 Crdate:    2011/07/13
*/

-- Population de la base
use master
GO
if exists (select 1 from sys.databases where name='demorecovery')
 drop database demorecovery
GO
create database demorecovery
GO

use demorecovery
GO
create table T1(
 a numeric identity,
 b char(4000) default replicate('b',4000),
 c bigint default round(rand()*100,0))
GO
insert into T1 default values
GO 1000
create unique clustered index IDX_T1C on T1(a)
GO
create index IDX_T1NC__c on T1(c)
GO

-- Activation du mode de récupération complet
alter database demorecovery set recovery full
GO
backup database demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_FULL.bak' with init, stats
GO

-- Quelques transactions et quelques backups de transactions
delete from T1 where a < 10
GO
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG1.bak' with init, stats
GO
delete from T1 where a < 20
GO
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG2.bak' with init, stats
GO
delete from T1 where a < 30
GO
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG3.bak' with init, stats
GO

-- Trois autres transactions à suivre, la dernière (a<60) est une erreur manuelle
delete from T1 where a < 40
GO
delete from T1 where a < 50
GO
delete from T1 where a < 60  -- <-- CES DONNEES SONT EFFACEES PAR ERREUR !!!
GO
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG4.bak' with init, stats
GO

-- Une autre transaction valide passe entre-temps
delete from T1 where a > 990
GO

-- Le téléphone sonne, l'utilisateur demande s'il est possible de récupérer les données avant le delete where a < 60
use master
GO
-- tail log backup
backup log demorecovery to disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_TAILLOG.bak' with init, stats, NO_TRUNCATE, NORECOVERY
GO
select state_desc from sys.databases where name='demorecovery'
GO

state_desc
------------------------------------------------------------
RESTORING

-- On identifie le backup de journal qui embarque l'erreur: demorecovery_LOG4.bak
-- on recherche les différentes transactions contenues à l'intérieur avec fn_dump_dblog():
select *, [Current LSN]
 ,Operation
 ,[Transaction ID]
 ,AllocUnitId
 ,[Begin Time]
 ,[Transaction Name]
 ,[End Time]
 ,[Description]
from fn_dump_dblog(DEFAULT, DEFAULT,DEFAULT, DEFAULT,
'C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG4.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'

Current LSN             Operation         Transaction ID  Begin Time               Transaction Name    Description
----------------------- ----------------- --------------  ------------------------ ------------------- -----------------------------------------------------------------------
00000041:00000338:000e  LOP_BEGIN_XACT    0000:000008b8   2011/07/13 15:59:43:580  DELETE              DELETE;0x0105000000000005150000006aa3aebb1b5c3491642b62e2e8030000
00000042:00000021:0001  LOP_BEGIN_XACT    0000:000008b9   2011/07/13 15:59:43:587  DELETE              DELETE;0x0105000000000005150000006aa3aebb1b5c3491642b62e2e8030000
00000042:00000076:0001  LOP_BEGIN_XACT    0000:000008ba   2011/07/13 15:59:43:630  DELETE              DELETE;0x0105000000000005150000006aa3aebb1b5c3491642b62e2e8030000


-- On restaure jusqu'au N-1 backup log avant pb
restore database demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_FULL.bak' with stats, norecovery
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG1.bak' with stats, norecovery
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG2.bak' with stats, norecovery
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG3.bak' with stats, norecovery
GO

-- On restaure en standby mode à la première transaction pour déterminer si les données entre 50 et 60 sont toujours là
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG4.bak' with stats,
standby='C:\UTRECHT\MSSQL.1\MSSQL\Backup\stdby_files.bak', stopbeforemark='lsn:0x00000042:00000021:0001'
GO

select state_desc, is_in_standby from sys.databases where name='demorecovery'
GO

state_desc    is_in_standby
------------- --------------
ONLINE        1

use demorecovery
GO
select * from T1 where a < 60
GO

a      b                            c
------ ---------------------------- ----
40     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 31
41     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 28
42     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 77
43     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 18
44     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 12
45     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 42
46     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
47     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 46
48     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 39
49     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 74
50     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 45
51     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
52     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 32
53     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 10
54     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
55     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 99
56     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 71
57     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 38
58     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
59     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 41

-- OK, allons voir à la transaction suivante
use master
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG4.bak' with stats,
standby='C:\UTRECHT\MSSQL.1\MSSQL\Backup\stdby_files.bak', stopbeforemark='lsn:0x00000042:00000076:0001'
GO

use demorecovery
GO
select * from T1 where a < 60
GO

a      b                            c
------ ---------------------------- ----
50     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 45
51     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
52     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 32
53     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 10
54     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
55     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 99
56     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 71
57     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 38
58     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
59     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 41

-- On dirait bien qu'on est dans l'état attendu. Allons voir à la dernière transaction pour confirmer:
use master
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG4.bak' with stats,
standby='C:\UTRECHT\MSSQL.1\MSSQL\Backup\stdby_files.bak'
GO

use demorecovery
GO
select * from T1 where a < 60
GO

a      b                            c
------ ---------------------------- ----

-- Ouaip, donc il faut revenir au point précédent, en rechargeant tout depuis le backup FULL:
use master
GO
restore database demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_FULL.bak' with stats, norecovery
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG1.bak' with stats, norecovery
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG2.bak' with stats, norecovery
GO
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG3.bak' with stats, norecovery
GO

restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_LOG4.bak' with stats,
stopbeforemark='lsn:0x00000042:00000076:0001', recovery
GO

use demorecovery
GO
select * from T1 where a < 60
GO

a      b                            c
------ ---------------------------- ----
50     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 45
51     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
52     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 32
53     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 10
54     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
55     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 99
56     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 71
57     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 38
58     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 2
59     bbbbbbbbbbbbbbbbbbbbbbbbbbbb 41

-- Note: la transaction suivante (a>990) est perdue. On ne peut pas la recharger car il y aurait une cassure dans la chaîne de LSNs.
-- Si on avait tenté de restaurer le tail-log à la suite:
restore log demorecovery from disk='C:\UTRECHT\MSSQL.1\MSSQL\Backup\demorecovery_TAILLOG.bak' with stats, recovery
GO

Msg 4305, Niveau 16, État 1, Ligne 1
Le journal dans ce jeu de sauvegarde commence au numéro de séquence d'enregistrement 66000000017600001, ce qui est trop récent
pour une application à la base de données. Une sauvegarde de fichier journal antérieure qui inclut le numéro de séquence
d'enregistrement 66000000009200001 peut être restaurée.
Msg 3013, Niveau 16, État 1, Ligne 1
RESTORE LOG s'est terminé anormalement.

Donc voilà enfin une méthode pour récupérer une base pile à l’endroit où on veut la récupérer, encore une fois grâce à une fonction non documentée qui mériterait d’être plus connue.

A+. David B.Continuez votre lecture sur le blog :

• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]
• How-To: réduire la taille du journal de transactions sur disque (David BAFFALEUF) [SQL Server]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• Principes d’une sauvegarde à chaud (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]

En gros c’est une fonction qui appelle un provider OLEDB, et qui retourne un résultat au format table-valué. Par exemple on l’utilise pour exécuter des requêtes sur des serveurs liés en passant le nom d’un provider (MSDAORA pour oracle, SQLNCLI pour le client natif MSSQL, etc…). Par exemple:

SELECT RemoteDepts.*
FROM OPENROWSET('SQLNCLI', 'Server=MS2K8-Win2008-1;Trusted_Connection=yes;',
     'SELECT * FROM CAPDATA.dbo.DEPARTEMENT') AS RemoteDepts;

Jusque là, rien de révolutionnaire.

Juste pour rire, on réinvente le CSV engine:

Il existe un certain nombre de providers non documentés sur lesquels s’appuient en général  les DMV/DMF et quelques fonctions table-valuées comme fn_dblog(), fn_helpcollations(), etc… qui feront l’objet de l’épisode 2. Il en existe un toutefois, BULK,  qui est parfaitement documenté et très pratique, et qui permet de faire du chargement massif notamment (l’ancêtre du BULK INSERT T-SQL) mais aussi de renvoyer à peu près n’importe quoi sous une forme table-valuée.

Par exemple, on peut reprendre à notre compte le concept du moteur CSV de MySQL, et créer des vues qui mappent des fichiers CSV sur disque, pour visualiser le contenu sans les stocker physiquement dans la base. Un exemple de fichier CSV et de fichier de format (pour plus d’infos voir la page MSDN concernant les fichiers de format):

bulktest.csv:

LOUISH,21941
DAVID,21940
LOUISP,21943
LAURENT,21942
JSEB,21944

bulktest.fmt:

9.0
2
1 SQLCHAR 0 10 "," 1 CurName ""
2 SQLCHAR 0 5 "\r\n" 2 ID ""

La vue T-SQL:

create view CSVENgine
as
    select * from openrowset(bulk 'V:\DBA2\MSSQL.1\MSSQL\Backup\bulktest.csv',
    FORMATFILE = 'V:\DBA2\MSSQL.1\MSSQL\Backup\bulktest.fmt') as CSV1
GO

select * from CSVENgine order by ID desc

CurName    ID
---------- -----
JSEB       21944
LOUISP     21943
LAURENT    21942
LOUISH     21941
DAVID      21940

(5 ligne(s) affectée(s))

Seule petite ombre au tableau, le provider BULK ne permet pas la mise à jour, on ne peut accéder aux données qu’en lecture seule. Mais ça reste quand même bien pratique pour attaquer une trace perfmon directement en SQL.

Charger des fichiers binaires:

Les options SINGLE_BLOB / SINGLE_CLOB/ SINGLE_NCLOB du provider BULK permettent en outre de charger des documents binaires (vidéos, images, PDF, documents word, etc…)  dans des tables, respectivement soit en varbinary(max) / varchar(max) / nvarchar(max) si les fichiers sont inférieurs à 2Gb comme c’est la cas dans l’exemple, soit dans du filestream pour les fichiers supérieurs.

create table Documents (ID numeric identity, title varchar(255), Filedata varbinary(max))

insert into Documents (title, Filedata)
SELECT 'SQL 2008 Licensing',
doc.* from OPENROWSET(BULK 'E:\CAPDATA\DOCUMENTATION\SGBD\SQL Server\WINWORDS\2008
SQL Licensing Overview final.docx', SINGLE_BLOB) as doc

insert into Documents (title, Filedata)
SELECT 'DBM Sharepoint Labs',
doc.* from OPENROWSET(BULK 'E:\CAPDATA\DOCUMENTATION\SGBD\SQL Server\WINWORDS\
DBM_Sharepoint_Labs.docx', SINGLE_BLOB) as doc

insert into Documents (title, Filedata)
SELECT 'DBM and Log Shipping',
doc.* from OPENROWSET(BULK 'E:\CAPDATA\DOCUMENTATION\SGBD\SQL Server\WINWORDS\
DBMandLogShipping.docx', SINGLE_BLOB) as doc

insert into Documents (title, Filedata)
SELECT 'Database Snapshot Performance',
doc.* from OPENROWSET(BULK 'E:\CAPDATA\DOCUMENTATION\SGBD\SQL Server\WINWORDS\
DBSnapshotPerf.docx', SINGLE_BLOB) as doc

Récupérer la sortie d’une procédure stockée sous la forme d’une table:

Une astuce monstrueuse révélée par Ward Pond en 2005, qui détourne l’utilisation d’OPENROWSET pour appeler une procédure stockée sur le serveur local et retransformer le résultat en format table-valué, un peu à la façon dont les tables MDA sont appelées sous Sybase ASE, et qui nous a sauvé la vie bien des fois sur SQL Server 2000 avant que n’apparaissent les DMV:

sp_configure 'Ad Hoc Distributed Queries',1
GO
reconfigure
GO
SELECT  w.SPID, w.Status, w.loginame, w.blk, w.dbname,w.cmd,
Lck.Objid, lck.Type, lck.Mode
FROM    OPENROWSET ('SQLNCLI','Server=(local);TRUSTED_CONNECTION=YES;',
                   'set fmtonly off exec master.dbo.sp_who') as w
INNER JOIN OPENROWSET ('SQLNCLI','Server=(local);TRUSTED_CONNECTION=YES;',
                       'set fmtonly off exec master.dbo.sp_lock') as lck
on lck.spid = w.spid
where w.blk <> 0
GO

SPID   Status       loginame            blk   dbname          cmd     Objid       Type Mode
------ ------------ ------------------- ----- --------------- ------- ----------- ---- --------
55     suspended    DBA2\dbaffaleuf     54    whitepaperz     SELECT  2073058421  TAB  IS
55     suspended    DBA2\dbaffaleuf     54    whitepaperz     SELECT  0           DB   S
55     suspended    DBA2\dbaffaleuf     54    whitepaperz     SELECT  2073058421  RID  S
55     suspended    DBA2\dbaffaleuf     54    whitepaperz     SELECT  2073058421  PAG  IS

Voir plus loin ?

MS fournit des providers OLEDB pour s’interfacer avec OPENROWSET, certains sont publics (providers relatifs aux serveurs liés, BULK), et certains sont non documentés et utilisés par des vues ou fonctions dynamiques dans SQL Server. C’est ceux-ci que nous essaierons de référencer et de comprendre dans l’épisode 2. Enfin dans l’épisode 3,  nous verrons comment créer son propre provider OLEDB avec Advanced Template Library et Visual C++, et nous essaierons de le faire communiquer avec SQL Server. Du pain sur la planche !

A+ David B.Continuez votre lecture sur le blog :

• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• How-To : réduire l’enveloppe de tempdb (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David BAFFALEUF) [SQL Server]

Démo:

Pourquoi il explose:

Avant de vouloir le réduire, il faut comprendre pourquoi on en est arrivé là. A l’origine de ce problème, une option par défaut de la base de données qui s’appelle RECOVERY. Elle permet d’indiquer deux choses:

• Quels types de sauvegarde il sera possible d’effectuer sur la base.
• De quelle manière on recycle les transactions validées dans le journal de transactions.

Cette option a trois valeurs possibles:

• FULL:toutes les transactions attendent d’être sauvegardées pour être purgées du fichier LDF. Il n’y a qu’une sauvegarde de transactions qui puisse les purger. Full est le mode par défaut pour toute nouvelle base utilisateur.
• SIMPLE: les transactions validées sont purgées du journal à intervalles réguliers par un processus d’arrière plan, le CHECKPOINT. Cette option correspond à l’ancien mode ‘trunc log on checkpoint’ qui existait en 7.0.
• BULK_LOGGED: permet de minimiser la journalisation de certains ordres de modification massive de données, tels que les reconstructions d’indexes par exemple.

Pour plus de détails sur ces différents modes, voir les épisodes 1 et 2 sur les modes de récupération.

On peut lire cette option en utilisant la commande suivante:

select DATABASEPROPERTYEX('CAPDATA','RECOVERY')
GO

------------
FULL

FULL est la valeur utilisée par défaut lors de la création d’une base. Ce qui signifie que si on ne fait jamais de sauvegardes de transactions sur une base dans ce mode, les transactions ne seront jamais purgées du journal et au bout de 6 mois ou d’un an on arrive à saturer l’espace disque, d’où le besoin de réduire la taille de ce fichier. Il existe une technique pour le ramener à sa taille initiale en moins de 2 minutes, comme expliqué dans le paragraphe suivant et dans la démo vidéo ci-dessus. Pour savoir si un backup transactionnel a déjà été exécuté sur une base, on peut interroger la table backupset de la base msdb:

select backup_start_date, backup_finish_date, type, recovery_model
from msdb.dbo.backupset where database_name = 'CAPDATA' and type = 'L'

backup_start_date              backup_finish_date         type          recovery_model
--------------------------     -------------------------- ------------- -------------------
2010-09-07 18:54:42.000           2010-09-07 18:54:52.000            L           FULL

Comment le réduire:

En deux étapes:

• Etape 1: on vide le journal de son contenu, ce qui revient à recycler simplement les transactions à l’intérieur de l’enveloppe, sans la réduire.
• Etape 2: on réduit l’enveloppe sur disque: une fois le journal vidé, il peut être réduit avec la commande DBCC SHRINKFILE ().

Si vous n’avez jamais fait de sauvegarde de journal, il y a des chances pour que la taille du fichier LDF soit assez conséquente. S’il s’agit de plusieurs dizaines ou centaines de Gb, et que vous faites des sauvegardes complètes tous les jours par exemple, ça ne sert à rien de sauvegarder toutes ces transactions qui sont entérinées depuis belle lurette. Si on regarde le contenu du journal de transactions avant de faire la manoeuvre;

dbcc sqlperf(logspace)

Database Name       Log Size (Mb)       Log Space Used (%)      Status
------------------  ------------------  ---------------------   ---------
CAPDATA               25889,367                91,7766              0

La technique consiste à passer la base en mode SIMPLE:

ALTER DATABASE [CAPDATA] SET RECOVERY SIMPLE
GO

Un checkpoint est exécutée automatiquement dès la fin de la commande. Toutes les transactions validées sont purgées du journal . Techniquement elles ne sont pas effacées mais leur conteneur physique  est réinitialisé et peut être réutilisé:

dbcc sqlperf(logspace)

Database Name       Log Size (Mb)       Log Space Used (%)      Status
------------------  ------------------  ---------------------   ---------
CAPDATA               25889,367                1,192919              0

Il ne reste plus qu’à réduire le fichier journal de transactions avec un DBCC SHRINKFILE. A cette étape il faut décider quelle est la nouvelle taille à donner au journal de transactions. Si on le réduit à son maximum, il risque de grandir à nouveau pour atteindre sa taille de croisière, et si on souhaite de réagrandir ensuite, la portion allouée sera zéro-initialisée [1]. Idéalement il faudrait un historique d’utilisation de l’espace dans le journal pour savoir combien d’espace consomme la plus grosse transaction. Par exemple dans notre cas, 50Mb:

select name from CAPDATA.sys.database_files where Type_DESC='LOG'

name
---------------
GESTIMMO_log01

dbcc shrinkfile('GESTIMMO_log01',50)

DbId   FileId      CurrentSize MinimumSize UsedPages   EstimatedPages
------ ----------- ----------- ----------- ----------- --------------
5      2           6400        6400        6400        6400

6400 pages de 8192 octets = 50Mb, on a réussi à réduire l’enveloppe sur disque de 25Gb à 50Mb en quelques secondes.

Quoi faire ensuite:

Il faut décider de la stratégie de backup à adopter pour cette base: quelle quantité de données est-il acceptable de perdre: 1 heure, 4 heures, 1 journée, 1 semaine ?

• Si la réponse est inférieure à la fréquence des backups complets, alors il faut repasser la base en mode FULL, relancer un backup complet pour réinitialiser la chaîne de sauvegarde, puis planifier des backups de journaux via l’agent ou un plan de maintenance par exemple. Les backups de journaux permettent de garantir une restauration à tout point dans le temps en mode de récupération FULL.
• Si la réponse est au moins égale à la fréquence des backups complets, alors laisser la base en mode SIMPLE, et l’espace sera automatiquement recyclé.

A suivre un autre How-To sur les problèmes d’administration de base de SQL Server.

A+ David B.

Notes:

[1]: l’initialisation instantanée (IFI) ne s’applique qu’aux fichiers de données MDF et NDF, pas aux journaux de transactions.Continuez votre lecture sur le blog :

• How-To : réduire l’enveloppe de tempdb (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]

- C’est plus pratique pour nous . Il m’est arrivé de passer plusieurs semaines sur un seul article donc ça ne va pas faire de mal de parler de choses communes, et en plus s’il y a une démo à l’appui…
- Ça parle à plus de gens. Je suis conscient qu’on ne doit pas être très nombreux à s’intéresser aux schedulers non-préemptifs et aux IO completion ports (re- ).

Ces articles seront taggés ‘howto‘ dans le nuage de tags, vous pourrez donc les retrouver tous facilement. Pour ce premier, on va parler d’un sujet qui revient de temps en temps dans les forums, à savoir comment faire pour réduire la taille de tempdb sur SQL 2005 et SQL 2008.

Démo sur SQL 2005:

Sur SQL Server 2005:

Parce que ça a l’air trivial comme ça, en théorie. Vous vous dites, trop facile je fais un dbcc shrinkfile du ou des fichiers de données de tempdb. Ou alors je fais un ALTER DATABASE tempdb MODIFY FILE (NAME=…, SIZE=…) et je redémarre.

Voyons voir:

select serverproperty('productversion')
-- Taille initiale
SELECT size/128 FROM master.sys.master_files WHERE file_id=1 and database_id=2 
 -- Taille courante
select size/128 from tempdb.sys.database_files WHERE file_id=1

---------------------------
9.00.4035.00

---------------------------
1699

---------------------------
1699

alter database tempdb modify file(name='tempdev',size=500MB)

Msg 5039, Niveau 16, État 1, Ligne 2
Échec de MODIFY FILE. La taille spécifiée est inférieure à la taille en cours.

Dans cette version de SQL Server, la base tempdb est considérée comme les autres bases: on ne peut pas réduire l’enveloppe à une valeur inférieure à la taille en cours. Quant au DBCC SHRINKFILE / SHRINKDATABASE, il ne va fonctionner que sur une base sans activité, or sur une instance en production, il y a toujours de l’activité dans tempdb: tris, agrégats, tables temporaires, version store, etc… Toute cette activité va le plus souvent empêcher DBCC SHRINKFILE de réduire l’enveloppe à la taille désirée:

select name,size/128 from master.sys.master_files where database_id=2 and file_id=1
GO

-----------------
1699

dbcc shrinkfile('tempdev',500)
GO

DbId	FileId	CurrentSize	MinimumSize	UsedPages	EstimatedPages
------- ------- --------------  --------------- --------------  --------------
2	1	200200	         1024	         200192	         200192

Les tailles sont exprimées en nombre de pages. Taille en Mb = 200200/128 = 1564 Mb, donc on n’a pas récupéré grand chose. Vous pouvez tenter le shrinkfile avec moins d’activité si vous ne souhaitez pas une interruption de service, mais si ça ne fonctionne pas, il n’y qu’une seule façon de régler le problème: il faut redémarrer l’instance avec la configuration minimale:

Démarrer SQL Server manuellement dans un prompt DOS en utilisant les options -f -c:

C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn>sqlservr -c -f
2011-07-06 07:35:12.17 Server      Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)
        Nov 24 2008 13:01:59
        Copyright (c) 1988-2005 Microsoft Corporation
        Developer Edition on Windows NT 5.1 (Build 2600: Service Pack 3)

2011-07-06 07:35:12.18 Server      (c) 2005 Microsoft Corporation.
2011-07-06 07:35:12.18 Server      All rights reserved.
2011-07-06 07:35:12.18 Server      Server process ID is 4076.
2011-07-06 07:35:12.18 Server      Authentication mode is MIXED.
2011-07-06 07:35:12.19 Server      Logging SQL Server messages in file
                                    'V:\DBA2\MSSQL.1\MSSQL\LOG\ERRORLOG'.
2011-07-06 07:35:12.19 Server      This instance of SQL Server last reported using a process
                                  ID of 3496 at 06/07/2011 07:34:18 (local) 06/07/2011 05:34:18
                                  (UTC). This is an informational message only;
 no user action is required.
2011-07-06 07:35:12.19 Server      Registry startup parameters:
2011-07-06 07:35:12.19 Server            -d V:\DBA2\MSSQL.1\MSSQL\DATA\master.mdf
2011-07-06 07:35:12.20 Server            -e V:\DBA2\MSSQL.1\MSSQL\LOG\ERRORLOG
2011-07-06 07:35:12.20 Server            -l V:\DBA2\MSSQL.1\MSSQL\DATA\mastlog.ldf
2011-07-06 07:35:12.20 Server      Command Line Startup Parameters:
2011-07-06 07:35:12.20 Server            -c
2011-07-06 07:35:12.20 Server            -f
2011-07-06 07:35:12.26 Server      Warning: The server instance was started using minimal
                                   configuration startup option (-f). Starting an instance
                                   of SQL Server with minimal configuration places the server
                                   in single-user mode automatically.  After the server has been
                                   started with minimal configuration, you should change the appropriate
                                   server option value or values, stop, and then restart the server.
2011-07-06 07:35:12.27 Serveur     SQL Server is starting at normal priority base (=7)...
2011-07-06 07:35:12.27 Serveur     Detected 2 CPUs. This is an informational message; no user action is required.
2011-07-06 07:35:12.94 Serveur     Using dynamic lock allocation.  Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node...
2011-07-06 07:35:12.96 Serveur     Support for distributed transactions was not enabled for this instance of the Database Engine because it was started using the minimal
                                  configuration option.  
2011-07-06 07:35:12.97 spid5s      Starting up database 'master'.
2011-07-06 07:35:13.11 spid5s      Recovery is writing a checkpoint in database 'master' (1). This is an informational message only. No user action is required.
2011-07-06 07:35:13.16 spid5s      Server started with '-f' option. Auditing will not be started. This is an informational message only; no user action is required.
2011-07-06 07:35:13.18 spid5s      Starting up database 'mssqlsystemresource'.
2011-07-06 07:35:13.20 spid5s      The resource database build version is 9.00.4035. This is an informational message only. No user action is required.
2011-07-06 07:35:13.40 spid6s      Starting up database 'model'.
2011-07-06 07:35:13.40 spid5s      Server name is 'DBA2'. This is an informational message only. No user action is required.
(...)

-f indique à SQL Server de démarrer avec les options minimales et en mode mono utilisateur (pas besoin d’utiliser le mode -m). Dans ce mode, tempdb reprend la taille initiale de la base model (2Mb), donc on va pouvoir faire passer un ALTER DATABASE MODIFY FILE.
-c indique que SQL Server ne démarre pas en tant que service

A partir de là on se connecte dans une seconde fenêtre DOS:

DOS>sqlcmd -E
1> select size/128 from tempdb.sys.database_files WHERE file_id=1
2> go

-----------
          2

1> alter database tempdb modify file(name='tempdev',size=500MB)
2> go
1> exit

En on redémarre via SQL Configuration Manager.

Sur SQL Server 2008:

La bonne nouvelle, c’est qu’à partir de SQL Server 2008, on n’a plus besoin de redémarrer en mode minimal, un ALTER DATABASE MODIFY FILE fonctionne avec des tailles inférieures à la taille en cours (uniquement sur tempdb):

select serverproperty('productversion')
-- Taille initiale
SELECT size/128 FROM master.sys.master_files WHERE file_id=1 and database_id=2
 -- Taille courante
select size/128 from tempdb.sys.database_files WHERE file_id=1

-------------------
10.0.2757.0

-------------------
1564

-------------------
1564

alter database tempdb modify file(name='tempdev',size=500MB)

Command(s) completed successfully.

Suivi d’un arrêt / redémarrage de l’instance avec SQL Configuration Manager.

A suivre un autre how-to SQL Server. A+

David B.

Liens:

http://support.microsoft.com/kb/307487/en-us

Continuez votre lecture sur le blog :

• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• How-To: réduire la taille du journal de transactions sur disque (David BAFFALEUF) [SQL Server]
• Bench avec NetApp / Datacore / ESX (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]

1. Gestion des entrées/sorties: alignement, I/Os asynchrones, alternate streams, scatter gather, I/O completion ports, etc…
2. Le multithreading:  synchronisation, events, mutexes, spinlocks, sections critiques…
3. La mémoire: allocation, fichiers mappés, AWE, large pages…

Cette série plutôt barbare va dévier un peu des sujets SGBD traditionnels. Elle s’adresse à toute personne souhaitant approfondir les mécanismes intrinsèques de SQL Server, pour en comprendre la logique et les contraintes. Ces articles seront classés sous les sujets Operating System et SQL Server. Leur lecture nécessite que vous ayez des connaissances minimum sur C/C++ et l’API win32.

Dans un post précédent, nous avions déjà effleuré la question de l’écriture à travers le cache, nous reprendrons le même exemple pour évoquer le sujet du jour: les I/Os asynchrones dans des fichiers. C’est une question large donc je propose d’éclater le sujet en trois épisodes:

1. Ce premier pour expliquer le principe et montrer à travers un petit exemple simple  les avantages, mais aussi les contraintes de faire des I/Os asynchrones.
2. Un second pour montrer comment gérer plus efficacement  la synchronisation des I/Os asynchrones entre plusieurs threads, notamment avec l’utilisation d’I/O completion ports.
3. Un dernier pour montrer l’utilisation qui en est faite par SQL Server, ainsi que certaines problématiques particulières.

SYNCHRONE vs ASYNCHRONE:

Quand on écrit un programme sous windows, on doit tôt ou tard accéder à un device en lecture / écriture. La plupart des applications que l’on utilise n’ont pas besoin d’écrire très souvent des  données durables. Souvent elles misent sur la bufferisation des entrées / sorties, c’est à dire l’écriture ou la lecture de données en mémoire. Parfois cependant, elles devront lire des données sur disque, par exemple lorsqu’elles démarrent, ou bien écrire des informations dans un fichier de configuration lorsqu’elles s’arrêtent. Le moyen de plus simple de lire ou d’écrire dans un fichier est alors de lancer une entrée/sortie synchrone en utilisant ReadFile() ou WriteFile().

On utilise le terme synchrone parce que le thread qui a initié cette écriture ou cette lecture doit attendre l’acquittement ou le retour de l’entrée/sortie avant de pouvoir continuer son exécution. Dès que la demande de lecture ou d’écriture est lancée, il entre immédiatement dans un état d’attente, il ne peut rien faire d’autre. De la sorte, s’il doit lancer de nombreuses opérations d’entrées sorties, il va devoir attendre que chacune soit terminée avant de pouvoir exécuter la suivante, ce qui va limiter en quelque sorte sa capacité à traiter un grand nombre d’opérations par seconde.

L’alternative est d’indiquer au thread de ne pas attendre le retour de l’I/O pour continuer son exécution, en postant des I/Os asynchrones (ou overlapped IO). Il existe plusieurs contraintes associées à l’utilisation des IO asynchrones, qui rendent la chose nettement plus compliquée à gérer:

• Lors d’une IO synchrone, le device object maintient un pointeur d’offset de sorte que si on lance deux lectures de 8K à la suite par exemple, le kernel sait toujours là où il s’est arrêté et là où il doit reprendre. D’ailleurs, si on regarde le prototype de ReadFile() ou WriteFile(), il n’y a pas d’information d’offset passées lors de l’appel. Avec une IO asynchrone, le pointeur d’offset est ignoré par le driver donc il faut le gérer dans le code. C’est une des différences les plus caractéristiques entre ces deux modes, et un vrai casse tête comme on va le voir dans un instant.
• Il y a de surcroît forcément un point dans le code où on ne  peut plus avancer sans avoir le retour de ces IO. Il faut donc trouver un moyen de se synchroniser avec la fin des opérations.

Dans la pratique, chaque thread  peut se synchroniser de 4 manières différentes:

1. Sur le fichier lui-même, car le fichier est un handle comme un autre. Ce serait le plus simple, il n’y a pas d’autre objet à créer. Le problème est que s’il y a plusieurs I/Os en cours sur le même fichier, on ne pourra pas déterminer laquelle vient de se terminer car le handle est signalé dès que la première I/O est retournée.
2. Sur un event associé à l’I/O. Comme nous allons le voir dans la section suivante, on utilise une structure comme traceur pour suivre chaque entrée/sortie asynchrone et cette structure contient par défaut un event associé, sur lequel le thread pourra se synchroniser. C’est la méthode que l’on va aborder dans cet épisode.
3. En utilisant une routine APC. A chaque thread créé avec beginthreadex() est associé une APC queue qui lui permet d’exécuter une routine de complétion lorsque sa tache est terminée. On peut utiliser ces routines avec les primitives WriteFileEx() et ReadFileEx(). L’avantage principal de cette méthode est que l’exécution de l’APC se fait en user mode, donc le programme conserve le contrôle pendant toute l’opération. Malgré ces quelques atouts, elle a une réputation calamiteuse [1] et reste compliquée à gérer. Le simple fait de gérer la completion dans une fonction séparée rend les choses beaucoup moins maintenables et débogables.
4. Sur un outil de synchronisation plus perfectionné, comme un I/O completion port. SQL Server utilise un I/O completion port par CPU-node pour gérer les entrées / sorties réseau. Nous verrons l’utilisation d’un tel outil dans l’épisode 2 pour gérer des I/O dans des fichiers.

Principes d’utilisation dans le code:

La structure OVERLAPPED

Que l’on utilise des entrées/sorties synchrones ou asynchrones, les primitives utilisées sont les mêmes [2], on leur passera simplement des paramètres différents. Pour pouvoir pister nos entrées / sorties asynchrones, on va utiliser un genre de traceur sous la forme d’une structure C appelée  Overlapped. Si on regarde sa composition de plus près:

typedef struct _OVERLAPPED {
  ULONG_PTR Internal;
  ULONG_PTR InternalHigh;
  union {
    struct {
      DWORD Offset;
      DWORD OffsetHigh;
    };
    PVOID  Pointer;
  };
  HANDLE    hEvent;
} OVERLAPPED, *LPOVERLAPPED;

Parmi les propriétés importantes pour le code utilisateur, Offset et OffsetHigh délimitent une portion de 64 bits de données et indiquent à quel endroit on va commencer d’écrire dans le fichier. Offset gère les 32 premiers bits pour les fichiers < 4Gb (souvenez-vous FAT 32…), et OffsetHigh les 32 suivants pour les fichiers de plus de 4Gb.

Si on exécutait deux IO synchrones, elles s’exécuteraient l’une derrière l’autre et le kernel s’occupperait d’indiquer à la seconde écriture où elle doit commencer, parce que la première s’est terminée et donc on sait où on en est. Mais dans le cas d’écritures asynchrones, on n’a pas cette information, donc si on exécute une seconde entrée/sortie avant que la première ne soit terminée, il faut pouvoir gérer les offsets soi-même. C’est le rôle de ces deux propriétés, mais c’est à nous de les maintenir. Lors d’une première exécution, ces deux valeurs doivent être initalisées (souvent à 0 pour marquer le premier offset en début de fichier):

OVERLAPPED ov;
ov.Offset = 0;
ov.OffsetHigh = 0;

De son côté, hEvent est l’event  que l’on va pouvoir utiliser pour synchroniser le thread sur l’I/O asynchrone. Si on utilise cette technique, alors il va falloir l’initialiser avec CreateEvent() en lui passant un event à reset manuel et dans l’état non – signalé (second et troisième paramètres, cf MSDN CreateEvent())

Une structure OVERLAPPED est associée à chaque I/O asynchrone que l’on va effectuer. Si on en lance 8 en même temps, il faudra créer et initialiser 8 structures. On peut utiliser un OVERLAPPED [] pour stocker toutes nos instances de structure par exemple. La chose la plus importante au sujet d’OVERLAPPED, est qu’elle doit toujours être accessible pendant toute la durée de vie de l’I/O, donc pas question d’allouer le tableau d’OVERLAPPED[] sur la stack. Le cas d’erreur le plus courant est d’exécuter un appel à ReadFile() ou WriteFile() dans une fonction et gérer la complétion dans le main ou une autre fonction, par exemple:

VOID ReadMyFile(HANDLE h)
{
    OVERLAPPED ov;
    BYTE b[255];
    ov.Offset=0;
    ov.OffsetHigh=0;
    ReadFile(h,b,255,NULL,&ov);
}

Lorsque la fonction sort la stack est vidée alors que le driver pointe encore vers &ov qui n’est déjà plus valide.

Pour indiquer à Windows que l’on souhaite faire des I/O asynchrones sur un fichier, on utilise un flag spécifique FILE_FLAG_OVERLAPPED, que l’on passe à CreateFile(), tel que:

// Ouverture du fichier Writethrough + No Buffering + Overlapped ----------------------------
HANDLE hOutputFile=CreateFile(argv[1]
       ,GENERIC_READ
       | GENERIC_WRITE
       ,0
       ,NULL
       ,CREATE_ALWAYS
       ,FILE_ATTRIBUTE_NORMAL
       | FILE_FLAG_WRITE_THROUGH
       | FILE_FLAG_NO_BUFFERING
       | FILE_FLAG_OVERLAPPED
       ,NULL);

 if (INVALID_HANDLE_VALUE==hOutputFile)
 {
       printf("Unable to open file %s.  Last error=%d\n",argv[1],GetLastError());
       return 1;
 }

A noter que cet exemple utilise aussi des I/Os non bufferisées comme nous l’avons déjà vu dans l’article sur SATA. SQL Server utilise précisément tous ces flags pour ouvrir les fichiers MDF, NDF et LDF. Il ne reste plus qu’à appeler ReadFile() ou WriteFile() en passant la structure Overlapped initialisée:

WriteFile(hOutput,csBuffer,dg.BytesPerSector,&dwBytesWritten,&ov)

Gestion de Offset et OffsetHigh

Si on exécute au moins deux appels à la suite à ReadFile() ou WriteFile() , Windows ne sait pas où le premier en est et où le second peut commencer à lire ou à écrire. C’est donc au programme utilisateur de comptabiliser les offsets exacts où chaque IO va devoir s’appliquer. On utilise pour cela les deux propriétés Offset et OffsetHigh de la structure Overlapped.

Historiquement, le compilateur C qui supporte l’API win32 ne comporte pas de type natif sur 64 bits (ce n’est pas le cas du compilateur VC++). Donc on ne peut pas tracer des offsets d’une valeur supérieure à 4Gb. Et encore aujourd’hui, il faut jongler avec une construction de type LARGE_INTEGER pour arriver à jouer avec des offsets au delà de 2e32:

 typedef union LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
       };
    LONGLONG QuadPart;
};

En fait le type LARGE_INTEGER est une union d’un DWORD et d’un LONG pour former un LONGLONG de 64 bits. Si on considère le schéma ci-dessous:

On utilisera donc QuadPart pour allouer de nouvelles valeurs d’offsets sur 64 bits puis LowPart et HighPart pour les passer respectivement à Offset et OffsetHigh, quelque chose comme :

OffsethOutput.QuadPart=0;
while(!EOF)
{
    ov.Offset        = OffsethOutput.LowPart;
    ov.OffsetHigh    = OffsethOutput.HighPart;
    BOOL b = Readfile (..., &ov);
    OffsethOutput.QuadPart += (LONGLONG) dg.BytesPerSector;
}

Gérer le retour de ReadFile() / WriteFile():

Voici un exemple d’appel à WriteFile() avec une structure overlapped tel que codé dans l’exemple:

if (!WriteFile(hOutput,csBuffer,dg.BytesPerSector,&dwBytesWritten,&ov))
{
     DWORD dwLastErr=GetLastError();            
     if (ERROR_IO_PENDING == dwLastErr)
     {    
         isASYNCWRITE=TRUE;    // On a une IO asynchrone
         OffsethOutput.QuadPart += (LONGLONG) dg.BytesPerSector;    // On décale Offset et OffsetHigh de la valeur de l'IO
     }            
     else
     {
          if (ERROR_SUCCESS == dwLastErr)        // C'est une IO synchrone
          isASYNCWRITE=FALSE;
          else
          {
              printf("Error when Writing to file %S. Last error=%d\n",argv[1],GetLastError());
              return -1;
          }
      }
}

Déjà quelque chose doit vous interpeller à ce niveau-là du code. Dans les faits, on n’a jamais la garantie à 100% d’obtenir du système qu’il poursuive pour nous une IO asynchrone, car l’IO Manager a toujours le dernier mot. Il peut décider pour une raison ou pour une autre de transformer cette demande en IO synchrone. Donc il faut toujours tester le code retour de WriteFile() quand on lui passe une structure OVERLAPPED:

• ERROR_SUCCESS =>Le kernel décide de transformer l’appel en IO synchrone. Il peut y avoir plusieurs raisons, notamment lorsqu’on écrit dans un fichier encrypté NTFS, ou lorsque l’écriture déclenche une augmentation de taille du fichier, cela doit vous rappeler certaines choses côté sikouel…  Une autre condition dans le cas d’un ReadFile() est que le kernel est capable d’accommoder la lecture immédiatement parce que la page demandée se trouve déjà dans le cache NTFS, ce qui ne sera jamais notre cas puisqu’on utilise FILE_FLAG_NO_BUFFERING.
• ERROR_IO_PENDING => dans ce cas l’IO est asynchrone. Ça ne sert donc à rien  d’attendre de WriteFile() qu’il nous renvoie une valeur d’octets écrits puisque lorsqu’il retourne au caller, il ne le sait pas lui-même. L’IO va se terminer quelque part dans le futur, donc pour l’instant on n’aura rien dans &dwBytesWritten. Dans ce cas on indique la taille de cluster comme incrément au QuadPart pour la prochaine valeur d’Offset à lire.
• ERROR_HANDLE_EOF  => peut être retournée lorsqu’on a atteint la fin du fichier par exemple dans le cas d’une lecture, mais comme on écrit on ne le teste pas dans notre cas.
• AUTRE => auquel cas c’est une erreur et il faut la traiter.

Récupérer le résultat de l’IO une fois terminée avec GetOverlappedResult()

Utiliser des IO asynchrones, c’est un peu comme jongler avec plusieurs balles à la fois: au bout d’un moment il va falloir les rattraper. Il faut donc choisir un point dans le code où on va devoir se synchroniser pour attendre le retour de ces IO avant de pouvoir continuer. On peut utiliser les primitives standard de synchronisation telles que WaitForSingleObject(), et dans notre cas puisqu’on attend le retour de plusieurs IO, WaitForMultipleObjects().On bloque en passant à la primitive le ou les events qui attendent d’être signalés:

dwEventSignPos = WaitForMultipleObjects(MAXOUTSTANDINGIO, hEvents, FALSE, INFINITE) - WAIT_OBJECT_0;

Lorsqu’un premier event est signalé parce que son IO vient de se terminer, WaitForMultipleObjects() retourne WAIT_OBJECT_0, et le code peut se poursuivre. WAIT_OBJECT_0 représente le premier event qui vient d’être signalé, on va s’en servir pour déterminer l’indice de cet event dans un tableau, comme dans notre exemple commenté ci-dessous. On va ensuite devoir récupérer le nombre d’octets écrits, et si l’on souhaite réutiliser la structure Overlapped, réinitialiser son event, puis rebloquer en attendant le retour d’une autre IO:

ResetEvent (hEvents[dwEventSignPos]);

Il existe plusieurs primitives win32 pour gérer la fin d’une IO asynchrone:

1. Utiliser GetOverlappedResults(): permet de récupérer la quantité d’octets écrits ou lus, ainsi que l’event qui a été signalé.
2. Utiliser HasOverlappedIOCompleted(): renvoie vrai ou faux en fonction de la completion de l’IO. Les informations d’octets lus ou écrits sont disponibles dans la structure Overlapped (Internal contient le code retour et InternalHigh le nombre d’octets lus ou écrits). Dans ce cas on n’aurait pas besoin de bloquer avec WaitForMultipleObjects(), mais il faut prévoir plusieurs points dans le code où faire régulièrement cette vérification. C’est de cette manière que SQL Server procède, comme on le verra dans l’épisode 3. Dans l’exemple:

if (isASYNCWRITE)
{
    if (!GetOverlappedResult(hOutput,&olwrite[dwEventSignPos],&dwBytesWritten[dwEventSignPos],TRUE))
    {
        printf("Error getting pending write IO.  Last error=%d\n",GetLastError());
        break;
    }
    else
    {
    // Action principale: on totalise chaque fin d'écriture async
    llTotalBytesWritten+=dwBytesWritten[dwEventSignPos];
    }
}

Il est important de n’exécuter GetOverlappedResults() que si l’IO est bien asynchrone, c’est pourquoi on teste avec un booléen d’abord.

Voilà, on a fait le tour, place à l’exemple commenté !

Exemple commenté d’utilisation des I/Os asynchrones:

Cet exemple reprend le principe de ce qui avait été utilisé dans l’article sur SATA. Il utilise simplement des écritures asynchrones en plus. Évidemment ça n’a pas grand intérêt de faire des écritures asynchrones dans ce contexte là (mono-thread, on lance un nombre d’IO puis on bloque sur la completion de l’ensemble), mais il a l’avantage d’être simple et de ne pas nous embarquer dans des notions hors cadre de synchronisation de threads et compagnie… Encore une fois, il s’agit juste de comprendre le principe de mise en place.

On définit une quantité de données à écrire dans un fichier (FileSizeInBytes, par défaut 10Mb) ainsi qu’un certain nombre d’outstanding IOs (MAXOUTSTANDINGIO), c’est à dire d’IO simultanées. On ne peut envoyer plusieurs IO simultanées que si on effectue des IO asynchrones, c’est pourquoi on dit que des compteurs tels que ‘Current Disk Queue Length’ par exemple peuvent être normalement élevés avec SQL Server, car on envoie plusieurs IOs en même temps.

// writethrougasync.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include <windows.h>
#include <stdlib.h>
#include <winioctl.h>
#include <direct.h>

#define MAXOUTSTANDINGIO 4            // Definit le nb d'IO max en cours
#define FileSizeInBytes 10485760    // Definit la taille max du fichier

int _tmain(int argc, _TCHAR* argv[])
{
    if (argc!=2)
    {
        printf("Usage is: writethrougasync <destfile> \n");
        printf("Example:  writethrougasync destfile.dat \n");
        return -1;
    }

    // Initialisation des différents objets nécessaires: OLs, events, HANDLES, etc... ------------------------------
    OVERLAPPED olwrite[MAXOUTSTANDINGIO];    // Ol IO pour l'écriture
    HANDLE hEvents[MAXOUTSTANDINGIO];        // tableau pour stocker les events écritures

    HANDLE hOutput;                             // HANDLE fichier dest
    LARGE_INTEGER OffsethOutput;                // (Offsets,OffsetHigh) olwrite 

    DWORD dwBytesWritten[MAXOUTSTANDINGIO];     // Nb octets lus par olwrite
    LONGLONG llTotalBytesWritten=0;             // Quantité totale d'octets écrits
    BOOL isASYNCWRITE=FALSE;                    // Flag de contrôle IO async / sync pour les écritures
    int NBIOCOMPLETED=0;                        // Compteur d'IOs terminées
    DWORD dwEventSignPos=0;                     // Index de l'event signalé retourné par WaitForMultipleObjects()

    // Récupération de la taille du secteur disque avec un IOCTL ---------------------------------------------------
    DISK_GEOMETRY dg;
    HANDLE hDrive;
    DWORD ioctlJnk; 

    hDrive=CreateFile(TEXT("\\\\.\\PhysicalDrive0")
                           ,0
                           ,FILE_SHARE_READ
                          | FILE_SHARE_WRITE
                          ,NULL
                          ,OPEN_EXISTING
                          ,0
                          ,NULL);

    if (INVALID_HANDLE_VALUE==hDrive)
    {
        printf("Unable to open drive PhysicalDrive0. Last error=%d\n",GetLastError());
        return 1;
    }

    if (! DeviceIoControl(hDrive
                          ,IOCTL_DISK_GET_DRIVE_GEOMETRY
                          ,NULL
                          ,0
                          ,&dg
                          ,sizeof(dg)
                          ,&ioctlJnk
                          ,NULL) )
    {
        printf("Error on IOCTL (IOCTL_DISK_GET_DRIVE_GEOMETRY) to %s.  Last error=%d\n",argv[1],GetLastError());
        return 1;
    }

    CloseHandle(hDrive);

    // Ouverture du fichier cible en write-though / no buffering / Overlapped -------------------------------------
    hOutput = CreateFile(argv[1]
                         ,GENERIC_READ
                         | GENERIC_WRITE
                          ,0
                          ,NULL
                          ,CREATE_ALWAYS
                          ,FILE_ATTRIBUTE_NORMAL
                          | FILE_FLAG_NO_BUFFERING
                          | FILE_FLAG_WRITE_THROUGH
                          | FILE_FLAG_OVERLAPPED
                          ,NULL);

    if (INVALID_HANDLE_VALUE==hOutput)
    {
        printf("Unable to open output file %S.  Last error=%d\n",argv[1],GetLastError());
        return -1;
    }

    // Initialisation du tampon --------------------------------------------------------------------------------
    wchar_t *csBuffer = (wchar_t *)HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,dg.BytesPerSector * sizeof(wchar_t));
    int len = swprintf_s(csBuffer,dg.BytesPerSector,L"abcdefghijklmnopqrstuvwxyz");    

    // On initialise les events
    for(int i=0;i<MAXOUTSTANDINGIO;i++)
    {        
        hEvents[i] = olwrite[i].hEvent = CreateEvent(NULL,TRUE,FALSE,NULL);
        if (hEvents[i] == NULL)
        {
             printf("Unable to create event for olwrite Last error=%d\n",GetLastError());
             return -1;
        }
    }

    // On envoie les écritures ----------------------------------------------------------------------------------
    OffsethOutput.QuadPart=0;

    while (OffsethOutput.QuadPart < FileSizeInBytes)
    {
         // On envoie MAXOUTSTANDINGIO écritures ASYNC si possible
         for(int i=0;i<MAXOUTSTANDINGIO;i++)
         {        
              // Mise à jour Offset + OffsetHigh pour olwrite
              olwrite[i].Offset        = OffsethOutput.LowPart;
              olwrite[i].OffsetHigh    = OffsethOutput.HighPart;

              if (!WriteFile(hOutput,csBuffer,dg.BytesPerSector,&dwBytesWritten[i],&olwrite[i]))
              {
                   DWORD dwLastErr=GetLastError();            
                   if (ERROR_IO_PENDING == dwLastErr)
                   {    
                       isASYNCWRITE=TRUE;    // On a une IO asynchrone
                   }            
                   else
                   {
                       if (ERROR_SUCCESS == dwLastErr)        // C'est une IO synchrone
                            isASYNCWRITE=FALSE;
                       else
                       {
                           printf("Error when Writing to file %S. Last error=%d\n",argv[1],GetLastError());
                           return -1;
                       }
                   }
                   OffsethOutput.QuadPart += (LONGLONG) dg.BytesPerSector;    // On décale Offset et OffsetHigh de la valeur de l'IO
             }
         }

         NBIOCOMPLETED =0;
         while(NBIOCOMPLETED < MAXOUTSTANDINGIO)
         {
             // On commence à se synchroniser sur les MAXOUTSTANDINGIO écritures envoyées
             dwEventSignPos = WaitForMultipleObjects(MAXOUTSTANDINGIO, hEvents, FALSE, INFINITE) - WAIT_OBJECT_0;

            // Une IO est terminée
            NBIOCOMPLETED++;
            ResetEvent (hEvents[dwEventSignPos]);    // on reset l'event

            if (isASYNCWRITE)
            {
                if (!GetOverlappedResult(hOutput,&olwrite[dwEventSignPos],&dwBytesWritten[dwEventSignPos],TRUE))
                {
                    printf("Error getting pending write IO.  Last error=%d\n",GetLastError());
                    break;
                }
                else
                {
                     // Action principale: on totalise chaque fin d'écriture async
                     llTotalBytesWritten+=dwBytesWritten[dwEventSignPos];
                }
            }
       }
    }

    // A la fin, affichage du nombre d'octets écrits
    printf("%d octets écrits\n", llTotalBytesWritten);        

    //Cleanup -------------------------------------------------------------------------------------------------------
    for (int i = 0; i < MAXOUTSTANDINGIO; i++) {
         CloseHandle (hEvents [i]);
    }
    CloseHandle (hOutput);

    return 0;
}

1. Comme on veut envoyer 4 IO en même temps, on est obligés d’avoir 4 structures Overlapped et 4 events. Donc on utilise un tableau de dimension [MAXOUTSTANDINGIO] de chaque pour stocker nos objets. Les autres variables locales sont plutôt évidentes: un HANDLE pour le fichier, un LARGE_INTEGER pour gérer nos offsets, deux variables pour comptabiliser les octets écrits, etc…
2. Comme dans l’article précédent, l’utilisation conjointe de FILE_FLAG_WRITE_THROUGH et FILE_FLAG_NO_BUFFERING impose de faire des écritures alignées sur la taille du secteur disque, donc on va le récupérer avec un IOCTL. Sur mon laptop, il est de 512 octets.
3. On ouvre le fichier en lui passant les deux flags pré-cités plus FILE_FLAG_OVERLAPPED qui indique que l’on souhaite effectuer des IO asynchrones.
4. On initialise le buffer à écrire avec swprintf_s()
5. On initialise les 4 Events avec CreateEvent() en passant bien bManualReset à TRUE (on resette manuellement l’event, prerequis pour se synchroniser dessus) et bInitialState à FALSE (non signalé, il sera signalé lors de la fin de l’IO correspondant à la structure overlapped).
6. On initialise à 0 les Offsets en utilisant le QuadPart, on commence à écrire en tout début de fichier.
7. On boucle tant qu’on n’a pas écrit la quantité de données attendue (10mb):
8. On met à jour Offset et OffsetHigh puis on envoie les 4 premières IO simultanées: si GetLastError() renvoie 997 (ERROR_IO_PENDING), ASYNCWRITE passe à true et on a bien une IO asynchrone. Sinon si le code retour de WriteFile() est ERROR_IO_SUCCESS, alors on a une IO synchrone, et sinon on a une erreur.
9. On incrémente les valeurs d’offsets en ajoutant la quantité d’octets envoyés avec le QuadPart.
10. Lorsqu’on a envoyé notre premier paquet d’IOs, on bloque avec WaitForMultipleObjects sur le tableau d’events. Lorsqu’un premier event est signalé, on exécute un GetOverlappedResult () sur la structure Overlapped correspondante.
11. On réinitialise l’event pour cette IO (ResetEvent() repasse bInitialState à FALSE).
12. Et on incrémente la quantité totale d’octets écrits jusqu’à écrire les 10Mb, etc…

Résumé:

• Par défaut, une opération d’entrée/sortie est synchrone, et le thread qui l’a initiée doit bloquer et attendre que chaque opération soit terminée avant de poursuivre. Pour ne pas bloquer, on utilise des IO asynchrones.
• On indique le flag FILE_FLAG_OVERLAPPED à la primitive d’ouverture pour indiquer que l’on souhaite faire des IO asynchrones.
• La structure Overlapped contient des informations sur chaque IO asynchrone. Elle doit être initialisée et maintenue dans le code utilisateur.
• Il existe plusieurs façons de se synchroniser sur le retour des IOs, la plus simple étant d’utiliser un event associé à chaque structure overlapped. Cet event doit être à reset manuel et initialisé dans l’état non-signalé.
• Il faut maintenir les pointeurs d’offsets manuellement dans le cas d’une IO asynchrone. On utilise les propriétés Offset et OffsetHigh pour cela.
• Rien ne garantit que l’IO sera bien asynchrone, il existe des cas où il ne sera pas possible de le faire, donc il faut pouvoir tester le code retour de ReadFile() ou WriteFile() et agir en conséquence.
• On peut récupérer la fin d’une IO asynchrone en utilisant GetOverlappedResult() ou HasOverlappedIOCompleted().

La prochaine fois, on verra comment faire pour utiliser les IO completion ports pour gérer les IO asynchrones.

A+. David B.

Biblio:

Windows via C++ (Jeffrey Richter / Christope Navarre)
Floundercraft: a Joseph M. Newcomer resource
http://download.microsoft.com/download/6/E/8/6E882A06-B71B-4642-9EB4-D1EA0D6223C8/SQL%20Server%20IO%20Reliability%20Program%20Requirements%20Document.docx : SQL Server I/O Reliability Program Review.

Notes:

[1] Dave Cutler, le papa de VMS et du premier kernel windows NT avait été tellement déprimé par l’implémentation des APC dans VMS qu’il aurait déclaré plus tard lorsqu’il travaillait sur le kernel NT : « Asynchronous callback I/O will go into Windows over my dead body! »
[2] en dehors de ReadFileEx et WriteFileEx qui sont réservées aux I/Os asynchrones.Continuez votre lecture sur le blog :

• Consistence des écritures avec SATA (David BAFFALEUF) [Operating SystemSQL Server]
• Bench avec NetApp / Datacore / ESX (David BAFFALEUF) [SQL Server]
• Checkpoint not complete: Comment limiter les alertes liées à la journalisation (Louis PROU) [Oracle]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]

Souvent c’est un aspect de l’administration qui est négligé: on effectue des sauvegardes des bases utilisateurs, mais les bases systèmes ne contiennent pas de données métier donc elles ne font pas partie  du plan de maintenance. C’est une erreur qui peut se payer très cher lorsque la base système devient inutilisable.

Dans cet article, nous allons voir comment se sortir de deux cas de corruption de la base master, qui est la clé de voûte de SQL Server:

• Lors du démarrage, le fichier master.mdf n’est pas lisible.
• Lors du démarrage, le fichier master.mdf est lisible mais le recovery sur la base master échoue.

Dans les deux cas, la conséquence est la même: SQL Server ne peut pas démarrer.

Et en prime, une petite vidéo qui illustre le second cas:

Bases système et rôles:

Les bases systèmes sont au nombre de 4 (on ne parle ni de distribution qui est liée à la réplication ni de resource qui n’est pas visible par défaut).

• master: elle contient tous les éléments de configuration et de fonctionnement de l’instance: logins, liste des bases, options de configuration, liste des fichiers, des serveurs liés, endpoints, etc… Sans base master, pas de SQL Server. Donc il faut la sauvegarder.
• msdb: elle contient toutes les informations nécessaires pour que l’agent puisse fonctionner: jobs, alertes, opérateurs, schedules, avec en plus de nombreuses tables d’historique (backupset, backupfile, restorefile, suspect_pages, etc…). Sans base msdb, pas d’agent SQL, pas d’informations statistiques. Donc il faut la sauvegarder.
• model: sert de définition pour toute nouvelle création de base. Nécessaire lors de la séquence de boot de l’instance pour permettre la création de tempdb. Beaucoup diront qu’il n’est pas  nécessaire de sauvegarder la base model, et l’argument est discutable: sans base model, pas de base tempdb au démarrage et donc pas de SQL Server. Sans sauvegarde, il faudrait retrouver une base depuis une instance en même version avec la même collation, alors que SQL Server met moins d’une seconde à sauvegarder cette base de 2Mb. Est-ce que ça ne vaut vraiment pas le coup de l’inclure dans le plan de maintenance ?
• tempdb: base servant à stocker temporairement le résultat d’agrégats (tris, regroupements, etc…), le version store, les facts de DBCC CHECKDB, parmi d’autres choses… Cette base est recréée de zéro à chaque redémarrage. Bien que l’issue de sa création soit critique pour la suite de la séquence de démarrage, les données qui s’y trouvent ne le sont pas. De la sorte, il n’est pas nécessaire de la sauvegarder.

Séquence de démarrage de SQL Server:

Pour bien comprendre quoi faire lorsque la base master est endommagée, il faut d’abord détailler la séquence de démarrage de SQL Server. En rouge les phases importantes pour ce qui nous intéresse dans cet article:

Etape 1:

Server    Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86)    Nov 24 2008 13:01:59 ...
Server    (c) 2005 Microsoft Corporation.
Server    All rights reserved.
Server    Server process ID is 168048.
Server    Authentication mode is MIXED.
Server    Logging SQL Server messages in file 'C:\UTRECHT\MSSQL.1\MSSQL\LOG\ERRORLOG'.
Server    This instance of SQL Server last reported using a process ID of 3332 at 21/06/2011 ...
Server    Registry startup parameters:
Server      -d C:\UTRECHT\MSSQL.1\MSSQL\DATA\master.mdf
Server      -e C:\UTRECHT\MSSQL.1\MSSQL\LOG\ERRORLOG
Server      -l C:\UTRECHT\MSSQL.1\MSSQL\DATA\mastlog.ldf
 

SQL Server va lire ses informations de démarrage dans la base de registre (sous HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\Parameters):
- Le fichier de données de la base master (-d)
- Le journal de transactions de la base master (-l)
- Le fichier ERRORLOG (-e)
- Éventuellement une liste de traceflags (-T, non indiqué dans cet exemple)

Etape 2:

Serveur    SQL Server is starting at normal priority base (=7)...
Serveur    Detected 2 CPUs. This is an informational message; no user action is required.
Serveur    Using dynamic lock allocation.  Initial allocation of 2500 Lock blocks and 5000 ...
Serveur    Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC) ...
Serveur    The Microsoft Distributed Transaction Coordinator (MS DTC) service could not be ...
Serveur    Database mirroring has been enabled on this instance of SQL Server.
spid4s    Starting up database 'master'.
spid4s    6 transactions rolled forward in database 'master' (1) ...
spid4s    0 transactions rolled back in database 'master' (1)...
spid4s    Recovery is writing a checkpoint in database 'master' (1) ...

en 3 sous étapes:
- 2.1 SQL Server ouvre le fichier master.mdf et le journal de transactions.
- 2.2: il exécute un recovery sur la base master.
- 2.3: master est mise en ligne à la fin du recovery.

On note qu’à partir de ce point le thread principal forke un premier fils (spid4s). Le suffixe ‘s‘ apposé au SPID indique qu’il s’agit d’une session système. Une fois la base master en ligne, cette session va demeurer pendant toute la durée d’exécution de SQL Server sous la dénomination ‘SIGNAL HANDLER’. C’est ce thread qui sera chargé d’intercepter ensuite une demande STOP envoyée par le Gestionnaire de Services.

Etape 3:

spid4s    SQL Trace ID 1 was started by login "sa".
spid4s    Starting up database 'mssqlsystemresource'.
spid4s    The resource database build version is 9.00.4035 ...
spid4s    Server name is 'UTRECHT'...
spid9s    Starting up database 'model'.
spid9s    Clearing tempdb database.
spid9s    Starting up database 'tempdb'.

SQL Server ouvre la base model, effectue un recovery et créé la base tempdb. Ces actions sont effectuées par une session système différente (spid9s).

Etape 4:

Serveur    A self-generated certificate was successfully loaded for encryption.
Serveur    Server is listening on [ 'any' <ipv6> 1433].
Serveur    Server is listening on [ 'any' <ipv4> 1433].
Serveur    Server local connection provider is ready to accept connection on ...
Serveur    Server named pipe provider is ready to accept connection on ...
Serveur    Server is listening on [ ::1 <ipv6> 1434].
Serveur    Server is listening on [ 127.0.0.1 <ipv4> 1434].
Serveur    Dedicated admin connection support was established for listening locally on port ...
Serveur    SQL Server is now ready for client connections...
spid12s    The Service Broker protocol transport is disabled or not configured.
spid12s    The Database Mirroring protocol transport is disabled or not configured.
spid12s    Service Broker manager has started.
spid16s    Starting up database 'msdb'.
spid17s    Starting up database 'CAPDATA'.
spid18s    Starting up database 'FoodMart2005'.
spid19s    Starting up database 'demorecovery'.
spid20s    Starting up database 'distribution'.

Enfin dernière étape, les bases utilisateurs sont ouvertes en parallèle et un recovery est exécuté sur chacune d’entre elles. Noter les différents threads système utilisés pour accélérer la mise en ligne.

Il faut savoir que ces étapes de démarrage sont débrayables. On peut indiquer à SQL Server de s’arrêter :
- Soit juste après l’ouverture du fichier master.mdf mais AVANT le début du recovery de master entre les étapes 2.1 et 2.2 (trace flag -T3607)
- Soit juste après le recovery de master, entre les étape 2.3 et 3  (trace flag -T 3608).

Corruption de la base master, quoi faire:

Cas n°1: le fichier master.mdf est illisible:

Lorsqu’un problème survient entre les étapes 2.1 et 2.2, le fichier master.mdf est illisible et ne peut pas être ouvert. Le recovery ne peut pas débuter et l’instance s’arrête:

2011-07-03 15:25:50.27 spid7s      Starting up database 'master'.
2011-07-03 15:25:50.30 spid7s      Error: 824, Severity: 24, State: 6.
2011-07-03 15:25:50.30 spid7s      SQL Server detected a logical consistency-based I/O error: restore pending. It occurred during a read of page (1:0) in database ID 1 at
                                    offset 0000000000000000 in file 'E:\MSSQL10.SQL1\MSSQL\DATA\master_corrupted.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.
2011-07-03 15:25:50.33 spid7s      Error: 5173, Severity: 16, State: 1.
2011-07-03 15:25:50.33 spid7s      One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct
                                   files.  If this is an existing database, the file may be corrupted and should be restored from a backup.

Dans ce cas, c’est l’enveloppe du fichier master.mdf qui est en cause, et on ne peut pas mettre de point d’arrêt avant l’étape 2.1, donc on est obligé de recréer une enveloppe saine pour la base master, que l’on ait un backup ou non.

En version 2005, on était obligé de repartir du DVD d’installation et relancer un setup /wait REINSTALL=SQL_Engine REBUILDDATABASE=1 pour reconstruire toutes les bases système. Donc au passage, si on n’avait pas non plus de sauvegarde de msdb, adieu jobs, opérateurs, alertes…

Depuis la version 2008, fort heureusement, un mini-setup et des templates des bases systèmes se trouvent dans le répertoire de base de SQL Server, et on n’a plus besoin du DVD d’installation:

• Le setup embarqué: c:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Release\Setup.exe
• Les templates des bases systèmes: sous le répertoire des binaires de l’instance, sous Binn\Templates.

On relance donc une réinstallation des bases systèmes à partir de là:

DOS>setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=SQL1 /SQLSYSADMINACCOUNTS=user1 /SAPWD=m0np@$$w0rdS@ /SQLCOLLATION=French_CI_AS
Microsoft (R) SQL Server 2008 Setup 10.00.2735.00
Copyright (c) Microsoft Corporation.  All rights reserved.
DOS>
 

• /ACTION=REBUILDDATABASE : indique que l’on souhaite reconstruire les bases systèmes.
• /INSTANCE=: est le nom de l’instance à reconstruire, on aurait utilisé MSSQLSERVER s’il avait s’agit d’une instance par défaut.
• /SQLSYSADMINACCOUNTS= : donne le ou les comptes à ajouter au rôle sysadmin lors de la réinstallation, c’est un minimum pour pouvoir ensuite se connecter.
• /SAPWD= : le mot de passe pour le compte SA lorsque l’authentification est MIXED.
• /SQLCOLLATION= : la collation de l’instance.

On peut vérifier la bonne exécution du setup dans le fichier Summary.txt sous ~SetupBootstrap\Log:

Overall summary:
 Final result:                  Passed
 Exit code (Decimal):           0
 Exit message:                  Passed
 Start time:                    2011-07-03 15:50:37
 End time:                      2011-07-03 15:52:36
 Requested action:              RebuildDatabase

Puis il faut redémarrer l’instance en mode mono-utilisateur dans une fenêtre DOS:

E:\MSSQL10.SQL1\MSSQL\Binn>sqlservr -m -s SQL1
2011-07-03 15:53:25.63 Server      Microsoft SQL Server 2008 (SP1) - 10.0.2757.0 (Intel X86)
 Jan  8 2010 20:19:57
 Copyright (c) 1988-2008 Microsoft Corporation
 Enterprise Edition on Windows NT 6.0 <X86> (Build 6001: Service Pack 1) (VM)

2011-07-03 15:53:25.63 Server      (c) 2005 Microsoft Corporation.
2011-07-03 15:53:25.63 Server      All rights reserved.
2011-07-03 15:53:25.64 Server      Server process ID is 952.
2011-07-03 15:53:25.64 Server      System Manufacturer: 'VMware, Inc.', System Model: 'VMware Virtual Platform'.
2011-07-03 15:53:25.64 Server      Authentication mode is MIXED.
2011-07-03 15:53:25.64 Server      Logging SQL Server messages in file 'E:\MSSQL10.SQL1\MSSQL\Log\ERRORLOG'.
2011-07-03 15:53:25.64 Server      This instance of SQL Server last reported using a process ID of 816 at 7/3/2011 3:52:34 PM (local) 7/3/2011 1:52:34 PM (UTC). ...
2011-07-03 15:53:25.64 Server      Registry startup parameters:
 -d E:\MSSQL10.SQL1\MSSQL\DATA\master.mdf
 -e E:\MSSQL10.SQL1\MSSQL\Log\ERRORLOG
 -l E:\MSSQL10.SQL1\MSSQL\DATA\mastlog.ldf
2011-07-03 15:53:25.64 Server      Command Line Startup Parameters:
 -m
 -s SQL1
 SQL1
2011-07-03 15:53:25.67 Server      SQL Server is starting at normal priority base (=7). This is an informational message only...
2011-07-03 15:53:25.67 Server      Detected 1 CPUs. This is an informational message; no user action is required.
2011-07-03 15:53:25.70 Server      Perfmon counters for resource governor pools and groups failed to initialize and are disabled.
2011-07-03 15:53:25.70 Server      Using dynamic lock allocation.  Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node...
2011-07-03 15:53:25.82 Server      Node configuration: node 0: CPU mask: 0x00000001 Active CPU mask: 0x00000001. This message provides a description of the NUMA configuration for this computer...
2011-07-03 15:53:25.85 Server      Database Mirroring Transport is disabled in the endpoint configuration.
2011-07-03 15:53:25.86 spid7s      Warning ******************
2011-07-03 15:53:25.87 spid7s      SQL Server started in single-user mode. This an informational message only. No user action is required.
2011-07-03 15:53:25.87 spid7s      Starting up database 'master'.
2011-07-03 15:53:25.98 spid7s      Recovery is writing a checkpoint in database 'master' (1)...
2011-07-03 15:53:26.05 spid7s      SQL Server Audit is starting the audits. This is an informational message. No user action is required.
2011-07-03 15:53:26.05 spid7s      SQL Server Audit has started the audits. This is an informational message. No user action is required.
2011-07-03 15:53:26.07 spid7s      FILESTREAM: effective level = 0, configured level = 0, file system access share name = 'SQL1'.
2011-07-03 15:53:26.17 spid7s      SQL Trace ID 1 was started by login "sa".
2011-07-03 15:53:26.18 spid7s      Starting up database 'mssqlsystemresource'.
2011-07-03 15:53:26.22 spid7s      The resource database build version is 10.00.2757...
2011-07-03 15:53:26.63 spid9s      Starting up database 'model'.
2011-07-03 15:53:26.98 Server      A self-generated certificate was successfully loaded for encryption.
2011-07-03 15:53:26.99 spid7s      Server name is 'VMSUSER1\SQL1'. This is an informational message only. No user action is required.
2011-07-03 15:53:27.17 Server      Server is listening on [ 'any' <ipv6> 49161].
2011-07-03 15:53:27.21 Server      Server is listening on [ 'any' <ipv4> 49161].
2011-07-03 15:53:27.24 Server      Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQL1 ].
2011-07-03 15:53:27.24 Server      Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQL1\sql\query ].
2011-07-03 15:53:27.28 Server      Server is listening on [ ::1 <ipv6> 49162].
2011-07-03 15:53:27.28 Server      Server is listening on [ 127.0.0.1 <ipv4> 49162].
2011-07-03 15:53:27.28 Server      Dedicated admin connection support was established for listening locally on port 49162.
2011-07-03 15:53:27.29 Server      The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQLServer service...
2011-07-03 15:53:27.30 Server      SQL Server is now ready for client connections. This is an informational message; no user action is required.
2011-07-03 15:53:27.36 spid9s      Clearing tempdb database.
2011-07-03 15:53:27.38 spid11s     A new instance of the full-text filter daemon host process has been successfully started.
2011-07-03 15:53:27.44 spid7s      Starting up database 'msdb'.
2011-07-03 15:53:28.04 spid9s      Starting up database 'tempdb'.
2011-07-03 15:53:28.23 spid7s      Recovery is complete. This is an informational message only. No user action is required.

Dans une seconde fenêtre de commande, se connecter et restaurer le backup :

C:\Users\user1>sqlcmd -E -S .\SQL1
1> restore database master from disk='E:\MSSQL10.SQL1\MSSQL\Backup\master.bak'
2> go
Processed 376 pages for database 'master', file 'master' on file 1.
Processed 4 pages for database 'master', file 'mastlog' on file 1.
The master database has been successfully restored. Shutting down SQL Server.
SQL Server is terminating this process.

Quand on est bien rôdé, la restauration ne prend pas plus de cinq minutes. Une fois la base restaurée, SQL Server s’arrête, et il ne reste plus qu’à le redémarrer via net start ou la console Configuration Manager. Et le service est de nouveau en ligne.

Cas n°2: le fichier master.mdf est lisible mais le recovery échoue:

C’est le cas utilisé dans la démo. Lorsqu’un problème survient entre les étapes 2.2 et 2.3, le fichier master.mdf est ouvert et le recovery commence, mais échoue avant d’avoir pu aller au bout. Même conséquence, la base master ne peut être ouverte et l’instance doit s’arrêter:

2011-07-03 16:11:32.98 spid7s      Starting up database 'master'.
2011-07-03 16:11:34.89 spid7s      Error: 824, Severity: 24, State: 2.
2011-07-03 16:11:34.89 spid7s      SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:84; actual 12336:808464432).
                                   It occurred during a read of page (1:84) in database ID 1 at offset 0x000000000a8000 in file 'E:\MSSQL10.SQL1\MSSQL\DATA\master_corrupted.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.
2011-07-03 16:11:34.94 spid7s      Error: 3314, Severity: 21, State: 1.
2011-07-03 16:11:34.94 spid7s      During undoing of a logged operation in database 'master', an error occurred at log record ID (196:64:2). Typically, the specific failure is logged
                                   previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2011-07-03 16:11:34.94 spid7s      Cannot recover the master database. SQL Server is unable to run. Restore master from a full backup, repair it, or rebuild it. For more information
                                   about how to rebuild the master database, see SQL Server Books Online.

Contrairement au cas précédent, l’étape d’ouverture de master.mdf est validée donc si on a un backup on peut intercaler un point d’arrêt et dire à SQL Server de stopper la séquence de démarrage juste avant le recovery, en utilisant le traceflag -T3607:

E:\MSSQL10.SQL1\MSSQL\Binn>sqlservr -m -T 3607 -s SQL1
2011-07-03 15:19:21.42 Server      Microsoft SQL Server 2008 (SP1) - 10.0.2757.0 (Intel X86)
 Jan  8 2010 20:19:57
 Copyright (c) 1988-2008 Microsoft Corporation
 Enterprise Edition on Windows NT 6.0 <X86> (Build 6001: Service Pack 1) (VM)

2011-07-03 15:19:21.47 Server      (c) 2005 Microsoft Corporation.
2011-07-03 15:19:21.47 Server      All rights reserved.
2011-07-03 15:19:21.48 Server      Server process ID is 560.
2011-07-03 15:19:21.48 Server      System Manufacturer: 'VMware, Inc.', System Model: 'VMware Virtual Platform'.
2011-07-03 15:19:21.48 Server      Authentication mode is MIXED.
2011-07-03 15:19:21.48 Server      Logging SQL Server messages in file 'E:\MSSQL10.SQL1\MSSQL\Log\ERRORLOG'.
2011-07-03 15:19:21.53 Server      This instance of SQL Server last reported using a process ID of 1996 at 7/2/2011 11:52:16 PM (local) 7/2/
2011 9:52:16 PM (UTC). This is an informational message only; no user action is required.
2011-07-03 15:19:21.53 Server      Registry startup parameters:
 -d E:\MSSQL10.SQL1\MSSQL\DATA\master_corrupted.mdf
 -e E:\MSSQL10.SQL1\MSSQL\Log\ERRORLOG
 -l E:\MSSQL10.SQL1\MSSQL\DATA\mastlog_corrupted.ldf
2011-07-03 15:19:21.54 Server      Command Line Startup Parameters:
 -m
 -T 3607
 3607
 -s SQL1
 SQL1
2011-07-03 15:19:21.62 Server      SQL Server is starting at normal priority base (=7). This is an informational message only. No user action is required.
2011-07-03 15:19:21.62 Server      Detected 1 CPUs. This is an informational message; no user action is required.
2011-07-03 15:19:22.18 Server      Perfmon counters for resource governor pools and groups failed to initialize and are disabled.
2011-07-03 15:19:22.22 Server      Using dynamic lock allocation.  Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node.  ...
2011-07-03 15:19:23.13 Server      Node configuration: node 0: CPU mask: 0x00000001 Active CPU mask: 0x00000001. This message provides a description of the NUMA configuration for this computer. ...
2011-07-03 15:19:23.34 Server      Database Mirroring Transport is disabled in the endpoint configuration.
2011-07-03 15:19:23.40 spid7s      Warning ******************
2011-07-03 15:19:23.41 spid7s      SQL Server started in single-user mode. This an informational message only. No user action is required.
2011-07-03 15:19:23.41 spid7s      Starting without recovery. This is an informational message only. No user action is required.
2011-07-03 15:19:23.56 spid7s      Starting up database 'master'.
2011-07-03 15:19:24.99 Server      A self-generated certificate was successfully loaded for encryption.
2011-07-03 15:19:25.02 Server      Server is listening on [ 'any' <ipv6> 49161].
2011-07-03 15:19:25.03 Server      Server is listening on [ 'any' <ipv4> 49161].
2011-07-03 15:19:25.05 Server      Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQL1 ].
2011-07-03 15:19:25.05 Server      Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQL1\sql\query ].
2011-07-03 15:19:25.07 Server      Server is listening on [ ::1 <ipv6> 49162].
2011-07-03 15:19:25.08 Server      Server is listening on [ 127.0.0.1 <ipv4> 49162].
2011-07-03 15:19:25.08 Server      Dedicated admin connection support was established for listening locally on port 49162.
2011-07-03 15:19:25.12 Server      The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL
Server service. Error: 0x54b, state: 3. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos...
2011-07-03 15:19:25.13 Server      SQL Server is now ready for client connections. This is an informational message; no user action is required.

Ensuite on ouvre un second prompt DOS et on restaure la sauvegarde de master :

C:\Users\user1>sqlcmd -E -S .\SQL1
1> restore database master from disk='E:\MSSQL10.SQL1\MSSQL\Backup\master.bak'
2> go
Processed 376 pages for database 'master', file 'master' on file 1.
Processed 4 pages for database 'master', file 'mastlog' on file 1.
The master database has been successfully restored. Shutting down SQL Server.
SQL Server is terminating this process.

Là encore, SQL Server détecte qu’une restauration de la base master vient d’avoir lieu, et stoppe l’instance immédiatement ensuite. Il suffit de redémarrer le service via SQL Configuration Manager et notre application est de nouveau disponible, tout ça en moins de 2 minutes.

Sans backup dans ce cas, il aurait fallu reconstruire une enveloppe de la base master comme dans le cas précédent, puis remettre à jour tous les logins, serveurs liés, options de configuration, patches, endpoints, etc… et enfin rattacher les bases utilisateur.

Conclusion:

La conclusion est simple: sauvegardez vos bases système. Si master se retrouve endommagée, sans backup le temps passé à remonter toutes les informations sera beaucoup plus important, et parfois il ne sera pas possible de tout remonter (les mots de passe des logins par exemple, certaines options de configuration modifiées). Le préjudice peut être très élevé: une interruption intempestive coûte cher à l’entreprise: pénalités financières par rapport aux clients, crise d’image, etc… alors qu’ajouter trois petites bases système dans un plan de maintenance ne vous coûte quasiment rien.

A+. David B.Continuez votre lecture sur le blog :

• How-To : réduire l’enveloppe de tempdb (David BAFFALEUF) [SQL Server]
• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Principes d’une sauvegarde à chaud (David BAFFALEUF) [SQL Server]
• How-To: réduire la taille du journal de transactions sur disque (David BAFFALEUF) [SQL Server]

Il n’est pas forcément évident de repérer une session d’exécution d’un package SSIS parmi toutes les sessions connectées au même moment sur un server SQL.

Pour repérer le package SSIS , il est possible de donner un nom parlant et repérable à votre package, en ajoutant la propriété « Application Name »  dans la chaîne de connexion
de la source de données SSIS comme dans l’exemple suivant:

Data Source=MonServer;User ID=Monuser;Initial Catalog=Mabase;Provider=SQLNCLI10;
Persist Security Info=True;Auto Translate=False;Application Name=Monapplication;

Une fois recompilé, le package SSIS  sera repérable de la manière suivante dans la liste de vos sessions :

select program_name, S.* from sys.dm_exec_sessions S where program_name  like 'Monapplication%'

ApplicationName='Monapplication'

Continuez votre lecture sur le blog :

• OPENROWSET, épisode 1 (David BAFFALEUF) [SQL Server]
• I/O asynchrones (épisode 1) (David BAFFALEUF) [Operating SystemSQL Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• Journées SQL Server 12/13 décembre (suite) (David BAFFALEUF) [SQL Server]
• Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David BAFFALEUF) [SQL Server]

Msg*8909, Niveau*16, État*1, Ligne*1
Erreur de TABLE : Objet ID = 0, INDEX ID*=*0, page ID = (1:22988). ID de page de l'en-tête
de page = (0:0).
CHECKDB a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence non associées à un
quelconque objet UNIQUE.
Msg*8928, Niveau*16, État*1, Ligne*1
Objet ID = 574885365, INDEX ID = 0 : La page (1:22988) ne peut pas être traitée. Pour
plus d'informations, consultez les autres erreurs.
Msg*8976, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 574885365, index ID = 1. Page (1:22988) n'a pas été trouvé
dans l'analyse bien que ses parents (1:22930) et (1:22987) précédents y font référence.
Contrôlez toutes les erreurs précédentes.
Msg*8978, Niveau*16, État*1, Ligne*1
Erreur de table : Objet ID = 574885365, index ID = 1. La page (1:22989) n'a pas de référence
dans la page précédente (1:22988). Possibilité d'un problème de liaison de chaîne.
CHECKDB a trouvé 0 erreurs d'allocation et 3 erreurs de cohérence dans la TABLE
'XXXXXXXX' (objet ID = 574885365).
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la base de
données 'xxxxxxx'.
repair_allow_data_loss est le minimum de niveau de réparation pour les erreurs trouvés
par DBCC CHECKDB (chantier ).

Outre le fait qu’un problème matériel empêche tout bonnement la lecture d’une page depuis le disque, le CHECKDB indique deux autres erreurs 8978 et 8976, parlant d’un problème de liaison de page. On rappelle que chaque page de données ou d’index hors pages spéciales (IAM, DBINFO, SGAM, GAM, PFS, ML, DM,…) est liée à la page qui la précède et à la page qui la suit dans le plan d’allocation, mais aussi à une page parente dans un index.

Lorsqu’une page parente référence une page à un niveau inférieur du B-tree et que cette page n’est pas trouvée, alors DBCC CHECKDB renvoie une erreur 8976. Lorsqu’une page référence une page Next et que cette page n’est pas trouvée, alors DBCC CHECKDB renvoie une erreur 8978. Mais ces messages n’indiquent pas s’il ne s’agit que d’une corruption de l’entête de la page, ou aussi des données.

Ce qui veut dire que les données peuvent être bonnes alors que DBCC CHECKDB nous oriente vers un repair_allow_data_loss comme méthode de résolution, avec les conséquences que l’on sait (désallocation de la page qui pose problème et perte des données).

Dans le cas évoqué sur developpez.net, la personne ne dispose pas de backup, la question est de savoir quelles données il risque de perdre, et si les données ne sont pas endommagées, comment peut-il les récupérer.

Repro pour ce problème

Nous allons créer une base linkcorrupt et modifier la valeur du pointeur prevPageID dans une page de niveau feuille d’un index cluster pour forcer des erreurs 8976 et 8978.

create database linkcorrupt
GO
use linkcorrupt
GO
create table T1(
     a numeric identity,
     b char(4000) default replicate('b',4000),
     c bigint default round(rand()*100,0))
GO
insert into T1 default values
GO 1000
create unique clustered index IDX_T1C on T1(a)
GO

On va choisir une page du niveau feuille de l’index cluster (le dbcc ind a été purgé de certaines colonnes pour une meilleure lisibilité)

dbcc ind('linkcorrupt','T1',-1)

 PageFID PagePID     PageType  IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID
 ------- ----------- --------  ---------- ----------- ----------- ----------- -----------
 1       90          10        NULL       0           0           0           0
 1       110         2         1          1           115         0           0
 1       115         2         1          0           0           1           110
 1       121         2         2          0           0           0           0
 1       672         1         0          1           673         0           0
 1       673         1         0          1           674         1           672
 1       674         1         0          1           675         1           673
 1       675         1         0          1           676         1           674
 1       676         1         0          1           677         1           675
 1       677         1         0          1           678         1           676
 1       678         1         0          1           679         1           677
 1       679         1         0          1           680         1           678
 1       680         1         0          1           681         1           679
 ...

De ce résultat on déduit que:

• La page 1:90 est la page IAM pour T1.
• La page 1:121 est la page racine de l’index cluster
• Les pages 1:110 et 1:115 sont des pages de niveau intermédiaire pour l’index cluster (on aura volontairement casé deux lignes par page pour augmenter le feuillage de l’index).
• Les autres pages sont les pages du niveau feuille de l’index cluster. On choisira de corrompre le pointeur prevPagePID dans la page 1:674. Comme l’index vient juste d’être construit, il est parfaitement clusterisé et les pages avant et après sont respectivement 1:673 et 1:675. On passe la base hors-ligne et on ouvre le fichier MDF dans xvi32.

alter database linkcorrupt set offline

La page 1:674 se trouve à l’offset 0×544000 dans le fichier mdf  (674*8192). Il est alors aisé de repérer les offset où sont stockés les pointeurs prev et next:

Le trait rouge représente l’offset 0 de la page 1:674. Les 96 premiers octets constituent l’entête de la page. x86 étant en little-endian, l’octet de poids faible est en premier donc il faut lire à l’envers. 02A1 représente notre page prev 1:673, 02A3 notre page next 1:675 et 02A2 notre PageID. On décide de zéro-initialiser l’octet de poids faible de 673 :

On repasse alors la base en ligne et on contrôle notre base pour vérifier qu’elle se trouve bien dans l’état attendu:

alter database linkcorrupt set online
GO
dbcc checkdb ('linkcorrupt') with no_infomsgs, all_errormsgs
GO

Msg 8928, Niveau 16, État 1, Ligne 1
ID d'objet 2073058421, ID d'index 1, ID de partition 72057594038386688,  ID d'unité d'allocation 72057594043367424 (type In-row data) :
impossible de traiter la page (1:674). Pour plus d'informations,  consultez les autres erreurs.
Msg 8939, Niveau 16, État 98, Ligne 1
Erreur de table : ID d'objet 2073058421, ID d'index 1, ID de partition  72057594038386688, ID d'unité d'allocation 72057594043367424
(type  In-row data), page (1:674). Échec du test (IS_OFF (BUF_IOERR,  pBUF->bstat)). Valeurs 12716041 et -4.
Msg 8976, Niveau 16, État 1, Ligne 1
Erreur de table : ID d'objet 2073058421, ID d'index 1, ID de partition  72057594038386688, ID d'unité d'allocation 72057594043367424
(type  In-row data). La page (1:674) n'a pas été détectée lors de l'analyse  alors que sa page parent (1:110) et les (1:673) pages précédentes
la  référencent. Vérifiez les erreurs précédentes.
Msg 8978, Niveau 16, État 1, Ligne 1
Erreur de table : ID d'objet 2073058421, ID d'index 1, ID de partition  72057594038386688, ID d'unité d'allocation 72057594043367424
(type  In-row data). Une référence de la page précédente (1:674) est manquante à  la page (1:675). Un problème de liaison de chaîne s'est
peut-être  produit.
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la table 'T1' (ID d'objet 2073058421).
CHECKDB a trouvé 0 erreurs d'allocation et 4 erreurs de cohérence dans la base de données 'linkcorrupt'.
repair_allow_data_loss est le niveau minimum de réparation pour les erreurs trouvées par DBCC CHECKDB (linkcorrupt).

Identifier les plages de valeurs concernées par la corruption:

Une des questions qu’on peut se poser, comment savoir ce qu’il y a à récupérer (si les données ne sont pas touchées) ou ce qu’on va potentiellement perdre (si les données sont touchées).

Avant cela, il faut déjà récupérer tout le reste de la table en injectant les données jusqu’à la page 1:673 comprise et à partir de la page 1:675 comprise, puis d’inspecter la page 1:674 pour voir si les données qui y sont contenues sont lisibles. On sait que les pages sont classées physiquement dans l’ordre de notre clé clusterisée, donc il suffit pour exclure l’intervalle compris dans la page 1:674, de connaître la dernière valeur de ‘a’ dans la page 1:673 et la première valeur de ‘a’ dans la page 1:675.

On créé deux tables temporaires pour stocker le résultat des dbcc page sur les deux pages prev et next:

CREATE TABLE #recover673 (parentobject varchar(50), Object varchar(100), Field varchar(50), Value varchar(max))
GO
INSERT INTO #recover673  exec ('dbcc page(10,1,673,3) with tableresults')
GO

CREATE TABLE #recover675 (parentobject varchar(50), Object varchar(100), Field varchar(50), Value varchar(max))
GO
INSERT INTO #recover675  exec ('dbcc page(10,1,675,3) with tableresults')
GO

C’est la table d’offset de ligne qui permet de retourner les lignes dans l’ordre, dans les faits les lignes ne sont pas nécessairement classées physiquement dans la page. On se sert des slots pour connaître la dernière valeur de ‘a’ dans la page 1:673 et la première dans la page 1:675 (on rappelle qu’on n’a que deux lignes par page).

select Object, Value FROM #recover673 where Field='a'
Object                                    Value
--------------------------------------  ---------
Slot 0 Column 0 Offset 0x4 Length 9        3
Slot 1 Column 0 Offset 0x4 Length 9        4

select Object, Value FROM #recover675 where Field='a'

Object                                    Value
--------------------------------------  ---------
Slot 0 Column 0 Offset 0x4 Length 9        7
Slot 1 Column 0 Offset 0x4 Length 9        8

Il s’agit donc des valeurs de clé 5 et 6 qui sont dans la page qui pose problème. On créé une table à l’identique et on injecte les deux plages de valeurs [0;4] et [7;1000]:

select * into T1_backup from T1 where 1=2
GO
insert into T1_backup select a,b from T1 with (index = IDX_T1C) where a in (1,2,3,4)
GO
insert into T1_backup select a,b from T1 with (index = IDX_T1C) where a >=7
GO

En vert, un hint qui permet de forcer un seek sur l’index clusterisé. En effet, un Clustered Index Scan aurait tenté de lire les pages 1:673 -> 1:674 et aurait remonté une erreur de chaînage et une erreur 824.

Il ne reste plus qu’à essayer de lire le contenu de la page endommagée pour voir ce qu’il peut y avoir de récupérable:

CREATE TABLE #recover674 (parentobject varchar(50), Object varchar(100), Field varchar(50), Value varchar(max))
GO
insert into #recover674  exec ('dbcc page(17,1,674,3) with tableresults')
GO

Si la page est lisible alors une requête simple permet de ramener les valeurs au format de T1:

with TA as (select cast(Object as char(6)) SlotID, Value from #recover674 where Field='a'),
TB as (select cast(Object as char(6)) SlotID, Value from #recover674 where Field='b')
insert into T1_backup select TA.Value as 'a', TB.value as 'b' from TA inner join TB on TA.SLotID = TB.SlotID

a      b
-------------------------------
5      bbbbbbbbbbbbbbbbbbb(...)
6      bbbbbbbbbbbbbbbbbbb(...)

Dans le cas où les données ne sont pas lisibles, on a au moins l’information de la plage qui est perdue, information que ne donne pas le repair_allow_data_loss.

A+. David B.Continuez votre lecture sur le blog :

• Msg 2508, Level 16, State 1: the In-Row data %% for object %% is incorrect (David BAFFALEUF) [SQL Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]
• Alter table rebuild (Louis HOCHBERG) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]

dbcc checkdb('MvxRef') with no_infomsgs, all_errormsgs

Msg 2508, Niveau 16, État 1, Ligne 1
Le nombre In-row data USED page pour l'objet 'Client_NULL', ID d'index 0,
ID de partition 29725599596544,ID d'unité d'allocation 29725599596544
(type In-row data) est incorrect. Exécutez DBCC UPDATEUSAGE.
CHECKDB a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence
dans la table 'Client_NULL' (ID d'objet 453576654).
CHECKDB a trouvé 0 erreurs d'allocation et 1 erreurs de cohérence
dans la base de données 'MvxRef'.

Lorsque DBCC CHECKDB arrive sur un objet en particulier, il se constitue une synthèse des informations qui décrivent la table, et notamment le décompte de pages totales allouées, et de pages utilisées pour l’objet. Si une des valeurs est négative, le message 2508 est renvoyé avec en paramètre une indication sur quelle valeur est négative (RSVD pour le nombre total de pages, USED pour le nombre de pages utilisées). La valeur négative en question est remontée par la DMV sys.allocation_units:

select allocation_unit_id, type_desc, container_id,total_pages, used_pages
from sys.allocation_units AU inner join sys.partitions P on AU.container_id = P.hobt_id
and P.object_id = object_id('Client_NULL')

allocation_unit_id   type_desc        container_id         total_pages    used_pages  
-------------------- ---------------- -------------------- -------------- ------------
29725599596544       IN_ROW_DATA      29725599596544       0              -104         

Il se trouve que la table a été vidée de son contenu entre deux DBCC CHECKDB, et l’erreur n’avait pas été détectée immédiatement après la migration. Un petit coup de DBCC UPDATEUSAGE sur cette table:

dbcc updateusage('MvxRef','Client_NULL')

DBCC UPDATEUSAGE : nombre mis à jour pour la table 'Client_NULL'
(index 'Client_NULL', partition 1) :
 Pages USED (In-row Data) : changement de (-104) pages en (0) pages.
Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur,
contactez l'administrateur système.

Et tout est rentré dans l’ordre:

select allocation_unit_id, type_desc, container_id,total_pages, used_pages
from sys.allocation_units AU inner join sys.partitions P on AU.container_id = P.hobt_id
and P.object_id = object_id('Client_NULL')

allocation_unit_id   type_desc     container_id         total_pages   used_pages
-------------------- ------------- -------------------- ------------- ------------
29725599596544       IN_ROW_DATA   29725599596544       0             0           

A+. David B.Continuez votre lecture sur le blog :

• Error 8976 / 8978, problèmes de chaînage, comment récupérer les données (David BAFFALEUF) [SQL Server]
• Suppression accidentelle de ligne : comment retrouver le coupable ? (David BAFFALEUF) [SQL Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]
• Pourquoi il faut sauvegarder les bases systèmes (David BAFFALEUF) [SQL Server]
• How-To : réduire l’enveloppe de tempdb (David BAFFALEUF) [SQL Server]

Contexte technique:

DataCore SANMelody / NetApp:

Le but de la manœuvre est de déterminer le débit maximum que sera capable de tirer le  sous système IO cible. L’architecture est la suivante:

2 salles techniques composées chacune de (
- 1 Contrôleur NetApp FAS 3210
- 1 tiroir T1 de 14 x 450 Gb SAS 15KRPM en RAIDDP. (11 disques data, 2 disques DP, 1 disque de spare).
- 1 tiroir T2 de 14 x 600 Gb SAS 15KRPM en RAIDDP. (11 disques data, 2 disques DP, 1 disque de spare).
- 1 tiroir T3 de 14 x 600 Gb SAS 15KRPM en RAIDDP. (11 disques data, 2 disques DP, 1 disque de spare).
- 1 contrôleur DataCore SANMelody 3.0.3.5, 16Gb cache.
- 1 volume Tiers1 pris sur le tiroir T1 raccordé directement à DataCore.
)

Soit:

SANMelody est un logiciel tournant sur Windows Server et qui émule un SAN en quelque sorte.  Il s’intercale entre le SAN et le host, et présente aux machines clientes (en l’occurence ici les 2 ESX) des disques comme s’il s’agissait directement du SAN. Il est à la fois initiateur côté baie, et target côté host. Deux avantages principaux:
- Il réserve une grande partie de la mémoire de la machine Windows pour bufferiser les IOs en provenance des hosts. Il ajoute un niveau de cache supplémentaire ici de 16Gb par contrôleur ce qui n’est pas rien.
- Ensuite, il permet de répliquer les blocs vers un second contrôleur de manière synchrone pour assurer une redondance des données.

Il est clair que le cache utilisé par SANMelody n’est pas WAL compliant dans la mesure où celui-ci réserve ses buffers à partir de la mémoire présentée par windows. Par contre, dans la mesure où le contrôleur est répliqué en synchrone sur une autre salle, chacune étant alimentée de manière autonome, on limite les risques. Il faudrait que les deux salles tombent en même temps pour exposer des données à la corruption. D’ailleurs une option ‘Force Cache Write Through‘ existe au niveau de SANMelody, qui permet comme son nom l’indique de forcer les écritures sur le média (donc le contrôleur NetApp). Donc bon, dans l’absolu, avec une bonne stratégie de backup derrière, pourquoi pas…

Dans tous les cas, nous allons tester avec et sans cette option.

Les ESX:

Du côté de la VM, on ne peut pas vraiment faire mieux: les procs sont des core i7 Xeon 7560, 64 bits, VT compatibles. D’après la matrice de VMM [1], un guest en 64 bits sur une telle plateforme profitera des avantages suivants:

- Il s’exécute en ring 0, donc on est en CPU-direct (pas de translation binaire).
- L’hyperviseur utilisera la technologie EPT du core i7 pour décharger la gestion des page tables et de la mémoire par guest.

On n’utilisera pas VMFS mais directement du soft RDM, donc pas d’histoire d’alignement [2]. Et de toutes façons, dans la mesure où ESX est amené à disparaître au profit d’ESXi, on pourra difficilement vérifier cela à l’avenir puisqu’on n’aura plus de service console.

Le guest OS quant à lui sera un Windows 2008R2 64 bits avec 4vCPU, 4Gb de mémoire dans un premier temps, et SQL Server 2005 x64 Enterprise Edition.

Les deux ESX forment un cluster HA DRS. Nous avons testé de lancer une alimentation (1 million de singleton inserts) pendant une bascule vMotion pour valider la partie secours et on n’a observé qu’un overhead de 7% seulement.

SQLIO:

Pour tester le sous système IO complet, nous nous appuierons sur SQLIO. Quelques rappels sur les paramètres de base:

Usage: sqlio [options] [<filename>...]
 [options] may include any of the following:
 -k<R|W>                 kind of IO (R=reads, W=writes)
 -t<threads>             number of threads
 -s<secs>                number of seconds to run
 -d<drv_A><drv_B>..      use same filename on each drive letter given
 -R<drv_A/0>,<drv_B/1>.. raw drive letters/number for I/O
 -f<stripe factor>       stripe size in blocks, random, or sequential
 -p[I]<cpu affinity>     cpu number for affinity (0 based)(I=ideal)
 -a[R[I]]<cpu mask>      cpu mask for (R=roundrobin (I=ideal)) affinity
 -o<#outstanding>        depth to use for completion routines
 -b<io size(KB)>         IO block size in KB
 -i<#IOs/run>            number of IOs per IO run
 -m<[C|S]><#sub-blks>    do multi blk IO (C=copy, S=scatter/gather)
 -L<[S|P][i|]>           latencies from (S=system, P=processor) timer
 -B<[N|Y|H|S]>           set buffering (N=none, Y=all, H=hdwr, S=sfwr)
 -S<#blocks>             start I/Os #blocks into file
 -v1.1.1                 I/Os runs use same blocks, as in version 1.1.1
 -F<paramfile>           read parameters from <paramfile>
Defaults:
 -kR -t1 -s30 -f64 -b2 -i64 -BN testfile.dat
Maximums:
 -t (threads):                   256
 no. of files, includes -d & -R: 256
 filename length:                256

Nous nous contenterons d’utiliser les paramètres suivants:

-k: type d’accès (lectures / écritures)
- s: durée du test en secondes.
- f: sequential / random.
- o: nombre d’outstandings IOs, le nombre d’I/Os en attente par thread. Dans la mesure où chaque worker et le Lazy Writer postent la grande majorité des IOs en asynchrone, il y a des chances qu’il y ait plus d’une IO asynchrone par thread à un instant donné. Nous choisirons de tester 64, 128 et 256 outstanding IOs par thread.
- b: taille de l’IO. Nous utiliserons toutes les tailles multiple de la page de 8K jusqu’à 256K, en accès séquentiel, et seulement 8k en aléatoire.
- L: indique que nous souhaitons récupérer les valeurs de latence remontées par le système.
- B: indique que nous ne souhaitons pas utiliser le cache NTFS (les fichiers de données et journaux sont ouverts en FILE_FLAG_WRITE_THROUGH | FILE_FLAG_NO_BUFFERING)
- F: nous allons passer à sqlio un fichier de paramètres dans lequel nous indiquerons le nombre de threads et la taille et la localisation du fichier de test.

Différentes batteries de tests:

Nous allons tester trois configuration possibles:

BANC1: NetApp -> Datacore sans Force Cache Write Through -> ESX -> Guest OS
BANC2:- NetApp -> Datacore avec Force Cache Write Through -> ESX -> Guest OS
BANC3:  NetApp -> ESX -> Guest OS

Le BANC1 sera l’utilisation nominale de la plateforme. Le BANC2 devra montrer le prix à payer pour être 100% WAL-compliant. Dans la dernière configuration, on souhaite mesurer ce qu’on perd potentiellement si on retire Datacore  de l’équation.

Préparation des scripts:

Il a fallu se constituer un petit package de recueil  et d’agrégation d’informations pour le bench. On a choisi de le préparer en fonction des IOs types envoyées par SQL Server:

• Lectures séquentielles de 8,32,64,128 et 256 K (read-ahead, ramp up prefetch, DBCC CHECKDB…)
• Écritures séquentielles de 8,32,64,128 et 256 K (Backup / restore, Alter index Rebuild, Bulk insert…)
• Lectures aléatoires de 8K: lectures types OLTP.
• Écritures aléatoires de 8K: écritures types OLTP.

Voici le contenu du fichier .bat utilisé:

sqlio -kR -s120 -o64 -fsequential -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o64 -fsequential -b32 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o64 -fsequential -b64 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o64 -fsequential -b128 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o64 -fsequential -b256 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o64 -frandom -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o64 -fsequential -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o64 -fsequential -b32 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o64 -fsequential -b64 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o64 -fsequential -b128 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o64 -fsequential -b256 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o64 -frandom -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o128 -fsequential -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o128 -fsequential -b32 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o128 -fsequential -b64 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o128 -fsequential -b128 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o128 -fsequential -b256 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o128 -frandom -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o128 -fsequential -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o128 -fsequential -b32 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o128 -fsequential -b64 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o128 -fsequential -b128 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o128 -fsequential -b256 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o128 -frandom -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o256 -fsequential -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o256 -fsequential -b32 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o256 -fsequential -b64 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o256 -fsequential -b128 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o256 -fsequential -b256 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kR -s120 -o256 -frandom -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o256 -fsequential -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o256 -fsequential -b32 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o256 -fsequential -b64 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o256 -fsequential -b128 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o256 -fsequential -b256 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"
sqlio -kW -s120 -o256 -frandom -b8 -BH -LS -F"C:\Program Files\SQLIO\my_param_file.txt"

 

En tout 72 minutes de bench, trois pavés avec 64, 128 et 256 outstanding IOs par thread. Le contenu du fichier de configuration my_param_file.txt :

e:\testfile.dat 4 0x0 51200

On utilisera donc 4 threads (1 par vCPU) sur un fichier de 50Gb. Le choix dans la taille du fichier de test est important car on souhaite tester le sous-système disque et principalement le back-end de la baie. Il faut donc créer un fichier qui ne tienne ni dans le cache du DATACORE ni dans le cache du contrôleur I/O de la baie, pour obliger celle-ci à déborder sur les disques. Le plus gros datamart de l’application faisant 50Gb, on n’a donc pas choisi cette taille par hasard. On lance donc le script et on s’en va boire un café…

C:\Program Files\SQLIO>benchSQL.bat > results.txt

Intégration des résultats en base:

Une fois le test terminé, il va falloir intégrer les résultats en base. Le script ci-dessous doit nous permettre de stocker le contenu du fichier results.txt dans une table et de l’afficher de manière simple et conviviale. Ce script est un dérivé de celui que propose Brent Ozar (blog|twitter) sur SQLServerPedia et utilise une vue sur le fichier resultat brut plutôt qu’une table intermédiaire.

create database SQLIO
GO
use SQLIO
GO

CREATE TABLE [dbo].[SQLIO_Import](
 [RowID] [int] IDENTITY(1,1) NOT NULL,
 [ParameterRowID] [int] NULL,
 [ResultText] [varchar](max) NULL,
CONSTRAINT [PK_SQLIO_Import] PRIMARY KEY CLUSTERED
(
 [RowID] ASC
))
GO

create view v_sqlimport
as
select
-- Test set #
row_number() over (order by ParameterRowID) 'Test set #',
-- SQLIO Version
(select substring(ResultText, 7, len(ResultText))
 from sqlio_import inner0 where ResultText like 'sqlio v%'
 and inner0.ParameterRowID = imp.ParameterRowID) 'SQLIO Version'
-- # of threads
,(select substring(ResultText, charindex('with',ResultText) + 5,
 (charindex('threads',ResultText)-(charindex('with',ResultText)+5)))
 from sqlio_import inner1 where ResultText like '%using mask%'
 and inner1.ParameterRowID = imp.ParameterRowID) '# of worker threads'
-- Read or Write
,(select substring(ResultText, charindex('-k',ResultText) + 2, 1)
 from sqlio_import inner2 where ResultText like '%>sqlio%'
 and inner2.ParameterRowID = imp.ParameterRowID) 'Reads (R) | Writes (W)'
-- Duration (secs)
,(select substring(ResultText, charindex('-s',ResultText) + 2,
 ((charindex('-',ResultText,charindex('-s',ResultText)+2))-(charindex('-s',ResultText) + 2)))
 from sqlio_import inner3 where ResultText like '%>sqlio%'
 and inner3.ParameterRowID = imp.ParameterRowID) 'Duration (sec)'
-- I/O Size (Kb)
,(select substring(ResultText, charindex('-b',ResultText) + 2,
 ((charindex('-',ResultText,charindex('-b',ResultText)+2))-(charindex('-b',ResultText) + 2)))
 from sqlio_import inner4 where ResultText like '%>sqlio%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'I/O Size (Kb)'
-- I/O Patterns
,(select substring(ResultText, charindex('-f',ResultText) + 2,
 ((charindex('-',ResultText,charindex('-f',ResultText)+2))-(charindex('-f',ResultText) + 2)))
 from sqlio_import inner4 where ResultText like '%>sqlio%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'I/O Pattern (Random | sequential)'
-- # outstanding I/Os
,(select substring(ResultText, charindex('-o',ResultText) + 2,
 ((charindex('-',ResultText,charindex('-o',ResultText)+2))-(charindex('-o',ResultText) + 2)))
 from sqlio_import inner4 where ResultText like '%>sqlio%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'Outstanding I/Os per thread'
-- File Size (Mb)
,(select substring(ResultText, charindex('size:',ResultText) + 6,
 ((charindex('MB',ResultText,charindex('size:',ResultText)+6))-(charindex('size:',ResultText) + 6)))
 from sqlio_import inner4 where ResultText like 'using specified size:%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'Target File Size (Mb)'
-- IOPS
,(select substring(ResultText, charindex('IOs/sec:',ResultText) + 8,
 ((len(ResultText)-(charindex('IOs/sec:',ResultText) + 7))))
 from sqlio_import inner4 where ResultText like 'IOs/sec:%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'IOPS'
-- MBPS
,(select substring(ResultText, charindex('MBs/sec:',ResultText) + 8,
 ((len(ResultText)-(charindex('MBs/sec:',ResultText) + 7))))
 from sqlio_import inner4 where ResultText like 'MBs/sec:%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'MBPS'
-- Min Latency
,(select substring(ResultText, charindex('Min_Latency(ms):',ResultText) + 17,
 ((len(ResultText)-(charindex('Min_Latency(ms):',ResultText) + 16))))
 from sqlio_import inner4 where ResultText like 'Min_Latency(ms):%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'Min Latency (ms)'
-- Avg Latency
,(select substring(ResultText, charindex('Avg_Latency(ms):',ResultText) + 17,
 ((len(ResultText)-(charindex('Avg_Latency(ms):',ResultText) + 16))))
 from sqlio_import inner4 where ResultText like 'Avg_Latency(ms):%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'Avg Latency (ms)'
-- Max Latency
,(select substring(ResultText, charindex('Max_Latency(ms):',ResultText) + 17,
 ((len(ResultText)-(charindex('Max_Latency(ms):',ResultText) + 16))))
 from sqlio_import inner4 where ResultText like 'Max_Latency(ms):%'
 and inner4.ParameterRowID = imp.ParameterRowID) 'Max Latency (ms)'
FROM     dbo.sqlio_import imp
where ParameterRowID is not null
GROUP BY ParameterRowID
GO

print 'Please import data now and then run:
-- 1)
UPDATE dbo.sqlio_import
SET    parameterrowid = (SELECT   TOP 1 rowid
 FROM     dbo.sqlio_import parm
 WHERE    parm.resulttext LIKE ''%>sqlio %''
 AND parm.rowid <= upd.rowid
 ORDER BY rowid DESC)
FROM   dbo.sqlio_import upd
GO'
print '
--2)
select * from v_sqlimport order by MBPS desc, IOPS desc
GO'

A cette étape, il ne reste plus qu’à importer le fichier results.txt avec SSIS (Database -> Tasks -> Import Data…).  Il faut penser notamment à indiquer que le type de données en entrée est du DT_TEXT:

Puis à sélectionner la table SQLIO_Import et colonne ResultText comme réceptacles du fichier results.txt:

Une fois l’import du fichier terminé, il ne reste plus qu’à exécuter les tâches de post-import:

UPDATE dbo.sqlio_import
SET    parameterrowid = (SELECT   TOP 1 rowid
 FROM     dbo.sqlio_import parm
 WHERE    parm.resulttext LIKE '%>sqlio %'
 AND parm.rowid <= upd.rowid
 ORDER BY rowid DESC)
FROM   dbo.sqlio_import upd
GO
(834 ligne(s) affectée(s))

Puis appeler la vue:

select * from v_sqlimport order by MBPS desc, IOPS desc
GO

Résultats

Légende:

- R8random128: reads 8K random 128 outstanding IOs
- R8sequential128: reads 8K sequential 128 outstanding IOs
- W8random128: writes 8K random 128 outstanding IOs
- etc…

• BANC1 vs BANC2: pas besoin de photo finish pour les départager:

680Mb/s sur du read-ahead, on peut difficilement battre un tel résultat à part peut être avec des SSD, qui eux offrent en plus un stockage résilient.

• BANC1 vs BANC3: avec ou sans Datacore ? c’est le même constat.

Je dois avouer que j’ai été très surpris des performances offertes par la solution de Datacore. Ca peut être une arme terrible pour écraser tous les problèmes de latence IO dans des environnements virtualisés… En attendant la globalisation des SSD, et avec sa solution de réplication de blocs, Datacore a encore de beaux jours devant lui.

A+. David B.

Références:

[1]: Virtual Machines Execution Modes in VSphere 4.0, Nikhil Bhatia, VMWare Corp
[2]: Storage Block Alignment with VMWare Virtual Infrastructure, Tim Coste, juillet 2007, TR-3593Continuez votre lecture sur le blog :

• Consistence des écritures avec SATA (David BAFFALEUF) [Operating SystemSQL Server]
• How-To : réduire l’enveloppe de tempdb (David BAFFALEUF) [SQL Server]
• Msg 2508, Level 16, State 1: the In-Row data %% for object %% is incorrect (David BAFFALEUF) [SQL Server]
• I/O asynchrones (épisode 1) (David BAFFALEUF) [Operating SystemSQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]

C’est quoi FUA ?

FUA = Force Unit Access. Il s’agit d’un bit au sein d’un Command Disk Block Read ou Write SCSI qui permet d’indiquer au driver de ne pas lire ou écrire depuis ou à partir d’un cache mais bien depuis ou à partir du média physique, c’est à dire du disque magnétique. Par exemple un CDB de Write(10) (source wikipedia):

C’est important d’avoir cette garantie pour les moteurs de bases de données car elle leur permet de supporter ce qu’on appelle le WAL protocol , le pilier qui soutient  la durabilité des transactions dans un SGBD. Lorsqu’une transaction est validée, quoi qu’il advienne ensuite cette information doit être physiquement inscrite quelque part sur un média persistant. Même si on perd un disque, l’alimentation de la machine ou toute la salle d’un seul coup, tout ce qui a été modifié avant la validation de cette transaction doit se retrouver sur disque avant fin du COMMIT, d’où le nom (WAL = Write Ahead Logging).

SQL Server utilise deux commutateurs lors de l’ouverture des fichiers de données et des journaux de transactions au démarrage de l’instance pour valider ce comportement (FILE_FLAG_WRITE_THROUGH  |  FILE_FLAG_NO_BUFFERING). Le premier indique que l’OS a le droit de bufferiser une écriture mais qu’il ne doit pas renvoyer d’acquittement avant que cette écriture n’ait touché le support physique (l’équivalent de O_DSYNC sur Linux, cf ce post). La seconde indique que l’Os n’a pas le droit de lire une donnée depuis le cache, mais de forcer la lecture à partir du disque. Donc vous l’aurez compris, l’association des deux permet de bypasser complètement le cache.

FUA et SATA:

Ce bit FUA fait partie intégrante du protocole SCSI mais reste ignoré par ATA et SATA. Lorsque l’information arrive au driver atapi.sys, elle est tout simplement non interprétée, les écritures vont dans le cache et l’acquittement OK revient au moteur. Pas terrible pour la durabilité des transactions. La seule arme face au problème reste de désactiver le cache en écriture au niveau du disque (sous windows une petite case à décocher dans les propriétés du disque, voir au bas de cet article), mais le problème, c’est qu’il n’y a encore aujourd’hui aucun moyen de savoir réellement si le driver a bien pris en compte cette modification ou non.

Depuis, SATA II a annoncé le support de FUA, mais dans la pratique je vois encore beaucoup de :

sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

sur les forums linux, même avec des contrôleurs SATA II. Après une petite discussion avec Bob Dorr du support MS, je suis parti à la recherche de preuves. J’ai un laptop avec un disque SATA, un SQL Server 2005 SP3, je voudrais savoir si les écritures envoyées vers le disque seront écrites dans le cache ou réellement sur le disque. Capture du matériel pour mémo:

La Descente vers le disque:

Avant d’aller plus loin, il faut rappeler un peu la théorie des IOs sous Windows, et la relation avec SQL Server.

Lorsque SQL Server démarre, il ouvre les fichiers de données et les journaux de transactions des bases qu’il monte en ligne avec CreateFile. Il récupère un type HANDLE qui sera utilisé ensuite pour toutes les opérations sur le fichier (lectures / écritures). Lorsqu’un processus demande l’ouverture ou la création d’un fichier, le noyau transfère le contrôle à l’Object Manager. Celui-ci créé un objet de type FILE_OBJECT pour décrire le fichier, ses attributs, ses modes d’accès, la liste des IOs en cours, etc.. Lorsque notre CreateFile ouvre un fichier en FILE_FLAG_WRITE_THROUGH, le bit FO_WRITE_THROUGH (0×00000010 *) va être ajouté au membre .Flags du FILE_OBJECT.

Ensuite, lorsque le programme doit  écrire dans le fichier, il utilisera une des primitives WriteFile() / WriteFileEx() / WriteFileGather().  Lors de l’écriture, le noyau transfère le contrôle à l’IO Manager pour l’initialisation de l’IO. Celui-ci va créer un IRP (IO Request Packet) pour décrire l’opération.  Chaque IRP a une structure en ascenceur. Elle contient un entête et plusieurs piles (une par driver dans la pile de drivers jusqu’au disque) qu’on appelle des IO_STACK_LOCATIONs. L’entête sert à pointer vers l’IO_STACK_LOCATION correspondant au driver en cours dans la pile. Lorsque le driver courant a terminé son opération, il passe l’IRP au driver suivant dans la stack et fait pointer l’entête de l’IRP vers l’IO_STACK_LOCATION suivante, etc…(cf Handling IRPS : what every driver writer needs to know).

Chaque IRP renseigne un bitmask (.Flags) pour indiquer quels sont les commutateurs actifs. Parmi ceux-ci, SL_WRITE_THROUGH (0×04 *) propage notre contrainte d’écriture sur le média au driver, et c’est là que les choses se gâtent.

L’idée est donc de contrôler la propagation du writethrough à travers les différentes IO_STACK_LOCATIONS et voir quel driver réinitialise le bit.

J’ai tenté pendant trois ou quatre jours de traquer la bête avec livekd, mais c’est assez difficile de prendre SQL Server la main dans le sac. Les IOs sont assez rapides et les IRP vers les disques sont supprimées par l’IO Manager avant que je n’aie le temps de les inspecter. J’ai donc décidé (pas borné du tout le garçon ) d’écrire un petit programme très simple qui me ferait en boucle des écritures alignées sur les secteurs disque en write-through exactement comme SQL Server, avec le côté asynchrone en moins (pas important pour ce que l’on cherche, et en plus pas très simple à gérer, mais promis ce sera l’objet d’un prochain post).

Le source:

// ------------------------------------------------------------------------------------------------------------
// writeThrough.cpp : Ecrit en boucle des caractères dans un fichier en mode Writethrough / No Buffering
// Utilisé avec livekd, permet de scruter le contenu des IO_STACK_LOCATION dans l'IRP correspondante
// pour contrôler si le bit SL_WRITE_THROUGH est bien propagé jusqu'au driver (pb ATA / IDE /S-ATA).
//
// On utilisera un IOCTL (IOCTL_DISK_GET_DRIVE_GEOMETRY) pour récupérer la taille du secteur
//
// dbaffaleuf@capdata.fr (c) CapData Consulting 2011
//
// ------------------------------------------------------------------------------------------------------------

#include <stdafx.h>
#include <windows.h>
#include <stdlib.h>
#include <winioctl.h>
#include <direct.h>

int _tmain(int argc, _TCHAR* argv[])
{
     if (argc!=2)
    {
        printf("Usage is:  writeThrough outputfilename\n");
        return 1;
    }

 // Récupération de la taille du secteur disque avec un IOCTL ---------------------------------------------------
 DISK_GEOMETRY dg;
 HANDLE hDrive;
 DWORD ioctlJnk; 

 hDrive=CreateFile(TEXT("\\\\.\\PhysicalDrive0")
                          ,0
                          ,FILE_SHARE_READ
                          | FILE_SHARE_WRITE
                          ,NULL
                          ,OPEN_EXISTING
                          ,0
                          ,NULL);

 if (INVALID_HANDLE_VALUE==hDrive)
 {
     printf("Unable to open drive PhysicalDrive0. Last error=%d\n",GetLastError());
     return 1;
 }

 if (! DeviceIoControl(hDrive
                          ,IOCTL_DISK_GET_DRIVE_GEOMETRY
                          ,NULL
                          ,0
                          ,&dg
                          ,sizeof(dg)
                          ,&ioctlJnk
                          ,NULL) )
 {
     printf("Error on IOCTL (IOCTL_DISK_GET_DRIVE_GEOMETRY) to %s.  Last error=%d\n",argv[1],GetLastError());
     return 1;
 }

 CloseHandle(hDrive);

 // Ouverture du fichier Writethrough + No Buffering ---------------------------------------------------------
 HANDLE hOutputFile=CreateFile(argv[1]
                      ,GENERIC_READ
                      | GENERIC_WRITE
                      ,0
                      ,NULL
                      ,CREATE_ALWAYS
                      ,FILE_ATTRIBUTE_NORMAL
                      | FILE_FLAG_WRITE_THROUGH
                      | FILE_FLAG_NO_BUFFERING
                      ,NULL);

 if (INVALID_HANDLE_VALUE==hOutputFile)
 {
     printf("Unable to open file %s.  Last error=%d\n",argv[1],GetLastError());
     return 1;
 }

 // Initialisation du tampon et écriture --------------------------------------------------------------------
 wchar_t *csBuffer = (wchar_t *)HeapAlloc(GetProcessHeap(),HEAP_ZERO_MEMORY,dg.BytesPerSector * sizeof(wchar_t));
 int len = swprintf_s(csBuffer,dg.BytesPerSector,L"abcdefghijklmnopqrstuvwxyz");    
 DWORD dwBytesWritten;
 DWORD dwTotalBytesWritten=0;

 do
 {
     if (! WriteFile(hOutputFile
                       ,csBuffer
                       ,dg.BytesPerSector
                       ,&dwBytesWritten
                       ,NULL))
     {
         printf ("WriteFile failed with error %d.\n", GetLastError());
         return 1;
     }

    dwTotalBytesWritten+=dwBytesWritten;
    printf("Operation terminée, %d octets écrits\n", dwTotalBytesWritten);
    Sleep (1);

 } while (TRUE);

 HeapFree(GetProcessHeap(),0,csBuffer);
 CloseHandle(hOutputFile);

 return 0;
}

La seule contrainte d’utilisation de (FILE_FLAG_NO_BUFFERING | FILE_FLAG_WRITE_THROUGH) est d’écrire en s’alignant sur les secteurs du disque, il nous faut donc récupérer la taille du secteur avec un IOCTL (en l’occurence IOCTL_DISK_GET_DRIVE_GEOMETRY). Dans la plupart des cas ce sera 512 octets, mais des tailles de 4K vont commencer à arriver sur le marché, donc il ne faut pas présumer et bien calculer tout ça proprement. Dans la seconde partie, on initialise un buffer sur une taille multiple de la taille du secteur et on écrit dans notre fichier hOutputFile en boucle continue, avec une pause de 1 ms entre chaque écriture.

On lance le programme en boucle et on va passer à la partie livekd:

C:\DBA\DEV\CPP\writeThrough\Debug>writeThrough.exe test.txt
Operation terminée, 512 octets écrits
Operation terminée, 1024 octets écrits
Operation terminée, 1536 octets écrits
Operation terminée, 2048 octets écrits
Operation terminée, 2560 octets écrits
Operation terminée, 3072 octets écrits
...

Observation des IRPs:

Première chose à faire si vous souhaitez reproduire ce POC, il vous faudra récupérer les outils de debug de Windows et les symboles pour votre plateforme. Il vous faudra aussi récupérer LiveKD.

Ensuite pointer vers le serveur de symboles MS:

set _NT_SYMBOL_PATH=srv*c:\temp\symbols*http://msdl.microsoft.com/download/symbols   

Et lancer livekd. Pour assurer un peu plus la cohérence des résultats, il peut être nécessaire de passer par un bcdedit /debug on + reboot pour activer le débogage du noyau. La stratégie est de retrouver les IRPs actives associées au fichier dans lequel on écrit par le biais d’un !irpfind en lui passant l’adresse du DEVICE_OBJECT associé au disque. Dans un foreach, ensuite on affiche le contenu détaillé de toutes les irps que l’on retrouve. Attention, vous devrez sans doute le faire un certain nombre de fois pour pouvoir observer un IRP décrivant une écriture (MAJOR= 4 => IRP_MJ_WRITE).

Première chose, on va récupérer l’adresse de notre processus writeThrough.exe, et le passer en process par défaut sous livekd:

lkd> !sym quiet
quiet mode - symbol prompts on

lkd> !process 0 0 writeThrough.exe
PROCESS 881b39d0  SessionId: 0  Cid: 0c08    Peb: 7ffde000  ParentCid: 0960
 DirBase: 0aa80740  ObjectTable: e4168638  HandleCount:   9.
 Image: writeThrough.exe

lkd> .process 881b39d0  
Implicit process is now 881b39d0

Ensuite, nous allons nous intéresser au fichier test.txt. Il nous faut récupérer le FILE_OBJECT créé par l’Object Manager lors du CreateFile():

0: kd> !handle 0 3
(...)
07dc: Object: 8701f1b0  GrantedAccess: 0012019f Entry: e3baefb8
Object: 8701f1b0  Type: (8a57a900) File
 ObjectHeader: 8701f198 (old version)
 HandleCount: 1  PointerCount: 1
 Directory Object: 00000000  Name: \CAPDATA\DEV\DEV++\writeThrough\Debug\test.txt {HarddiskVolume3}
(...)

0: kd> dt nt!_FILE_OBJECT 8701f1b0
 +0x000 Type             : 0n5
 +0x002 Size             : 0n112
 +0x004 DeviceObject     : 0x8a4a5a30_DEVICE_OBJECT
 +0x008 Vpb              : 0x8a4a71e8 _VPB
 +0x00c FsContext        : 0xe6be4928 Void
 +0x010 FsContext2       : 0xe6be4a80 Void
 +0x014 SectionObjectPointer : 0x8839f5cc _SECTION_OBJECT_POINTERS
 +0x018 PrivateCacheMap  : (null)
 +0x01c FinalStatus      : 0n0
 +0x020 RelatedFileObject : 0x88752ec0 _FILE_OBJECT
 +0x024 LockOperation    : 0 ''
 +0x025 DeletePending    : 0 ''
 +0x026 ReadAccess       : 0x1 ''
 +0x027 WriteAccess      : 0x1 ''
 +0x028 DeleteAccess     : 0 ''
 +0x029 SharedRead       : 0 ''
 +0x02a SharedWrite      : 0 ''
 +0x02b SharedDelete     : 0 ''
 +0x02c Flags            : 0x4101a
 +0x030 FileName         : _UNICODE_STRING "\CAPDATA\DEV\DEV++\writeThrough\Debug\test.txt"
 +0x038 CurrentByteOffset : _LARGE_INTEGER 0x7c00
 +0x040 Waiters          : 0
 +0x044 Busy             : 0
 +0x048 LastLock         : (null)
 +0x04c Lock             : _KEVENT
 +0x05c Event            : _KEVENT
 +0x06c CompletionContext : (null)

Par la même occasion, on va vérifier si notre CreateFile() a bien propagé FO_WRITE_THROUGH au FILE_OBJECT:

0: kd> ? (0x4101a & 0x00000010)
Evaluate expression: 16 = 00000010

OK. On peut donc poursuivre en gardant sous le coude l’adresse du DEVICE OBJECT renvoyé par le dt nt!_FILE_OBJECT… :

(...)
+0x004 DeviceObject     : 0x8a4a5a30_DEVICE_OBJECT
(...)

Courage !

Et c’est là que la partie de pêche commence vraiment. Je vous laisse le soin de regarder comment les instructions sous un déboggeur fonctionnent mais l’idée est de récupérer l’adresse de chaque IRP associée au DEVICE OBJECT de notre disque et d’afficher son contenu, en vérifiant qu’il provient bien de notre petit programme. Il faut être patient. Au bout d’un certain nombre de tentatives, on arrive à en attraper une :

lkd> .foreach /pS 1 /ps 3 (irpaddr {.foreach /pS 21 /ps 9 (irpaddressblk {!irpfind 0 0 device 0x8a4a5a30}) { .echo ${irpaddressblk} } }) { !irp ${irpaddr} 1 }
Irp is active with 10 stacks 6 is current (= 0x882a312c)
 Mdl=88195a60: No System Buffer: Thread 881059e8:  Irp stack trace.  
Flags = 00000043
ThreadListEntry.Flink = 882a3018
ThreadListEntry.Blink = 882a3018
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = a0e60878
UserEvent = a0e60820
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000   
UserBuffer = 88083000
&Tail.Overlay.DeviceQueueEntry = 882a3048
Tail.Overlay.Thread = 881059e8
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = 882a312c
Tail.Overlay.OriginalFileObject = 899ef028
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
 cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

 Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

 Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

 Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

 Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

 Args: 00000000 00000000 00000000 00000000
>[  4, 0]   0  0 8a483770 00000000 f77077ca-8a483548    
 \Driver\Disk    
 Args: 00000000 00000000 00000000 00000000
 [  4, 0]   0  0 8a483548 00000000 f7238962-8a4a5ae8    
 \Driver\PartMgr    
 Args: 00000000 00000000 00000000 00000000
 [  4, 0]   0  0 8a4a5a30 00000000 f74a7680-8a48a7b8    
 \Driver\Ftdisk    
 Args: 00000000 00000000 00000000 00000000
 [  4, 0]   0  0 8a48a700 00000000 f7063e3f-a0e6045c    
 \Driver\VolSnap    
 Args: 00000000 00000000 00000000 00000000
 [  4, 0]   0  0 8979c020 00000000 00000000-00000000    
 \FileSystem\Ntfs
 Args: 00000000 00000000 00000000 00000000

J’ai volontairement colorié le membre .Flags et l’IO_STACK_LOCATION courante. On voit bien ici l’empilement des drivers: Ntfs -> VolSnap -> Ftdisk -> PartMgr -> Disk. Entre crochets, notre couple [MAJOR,Minor] qui indique le type d’opération en cours (pour plus d’infos cf l’aide de la commande !irp dans le DDK). [4,0] indique que la commande en cours est un IRP_MJ_WRITE, donc une écriture, et la petite indirection à l’extrême gauche montre que la besogne est entre les mains du driver le plus bas dans la stack (c:\Windows\system32\Disk.sys). Quant à la valeur de .Flags:

lkd> ? (0x00000043 & 0x4)
Evaluate expression: 0 = 00000000

Bingo. Pas de SL_WRITE_THROUGH. J’ai pû faire le test avec et sans cache activé au niveau du disque, et le résultat est le même:

Donc potentiellement si je débranche ma batterie et que je coupe mon alimentation au moment d’une grosse écriture il y a un risque de perdre une transaction validée. Je vous avoue que je ne l’ai testé qu’une seule fois (je tiens aussi un peu à mon matériel), mais la coupure est intervenue quelques millisecondes avant le commit, et SQL Server a rollbacké tout ça proprement. Il faudrait faire une batterie de tests mais je n’ai pas les moyens de cramer du disque comme ça. Après, celà jette tout de même de lourds soupçons sur la capacité de SATA à répondre aux besoins des SGBD.

Ce n’est plus qu’une question de coût ou de performance que de comparer SCSI à SATA. Celà devient une question d’intégrité des données, et donc un problème fondamental. Affaire à suivre…

A+. David B.

* Sources: winddk.h

Références:
http://support.microsoft.com/kb/234656
http://support.microsoft.com/kb/46091
http://support.microsoft.com/kb/86903Continuez votre lecture sur le blog :

• I/O asynchrones (épisode 1) (David BAFFALEUF) [Operating SystemSQL Server]
• Bench avec NetApp / Datacore / ESX (David BAFFALEUF) [SQL Server]
• Point-in-time recovery et fn_dump_dblog() (David BAFFALEUF) [SQL Server]
• Installation ASM sur SUSE 10 en 64 Bits avec multipathing (EMC Powerpath) (Thierry GASCARD) [Oracle]
• Fragmentation sur des tables stockées en S-GAM (David BAFFALEUF) [SQL Server]

• Plus de question à se poser sur le choix des colonnes pour reconstruire la table
• Elle est simple à utiliser : Alter table TABLE1 rebuild
• Elle permet de diminuer le nombre de « forwarding record » dans les pages de données.
• Lorsque l’on met à jour les données d’une ligne et qu’il ne reste pas suffisamment d’espace libre dans la page, SQL Server enregistre une information « forwarding record » qui contient un pointeur vers l’adresse de la page qui contient la suite de la ligne. Ce phénomène est pénalisant pour les performances, car il impose des déplacements coûteux entre les pages lors des lectures de lignes.
• Elle permet de réduire le nombre de pages utilisées par une table après une réduction importante des données des lignes.
• Les indexes non cluster sont reconstruits en même temps que la table
• Si on est en version Enterprise, il est possible de reconstruire la table ONLINE , c’est à dire en optimisant le verrouillage de la table pour pénaliser le moins possible les accès à celle_ci lors de la reconstruction.

Voici 2 exemples d’utilisation

– #######################################################################
– # Demo1 : Reconstruire un HEAP pour réduire les « forwarding record » –
– #######################################################################

-- creation base de tests
drop database B1
Create database B1
alter database B1 set recovery simple
use B1
go

-- creation table HEAP exemple
create table TABLE1(a numeric identity, b varchar(4000), c varchar(4000))
go

-- ajoute 1000 lignes dans la table
insert into TABLE1 values ('b','c')
go 1000

-- Inspection de son plan d'allocation
dbcc traceon (3604)dbcc ind('B1', 'TABLE1',-1)
PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber PartitionID        
------- ----------- ------ ----------- ----------- ----------- --------------- --------------------
1       77          NULL   NULL        2105058535  0           1               72057594038779904  
1       55          1      77          2105058535  0           1               72057594038779904  
1       78          1      77          2105058535  0           1               72057594038779904  
1       79          1      77          2105058535  0           1               72057594038779904  
1       80          1      77          2105058535  0           1               72057594038779904   ...
(5 row(s) affected)
=> 5 pages (1 IAM et 4 Data)

-- Mise à jour de la table pour provoquer des débordements de lignes :
update TABLE1 set b=(replicate('b',1000)), c=(replicate('c',1000))

-- Nouveau plan d'allocation
dbcc ind('B1', 'TABLE1',-1)

PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber PartitionID        
------- ----------- ------ ----------- ----------- ----------- --------------- -------------------
1       77          NULL   NULL        2105058535  0           1               72057594038779904  
1       55          1      77          2105058535  0           1               72057594038779904  
1       78          1      77          2105058535  0           1               72057594038779904  
1       79          1      77          2105058535  0           1               72057594038779904  
1       80          1      77          2105058535  0           1               72057594038779904  
1       89          1      77          2105058535  0           1               72057594038779904  
1       90          1      77          2105058535  0           1               72057594038779904  
1       93          1      77          2105058535  0           1               72057594038779904  
1       94          1      77          2105058535  0           1               72057594038779904  
1       176         1      77          2105058535  0           1               72057594038779904  
1       177         1      77          2105058535  0           1               72057594038779904  
1       178         1      77          2105058535  0           1               72057594038779904  ...
...
--(336 row(s) affected)
--=> 336 pages (1 page IAM + 335 pages de donnees)

-- Affiche fragmentation
select object_name(F.object_id) Object, index_type_desc, page_count, record_count, forwarded_record_count, avg_fragmentation_in_percent from sys.indexes I
cross apply sys.dm_db_index_physical_stats(db_id(),object_id('TABLE1'), -1,NULL,'DETAILED') F where I.object_id = object_id('TABLE1')

Object                         index_type_desc                page_count           record_count         forwarded_record_count avg_fragmentation_in_percent
------------------------------ ------------------------------ -------------------- -------------------- ---------------------- ----------------------------
TABLE1                         HEAP                           335                  1993                 993                    4,44444444444444
=> 335 pages
=> 1993 records pour 1000 lignes
=> 993 forwarded_record_count - 993 lignes sur 1000 contiennent un pointeur vers une autre page qui contient la suite de la page, c'est pas terrible
=> fragmentation : 4.4 %

-- Affiche le contenu de la page 78
dbcc page('B1', 1, 78, 3)
Slot 0 Offset 0x258 Length 9
Record Type = FORWARDING_STUB        Record Attributes =                  Record Size = 9
Memory Dump @0x46E6C258
00000000:   040d0100 00010001 00†††††††††††††††††.........
Forwarding to  =  file 1 page 269 slot 1
Slot 1 Offset 0x261 Length 9
=> informations pour le row forwarding

-- reconstruit la table TABLE1
alter table TABLE1 rebuild

-- Nouveau plan d'allocation
dbcc ind('B1', 'TABLE1',-1)
PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber PartitionID          iam_chain_type      
------- ----------- ------ ----------- ----------- ----------- --------------- -------------------- --------------------
1       110         NULL   NULL        2105058535  0           1               72057594038845440    In-row data          
1       109         1      110         2105058535  0           1               72057594038845440    In-row data          
1       504         1      110         2105058535  0           1               72057594038845440    In-row data          
1       505         1      110         2105058535  0           1               72057594038845440    In-row data          
...
(252 row(s) affected)
=> la table a été reconstruite a un nouvel emplacement, elle utilise 252 pages au lieu de 335

-- Affiche fragmentation
select object_name(F.object_id) Object, index_type_desc, page_count, record_count, forwarded_record_count, avg_fragmentation_in_percent from sys.indexes I
cross apply sys.dm_db_index_physical_stats(db_id(),object_id('TABLE1'), -1,NULL,'DETAILED') F where I.object_id = object_id('TABLE1')

Object                         index_type_desc                page_count           record_count         forwarded_record_count avg_fragmentation_in_percent
------------------------------ ------------------------------ -------------------- -------------------- ---------------------- ----------------------------
TABLE1                         HEAP                           251                  1000                 0                      3,03030303030303
=> 3 lignes par page, le niveau de fragmentation a légèrement baissé
=> et surtout il n'y a plus de forwarded record

#########################################
-- Demo2 : On continue l'exemple précédent, on va Reconstruire la table pour optimiser le nombre de pages après une Réduction des données dans les lignes:
#########################################

-- reduction des donnees dans les lignes
update TABLE1 set b='b', c='c'
(1000 row(s) affected)

-- Affiche fragmentation
select object_name(F.object_id) Object, avg_page_space_used_in_percent, index_type_desc, page_count, record_count, forwarded_record_count, avg_fragmentation_in_percent from sys.indexes I
cross apply sys.dm_db_index_physical_stats(db_id(),object_id('TABLE1'), -1,NULL,'DETAILED') F where I.object_id = object_id('TABLE1')

Object                         avg_page_space_used_in_percent index_type_desc                page_count           record_count         forwarded_record_count avg_fragmentation_in_percent
------------------------------ ------------------------------ ------------------------------ -------------------- -------------------- ---------------------- ----------------------------
TABLE1                         1,25517667407957               HEAP                           251                  1000                 0                      3,03030303030303
=> avg_page_space_used_in_percent : 1,25% d'espace utilise par page c'est faible !
-- reconstruction de la table
alter table TABLE1 rebuild

-- plan d'allocation
dbcc ind('B1', 'TABLE1',-1)
PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber PartitionID          iam_chain_type      
------- ----------- ------ ----------- ----------- ----------- --------------- -------------------- --------------------
1       121         NULL   NULL        2105058535  0           1               72057594038976512    In-row data          
1       120         1      121         2105058535  0           1               72057594038976512    In-row data          
1       400         1      121         2105058535  0           1               72057594038976512    In-row data          
1       401         1      121         2105058535  0           1               72057594038976512    In-row data          
1       402         1      121         2105058535  0           1               72057594038976512    In-row data          
1       403         1      121         2105058535  0           1               72057594038976512    In-row data          
(6 row(s) affected)
=> A nouveau 6 pages

Object                         avg_page_space_used_in_percent index_type_desc                page_count           record_count         forwarded_record_count avg_fragmentation_in_percent
------------------------------ ------------------------------ ------------------------------ -------------------- -------------------- ---------------------- ----------------------------
TABLE1                         64,225352112676                HEAP                           5                    1000                 0                      50
=> avg_page_space_used_in_percent : 64,22 % c'est mieux !
fragmentation 50% : pas genant pour une table de cette taille (- de 8 pages)

Continuez votre lecture sur le blog :

• 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]
• Msg 2508, Level 16, State 1: the In-Row data %% for object %% is incorrect (David BAFFALEUF) [SQL Server]
• Fragmentation sur des tables stockées en S-GAM (David BAFFALEUF) [SQL Server]
• Regénérer le DDL des indexes FULL TEXT (David BAFFALEUF) [SQL Server]

Si vous êtes intéressés par une formation orientée opérationnelle associée à une reconnaissance de vos compétences sur SQL Server , n’hésitez pas à contacter notre service commercial au 0820 620 400 (0.12€/min) ou par mail à formation@capdata.fr.

En espérant vous voir bientôt dans nos salles de formation !

A+. David B.Continuez votre lecture sur le blog :

• Formation Optimisation de requêtes (David BAFFALEUF) [SQL Server]
• Abonnez-vous au blog de la CapData team ! (Cédric PEINTRE) [GénéralMySQLOracleSQL ServerSybase]
• Intérêt de créer des indexes cluster uniques (David BAFFALEUF) [SQL Server]
• Scruter les journaux d’évènements Windows avec LogParser (David BAFFALEUF) [SQL Server]
• Cours MCM en ligne (David BAFFALEUF) [SQL Server]

Encore une mine d’or à ciel ouvert, merci SQLSkills !

A+. David B.Continuez votre lecture sur le blog :

• Intérêt de créer des indexes cluster uniques (David BAFFALEUF) [SQL Server]
• Voucher certification SQL Server 70-432 offert ! (David BAFFALEUF) [SQL Server]
• Réunion GUSS le 1er juillet ! (David BAFFALEUF) [SQL Server]
• Scruter les journaux d’évènements Windows avec LogParser (David BAFFALEUF) [SQL Server]
• Retrouver une transaction en échec (David BAFFALEUF) [SQL Server]

Lorsque SNAPSHOT_ISOLATION ou READ_COMMITTED_SNAPSHOT est activé sur une base, les UPDATES / DELETES vont pousser les lignes originales dans le version store. Donc un des inconvénients d’utiliser ce mécanisme est la pression qui s’ajoute sur tempdb.

Un autre impact moins connu est l’accroissement de l’espace utilisé dans les lignes modifiées: 14 octets de plus vont être utilisés par ligne, 6 pour pour stocker l’identifiant de la transaction qui a modifié la ligne, et 8 pour stocker le RID de la copie dans le version store. On essaie de s’intéresser au nombre de pages avant et après modification en RCSI, et au nombre de page splits potentiels qui peuvent survenir lorsque l’on modifie des données en masse dans une base en mode RCSI.

On créé une table clusterisée d’une seule page que l’on va remplir au maximum. A tâtons on arrive à voir que 250 lignes permettent de remplir la table au maximum de la capacité d’une page:

create database testRCSI
GO
use testRCSI
GO
create table RCSI(a numeric identity, b varchar(10))
GO
insert into RCSI values (replicate('b',10))
GO 250
create unique clustered index PK_RCSI on RCSI(a)
GO
dbcc ind('testRCSI','RCSI',-1)
GO

/*
PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber (...)
------- ----------- ------ ----------- ----------- ----------- --------------- (...)
1       114         NULL   NULL        2073058421  1           1               (...)
1       109         1      114         2073058421  1           1               (...)

PartitionID          iam_chain_type       PageType IndexLevel NextPageFID (...)
-------------- -------------------- -------------------- -------- --------(...)
72057594038386688    In-row data          10       NULL       0           (...)
72057594038386688    In-row data          1        0          0           (...)

*/

select * from sys.dm_db_index_physical_stats(11,2073058421,1,NULL, 'DETAILED')
where Index_Level=0
GO

/* La sortie est simplifiée pour plus de lisibilité
avg_page_space_used_in_percent=98,8139362490734
max_record_size_in_bytes=30
*/

Donc nous savons que notre table est stockée sur la page (1:109), que la page est dense à 98,8% et que la taille max d’une ligne est 30 octets. On passe la base en mode RCSI et on note la valeur de Page Splits courante.

alter database testRCSI set read_committed_snapshot on
GO
select cntr_value from sys.dm_os_performance_counters where counter_name like 'Page Splits%'
GO
/* cntr_value
--------------------
4013
*/

Ensuite, on va mettre à jour les lignes par une valeur de dimension égale (on remplace le caractère ‘b’ par un ‘c’ par exemple), et on s’intéresse en premier lieu à la nouvelle taille max de chaque ligne:

update RCSI set b = (replicate('c',10))
GO
select * from sys.dm_db_index_physical_stats(11,2073058421,1,NULL, 'DETAILED')
where Index_Level=0
GO
 /* La sortie est simplifiée pour plus de lisibilité
 avg_page_space_used_in_percent=71,0155670867309 
 max_record_size_in_bytes=44
 */

On voit que chaque ligne a bien grossi de 14 octets. Le version store quant à lui a bien stocké les 250 lignes modifiées (il faut le faire dans la minute qui suit le commit sinon le version store est recyclé):

select version_store_reserved_page_count from sys.dm_db_file_space_usage
GO
/*
version_store_reserved_page_count
----------------------------------------------
16
*/

Si on regarde le plan d’allocation de notre table mise à jour:

dbcc ind('testRCSI','RCSI',-1)
GO

/*
PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber
------- ----------- ------ ----------- ----------- ----------- ---------------
1       114         NULL   NULL        2073058421  1           1              
1       109         1      114         2073058421  1           1              
1       41          1      114         2073058421  1           1              
1       73          1      114         2073058421  1           1              

PartitionID          iam_chain_type       PageType IndexLevel (...)
-------------------- -------------------- -------- ---------- (...)
72057594038386688    In-row data          10       NULL       (...)
72057594038386688    In-row data          1        0          (...)
72057594038386688    In-row data          2        1          (...)
72057594038386688    In-row data          1        0          (...)

*/

Une page root a été ajoutée pour l’index clusterisé (PageType=2) plus une nouvelle page leaf (PageType=1). On n’est plus sur une seule page de données mais sur deux maitenant pourtant pour la même quantité de données, ce qui signifie qu’un page split est intervenu pour couper notre page initiale en deux.  Un rapide coup d’oeil au compteur perfmon va nous le confirmer (je précise que l’instance est idle):

select cntr_value from sys.dm_os_performance_counters where counter_name like 'Page Splits%'
GO
/*
cntr_value
--------------------
4015
*/

Pour récupérer cet espace, reconstruire l’index cluster devrait suffire:

alter index PK_RCSI on RCSI rebuild
GO
dbcc ind('testRCSI','RCSI',-1)
GO

/*
PageFID PagePID     IAMFID IAMPID      ObjectID    IndexID     PartitionNumber (...)
------- ----------- ------ ----------- ----------- ----------- --------------- (...)
1       89         NULL   NULL        2073058421  1           1               (...)
1       80         1      114         2073058421  1           1               (...)

PartitionID          iam_chain_type       PageType IndexLevel NextPageFID (...)
-------------- -------------------- -------------------- -------- --------(...)
72057594038386688    In-row data          10       NULL       0           (...)
72057594038386688    In-row data          1        0          0           (...)

*/

L’objet a été déplacé et réorganisé en entier (les pages sont différentes). On retrouve notre page unique du début. Quant à la taille des lignes, elle est revenue à sa valeur nominale:

select * from sys.dm_db_index_physical_stats(11,2073058421,1,NULL, 'DETAILED') where Index_Level=0
GO
/* La sortie est simplifiée pour plus de lisibilité
avg_page_space_used_in_percent=98,8139362490734
max_record_size_in_bytes=30
*/

Morale de l’histoire, attention aux page splits et à l’espace qu’occupent des lignes versionnées en mode SNAPSHOT_ISOLATION ou READ_COMMITTED_SNAPSHOT. Et reconstruire fréquemment les indexes sur ces tables permet de récupérer l’espace perdu.

A+. David B.Continuez votre lecture sur le blog :

• Se connecter à SQL Server à travers Oracle, quelle drôle d’idée ? (Thierry GASCARD) [Oracle]
• Installation Oracle 11gR2 64 bits sur Red Hat 5 Partie 1 (Thierry GASCARD) [Oracle]
• Installation Oracle 64 bits sur Red Hat 5 (Thierry GASCARD) [Oracle]
• Création et utilisation d’OCFS2 (Thierry GASCARD) [Oracle]
• Utiliser ASMCMD (Thierry GASCARD) [Oracle]