09. juni 2001 - 00:13Der er
10 kommentarer og 1 løsning
Locking i MS SQL 2000 mod IIS 5.0
Jeg har en række tabeller som der konstant bliver tonset data ned i.
Jeg laver det via ado på følgende måde
connection.begintrans connection.execute(\"Delete * from Table\") do until iTal=100 connection.execute (\"Insert Into Table (FELT1) values (\'DAVS\');\" ital=ital+1 loop connetion.committrans
MIT PROBLEM er at så snart at jeg har fyret begintrans af OG foretaget ændringer i basen (Delete eller add) så kommer der locks på records. Dvs at min IIS 5.0 ikke kan trække på queryen FØR at committrans er fyret af. Da det kan køre over fx. 128 Kb linier kan det risikere at tage lang tid før en committrans kommer og frigiver tabellerne. Samtidig kan der være op til 40 lokationer der på forskudt tid skriver til basen og dermed opnår jeg konstant låsning.
Jeg har prøvet at rode med Select ... From ... WITH (NOLOCKS) men den skid.. bare højt og flot på transaktionen og læser alt. Den duer ikke.
Med kunstig intelligens skaber HP’s nye OmniBook X 14 en unik og skræddersyet brugeroplevelse målrettet dem, der ønsker høj ydeevne og intelligente funktioner
Hvad gør lock_timeout (er lidt grøn med SQL serveren) - Som det er i øjeblikket går der ca. 30 sekunder før timeout\'en kommer. Når der ikke er locks (dvs. at der ikke tilføjes i db\'en) kommer svaret på under 1 sek.
Cursors: jeg kan ikke finde noget sted i Frontpage 2000, hvor jeg kan sætte cursors ?
Transactions bevirker ikke at der ikke bliver placeret locks på dine data pages.
Dit problem ligger nok i at når du laver en insert bliver der placeret en Exclusive Lock der hvor den næste record skal indsættes. Da du har slettet alt i tabellen, vil ligge i begyndelsen af tabellen.
En Exclusive Lock forhindre al anden aktivitet der hvor locken er placeret.
Din transaktion bevirker i princippet at din lock bliver opretholdt i længere tid, indtil alle dine inserts er løbet ind.
Du burde nok se på om ikke det er mulig at udføre insert logikken mere effektivt. En anden mulighed er at oprette flere tabeller, hvor de forskellige lokationer indsætter. Dette kan så efterfølgende konsolideres over i en tabel.
En mulighed var måske indenfor din transaction, at oprette en #temp tabel hvor du først indsætter data, derefter sletter du indholdet i target tabellen, og indsætter indholdet fra temp tabellen. Dette burde formiske den tid hvor der er lock på target tabellen, da insert fra temp tabellen burde være langt hurtigere.
--> Gandalfthewhite: Jeg har indtil videre lavet lidt af det du foreslår. Dog via replikering (jeg vidste ikke bedre) - således at ændringer i \"arbejdskopiens\" indhold replikeres over i en anden tabel. Herfra kan IIS\'en arbejde problemfrit. Det virker faktisk fint. Tak for tippet.
Der er ingen tvivl om at locking problemer også kan opstå ved replikering. Derfor bør replikering ske på tidspunkter hvor der ikke erså meget aktivitet, f.eks. om natten.
Replikering er vel groft sagt en automatiseret updatering/insert som på samme måde sætter locks på tabeller/pages/extents som alle andre action queries.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
