Business Geek

...depuis quelques heures déjà.

Désolé de ne pas plus m'étendre plus sur cette nouvelle mais je suis chez un client en plein audit de perfs alors je développerai ce soir, pendant l'installation

Lorsque l'on travaille avec des transactions imbriquées, on veut parfois pour voir annuler une transaction intermédiaire mais garder les précédentes opérations.

En T-SQL, l'opération de ROLLBACK annule l'ensemble des niveaux de transactions (scopes). Pour s'en convaincre, cette citation de la documentation (ROLLBACK) :

When nesting transactions, this same statement rolls back all inner transactions to the outermost BEGIN TRANSACTION statement.

Le code suivant montre un exemple du problème. Le premier ROLLBACK annule tout depuis la transaction A. La variable @@trancount permet de voir qu'il n'y a plus de transaction en cours

BEGIN TRAN A
-------on démarre le premier niveau de transaction

INSERT INTO [AdventureWorks].[dbo].[truc]([a],[b])
VALUES ('transaction A','transaction A')

select @@trancount --returns 1

BEGIN TRAN B
-------on démarre le deuxième niveau de transaction

INSERT INTO [AdventureWorks].[dbo].[truc]([a], [b])
VALUES ('transaction B','transaction B')

select @@trancount --returns 2

ROLLBACK TRANSACTION B
--on annule la transaction intermédiaire

select @@trancount
--returns 0 : plus de transaction en cours

COMMIT TRAN A --génère une erreur
--Msg 6401, Level 16, State 1, Line 19
--Cannot roll back B. No transaction or savepoint of that name was found.

Ce comportement ne nous permet donc pas d'annuler une partie du traitement tout en gardant le reste. Heureusement, l'instruction SAVE TRANSACTION nous permet de corriger le tir. SAVE TRANSACTION permet de mettre un point de sauvegarde dans la transaction en cours pour pouvoir y revenir par la suite, avec l'instruction ROLLBACK.

Voici le script modifié. A la fin, la ligne A est insérée mais pas la B.

BEGIN TRAN A
-------on démarre le premier niveau de transaction

INSERT INTO [AdventureWorks].[dbo].[truc]([a],[b])
VALUES ('transaction A','transaction A')

select @@trancount --returns 1

BEGIN TRAN B
-------on démarre le deuxième niveau de transaction

SAVE TRANSACTION B_Saved
--on met un point de sauvegarde

INSERT INTO [AdventureWorks].[dbo].[truc]([a], [b])
VALUES ('transaction B','transaction B')

select @@trancount --returns 2

ROLLBACK TRANSACTION B_Saved

COMMIT B
--on force quand même un commit pour valider la transaction B

select @@trancount --returns 1

COMMIT TRAN A

A noter que l'on doit quand même faire un COMMIT de la transaction enfant car le retour à un point de sauvegarde ne termine pas la transaction.

Non, ce n'est pas un jeu de mot pour présenter une nouvelle Assembly. Je parle ici de références clients qui utilisent avec succès SQL Server.
Le tout présenté dans une petite application Silverlight.

Le site est ici : http://www.microsoft.com/france/sql/ilslontfait/

Les références sont :

