28. december 2009 - 16:37Der er
34 kommentarer og 1 løsning
Perfomance på sql-server
Hejsa
Jeg sidder med en database, som har vokset sig så stor at hastigheden er blevet et problem. Jeg har nogle spørgsmål desangående. Da det er flere spørgsmål
har jeg valgt at opdele de enkelte spørgsmål i point.
Følgende er vores nuværende opsætning:
På samme server kører: Domæneserver Database - Navision (bliver brugt knapt så ofte) mdf - 77 mb ndf - 3,7 gb ldf - 800 kb.
Database - Invoice (bliver brugt knapt så ofte) mdf - 210 mb. ldf - 241 mb.
Som jeg er orienteret skal en domæneserver kun køre de applikationer som har med domænets funktionalitet at gøre; Active Directory, DNS, og DHCP.
Derfor er mit forslag - som jeg gerne vil have kommentarer til - at gøre flg.:
Pille sql-serveren ud på en selvstændig opdateret 2008-server (og opdatere databasefilerne).
- (30 point) kan man dele sql-serverens mdf, ndf og ldf filer ud på forskellige servere. De skulle kommunikere på et 1Gb backbone. - (20 point) Er det ligegyldigt om sql-serveren og (mdf, ndf)-filerne ligger på samme drev (blot at ldf-filerne er adskilt)? - (20 point) Hvor stor betydning har tmp-databasen for performance. - (30 point) Er det muligt at begrænse databasen, således at det kun er de seneste 5 år (på den måde at minimere databasen så der kun søges på relevante data), der søges på og der laves en slags "arkivdatabase", som kan tilgåes ved særlige tilfælde? Eller er filegroup og .ndf-filer man skal gøre?
1. Nej, jeg er ret sikker på at mdf(data) og ldf(log) skal være på samme server. ( ik' klar over hvad ndf er )
2. Hvis disk performance er et problem, kan du godt smide de forskellige filer på forskellige drev. Det er faktisk godt skik. Log fil er jo til transactions og ja, mdf er til data.
Men er næsten kun læse operationer, så er der ikke meget ved at flytte log filen til en anden disk.
3. Kommer an på hvor tit den bliver brugt ... er der ik' nok ram, jamen så bliver tmp db brugt.
4. Du kan partionere databasen ... udfra en partionerings nøgle, dog ikke noget jeg selv har prøvet, men synes ikke du har nok data til at det kan have den vilde effekt.
Du siger det hele er langsomt ... det skal man ikke være professor for at kunne se ... men hvad gør den langsom ? Her er et par ting jeg ville undersøge inden du kaster dig ud i en kæmpe omstrukturering.
1. Rebuild indexes på alle dine tables.
2. Du siger den er langsom, find ud af hvad de quries laver? ... Execution plan i SSMS eller Sql server profiler ... og finde ud af hvorfor de er langsomme.
3. Som ektra til overstående kan det jo ske at du mangler ram i din server eller der måske mangler nogen indexes.
Der kan være mange grunde ... her var i hvert fald de første som du bør undersøge.
jape44: Ingen tvivl ... derfor jeg også efterspørger specs på den server ... for RAM koster jo intet i dag.
16 GB for 4000 excl moms ... måske mindre.
Og så bør disk access jo ikke være et problem, og de fleste quries kan være cached.
mvh
Synes godt om
Slettet bruger
28. december 2009 - 17:46#5
Ja klart! Men som jeg forstår spøgeren, handler det om hvilke "database" funktioner han skal flytte over på et andet drev, hvilket i ringeste grad hjælper.
Så må svaret være. Bed firmaet om at købe en ny server til formålet.
SQL serveren vil være et godt udgangspunkt.
Synes godt om
Slettet bruger
28. december 2009 - 17:53#6
Lidt historie: Jeg har haft ansvar for en MS-SQL server som samlet betjente omkring 3000 samtidige bruger, fordelt over flere lande, i et telefon-selskab. Ikke uden problemer, men vi brugte også load-sharing, så det var fordelt over 350m2 og det gik ganske fint :-)
Ja, problemet er tydeligt, har jeg sagt andet ? Løsningen kan jo bare findes 2 steder.
Kommer igen an på størrelse ... som vi endnu intet ved om.
Mht de 3000 brugere, så er det jo intet der siger nogen om hvor aktive de er ... og så er 3000 jo ikke specielt meget.
Et live system er ikke sjovt at rode på, men derfor kan man jo stadig hente data ud for at finde ud af hvad der ikke virker som det skal ... og lave et live rebuild af index hvis det er tilfældet at det vil hjælpe, hvilket jeg har set før herinde på exp.dk
Men vi er begge enige om at der mangler input.
Synes godt om
Slettet bruger
28. december 2009 - 19:26#10
Nu var det så et gennemsnit på 3000 opkald per minut og dermed en forespørgsel som virkelig sætter grå hår i hovedet.
Til spørgeren: De 5 år kan klares med en schedule som tricker på en dato. Måske hver dag.
Mange tak for de hurtige svar. (Jeg fik mere og mere feber, så jeg måtte tage hjem i seng, så derfor hørte I ikke fra mig før nu).
Der er temmeligt meget input fra Jer, og det er jeg glad for. Vil her give lidt mere info:
Det er en virksomhed på 50 ansatte som benytter systemet (+ få partnere udefra). Det er rigtignok at arbejdsgiveren er svær at hive penge ud af til nyt hardware, men hvis jeg kan argumentere godt, kan det godt lade sig gøre, men det er lidt svært at argumentere for et drev til nogle få gigabyte..
Databasen består i korte træk af 200.000 aktiviteter samt activitydetails på cirka 15 poster pr. aktivitet.
første aktivitet stammer fra år 2000, hvorfor jeg tænkte om man kunne begrænse databasen til kun at tage de seneste 4 år, og ved særtilfælde kunne finde data i et databasearkiv.
buzz skriver tre ting jeg bør undersøge:
1. Rebuild indexes på alle dine tables.
2. Du siger den er langsom, find ud af hvad de quries laver? ... Execution plan i SSMS eller Sql server profiler ... og finde ud af hvorfor de er langsomme.
3. Som ektra til overstående kan det jo ske at du mangler ram i din server eller der måske mangler nogen indexes.
Jeg har ikke lavet disse ting før men vil prøve og skrive tilbage med svar eller opfølgende spørgsmål.
Grunden til jeg efterspørger om jeg kan splitte filerne ud over flere servere er manglen på drev. Jeg tænkte hvis vi har en rimelig hurtig backbone, ville det måske være løsningen - men det kan jeg forstå på Jer at det IKKE er?
Til buzzzz ndf har jeg læst om i en sql-bog, citat: In a sql-server 2005 database, you can create two types of data files: primary and secondary: Primary datafiles is mandatory and contains startup information for the database catalog and points to the other database files. The primary data file can also contain objects and user data. The recommended extension for the primary data is .mdf Secondary data fil, which is optonal and user-defined, contains objects and user data. You can put each secondary data file on a different disk drive to boost performance. A database can contain a maximum of 32,766 secondary data files. The recommended extension for a secondary data file is .ndf.
Jeg tænkte at disse filgrupper ville svare til at begrænse databasesøgningen således at sql-serveren deler data op i brugte og mindre brugte data (men det er kun et gæt).
Yderligere info: Det vil blive en detach/attach opgradering hvor vi vil være her efter arbejdets ophør opgradere.
Seneste: Jeg har lavet testdata: Chap (selvstændig server kun til databasen) På Chap sat to usb-nøgler hvor den ene indeholder mdf-filer og den anden ldf-filer. Følgende udmelding har jeg fået på testbruger: Ud over det, så testede jel lige beta2, jeg bad den åbne 10 logs lige efter hinanden/samtidigt.. det gik f... stærkt, set i forhold til vores live data. Da jeg klikkede på den 10ende, var de 9 andre allerede åbne og fuldt tilgængelige :-) WOOOOOP WOOOOP
Hardware specifikationer Zeus (hvor hele møjet ligger på nu; sql-server, domæneserver) ----------- CPU Xenon 2Ghz RAM 1Gb HDD RAID-5 230GB fordelt på C: 98Gb D: 132Gb
Chap (hvor den fremtidige sql 2008-server skal ligge) ----------- CPU Xenon 2,13Ghz RAM 1Gb HDD RAID-1 150GB fordelt på C: 60Gb D: 90Gb
Vores servermand har svaret flg.: Til Chap kan jeg skaffe 2Gb (1211168-Actebis) til 279,98 xm/fragt stk. og der skal RAM i af par, dvs 2 stk af gangen. Så det vil koste min 559,96 at få den opgraderet, men så burde den også vise 5GB RAM
Jeg vil som sagt forsøge mig med buzz's forslag:
1. Rebuild indexes på alle dine tables.
2. Du siger den er langsom, find ud af hvad de quries laver? ... Execution plan i SSMS eller Sql server profiler ... og finde ud af hvorfor de er langsomme.
3. Som ektra til overstående kan det jo ske at du mangler ram i din server eller der måske mangler nogen indexes.
Vedrørende "Rebuild Indexes": Jeg kan se at jeg kan gå ind på hver enkelt tabel og rebuilde indexes. Jeg er ikke helt med på hvad det er; Ødelægger det noget? Er det tilrådeligt at gøre live?
ok, jeg kan se at buzz siger man kan gøre dig live.
Jeg har lige prøvet på en test-db. og kan se på den ene af tabellerne (activities - den største) er Total Fragmentation = 63,14894894864... Det er vel helt galt eller?
Mer info, som jeg forstår det fra vores server-mand ;)
Problemet med vores servere, er at der kun er plads til to harddiske. Skal der være plads til flere hdd, kræver det nyt server-hardware, og det vil der ikke blive råd til.
Som tidligere skrevet kører det hurtigt med usb-nøglerne, men næppe en sikkerhedsmæssig brugbar løsning(?)
Derfor har vi talt om at sætte en NAS-server til. Hvad er jeres kommentarer til det?
Nu forventer jeg ikke at I skal kigge hele denne liste igennem, men det lykkedes mig at lave et script som viser fragmenteringen på den ene af databasens indexes/nøgler og det ser helt vildt ud; Så der bør være yderlige at hente her :-)
dbo.FscAdler.PK_FscAdler is 95.894% Fragmented dbo.MenuProfileAccess.PK_MenuProfileAccess is 80% Fragmented dbo.TeamUser.PK_TeamUser is 50% Fragmented dbo.Quotes.PK_Quotes_QuoteID is 94.4056% Fragmented dbo.ActivityListTemplates.PK_ActivityListTemplates is 50% Fragmented dbo.ActivityHistory.PK_ActivityHistory is 38.7223% Fragmented dbo.ActivityHistory.IX_ActivityHistory is 78.8689% Fragmented dbo.Employees.PK_EmployeeID is 66.6667% Fragmented dbo.QuoteLines.PK_QuoteLines_QuoteLineID is 91.2929% Fragmented dbo.PartOrders_History.PK_PartOrders_History is 67.837% Fragmented dbo.PartOrders_History.IX_PartOrders_PartOrderID is 88.4236% Fragmented dbo.FlowChartLogs.PK_FlowChartLogs is 48.9362% Fragmented dbo.TrackAndTrace.PK__TrackAndTrace__1308BEAA is 80.1418% Fragmented dbo.Employees_History.PK_Employees_History is 72.8571% Fragmented
dbo.PartPackages.PK_PartPackages is 88.3871% Fragmented dbo.ActivityDetails.PK_ActivityDetails is 81.0316% Fragmented dbo.ActivityDetails.IX_ActivityDetails_ActivityID is 99.2079% Fragmented dbo.PostalCodes.PK_PostalCodes is 68.3168% Fragmented dbo.TESTActivityDetailsAll.PK__TESTActivityDeta__171946B0 is 85.1064% Fragmented
dbo.DSVlog.PK__DSVlog__12549193 is 87.8788% Fragmented
dbo.Parts.PK_Parts is 93.7267% Fragmented dbo.Parts.IX_Parts_MaterialNumber is 94.8052% Fragmented dbo.EmployeeOfTheMonth.PK_EmployeeOfTheMonth is 50% Fragmented
dbo.Users_History.PK_UsersHistory is 80% Fragmented dbo.PartsByProducts.PK_PartsByProducts is 96.875% Fragmented dbo.Activities.PK_Activities is 63.9363% Fragmented dbo.Products.PK_Products is 79.4872% Fragmented dbo.Orders.PK_Orders is 93.2099% Fragmented
dbo.PartOrders.PK_PartOrders is 89.1866% Fragmented dbo.PartOrders.IX_PartOrders_ReceiveMaterialNumber is 98.75% Fragmented dbo.SubCodes.PK_SubCodes is 50% Fragmented dbo.Queues.PK_Queues is 50% Fragmented
dbo.UserNames.PK_UserNames is 33.3333% Fragmented dbo.FscProductTypes.PK_FscProductTypes is 84.6154% Fragmented dbo.XeroxOrders.PK_XeroxOrders is 93.8983% Fragmented dbo.Queues_History.PK_Queues_History is 50% Fragmented dbo.PartReturns.PK_PartReturns is 96.8663% Fragmented dbo.AddressContacts.PK_AddressContacts is 50% Fragmented dbo.EmployeeVotes.PK_EmployeeVotes is 75% Fragmented
dbo.XeroxAccessories.PK_XeroxAccessories is 50% Fragmented dbo.UserSettings.PK_UserSettings is 75% Fragmented dbo.PartsStock.PK_PartsStock is 48.6257% Fragmented dbo.FscTranslationToolRequests.PK_FscTranslationToolRequests is 91.0156% Fragmented dbo.XeroxOrdersByServices.PK_XeroxOrdersByServices is 97.4359% Fragmented dbo.PartSupplies.PK_PartSupplies is 77.9904% Fragmented dbo.FscCreditNotes.PK_FscCreditNotes is 55.1887% Fragmented dbo.FscCreditNotes.IX_FscCreditNotes is 82.1012% Fragmented
dbo.FscCreditNotes_History.PK_FscCreditNotes_History is 80% Fragmented dbo.FscCreditNotes_History.IX_FscCreditNotes_CreditNoteNumber is 83.3333% Fragmented dbo.FscCreditNotes_History.IX_FscCreditNotes_PartOrderID is 33.3333% Fragmented dbo.FscInvoices.PK_FscInvoices_RecordID is 75.2366% Fragmented dbo.FscInvoices.IX_FscInvoices_InvoiceNumber is 84.4156% Fragmented dbo.Users.PK_Users is 81.8182% Fragmented dbo.fscRevisedActivities_History.PK__fscRevisedActivi__2957F27C is 60.4167% Fragmented dbo.Menu.PK_Menu is 75% Fragmented
dbo.FscInvoices_History.PK_FscInvoices_HistoryID is 58.3333% Fragmented dbo.FscInvoices_History.IX_FscInvoices_InvoiceNumber is 53.8462% Fragmented dbo.FscInvoices_History.IX_FscInvoices_PartOrderID is 71.4286% Fragmented
dbo.Services.PK_Services is 50% Fragmented dbo.ImpactsByKits.PK_ImpactsByKits is 60% Fragmented dbo.Kits.PK_Kits is 44.4444% Fragmented dbo.ObjectProfileAccess.PK_ObjectProfileAccess is 75% Fragmented dbo.Activities_History.PK_Activities_History is 53.3473% Fragmented
Ja ... hvis din DB er IO bound, så vil det ikke hjælpe med NAS, men kun smide mere latency på.
Mere RAM, mere RAM ... 1 GB for alt det i den lille kasse er jo NADA.
OS: 400 MB AD og andre små services tager vel ca. 200 MB
Så har du 400 tilbage hvilket ikke er meget til en SQL ... og den tager hvad den kan få.
Hvordan ligger de ram i serveren fordelt på forskellige processes?
Hvis jeres timeløn skal være hurtig tjent tilbage, så ville jeg smide 4x2GB i serveren eller 2x4 GB alt efter hvor mange slots der er frie. Igen, RAM koster intet, og i servere er det ikke RAM man må mangle ... det er billigste måde at få mere performance på.
Nu siger du den anden nye server er hurtigt, selvom den ca. har de samme specs som den gamle ? Hvor mange brugere er den på den nye? Det skal jo ligne det gamle miljø 100% før du kan vide om der er bedre performance. Jeg ville nok ikke bruge USB nøgler, da de bliver slidt op rimeligt hurtigt, pga read/writes konstant, specielt til Log filen.
Du kan gøre en Online Rebuild af dine Indexes, tager ekstra ram, og bruger tmp DB hvis du ikke har nok ram ... og med 1 GB ... så vil du løbe ind i problemer.
Jeg skaffe 2Gb (1211168-Actebis) til 279,98 xm/fragt stk. og der skal RAM i af par, dvs 2 stk af gangen. Så det vil koste min 559,96 at få den opgraderet, men så burde den også vise 5GB RAM
Forskellen på den nye server og den gamle er at den kun kører sql-2000-server (og ikke - som nu - sql, domæneserver, webserver) og at jeg har delt ldf-filerne ud på en usb-nøgle. Det er naturligvis noget møg, som du skriver. Men I Chip & Chap-serverne, der er indkøbt af sikkerheds hensyn, sidder der kun 2 fysiske diske i, hvilket er max for modellen. Det var derfor jeg tænkte på en NAS-server.
Der er kun een test-bruger på den nye opsætning, så direkte sammenlignelig er den ikke, men når jeg kører på den sædvanlige testdatabase [BETA] (som ligger sammesteds som nuværende) kan jeg se en klar forbedring ifht. den nye opsætning[BETA2].
Testbrugeren er desuden siddet tidligt om morgenen (hvor han har været alene på systemet) og sammenlignet live-databasen med [BETA2]. Men ellers må jeg give dig ret sammenligningen er ikke 100% sammenlignelig, og jeg har nu bedt alle brugere om at teste samtidigt; først fik de timeout, men efter et par opslag "sparkede det røv" ;)
Rebuild indexes har jeg læst mig til og lavet et script, som evt. kan køre en gang 1. søndag i md. (hvor der alligevel ikke er nogle som bruger systemet). Men som jeg ser det, har det kun indflydelse ved opdateringer; insert, update og delete (det er selvfølgelig også brugbart).
Jeg forsøgte at køre en Rebuild på [BETA](det er den gamle opsætning) og her var udmeldingen at der ikke var nogen forbedring
Du bliver nød til at finde ud af hvorfor dine quries er langsomme ...
er de IO bound, så vil NAS være noget skod at indkøbe og ikke nogen billig løsning hvis det skal være hurtige end lokale diske, da du får et delay mere ind.
Er de CPU bound ... jamen, så vil en ny server være eneste mulighed. Med mindre du kan smid en ekstra CPU i.
Er det pga mangel på RAM, så smid flere i ... er det heller ikke en mulighed i nuværende server, så vil en ny server være en mulighed.
Igen ... SQL Server Profiler eller Execution Plans i SSMS ( Sql Server Management Studio )
Kig på hvad der reelt laver ... og hvad der gør den langsom.
1. Find querien i SQL Server Profiler. 2. Smid den ind i SSMS og kør den så du kan se dens execution plan og hiv nogen stats ud på det ...
I step 2, kan du mere eller midnre direkte se hvad det er som gør din query langsom.
Nu vil jeg ikke blande mig det store her, da der allerede er masser af forslag. Jeg vil dog lige nævne table partitioning på SQL2008 kun er brugbart nåt vi snakker et par hundrede gigabyte data, de datamængder som du sidder med er absolut ikke noget man vil dele op, jeg er sikker på det hele handler om indexering, altså IO som der også nævnes.
(og jo.. indexering og fragmentering har i høj grad noget med query performance at gøre)
Hej igen Og godt nytår! Når jeg taler om partionering, mener jeg partitionering af harddisken, således at jeg kan dele transaction-logfilerne på drev d: og mdb-filen på drev e: og evt.
Da det ikke er muligt med flere harddiske og en usb-nøgle er en for usikker løsning, tænkte jeg alternativt på partitionering af hdd.
Da det stadig reelt jo er samme Harddisk, ville det være mærkeligt hvis der skulle kommer mere performance ud af det.
Hvis der måske kan hentes noget, så ville det nok skyldes at fragmenteringen af mdf og ldf kun ville ske intern i din 2 filer ... og at det ikke ville komme til at ligge udover hele disken.
Det er også en god ide at tildele store "chunks" af gangen i stedet for de 1MB den vist står til normalt, så der ikke kommer så mange huller ind i mellem.
ja, jeg kan godt se at det er samme diske og dermed ingen perfomance-forbedring.
Men jeg er begrænset af kun den ene disk, og usb-løsningen var der jubel over gik hurtigt (bl.a. var en søgning, der normalt tog 43 sekunder nu 3 sekunder om det). Derfor er jeg nu i færd med at forsøge mig med partitioneringerne. Hvis partitioneringen stadig giver en god performance, må den hurtige hastighed skyldes (som jeg ser det): Primært - at sql-serveren er blevet opgraderet fra 2000 til 2008 - at sql-serveren ligger på sin egen server (før sammen med web- og domæneserver)
Sekundært (giver kun performanceforbedring for INSERT, DELETE og UPDATE-kommandoer) - fragmentering, - Rebuild indexes
Ud fra de fysiske begrænsninger kan jeg ikke finde anden løsning end at partitionere hdd.
Jeg har lagt en testversion ud hvor transaktionsfilerne og databasefilerne ligger på samme hdd men hver sin partiotion. I morgen får jeg nok en tilbagemelding fra folk.
Ellers vil jeg kigge på de mange andre gode forslag I er kommet med til forbedring.
Anders ... Rebuild af index giver også performance optimering ved alt (Specielt select som det lyder til at du har store problemer med ) ... alt efter hvordan din Fillfactor er.
Men det lyder mest af alt som om du bare vil have nyt hardware at lege med og ikke prøver præcis de ting vi skriver ...
Du har stadig ikke undersøgt hvorfor nogen quries tager 43 sekunder på den ene server og 3 sekunder på den anden. Jeg forstår ikke hvorfor du ikke gør det ... Mangler du hjælp eller gider du ikke?
Du kan kaste alt det nye jern efter en database du vil ... men er den dårligt lavet (Normalisering, Indexes), så er og bliver den langsom.
Jeg ved ikke hvor meget mere vi kan hjælpe med ...
næh jeg vil sandelig gerne, og jo det er ikke alt jeg har kunnet klare (Mit udgangspunkt er at jeg godt nok kan lave det meste transactsql og databasedesign, men ikke kender en dyt til databaseadministration).
Rebuild af indexes og fragmentering har jeg klaret, men jeg synes ikke at kunne mærke den store performance-forskel.
Jeg vil ikke "lege med hardware". Det vil være lykkeligt hvis jeg kan klare mig med det vi har.
Dine oprindelige 3 punkter har jeg således løst punkt 1, men Execution Plan, sql-server profiler om der er i/o-bound eller cpu-bound kæmper jeg med at få rede på.
Jeg beklager meget, men jeg vil bestemt gerne følge de mange råd og er ked af hvis det har virket anderledes.
" Jeg ved ikke hvor meget mere vi kan hjælpe med ... " Du har givet mig meget hjælp (og jeg har fået masser af gode råd der skal læses videre på), så sig bare til hvis du vil stoppe.
M.h.t. hardware, er der både i denne tråd og i flere bøger beskrevet hvordan man skal adskille tingene fra hinanden.
At man skal søge og måle hvor problemet ligger kan jeg godt forstå, men det er et område jeg slet ikke har beskæftiget mig med. Jeg vil i denne forbindelse komme med et citat fra ovenstående link: Citat: " Learning how to master SQL Sever 2000 performance tuning cannot be learned overnight. In fact, experience, more than book learning, is how you will master this skill. "
m.a.o kan det ikke forventes at jeg kan måle performance og komme med svar på hvor problemet ligger.
Meeen denne tråd og linket har givet mig et godt udgangspunkt for at forske nærmere.
m.h.t. aktuelle problemstilling, adskilte jeg sql-serveren fra resten (ad, web) og lagde sql-serveren (med mdf- og ldffiler) på samme server. Samtidigt lavede jeg rebuild indexes og defrag (der nu bliver kørt en gang pr. uge). Dette gav en voldsom forbedring (cirka 4 gg. hurtigere).
Buzzz- jeg vil gerne give dig pointene, så hvis du vil lægge et svar ;)
og lille kommentar om hvorfor netop det du citere er vejen frem.
Hvis du kunne se det var IO der var problemet ... så kan der være mange grunde ... "Sort warnings" hvis "order by" foregår på disk, hvis den query ikke får allokeret nok ram, og skal til at gøre det i tempdb ...
Der er mange ting ... jeg bliver selv klogere hele tiden, derfor jeg også følger hvad folk kommer med at spørgsmål herinde på exp.dk
Men hvad endte det hele så med ? altså hvad var din løsning ?
Hej Som jeg skrev i forrige indlæg: Lagde sql-serveren over på en selvstændig server, men adskilte IKKE mdf og ldf-filerne til fysiske hdd. Desuden foretog rebuild indexes og defragmentering.
Har lavet et job som defragmenterer indexes hver søndag nat.
Du mangler stadig at give mig et svar ;)
Ja jeg må udforske, så kan det være der kommer nogle delspørgsmål her på eksperten ;)
En af tingene har måske løst dit problem. Det at smide ny hardware efter ting er ikke altid en god løsning.
Men godt at du fik det løst.
mvh
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.
