SQL Server op Server 2012 vragen

[HellStorm666]

Hallo allemaal,

Momenteel draait hier een Windows Server 2008 R2 met een X3450 @ 2,66Ghz en 8GB Ram.
Deze server wordt gebruikt voor Product Stream Pro.
Er draait een Microsoft SQL database op (ongeveer 1GB groot momenteel) en de dataopslag is zo'n 1TB. (Beide zullen nog groeien)
Momenteel is er een 250GB HDD (SATA) voor het OS.
2x een 2TB HDD (SATA) in mirror voor de Database en data.
1x een 2TB (STAT) voor losse backups.

Omdat er momenteel weer een upgrade/overstap aan zit te komen (Product Stream Pro wordt vervangen door Vault, Inventor Pro gaat naar 2015, enz.) en de huidige server al een upgrade van een upgrade is, willen we van scratch af aan beginnen en de data migreren naar de nieuwe server.

De nieuwe server (ex-ESXi server) is een Dell T310.
Hierop komt Windows Server 2012.
x3430 @2,4Ghz (De CPU gaan we waarschijnlijk nog wisselen, zodat de X3450 hier in komt)
16GB ram
3x 750GB (SATA)


Natuurlijk willen wij, zeker omdat het systeem nu wel eens traag reageert terwijl de server bijna niets aan het doen is, de performance maximaal hebben.
Ik heb het idee dat een SSD toevoegen een flinke boost kan geven (IOPS zijn immers flink hoger bij SSD dan bij HDD). Klopt dit?
Zo ja, Is een SSD voor het OS + SQL database dan voldoende. (2st in mirror)
Of is het beter om 4 SSD's in RAID 5 te zetten en dan ook de Data er op de zetten?
Of zelfs SSD's, maar dan zonder RAID?

Waar moet ik nog meer op letten qua hardware (of software) om het maximale uit de server te halen?

[P_de_B]

Je moet eerst gaan achterhalen waar nu de bottleneck zit. Je kunt wel I/O investeren, maar als memory of CPU de bottleneck is kun je beter daar in investeren. Weet je waar de oorzaak zit van het soms traag reageren?

[HellStorm666]

Eerlijk gezegd geen flauw idee.
Het probleem hebben we al een geruime tijd.
Meestal draait alles prima, maar soms schiet het systeem niet op.
Een folder aanmaken in Productstream duurt dan minimaal 10 minuten.

Ik monitor (nu we weer problemen hebben) al een geruime tijd de sever (Recource Monitor).
Maar het vreemde is.
CPU komt niet boven de 10%
Disk IO staat grotendeels op 0kb/s en piekt dan even als er data opgevraagd moet worden naar 500kb/s ofzo. Active time staat ook meestal op 0%.
Network komt ook niet boven de 40Mbit en beweegt redelijk mee met de Disk IO (alles heeft Gigabit en een eigen switch)
Memory zit op een 70% met 0 Hard Faults.

Databases zelf heb ik niet echt ervaring mee, maar in de Logs van de SQL server staan geen errors.

[P_de_B]

SQL Server kent veel mogelijkheden om performance te monitoren, te loggen en te tunen. Ik kan dat nu niet even 1,2,3 in een post uitleggen, maar als ik jou was zou ik me daar wat in verdiepen. Dat zorgt er voor dat je goed inzicht krijgt in de onderdelen die de performance nu negatief beïnvloeden. Alleen met performance monitor naar de server kijken is niet voldoende.

Kijk in ieder geval eens naar: MSDN: Server Performance and Activity Monitoring en [google="sql server performance management views"]

[HellStorm666]

Ok, thnx.
Zal ik doen.

[Trommelrem]

Let er bij een SSD op dat niet alle RAID controllers goed overweg kunnen met alle SSD's, ook al heb je de nieuwste firmwares.

Je kunt een consumentenversie van de Samsung SSD's aan de controller hangen, maar de performancewinst is dan echt minimaal en je zit met een unsupported configuratie. Je zal bijna verplicht een Dell SSD moeten afnemen. Gelukkig hoeft dat geen SLC te zijn, maar kan een MLC ook voldoende zijn.

[Wim-Bart]

Met een dergelijke database zou je kunnen beginnen met meer memory in je SQL Server. Daarna database. Transactie logs, tempdb tempdb log op aparte storage zetten. Dus gewoon alle 4 splitsen. Database kan gewoon op raid5 transactie logs op snelle storage. Tempdb op normale storage en tempdb log op snelle storage.

[HellStorm666]

Ok thnx.
RAM gaat van 8GB naar 16GB.
Nu nog even uitzoeken wat Transactie Logs, tempdb en tempdb log is
Maar daar moet ik wel uitkomen (op de naam afgaande denk ik al te weten wat het is)

