SQL - Etienne ZINZINDOHOUE

SQL Three-Valued Logic (3VL)

zinzineti — Wed, 08 Aug 2012 21:52:40 +0000

Soit les tables T1 et T2 suivantes :

create table T1 (col1 int)
create table T2 (col2 int)
insert into T1 select 1 union select 2 union select 3 union select null
insert into T2 select 4 union select 2 union select 5 union select null

Pourquoi la requête SELECT * FROM T1 WHERE col1 NOT IN (SELECT col2 FROM T2) ne renvoie aucune valeur alors que
SELECT * FROM T1 WHERE col1 IN (SELECT col2 FROM T2) renvoie la valeur 2 ?
Rappelons qu’une colonne affiche NULL lorsqu’elle ne contient pas de valeur. En SQL une opération de comparaison peut être avoir l’une des trois valeurs logiques suivantes : TRUE (vrai) ou FALSE (faux) ou UNKNOWN (inconnu). C’est ce qu’on a appelle « Three-Valued Logic » (3VL). Signalons qu’en mathématiques, l’algèbre de Boole est 2VL et ne connait donc que deux valeurs (VRAI ou FAUX). En SQL la valeur logique UNKNOWN est due à la présence de NULL dans une opération de comparaison.
Exemple :

——————————————————

p condition état logique

——————————————————

2 p IS NULL FALSE

——————————————————

2 p IS NOT NULL TRUE

——————————————————

NULL p IS NULL TRUE

——————————————————

NULL p IS NOT NULL FALSE

——————————————————

2 p = NULL UNKNOWN

——————————————————

2 p <> NULL UNKNOWN

——————————————————

NULL p = NULL UNKNOWN (pour SQL standard)

——————————————————

NULL p <> NULL UNKNOWN

——————————————————

NULL p = 2 UNKNOWN

——————————————————

NULL p <> 2 UNKNOWN

——————————————————

avec le tableau ci-dessus on peut constater que si l’un des opérandes est NULL alors l’opération de comparaison prend la valeur logique UNKNOWN. Pour déterminer si une expression est NULL (ou pas) il faut utiliser IS NULL (ou IS NOT NULL)

=> Algèbre Three-Valued Logic (3VL) et les opérateurs NOT, AND et OR
–> avec l’opérateur NOT
NOT TRUE = FALSE
NOT FALSE = TRUE
NOT UNKNOWN = UNKNOWN

–> avec l’opérateur AND
TRUE AND TRUE = TRUE
TRUE AND FALSE = FALSE
TRUE AND UNKNOWN = UNKNOWN

FALSE AND TRUE = FALSE
FALSE AND FALSE = FALSE
FALSE AND UNKNOWN = FALSE

UNKNOWN AND TRUE = UNKNOWN
UNKNOWN AND FALSE = FALSE
UNKNOWN AND UNKNOWN = UNKNOWN

–> avec l’opérateur OR
TRUE OR TRUE = TRUE
TRUE OR FALSE = TRUE
TRUE OR UNKNOWN = TRUE

FALSE OR TRUE = TRUE
FALSE OR FALSE = FALSE
FALSE OR UNKNOWN = UNKNOWN

UNKNOWN OR TRUE = TRUE
UNKNOWN OR FALSE = UNKNOWN
UNKNOWN OR UNKNOWN = UNKNOWN

=> UNKNOWN avec les clauses WHERE et CHECK
Dans une clause WHERE une expression évaluée comme UNKNOWN se comporte comme FALSE et dans ce cas aucune ligne n’est renvoyée.
Exemple :
select * from T1 where col1 not in (select col2 from T2)
Par contre dans une clause CHECK une expression évaluée comme UNKNOWN se comporte comme TRUE et l’expression est considérée comme valide
Exemple

create table T2 (col2 int , CONSTRAINT CHK CHECK (col2 < 10))
insert into T2 select 4 union select 2 union select null

— insertion réalisée

=> opération arithmétique avec NULL renvoie NULL et peut donc provoquer un état logique UNKNOWN lors d’une comparaison

SELECT 3 + null
SELECT 3 - null
SELECT 3 * null
SELECT 3 /null

=> La plupart des fonctions d’agregation ignorent NULL

select AVG(col2) from T2 -- donne (4+2)/2 = 3 ici null est ignoré
select COUNT(*) from T2 -- donne 4 : ici null n'est pas ignoré
select COUNT(col2) from T2 -- donne 3 : ici null est ignoré

=> Les opérateurs ensemblistes UNION,INTERSECT,EXCEPT n’ignorent pas NULL

select * from T1 UNION select * from T2
select * from T1 EXCEPT select * from T2
select * from T1 INTERSECT select * from T2

=> CASE expression : attention lorsque la clause ELSE n’est pas explicite ELSE NULL est rajouté !
Exemple

SELECT case col1
when 1 then 1
when 2 then 2
when 3 then 3
END
FROM T1

Les fonctions CASE, COALESCE, … permettent de traiter les NULLs afin d’obtenir les résultats escomptés.

——————–
Etienne ZINZINDOHOUE
——————–

IPv4 : Stockage et Manipulations

zinzineti — Fri, 08 Jun 2012 17:26:29 +0000

La norme SQL n’a rien proposé jusqu’à ce jour pour stocker les types de données network (IPv4, IPv6, masque de sous-réseau,…) . Les « grands » éditeurs de SGBD ne disposent pas encore de types de données capable de stocker et de manipuler aisément les données de types IP par exemple. Dans ce domaine PostGreSQL est largement en avance. Pour illustrer mes propos prenons un exemple simple :
Imaginer une application web qui stocke l’adresse IP des ordinateurs des utilisateurs dans une table nommée « TableDesIPs » pour faciliter un certain nombre d’opérations : identification, redirection, restriction, filtrage, … SQL Server et ORACLE sont aujourd’hui incapables de donner une réponse favorable à la requête suivante : SELECT IP_VISITEUR FROM TableDesIPs WHERE IP_VISITEUR > IP_MIN AND IP_VISITEUR < IP_ADR_MAX
C’est à dire lister les adresses IP membre d’une plage d’adresse IP. La borne inférieure de la plage est IP_MIN et la borne supérieure IP_MAX.
Par contre PostGreSQL se démarque en implémentant les types de données : CIDR et INET qui permettent de stocker et de manipuler aisément les données de type IP. Voyons quelques rustines pour stocker des données IPv4 et MAC-48 sous SQL Server
Quelques rustines pour stocker des données IPv4 sous SQL Server
=> Stocker IPv4 sous SQL Server

–> Création de la fonction de validation d’IPv4

