SQL SERVER 2008 apporte une nouveauté dans la compression : La faculté de compresser une table.
Pour réaliser cette compression, vous pouvez opter pour la compression par page de données ou par ligne. (PAGE COMPRESSION, ROW COMPRESSION)
Hormis le taux de compression que l’on gagne, donc un I/O réduit, et par déduction un gain de performance notable (modulo votre overhead CPU), quel choix faire entre Row ou Page Compression ?
Rappel de ces deux modes de stockage différents :
Row Compression : Les données dont le type est fixé (genre Char(100) sont stockées sous forme variable, avec optimisation du stockage de l’information de longueur. Et qui dit gain de bits non utilisés, dit plus moins de place pris par la row dans la page, donc plus de données stockées dans la page etc …
Page Compression : Les données redondantes sont stockées unitairement dans la page (genre une valeur par défaut) pour sauvegarder de la place. Qui dit gain de place, dit plus de données dans une page etc …
Généralement, on va dire que :
Si vous avez une activité intense, typique d’une base de données OLTP, utilisez la ROW COMPRESSION
Si vous avez une activité aléatoire, une table d’archive accédée plus rarement, utilisez la PAGE COMPRESSION
Ce genre de scénario est très utilisé dans les partitions de table par exemple:
On peut imaginer une table partitionnée par date, dont les données de l’année en cours sont compressées en mode ROW compression, et dont les données antérieures à 10 ans (par ex) stockées sur une autre partition sont compressées avec le mode PAGE Compression
Bonne compression
Il existe plusieurs modes dans la haute disponibilité avec SQL SERVER.
Ces modes Softwares, comme le Mirroring, Log Shipping, Replication Peer to Peer ou tout simplement une bonne stratégie de backups, s’appuient derrière sur du matériel physique : Nos chers disques durs, nos LUN dans nos SAN etc…
Il est donc peut être utile de rappeller (enfin moi ça m’est utile là tout de suite :)) les modes RAIDS à notre disposition :
MODE | |
RAID 0 (Répartition) | |
| Le Raid 0 est une solution de performance. Ici pas de redondance. C'est un système de répartition qui améliore les performances. Capacité : La totalité des disques Fiabilité : Le défaut de cette solution est que la perte d'un seul disque entraîne la perte de toutes les données |  |
RAID 1 (Redondance) | |
| Le Raid 1 consiste en un mirroring de Disque dur Redondance des disques Capacité : La taille d’un seul disque (le plus petit) La capacité supplémentaire est inutilisée si les disques durs n’ont pas la même capacité. Pensez à utiliser des disques de même capacités Fiabilité : Cette solution offre un excellent niveau de protection des données. Elle accepte une défaillance de n − 1 éléments. |  |
RAID 5 | |
| La répartition par bit de parité est circulaire. Si un disque tombe, les autres disques sont capables de recalculer les données perdues. Attention, un seul disque peut tomber en défaillance. Capacité : Sur 3 disques en RAID 5 : 2/3 de places disponible Fiabilité : Bonne si un seul disque tombe … La durée de remontage d'un disque est proportionnelle à la taille du disque (prohibitif sur les disques actuelles > 1 TO qui représente une dizaine d'heures de traitement) Implémentation Attention il faut un minimum de 3 disques pour mettre en place du RAID 5 | |
De là on peut imaginer plusieurs modes “complémentaires”
RAID 0+1
Comprenez : RAID 0 puis implémentation du RAID 1 par dessus
RAID 1+0
Comprenez : RAID 1 puis implémentation de RAID 0
RAID 5+1