[Arjen42]

SSD is natuurlijk sneller dan dan HDD, maar ook prijziger. Een combinatie van SSD en HDD is dan economischer. Alleen de bedrijven met idioot grote budgetten kunnen complete databases van honderden gigabytes op SSD veroorloven.

Meer geheugen (16 GB is al heel mooi ) zal vooral de leessnelheid verhogen. Zie het als een hele grote cache. Echter wijzigingen in een SQL Server database worden altijd eerst naar de transaction log geschreven voordat ze gecommit worden. Het schrijven naar de transactie log is een veel voorkomende bottleneck.

Het is daarom aan te raden om de transaction log bestanden (*.ldf) van de applicatie databases op de SSD te plaatsen. Mits goed ingesteld vragen deze bestanden niet veel ruimte. Een paar GB bij grote drukke databases.

Transaction log files kunnen op een drukke database na verloop van tijd aardig groeien. Dit komt omdat alle wijzigingen hierin weggeschreven worden. (Zie MSDN: Move User Databases voor informatie hoe je deze bestanden kunt verplaatsen.)

Om er voor te zorgen dat de transaction log files niet al te groot worden. Kun je ervoor zorgen dat oude transacties overschreven worden. Dit kan op twee manieren:

1. Je kan er voor zorgen dat de transaction log regelmatig gebackupt wordt (bijv. 1 keer per uur, of vaker). Hiervoor zal je database op het full recovery model ingesteld moeten zijn. Het gebackupte gedeelte van de transaction log wordt vrijgegeven om opnieuw gebruikt te worden. De transaction log backup kan restored worden na de restore van een full backup om te herstellen tot het punten van de transaction log backup. Transaction log backups kun je zien als incrementele backups.

2. Als alternatief kun je database instellen op het simple recovery model. Dan wordt automatisch de transaction log opnieuw gebruikt en groeit deze dus niet veel. Je kan dan echter geen transaction log backups maken.

Uiteraard is het van belang om regelmatig normale database backups te maken. Gangbaar is dagelijks een full backup of wekelijks een full backup i.c.m. dagelijks een differentiële backup. Al dan niet aangevuld met transaction log backups om het uur of vaker.

Het is tevens van belang voor de tempdb database zowel de data file (tempdb.mdf) als de transaction log file (templog.ldf) op de SSD te zetten. Zie MSDN: Move System Databases voor informatie hoe je de tempdb kunt verplaatsen.) De overige systeem databases hebben geen invloed op de performance dus die laat je gewoon staan.

Als de tempdb intensief gebruikt wordt kan zinvol zijn om voor de tempdb meerdere data files aan te maken. Zie http://www.sqlskills.com/...adding-data-files-tempdb/ voor meer informatie.

RAID5 is voor databases niet aan te raden. Zeker niet voor de transaction log en tempdb. Bij RAID5 moet namelijk voor elk block wat geschreven worden alle overeenkomstige blocks op de andere schijven opnieuw gelezen worden om de parity opnieuw te berekenen. Voor veel aparte kleine schrijfacties vlak achter elkaar zorgt dit voor enorme opstopping. Het is veel beter is het om i.p.v. RAID5 RAID10 te gebruiken. RAID5 gebruik alleen voor database files als je budget erg krap is en er geen grote database belasting is (e.g. archief database). Voor data bestanden (e.g. attachments) die buiten de database worden opgeslagen zou RAID5 wel geschikt kunnen zijn.

Als je meer zou willen leren. Zou ik je willen aanraden om de volgende video serie te volgen: http://www.microsoftvirtu...ql-server-2012-jump-start

[ Voor 2% gewijzigd door Arjen42 op 22-12-2014 11:18 . Reden: Link naar video toegevoegd ]

[demokert]

Hoi HellStorm666,


In de Transactionlog worden de transacties bijgehouden die in de database gedaan worden.
Daarop volgend neemt men altijd een transactionlog backup hiervan zodat de file zelf weer leeg gemaakt wordt. Dit heeft als gevolg dat je gecontrolleerde checkpoints op je database krijgt en gemakkelijk een point in time restore kunt uitvoeren. (FULL RECOVERY MODE)

In de SIMPLE RECOVERY MODE wordt er niet veel gelogged naar je Transactionlog, en worden er willekeurige checkpoints gezet.


Dit specifieke geval kun je vanuit meerdere invalshoeken benaderen. Maar je zal eerst moeten meten hoe en wat er precies gebruikt wordt. Natuurlijk ga je iets merken als je je databases op SSD gaat zetten, de vraag is echter hoeveel...

De Activity monitor van de studio geeft een indicatie maar is eigenlijk niet heel betrouwbaar.Hiervoor zijn veel betere tools of zelfs gratis scripts te vinden!