CREATE FUNCTION [dbo].[IsIPv4](@IsIPv4 CHAR(19))
RETURNS SMALLINT
AS
BEGIN
DECLARE @IsOK SMALLINT;
-- Vérifier si on que des nombres en dehors des points
IF (ISNUMERIC(REPLACE(@IsIPv4,'.',''))=1
-- Vérifier s'il y a 3 points dans la chaine
AND LEN(@IsIPv4) - LEN(REPLACE(@IsIPv4,'.','')) = 3
-- Vérifier que les nombres de bits pour l'IPV4 est compris entre 0 et 255
AND 0 <= CAST(PARSENAME(@IsIPv4,1) as SMALLINT) AND CAST(PARSENAME(@IsIPv4,1) as SMALLINT) <= 255
AND 0 <= CAST(PARSENAME(@IsIPv4,2) as SMALLINT) AND CAST(PARSENAME(@IsIPv4,2) as SMALLINT) <= 255
AND 0 <= CAST(PARSENAME(@IsIPv4,3) as SMALLINT) AND CAST(PARSENAME(@IsIPv4,3) as SMALLINT) <= 255
AND 0 <= CAST(PARSENAME(@IsIPv4,4) as SMALLINT) AND CAST(PARSENAME(@IsIPv4,4) as SMALLINT) <= 255
)
SELECT @IsOK = 1
ELSE
SET @IsOK = 0
RETURN @IsOK
END

–> Test de Stockage d’IP

CREATE TABLE TableIPv4 (ID INT IDENTITY, IPv4 CHAR(19) CHECK (dbo.IsIPv4 (IPv4)=1))
INSERT TableIPv4 VALUES('10.276.33.25')

Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint « CK__TableIPv4__IPv4__090A5324″. The conflict occurred in database « AdventureWorks », table « dbo.TableIPv4″, column ‘IPv4′.
The statement has been terminated.

INSERT TableIPv4 VALUES('10.226.33.25')

(1 row(s) affected)

Comment stocker des adresses mac sous SQL Server ?
Rappelons que l’adresse MAC-48 est constituée de 48 bits (6 octets) se représente sous la forme hexadécimale avec les octets séparés par deux point (:) ou par un tiret (-)
Exemples :
——–
08-00-2B-01-02-03
08:00:2B:01:02:03

=> Stocker ADRESSE MAC sous SQL Server

–> Création de la fonction de validation MAC-48

CREATE FUNCTION [dbo].[IsMacAddress48](@MacAddress CHAR(17))
RETURNS SMALLINT
AS
BEGIN
DECLARE @IsOK SMALLINT;
-- Vérifier si on que des nombres en dehors des points
IF (LEN(REPLACE(REPLACE(@MacAddress,'-',''),':',''))= 12
-- Vérifier s'il y a 3 points dans la chaine
AND (@MacAddress LIKE '[0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F]-[0-9a-fA-F][0-9a-fA-F]'
OR @MacAddress LIKE '[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]:[0-9a-fA-F][0-9a-fA-F]'
)
)
SELECT @IsOK = 1
ELSE
SET @IsOK = 0
RETURN @IsOK
END

–> Test de Stockage de MAC-48

CREATE TABLE TableMacAddress48 (ID INT IDENTITY, MacAddress48 CHAR(17) CHECK (dbo.IsMacAddress48(MacAddress48)=1))
INSERT TableMacAddress48 VALUES('08-00-2G-01-02-03')

Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint « CK__TableMacA__MacAd__0CDAE408″. The conflict occurred in database « AdventureWorks », table « dbo.TableMacAddress48″, column ‘MacAddress48′.
The statement has been terminated.

INSERT TableMacAddress48 VALUES(’08-00-2B-01-02-03′)

(1 row(s) affected)

——————————————————
— Etienne ZINZINDOHOUE
——————————————————

Transactions implicite, explicite et autocommit

zinzineti — Tue, 01 May 2012 00:24:07 +0000

Petite discussion sur les transactions implicite, explicite et auto-commit d’une part et variation de la variable @@TRANCOUNT en fonction de l’option SET IMPLICIT_TRANSACTIONS d’autre part. Il s’agit ici des transactions SQL, des transactions au sein du SGBD SQL Server.

=> Transaction explicite
———————-
Une transaction est dite explicite lorsqu’on indique le début (BEGIN TRANSACTION) et la fin (COMMIT TRANSACTION ou ROLLBACK TRANSACTION) de la transaction

Exemple
——–

BEGIN TRANSACTION
-- ici instruction(s) SQL
create table t (col char(1))
insert into t values ('1')
COMMIT TRANSACTION

=> Transaction implicite
Une transaction est dite implicite lorsqu’il n’y a pas de BEGIN TRANSACTION pour indiquer le début de la transaction. Cette dernière est automatiquement démarrée par l’une des commandes :
ALTER TABLE, CREATE, DELETE, DROP, FETCH, GRANT, INSERT, OPEN, REVOKE, SELECT, TRUNCATE TABLE, UPDATE mais il est indispensable de valider la transaction implicite par COMMIT TRANSACTION ou de l’annuler avec ROLLBACK TRANSACTION.
Pour activer ce mode de fonctionnement sous SQL Server, il suffit d’exécuter la commande :
SET IMPLICIT_TRANSACTIONS ON

Exemple
——–

SET IMPLICIT_TRANSACTIONS ON
-- ici instruction(s) SQL
create table t (col char(1))
insert into t values ('1')
COMMIT TRANSACTION

=> Autocommit
Si en l’abscence des verbes BEGIN TRANSACTION, COMMIT TRANSACTION ou ROLLBACK TRANSACTION chaque instruction SQL est considérée comme une transaction alors on dit qu’on est en mode autocommit. Dans ce cas chaque instruction SQL est automatiquement validée (s’il n’y a pas d’erreur) ou annuler (s’il y a erreur). C’est le mode de fonctionnement par défaut sous SQL Server. Pour activer ce mode de fonctionnement sous SQL Server, il suffit d’exécuter la commande :
SET IMPLICIT_TRANSACTIONS OFF

Exemple
——–

SET IMPLICIT_TRANSACTIONS OFF
create table t (col char(1))
insert into t values ('1')
insert into t values ('12') -- échec lors de l'insertion de cette ligne
select * from t -- on a une ligne dans la table

=> @@TRANCOUNT en fonction de l’option IMPLICIT_TRANSACTIONS
–>1# @@TRANCOUNT et SET IMPLICIT_TRANSACTIONS OFF

SET IMPLICIT_TRANSACTIONS OFF
print '@@TRANCOUNT avant begin : ' + cast (@@TRANCOUNT as char(1))
BEGIN TRANSACTION
print '@@TRANCOUNT après begin : ' + cast (@@TRANCOUNT as char(1))
create table t (col char(1))
print '@@TRANCOUNT après create : ' + cast (@@TRANCOUNT as char(1))
insert into t values ('1')
print '@@TRANCOUNT après insert : ' + cast (@@TRANCOUNT as char(1))
COMMIT TRANSACTION
print '@@TRANCOUNT après commit : ' + cast (@@TRANCOUNT as char(1))

Résultat
———
@@TRANCOUNT avant begin : 0
@@TRANCOUNT après begin : 1
@@TRANCOUNT après create : 1
(1 row(s) affected)
@@TRANCOUNT après insert : 1
@@TRANCOUNT après commit : 0

–>2#@@TRANCOUNT et IMPLICIT_TRANSACTIONS ON avec BEGIN TRANSACTION

