---

Vi har p.t. én Windows 2000 server i firmaet, som køre både som web og SQL
server. Nu er den ved at blive for lille (ligger typisk på 80% CPU load), så
vi skal have fundet en anden løsning. Det er klart SQL serveren der trækker
flest ressourcer (70GB SQL database).

En måde at udvide systemet på, kunne selvfølgelig være, at splitte web og
SQL server op i to servere. Det ville give lidt ekstra CPU tid til SQL
serveren, men det er en stakket frist. Vi køre i forvejen med flere RAID1
arrays til henholdsvis databasen, temp.db, trans.log og OS m.v. så på dét
område kan vi ikke gøre så meget mere (tror jeg).

Hvordan udvider vi bedst kapaciteten på vores SQL server? Jeg har selv tænkt
på at have to eller flere SQL servere og så ét fælles disk array til SQL
databasen (SAN eller DAS?), men jeg ved ikke nok om det. Det vil jo kræve,
at webserveren kan dele belastningen ud imellem de tre SQL servere og at de
tre SQL serveren kan deles om det fælles database lager på SAN/DAS.

OS: Windows 2000 server
Server: Intel server med 10 diske i RAID1 arrays
CPU: 1 x Xeon 2,8GHz (snart kommer der en ekstra CPU i)
RAM: 3GB (2GB afsat til SQL)

Forslag modtages gerne

---

On Fri, 22 Oct 2004 11:58:21 +0200, Dingo wrote:

> Vi har p.t. én Windows 2000 server i firmaet, som køre både som web og SQL
> server. Nu er den ved at blive for lille (ligger typisk på 80% CPU load), så
> vi skal have fundet en anden løsning. Det er klart SQL serveren der trækker
> flest ressourcer (70GB SQL database).

Er det web-aktivitet, der giver databasen det høje load? (Det fremgår
ikke tydeligt af din mail.)

Hvis "ja": Hvor "dynamiske" er jeres web-sider? - Kan (evt. kun dele af)
de mest besøgte fx. tåle at blive cache'et et par minutter, eller måske
endda længere? - Så kig evt. på http://troels.arvin.dk/linuxforum2003/

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

> Er det web-aktivitet, der giver databasen det høje load? (Det fremgår
> ikke tydeligt af din mail.)

Det er udelukkende web aktivitet der generére det høje SQL forbrug.

> Hvis "ja": Hvor "dynamiske" er jeres web-sider? - Kan (evt. kun dele af)
> de mest besøgte fx. tåle at blive cache'et et par minutter, eller måske
> endda længere? - Så kig evt. på http://troels.arvin.dk/linuxforum2003/

Det skal være fuldt opdaterede data på websiden, så de kan nok ikke tåle at
blive cachet.

---

Split ud i to maskiner, og få en DB server med flere CPU. Prop maskinen med
ram - forbind de to med gigabit direkte - udenom det almindelige switchede
netværk.

Kig på det genererede sql - hvad er det tungeste ?? - kan det optimeres
yderligere (undgå reverse sorts, full table scans og prøv at have where
clause der rammer godt index i base tabellen).

Er det ikke nok - så skal i måske splitte basen i flere - på flere
servere...


/Henrik
"Dingo" <dingo@invalid.invalid> wrote in message
news:4178df9b$0$228$edfadb0f@dread11.news.tele.dk...
>> Er det web-aktivitet, der giver databasen det høje load? (Det fremgår
>> ikke tydeligt af din mail.)
>
> Det er udelukkende web aktivitet der generére det høje SQL forbrug.
>
>> Hvis "ja": Hvor "dynamiske" er jeres web-sider? - Kan (evt. kun dele af)
>> de mest besøgte fx. tåle at blive cache'et et par minutter, eller måske
>> endda længere? - Så kig evt. på http://troels.arvin.dk/linuxforum2003/
>
> Det skal være fuldt opdaterede data på websiden, så de kan nok ikke tåle
> at blive cachet.
>
>

---