BON RAIDS (private joke ;))
l’option TRUSTWORTHY permet de spécifier un niveau de “confiance” d’une instance vis à vis d’une base de données.
Ce nouveau concept a été introduit avec SQL SERVER 2005.
Il est implicitement induit par de nouvelles fonctionnalités apportées par SQL SERVER 2005, notamment l’intégration de la SQL CLR.
Supposons que vous attachiez une base de données contenant une proc. stock. CLR :
Lors d’un attachement de la base de données contenant l’assembly SQL CLR en mode EXTERNAL_ACCESS ou UNSAFE, SQL SERVER permet l’attachement, mais n’autorisera pas l’exécution de la procédure stockée SQL CLR.
Pour activer cette procédure stockée CLR, en admettant que vous lui fassiez “confiance”, il vous faudra exécuter le script suivant :
ALTER DATABASE <database> SET TRUSTWORTHY ON
go
sp_configure 'clr enabled', 1
go
reconfigure
Vous faites “Confiance” et vous “activez” la CLR.
Cette option est aussi utilisé lors de l’emprunt d’identité (délégation) et l’utilisation via ce token de ressources externes (Execute AS)
Ainsi, si vous utilisez des ressources externes via un contexte de sécurité de votre utilisateur connecté, vous devez donc faire confiance à votre bdd et activez l’option TRUSTWORTHY.
Un exemple via un schéma MSDN (Prolongement de l'emprunt d'identité) :
.gif)
Petit rappel sur la différence entre SqlNativeClient et ADO.NET
SqlNativeClient est une API utilisé en lieu et place d’ODBC ou OLE DB :
- Pour faire simple SqlNativeClient est une combinaison des deux (ODBC ET OLE DB) PLUS les fonctionnalités spécifiques à SQL SERVER comme MARS, XML , UDT etc….)
-
L’utilisation de SqlNativeClient s’adresse aux « migrations » d’ODBC ou OleDb qui veulent profiter des fonctionnalités de SQL SERVER 2005 et +
Dans tous les cas, en Code managed, la préconisation reste la Stack ADO.NET, si vous partez sur un nouveau projet.
Conclusion :
Vous voulez « migrer » votre Stack d’accès aux données actuellement en ODBC (ou OLE DB) ? Utilisez SqlNativeClient.
Vous partez sur un nouveau développement en code managed ? Utilisez ADO.NET
Au niveau des performances, rien de notable entre ADO.NET et SqlNativeClient (pas à ma connaissance du moins :))
Bon … choix !
Ok elle était facile celle là :)
Enfin il n’en reste pas moins que la session sur SQL SERVER Haute Dispo que j’ai co animée avec PASCAL BELAUD est maintenant disponible en téléchargement.
Rendez vous sur le site de l’AfterBDC , section Les SessionS
Notez au passage que nous avons mis en ligne quelques photos de l’évènements
Bon visionnage :)
Ah ben c’est allé trés trés vite, la balle de Mitch vient de passer par là :)
Bon j’écris jamais de trucs perso sur ce blog, mais l’exception confirme la règle. C’est parti:
10 trucs sur moi que vous connaissez peut être pas :
- Mon nom s’écrit sans H : On écrit PERTUS, pas PERTHUS. Le Col du Perthus est un village entre la Fance et l’Espagne.
Ce qui est marrant, c’est que beaucoup de gens se gourent sur mon nom en rajoutant un H, alors qu’ils ne connaissent pas le fameux Col du Perthus. Appelez ça l’inconscient collectif, va savoir … - Je suis un vrai Geek. un VRAI. C’est à dire que j’aime les jeux vidéos, de chez Blizzard de préférence. Je fais même des LAN entre pote trentenaire, à l’occaze.
En plus je travaille dans l’informatique. Voilà le bon gros Geek !
Par contre, j’ai aussi une vie sociale, je me rase presque tous les matins, je ne me nourris pas exclusivement de pizza et de coca périmé…
J’ai pas la gueule pleine de boutons et j’ai quelques fois réussi à draguer de jolies filles. La dernière en date est encore avec moi (comme quoi …)
J’arrive à tenir une conversation aussi, même si c’est pas forcément relié à mon métier et ma passion.
Stop les stéréotypes à la con . Geek powaa - Je suis né prématuré de 2mois. J’étais pressé faut dire. J’ai failli naitre en 1977. Mais 76 c’est mieux, c’est une meilleure année pour le pinard. Merci maman.
- J’ai été Cariste et Menuisier dans une ancienne vie. Je manipule (enfin manipulais) le FenWick thermique comme personne ! Et je montais une cuisine, des volets roulants ou des ouvrants double battant en un temps record. Aujourd’hui … euh passons :)
- Je fais de la baterrie et je suis nul comme une quiche mais je me soigne.
- J’écoute du JJ Goldman et Rammstein, en boucle. Je suis d’ailleurs allé au concert de chacun d’entre eux. Au final c’est assez proche (en tout cas, dans mon lecteur mp3 si :))
- Ma grand mère maternelle a eu 18 enfants. Ce qui me fait environ 17 oncles et 17 tantes. Je vous parle pas des cousins cousines… Au final, la vie fait que j’en connais … deux.
- Mon grand père (le père des 18 là ) s’appelait Celestrano. Je suis Italien d’origine. Le papy a été retrouvé devant la porte des bonne sœurs au début du 20eme siècle à Rome.
Celestrano veut dire “trouvé sous les étoiles”. La légende voudrait qu’il fut le fils illégitime d’une grande comtesse Italienne. Ca pète la classe, je sais. - J’ai eu une Peugeot y’a longtemps… Et y’a encore plus longtemps, une Renault… Ok chambrage en règle Lundi au taf.
- J’ai été dans un lycée où j’étais le seul mec de ma classe.
- C’est bien la première année. Clairement…
- La deuxième année, ça passe, mais tu te traines déjà une réputation de l’année passée.
- La troisième année c’est mort, clairement… Par contre les filles font plus trop gaffe à toi, tu fais parti du truc quoi… Et là tu participes au discussion de filles, les vraies discussions, celles qu’elles n’ont pas en général avec un gars dans les parages….
Dure la 3ème année… très dure.. Instructive, clairement.
Allez c’est bon pour moi, je passe le relais à mon pote Ben, notre Cht’i à nous :)
Je viens de faire un petit test sur les colonnes XML
On se doute tous que l’ajout d’index sur une colonne XML peut améliorer les performances, pour peu que bien sur vous ayez besoin de requêter la colonne XML elle même que ce soit via un PATH ou une VALUE (Xquery power)
Si ce n’est pas le cas, un bon vieux VarChar(max) est bien plus performant. N’oubliez pas qu’une colonne xml est en fait une bonne vielle table stockée dans une table système de votre base :)
Deuxième chose, la performance d’une colonne XML soumise à un schéma de validation XSD.
ON sait qu’un schéma va permettre de valider les données contenu dans notre champ XML. Déjà rien que ça justifie pleinement le fait de mettre une colonne XML Validée par un schéma XSD
Pour notre test, j’ai créé un schéma XSD, qui me permettra de valider ma colonne XML :
-- Création du schéma
CREATE XML SCHEMA COLLECTION AdditionalInfos AS '<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:simpleType name="addressType">
<xs:restriction base="xs:string">
<xs:enumeration value="Home" />
<xs:enumeration value="Office" />
<xs:enumeration value="Travel" />
<xs:enumeration value="Undefined" />
</xs:restriction>
</xs:simpleType>
<xs:element name="additionalOrder">
<xs:complexType>
<xs:sequence>
<xs:element name="orderDate" type="xs:dateTime"/>
<xs:element name="additionalAddress" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string"/>
<xs:element name="address" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
<xs:element name="country" type="xs:string"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="type" type="addressType" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="complementOrder" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="quantity" type="xs:positiveInteger" />
<xs:element name="price" type="xs:decimal"/>
</xs:sequence>
<xs:attribute name="orderId" type="xs:positiveInteger" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="additionalOrderId" type="xs:positiveInteger" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
'
Puis j’ai créé mes colonnes XML
- Première colonne : Colonne XML validée par mon schéma avec un index dessus et 2 index supplémentaires (VALUE et PATH)
- Deuxième colonne : Colonne XML sans schéma avec un index dessus et 2 index supplémentaires (VALUE et PATH)
- Troisième colonne : Colonne XML sans schéma sans index
Voilà la définition de ces colonnes:
-- Modification de la table
ALTER TABLE Sales.Customer ADD
AdditionnalInformations xml(DOCUMENT dbo.AdditionalInfos) NULL
GO
-- Création de l'index primaire XML
CREATE PRIMARY XML INDEX PXML_AdditionnalInformations on Sales.Customer (AdditionnalInformations)
-- Création d'un index secondaire de type Path
CREATE XML INDEX PXML_AdditionnalInformations_Path ON Sales.Customer (AdditionnalInformations)
USING XML INDEX PXML_AdditionnalInformations
FOR PATH
-- Création d'un index secondaire de type Value
CREATE XML INDEX PXML_AdditionnalInformations_Value ON Sales.Customer (AdditionnalInformations)
USING XML INDEX PXML_AdditionnalInformations
FOR VALUE
-- Modification de la table
ALTER TABLE Sales.Customer ADD AdditionnalInformationsWithoutSchema xml NULL
GO
-- Création de l'index primaire XML
CREATE PRIMARY XML INDEX PXML_AdditionnalInformations_WithoutSchema on Sales.Customer (AdditionnalInformationsWithoutSchema)
-- Création d'un index secondaire de type Path
CREATE XML INDEX PXML_AdditionnalInformations_WithoutSchema_Path ON Sales.Customer (AdditionnalInformationsWithoutSchema)
USING XML INDEX PXML_AdditionnalInformations_WithoutSchema
FOR PATH
-- Création d'un index secondaire de type Value
CREATE XML INDEX PXML_AdditionnalInformations_WithoutSchema_Value ON Sales.Customer (AdditionnalInformationsWithoutSchema)
USING XML INDEX PXML_AdditionnalInformations_WithoutSchema
FOR VALUE
ALTER TABLE Sales.Customer ADD
AdditionnalInformationsWithoutSchemaWithoutIndexes xml NULL
Y’a plus qu’à remplir les données, via un bon vieil INSERT ou UPDATE
Vous trouverez le script en PJ pour vous faire une idée
Voici les résultats de l’insertion
| Colonne XML Index + Schéma |
02:51 |
| Colonne XML Index |
03:56 |
| Colonne XML |
00:08 |
Alors oui, on est d’accord, l’insertion est bien plus performante sur une colonne XML sans index, un Blob quoi.
On Imagine bien que le parsing de chaque valeur XML et la création d’une table système avec une insertion à la volée peut être consommateur de ressources !
Passons aux requêtes de Sélection sur une requête Xquery PATH
-- Using PATH index
select Top 10 C.CustomerID, C.AdditionnalInformations.query('/additionalOrder/additionalAddress[@type = "Home"]')
from Sales.Customer C
select Top 10 C.CustomerID, C.AdditionnalInformationsWithoutSchema.query('/additionalOrder/additionalAddress[@type = "Home"]')
from Sales.Customer C
select Top 10 C.CustomerID, C.AdditionnalInformationsWithoutSchemaWithoutIndexes.query('/additionalOrder/additionalAddress[@type = "Home"]')
from Sales.Customer C
Je ne mesure pas le temps ici, il faudrait avoir un champ XML totalement énorme pour avoir une différence notable. J’ai donc noté le % d’exécution donné par le plan d’exécution
| Colonne XML Index + Schéma |
0% |
| Colonne XML Index |
0% |
| Colonne XML |
100% |
Bon Ok, la requête sur le BLOB sans index écroule tout. Je refais le test uniquement sur les colonnes indexés :
| Colonne XML Index + Schéma |
49% |
| Colonne XML Index |
51% |
Bon le gain sur une requête PATH n’est pas notable qu’on soit ou non validé par un schéma
Passons aux requêtes de Sélection sur une requête XQuery VALUE
-- Using VALUE index
Select C.CustomerID, C.AdditionnalInformations
from Sales.Customer C
where C.AdditionnalInformations.exist('/additionalOrder/@additionalOrderId[.=100]') = 1
Select C.CustomerID, C.AdditionnalInformations
from Sales.Customer C
where C.AdditionnalInformationsWithoutSchema.exist('/additionalOrder/@additionalOrderId[.=100]') = 1
Select C.CustomerID, C.AdditionnalInformations
from Sales.Customer C
where C.AdditionnalInformationsWithoutSchemaWithoutIndexes.exist('/additionalOrder/@additionalOrderId[.=100]') = 1
Les premiers résultats en comparant avec une colonne non indexée sont identiques à l’exemple précédent. Je passe donc directement à la comparaison des deux colonnes indexées :
| Colonne XML Index + Schéma |
0% |
| Colonne XML Index |
100% |
Wow … là oui y’a différence !
Examinons le plan d’éxécution :
Que se passe t’il : dans le premier cas, on a un schéma, donc une table fortement typée, où SQL SERVER sait que quelque soit la ligne, les données (enfin le type) sera identique :
Il peut donc faire une requête directement sur l’index
Sur la deuxième requête, la colonne est “permissive”. On peut stocker n’importe quel champ xml.
Pour pouvoir récupérer toutes les valeurs ‘@type’ il est donc obligé de faire un bon vieux gros SCAN de l’index XML PRIMARY
D’où l’intérêt du schéma !
Conclusion :
Les schémas c’est bien, une colonne XML indexé avec un schéma c’est performant et secure.
Par contre, vous perdez en Insertion. Attention à l’intéret d’une colonne XML si vous ne requêtez jamais l’arbre XML !
Quelques liens utiles :
Voilà voilà, bon indexation, bon XML tout ça tout ça !
Je fais pas mal de test sur les colonnes XML dans SQL SERVER (Post à venir d’ailleurs) et je viens de rencontrer une erreur assez improbable.
A force de supprimer puis rajouter des colonnes de type XML, j’ai eu au bout du compte une erreur m’indiquant en substance :
Cannot create a row of size 8063 which is greater than the allowable maximum of 8060.
Ok alors en fait non hein, j’ai que 2 colonnes dans ma table là oh !
Et bien la réponse est assez simple :
Voici une réponse de l’équipe MS là dessus:
“This behaviour is expected. Dropping a column is a metadata-only change and can leave gaps in column-offsets on the row.
When new columns are added to such a table the space left by the dropped columns may or may not be reused for the new column; it depends on the size and type of the old/new columns.
Bottom-line is that if you drop/add columns enough times there will be a point at which the max-fixed-size of the row will be exceeded due to the "holes" left behind by the dropped columns.”
Ok en gros on supprimer les métadatas de la colonne mais on ne récrit pas forcément toutes les pages (c’est pas bête)
A mieux les nouvelles données des futures nouvelles colonnes viendront écraser le contenu de l’ancienne colonne dans ma page de données.
Ou pas .. ce qui est mon cas, et particulièrement vrai dans une colonne XML.
La solution ?
Un bon vieux Rebuild Index
Voilà, j’arrête de m’arracher les cheveux et j’y retourne :)
Bewise vient de mettre en ligne le site http://AfterBDC.bewise.fr
Vous y trouverez tout ce qui concerne les sessions et les photos de la Bewise Day Conference 2010.
Nous mettrons chaque semaine des nouveaux éléments.
Vous pouvez le suivre également sur Tweeter: http://twitter.com/AfterBDC