SET IMPLICIT_TRANSACTIONS ON
print '@@TRANCOUNT avant begin : ' + cast (@@TRANCOUNT as char(1))
BEGIN TRANSACTION
print '@@TRANCOUNT après begin : ' + cast (@@TRANCOUNT as char(1))
create table t (col char(1))
print '@@TRANCOUNT après create : ' + cast (@@TRANCOUNT as char(1))
insert into t values ('1')
print '@@TRANCOUNT après insert : ' + cast (@@TRANCOUNT as char(1))
COMMIT TRANSACTION
print '@@TRANCOUNT après commit : ' + cast (@@TRANCOUNT as char(1))

Résultat
———
@@TRANCOUNT avant begin : 0
@@TRANCOUNT après begin : 2
@@TRANCOUNT après create : 2
(1 row(s) affected)
@@TRANCOUNT après insert : 2
@@TRANCOUNT après commit : 1

–>3#@@TRANCOUNT et IMPLICIT_TRANSACTIONS ON sans BEGIN TRANSACTION

SET IMPLICIT_TRANSACTIONS ON
print '@@TRANCOUNT après set implicit on : ' + cast (@@TRANCOUNT as char(1))
create table t (col char(1))
print '@@TRANCOUNT après create : ' + cast (@@TRANCOUNT as char(1))
insert into t values ('1')
print '@@TRANCOUNT après insert : ' + cast (@@TRANCOUNT as char(1))
COMMIT TRANSACTION
print '@@TRANCOUNT après commit : ' + cast (@@TRANCOUNT as char(1))

Résultat
———
@@TRANCOUNT après set implicit on : 1
@@TRANCOUNT après create : 1
(1 row(s) affected)
@@TRANCOUNT après insert : 1
@@TRANCOUNT après commit : 0

Bonne fête du travail

————————-
Etienne ZINZINDOHOUE
————————-

blocage – interblocage : lock – deadlock

zinzineti — Mon, 23 Apr 2012 18:47:33 +0000

Lorsque deux processus (instructions sql) tentent simultanément de modifier (INSERT,UPDATE,DELETE) les mêmes données, le SGBD empêche les traitements simultanés de ces processus afin de protéger les données et l’intégrité de la base. SQL Server crée un verrou pour chaque processus et les gère selon un agorithme FIFO (First In First Out). Dans ce cas SQL Server impose un traitement en série dans instructions, ce qui entraine donc des temps d’attente, donc des blocages. Mais lorsque ce blocage dure longtemps, les applications qui pointent vers la base de données deviennent inutilisables et les utilisateurs ne sont pas contents …
Dans ce billet, nous mettre en évidence quelques situations provoquant des blocages, des interblocages et des pistes pour anticiper/gérer aux mieux ces situations.

Dans les exemples qui vont suivre nous allons utiliser deux sessions via SQL Server Management Studio (ssms)
Pour passer d’une session à une autre j’ai préféré la présentation ci-dessous pour plus de confort visuel.
Une fois les deux fenêtre ouvertes, clique droit sur l’onglet

Choisir l’affichage verticale des sessions

=> Mise en évidence d’un blocage

-- Création de la table
IF OBJECT_ID('T') IS NOT NULL DROP TABLE T
CREATE TABLE T (id INT,col CHAR(1))
-- insertion des données dans la table
INSERT INTO T (id,col) VALUES (1,'a')
INSERT INTO T (id,col) VALUES (2,'b')

Supposons que deux utilisateurs veulent exécuter presque au même moment, la même transaction.

–> Session 1 (utilisateur 1) : démarrer la transaction suivante
————–

BEGIN TRAN
UPDATE T
SET col = 'c'
WHERE id = 1
/*
Résultat : UPDATE effectué dans la session 1
*/

–> Session 2 (utilisateur 2) : démarrer la transaction suivante
————–

BEGIN TRAN
UPDATE T
SET col = 'd'
WHERE id = 1
/*
Résultat : UPDATE mis en attente dans la session 2, le processus est bloqué !
*/

–> Comment identifier les processus bloqués sur une instance ?

SELECT session_id,start_time,wait_time,status,wait_type,command,blocking_session_id,transaction_id
FROM sys.dm_exec_requests
WHERE blocking_session_id <> 0

SELECT spid,open_tran,blocked
FROM sys.sysprocesses WHERE blocked <> 0

L’ID des sessions (session_id ou spid) responsables du blocage sont donc identifiés .

–> Comment mettre fin à ce blocage ?

Il suffit de tuer le processus responsable du blocage à l’aide la commande suivante :

KILL
Exemple
--------
KILL 54

Cette commande annule toutes les transactions liées à ce processus. Cette opération est tracé dans les fichiers de
d’erreurs SQL Server (ERRLOG) et Event Viewver Application (\WINDOWS\system32\config\AppEvent.Evt)

=> Interblocage des transactions SQL : deadlock – verrou mortel
Le phénomène d’interblocage (deadlock) se présente lorsque plusieurs processus (transactions sql) se bloquent de façon à ce qu’aucun de ces processus ne peut se débloquer quelque soit la durée d’attente.
Ceci apparaît lors de la modification des données(INSERT, UPDATE, DELETE). Dans ce cas le gestionnaire de verrou SQL Server détecte qu’il y a un deadlock et va donc tuer un des processus, annuler la totalité des
transactions sql du processus liquidé et renvoyé le code d’erreur 1205 à la session concernée.
Sur quels critères SQL Server choisit la processus à tuer ? Pour deux transactions ayant la même priorité, les règles de sélection du processus à liquider ne sont pas clairement détaillées par Microsoft .
Rappelons que l’option SET DEADLOCK_PRIORITY { LOW | NORMAL | HIGH } permet de spécifier la priorité d’une transaction en cas de deadlock.

Ouvrons une petite parenthèse : Sous ORACLE le code d’erreur des deadlocks est ORA-00060 (détection d’interblocage pendant l’attente d’une ressource) et fermons cette parenthèse

–> Mise en évidence du phénonème de verrou mortel (deadlock)
– # Cas une table : objet non distinct

Dans la session 1, démarrer la transaction suivante :

BEGIN TRAN
UPDATE T
SET col = 'c'
WHERE id = 2

/*
Résultat : UPDATE effectué dans la session 1
*/

— Dans la session 2, démarrer la transaction suivante :

BEGIN TRAN
UPDATE T
SET col = 'e'
WHERE id = 1

/*
Résultat : UPDATE en attente dans la session 2
*/

— Dans la session 1, exécuter la requête suivante :

UPDATE T
SET col = 'f'
WHERE id = 2

/*
Résultat : un message d’erreur apparaît dans la session 1.
Msg 1205, Level 13, State 45, Line 1
Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

dans la session 2, la mis à jour est réalisée

— Vérification de la modification dans la session 2
select * from T where id = 1

id col
——-
1 e

Comment résoudre ce problème dans ce cas ?

Pour contouner ce deadlock, il suffit de créer sur cette table un index du genre :
CREATE INDEX IX ON T (id) INCLUDE (col)
Et le tour est joué !

– # Cas de deux tables distinctes : objets distincts

-- Création des deux tables
IF OBJECT_ID('T1') IS NOT NULL DROP TABLE T1
IF OBJECT_ID('T2') IS NOT NULL DROP TABLE T2
CREATE TABLE T1 (id1 INT,col1 CHAR(1))
CREATE TABLE T2 (id2 INT,col2 CHAR(1))
-- insertion des données dans la table
INSERT INTO T1 (id1,col1) VALUES (1,'a')
INSERT INTO T2 (id2,col2) VALUES (2,'b')

Dans la session 1, démarrer la transaction suivante :

BEGIN TRAN
UPDATE T1
SET col1 = 'c'
WHERE id1 = 1

/*
Résultat : UPDATE effectué dans la session 1
*/