Verder zou ik de volgende dingen als eerst nagaan;
- klopt je (SQL Instance) configuratie (geheugen/maxdop bijv)
- Indexen / statistics op orde?
- TempDB bestanden verdeeld over meerdere disks?
- Database bestanden verdeeld over meerdere disks (intensief schrijven + lezen kan killing zijn)
- whitepaper van de leverancier (Vault, Inventor Pro? ) Helaas hebben wij dit product zelf niet in huis anders kon ik even voor je kijken.
- Exclusion van bijvoorbeeld je MDF/LDF/NDF bestanden in de AV software

Wat betreft RAID configuratie;

• RAID 0 (sometimes called disk striping). This RAID level spreads all the data across all the available disks. You often see this RAID level used in different database benchmarks. RAID 0 provides good performance, but you should never use it on a production server because one disk failure will result in data loss.

• RAID 1 (sometimes called disk mirroring). With RAID 1, data is mirrored on the disks. Read and write performance is good, but the overall disk capacity is cut in half. RAID 1 is often used for SQL Server log files. It can sustain one disk failure.

• RAID 5 (sometimes called disk striping with parity). RAID 5 stripes data across multiple disks and uses a disk for data redundancy. It's often used for data files. This RAID level provides good read performance and can sustain the failure of one disk. However, it's known for slower write performance.

• RAID 10 (sometimes called disk mirroring with striping). RAID 10 combines the performance of striping with the protection of mirroring. RAID 10 provides the highest levels of performance and availability out of the different RAID levels. RAID 10 uses twice as many disks as RAID 5, but it can sustain multiple disk failures. A RAID 10 array can sustain failures for as many as half of the disks in the set. RAID 10 is good for both data and log files.

Bron; http://sqlmag.com/storage/sql-server-storage-best-practices


Kortom;
Ik denk dat je eerst de voor de hand liggende best-practise zaken zou moeten toepassen voor je verder gaat uitbouwen.
Mocht je nog hulp nodig hebben stuur maar een PM .

[HellStorm666]

@demokert,
Super bedankt!!
Ik zal die best-practice even goed doornemen.
En mocht ik nog vragen hebben, dan zal ik je zeker een PM sturen.

[CMD-Snake]

HellStorm666 schreef op maandag 22 december 2014 @ 10:03:
Momenteel is er een 250GB HDD (SATA) voor het OS.
2x een 2TB HDD (SATA) in mirror voor de Database en data.

Alles op een disk is redelijk de doodsteek voor performance. Uitsplitsen in de nieuwe situatie is lijkt me sowieso handiger. Een disk voor je databases, een disk voor je logfiles en een disk waar je data komt te staan.

Hoe is de relatie eigenlijk tussen die database en de data? Ik ken de genoemde pakketten niet, maar staan er in de database verwijzingen waar de data te vinden is?

Ik heb namelijk een keer een pakket meegemaakt dat op bovenstaande manier werkte. Helaas bestond de database uit een grote tabel waarin alle locaties stonden van bestanden. Je kreeg dus een waanzinnig grote tabel na een tijdje en het duurde dan wel even voordat SQL Server die doorzocht had als iemand een bestand opvroeg. En doe dat dan nogmaals tig tallen gebruikers. Het bleek bij navraag dat het pakket niet zo lekker kon schalen, althans, boven een bepaald aantal bestanden erin ging de performance wel omlaag.

Welke versie van SQL Server hebben we het eigenlijk over? Let wel dat sommige nieuwe SQL Server versies nog wat opties introduceren om beter te schalen. (Alleen handig als je pakket dat niet kan.)

De nieuwe server (ex-ESXi server) is een Dell T310.
Hierop komt Windows Server 2012.
x3430 @2,4Ghz (De CPU gaan we waarschijnlijk nog wisselen, zodat de X3450 hier in komt)
16GB ram
3x 750GB (SATA)


Natuurlijk willen wij, zeker omdat het systeem nu wel eens traag reageert terwijl de server bijna niets aan het doen is, de performance maximaal hebben.
Ik heb het idee dat een SSD toevoegen een flinke boost kan geven (IOPS zijn immers flink hoger bij SSD dan bij HDD). Klopt dit?
Zo ja, Is een SSD voor het OS + SQL database dan voldoende. (2st in mirror)
Of is het beter om 4 SSD's in RAID 5 te zetten en dan ook de Data er op de zetten?
Of zelfs SSD's, maar dan zonder RAID?

SSD's zou ik niet doen. Om eerder genoemde redenen van ondersteuning door de controller en dat de kosten per Gb nogal hoog liggen. Je zou dan eerder SAS disks moeten overwegen. Die hebben een hogere I/O dan reguliere SATA schijfjes. Als je met RAID gaat werken is een goede RAID controller essentieel. Een slechte RAID controller trekt ook je I/O lelijk naar beneden.