Le feature pack de SQL SERVER 2008 R2 est sorti
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ceb4346f-657f-4d28-83f5-aae0c5c83d52
Comme toujours vous retrouvez un ensemble d’outil permettant d’étendre les possibilités de déploiement de SQL SERVER, ou encore des outils annexe en version Stand Alone
Pour vous donner une idée de ce que ça contient, voici une liste des principales features (tout du moins celle qui m’intéresse ces temps ci :)) :
- Microsoft® SQL Server Report Builder 3.0 for Microsoft® SQL Server 2008 R2
- Microsoft® SQL Server® PowerPivot for Microsoft® Excel
- Microsoft® SQL Server® 2008 R2 Reporting Services Add-in for Microsoft® SharePoint® Technologies 2010
- Microsoft® SQL Server® 2008 R2 Policies
- Microsoft® Sync Framework 2.0 Software Development Kit (SDK)
- Microsoft® SQL Server® Compact 3.5 SP2
- Microsoft® SQL Server® Compact 3.5 SP2 For Windows Mobile
- Microsoft® SQL Server ®Compact 3.5 SP2 Server Tools
- Microsoft® System CLR Types for SQL Server® 2008 R2
- Microsoft® SQL Server® 2008 R2 Remote Blob Store
- Microsoft® SQL Server® 2008 R2 Command Line Utilities
- Microsoft® Windows PowerShell Extensions for SQL Server® 2008 R2
- Microsoft® SQL Server® 2008 R2 Shared Management Objects
Et encore d’autres …
Et hop, en avant le téléchargement :)
Allez plus que 4 GO et on installe !
Bon téléchargement :)
Il y a longtemps, j’ai écris un post (à l’époque de Windows Vista, un siècle en somme :)) qui expliquait comment configurer une machine simple pour ouvrir l’accès à son serveur SQL.
Je vous laisse consulter ce petit tips ici : SQL SERVER & Remote Connections
J’ai souvent eu la réflexion : “Le Point 2) sur le Sql Server Browser n’est pas nécessaire, moi je l’ai désactivé et ça marche quand même …”
Oui, bon, petite explication :
Le Service Browser est là pour BroadCaster votre (ou vos) instance(s) sur le réseau. Ce qui permet notamment à d’autres serveurs d’apparaître dans votre liste lorsque vous faites “Parcourir …”
Voilà c’est simple, ça broadcast sur le port UDP 1433 en gros.
Le truc, c’est que le Browser n’est pas là que pour ça.. Il fournit notamment les informations de protocoles que votre instance peut utiliser (Shared Memory, Named Pipres, TCP …)
SQL Browser fait ce qu’on appelle du SSRP “SQL Server Resolution Protocol” : Il résoud les protocoles autorisés pour une instance donnée.
Là où ça devient donc obligatoire (d’avoir le Browser activé, on suit au fond là !!) c’est justement quand vous avez des instances nommées.
Le problème ne se pose pas sur une instance par défaut, il n’y en a qu’une sur la machine. Lors de l’appel d’une instance nommée, votre demande de connexion passe par le browser pour connaitre les protocoles autorisés.
En somme, pour faire simple : Vous avez une instance nommée ? Activez le Browser :)
Bonne connexion !
A fortiori, on peut dire Oui :)
Aprés on peut dire aussi “Surtout le dernier, en fait !”
Vraiment le dernier dernier ? :) Et si je l’ai plus ce dernier là ??
Nous savons tous que le dernier rempart protégeant votre base de données reste la stratégie de sauvegarde que vous avez mis en place.
On peut imaginer une stratégie (pour un mode de récupération complet) basée sur une sauvegarde complète, plus un ou deux différentiel, et enfin les sauvegardes du transaction log.
Je reprends un schéma de MSDN pour illustrer ce cas simple :
Un client m’a posé la question suivante :
“Que se passe t’il si je perds le dernier backup full ? Puis-je tout de même remonter la base jusqu’au dernier log ? '(à supposer qu’au final je n’ai perdu que le dernier backup full mais pas les logs qui ont suivi)”
Bon ok c’est tordu, mais ce qui est aussi intéressant c’est savoir si le backup contiendrait des informations indispensables entre le log qui le précède et le log qui lui succède.
J’ai donc monté un petit script de test, simplissime pour évaluer la situation :
1: INSERT [dbo].[Employe] ([EmployeId], [Nom],
2: [Prenom], [NumeroCarteCredit])
3: VALUES (N'37cb101c-f2f9-4f28-b9f6-10e4193849ff',
4: N'Pertus', N'Sébastien', N'1234-2344-2333-45555')
5: Go
6:
7: /*** Premier backup Complet ***/
8: BACKUP DATABASE [bBackupStrategie]
9: TO DISK = N'C:\Projects\Backup\bBackupFull1.bak'
10:
11:
12: Update [dbo].[Employe]
13: Set [NumeroCarteCredit] = '1234-2344-2333-888888'
14: Where EmployeId= '37cb101c-f2f9-4f28-b9f6-10e4193849ff'
15: Go
16: /*** Premier backup Transactionnel ***/
17: BACKUP LOG [bBackupStrategie]
18: TO DISK = N'C:\Projects\Backup\bBackupTrans1.trn'
19:
20: GO
21: Update [dbo].[Employe]
22: Set [NumeroCarteCredit] = '1234-2344-2333-777777'
23: Where EmployeId= '37cb101c-f2f9-4f28-b9f6-10e4193849ff'
24: Go
25: /*** Deuxième backup Transactionnel ***/
26: BACKUP LOG [bBackupStrategie]
27: TO DISK = N'C:\Projects\Backup\bBackupTrans2.trn'
28:
29: /*** Deuxième backup Complet ***/
30: BACKUP DATABASE [bBackupStrategie]
31: TO DISK = N'C:\Projects\Backup\bBackupFull2.bak'
32:
33: Update [dbo].[Employe]
34: Set [NumeroCarteCredit] = '1234-2344-2333-666666'
35: Where EmployeId= '37cb101c-f2f9-4f28-b9f6-10e4193849ff'
36: Go
37: /*** Troisième backup Transactionnel ***/
38: BACKUP LOG [bBackupStrategie]
Ok à partir de là, on voit que j’ai 2 backups full et plusieurs transaction Logs
Je vais donc tenter de restaurer ma base de données sans le dernier backup full.
Il me faut donc le premier backup Full ainsi que l’ensemble des transactions logs jusqu’au dernier (sans oublier le tail log que j’inclus dans ma procédure de restauration)
Et voilà ce que ça donne :
1: USE master;
2: GO
3:
4: /*** Sauvegarde du tail log ***/
5: BACKUP LOG [bBackupStrategie]
6: TO DISK = N'C:\Projects\Backup\bBackupTailLog.trn' WITH NO_TRUNCATE, NORECOVERY
7: GO
8:
9: /**** Restauration à partir du 1er Backup complet (et non pas le dernier) ***/
10: RESTORE DATABASE [bBackupStrategie]
11: FROM DISK = N'C:\Projects\Backup\bBackupFull1.bak'
12: WITH FILE = 1, NORECOVERY
13: GO
14: RESTORE LOG [bBackupStrategie]
15: FROM DISK = N'C:\Projects\Backup\bBackupTrans1.trn'
16: WITH FILE = 1, NORECOVERY
17: GO
18: RESTORE LOG [bBackupStrategie]
19: FROM DISK = N'C:\Projects\Backup\bBackupTrans2.trn'
20: WITH FILE = 1, NORECOVERY
21: GO
22: /*** Depart hypothétique si le dernier backup était accessible ***/
23: --RESTORE DATABASE [bBackupStrategie]
24: -- FROM DISK = N'C:\Projects\Backup\bBackupFull2.bak'
25: -- WITH FILE = 1, NORECOVERY
26: --GO
27:
28: RESTORE LOG [bBackupStrategie]
29: FROM DISK = N'C:\Projects\Backup\bBackupTrans3.trn'
30: WITH FILE = 1, NORECOVERY
31: GO
32: RESTORE LOG [bBackupStrategie]
33: FROM DISK = N'C:\Projects\Backup\bBackupTailLog.trn'
34: WITH FILE = 1, RECOVERY
35:
36: GO
Et là miracle (ou pas) tout se déroule correctement.
Résultat, le backup complet ne compromets pas la cohérence des données dans le Transaction log.
Bon ce cas de figure est un peu tordu, je vous le concède, mais il a le mérite d’éclaircir un point sous-jacent non négligeable, lui.
Voici le lien vers le source complet de ce script : http://www.dotmim.com/SiteFiles/TipsBackupWithoutLastBackup.sql.txt
Bon backup !
Voilà une chouette annonce. SQL SERVER 2008 R2 passe en RTM
Encore quelques jours et vous devriez pouvoir profiter des nouveautés de cette mouture via vos abonnements MSDN par exemple
L’annonce : http://www.microsoft.com/presspass/presskits/sqlserver/
voilà voilà…. va falloir patienter un chouilla !
Microsoft vient de sortir un E-Book gratuit sur SQL SERVER 2008 R2.
Un bon aperçu des fonctionnalités de SQL SERVER, avec les nouveautés de la R2.
Un must read donc :)
Le lien du blog MSDN Press : http://blogs.msdn.com/microsoft_press/archive/2010/04/14/free-ebook-introducing-microsoft-sql-server-2008-r2.aspx
Les liens directs :
- XPS
- PDF
Bonne lecture :)
Plus de Messages
Page suivante »