Dans la session 2, démarrer la transaction suivante :

BEGIN TRAN
UPDATE T2
SET col2 = 'd'
WHERE id2 = 2

/*
Résultat : UPDATE effectué dans la session 2
*/

Dans la session 1, exécuter la requête suivante :

UPDATE T2
SET col2 = 'e'
WHERE id2 = 2

/*
Résultat : UPDATE en attente dans la session 2
*/

Dans la session 2, exécuter la requête suivante :

UPDATE T1
SET col1 = 'f'
WHERE id1 = 1

/*
Résultat :
Msg 1205, Level 13, State 45, Line 1
Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
*/

Dans ce cas, la création des index sur les tables T1 et T2 ne permet pas de solutionner le problème. Une piste consiste à catcher l’erreur 1205 (TRY/CATCH) puis tenter de rejouer la transaction. D’autres solutions existent, mais avant de les présenter examinons d’abord comment identifier les instructions responsables du deadlock sur une instance

=> Comment identifier les instructions responsable du deadlock ?
– # Avec XEvents
Sous SQL Server 2008 et + on peut utiliser XEvents pour collecter les informations relatives aux deadlocks.
La requête ci-dessous renvoie un fichier XML montrant les requêtes responsables des deadlocks. On peut faire des filtres horodatages pour cibler les deadlocks ayant lieu à un moment donnée.

DECLARE @xml xml
SELECT @xml = CAST(st.target_data as xml)
FROM sys.dm_xe_session_targets st
INNER JOIN sys.dm_xe_sessions s on s.address = st.event_session_address
INNER JOIN sys.server_event_sessions es on s.name = es.name
WHERE s.name = 'system_health' AND st.target_name = 'ring_buffer'
-- and convert(varchar(8),s.create_time,112) = '20120422' -- cibler une date particulière
SELECT @xml.query('/RingBufferTarget/event [@name="xml_deadlock_report"]')

– # Avec la trace 1222
Activer Trace Flag 1222 option -1 :
{1222} : pour collecter toutes les informations relatives aux deadlocks.
{-1} : appliquer la collecte des traces deadlock à toutes les sessions et à tous les utilisateurs

DBCC TRACEON (1222, -1)

-- voir le status des traces
DBCC TRACESTATUS(1222,-1)

TraceFlag Status Global Session
-----------------------------------------------------
1222 ----- 1 ----- 1 ----- 0

L’activation de la trace 1222 option -1 permet de cibler le problème et d’identifier les instructions responsables de l’interblocage. Voici ce qu’on observe dans le fichier ERRORLOG après activation des traces et reproduction du premier scénario (cas d’un même objet) deadlock

————&# — Fichier de log ————&# 2012-04-22 19:43:47.15 spid56 2012-04-22 19:44:11.92 spid53 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s 2012-04-22 19:44:36.56 spid19s …………&# …………&# …………&# 8212;———————————————————————————–
emplacement : \Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Log\ERRORLOG
8212;———————————————————————————–
DBCC TRACEON 1222, server process ID (SPID) 56. This is an informational message only; no user action is required.
Starting up database ‘AdventureWorks2008R2′.
deadlock-list
deadlock victim=processd0bc78
process-list
process id=processd0bc78 taskpriority=0 logused=208 waitresource=RID: 6:1:15160:0 waittime=1429 ownerId=170698 transactionname=user_transaction lasttranstarted=2012-04-19T19:44:21.183 XDES=0x4338ac08 lockMode=U schedulerid=1 kpid=5488 status=suspended spid=56 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2012-04-19T19:44:35.137 lastbatchcompleted=2012-04-19T19:44:21.190 lastattention=2012-04-19T16:41:08.620 clientapp=Microsoft SQL Server Management Studio – Query hostname=XX-XX hostpid=4064 loginname=xx isolationlevel=read committed (2) xactid=170698 currentdb=6 lockTimeout=4294967295 clientoption1=671090784 clientoption2=390200
executionStack
frame procname=adhoc line=1 stmtstart=58 sqlhandle=0x020000003737ba3a21719d4dd9cf31b6b7211a6fb6e2e5d1
UPDATE [T] set [col] = @1 WHERE [id]=@2
frame procname=adhoc line=1 sqlhandle=0x02000000fcf4a3305a4444f97c3ec147da8f12aa2b69fcd2
UPDATE T
SET col = ‘f’
WHERE id = 2
inputbuf
8230;…………………………..
8230;…………………………..
8230;…………………………..

Dans le fichier de trace ERRLOG on identifie clairement :
* les requêtes responsables du deadlock,
* les objets concernés (nom du serveur,nom de la base,nom des tables,…)
– # Autres méthodes d’identification des deadlocks :
Mise en place des traces via SQL Server Profiler ou ajout de l’option ‘-T1222′ lors du redémarrage de l’instance SQL SERVER

=> Quelques pistes pour anticiper/gérer les deadlocks

–# Ecrire des requêtes courtes et précises sur des tables bien indexées.
–# Respecter le même ordre d’exécution des requêtes dans les transactions (voir exemple plus bas)
–# Catcher (TRY/CATCH) l’erreur 1205 puis ré-exécuter la transaction (voir exemple plus bas)
–# Utiliser si possible l’option SET DEADLOCK_PRIORITY pour générer les priorités entre les transactions en cas de deadlock

–> Exemples : Gestion des erreurs 1205 (TRY/CATCH)

– Exemple 1 : TRY/CATCH simple
———————

BEGIN TRY
/* Mettre ici les opérations à effectuer */
END TRY
BEGIN CATCH
IF ERROR_NUMBER() = 1205 RAISERROR('deadlock erreur !', 16, 1);
ELSE RAISERROR('Pas de deadlock mais une autre erreur est survenue ! ', 16, 1);
END CATCH;

– Exemple 2 : TRY/CATCH avec Re-exécution de la requête
———————

DECLARE @RetriesCounter int;
SET @RetriesCounter = 3;
WHILE @RetriesCounter > 0
BEGIN
BEGIN TRY
/* Mettre ici les opérations à effectuer */
END TRY
BEGIN CATCH
IF ERROR_NUMBER() = 1205
BEGIN
SET @RetriesCounter = @RetriesCounter - 1;
IF @RetriesCounter = 0 RAISERROR('Impossible de terminer la transaction !', 16, 1);
END
ELSE
RAISERROR('Pas de deadlock mais autre erreur ! ', 16, 1);
END CATCH
END;

–> Exemple : Respecter le même ordre d’exécution des transactions