Ik zou in die nieuwe server toch minstens het volgende doen:

Disk 1: OS + SQL Server (alleen de SQL Server installatie)
Disk 2: SQL Server databases (.mdf en .ndf files)
Disk 3: SQL Server logfiles (.ldf files)
Disk 4: Overige data bestanden

Disks 2, 3 en 4 in mijn voorbeeldje kan je ook RAID configs van maken indien nodig, maar houdt die dingen gescheiden.

Zorg er ook voor dat je van het totale systeemgeheugen 2Gb reserveert voor Windows Server zelf. De rest kan je aan SQL geven.

Overleg ook met de leverancier van je pakket. Als het goed is kunnen zij ook configuratie advies geven. Zij weten als geen ander hoe hun pakket zich gedraagt en waar eventuele knelpunten zijn.

[HellStorm666]

CMD-Snake schreef op maandag 22 december 2014 @ 14:18:
[...]

.....

Hoe is de relatie eigenlijk tussen die database en de data? Ik ken de genoemde pakketten niet, maar staan er in de database verwijzingen waar de data te vinden is?
......

Welke versie van SQL Server hebben we het eigenlijk over? Let wel dat sommige nieuwe SQL Server versies nog wat opties introduceren om beter te schalen. (Alleen handig als je pakket dat niet kan.)

......

Volgens mij staat alle data (tekeningen, samenstellingen ed) in de data.
Vervolgens staat er in de database welk project welke tekeningen en bestanden gebruikt.
Dit zorgt er voor dat elk bestand maar 1x hoeft te bestaan, omdat de database vermeld welke bestanden er gebruikt worden binnen het project.

Microsoft SQL Server Management Studio 9.00.5000.00
Microsoft Analysis Services Client Tools 2005.090.5000.00
Microsoft Data Access Components (MDAC) 6.1.7601.17514 (win7sp1_rtm.101119-1850)
Microsoft MSXML 3.0 4.0 5.0 6.0
Microsoft Internet Explorer 9.11.9600.17501
Microsoft .NET Framework 2.0.50727.5485
Operating System 6.1.7601

[CMD-Snake]

HellStorm666 schreef op maandag 22 december 2014 @ 14:29:

Microsoft SQL Server Management Studio 9.00.5000.00
Microsoft Analysis Services Client Tools 2005.090.5000.00
Microsoft Data Access Components (MDAC) 6.1.7601.17514 (win7sp1_rtm.101119-1850)

SQL Server 2005 dus? Je data engine staat er niet bij het overzicht, maar van de andere componenten gok ik dat we het over 2005 hebben. Nog enige service packs geïnstalleerd? Je moet minimaal SP4 draaien tegenwoordig.

Let wel dat SQL Server 2005 binnenkort uit de support cyclus gaat van Microsoft. Ik denk dat het pakket ook niet zal werken op Windows Server 2012(R2). Je moet sowieso al moeite doen om het werkend te krijgen op Windows Server 2008 of hoger. Je moet een minimaal Service Pack niveau dan al hebben.

Mijn advies is dan om ook te kijken naar een nieuwe SQL Server versie als mijn idee klopt, niet zozeer nog voor je tuning mogelijkheden maar ook om het in de toekomst binnen de Microsoft support te houden. Overleg met de leverancier van je pakket welke versies van SQL Server zij ondersteunen. Bij voorkeur zou ik zeggen SQL Server 2012 met SP1 of SP2. Eventueel SQL Server 2008R2 met SP2 of SP3. Of natuurlijk SQL Server 2014 RTM, maar niet veel leveranciers zijn zo ver nog.

[HellStorm666]

O, sorry,
Bij de eigenschappen van de totale server staat:
Microsoft SQL Server standard edition 64bit
Version 9.00.5057.00

Nog wat verder gekeken.
SQL Server 2005 is dat.
SP4 is geinstalleerd.
Net als GDR 5057 for Server Tools. en voor Database Services

[ Voor 35% gewijzigd door HellStorm666 op 22-12-2014 14:52 ]

[CMD-Snake]

HellStorm666 schreef op maandag 22 december 2014 @ 14:48:
Bij de eigenschappen van de totale server staat:
Microsoft SQL Server standard edition 64bit
Version 9.00.5057.00

SQL Server 2005 Standard Edition met Service Pack 4 dus.

Tijd om te upgraden. Zie mijn vorige post, maar je moet eigenlijk minimaal SQL Server 2008R2 SP2 of SP3 draaien.

[HellStorm666]

Die upgrade gaan we dan direct uitvoeren samen met de update naar Server 2012.