> Split ud i to maskiner, og få en DB server med flere CPU. Prop maskinen
> med ram - forbind de to med gigabit direkte - udenom det almindelige
> switchede netværk.

Jeg kan ikke helt vurdere hvad der er billigst (jeg har ikke set p åpriser
endnu). Hvad er billigst - at få én mega server med masser af RAM (16GB?) og
f.eks. 4 CPU'er (det vil vel kræve en Windows Advanced Server?) eller at få
4 mindre servere med et fælles SQL lager (SAN/DAS)?

> Kig på det genererede sql - hvad er det tungeste ?? - kan det optimeres
> yderligere (undgå reverse sorts, full table scans og prøv at have where
> clause der rammer godt index i base tabellen).

Jeg tager mig ikke af selve SQL "inside", men jeg tror at de som sidder med
det, har rimeligt styr på det. Selvfølgelig kan der sikkert være nogle
småting, men næppe noget der giver nogen væsentligt mærkbar forbedring på
det nuværende.

---

I dit tilfælde er det cpuer først: og så nok ram per cpu.
Bemærk evt issues med licens til sql med multicpu.
det behøves ikke at være advanced server - men bare en 1-4 SMP licens

Om SQL Inside: det er altid der det koster: mest med mindre du har
rigtig-rigtig mange besøgende på een gang.

ad SAN: ja det kan være en fordel: alternativt (og meget billigere): Raid 5
med SCSI ultra 320 - Meget hurtig read lidt langsommere til write. Husk:
Raid Controller med batteribackup = hurtigere skriv.

Personligt er jeg til 4xcpu + max ram + raid5.

/Henrik

"Dingo" <dingo@invalid.invalid> wrote in message
news:4178f256$0$306$edfadb0f@dread11.news.tele.dk...
>> Split ud i to maskiner, og få en DB server med flere CPU. Prop maskinen
>> med ram - forbind de to med gigabit direkte - udenom det almindelige
>> switchede netværk.
>
> Jeg kan ikke helt vurdere hvad der er billigst (jeg har ikke set p åpriser
> endnu). Hvad er billigst - at få én mega server med masser af RAM (16GB?)
> og f.eks. 4 CPU'er (det vil vel kræve en Windows Advanced Server?) eller
> at få 4 mindre servere med et fælles SQL lager (SAN/DAS)?
>
>> Kig på det genererede sql - hvad er det tungeste ?? - kan det optimeres
>> yderligere (undgå reverse sorts, full table scans og prøv at have where
>> clause der rammer godt index i base tabellen).
>
> Jeg tager mig ikke af selve SQL "inside", men jeg tror at de som sidder
> med det, har rimeligt styr på det. Selvfølgelig kan der sikkert være nogle
> småting, men næppe noget der giver nogen væsentligt mærkbar forbedring på
> det nuværende.
>
>

---

On Sat, 23 Oct 2004 21:26:50 +0200, Henrik Ohm Eriksen wrote:

> alternativt (og meget billigere): Raid 5 med SCSI ultra 320

Jeg synes at høre, at folk generelt anbefaler RAID 10 til krævende
databasesystemer. RAID 10 er lidt mere disk-krævende end RAID 5, men mon
ikke det er pengene værd her?

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Tak for tilbagemelding.

>I dit tilfælde er det cpuer først: og så nok ram per cpu.
> Bemærk evt issues med licens til sql med multicpu.
> det behøves ikke at være advanced server - men bare en 1-4 SMP licens

Jeg mener ikke at en Windows 2000 Server kan bruge mere end 4GB RAM... og
SQL serveren skal "tweakes", hvis den skal bruge mere end 3GB. Derfor bør
man vel have en 2000 Advanced Server og en... Enterprise(?) SQL?

> Om SQL Inside: det er altid der det koster: mest med mindre du har
> rigtig-rigtig mange besøgende på een gang.

Undskyld, men den forstod jeg ikke helt? Hvad koster?

> ad SAN: ja det kan være en fordel: alternativt (og meget billigere): Raid
> 5 med SCSI ultra 320 - Meget hurtig read lidt langsommere til write. Husk:
> Raid Controller med batteribackup = hurtigere skriv.