IF OBJECT_ID('T1') IS NOT NULL DROP TABLE T1
IF OBJECT_ID('T2') IS NOT NULL DROP TABLE T2
CREATE TABLE T1 (id1 INT,col1 CHAR(1))
CREATE TABLE T2 (id2 INT,col2 CHAR(1))
-- insertion des données dans la table
INSERT INTO T1 (id1,col1) VALUES (1,'a')
INSERT INTO T2 (id2,col2) VALUES (2,'b')

exécuter dans la session 1

BEGIN TRAN
UPDATE t1 SET col1 = 'x'
WAITFOR DELAY '00:00:05'
UPDATE t2 SET col2 = 'y'
ROLLBACK TRAN

exécuter dans la session 2

BEGIN TRAN
UPDATE t2 SET col2 = 'y'
WAITFOR DELAY '00:00:05'
UPDATE t1 SET col1 = 'x'
ROLLBACK TRAN

/* Résultat :
(1 row(s) affected)
Msg 1205, Level 13, State 45, Line 6
Transaction (Process ID 55) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
*/

–> Solution : Exécution des requêtes dans le même ordre

exécuter dans la session 1

BEGIN TRAN
UPDATE t1 SET col1 = 'x'
WAITFOR DELAY '00:00:05'
UPDATE t2 SET col2 = 'y'
ROLLBACK TRAN

exécuter dans la session 2

BEGIN TRAN
UPDATE t1 SET col1 = 'x'
WAITFOR DELAY '00:00:05'
UPDATE t2 SET col2 = 'y'
ROLLBACK TRAN

/* Résultat : Opération effectuée avec succès */

Il y a encore des choses à dire sur les deadlocks. Mais l’idée c’est d’avoir ici une petite synthèse
du phénomène et d’essayer de présenter quelques pistes pour gérer au mieux les blocages et interblocages

——————————————-
Etienne ZINZINDOHOUE
——————————————-

TRANSACTION SQL : mode d’accès – niveau d’isolation – niveau de diagnostic

zinzineti — Wed, 11 Apr 2012 18:17:15 +0000

Une transaction SQL est caractérisée par un mode d’accès (READ ONLY ou READ WRITE),un niveau d’isolation (READ UNCOMMITED,READ COMMITED,REPEATABLE READ,SERIALIZABLE) et un niveau de diagnostic (DIAGNOSTIC SIZE).Le mode d’accès permet de préciser explicitement les opérations (lecture seule ou lecture/écriture) à réaliser sur la transaction. Le niveau d’isolation permet d’indiquer avec quel acharnement on souhaite protéger les transactions les unes des autres. Le niveau de diagnostic permet de limiter le nombre d’ereur dans la transaction. Selon la norme SQL une transaction doit être paramétrée de la façon suivante :

SET [LOCAL] TRANSACTION [READ ONLY | READ WRITE]
[ISOLATION LEVEL {READ COMMITTED | READ UNCOMMITTED |
REPEATABLE READ | SERIALIZABLE}]
[DIAGNOSTIC SIZE int]

LOCAL : indique que le mode d’accès et le niveau d’isolation indiqué s’applique à la session courante. si le mot clé LOCAL n’est pas indiqué la transaction suivante peut changer même si on est sur la même session
READ ONLY : indique que la transaction est une opération de lecture seule
READ WRITE : indique que la transaction peut lire ou modifier des données dans la base
ISOLATION LEVEL : indique le niveau de protection des transactions
DIAGNOSTIC SIZE int : limite le nombre d’erreur dans la transaction. plus ce nombre est élévé plus il y a consommation de ressources système. la commande GET DIAGNOSTICS permet de recupérer les messages d’erreurs.

SQL SERVER ne respecte pas rigoureusement cette syntaxe. Il est impossible sous SQL SERVER de préciser de façon explicite le :
1) mode d’accès (READ_ONLY ou READ_WRITE)
2) niveau de DIAGNOSTIC

Seul le niveau d’isolation peut être explicitement indiqué sous SQL SERVER. Rappelons que les niveaux d’isolation permettent de resoudre les problèmes de lecture sale (dirty read), lecture qui ne peut être répétée (non-repeatable read) et de lecture fantôme (phantom read). Dans ce billet nous allons examiner ces problèmes et mettre en évidence le mécanisme de verrou (lock) posé par SQL SERVER sur une table.

Une fois les deux fenêtre ouvertes, clique droit sur l’onglet

Choisir l’affichage verticale des sessions

Voyons maintenant les différents niveaux d’isolation.

=> READ COMMITED (c’est niveau d’isolation par défaut sous SQL SERVER) : isole la transaction des problèmes de lecture sale

–> Session 1 : dans la session 1, exécuter la requête de création et de remplissage de la table
————–

-- Création de la table
IF OBJECT_ID('ExpertSGBD') IS NOT NULL DROP TABLE ExpertSGBD
CREATE TABLE ExpertSGBD (id int,prenom varchar(20),nbpoints int,date_inscription datetime)
-- insertion des données dans la table
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (1,'Frédéric',17581,'20020501')
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (2,'David',6704,'20020801')
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (3,'Nicolas',8488,'20050101')
-- vérification des données insérées
SELECT * FROM ExpertSGBD

--Démarrer dans la session 1 la transaction suivante :
BEGIN TRAN
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (4,'Etienne',2408,'20100301')
-- Vérifier l'insertion de la nouvelle ligne dans la session 1, remarquer que jusque là on n'a pas encore COMMITé ni ROLLBACKé la transaction
SELECT * FROM ExpertSGBD

–> Session 2 : dans la session 2, exécuter la requête suivante :
————-
SELECT * FROM ExpertSGBD

# Résultat session 2 : La requête ne s’exécute pas, elle reste bloquée.
## Explication : La transaction en cours d’exécution dans la session 1 fait que SQL Server a posé un verrou (LOCK) sur la table, il est donc impossible à d’autre session de lire les données de la table

–> Session 1 : Revenons dans la session 1 et validons la transaction en cours avec un COMMIT
————–
COMMIT TRANSACTION

–> Session 2 : Dans la fenêtre de la session 2, exécutons la requête suivante :
————–
SELECT * FROM ExpertSGBD

# Résultat session 2 : La requête s’exécute correctement et la nouvelle ligne apparaît après COMMIT (validation) dans la session 1
## Explication : après validation (COMMIT) de la transaction dans la session 1, le verrou posé par SQL SERVER sur la table est lévé et les données ainsi validées sont accessibles à toutes les sessions

Mais comment éviter le verrou sur la totalité des lignes de la TABLE et permettre l’accessibilité des données initiales validées avant le démarrage de la transaction ?

## Astuce : faire en sorte que SQL Server utilise par exemple un index et pas un Table Scan lors de la lecture des données.

Exemple
——–

–> Session 1 : dans la session 1, exécuter la requête de création et de remplissage de la table
————–

IF OBJECT_ID('ExpertSGBD') IS NOT NULL DROP TABLE ExpertSGBD
CREATE TABLE ExpertSGBD (id int,prenom varchar(20),nbpoints int,date_inscription datetime)
-- insertion des données dans la table
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (1,'Frédéric',17581,'20020501')
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (2,'David',6704,'20020801')
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (3,'Nicolas',8488,'20050101')
-- posons un index sur la table
CREATE INDEX IX ON ExpertSGBD (id,prenom,nbpoints,date_inscription)

