Nieuwe MSSQL server

[JasperE]

Op mijn stagebedrijf hebben we een SQL server, de huidige specs voor zover bekend:

Windows 2000
2GB ram
AMD 64 2600+

Op deze SQL server draait een ERP pakket waarvan zo'n 20 computers gebruik maken. Bepaalde handelingen met dit pakket duren op het moment te lang, een volledige planning voor een bepaalde afdeling opvragen kan bijvoorbeeld meerdere minuten in beslag nemen.

De huidige SQL server willen we als backupsysteem gaan inzetten. Voor de hoofd sql-server zal een nieuw systeem aangeschaft worden. Wat hier de specs precies van moeten worden is mij nu nog niet helemaal duidelijk.
Op welke punten ik moet investeren voornamelijk niet, wanneer de bovengenoemde planning opgevraagd wordt piekt het cpu gebruik namelijk niet, dit hangt ergens rond de 70%. Ook het cpu gebruik op de client is nog ruim binnen de marges en het newerkverbruik ergens rond de 2% van 100mbit. De 2gb geheugen in het systeem wordt niet volledig benut.

Zou het zoiets als de geheugenbandbreedte naar de processor op de SQL server zijn. Heeft iemand een praktische manier om te ontdekken waar het knelpunt zit?

Btw,
- Leverancier van ERP pakket kan/wil geen advies geven over nieuwe hardware .
- Aanpassen van queries/tables is geen optie

Mijn idee is een dual opteron/xeon systeem. Opteron heeft de hogere geheugenbandbreedte heb ik gelezen.

[ Voor 8% gewijzigd door JasperE op 29-05-2006 12:20 ]

[Silver7]

Nieuwe systeemeisen bedenken is niet moeilijk.

Maar zou je niet ff die oude systeem waarop ERP en zo draait controleren?

Want het zou kunnen dat het geen zin heeft als de nieuwe systeem hetzelfe bottleneck kan hebben als de oude systeem..

