---

Vi har fået nogle problemer med deadlocks i vores system. Vores SQL-server
kaldes fra et .Net-lag, og sekvensen er som følger:

Opret transaktionsobject i .Net
for hver tabel i en liste (fx 11 tabeller)
DELETE FROM Table WHERE SomeID IN (x,y) // SomeID er fremmednøgle
// slut FOR

for hver tabel i en liste (samme liste som før, blot i modsat rækkefølge)
BULK INSERT MyTable ..
// slut FOR

transaktionsobject.Commit();

Vi modtager data fra et eksternt system en gang om ugen. Det eksterne
system kan ikke give os delta-data (altså kun nye data), men de sender hele
deres datagrundlag til os. Derfor sletter vi tilsvarende alle vores data og
indsætter dem igen.

Problemet opstår ved BULK indsættelse, men det sker sjovt nok ikke altid,
at der kommer en deadlock. Databasen er for resten af systemet offline, så
der "sker" ikke andet på tabellerne end denne indsættelse.
Transaktionsobjektet sendes via .Net-kode til SQL-server, så det er muligt
at rulle tilbage, hvis der sker en fejl.

Vi er lidt på herrens mark mht hvad vi skal gøre for at løse dette problem
- er der nogen af jer, der har været ude for det samme?

mvh,



--
Jesper Stocholm
http://stocholm.dk
<a href="http://www.sony.com">evil
Findes din kiosk på nettet? Se http://ekiosk.dk

---

Jesper Stocholm wrote:
> Vi har fået nogle problemer med deadlocks i vores system. Vores SQL-server
> kaldes fra et .Net-lag, og sekvensen er som følger:
>
> Opret transaktionsobject i .Net
> for hver tabel i en liste (fx 11 tabeller)
> DELETE FROM Table WHERE SomeID IN (x,y) // SomeID er fremmednøgle
> // slut FOR
>
> for hver tabel i en liste (samme liste som før, blot i modsat rækkefølge)
> BULK INSERT MyTable ..
> // slut FOR
>
> transaktionsobject.Commit();
>
> Vi modtager data fra et eksternt system en gang om ugen. Det eksterne
> system kan ikke give os delta-data (altså kun nye data), men de sender hele
> deres datagrundlag til os. Derfor sletter vi tilsvarende alle vores data og
> indsætter dem igen.
>
> Problemet opstår ved BULK indsættelse, men det sker sjovt nok ikke altid,
> at der kommer en deadlock. Databasen er for resten af systemet offline, så
> der "sker" ikke andet på tabellerne end denne indsættelse.
> Transaktionsobjektet sendes via .Net-kode til SQL-server, så det er muligt
> at rulle tilbage, hvis der sker en fejl.
>
Jeg vil formode at din deadlock opstår pga constraints mellem
tabeller?

Vi har lidt ala det samme scenarie hvor vi replikerer "kontrol/opslags"
data fra et ERP system til en lokal transactions database

I tidligere versioner blev data lagt i en ny "midlertidig" fysisk tabel
i den lokale database
Efter at data er lagt ind bliver den rigtige tabel slettet og den nye
tabel bliver omdøbt
(I dag replikerer vi kun ændringerne)

En anden mulighed er at bruge
DELETE FROM LiveTable WHERE ...
INSERT INTO LiveTable FROM NewDataTable

Generelt er en transaction der kører i længere tid en skidt ide (men
kan være nødvendig)

Ved ikke om det kan bruges :)

- Peter

---

"Peter Lykkegaard" <peter.aghl@gmail.com> wrote in
news:1132133134.048323.141760@f14g2000cwb.googlegroups.com:

> Jesper Stocholm wrote:
>> Vi har fået nogle problemer med deadlocks i vores system.
> Jeg vil formode at din deadlock opstår pga constraints mellem
> tabeller?

Det ved jeg ikke - men det er da et godt bud.

> Vi har lidt ala det samme scenarie hvor vi replikerer
> "kontrol/opslags" data fra et ERP system til en lokal transactions
> database
>
> I tidligere versioner blev data lagt i en ny "midlertidig" fysisk
> tabel i den lokale database
> Efter at data er lagt ind bliver den rigtige tabel slettet og den nye
> tabel bliver omdøbt
> (I dag replikerer vi kun ændringerne)

Ok - det overvejer jeg lige.

> En anden mulighed er at bruge
> DELETE FROM LiveTable WHERE ...
> INSERT INTO LiveTable FROM NewDataTable

Men pga constraints kan dette ikke lade sig gøre. En af vores constraints
er, at en fremmednøgle skal eksistere i den linkede tabel. Derfor sletter
vi "nedefra" i relationstræet og indsætter fra oven. Hvis vi gør det
omvendt, så kan vi komme i konflikt med constraints. Derfor er vi reelt
nødt til at "slette færdigt" i alle tabeller før vi indsætter i dem igen.

> Generelt er en transaction der kører i længere tid en skidt ide (men
> kan være nødvendig)

Transaktionen kører ikke særligt lang tid - måske et minut eller to.



--
Jesper Stocholm
http://stocholm.dk
<a href="http://www.sony.com">evil
Findes din kiosk på nettet? Se http://ekiosk.dk