–> Session 1 : Démarrer depuis la session 1 la transaction suivante :
————–

BEGIN TRAN
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (4,'Etienne',2408,'20100301')

-- Vérifier l'insertion de la nouvelle ligne depuis la session 1, remarquer que jusque là on n'a pas encore COMMITé ni ROLLBACKé la transaction
SELECT * FROM ExpertSGBD

–> Session 2 : Dans la fenêtre de la session 2, exécuter la requête suivante
————–

SELECT * FROM ExpertSGBD WHERE ID < 4

# Résultat session 2 : Cette fois-ci la requête s’exécute. Les données présentes dans la table avant le début de transaction sont affichées.
## Explication : SQL Server utilise l’index créé (INDEX SEEK) pour parcourir la table. une analyse du plan d’exécution de la requête le montre. Par contre la nouvelle ligne insérée (non COMMITée) visible depuis la session 1 n’est pas visible par la session 2 car l’exécution de la requête SELECT * FROM ExpertSGBD WHERE ID < 5 bloque.

–> Session 1 : Faire un COMMIT TRANSACTION pour valider la transaction
————–
COMMIT TRANSACTION

Quelles sont les limites du niveau d’isolation READ COMMITED ?

READ COMMITED ne protège pas de la lecture non répétable, c’est quoi la lecture non répétable ? Pour une même requête, les données affichées variées. Prenons un exemple :

Exemple
——–

–> Session 1 : Exécuter la requête de création et de remplissage de la table
————–
— table

— Exécutons dans la session 1 la requête suivante :
SELECT * FROM ExpertSGBD WHERE nbpoints > 17580 -- on a 1 ligne qui s'affiche

# Résultat session 1 : On a 1 ligne affichée

–> Session 2 : Depuis la session 2 exécuter une requête de mise à jour :
————–

UPDATE ExpertSGBD
SET nbpoints = 17580
WHERE id = 1

# Résultat session 2 : Update effectué avec succès

–> Session 1 : Rejouons à nouveau la même requête SELECT que précedemment
————–
SELECT * FROM ExpertSGBD WHERE nbpoints > 17580 -- on a 0 ligne qui s'affiche

# Résultat session 1 : Cette fois-ci on a 0 ligne ! la requête SELECT * FROM ExpertSGBD WHERE nbpoints > 17580 n’est donc pas repetable sous la session 1 un coup on a 1 ligne et un autre coup on a 0 ligne ! Voilà un des problèmes du niveau d’isolation READ COMMITED

=> REPEATABLE READ : protège la transaction des problèmes de lecture sale et lecture qui ne peut être répétée

— Session 1 : Exécuter la requête de création et de remplissage de la table
————–
— Création de la table

–> Session 1 : Démarrer depuis la session 1 la transaction suivante :
————–

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
SELECT * FROM ExpertSGBD WHERE nbpoints > 17580 -- on a une ligne qui qui s'affiche

–> Session 2 : Depuis la session 2, mettons à jour une ligne de la table à l’aide de la requête suivante :
————–

UPDATE ExpertSGBD
SET nbpoints = 17580
WHERE id = 1

# Résultat session 2 : Impossible de mettre à jour la ligne, LOCK de la Table

–> Session 1 : Rejouons à nouveau dans la session 1 la requête suivante :
————–
SELECT * FROM ExpertSGBD WHERE nbpoints > 17580 -- on a une ligne qui s'affiche

# Résultat session 1 : On a toujours une ligne affichée, la requête renvoie toujours les mêmes données.
## Explication : SQL SERVER a posé un verrou sur les lignes en cours de lecture, ainsi aucune modification de ces lignes n’est possible par une autre session. Le problème de lecture qui ne peut être répétée est ainsi résolu avec le niveau d’isolation REPEATABLE READ

–> Session 1 : Dans la session 1 faisons un COMMIT pour valider la transaction
————–
COMMIT TRANSACTION

Quelles sont les limites du niveau d’isolation REPEATABLE READ ? REPEATABLE READ resoud le problème de lecture qui ne peut être répétée, mais pas le problème de lecture fantôme. Prenons un exemple.

Exemple
————–

–> Session 1 : Exécuter la requête de création et de remplissage de la table
————–
— Création de la table

–> Session 1 : Démarrer depuis la session 1 la transaction suivante :
————–

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ
BEGIN TRAN
SELECT * FROM ExpertSGBD -- on a 3 lignes qui qui s'affiche

–> Session 2 : Depuis la session 2, insérons une nouvelle à l’aide de la requête suivante :
————–
INSERT INTO ExpertSGBD (id,prenom,nbpoints,date_inscription) VALUES (4,'Etienne',2408,'20100301')

# Résultat session 2 : insertion effectuée avec succès depuis la session 2

–> Session 1 : Rejouons dans la session 1, la requête SELECT * FROM ExpertSGBD
————–
SELECT * FROM ExpertSGBD -- on a 4 lignes qui s'affiche

# Résultat session 1 : Cette fois-ci on a 4 lignes ! une ligne fantôme apparaît ! le niveau d’isolation REPEATABLE READ ne resoud pas ce problème de ligne fantôme.

–> Session 1 : Validons la transaction (COMMIT)
————–
COMMIT TRANSACTION

=> SERIALIZABLE : protège la transaction des problèmes de lecture sale, de lecture qui ne peut être répétée et de lecture fantôme

–> Session 1 : Exécuter la requête de création et de remplissage de la table
————–

–> Session 1 : Démarrer depuis la session 1 la transaction suivante :
————–

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRAN
SELECT * FROM ExpertSGBD -- on a 3 lignes qui qui s'affiche

# Résultat session 2 : Impossible de faire l’INSERT ! depuis la session 2

–> Session 2 : depuis la session 2, essayer un UDPATE
————–

UPDATE ExpertSGBD
SET nbpoints = 17580
WHERE id = 1

# Résultat session 2 : Impossible de faire un UPDATE sur la table !

–> Session 1 : Rejouons dans la session 1, la requête SELECT * FROM ExpertSGBD
————–
SELECT * FROM ExpertSGBD

# Résultat session 1 : On a toujours les mêmes données que précédemment : pas de lecture sale, pas de lecture qui ne peut être répétée, pas de lecture fantôme

–> Session 1 : Validons la transaction (COMMIT)
————–
COMMIT TRANSACTION

=> READ UNCOMMITED
Le niveau d’isolation READ UNCOMMITED est le niveau de protection le plus bas. READ UNCOMMITED n’assure aucune protection. Ne résoud donc aucun des problèmes d’intégrité de données : lecture sale, lecture non repetatable,lecture fantôme. Il existe plusieurs possibilités pour positionner une transaction sur ce niveau d’isolation :

Exemple 1 : SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
————–

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
BEGIN TRAN
SELECT * FROM ExpertSGBD
COMMIT TRANSACTION

Exemple 2 : Utilisation dans la requête du mot clé (HINT) READUNCOMMITTED
————–
SELECT * FROM ExpertSGBD WITH (READUNCOMMITTED)

