26. september 2001 - 12:38Der er
18 kommentarer og 1 løsning
SQL Server crasher efter DELETE!
Hejsa!..
Jeg har et meget irriterende problem, når jeg prøver at delete/inserte i min SQL server gennem ASP!
Problem-stillingen er flg.:
Jeg kører et script, hvor jeg først fjerner ALT fra 3 tabeller (DELETE FROM MY_TABLES WHERE ID > \'0\')
Derefter haster jeg videre til en anden tabel og siger: SELECT * FROM THIS_TABLE
Jeg genererer nu et loop, hvor jeg fylder data ind i de 3 tabeller jeg slettede i starten af scriptet(oversat til børnesprog):
DO WHILE RECORDS IN OTHER_TABLE NOT END OF FILE
PUT STUFF IN MY_TABLE PUT STUFF IN MY_TABLE2 PUT STUFF IN MY_TABLE3
LOOP
Hvis der er fejl i SQL\'en skriver den fejlen ud:
IF ERR.Number <> \'0\' then Response.Write err.description Else Response.Write \"OKAY\" End If
Problemet er, at dette virker rent kodemæssigt - og det er lynhurtigt!.. Det er SQL-server, der crasher. Den bruger ca. 15 minutter på at stå og tænke, alt imens mine webpages ikke kan vises, hvorefter den melder \"Timeout Expired\" fra Enterprise Manager. IKKE fra ASP! Derefter virker alt igen, og når jeg kører rutinen igennem igen er der ingen problemer! Laver jeg en lille ændring til et af punkterne i \"OTHER_TABLE\", så skal jeg igennem samme ventetid/problemer igen. Derefter er der ingen problemer!
I lang tid har samarbejdsbranchen fokuseret på at forbedre enhedsfunktioner – bedre kameraer, klarere lyd og smartere software. Men den virkelige forvandling handler ikke om funktioner.
Måske kan det hjælpe at TRUNCATE de tabeller der skal slettes i stedet for at bruge DELETE. SÅ bliver der ikke lagt nær så meget i TRANSACTION LOGen. Det kan nok hjælpe serveren lidt.
Kan jeg \"truncate\" on-the-fly direkte fra koden??.. Problemet er, at jeg ikke får hands-on rettighed til at truncate tabellerne, når først sitet er live. Derfor må, og skal jeg, finde en løsning på problemet, før vi går live!
Slash,
Nej!.. Ingen deadlocks eller andre mystiske ting. Det er desuden en næsten ny SQL server 2000 installation på Win2K Server og IIS5.0!
Jeg forstår det ikke!!.. Jeg har lavet usandsynligt mange funktioner som denne uden problemer!.. :(
Hvis du ikke får rettighed til at truncate på live sitet, så er det jo ligegyldigt at kigge nærmere på det. :-(
Er det meget store datamængder/indexer ?? Når du bruger DELETE skal den jo (så vidt jeg ved) skrive en post i TRANSACTION LOG for hver post der slettes. Og der skal også rettes i indexer for hver post der slettes.
Sjov ide : Hvad med at fjerne evt. indexer inden du sletter postern, og så sætte det på igen når tabellen er tom ???
Jeg har naturligvis administrator-ret til alt hvad jeg har lyst til, både når sitet er live og i test på min lokale maskine her, men problemet er, at jeg helst vil have alting til at køre fuldstændigt uden nogensinde at skulle ha\' hænderne nede i den database jeg har kørende live. Altså, hvis jeg kan undgå det!.. :)
Det drejer sig om ca. 8 linier i hver af de 3 tabeller der bliver slettet, så det kan ikke rigtigt betragtes som værende store datamængder!
Jeg ville gerne ha\' lavet hele funktionen som en UPDATE routine uden at skulle slette indholdet først, men problemet er, at jeg ikke kan holde styr på de værdier og ID\'er jeg får fra \"hoved-tabellen\", som jeg kopierer fra. Derfor sletter jeg alt indholdet fra de 3 tabeller. Det kan være, at jeg skal lave en \"DROP\" istedet for, men giver det ikke anledning til endnu flere muligheder for fejl??..
Hvis jeg vælger at \"DROP\"\'e tabellerne, så havde jeg jo naturligvis tænkt mig at \"CREATE\" dem lige efter igen!.. :)
Jeg giver dig fuldstændigt ret i, at 8 poster ikke er meget, når man tænker på, at SQL-server efter sigende er næsten grænseløs(Hvilket den dog ikke er)..
Jeg er fuldstændigt tom for idéer. Det er ikke maskinen. Det er en helt ny DELL 1700Mhz Pentium4 med 512MB RAM og en splinterny installation af WIN2K Server. Der har aldrig været problemer med den før!
Nu smed jeg sitet over på en anden server, og sjovt nok er der INGEN problemer!..
Jeg vil nu stadig meget gerne finde ud af hvorfor jeg oplevede fejl på min egen server, men pointene skal du ha\' uanset hvad!.. Kan du ikke lige lave et \"Svar\" ?
Kunne være interessant, at se, hvad der kom ud af at køre SQL Profiler imens den laver disse \"stunts\" - det skulle nok kunne give nogle hints.
Umiddelbart lyder det så ganske afgjort som et deadlock problem - det er typisk det eneste, der kan få den til at hænge så uhæmmet. Men de kan være svære at finde. Du kan sætte Performance Monitor på, den kan vise deadlocks, så kan du i hvert fald se, om der er nogle.
Når/hvis du finder løsningen, så vil jeg meget gerne høre om det - det er sådan noget, man gerne vil vide noget om, når man selv havner i situationen...!
Du har fuldstændigt ret i, at det lyder som en deadlock, men jeg synes jeg plejer at få en fejl, når SQL-serveren går i deadlock.. Det sker heldigvis ikke så ofte!.. Jeg skal nok, hvis jeg nogensinde finder fejlen, poste løsningen herinde!
Har noget lignede samme problem - det er dybt mystisk.
Jeg får en timeout på den samme update HVER gang jeg køre den, jeg kan fint indsætte 30 records, og update dem, men når jeg så når til den næste update dør den.
Jeg har haft problemer med det 2 gange nu, i begge tilfælde på en Windows 2000 maskine med MS SQL 2000 SR-1.
I et af tilfældene dør den når den når over 20 records.
Hvis jeg kopiere update sætningen direkte ind i Enterprise manageren, spiser den den uden problemer.
Hvis MYSQL havde en transaction server, så havde MS fået fingeren for lang tid siden.
Har du prøvet profileren? Den kan altså nogle gange give - om ikke svaret - så i hvert fald nogle ledetråde! For mig er den et fuldstændigt uundværligt værktøj i den slags situationer.
Efter den update der går galt, begynder der at komme nogle entries fra SQLagent -Alert Engine, på SYSTEM user. kan ikke lige gennemskue den.
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.
