Vi havde et problem med et system der var meget langsomt ved opslag til database. Der blev installeret en ny smallbusiness server, hvor databasen blev attached. Databasen kører stadig i 2000 mode (sql'en er en 2005). Herefter var opslag stadig langsomme og derfor blev der lagt en række index på. Dette hjalp på performance, men nu er der sket det, at når man laver en sortering på en kolonne uden index, så dør serveren. Det skal siges, at der i pågældende tabel er ca.500.000 rækker.
Der sker det, at i løbet af et øjeblik holder serveren op med at svare, ikke bare sql-serveren, men hele windows. Da der er tale om en sbs er det hele domænet der dør... Eneste vej ud er at slukke og genstarte sbs'en og håbe at alt virker (det gør det desværre ikke hver gang...). Ram forbruget på sql'en er sat til ca. max 1,25gb. SQL-serveren kører på sine egne diske der kører raid 10.
Man kan argumentere for at sql'en bør flyttes over på en anden server, men i bund og grund kører det fint. Men, men - ind i mellem er der nogen der får åbnet et eller andet som der formodentligt ikke er index på. Formodentligt, da der intet er at se i logfilerne. I hvertfald så dør serveren... Vi har forsøgt at rebuild index'er uden at det hjælper.
Vi kunne godt via profileren etc. lægge indexer på, som ville optimere kørsel, men det ville ikke sikre, at der er et hjørne af systemet, hvor man kan komme til at åbne noget, som sorterer eller laver et udvalg på noget uden index, hvorefter alt dør.
Hvorfor "overlevede" serveren før vi begyndte at lægge index'er på? (det ville være ok, hvis det gik langsomt, for så kunne vi bare lægge et nyt index på - det er det totale crash der er katestrofalt!!!) Kan det være rigtigt, at sql'en kan trække hele serveren ned på denne måde - hvad gør vi for at undgå dette? Hvordan finder vi ud af med sikkerhed om det er sortering uden index der er problemet?
Der er tale om ordrelinie tabellen. Primært index er på ordrenummer samt et felt der hedder srt (sortering - rækkefølge som vises i ordreregistrering). Der er ikke index på kundenummer, og hvis man sortere på kundenummer, så går det galt... Jeg kunne lægge index på dette, men så jeg mener, at der er et generelt problem. Det skal siges, at primært indexet ikke er et clostered index - af en eller anden grund laver ERP-system ingen clostered indexes...
kan du fortælle hvilke kolonner du har ? du kan indexere på yderligere felter evt. evt. et dato felt.. det tager så lidt længere tid at indsætte i databasen, men kan gøre en forskel når du sortere
Jeg kan godt løse dette kendte tilfælde. ERP-systemet er Visma, hvor man på få minutter kan lave et nyt skærmbillede, trække en hvilken som helst tabel ind, lægge filtre på, sortere samt lave deltotaler og totaler. En simpel salgsstatistik kan laves på et øjeblik...Af samme årsag er dette noget brugerne benytter... Jeg kan godt løse denne kendte situation, men hvad med den næste situation hvor en bruger laver en anden sortering eller åbner et skærmbillede som sorterer på noget uden indexer.
Mit store problem er, at på den gamle server kørte det langsomt, men den gik aldrig ned!!! Nu har vi løftet performance på nyt hardware og med flere indexer, men flere gange om ugen dør serveren HELT og skal "cold bootes". Det er OK, at det går langsomt, det kan løses med indexer, men den må ikke gå helt kold!!!
Dit problem lyder som om tempdb bliver fuld, og ikke kan udvides, enten fordi der er sat en max størrelse på, eller den (de) disk(e) som tempdb ligger på, ikke har mere plads.
Der intet at se i Event Viewer. Mig bekendt er der ikke nogen begrænsninger på tempdb - men efter at alt crashede i fredags kan jeg ikke komme ind i studie management...skal geninstalleres (ikke godt på et system der er i 24timers drift) - så jeg kan desværre ikke kigge nærmere på tempdb lige nu. God ide ellers!
Der er muligheder for at med Profiler at logge alle forespørgsler, og efterfølgende forsøge at analysere de sidste forespørgsler, inden serveren gik ned. Du kan også med Performanc viewer i NT bl.a. monitorere udviklingen i tempdb, og ledig diskplads.
Check eventuelt også at den ikke løber tom for virtuel hukommelse.
Den datastørrelse du angiver (500.000), bør ikke give problemer for en SQL Server, hvis den er rigtig konfigureret, og ikke løber ind i pladsproblemer.
Betyder det at du har checket, at der ikke er nogen begrænsninger i hvordan tempdb kan udvide sig, og at du også har checket om der er fysisk plads på de drev tempdb kan bruge?
Grunden til at jeg fokuserer på tempdb er, at froespørgsler bruger tempdb, når der skal sorteres/grupperes. Hvsi det er denne type forespørgsler som giver ustabile SQL Server, vil jeg i første omgang tro at problemet er knyttet til tempdb.
Jeg syntes at det lyder meget fornuftigt, at det kan have noget med tempdb at gøre. Der er masser af plads på alle drev og der er ikke lagt nogen begrænsninger på hvor stor tempdb kan være - i hvertfald i operativsystemet. Tempdb er helt standart, så jeg skal ikke kunne sige om der ligger noget i sql-serveren der sætter en begrænsning. Desværre kan jeg ikke komme ind i studie management, før jeg får geninstalleret sql-serveren... En ting er dog, at tempdb ligger på c-drevet - den skal jeg i hvertfald have flyttet væk - især da der er et sæt diske der ikke rigtigt laver noget og med masser af plads. Nok ikke helt smart at tempdb ligger på systemdiskene...
Jeg er i øvrigt meget sikker på, at tempdb er sat til simpel recovery mode. Jeg kan ikke se noget om pladsproblemer i event loggen.
Hvilken SP bruger du på din SQL Server. Jeg kan se at der er nogle issues ang. setting af autogrowth på tempdb, som er rettet i SP2.
Du kan også med sql se dine databasefiler i en angiven database: select * from sys.database_files
Hvis du kører ovenstående i tempdb, kan du se i 'Growth' hvor meget databasen udvides hver gang. 'Size' indikerer størrelsen på på hver fil, og 'maxsize' skulle gerne stå til -1, for at indikere, at der ikke er nogen begrænsning i hvor store tempdb kan blive.
Hvis tempdb bliver monster stor, må man heller gå ind og analysere hvilke forespørgsler der genererer stor tempdb, og vurder om disse skal omskrives, eller der skal laves nogle indexer, således at SQL Server kan lave forespørgselen mere effektivt.
Jeg tror godt, at jeg kan fastslå, at det ikke har noget med tempdb at gøre. Igår crashede serveren igen og efter den var kommet op igen satte vi memory grænsen ned for sql'en og prøvede at genskabe problemet. Det lykkedes for os at genskabe problemet og indtil den gik ned stabiliserede RAM forbruget sig (som det skal - der var 1,5 gb RAM tilbage da den frøs) og tempdb voksede stort set ikke. Tempdb er i øvrigt i simple mode og ikke begrænset mht. at vokse. Der er SP2 på sql'en.
Vi er nødt til at gøre noget, så vi vil nu oprette en virtuel server med sql'en på - på den måde håber vi, at vi kan undgå at small business serven går ned.
Nyeste teori er i øvrigt, at sql'serveren venter på en ressource der får den fysiske server til at fryse indtil sql'en enten får ressourcen eller timer ud - hvilket den ikke gør inden for nogle minutter... Men det er kun en teori. Der kan også være en fejl i SQL.
For at opsummere: Det ser ikke ud til at have noget med hukommelsen, diskene eller tempdb at gøre.
Ved at flytte databasen til en anden server, hvor der ikke var problemer, fik jeg en mistanke. Vi flyttede de diske som databasen lå på hvor der var problemer til en anden server og lagde databasen på disse diske igen - fejl var tilbage. Alle værktøjer, event viewer etc. meldte ikke om fejl på diskende, men fakta er, at der var tale om en fejl på diskene. Diskene blev skiftet og der har ikke været problemer siden :-)
Jeg takker for hjælpsomheden.
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.
