T-SQL

Re: SQL 2000 - SNAPSHOT ISOLATION

xmldeveloper — Sat, 12 Dec 2009 12:09:04 GMT

SQL Server 2000 aborda varianta pesimista pentru tratarea tranzactiilor.
Introducerea nivelului de izolare snapshot inseamna de fapt folosirea versiunilor de rand (o abordare optimista) si tratarea potentialelor conflicte in cazul modificarilor.
Evident chiar si in SQL Server 2000 se pot genera versiuni de rand folosind un mecanism custom (similare celui prezentat de Bogdan) sau folosind bazati pe triiggers.

Re: SQL 2000 - SNAPSHOT ISOLATION

B_gd_n[ ]Sahlean — Mon, 07 Dec 2009 12:41:32 GMT

Dacă este ... să o luăm aşa ... atunci chiar şi dialectul SQL din Access 2000 are nişte chestii faine care lipsesc din T-SQL 2000 iar Cascade Update/Delete era în Access încă de pe vremea lu' SQL Server 7.

Re: SQL 2000 - SNAPSHOT ISOLATION

neagu_laurentiu — Mon, 07 Dec 2009 12:18:26 GMT

Multumesc pt. raspuns.
Nu pot sa implementez eu povestea fiindca aplicatia e deja functionala.
Voiam sa stiu daca nu mi-a scapat ceva din lectura documentatiei pt. 2000, ca sa pot seta ceva si sistemul sa faca asta (precum in 2005(8)).
Totusi mi se pare ciudat ca nu au implementat versionarea in 2000 ! Pana si VFoxPro are asa ceva...

Re: SQL 2000 - SNAPSHOT ISOLATION

B_gd_n[ ]Sahlean — Sun, 06 Dec 2009 14:12:43 GMT

ALLOW_SNAPSHOT_ISOLATION a fost introdus începând cu SQL 2005.

Totuşi dacă BD este SQL2005(2008 ?) şi setezi nivelul de compatibilitate la SQL2000 poţi utiliza acest nivel de izolare a tranzacţiilor. Citeşte şi comentariile.

A doua opţiune ar fi să implementezi chiar tu acest nivel de izolare.
O posibilă soluţie în acest sens ar putea fi (scripturile 2 şi 3 tb. rulate în ferestre separate SSMS/"în paralel"):
Script T-SQL 1
IF OBJECT_ID('Marbles') IS NOT NULL
  DROP TABLE Marbles;
GO

CREATE TABLE Marbles
(
ID INT PRIMARY KEY,
Color VARCHAR(10) NOT NULL
);
GO

INSERT INTO Marbles VALUES (1, 'Black');
INSERT INTO Marbles VALUES (2, 'White');
GO

SELECT * FROM Marbles

Script T-SQL 2
BEGIN TRAN
  DECLARE @temp TABLE (ID INT PRIMARY KEY, Color VARCHAR(10) NOT NULL)
  INSERT INTO @temp
  SELECT *
  FROM Marbles
  WHERE Color = 'Black'


  WAITFOR DELAY '00:00:10'
  UPDATE @temp SET Color = 'White'
  UPDATE Marbles SET Color = TMP.Color FROM @temp AS TMP WHERE Marbles.ID = TMP.ID
COMMIT TRAN
PRINT 'Finish T1'

SELECT * FROM Marbles

Script T-SQL 3
BEGIN TRAN
  DECLARE @temp TABLE (ID INT PRIMARY KEY, Color VARCHAR(10) NOT NULL)
  INSERT INTO @temp
  SELECT *
  FROM Marbles
  WHERE Color = 'White'


  WAITFOR DELAY '00:00:20'
  UPDATE @temp SET Color = 'Black'
  UPDATE Marbles SET Color = TMP.Color FROM @temp AS TMP WHERE Marbles.ID = TMP.ID
COMMIT TRAN
PRINT 'Finish T2'

SELECT * FROM Marbles

Iniţial am:
ID    Color
1    Black
2    White

Rezultatul este:
ID    Color
1    White
2    Black

şi NU
1    White
2    White
sau
1    Black
2    Black

După cum se observă, ideea este ca la începutul fiecărei tranzacţii se încarcă înregistrările într-un cache (@temp) şi toate modificările care le realizăm, nu se fac direct pe tabela Marbles ci în cache. La finalul tranzacţiei actualizez tabela Marbles cu modificările din cache-ul fiecărei tranzacţii folosind valorile din cheia primară.

Soluţia aceasta nu este 100% . Dacă cea de-a doua tranzacţie citeşte (INSERT ... SELECT) date din Marbles între ultimul UPDATE şi COMMIT de la prima tranzacţie:
  UPDATE Marbles SET Color = TMP.Color FROM @temp AS TMP WHERE Marbles.ID = TMP.ID
  --- aici T2 citeste datele cu INSERT ... SELECT ... ---
COMMIT TRAN
atunci vei avea o problemă.

PS: Alte informaţii utile pot fi găsite aici.

SQL 2000 - SNAPSHOT ISOLATION

neagu_laurentiu — Sat, 05 Dec 2009 23:36:01 GMT

In SQL Server 2000 pot avea un fel de ALLOW_SNAPSHOT_ISOLATION ?
Daca o tranzactie a unui user incepe sa modifice anumite randuri dintr-o tabela, ceilalti useri sa nu astepte terminarea tranzactiei ci sa citeasca valoarea dinaintea respectivei tranzactii (READPAST sare peste row-urile blocate iar READ UNCOMMITTED nici nu poate intra in calcul)...