(correct me if i'm wrong with language NL)

[MAX3400]

SQL/Microsoft heeft hier voldoende tools/info voor beschikbaar om te kijken waar het knelpunt ligt. Verder kennen we ook nog www.sysinternals.com met allerlei slimme tools.

Zelf doe ik een gooi naar het feit dat de CPU & OS niet goed op elkaar afgesteld zijn; met een dergelijke bak zou ik liever Win2K3 draaien (en indien wenselijk de x64-versie maar die draait niet lekker met SQL2000).

*edit*
Leverancier ERP wil geen advies geven??? WTF?? Hebben ze geen minumum & recommended system-specs??

[ Voor 13% gewijzigd door MAX3400 op 29-05-2006 12:23 ]

[lier]

Een bottelnek zou kunnen zijn je disk IO. Dit is erg eenvoudig te controleren met behulp van de performance counters.

Zou je eens de specs/schijfen/schijfindeling/RAID/whatever configuratie van je huidig systeem kunnen geven ?

En hoe is je datatbase/logfile/tempdb verdeeld over de schijven ?

[bakkerl]

Wat je nog niet noemt is de (disk) IO.
Hoe zwaar wordt deze belast? Als de rest niet voor 100% belast wordt zou ook hier een knelpunt kunnen zitten.

(ben weer eens te langzaam)

[ Voor 10% gewijzigd door bakkerl op 29-05-2006 12:29 ]

[JasperE]

MAX3400 schreef op maandag 29 mei 2006 @ 12:22:
SQL/Microsoft heeft hier voldoende tools/info voor beschikbaar om te kijken waar het knelpunt ligt. Verder kennen we ook nog www.sysinternals.com met allerlei slimme tools.

SQL table optimiser op basis van traces enzo? Die heb ik al geprobeerd, gaf geen suggesties die niet al bestonden.

Zelf doe ik een gooi naar het feit dat de CPU & OS niet goed op elkaar afgesteld zijn; met een dergelijke bak zou ik liever Win2K3 draaien (en indien wenselijk de x64-versie maar die draait niet lekker met SQL2000).

Dat zou goed kunnen, er komt nu sowieso een nieuw systeem. Daar willen we op focussen, niet op optimalisatie van het oude systeem.

*edit*
Leverancier ERP wil geen advies geven??? WTF?? Hebben ze geen minumum & recommended system-specs??

Quote: "Ja meneer, bij sommige bedrijven loopt het systeem gewoon op een pc" "Nee meneer, daar kunnen we ons niet op vastpinnen hoor...."

Waardeloos dus.

[JasperE]

bakkerl schreef op maandag 29 mei 2006 @ 12:28:
Wat je nog niet noemt is de (disk) IO.
Hoe zwaar wordt deze belast? Als de rest niet voor 100% belast wordt zou ook hier een knelpunt kunnen zitten.

Voor zover ik kon ziet wordt deze zo goed als niet belast, de lampjes gaan niet knipperen tijdens intensieve bewerkingen en in perfmon.msc is de disk wait time vrijwel niet aanwezig.

Volgens mij is vrijwel de volledige database dus in het geheugen geladen. (MDF bestand is 2.7GB groot)


Edit:
Samengevat, de disk IO lijkt niet de beperkende factor te zijn, CPU gebruik hangt rond de 70%, de bottleneck van het huidige systeem is dus de FSB bandbreedte?

[ Voor 22% gewijzigd door JasperE op 29-05-2006 13:03 ]

[lier]

Waarom gelijk nieuwe hardware aanschaffen terwijl je nog geen eens een fatsoenlijke troubleshoot hebt uitgevoerd...

Weet je bijvoorbeeld zeker dat je systeem de bottleneck is, of zou het ook aan het pakket/SQL kunnen liggen ? Heb je al eens de profiler gebruikt om te kijken of er iets scheef zit ? Hebben je clients wel de juiste specificaties ? Draait er niet een virusscanner "in de weg" ?

offtopic:
Ben benieuwd...

Volgens mij is vrijwel de volledige database dus in het geheugen geladen. (MDF bestand is 2.7GB groot)

Maar ja, alle inserts/updates/deletes moeten toch dubbel weggeschreven worden...

CPU gebruik hangt rond de 70%

Welk proces vreet zoveel CPU ?

[ Voor 26% gewijzigd door lier op 29-05-2006 13:22 ]

[P_de_B]

Ik ben het eens met degenen hierboven die aanraden om eerst eens fatsoenlijk erachter proberen te komen waar de bottleneck precies ligt.

Welke servicepack heb je? Voor optimale ondersteuning van de ADM64 moet je SP4 hebben. Je kunt zien welk servicepack je hebt door SELECT @@Version te doen.

[JasperE]

lier schreef op maandag 29 mei 2006 @ 13:20:
Waarom gelijk nieuwe hardware aanschaffen terwijl je nog geen eens een fatsoenlijke troubleshoot hebt uitgevoerd...

Die troubleshoot moet inderdaad gebeuren, daar heb ik ook al vele uren in gestoken, tot zover zonder veel resultaat. Maar zoals ik volgens mij al aangegeven heb, komt er sowieso een 2de server bij. De huidige gaat als *backup* server functioneren indien de hoofdserver uitvalt/doorbrand/op mysterieuse wijze verdwijnt.

Weet je bijvoorbeeld zeker dat je systeem de bottleneck is, of zou het ook aan het pakket/SQL kunnen liggen ? Heb je al eens de profiler gebruikt om te kijken of er iets scheef zit ? Hebben je clients wel de juiste specificaties ? Draait er niet een virusscanner "in de weg" ?

Die profiler heb ik gebruikt, zonder resultaat. Aan het pakket zou het goed kunnen liggen, helaas kunnen we daar niet zomaar vanaf stappen. De support erbij is zoals je al hebt kunnen lezen niet om vrolijk van te worden. (De ERP clients zijn 16bit ntvdm )

Welk proces vreet zoveel CPU ?

sqlservr.exe en MEDSVC.EXE

P_de_B schreef op maandag 29 mei 2006 @ 13:24:
Ik ben het eens met degenen hierboven die aanraden om eerst eens fatsoenlijk erachter proberen te komen waar de bottleneck precies ligt.

Welke servicepack heb je? Voor optimale ondersteuning van de ADM64 moet je SP4 hebben. Je kunt zien welk servicepack je hebt door SELECT @@Version te doen.

Resultaat:

Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

[MAX3400]

OD-Frozen schreef op maandag 29 mei 2006 @ 13:38:
[...]

Die troubleshoot moet inderdaad gebeuren, daar heb ik ook al vele uren in gestoken, tot zover zonder veel resultaat. Maar zoals ik volgens mij al aangegeven heb, komt er sowieso een 2de server bij. De huidige gaat als *backup* server functioneren indien de hoofdserver uitvalt/doorbrand/op mysterieuse wijze verdwijnt.

Dit klinkt enigszins amateuristisch... Als je een goede "backup"-server wil hebben; lijkt het me minstens slim dat ze hardware-matig gelijk zijn, waar nodig geclusterd zijn en de data ook centraal staat (dus niet op een RAID1 van server1). No offence, maar ik zou het nog maar eens overdenken om een andere machine als produktie-server neer te zetten en een volledig andere server als backup neer te zetten.

[Verwijderd]

denk ook aan de limitaties van de SQL server editie, die je gebruikt. standaard editie kan misschien niet meer dan 1gb geheugen gebruiken (ik dacht overigens 2GB), voor standaard editie mag je maar 1 cpu gebruiken, heb je een hyperthreading cpu (of 2 natuurlijk) dan kan het zijn dat sql toch op max cpu gebruik staat te blazen (wat overigens te verwachten is bij zware queries).

verder is een handige counter voor je disken de "runqueue", kijk even of deze niet ontzettend hoog wanneer je de traagheid ervaart (je hebt pas echt een bottle neck als deze over langere tijd op 2 of hoger staat).

[JasperE]

MAX3400 schreef op maandag 29 mei 2006 @ 13:41:
[...]

Dit klinkt enigszins amateuristisch... Als je een goede "backup"-server wil hebben; lijkt het me minstens slim dat ze hardware-matig gelijk zijn, waar nodig geclusterd zijn en de data ook centraal staat (dus niet op een RAID1 van server1). No offence, maar ik zou het nog maar eens overdenken om een andere machine als produktie-server neer te zetten en een volledig andere server als backup neer te zetten.

Laten we voorop stellen dat ik absoluut geen expert ben op dit gebied. Maar een 'mirror' sql kan je toch gewoon met replication oid bijhouden? En wat is er mis met instant-backup systeem achter de hand te hebben zonder eerst van tapes ed te hoeven inlezen?

denk ook aan de limitaties van de SQL server editie, die je gebruikt. standaard editie kan misschien niet meer dan 1gb geheugen gebruiken (ik dacht overigens 2GB), voor standaard editie mag je maar 1 cpu gebruiken, heb je een hyperthreading cpu (of 2 natuurlijk) dan kan het zijn dat sql toch op max cpu gebruik staat te blazen (wat overigens te verwachten is bij zware queries).

Als ik me niet vergis is dit een limiet van 2 cpu's en idd 2gb geheugen.

verder is een handige counter voor je disken de "runqueue", kijk even of deze niet ontzettend hoog wanneer je de traagheid ervaart (je hebt pas echt een bottle neck als deze over langere tijd op 2 of hoger staat).

De disk performance heb ik volgens verschillende performance guides al gemeten met perfmon.msc. Dit is niet de bottleneck voor zover ik kan zien.

[MAX3400]

OD-Frozen schreef op maandag 29 mei 2006 @ 13:53:
[...]

Laten we voorop stellen dat ik absoluut geen expert ben op dit gebied. Maar een 'mirror' sql kan je toch gewoon met replication oid bijhouden? En wat is er mis met instant-backup systeem achter de hand te hebben zonder eerst van tapes ed te hoeven inlezen?

Hoe ga je "instant replication" regelen? Constant produktie-databases kopieren naar backup? En wat als je produktie eruit klapt tijdens een replicatie-slag van 2.79GB aan database?

Dat je geen expert bent, is geen probleem, daarvoor kunnen we hier meedenken maar ik denk dat het zinvoller is om de volgende punten eerst te overdenken alvorens iets aan te schaffen:

- welk budget?
- wat is de vereiste uptime?
- welk OS, welke SQL-versie, welke rand-software?

Als ik kijk naar mijn bedrijf; alles wat een hoge uptime moet hebben en "vlekkeloos" onderuit moet kunnen gaan, draait in een cluster. Elke node in een apart rack; verbonden met glas naar een SAN. En voor 1 van onze SAN's gaan we zelfs zover dat er regelmatig disks worden verwisseld zodat de data ook veilig in een kluis ligt aangezien de nieuwe disk automatisch een rebuild krijgt op tijden van lage belasting van het SAN.

[JasperE]

MAX3400 schreef op maandag 29 mei 2006 @ 14:20:
[...]

Hoe ga je "instant replication" regelen? Constant produktie-databases kopieren naar backup? En wat als je produktie eruit klapt tijdens een replicatie-slag van 2.79GB aan database?

Nog niet aan gedacht, ik dacht dat dat bij iedere query zegmaar bijgewerkt werd

Dat je geen expert bent, is geen probleem, daarvoor kunnen we hier meedenken maar ik denk dat het zinvoller is om de volgende punten eerst te overdenken alvorens iets aan te schaffen:

- welk budget?

Budget is niet zozeer het probleem, als het maar sneller gaat werken. Juist deze grens stellen is waar mijn probleem ligt. Laten we zeggen rond de 4000 max??

- wat is de vereiste uptime?

Als ik het mijn baas zou vragen zou het antwoord 100% zijn. Liever wat investeren dan een halve dag geen ERP. Dan ligt alles plat hier.

- welk OS, welke SQL-versie, welke rand-software?

Momenteel dus win2000 met Microsoft SQL Server 2000 - 8.00.760 (Intel X86) Dec 17 2002 14:22:05 Copyright (c) 1988-2003 Microsoft Corporation Standard Edition on Windows NT 5.0 (Build 2195: Service Pack 4)

Rand software? 't is een SQL only server.

Als ik kijk naar mijn bedrijf; alles wat een hoge uptime moet hebben en "vlekkeloos" onderuit moet kunnen gaan, draait in een cluster. Elke node in een apart rack; verbonden met glas naar een SAN. En voor 1 van onze SAN's gaan we zelfs zover dat er regelmatig disks worden verwisseld zodat de data ook veilig in een kluis ligt aangezien de nieuwe disk automatisch een rebuild krijgt op tijden van lage belasting van het SAN.

Die disken verwisselen gebeurt hier ook op de servers. Clusteren niet

[ Voor 5% gewijzigd door JasperE op 29-05-2006 14:38 ]

[Verwijderd]

Manmanman, hier wordt je niet blij van en ik maak het steeds vaker mee. Incompetente developers die zelf niet in staat zijn hun SQL omgeving te optimaliseren en er alleen maar meer hardware tegen aan willen gooien, terwijl het probleem vaak in een inefficiente query oid zit.

Net als een aantal anderen wil ik je adviseren de profiler te proberen, soms lost dit het probleem op of brengt je op weg naar een oplossing.

Een andere oplossing die je kan toepassen (vooral als de leverancier/ontwikkelaar van het pakket niet meewerkt) is een DBA in de hand te nemen en hem een controle van de omgeving uit laten voeren.

[Verwijderd]

MAX3400 schreef op maandag 29 mei 2006 @ 14:20:
[...]

Hoe ga je "instant replication" regelen? Constant produktie-databases kopieren naar backup? En wat als je produktie eruit klapt tijdens een replicatie-slag van 2.79GB aan database?

Nou, met de replication mogelijkheden van SQL Server 2000 bijvoorbeeld? Elke x minuten repliceren, of realtime replication indien gewenst?
Gaat het in lokatie A fout dan heb je in elk geval een live draaiende kopie van je database op lokatie B.
Ik ken zelfs bedrijven die op deze manier hun databasejes verspreiden over meerdere sites, inclusief websites, en zo hun datauitwisselingen, redundante backups en klantcontact voor elkaar boxen.

Overigens zou ik als je performance omhoog moet en de suplier verdomt het mee te werken de accountmanager bellen en uitleggen dat er nog veel meer ERP boeren zijn, en dat de meeste anderen wél hun klanten willen helpen.

[ Voor 15% gewijzigd door Verwijderd op 29-05-2006 14:48 ]

[P_de_B]

MAX3400 schreef op maandag 29 mei 2006 @ 14:20:
[...]

Hoe ga je "instant replication" regelen? Constant produktie-databases kopieren naar backup? En wat als je produktie eruit klapt tijdens een replicatie-slag van 2.79GB aan database?

Dat je geen expert bent, is geen probleem, daarvoor kunnen we hier meedenken maar ik denk dat het zinvoller is om de volgende punten eerst te overdenken alvorens iets aan te schaffen:

gewoon repliceren, of anders log shipping

[MAX3400]

Het probleem is nu: performance is niet optimaal en men weet niet waarom.

Dan is dus de vraag: waarom een nieuwe bak kopen, dan met replicatie gaan werken zonder te weten of het vlekkelozer loopt?

Daarom geef ik aan dat er over replicatie en uptime goed moet worden nagedacht als je nieuwe spullen wil gaan kopen. En als ERP-leverancier weinig zinnigs erover te zeggen heeft, kan je net zo goed een Himalaya-server neerzetten a een paar ton maar nog steeds slechte performance hebben.

Ik ben het wel eens met bovenstaande antwoorden; replicatie kan op verschillende manieren, intervallen en dergelijke maar ikzelf heb niet de indruk dat replicatie tussen 2 volledig verschillende machines een goed idee is in geval van uitval van 1 van die machines...

[JasperE]

sql server profiler->
file new trace ->
template: tuning->
save to file: trace.trc ->
go


database engine tuning advisor ->
open trace file ->
select database "blah" ->
start analysis

Resultaat:
Een aantal gesuggereerde indexes voornamelijk op een aantal kleine tabellen.
Estimated percentage improvement: 0,00%

Niet echt nuttig dus.

[JasperE]

Weet iemand of er een tooltje bestaat waarmee je het percentage gebruikte FSB bandwidth kan zien?

[CH4OS]

OD-Frozen schreef op dinsdag 30 mei 2006 @ 08:35:
Weet iemand of er een tooltje bestaat waarmee je het percentage gebruikte FSB bandwidth kan zien?

Geheugen benchmarks?
Het (theoretische) maximaal haalbare weet je al, dat is bijvoorbeeld PC3200 (400MHz, DDR) voor 3200MB/sec PC3500 (433MHz, DDR) voor 3500MB/sec en so on...

Dan hoef je dus alleen nog maar even uit te rekenen hoeveel % je daadwerkelijk hebt, tegenover het theoretische maximaal haalbare...

[ Voor 43% gewijzigd door CH4OS op 30-05-2006 14:34 ]

[JasperE]

Dat je het kan benchmarken weet ik, maar om te kijken of dit nu de bottleneck is zou ik het graag realtime willen meten. Heb alleen nog geen software gezien die dit kan.

[MAX3400]

Ik lees even terug en zie het volgende...

puntje 1
"De 2GB wordt niet volledig benut"...
en later
"Volgens mij is vrijwel de volledige database dus in het geheugen geladen. (MDF bestand is 2.7GB groot)"

Oftewel; zit je niet naar de verkeerde parameters te kijken tijdens het monitoren?

puntje 2
"...piekt het cpu gebruik namelijk niet, dit hangt ergens rond de 70%. Ook het cpu gebruik op de client is nog ruim binnen de marges..."

Misschien is mijn kennis van SQL niet voldoende maar waarom wordt er ook gesproken over de client-CPU? Die zal theoretisch, tijdens een query op de SQL-bak, niets staan te doen m.u.v. draaiende processen?

puntje 3
Idee; is het ERP dusdanig crap aangeleverd of geconfigureerd dat de queries die men dagelijks opvraagt, als real-time query worden behandeld of zijn het stored procedures? Voor zover ik weet kan dat ook nog een slok op een borrel schelen.

puntje 4
Is er ook al gekeken naar randvoorwaarden op de server zelf zoals caching, CPU-priority en dergelijke?

[ Voor 3% gewijzigd door MAX3400 op 31-05-2006 10:14 ]

[P_de_B]

Puntje 3 is sinds SQL7 al niet meer van toepassing.

[MAX3400]

P_de_B schreef op woensdag 31 mei 2006 @ 10:15:
Puntje 3 is sinds SQL7 al niet meer van toepassing.

Goed punt; vooral omdat er nog steeds in SQL 2005 opleidingen over wordt gesproken? Plus het algemene feit dat een stored procedure valt onder cached transaction en dus veel minder load op een server kan leggen dan al die ad-hoc queries van gebruikers?

De werking is iets anders, maar stored procedures hebben nog steeds zin.

[P_de_B]

MAX3400 schreef op woensdag 31 mei 2006 @ 10:26:
[...]

Goed punt; vooral omdat er nog steeds in SQL 2005 opleidingen over wordt gesproken? Plus het algemene feit dat een stored procedure valt onder cached transaction en dus veel minder load op een server kan leggen dan al die ad-hoc queries van gebruikers?

De werking is iets anders, maar stored procedures hebben nog steeds zin.

Nee, ook geparamteriseerde ad-hoq queries hebben het voordeel dat het executieplan wordt gecached. Dat voordeel is al lang niet meer exclusief voor stored procedures.
Als er in de SQL 2005 opleidingen over gesproken wordt zijn de opleidingen fout.

[Wirf]

OD-Frozen schreef op maandag 29 mei 2006 @ 16:07:
sql server profiler->
file new trace ->
template: tuning->
save to file: trace.trc ->
go

Kijk anders zelf eens wat de langst durende queries zijn, dan kun je zelf wat gerichter zoeken.

Verder kan het ook zo zijn dat je ERP systeem veel tabellen lockt, als dat zo is gaat de performance vrij snel naar beneden als je met meerdere mensen tegelijk werkt. Extra hardware zal hierbij dan ook weinig helpen. Dan moeten de queries aangepast worden die het ERP systeem maakt.

_{* Wirf ontwikkeld ERP systemen op MSSQL. Wij lossen bugs altijd kostenloos op}

[weerdo]

P_de_B schreef op woensdag 31 mei 2006 @ 10:29:
Nee, ook geparamteriseerde ad-hoq queries hebben het voordeel dat het executieplan wordt gecached. Dat voordeel is al lang niet meer exclusief voor stored procedures.

Ik zou dit niet te hard willen stellen. Aan de caching van ad hoc queryplans in MSSQL 2000 zitten behoorlijk wat haken en ogen. Zie het stuk "Execution Plan Caching and Reuse" uit SQL Server Books online, waarin dit proces beschreven wordt. (En volgens mij is dit gedeelte in MSSQL 2005 niet drastisch veranderd)

De belangrijkste quote daaruit is:

The algorithms to match new SQL statements to existing, unused execution plans in the cache require that all object references be fully qualified. For example, the first of these SELECT statements is not matched with an existing plan, and the second is matched:

SELECT * FROM Employees

SELECT * FROM Northwind.dbo.Employees

Bij een stored proc speelt dit probleem niet, omdat alles daarin van te voren volledig vastgesteld wordt. Bij Ad hoc queries hoeft dit helemaal niet het geval te zijn, reden voor Microsoft om het gebruik van stored procs nog steeds te adviseren.

Overigs het probleem eenvoudig te diagnostiseren: de performance counters "SQL Compilations/sec" en "SQL Re-Compilations/sec" bieden hiervoor genoeg uitsluitsel. Ook kan een korte blik met de SQL profiler genoeg uitsluitsel geven over het gebruik van fully qualified object references in ad hoc queries.

[P_de_B]

Fully qualified naming is sowieso wel een goed idee. Ik zou niet als reden voor sp's geven "Dat wordt het execution plan hergebruikt ook als je geen 4 delige naamgeving gebruikt".

Overigens is die discussie offtopic hier. In [rml][ ALG] zeg nee tegen Stored Procedures *[/rml] staat heel veel informatie en inzichten

[JasperE]

MAX3400 schreef op woensdag 31 mei 2006 @ 10:14:
Ik lees even terug en zie het volgende...

puntje 1
"De 2GB wordt niet volledig benut"...
en later
"Volgens mij is vrijwel de volledige database dus in het geheugen geladen. (MDF bestand is 2.7GB groot)"

Oftewel; zit je niet naar de verkeerde parameters te kijken tijdens het monitoren?

Goed gezien, maar blijkbaar hoeven niet alle tabellen blijkbaar in het geheugen te zitten. Ik zal even rephrasen: "Volgens mij zijn alle regelmatig aangesproken tabellen in het geheugen geladen". Ik ben er vrijwel zeker van dat de HDD niet de bottleneck omdat:
- De disk wait time in permon.msc 99% van de tijd op 0 staat
- De disk lampjes tijdens heftige bewerking niet harder knipperen dan wanneer idle
- De disk geen hoorbare geluiden maakt tijdens die bewerking en wel wanneer je bijvoorbeeld de eigenschappen van c:\windows opvraagt (dan gaat windows de grootte bepalen)

puntje 2
"...piekt het cpu gebruik namelijk niet, dit hangt ergens rond de 70%. Ook het cpu gebruik op de client is nog ruim binnen de marges..."

Misschien is mijn kennis van SQL niet voldoende maar waarom wordt er ook gesproken over de client-CPU? Die zal theoretisch, tijdens een query op de SQL-bak, niets staan te doen m.u.v. draaiende processen?

Als het cpu gebruik op de ERP clients maximaal is zouden de clients trager zijn dan de SQL server. Ze zouden dan theoretisch niet zoveel queries kunnen versturen om de SQL server volledig te belasten.

puntje 3
Idee; is het ERP dusdanig crap aangeleverd of geconfigureerd dat de queries die men dagelijks opvraagt, als real-time query worden behandeld of zijn het stored procedures? Voor zover ik weet kan dat ook nog een slok op een borrel schelen.

Ik zou het eerlijk gezegd niet weten, ik heb geen toegang tot de source van het ERP pakket en kan deze ook niet wijzigen. In SQL management studio staan er geen stored procedures bij de tabel.

puntje 4
Is er ook al gekeken naar randvoorwaarden op de server zelf zoals caching, CPU-priority en dergelijke?

Jep, verschillende van die performance guides afgelopen die cache hit ratio enzo beschrijven. Alles valt binnen de normen die daar gesteld worden.

Wirf schreef op woensdag 31 mei 2006 @ 10:33:
[...]


Kijk anders zelf eens wat de langst durende queries zijn, dan kun je zelf wat gerichter zoeken.

Veel van de queries begrijp ik niet, bovendien heb ik niets aan die kennis aangezien ik het pakket toch niet kan wijzigen.

Verder kan het ook zo zijn dat je ERP systeem veel tabellen lockt, als dat zo is gaat de performance vrij snel naar beneden als je met meerdere mensen tegelijk werkt. Extra hardware zal hierbij dan ook weinig helpen. Dan moeten de queries aangepast worden die het ERP systeem maakt.

Er wordt inderdaad veel gelocked denk ik, helaas kan ik de ERP source niet wijzigen.... Daar zeg je me wel wat, is er iets waarmee je kan zien hoe lang SQL wacht op het vrijkomen van de locks??? Als dit de bottleneck zou zijn is er weinig wat we daar aan zouden kunnen verbeteren

[Wirf]

OD-Frozen schreef op woensdag 31 mei 2006 @ 13:27:
Veel van de queries begrijp ik niet, bovendien heb ik niets aan die kennis aangezien ik het pakket toch niet kan wijzigen.

Je zou indexen zelf kunnen aanleggen, als er bijvoorbeeld deze query staat:

select * from inkooporders order by inkoopordernummer

dan zou je een index kunnen aanleggen over de inkoopordernummers, eventueel clustered voor nog wat meer performance.

Er wordt inderdaad veel gelocked denk ik, helaas kan ik de ERP source niet wijzigen.... Daar zeg je me wel wat, is er iets waarmee je kan zien hoe lang SQL wacht op het vrijkomen van de locks??? Als dit de bottleneck zou zijn is er weinig wat we daar aan zouden kunnen verbeteren

Ik weet zo niet of je kunt zien hoe lang de locks duren, maar ik weet wel hoe je kunt zien welke locks er op dit moment zijn.

Open de Enterprise manager, open je server, ga naar het mapje "management", klik op "Current activity"
Hier kun je de locks per process ID zien en ook per object (per tabel zeg maar)


Is anders een compleet ander ERP systeem niet wat voor je? Ben je nog wel tevreden met het huidige pakket?

[Wirf]

Verder nog wat puntjes voor de aanschaf van een nieuwe server:

- Dual CPU machine's zijn volgens mijn collega's echt een _STUK_ sneller voor SQL server (zelf heb ik hier weinig ervaring mee)
- Gebruik GEEN raid5, gebruik hiervoor in de plaats Raid 1 of Raid 10. De schrijf performance (wat bij databases toch vaak voorkomt) is te laag bij raid5
- Gebruik verschillende schijven/raidsets voor de pagefile/os, tempDB, log (.ldf) files en data files (.mdf) op die manier zitten de verschillende activiteiten zo min mogelijk elkaar "in de weg"
- Gebruik natuurlijk snelle, serverclass hardware: Dit is de kern van je bedrijf, ik zou er niet op bezuinigen (10/15k schijven, SCSI, XEON, RAID, IBM dat soort termen, geen 7200, IDE, SATA, Trust)

[MAX3400]

Wirf schreef op woensdag 31 mei 2006 @ 17:29:
Verder nog wat puntjes voor de aanschaf van een nieuwe server:

- Dual CPU machine's zijn volgens mijn collega's echt een _STUK_ sneller voor SQL server (zelf heb ik hier weinig ervaring mee)
- Gebruik GEEN raid5, gebruik hiervoor in de plaats Raid 1 of Raid 10. De schrijf performance (wat bij databases toch vaak voorkomt) is te laag bij raid5
- Gebruik verschillende schijven/raidsets voor de pagefile/os, tempDB, log (.ldf) files en data files (.mdf) of die manier zitten de verschillende activiteiten zo min mogelijk elkaar "in de weg"

Een single HyperThreading CPU is voldoende voor de meeste database-servers.
RAID1 is inderdaad een slimme oplossing, maar dat wel 2 sets. Eentje voor de databases en eentje voor OS, logs etc.

- Gebruik natuurlijk snelle, serverclass hardware: Dit is de kern van je bedrijf, ik zou er niet op bezuinigen (10/15k schijven, SCSI, XEON, RAID, IBM dat soort termen, geen 7200, IDE, SATA, Trust)

De opkomst van SATA is aanzienlijk en doet in het hogere segment echt niet onder voor 10K SCSI.

IBM is ongeveer wel de laatste die je aan moet schaffen; een mooie DL380 van HP met wat extra toeters/bellen geeft wat mij betreft 4x meer ruwe performance dan wat je nu hebt staan (zonder de garantie dat je ERP-pakket dus beter loopt).

[JasperE]

Ik zie een 30-tal Locks,
Type: DB,
Mode: S
Status: GRANT
Request owner: Sess
Object: Naam vd database