Exemple 3 : Utilisation dans la requête du mot clé NOCLOCK
————–
SELECT * FROM ExpertSGBD WITH (NOCLOCK)

——————xxx——————

On peut conclure, au travers de ces scénarii que le niveau SERIALIZABLE assure une parfaite protection (isolation) des transactions et donc l’intégrité des données. Les transactions sont dans ce cas traitées en série au sein du SGBD. Ce mécanisme de traitement en série des transactions SQL peut nuire au performance. Et c’est ce niveau SERIALIZABLE que la norme SQL propose comme niveau par défaut pour les SGBDs. À mon humble avis lors du développement des procédures SQL pour les applications il faut essayer de trouver l’équilibre entre performance (niveau d’isolation faible, donc pas de traitement en série) et intégrité (niveau d’isolation élevé) de données.

—————————–
Etienne ZINZINDOHOUE
—————————–

AUTOCOMMIT ou COMMIT IMPLICITE : quelle confusion ?

zinzineti — Thu, 05 Apr 2012 16:47:40 +0000

La norme SQL standard (ANSI/ISO) affirme que :
1. la première instruction SQL lancée depuis une session est considérée comme le début d’une transaction (même si le verbe BEGIN TRANSACTION n’est pas indiqué).
2. la fin de toute transaction DOIT se terminer de façon EXPLICITE par un ROLLBACK ou un COMMIT.
C’est ce que dit la norme SQL à propos de la notion de début et fin d’une transaction SQL.
Rappelons qu’une transaction SQL est une entité logique comportant une ou plusieurs instruction SQL.
Par défaut SQL SERVER considère chaque instruction comme une transaction et fait des COMMITs implicites après chaque exécution : c’est l’AUTOCOMMIT.
Par défaut ORACLE fait des commit implicites à la fin de chaque instruction DDL (CREATE, ALTER, DROP). Notons que sur ce point ORACLE est plus proche de la norme que SQL SERVER.
Ce que je ne comprends pas c’est la confusion que crée MS SQL SERVER autour de la définition de l’option AUTOCOMMIT. De quoi s’agit-il exactement ?
D’après la documentation officielle de MS SQL SERVER :
Version originale
——————

SET IMPLICIT_TRANSACTIONS { ON | OFF }
Sets implicit transaction mode for the connection.
When ON, SET IMPLICIT_TRANSACTIONS sets the connection into implicit transaction mode.
When OFF, it returns the connection to autocommit transaction mode.

Traduction en français
———————–

SET IMPLICIT_TRANSACTIONS { ON | OFF }
Définit le mode de transaction implicite pour la connexion.
Si sa valeur est ON, SET IMPLICIT_TRANSACTIONS met la connexion en mode de transaction implicite.
Si la valeur est OFF, la connexion est remise en mode de validation automatique.

D’après ce qui est écrit dans la documentation officielle :
SET IMPLICIT_TRANSACTIONS OFF = AUTOCOMMIT (validation automatique).
Mais le problème c’est que si IMPLICIT_…. est OFF on peut penser qu’on est en mode EXPLICIT_… et en EXPLICIT_… ce n’est plus de l’AUTOCOMMIT !

=> Sous SQL SERVER
D’abord comment identifier l’option SET IMPLICIT_TRANSACTIONS de ma session ?

SELECT CASE WHEN (@@OPTIONS & 2 = 2) THEN 'IMPLICIT_TRANSACTIONS ON'
ELSE 'IMPLICIT_TRANSACTIONS OFF'
END 'IMPLICIT_TRANSACTIONS'

Exemple avec SET IMPLICIT_TRANSACTIONS OFF
———————————————
Session 1
———

IF OBJECT_ID(N't1', N'U') IS NOT NULL DROP TABLE t1;
SET IMPLICIT_TRANSACTIONS OFF
CREATE TABLE t1(c INT);
INSERT INTO t1 VALUES (1);

Session 2
———
SELECT * FROM t1

La session 2 affiche bien les données de la table t1

Exemple avec SET IMPLICIT_TRANSACTIONS ON
———————————————
Session 1
———

IF OBJECT_ID(N't1', N'U') IS NOT NULL DROP TABLE t1;
SET IMPLICIT_TRANSACTIONS ON
CREATE TABLE t1(c INT);
INSERT INTO t1 VALUES (1);

Session 2
———
SELECT * FROM t1

Impossible de lire les données de la table t1 depuis la session 2, puisque la transaction n’est pas encore validée (commit) par la session 1

=> Sous ORACLE
D’abord comment identifier l’option AUTOCOMMIT de ma session ?

SQL> SHOW AUTOCOMMIT;

Exemple avec AUTOCOMMIT ON
———————————————
Session 1
———

SET AUTOCOMMIT ON
CREATE TABLE t1(c INT);
INSERT INTO t1 VALUES (1);

Session 2
———
SELECT * FROM t1
La session 2 affiche bien les données de la table t1

Exemple avec AUTOCOMMIT OFF
———————————————
Session 1
———

SET AUTOCOMMIT OFF
CREATE TABLE t1(c INT);
INSERT INTO t1 VALUES (1);

Session 2
———
SELECT * FROM t1
Impossible de lire les données de la table t1 depuis la session 2, puisque la transaction n’est pas encore validée (commit) par la session 1

Pour conclure notons que pour MS SQL SERVER SET IMPLICIT_TRANSACTIONS OFF = AUTOCOMMIT. À mon humble avis, MS SQL SERVER devrait plutôt mettre SET IMPLICIT_TRANSACTIONS ON = AUTOCOMMIT

——————————
Etienne ZINZINDOHOUE
——————————

SAVEPOINT vs SAVE TRANSACTION

zinzineti — Fri, 23 Mar 2012 17:20:16 +0000

La norme SQL propose un moyen de poser des points de restaurations dans une transaction : les SAVEPOINTs. L’idée c’est de pouvoir revenir à une étape donnée dans la transaction. Selon la norme SQL la synthaxe pour créer un SAVEPOINT est la suivante :SAVEPOINT savepoint_name et pour revenir en arrière :ROLLBACK TO SAVEPOINT savepoint_name . La commande SAVEPOINT n’existe pas sous MS SQL SERVER mais une commande similaire exite : SAVE { TRAN | TRANSACTION } { savepoint_name | @savepoint_variable } et pour revenir en arrière : ROLLBACK { TRAN | TRANSACTION } [ transaction_name | @tran_name_variable | savepoint_name | @savepoint_variable ]

La norme SQL:2003 introduit la commande RELEASE SAVEPOINT savepoint_name qui permet de détruire un savepoint. Son équivalent SQL SERVER n’existe pas. MS SQL SERVER supprime les points de restauration automatiquement à la fin des transaction (COMMIT ou ROLLACK)

=> SAVEPOINT /ROLLBACK TO SAVEPOINT

–> Avec PostgreSQL

BEGIN;
INSERT INTO table1 VALUES ('1');
SAVEPOINT savepoint1; -- création du savepoint1
INSERT INTO table1 VALUES ('2');
SAVEPOINT savepoint2; -- création du savepoint2
INSERT INTO table1 VALUES ('3');
ROLLBACK TO SAVEPOINT savepoint1; -- ROLLBACK TO savepoint1
COMMIT;

