28. november 2002 - 21:34Der er
6 kommentarer og 1 løsning
Database falder i søvn !!
Jeg har en MSSQL server kørende med flere forskellige databaser med diverse dataopsamling, som kommer via ADO fra andre maskiner. En enkelt af disse databaser har en tendens til efter et stykke tid (1-4 timer) uden forespørgsler at "falde i søvn". Nå så den første forespørgsel udføres derefter går der MEGET lang tid med at returnere svaret, eller man får simplelthen timeout. Næste går lidt bedre og så kører det derefter bare som det skal, med hurtigt returnerede svar. Min vigtigste forespørgsel ligger som en Stored Procedure. Jeg har bemærket at hvis SQL server har været stoppet (og frigjordt memory)og man kigger på hukommelses forbruget under den første forespørgsel, bliver memory langsomt bygget op under den lange ventetid. Men selv om mem forbruget derefter er konstant går det alligevel istå igen efter et stykke tid. En anden database hvor der spørges fra en webserver virker altid ??. Jeg har prøvet at justere på alt hvad jeg har kunnet finde omkring memory omkring serveren og på opsætningen af databasen hvor det går galt. Serveren kører på en dual 1,4Ghz Compaq server med 512 Mb ram, og jeg har begrænset MSSQL til 384Mb ram forbrug. Jeg har prøvet med forskellige performance målinger både på serveren, processor og MSSQL uden held. Der er f.eks intet at se på processorenes load (1-4%) når fejlen optræder. Mem forbruget totalt ligger på ca 470 Mb. Der kører ikke IIS på serveren.
Har du kontrolleret at antallet af connections på serveren ikke "eksploderer" - det passer nemlig meget godt med symptomerne?
Gå ind i Enterprise Manager under "Management" og derefter "Current Activity", "Process info". Hvis der er omkring 100 åbne connections vil en maskine der er konfigureret som din gå i coma.
Hvis dette er tilfældet mangler der en masse "Connection.Close" i jeres webapplikationer.
Her er en lille "utility" jeg har lavet til at udføre "kill" på samtlige åbne connections til en database. (Jeg har nemlig samme problem med en applikation)
Kald den således: KillAll 'MinDatabase'
create proc KillAll @dbname varchar(50) as
declare @dbid bigint declare @spid int
select top 1 @dbid = dbid from master..sysdatabases where name like @dbname
declare crs cursor fast_forward for select spid from master..syslocks where dbid = @dbid and spid <> @@spid
open crs
fetch next from crs into @spid while @@fetch_status = 0 begin Print 'Killing ' + cast(@spid as varchar) exec('kill ' + @spid) fetch next from crs into @spid end
Der ser ikke ud til at være for mange connections åbne, der er 24 connections og 10 locks (Spid). Jeg kom vist til at give ocp alle point'ene, kan man mon forstætte spørgsmålet eller skal der åbnes et nyt ?
Hej ocp Det var nu ikke meningen, jeg går ikke så højt op i point'ene.
For øvrigt er jeg kommet en smule videre, tror jeg. Jeg opdagede at jeg ikke havde nogen index ud over primary på den DB der falder i søvn. (dem genererede jeg i den sp der laver rapporter) Nu har jeg lavet et par index og nu kører det hurtigere efter at SQL server har været genstartet, hvor der før gik MEGET lang tid med ligesom at genopbygge hukommelsen i SQL serveren. Så nu får den en god nats 'søvn' incl aut backup, og så må vi se i morgen tidlig. Er det ikke bedre åbner jeg spørgsmålet igen.
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.
