Forespørgsel tager lang tid første gang.

Kan man på nogen måde få SQL Server til at gemme disse execution plans på disk og få den til at loade dem igen når servicen starter op efter backup?

Nu ved jeg absolut intet om Navision, men, kan du ikke oprette et Sql Server Agent Job som udfører en eller anden dummy-søgning hver morgen klokken 05:00 eller lignende? Så vil den første søgning have kørt, når de første brugere kommer på arbejde.

Hmm...om morgenen, når brugeren møder og kører en søgning i f.eks. Fakturaer, tager det lang tid første gang. Hvis brugeren søger igen i Fakturaer, tager det kort tid. Hvis brugeren i stedet søger i f.eks. Ordrer, tager DET lang tid - så det afhænger altså af hvad man søger på, så jeg er ikke sikker på at din løsning er 100% den rigtige løsning.

SQL Server processen lukkes ikke ned under backup proceduren (Tivoli System), så hvorfor "glemmes" søgningerne/forespørgslerne?

Jeg tvivler på at det er fordi execution plan glemmes.

Jeg tror snarere det er fordi alt ryger ud af cache.

Hvordan ser ramforbruget ud efter arbejdsdagen ? og hvordan ser det ud om morgenen ? er der nok ?

Hvis det kun er den første søgning der er langsom, så burde brugere da kunne leve med det ... ellers må du vel som aaberg_cc
siger lave en masse dummy søgninger.

Der er 3 GB ram i serveren, 281 MB fri på nuværende tidspunkt (og det ændrer sig ikke dagen igennem).
sqlservr.exe bruger 1.7 GB og sqlWb.exe bruger 135 MB

arne_v: det var også den konklusion jeg selv kom frem til i går eftermiddags, men er der ikke en måde at omgå dette (at undlade at tage backup er IKKE en option! :))

buzzzzz: serveren er generelt aldrig belastet, hverken CPU eller RAM-mæssigt.

Buzzz: jeg tror ikke helt jeg forstår hvordan det skal skrues sammen, altså dummy searches.
Det er vel ikke nok bare at køre en forespørgsel op mod en SQL Server tabel, det skal vel næsten være en forespørgsel der er identisk med det Navision gør, når man søger f.eks. på et ordrenummer.  Hvordan ser jeg hvad Navision forespørgslen ser ud som??

Når der tages backup af en database, flushes forespørgsels-cachen så? (antager at det gør den, men har ikke kunnet finde noget på det).

Ang. min post af 09:07:22, kan man jo selvfølgelig starte et trace et stykke tid før første bruger logger på og så se forespørgslen der.....

Men er forbruget SQL serveren bruger er det samme ? altså af ram ?

Var til et foredrag med Mark.
http://improve.dk/blog/2009/03/11/anug-talk-optimizing-sql-server-2005

Han kommer ind på mange ting som generelt bare kan optage ram ... og SQL bruger hvad den kan komme til ...

Har en som egentlig ik' laver noget speceilt ... men alligevel bruger den 10GB ... og det er hvad der er i maskinen.

Specielt det med caches query plans er sjovt at se ... havde et forbrug på 220 MB ud af de 10 GB ... hvilket er godt :-)

// ouT

Ja, forbruget af RAM (SQL Server processen) er den samme, hvis det varierer, er det ikke med mange MB.

Hvor ændrer man cache-størrelsen for query plans?

Jeg kørte SQL Server Profiler og oprettede et job med en 20 dummy forespørgsler på de tabeller der blev brugt mest.

Brugeren nøjedes med at låse sin computer (men lukkede Navision), da hun gik hjem i går. Dummy forespørgslerne blev kørt i morges kl. 5, ingen errors.

Brugeren siger at hastigheden stadig er langsom på de første forespørgsler, så nu har jeg bedt hende om at lade Navision være åben og bare låse computeren ved arbejds ophør i dag, så må jeg følge op på det tirsdag morgen.

Hvis der er andre der har forslag at byde ind med, så meget gerne...

Nu skriver du bare "rigtig lang tid" ... er det 5 mins eller 10 sek ?

Nu ved jeg ikke hvor stor sådan en navision db er men er den blevet langsom med tiden ? Så kunne man jo forestille sig at der måske mangler index's ... ?

// ouT

buzz: lang tid er ca. 1.5-2 min. - efterfølgende søgninger tager under 1 sek.

Nå, brugeren lod sin PC stå tændt, med Navision åben og kunne her til morgen fortælle, at alt kørte rigtig hurtigt.
Hurra, tænkte jeg, så er det et PC cache problem! Men nej, for jeg bad hende genstarte sin PC og herefter kørte alt STADIG hurtigt.

Back to square one...

Databasen er på 18 GB, fordelt i 2 databaser på hhv. 0.5(.mdf) og 17.5 (.ndf) GB
Logfilen er på 12.6 GB og placeret på system-drevet.

Lidt nyt i sagen...

Problemet viser sig i Navision (4.0 SP 3) når brugeren vælger Økonomistyring -> Finans -> Kontoplan -> Poster.

Hvis jeg åbner den underliggende tabel i SQL Server Management Studio, farer CPU belastningen op på 70% - free ram forbliver den samme (ca. 450-500 MB).

Mit spørgsmål er så, når nu brugeren vælger Poster for en given Kontoplan og det tager ca. 1-2 minutter før posterne er hentet, og brugeren så efterfølgende vælger en anden konto og det kun tager et par sekunder, hvor ligger dataene da - i SQL Server Cache, Navision Server Cache eller på klient-PC'en?

Hej,

Jeg har oplevet at et reuild af mine "statictics" på en table satte farten om ... nok fordi min struktur var blevet ændret så meget, at der var kommet nye og bedre måder at lave execution plans på ...

Er der de rigtige indexes på (måske rebuild af indexes) ? Hvad siger den hvis du kører en SQL Profiler når den query bliver kørt ? Er der mange fysiske reads ?

Du har stadig ikke svaret på om det bare er blevet langsom med tiden eller ?

Siden Navision blev installeret på serveren for 2-3 år siden, er der ikke foretaget ændringer/optimeringer.

Dvs så må det være størrelsen der gør den langsom.

Så er min første tanke igen ... der må mangle nogen indexes i den table siden den kan blive langsom. Så længe en table er lille og det hele kan være i RAM ... så er index for det meste en dårlig ting. Det kan nu ske at du har nået en sådan størrelse at index reelt har noget at sige.

Jeg ved ikke hvordan Navision databaser bliver oprettet og man måske kan komme til at skippe dem når man sætter det hele op. Men kontroller du har indexes på de felter der er i din WHERE conditions. Og at dit Clustered index er rigtigt.

igen ... måske bare rebuild af indxes og statistics kan hjælpe.

I går kørte jeg Navisions egen Optimer tabeller funktion og ind til videre synes brugerne at hastigheden på første søgninger er lige så hurtig som ved efterfølgende.
Håber det holder over de næste par dage, så vil jeg sige det var løsningen på problemet. :)

Alt ser ud til at være i orden nu, læg et svar, buzz, du var inde på det rigtige med indexes.

Hvis der kommer ny data hele tiden vil der opstå fragmentering på dine data ... så en REORGANIZE INDEX eller REBUILD IDNEX er altid en god ting.

Jeg har min egen db på 100 GB ... organize en gang om dagen, og så en rebuild hver 14 dag, den den tager pænt lang tid.

og et svar.

// ouT