Som Troels også skriver, så synes jeg at jeg har læst, at RAID5 ikke er den
mest velegnede til SQL databaser men, at det hellere skulle være en RAID1
(og helt perfekt med en RAID01).

> Personligt er jeg til 4xcpu + max ram + raid5.

Det er helt klart en løsning... men den er bare ikke så fleksibel. Når vi så
når grænsen med de 4 CPU'er, så skal vi igen have en ny-installation og en
ny server. Det ville være smartest, hvis man "bare" kunne udvide med endnu
en server.

Men jeg ved jo selvfølgelig godt, at alting er en opvejelse mellem pris og
funktionallitet.

---

Hej Alle,

Raid 10 vs Radi 5: Ja - men som nævnt noget dyrere i disk.

Du har vist ret mht til Ram og os - men jeg er ikke 100% sikker - de sql
servere jeg har kørende er med 4gb - og er standard sql 2000 servere med
win2000 server - jeg allokerer de 3936mb via automatic mem allocation til
sql - uden problemer.

Om SQL Inside: Det der trækker tænder ud (koster) i databaser er altid
SQL'en der bliver genereret - selects mv. Derfor er det også vigtigt at
checke at de tungeste selects bliver optimeret - du kan fylde maskinen med
cpu & ram men den vil stadig blive voldsomt belastet hvis der er "dårlig"
sql. Forskellen på god og dårlig sql og godt eller dårligt index kan nemt
være en faktor 10 eller mere.

Hvis begrænsningen på 4x cpu er et reelt problem - så skal du kigge på
loadbalancing og clustering (active/active) løsninger - men det koster jo
også en del penge.

Jeg tror at opgraderingen fra delt server til DB på egen server der er
heftigt speccet vil give meget luft: derfra vill jeg angribe SQL SELECTS og
Index - og derefter ville jeg overveje loadbalancing eller clustering eller
at splitte databasen ud på flere servere.


/Henrik




"Dingo" <dingo@invalid.invalid> wrote in message
news:417cc130$0$184$edfadb0f@dread11.news.tele.dk...
> Tak for tilbagemelding.
>
>>I dit tilfælde er det cpuer først: og så nok ram per cpu.
>> Bemærk evt issues med licens til sql med multicpu.
>> det behøves ikke at være advanced server - men bare en 1-4 SMP licens
>
> Jeg mener ikke at en Windows 2000 Server kan bruge mere end 4GB RAM... og
> SQL serveren skal "tweakes", hvis den skal bruge mere end 3GB. Derfor bør
> man vel have en 2000 Advanced Server og en... Enterprise(?) SQL?
>
>> Om SQL Inside: det er altid der det koster: mest med mindre du har
>> rigtig-rigtig mange besøgende på een gang.
>
> Undskyld, men den forstod jeg ikke helt? Hvad koster?
>
>> ad SAN: ja det kan være en fordel: alternativt (og meget billigere): Raid
>> 5 med SCSI ultra 320 - Meget hurtig read lidt langsommere til write.
>> Husk: Raid Controller med batteribackup = hurtigere skriv.
>
> Som Troels også skriver, så synes jeg at jeg har læst, at RAID5 ikke er
> den mest velegnede til SQL databaser men, at det hellere skulle være en
> RAID1 (og helt perfekt med en RAID01).
>
>> Personligt er jeg til 4xcpu + max ram + raid5.
>
> Det er helt klart en løsning... men den er bare ikke så fleksibel. Når vi
> så når grænsen med de 4 CPU'er, så skal vi igen have en ny-installation og
> en ny server. Det ville være smartest, hvis man "bare" kunne udvide med
> endnu en server.
>
> Men jeg ved jo selvfølgelig godt, at alting er en opvejelse mellem pris og
> funktionallitet.
>
>

---

> Du har vist ret mht til Ram og os - men jeg er ikke 100% sikker - de sql
> servere jeg har kørende er med 4gb - og er standard sql 2000 servere med
> win2000 server - jeg allokerer de 3936mb via automatic mem allocation til
> sql - uden problemer.