SELECT * FROM table1;

/*** résultat ***/

col
---
1

—> Avec MS SQL SERVER

DROP TABLE table1;
CREATE TABLE table1 (col CHAR(1));
BEGIN TRAN Transaction_Principale
INSERT INTO table1 VALUES ('1')
SAVE TRAN savepoint1 -- création du savepoint1
BEGIN TRAN Transaction_Imbriquée
INSERT INTO table1 VALUES ('2')
SAVE TRAN savepoint2 -- création du savepoint2
INSERT INTO table1 VALUES ('3');
ROLLBACK TRAN savepoint1 -- ROLLBACK TO savepoint1
COMMIT ;

SELECT * FROM table1

/*** résultat ***/

col
---
1

=> SAVEPOINTS avec les mêmes noms
La norme SQL stipule que lorsqu’on crée un savepoint avec le même nom qu’un autre savepoint existant alors ce dernier doit être automatiquement détruit. le plus récent savepoint remplace donc l’ancien ayant le même nom.

–> Avec PostgreSQL

DROP TABLE table1;
CREATE TABLE table1 (col CHAR(1));
BEGIN;
INSERT INTO table1 VALUES ('1');
SAVEPOINT savepoint1;
INSERT INTO table1 VALUES ('2');
SAVEPOINT savepoint1;
INSERT INTO table1 VALUES ('3');
ROLLBACK TO SAVEPOINT savepoint1;
COMMIT;

SELECT * FROM table1;

/*** résultat ***/

col
---
1
2

–> Avec MS SQL SERVER

DROP TABLE table1;
CREATE TABLE table1 (col CHAR(1));
BEGIN TRAN Transaction_Principale
INSERT INTO table1 VALUES ('1')
SAVE TRAN savepoint1 -- création du savepoint1
BEGIN TRAN Transaction_Imbriquée
INSERT INTO table1 VALUES ('2')
SAVE TRAN savepoint1 -- création du savepoint2
INSERT INTO table1 VALUES ('3')
ROLLBACK TRAN savepoint1 -- ROLLBACK TO savepoint1
COMMIT ;

SELECT * FROM table1

/*** résultat ***/

col
---
1
2

=> RELEASE SAVEPOINT

–> Avec PostgreSQL

DROP TABLE table1;
CREATE TABLE table1 (col CHAR(1));
BEGIN;
INSERT INTO table1 VALUES ('1');
SAVEPOINT savepoint1;
INSERT INTO table1 VALUES ('2');
SAVEPOINT savepoint2;
INSERT INTO table1 VALUES ('3');
RELEASE SAVEPOINT savepoint1;
COMMIT;

SELECT * FROM table1;

/*** résultat ***/

col
---
1
2
3

–> Avec MS SQL SERVER

DELETE FROM table1
BEGIN TRAN Transaction_Principale
INSERT INTO table1 VALUES ('1')
SAVE TRAN savepoint1 -- création du savepoint1
BEGIN TRAN Transaction_Imbriquée
INSERT INTO table1 VALUES ('2')
SAVE TRAN savepoint2 -- création du savepoint2
INSERT INTO table1 VALUES ('3')
COMMIT TRAN savepoint1 -- ROLLBACK TO savepoint1
COMMIT ;

SELECT * FROM table1

/*** résultat ***/

col
---
1
2
3

Comme MS SQL SERVER, ORACLE ne supporte pas non plus la commande standard RELEASE SAVEPOINT. Notons que parmi les SGBDs les plus connus du marché, MS SQL SERVER est le seul à ne pas implémenter la commande SAVEPOINT savepoint_name. IBM DB2, ORACLE, PostGreSQL et « MySQL » ont tous implémenté la commande SAVEPOINT.

———————–
Etienne ZINZINDOHOUE
———————–

Modeles de licences pour SQL SERVER 2012

zinzineti — Sat, 17 Mar 2012 09:01:38 +0000

–> Vidéo 5 minutes pour comprendre les modèles de licences pour SQL SERVER 2012

–> PDF Modèles de licences pour SQL SERVER 2012

Curseurs ouverts

zinzineti — Mon, 12 Mar 2012 19:51:57 +0000

Les curseurs font partie intégrante de la norme SQL. Ils sont utilisés dans les SGBDRs pour réaliser des traitements ligne par ligne. Le temps de traitement des transactions SQL utilisant des curseurs dépend du SGBDR, de la qualité/quantité des données traitées, de l’écriture de la transaction SQL contenant le curseur, ….
Un curseur utilisé et qui n’est pas fermé (ne se termine pas par CLOSE nomCurseur et DEALLOCATE nomCurseur) aura des incidences sur la performance du serveur de base de données.

=> Liste des curseurs ouverts pour toutes les sessions

SELECT c.session_id
,s.login_name
,s.host_name
,s.program_name
,c.creation_time
,c.name
,c.is_open
,c.is_close_on_commit
,c.worker_time
,c.dormant_duration
,t.text as sql_text
FROM sys.dm_exec_cursors(0)as c
INNER JOIN sys.dm_exec_sessions as s ON c.session_id = s.session_id
CROSS APPLY sys.dm_exec_sql_text(c.sql_handle) t

=> Pour fermer les curseurs : Solution brutale
KILL c.session_id
Exemple
——–
KILL 52

=> Pour fermer les curseurs : Solution durable

Ajouter CLOSE nomCurseur et DEALLOCATE nomCurseur dans les procédures concernées

L’option CURSOR_CLOSE_ON_COMMIT (pour la session ou pour la base de donnée) est sensée résoudre ce genre de problème selon les recommandations de la norme ISO, mais la réalité est tout autre.

——————–
Etienne ZINZINDOHOUE

FOREIGN KEYs non indexés

zinzineti — Mon, 12 Mar 2012 18:33:57 +0000

Il est souvent recommandé d’indexer les clés étrangères (FK). Cette opération d’indexation ne doit pas se faire de façon mécanique. Elle devrait passer par les phases d’analyse, de création et de test. Mais avant comment identifier les FKs non indexés ?

SELECT a.TABLE_SCHEMA,a.TABLE_NAME, b.COLUMN_NAME, b.CONSTRAINT_NAME,a.IS_DEFERRABLE,a.INITIALLY_DEFERRED
FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS a
INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE b ON a.CONSTRAINT_NAME = b.CONSTRAINT_NAME
WHERE a.CONSTRAINT_TYPE = 'FOREIGN KEY'
--AND a.TABLE_NAME = 'Commandes' /* pour une table specifique */
AND a.TABLE_NAME + '.' + b.COLUMN_NAME NOT IN (
SELECT o.name +'.'+c.name
FROM sys.objects o
INNER JOIN sys.indexes i ON i.object_id = o.object_id
INNER JOIN sys.columns c ON o.object_id = c.object_id
INNER JOIN sys.index_columns ic ON ic.object_id = o.object_id AND i.index_id = ic.index_id AND ic.column_id = c.column_id
WHERE o.type in ('U')
)

——————-
Etienne ZINZINDOHOUE