• JCDecaux (plus connu sous le nom de Velib') : 400 000 locations par jour
• Premier Bankcard : un datawarehouse de 20 To (27 milliards de lignes)
• AFP : 4000 utilisateurs en simultanés
• Xiti : 17 milliards d'enregistrements par mois
• AXA : Business Intelligence temps réel
• Nancy-Université : réduction des coûts de SAP

Il y a plusieurs semaines, j'ai terminé un article d'introduction aux fonctionnalités spatiales de SQL Server 2008. Voici quelques extraits pour vous mettre en appétit. Et pour aller directement sur l'article complet :

      Premiers pas dans l'espace (www.bewise.fr)

Introduction
Cet article se veut une première introduction aux nouveaux types spatiaux de SQL Server 2008. Je vais vous les présenter et nous les manipulerons. Nous aborderons aussi leur utilisation avec du code .NET. Enfin, nous utiliserons Virtual Earth pour présenter les données géographiques mais nous ne rentrerons pas dans le détail de cette technologie.

[...]

Premières requêtes
Les 2 nouveaux types proposent toute une série de méthodes pour manipuler des données spatiales. Aire de la surface, surface circonscrite, inscrite, périmètre, intersection, union, barycentre… Le but n’est pas de vous les décrire ici une à une. Nous allons toutefois en utiliser quelques unes dans des requêtes simples mais indispensables dans une application gérant des types spatiaux.

Tout d’abord, voyons comment retrouver les points contenus dans une zone donnée. Comme cas concret, on peut imaginer une recherche d’appartements ou d’hôtels dans une zone définie. Pour cela, nous avons plusieurs possibilités avec les méthodes STContains, STIntersects et STWithin. La méthode STIntersects serra utilisée pour le type geography car les 2 autres n’existent que sur le type geometry. Voici le code T-SQL permettant cette requête :

Declare @zone geography = geography::STPolyFromText('POLYGON((43 3.2, 43 3.5, 43.2 3))', 4326)

Select *
From CustomerPlaces
Where @zone.STIntersects(CustomerPlaces.Localization) = 1

[...]

ADO.NET
Après avoir vu un aperçu des types spatiaux et de leur utilisation dans SQL dans Management Studio, intéressons nous à la manipulation depuis une application .NET.

[...]

Et comme d'habitude, n'hésitez pas pour les questions...

J'ai eu il y a quelques temps la question suivante :

j'aimerais faire comprendre à mes développeurs l'intéret de positionner des NOLOCK dans les requêtes de sélection, peux-tu m'aider pour faire l'argumentaire

Pour rappel ou pour ceux qui ne voient pas de quoi je parle, NOLOCK est un Query Hint qui permet de passer le mode d'isolation au niveau le plus bas sur la lecture d'une table. Il s'utilise de la façon suivante :

Select * From MaTable WITH (NOLOCK)

Voici la réponse que j'ai donné :

Premièrement et c'est le plus important, utiliser NOLOCK n'est pas « naturel », dans le sens où la base de donnnées est là pour garantir les accès concurrents et gérer des lecture/écriture dans une optique transactionnelle (contraintes ACID¹) et ceux même pour un énorme volume de transactions.

Cependant, sans aller jusqu'à dire que c'est un constat d'échec que de l'utiliser, le hint NOLOCK est intéressant dans certains contextes.
Notamment les sites Web qui font beaucoup d'accès en lecture pour faire principalement de l'affichage. Dans ce cas, en effet, avoir une donnée non commitée n'est (en général) pas critique, sauf pour certains sites (bourses, état de stock, etc.). Cela permet de soulager la base de données et de booster l'affichage des pages.

Mais pour moi, le NOLOCK n'est qu'une réponse technique d'urgence et ne sert juste qu'à cacher la poussière sous le tapis. Il faut comprendre pourquoi l'ajout d'une ligne dans une facture bloque l'affichage du top 10 des vendeurs et essayer d'y répondre par la conception de l'application (cache, portée des transactions, etc.) ou de la base (normalisation/dénormalisation).
J'insiste qu'il y a un risque à utiliser NOLOCK à tout va, car on peut récupérer des données "dirty" et les réécrire par la suite et perdre la cohérence (aCid); à l'application d'adresser cette contrainte.

Donc pour conclure :

• le NOLOCK est une réponse technique intéressante pour optimiser l'affichage de données NON CRITIQUES
• l'utilisation systématique du NOLOCK n'est pas une bonne chose car elle cache un réel problème transactionnel. Et surtout on ne respecte plus la "norme" ACID.

Si tu utilises SQL Server 2005, il faut te tourner vers les autres niveaux de verrou comme le Snapshot (READ_COMMITTED_SNAPSHOT) qui apporte la souplesse en lecture tout en garantissant les transactions (comme le fait Oracle). Un bon argument pour passer à 2005.

¹ACID: Atomicité, Cohérence, Isolation, Durabilité