Jeg er nu ikke sikker på, at du udnytter de 3936MB fuldt ud til SQL
serveren, da Win2K server og SQL2K Std. kun kan udnytte maks 3GB, så vidt
som jeg kan forstå på dette link,
http://www.sql-server-performance.com/awe_memory.asp
Dvs. at hvis du har sat /3GB option i din boot.ini, så kan du maks udnytte
3GB istedet for kun de 2GB som er standard.

Dvs. at man rent faktisk skal have en Windows 2000 Datacenter server med SQL
Enterprise for at udnytte f.eks. 9GB RAM.

> Om SQL Inside: Det der trækker tænder ud (koster) i databaser er altid
> SQL'en der bliver genereret - selects mv. Derfor er det også vigtigt at
> checke at de tungeste selects bliver optimeret - du kan fylde maskinen med
[CUT]

Ja, det er klart. Men det tror jeg også, at der er nogenlunde styr på.

> Hvis begrænsningen på 4x cpu er et reelt problem - så skal du kigge på
> loadbalancing og clustering (active/active) løsninger - men det koster jo
> også en del penge.

Helt sikkert - og det er sikkert også vedligeholdelses tungt og kræver en
ekspert for at opsætte det.

---

Hmm,

Jeg ser nu allokeringen af de 3.9GB via Properties på min SQL Se4rver
Instance in Enterprise Manager. Jeg har ikke lavet noget specielt om - om
memory bliver allokeret når DB'en har kørt et stykke tid...

Som Jeg læser linket så er det over 4gb der kræver enterprise plus lidt
fiksfakserier.

Men jeg skal ikke sige mig fri - jeg bruger Oracle 9i Enterprise til de helt
store opgaver (100gb+ DB'er)..

/Henrik
"Dingo" <dingo@invalid.invalid> wrote in message
news:417cd3a2$0$192$edfadb0f@dread11.news.tele.dk...
>> Du har vist ret mht til Ram og os - men jeg er ikke 100% sikker - de sql
>> servere jeg har kørende er med 4gb - og er standard sql 2000 servere med
>> win2000 server - jeg allokerer de 3936mb via automatic mem allocation til
>> sql - uden problemer.
>
> Jeg er nu ikke sikker på, at du udnytter de 3936MB fuldt ud til SQL
> serveren, da Win2K server og SQL2K Std. kun kan udnytte maks 3GB, så vidt
> som jeg kan forstå på dette link,
> http://www.sql-server-performance.com/awe_memory.asp
> Dvs. at hvis du har sat /3GB option i din boot.ini, så kan du maks udnytte
> 3GB istedet for kun de 2GB som er standard.
>
> Dvs. at man rent faktisk skal have en Windows 2000 Datacenter server med
> SQL Enterprise for at udnytte f.eks. 9GB RAM.
>
>> Om SQL Inside: Det der trækker tænder ud (koster) i databaser er altid
>> SQL'en der bliver genereret - selects mv. Derfor er det også vigtigt at
>> checke at de tungeste selects bliver optimeret - du kan fylde maskinen
>> med
> [CUT]
>
> Ja, det er klart. Men det tror jeg også, at der er nogenlunde styr på.
>
>> Hvis begrænsningen på 4x cpu er et reelt problem - så skal du kigge på
>> loadbalancing og clustering (active/active) løsninger - men det koster jo
>> også en del penge.
>
> Helt sikkert - og det er sikkert også vedligeholdelses tungt og kræver en
> ekspert for at opsætte det.
>
>

---

> Jeg ser nu allokeringen af de 3.9GB via Properties på min SQL Se4rver
> Instance in Enterprise Manager. Jeg har ikke lavet noget specielt om - om
> memory bliver allokeret når DB'en har kørt et stykke tid...
>
> Som Jeg læser linket så er det over 4gb der kræver enterprise plus lidt
> fiksfakserier.

Citat:

"The /3GB switch is used to tell SQL Server to take advantage of 3GB out of
the base 4GB of RAM that Windows 2000 supports natively. If you don't
specify this option, then SQL Server will only take advantage of 2GB of the
first 4GB of RAM in the server, essentially wasting 1GB of RAM."

Den forstår jeg helt klart som om, at den maks kan udnytte 2GB og at hvis
den skriver andet, så er det spildt RAM (fordi det ikke udnyttes).

> Men jeg skal ikke sige mig fri - jeg bruger Oracle 9i Enterprise til de
> helt store opgaver (100gb+ DB'er)..

Det var jo også en slags database må man sige. Men hvorfor Oracle? Er SQL
ikke god nok til så store databaser (jeg spørger fordi jeg ikke ved det)?

---

hmm.
om de 3 gb så synes jeg det lyder lidt udnerligt - jeg ved ikke om en
service pack til slq kan finde på at sætte den switch. men det er da også
ligemeget - bare mssql kan bruge rammen.

Oracle er helt klart bedre når der er tale om performance krævende og store
databaser - alene af den årsag at man har meget bedre kontrol med
fordelingen af tabeller, indexes og så videre hen over forskellige devices
mv.

Der er sikkert noget religion i det også

Oracle Enterprise er vist også lidt dyrere....

/hennrik

"Dingo" <dingo@invalid.invalid> wrote in message
news:417e1063$0$182$edfadb0f@dread11.news.tele.dk...
>> Jeg ser nu allokeringen af de 3.9GB via Properties på min SQL Se4rver
>> Instance in Enterprise Manager. Jeg har ikke lavet noget specielt om - om
>> memory bliver allokeret når DB'en har kørt et stykke tid...
>>
>> Som Jeg læser linket så er det over 4gb der kræver enterprise plus lidt
>> fiksfakserier.
>
> Citat:
>
> "The /3GB switch is used to tell SQL Server to take advantage of 3GB out
> of the base 4GB of RAM that Windows 2000 supports natively. If you don't
> specify this option, then SQL Server will only take advantage of 2GB of
> the first 4GB of RAM in the server, essentially wasting 1GB of RAM."
>
> Den forstår jeg helt klart som om, at den maks kan udnytte 2GB og at hvis
> den skriver andet, så er det spildt RAM (fordi det ikke udnyttes).
>
>> Men jeg skal ikke sige mig fri - jeg bruger Oracle 9i Enterprise til de
>> helt store opgaver (100gb+ DB'er)..
>
> Det var jo også en slags database må man sige. Men hvorfor Oracle? Er SQL
> ikke god nok til så store databaser (jeg spørger fordi jeg ikke ved det)?
>
>

---

> Oracle Enterprise er vist også lidt dyrere....

Hvordan definerer du lidt?
SVJH er der tale om en faktor 2 pr. processor.

--
Mvh. Jesper

---

som i jeg ikke er den der skal betale for licenserne i sidste ende


/Henrik
"Jesper Nielsen" <jn@nielsenit.invalid> wrote in message
news:Re4hd.61072$Vf.2935245@news000.worldonline.dk...
>> Oracle Enterprise er vist også lidt dyrere....
>
> Hvordan definerer du lidt?
> SVJH er der tale om en faktor 2 pr. processor.
>
> --
> Mvh. Jesper
>
>

---

Henrik Ohm Eriksen wrote:
> Om SQL Inside: Det der trækker tænder ud (koster) i databaser er altid
> SQL'en der bliver genereret - selects mv. Derfor er det også vigtigt at
> checke at de tungeste selects bliver optimeret - du kan fylde maskinen med
> cpu & ram men den vil stadig blive voldsomt belastet hvis der er "dårlig"
> sql. Forskellen på god og dårlig sql og godt eller dårligt index kan nemt
> være en faktor 10 eller mere.
>
Helt korrekt! Det er vigtigt at se på de stored procedures osv, der
afvikles, for at se hvad der er mest ressourcekrævende. Måske skal der
tweakes, måske skal der vælges et andet design/måde at manipulere data.

> Hvis begrænsningen på 4x cpu er et reelt problem - så skal du kigge på
> loadbalancing og clustering (active/active) løsninger - men det koster jo
> også en del penge.
>
Desværre har MS SQL Server ikke samme muligheder for "rigtig" load
balancing. Hvis det skal fungere rigtigt, skal det være indbygget i
databasen, og det har MS SQL Server ikke. Oracle 9i er et eksempel på en
database som har dette indbygget.

> Jeg tror at opgraderingen fra delt server til DB på egen server der er
> heftigt speccet vil give meget luft: derfra vill jeg angribe SQL SELECTS og
> Index - og derefter ville jeg overveje loadbalancing eller clustering eller
> at splitte databasen ud på flere servere.
>
Helt enig. Desuden kan man jo overveje at kigge på databasedesignet og
overveje at flytte nogle af tabellerne og forespørgslerne over på en
anden maskine.

Mvh
Jeppe

---

Dingo wrote:

> Vi har p.t. én Windows 2000 server i firmaet, som køre både som web og SQL
> server. Nu er den ved at blive for lille (ligger typisk på 80% CPU load), så
> vi skal have fundet en anden løsning. Det er klart SQL serveren der trækker
> flest ressourcer (70GB SQL database).
>
> En måde at udvide systemet på, kunne selvfølgelig være, at splitte web og
> SQL server op i to servere. Det ville give lidt ekstra CPU tid til SQL
> serveren, men det er en stakket frist. Vi køre i forvejen med flere RAID1
> arrays til henholdsvis databasen, temp.db, trans.log og OS m.v. så på dét
> område kan vi ikke gøre så meget mere (tror jeg).
>
> Hvordan udvider vi bedst kapaciteten på vores SQL server? Jeg har selv tænkt
> på at have to eller flere SQL servere og så ét fælles disk array til SQL
> databasen (SAN eller DAS?), men jeg ved ikke nok om det. Det vil jo kræve,
> at webserveren kan dele belastningen ud imellem de tre SQL servere og at de
> tre SQL serveren kan deles om det fælles database lager på SAN/DAS.
>
> OS: Windows 2000 server
> Server: Intel server med 10 diske i RAID1 arrays
> CPU: 1 x Xeon 2,8GHz (snart kommer der en ekstra CPU i)
> RAM: 3GB (2GB afsat til SQL)
>
> Forslag modtages gerne
>
>
Det lyder som om du har to problemer:
1) Diskplads til dine SQL Server data
2) Performance på din SQL Server

Mht. diskplads, så vil jeg foreslå at kigge på SAN, men jeg har desværre
ikke nogen praktisk erfaring med dette.

Hvis vi talte om webservere, ville det være forholdsvis enkelt at lave
loadbalancing, men nu hvor vi taler om SQL Server, er denne mulighed
nærmest ikke-eksisterende. SQL Server har nemlig ikke nogen indbygget
feature til at lave loadbalancing (som fx Oracle 9i har).

Den bedste mulighed du har er at få fat i det hurtigste hardware du har
råd til og så ellers tune din base son ind i h...... Såfremt hurtigere
hardware ikke løser dit problem, må du kigge på at flytte visse ting fra
din SQL Server over på en anden maskine. Det kan fx være filer som
gemmes i databasen, som kan flyttes på filsystemet, eller bestemte
ressourcekrævende tabller/forespørgsler som som laves i en database på
en anden maskine.

Mvh
Jeppe

---

> Det lyder som om du har to problemer:
> 1) Diskplads til dine SQL Server data
> 2) Performance på din SQL Server

1) Nej, rent pladsmæssigt har vi rigeligt plads.

> Den bedste mulighed du har er at få fat i det hurtigste hardware du har
> råd til og så ellers tune din base son ind i h...... Såfremt hurtigere
> hardware ikke løser dit problem, må du kigge på at flytte visse ting fra
> din SQL Server over på en anden maskine. Det kan fx være filer som gemmes
> i databasen, som kan flyttes på filsystemet, eller bestemte
> ressourcekrævende tabller/forespørgsler som som laves i en database på en
> anden maskine.

Tak for info.