Hallo

Welkom, Gast. Alsjeblieft inloggen of registreren.

Recent

208 gasten, 0 leden

Welkom, Gast. Alsjeblieft inloggen of registreren.

28 maart 2024, 18:07:44

Login met gebruikersnaam, wachtwoord en sessielengte

Nieuws

Welkom op het vernieuwde NL Computer Forum!

Auteur Topic: Versnellen SQL query mogelijk?  (gelezen 30874 keer)

0 leden en 1 gast bekijken dit topic.

Offline NLCOMP

  • Forumheld
  • *****
  • Berichten: 14.666
    • NL Computer Forum
Versnellen SQL query mogelijk?
« Gepost op: 9 november 2009, 20:32:36 »
Bericht 1 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:28-03-2008
Aan:Hugo KornelisMsgID:3801.1
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Hugo,

Dank je weer voor je vorige antwoord! Daar kom ik dit weekend nog op terug. Ondertussen heb ik nog iets anders... ;-)

Het gaat om deze query:

INSERT INTO statushistory
SELECT ID, orderID, status, 1+ID - (select MIN(ID) FROM statushistory_tmp A
                                                    where a.orderID = B.orderID
                                                    group by orderID)
FROM statushistory_tmp B


statushistory_tmp ziet er zo uit:

ID    orderID   status
1     123456    2008-03-27 12:13 A1
2     
123456    2008-03-27 15:42 A2
3     
123456    2008-03-28 09:12 A3
4     987654    2008-03-27 15:53 A1
5     
987654    2008-03-27 10:15 A2

Hierbij is ID de sleutel (primary key), type bigint en is in de voorgaande stap al automatisch opgenummerd. orderID en status zijn beide nvarchar(255).

Het doel van deze query om volgnummers toe te kennen. Dus binnen een orderID een volgnummer. Dit heb ik nodig, omdat het soms voorkomt dat binnen 1 minuut 2 keer een statuswijziging plaatsvindt. De seconden toevoegen is helaas niet mogelijk, dus heb ik het opgelost met een volgnummer.

statushistory ziet er na het uitvoeren van de query dus zo uit:

ID    orderID   status                volgnummer
1     123456    2008-03-27 12:13 A1   1
2     
123456    2008-03-27 15:42 A2   2
3     
123456    2008-03-28 09:12 A3   3
4     987654    2008-03-27 15:53 A1   1
5     
987654    2008-03-27 10:15 A2   2

Ook in deze tabel is ID de sleutel (primary key), type bigint en orderID en status zijn opnieuw nvarchar(255). De volgnummer kolom is van type int.

En... het werkt! Maar de machine waarop dit draait heeft er toch héél wat meer moeite mee dan mijn eigen computer. Bij 10.000 rijen ben ik op mijn pc nog binnen 1 seconde klaar, maar op de server waar het op moet draaien duurt het dan al 11 seconden. Vandaag heb ik een test gedaan met 58.000 rijen. Dat duurde ruim 6 minuten! Nog even op mijn computer geprobeerd: 2 seconden.

Heb jij enig idee waarom die andere machine zo ongeloofelijk veel moeite heeft met deze query? En is er wellicht een manier om dit te versnellen (met een slimmere query?)

De machine waarop dit draait, is trouwens een Dual-Core AMD Opteron 2210 1.8 Ghz met 4 GB intern geheugen (draaiend op Windows Server 2003 R2 SP2). De /3GB switch is geactiveerd in boot.ini om SQL Server voldoende intern geheugen toe te kennen. Mijn eigen computer is een Intel Core2 6300 1.87Ghz met 2 GB intern geheugen (draaiend op Windows Vista SP1).

De versie van SQL Server 2005 is dezelfde (9.0.3054).

Groeten,

Ronald



Bericht 2 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:31-03-2008
Aan:AllenMsgID:3801.2
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Inmiddels kwam ik het volgende tegen:
FIX: A query performance issue occurs when you run a query against a column of the bigint data type in SQL Server 2005http://support.microsoft.com/kb/948248

Ik weet niet 100% zeker of dit van toepassing is, maar voor alle zekerheid heb ik het datatype veranderd in 'int'. Aan maximaal 2 miljard nummers heb ik per dag toch wel genoeg. <g>

Of het probleem hiermee is opgelost, weet ik later vandaag (als het aantal rijen weer groot is geworden).



Bericht 3 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:01-04-2008
Aan:Ronald BeukerMsgID:3801.3
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Helaas.... de query met op dit moment 74,000 rijen in de brontabel loopt bij mij nu in 3 seconden. Op dat andere systeem duurt het 55 minuten!! :-/



Bericht 4 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Michel Uphoff (Sysop)Datum:01-04-2008
Aan:Ronald BeukerMsgID:3801.4
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Ik neem aan dat je niet alleen maar wat tegen jezelf aan het neuzelen was, en dat je hier wat mee wilt.
>> Op dat andere systeem duurt het 55 minuten <<
T.o.v. 3 seconden... dat is een bijkans onmogelijk verschil. Wat zijn de hoofdspecs van het snelle en van het trage systeem? OS verschil? Werkstations of servers?
Hoe staat het met evt. virusscanners? Ik weet dat er scanners zijn die met name queries piepend en knarsend tot stilstand kunnen brengen.
Doe even het volgende (naast die hoofdspec's) start op beide machines taakbeheer (Ctrl-Shift-Esc), tabblad processen, en kijk naar abnormale cpu load door processen, kijk ook naar (vrij) geheugen. Kijk ook naar de netwerkgrafiek; er wordt toch niets iets heel diks telkens over een touwtje gesleept?
Schijfruimte voldoende, defragmentatie misschien een echt probleem (kan vooral op database servers wel eens echt heel ernstig worden).

Michel Uphoff (NLcomputer)
Homepage



Bericht 5 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:02-04-2008
Aan:Ronald BeukerMsgID:3801.5
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Sorry voor het vertraagde antwoord - ik had het even druk met andere zaken.
Heb jij enig idee waarom die andere machine zo ongeloofelijk veel moeite heeft met deze query?
In feite vraag je om voor elke rij in "StatusHistory_tmp" een subquery uit te voeren waarin de laagste ID van een overeenkomende OrderID in diezelfde "StatusHistory_tmp" wordt gezocht. Bij 100 rijen moet dus 100 keer in die 100 rijen gezocht worden, bij 1000 rijen 1000 keer in die 1000 rijen, enzovoort. De benodigde verwerkingstijd zal exponentieel stijgen met de hoeveelheid rijen.
Maar je eigenlijke vraag is vermoedelijk waarom er zo'n groot verschil tussen de twee machines is. Ik denk dat dit te maken heeft met een verschil in de aanwezige indexen. Ik denk dat je op je eigen computer een index hebt gedefinieerd op de OrderID kolom in StatusHistory_tmp, en dat een dergelijke index op de server ontbreekt. Door deze index kan SQL Server voor elke rij (via die index) direct de laagste ID waarde bij een orderID vinden, zodat de performance nu lineair stijgt met het aantal rijen in plaats van exponentieel.
Een andere mogelijke verklaring, als de indexen op beide machines wel gelijk zijn, kan de data distributie zijn. Met een index op alleen OrderID moet SQL Ser ver nog wel alle rijen van een order lezen om de laagste ID te zoeken. Als jouw machine 6000 orders met gemiddeld 10 rijen heeft, en de echte server 60 orders met gemiddeld 1000 rijen, dan moet de echte server veel meer werk doen.
En is er wellicht een manier om dit te versnellen (met een slimmere query?)
Jazeker. Dan grijp ik opnieuw naar de nieuwe ROW_NUMBER() functie, dit keer met behalve een ORDER BY ook een PARTITION BY clause om de nummers per waarde van OrderID opnieuw te laten beginnen:
INSERT INTO statushistory   -- Altijd een kolomlijst opgeven !!!!!
SELECT ID, orderID, status,
       ROW_NUMBER() OVER (PARTITION BY OrderID ORDER BY ID)
FROM statushistory_tmp;
En aangezien dit er wel erg uitziet als het vervolg op een andere discussie is mijn volgende suggestie om de hele tijdelijke tabel er tussenuit te knippen en direct de nummering per order toe te kennen:
INSERT INTO statushistory(ID, OrderID, Status, Volgnummer)
SELECT ROW_NUMBER() OVER (ORDER BY WeetIkNietMeer),
       OrderID, Status,
       ROW_NUMBER() OVER (PARTITION BY OrderID ORDER BY ID)
FROM   WeetIkOokNietMeer;
Als je de ID kolom alleen nodig had om het volgnummer te kunnen bepalen, dan kan je die uiteraard ook meteen laten vervallen.
Het voordeel van het overslaan van tussenstappen is dat er veel minder naar schijf geschreven en weer van schijf gelezen hoeft te worden. Bovendien geef je de query optimizer veel meer kans om "shortcuts" te vinden. Dit is vaak een van de moeilijkste dingen voor een "3GL" ontwikkelaar die overstapt naar SQL schrijven: leren om (in één enkele query) het resultaat te beschrijven in plaats van in een serie kleine stapjes een manier om tot het resultaat te komen.
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis


Bericht 6 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:02-04-2008
Aan:Michel Uphoff (Sysop)MsgID:3801.6
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Michel,

Ik babbel altijd zo gezellig tegen mezelf. <g> Doet me denken aan een sketch van Herman van Veen:

Komt een man bij de dokter. Man geeft aan niet zo lekker in z'n vel te zitten.
Dokter: 'Houdt u wel van u zelf?'
Man: 'Ja...
....maar het is niet wederzijds'


Dit slaat niet op mij trouwens. <g> Maar terug naar deze server. Een virusscanner draait er niet op. Of dat (on)verstandig is, laat ik maar in het midden (niet mijn probleem, en sowieso lijkt het mij qua performance alleen maar gunstig <g>).

Ik ben nu de C-schijf aan het defragmenteren. Die is 12 GB groot, 4 GB vrij, 30% fragmentatie. De data staan hier trouwens niet op.
De D-schijf (met de SQL Server databestanden) is 220 GB groot, met 210 GB vrij. Fragmentatie kan ik zien als de C-schijf zometeen klaar is met defragmenteren. ;-)

Netwerkverkeer is er nauwelijks. Deze server is zelfs buiten het domein gehouden.

Het performance probleem op de SQL Server heb ik kunnen oplossen (dat zal ik zo in een bericht aan Hugo uiteenzetten). Maar met die server ben ik nog niet klaar. Het ding moet razendsnel zijn, maar je zit regelmatig te wachten. CPU-gebruik is  dan bijna niets, vrije geheugenruimte is er nog zát, maar toch gebeurt er regelmatig even niets. Dus 'iets' blokkeert die server, heb jij nog ideeën wat zoiets kan veroorzaken? Ik denk inmiddels aan iets met de hardware, of een iets teveel getweakte BIOS-setting. Morgen ga ik zeker in het BIOS kijken; misschien de 'zet alles terug naar standaard' optie maar gebruiken?

Groeten,

Ronald





Bericht 7 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:02-04-2008
Aan:Hugo KornelisMsgID:3801.7
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Hugo,

>>De benodigde verwerkingstijd zal exponentieel stijgen met de hoeveelheid rijen.<<

Ok! Nou ja, niet ok dus, maar zo'n gevoel had ik er zelf ook al bij (dat het exponentieel toeneemt).

>>Ik denk dat dit te maken heeft met een verschil in de aanwezige indexen. (...) Een andere mogelijke verklaring, als de indexen op beide machines wel gelijk zijn, kan de data distributie zijn.<<

De brondata waren exact dezelfde (op beide machines is de 1e stap van het DTS-package is het downloaden van hetzelfde XML-bestand). Qua indexen was er geen verschil. Sterker nog: die waren er niet eens. <g> De tabellen op mijn systeem had ik met rechtermuisknop --> Script table --> CREATE to omgezet in een query, en die op de andere machine uit laten voeren). Ik heb nog even bij de 'Indexes and keys' gekeken, maar daar stond op beide systemen alleen de primary key (op het 'ID' veld).

Door de subquery om te zetten naar een aantal tussenstappen, waardoor ik met een LEFT JOIN per orderID het 'startID' nummer erbij kon zetten, had ik gistermiddag zelf al een enorme snelheidsvergroting bereikt. Echter, jouw methode werkt nog véle male sneller! Die 50 minuten werden opeens... 1 seconde. Zelfs snéller op de server dan op mijn computer. <g>

Toen liep ik wel vast bij een andere query die een driedubbelgeneste SELECT CASE bevat. Drie draaide op mijn systeem in 3 seconden, en op de andere machine 13 minuten. Toen vond ik de Database Engine Tuning Advisor en die adviseerde om indexen te gaan gebruiken. En weg was het probleem!

Hieronder trouwens die prachtige query (althans, ik vond 'm prachtig toen ik eindelijk alle haakjes goed had staan <g>):

INSERT INTO STATUSHIST_TMP2
select ID, A.orderID AS orderID, volgnummer,
(SELECT CASE status
WHEN 'A1' THEN (SELECT CASE (SELECT COUNT(*) FROM STATUSHISTORY C WHERE C.orderID = A.orderID)
WHEN 0 THEN (SELECT CASE(SELECT MAX(volgnummer) FROM STATUSHIST_TMP1 D WHERE D.orderID = A.orderID)
WHEN 1 THEN LEFT(UpdTime,10) + 'T' + SUBSTRING(UpdTime,12,6) + '00'
ELSE '20' + RIGHT(orderDate,2) + '-' + SUBSTRING(orderDate,4,2) + '-' + LEFT(orderDate,2) + 'T00:00:00'
END)
END)
ELSE
LEFT(status,10) + 'T' + SUBSTRING(status,12,5) + ':00'
END) AS StatusDateTime,
(SELECT CASE status
WHEN 'A1' THEN 'A1'
ELSE
STUFF(status,1,17,'')
END) AS Status
FROM STATUSHIST_TMP1 A,XML B
WHERE A.orderID = B.orderID
ORDER BY ID


Ik heb al bedacht dat die ORDER BY eruit kan, en dat achter de INSERT INTO de kolomlijst moet komen. ;-) 

Achtergrond van wat hier gebeurt: soms bevat de status-kolom (door een invoerfout) alleen de code 'A1', en géén datum/tijd ervoor. Als dat zo is, dan kijk ik of die order al in de totale historietabel voorkomt. Zo nee, dan kijk ik of ik precies 1 nieuwe regel informatie heb over die nieuwe order (in theorie zou het kunnen dat die order nieuw is binnengekomen, maar ook al een statuswijziging heeft gehad). Op basis daarvan bepaal ik welke kolom ik gebruik om e.e.a. recht te trekken.

Dit had ik nodig omdat anders de hele procedure staakte: als er geen geldige datum/tijd was in 'nvarchar-formaat', dan ging de conversie naar datetime-formaat fout.

Wat wel vreemd blijft, is dat ik op mijn systeem zónder deze indexen al een goede performance haal, terwijl het op die andere machine dan dramatisch traag is. Sowieso heb ik nog steeds het gevoel dat er 'iets' niet lekker op die server zit (zie mijn bericht aan Michel).

>>INSERT INTO statushistory   -- Altijd een kolomlijst opgeven !!!!! <<

Is dat vanwege performance redenen, of is er (ook) een andere reden? Ik dacht dat het voldoende was om ervoor te zorgen dat in de SELECT-list de correcte namen stonden (voor zover nodig gebruik makend van 'AS').

>>Dit is vaak een van de moeilijkste dingen voor een "3GL" ontwikkelaar die overstapt naar SQL schrijven: leren om (in één enkele query) het resultaat te beschrijven in plaats van in een serie kleine stapjes een manier om tot het resultaat te komen.<<Point taken. <g>  Wat ik mij nog zat af te vragen: als ik nu ipv al die tussenstappen en tabellen alles eens in 1 lange transactie zet, gebruik makend van tijdelijke tabellen? Want tijdelijke tabellen worden toch alleen in het geheugen bewaard? (Met als gevolg: minder schijf I/O?) Het voordeel van die tussenstappen vind ik wel dat het veel makkelijker is om terug te herleiden wat er nu precies gebeurt. Maar het kan een kwestie zijn van anders gaan denken zijn. <g>

Groeten,

Ronald
« Laatst bewerkt op: 1 januari 2010, 17:45:34 door Ronald »

Offline Ronald

  • Forum Manager
  • *****
  • Berichten: 1.856
  • Geslacht: Man
    • NL Computer Forum
Re: Versnellen SQL query mogelijk?
« Reactie #1 Gepost op: 1 januari 2010, 17:47:15 »
Bericht 8 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:02-04-2008
Aan:Ronald BeukerMsgID:3801.8
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Qua indexen was er geen verschil. Sterker nog: die waren er niet eens. <g>
Dat dacht je maar :P  Du moment dat jij een primaire sleutel instelt wordt er in elk geval één index gemaakt.
De tabellen op mijn systeem had ik met rechtermuisknop --> Script table --> CREATE to omgezet in een query, en die op de andere machine uit laten voeren).
Met de default opties van SQL Server Management Studio worden indexen (behalve dus de index die je "kado" krijgt bij een primaire sleutel) niet mee gegenereerd, dus dit is geen heel overtuigend argument. Het zou juist mijn theorie kunnen bevestigen dat er een index op jouw machine is die op de server ontbreekt.
Ik heb nog even bij de 'Indexes and keys' gekeken, maar daar stond op beide systemen alleen de primary key (op het 'ID' veld).
Wat gebruik jij eingelijk als front end? In SQL Server Management Studio staan "Indexes" en "Keys" als aparte "mappen" in het object explorer venster, en bestaat (voor zover ik weet) geen "Indexes and keys" optie.
driedubbelgeneste SELECT CASE
Brrr. Wil je dat soort dingen niet voor etenstijd schrijven? :D
Je kunt overigens gewoon CASE gebruiken, je hoeft er geen SELECT voor en haakjes omheen te doen. Dat scheelt al weer iets in de leesbaarheid van je query. Voor de rest heb ik het idee dat de query nog wel verder vereenvoudigd (en hopelijk ook versneld) moet kunnen worden, maar daar moet ik even wat dieper over nadenken.
>>INSERT INTO statushistory   -- Altijd een kolomlijst opgeven !!!!! <<

Is dat vanwege performance redenen, of is er (ook) een andere reden? Ik dacht dat het voldoende was om ervoor te zorgen dat in de SELECT-list de correcte namen stonden (voor zover nodig gebruik makend van 'AS').
Niet vanwege de performance, wel vanwege onderhoudbaarheid en betrouwbaarheid van je code.
De namen in de SELECT lijst doen niet ter zake en AS heeft daar al helemaal geen zin. Bij een INSERT heb je aan de ene kant de opgegeven lijst met kolommen in de INSERT clause, en aan de andere kant de lijst met waarden in de VALUES of SELECT. Die worden gewoon van links naar rechts met elkaar gematched - dus de eerste waarde in de SELECT komt in de kolom die als eerst genoemd wordt, de tweede waarde in de tweede kolom, etc.
Laat je de kolomlijst weg, dan zal SQL Server zelf de lijst invullen door alle kolommen uit de tabel achter elkaar te plakken. De volgorde is de volgorde waarin de tabellen genoemd stonden tijdens het maken van de tabel, gevolgd door de kolommen die later met ALTER TABLE zijn toegevoegd (op volgorde van toevoegen). De nadelen die je hierbij krijgt zijn:
1. Als iemand een kolom verwijdert, of de tabel opnieuw aanmaakt met de kolommen in een andere volgorde, dan krijg je in het beste geval een fout, in het ergste geval gegevens in de verkeerde kolom;
2. Als je voor een geplande wijziging een impact analyse moet doen en je scant je hele code op het vóórkomen van een kolomnaam, dan zal een procedure waar INSERT zonder kolomlijst gebruikt wordt niet gevonden worden.
3. Iemand die de code niet eerder gezien heeft zal meer moeite moeten doen om de code te kunnen lezen, omdat niet duidelijk te zien is welke waarde in welke kolom van de tabel zal worden opgeslagen.
Wat ik mij nog zat af te vragen: als ik nu ipv al die tussenstappen en tabellen alles eens in 1 lange transactie zet, gebruik makend van tijdelijke tabellen? Want tijdelijke tabellen worden toch alleen in het geheugen bewaard? (Met als gevolg: minder schijf I/O?)
Helaas moet ik je teleurstellen. Dit is slechts gedeeltelijk waar. SQL Server bewaart alle gewijzigde gegevens in het geheugen (de data cache) en schrijft de wijzigingen periodiek en asynchroon naar schijf (het "checkpoint" proces). Gelukkig maar, want het zou knap beroerd zijn als de omvang van een tijdelijke tabel door het fysieke geheugen beperkt werd! Als een tijdelijke tabel relatief weinig geheugen gebruikt en slechts kort bestaat, dan is de kans statistisch gezien groot dat de betreffende pages nooit naar disk geschreven worden omdat ze al opgeruimd zijn voordat er weer een checkpoint volgt. Dit heeft echter relatief weinig performance impact. Bovendien worden tijdelijke tabellen wél gelogd en worden log records synchroon naar schijf geschreven; dat heeft een veel grotere invloed op de performance.
Het voordeel van die tussenstappen vind ik wel dat het veel makkelijker is om terug te herleiden wat er nu precies gebeurt. Maar het kan een kwestie zijn van anders gaan denken zijn. <g>
Dat is het inderdaad.
Eventueel kan het ook helpen om voor de tussenstappen views te gebruiken. Een view is te vergelijken met een macro - op het moment dat een query wordt uitgevoerd die een view gebruikt, dan wordt de naam van die view vervangen door diens definitie en het resultaat daarvan is dan de uit te voeren query. Een andere oplossing om het jezelf makkelijk te maken (in SQL Server 2005) is het gebruik van Common Table Exprerssions (CTEs) - als het ware tijdelijke views die alleen tijdens één query gebruikt kunnen worden:WITH Stap1 AS
 
  (SELECT bla bla bla
     FROM   Tabelletje
     WHERE  whatever),
     Stap2 AS
    (SELECT bla bla bla
     FROM   Stap1
     WHERE  nogwat)
SELECT bla bla bla
FROM   Stap2
WHERE  wat je maar wilt;
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis


Bericht 9 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:02-04-2008
Aan:Ronald BeukerMsgID:3801.9
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Een virusscanner draait er niet op. Of dat (on)verstandig is, laat ik maar in het midden
Zie je vaker op een pure database server. Als de firewall in orde is komt er niets anders binnen dan queries voor de database en daar kan geen virus in zitten. (Wel ander onheil, maar de virus scanner die dat tegenhoudt moet nog uitgevonden worden).
Fragmentatie kan ik zien als de C-schijf zometeen klaar is met defragmenteren. ;-)
Controleren kan geen kwaad, maar ik verwacht hier weinig van. Tenzij de database veel te klein gealloceerd is geweest en in kleine stapjes gegroeid is. En zelfs dan weet ik nog niet of je dit als fragmentatie van het file systeem zal zien.
Fragmentatie van de indexen en tabellen (logische fragmentatie binnen de database bestanden) is veel vaker een probleem bij SQL Server. Zou je in de betreffende database eens de onderstaande query kunnen draaien en het resultaat hier neerzetten?SELECTOBJECT_NAME(object_id)AS objectname,
       
index_id, partition_number, avg_fragmentation_in_percent
FROM   sys.dm_db_index_physical_stats (DB_ID(),NULL,NULL,NULL,'LIMITED'); je zit regelmatig te wachten. CPU-gebruik is  dan bijna niets, vrije geheugenruimte is er nog zát, maar toch gebeurt er regelmatig even niets
Voer de volgende keer dat dit gebeurt even onderstaande query uit en kijk of er een locking probleem is:EXECsp_who2; Er zijn nog meer zaken waar dit door kan komen, maar dit is niet het gebied waar ik dagelijks mee bezig ben dus ik moet me er weer even in verdiepen. Misschien moeten we eerst eens kijken of dit iets oplevert. Helpt dit niet, en kom je er ook met Michel's meer OS-gerelateerde suggesties niet uit, dan ga ik dieper graven en verder zoeken.
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis


Bericht 10 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:02-04-2008
Aan:Hugo KornelisMsgID:3801.10
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Hugo,
Dank je weer je uitgebreide reacties! Echt super.
Ik ga toevallig morgen naar die klant en neem die query mee. Morgenmiddag meld ik dan het resultaat en reageer ik 'echt' op al je berichten van vandaag.
Trouwens wel erg grappig dat we nu dus nog steeds niet weten hoe je COALS--nog wat uitspreken. Kijk, zo onthoud ik het dus echt niet hè! Had Microsoft er niet ISNULL2 ofzo van kunnen maken. Veel minder fraai, maar wel duidelijk. <g>
Groeten,
Ronald


Bericht 11 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:03-04-2008
Aan:Hugo KornelisMsgID:3801.11
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Hugo,

De D-schijf (met de SQL Server data-bestanden erop) was nauwelijks gefragmenteerd. De C-schijf zag daarentegen 'knalrood' van de fragmentatie (in het Windows plaatje zag het érg rood <g>). De machine loopt nu veel vlotter. ;-)

De sp_who2 kende ik al, maar ik moet bekennen dat ik niet zou weten hoe ik daarmee een locking probleem zou kunnen herkennen. In welke kolom(men) moet ik dan precies kijken?

Hieronder de output van de query. Ik heb zo'n donkerbruin vermoeden dat dit niet heel best is. <g>

objectname                 index_id    partition_number     avg_fragmentation_in_percent
----------                 --------    ----------------     ----------------------------
STATUSHIST_TMP_STARTIDS2   1           1                    0,370713624
STATUSHIST_TMP_STARTIDS    1           1                    8
CALLAGENT_LAST             0           1                    72,72727273
ORDERHISTORY_TMP           0           1                    66,66666667
CALLAGENT_TMP1             1           1                    80
CALLAGENT_TMP              1           1                    77,77777778
CALLAGENTHISTORY           1           1                    98,87640449
ORDERHISTORY               1           1                    92,88864388
STATUSHIST_TMP3            1           1                    46,66666667
STATUSHISTORY              1           1                    84,73400154
STATUSHISTORY              2           1                    64,01028278
XML                        0           1                    16,66666667
XML                        2           1                    0
STATUSHIST_TMP             1           1                    27,27272727
STATUSHIST_TMP1            1           1                    30,43478261
STATUSHIST_TMP1            2           1                    30,43478261
STATUSHIST_TMP1            3           1                    70
STATUSHIST_TMP2            1           1                    28



C'est grâve, docteur? ;-)  Ou ce trouve le button pour défragmenter toutes ça? (Waar zit de knop om dit te defragmenteren? <g>)

Groeten,

Ronald



Bericht 12 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:03-04-2008
Aan:Michel Uphoff (Sysop)MsgID:3801.12
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Michel,

Na het defragmenten van de C-schijf loopt de Windows 2003 R2 server een héél stuk beter! Voor de zekerheid hebben we ook nog in het BIOS gekeken, daar zag ik niets vreemds (er viel ook eigenlijk weinig in te stellen; het is een DELL server). De paar vragen die ik nog heb, zijn deze:

- In het BIOS zag ik staan dat de Bus speed 1000 Mhz is. Het geheugen is 4.0 GB ECC DDR2 667 MHz. De processor is een 64-bits Dual Core AMD Opteron 2210 met Core Speed 1.8 Ghz. Is het geheugen nu een bottleneck?

- Op de C-schijf staat geen wisselbestand, op de D-schijf wel. Fysiek is het 1 schijf. Is dit de beste instelling? Ik ben even kwijt of je het wisselbestand nu juist wél, of juist niet op dezelfde schijf moet zetten als waar Windows op draait (op C dus).

- Bij de instelling van de netwerkaansluiting kwam ik tegen: Embedded Gb NIC 1 - Enabled with PXE. Dankzij het Mac-adres dat erbij staat heb ik kunnen afleiden dat we díe netwerkaansluiting gebruiken (op 100Mbit trouwens; zal wel met de rest van het netwerk daar te maken hebben). Wat is dat PXE precies, en maakt dat nog wat uit?

Groeten,

Ronald
Forum Manager NL Computer Forum
Microsoft Certified Solutions Expert (MCSE) - Business Intelligence

Offline Ronald

  • Forum Manager
  • *****
  • Berichten: 1.856
  • Geslacht: Man
    • NL Computer Forum
Re: Versnellen SQL query mogelijk?
« Reactie #2 Gepost op: 1 januari 2010, 17:47:55 »
Bericht 13 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Michel Uphoff (Sysop)Datum:03-04-2008
Aan:Ronald BeukerMsgID:3801.13
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
>> Na het defragmenten van de C-schijf loopt de Windows 2003 R2 server een héél stuk beter <<
Nou, da's heel mooi. Zet defragmenteren in een geplande taak. Eens per week of zo op rustige uren zelf laten draaien.
Het belangrijkste had je niet vermeld: Dat de database omgeving en/of instellingen op beide computers behoorlijk verschillen. Want het absurde verschil in snelheid tussen de twee computers kon m.i. al niet door louter OS en hardwareverschillen verklaard worden. Ik begrijp dat je met wat gunstiger instellingen de grootste bottlenecks al hebt werggewerkt.
>> Bus speed 1000 Mhz is. Het geheugen is 4.0 GB ECC DDR2 667 MHz. Is het geheugen nu een bottleneck? <<
Lekker machientje, moet op zich zoeven. Toch geen overijverige virusscanner op dat ding aanwezig? Ik zou minimaal de databasefolders uitsluiten van virusscannen, en als de server louter die database staat te servicen, zou ik helemaal afzien van een real-time scanner. Een (auto) on-demand scan zo eens in de zoveel tijd is dan in de regel voldoende. Dat geheugen (dat in feite op 333MHZ draait) is geen bottleneck. Natuurlijk is 800 of -als het door het bordje ondersteund wordt- 1066 Mhz geheugen sneller, maar in de praktijk merk je er bitter weinig van.
Het wisselbestand zet je bij voorkeur óf op een snelle 2e fysieke harddisk, of als niet te resizen bestand op de OS partitie. Wil je het dus terugzetten naar 1:1 defragmenteer 1:1 (C:) nog een keer, en maak het swapbestand aan in C: en geef het een vaste omvang van 4 GB (min en max is dus gelijk).

>> Wat is dat PXE precies, en maakt dat nog wat uit? <<
Dat is het Preboot eXecution Environment (waarom die techneuten geen begrijpelijke taal kennen weet ik niet). Zeg maar een standaard om een computer -buiten zijn eigen OS om- te kunnen laten opstarten over het netwerk. Het heeft dus geen sok met performance te maken.
Die 1 Gbit natuurlijk wel. Op zich is het bij multi-user gebruik (en daar heb je die W2003 server vast voor) vaak wel voordelig die server op een 1GB switch poort aan te sluiten. Goede switches (Planet, LinkSys, Netgear, D-Link) hebben tegenwoordig bijna allemaal wel 1 tot 4 1Gbit poortjes, naast de gebruikelijk 100 Mbit poorten. Ze kosten echt niet veel, zelfs al kies je voor een switch met louter 10/100/1000 poorten, dan valt de prijs best mee. Ik zag er net al een met 24 1GHz pootjes voor pakweg 320 euro. Tenzij je voor Cisco gaat natuurlijk (wat ik in veel gevallen grote onzin en geldverspillerij vind).
Zet verder eens een tijdje taakbeheer aan, om te zien hoe het staat met het gebruik van CPU, memory en netwerk. Pas de kolommen dan even aan, en voeg toe: Piek geheugen gebruik, virtueel geheugen, IO gelezen en IO geschreven bytes, totale cpu tijd.  Zet de verneiuwingssnelheid eens op laag en kijk na een druk uur eens naar de diverse getallen en de netwerk + geheugen grafiek. Daar kan je veel aan hebben tbv. mogelijke aanpassingen

Michel Uphoff (NLcomputer)
Homepage


Gewijzigd 3/04/2008 15:39 CET door Michel Uphoff (Sysop)


Bericht 14 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:14-04-2008
Aan:Michel Uphoff (Sysop)MsgID:3801.14
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Michel,

Met de nieuwe indexen op de database én dankzij de gedefragmenteerde C-schijf loopt het inderdaad als een zonnetje. Ik stond wel met open mond te kijken toen een SQL-query opeens nog maar 1 seconde duurde (ipv bijna 1 uur <g>).

Ik heb net nog even gekeken: de C-schijf is nog steeds nauwelijks gefragmenteerd. Het wisselbestand op C zetten wordt lastig, want daar heb ik nog maar iets meer dan 4 GB vrij! Het wisselbestand staat nu dus op D (dat heeft een stuwmeer van 200+ GB). Waarom is het eigenlijk beter om de omvang vast te zetten?

De instellingen bij taakbeheer heb ik aangepast. Interessant, SQL Server heeft 66 miljard write bytes. <g>  Wat zijn nou bijvoorbeeld dingen om op te letten? 'Hoge getallen = niet goed'? ;-)

Heb jij trouwens wel eens van VivaldiFramework.exe gehoord? Dat staat erbij als actief proces, maar ik heb geen idee waarvan dat is. De Vier Jaargetijden heb ik in ieder geval nog niet gehoord. <g>

Groeten,

Ronald



Bericht 15 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:14-04-2008
Aan:Hugo KornelisMsgID:3801.15
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer
Hoi Hugo,

Ah ok, er was dus in ieder geval 1 index vanwege die primary key. Maar die had ik dus zowel op mijn computer als op die server, dus daarin zat geen verschil. Met de nieuwe indexen is het ook op de server snel (zelfs nog sneller als op mijn computer <g>). Op mijn computer waren er verder geen indexen!

Nee, echt niet!
<g>

>>Wat gebruik jij eingelijk als front end? In SQL Server Management Studio staan "Indexes" en "Keys" als aparte "mappen" in het object explorer venster, en bestaat (voor zover ik weet) geen "Indexes and keys" optie.<<

Dit gebruik ik:

Microsoft SQL Server Management Studio     9.00.3042.00
Microsoft Analysis Services Client Tools   2005.090.3042.00
Microsoft Data Access Components (MDAC)    6.0.6001.18000 (longhorn_rtm.080118-1840)
Microsoft MSXML                            3.0 4.0 5.0 6.0
Microsoft Internet Explorer                7.0.6001.18000
Microsoft .NET Framework                   2.0.50727.1434
Operating System                           6.0.6001


Ik klik met rechts op een tabel en kies Design. Vervolgens heb ik linksboven een knopje 'Manage Indexes and Keys'. Vervolgens kom ik in een vester dat 'Indexes/Keys' heet.

Al je andere opmerkingen zijn mij duidelijk, hartelijk dank weer daarvoor! :-)   Dat met die CTEs ga ik zeker nog bekijken. Maar vooralsnog richt ik mij eerst op het perfectioneren van de 'logica'. Ik merk dat ik vooral bezig ben met het kunnen afvangen van wéér een onverwachte kolomwaarde. Zo stond er vandaag opeens een '14-4-2008' string in een kolom die normaal gesproken alleen data in '14-04-08' formaat bevat. Dat is een leuke CASE geworden op het 2e teken ná het eerste koppelteken in de string. <g>

CAST(('20' + RIGHT(deliveryDate,2) + '-' +
(select case SUBSTRING(deliveryDate,CHARINDEX('-',deliveryDate)+2,1)
when '-' then '0' + SUBSTRING(deliveryDate,CHARINDEX('-',deliveryDate)+1,1)
ELSE SUBSTRING(deliveryDate,CHARINDEX('-',deliveryDate)+1,2)
END) + '-' +
(select case SUBSTRING(deliveryDate,2,1)
when '-' then '0' + LEFT(deliveryDate,1) + 'T00:00:00'
else LEFT(deliveryDate,2) + 'T00:00:00'
end)) as datetime)
END) AS deliveryDateTime


Wel leuk allemaal! Zeker als het eenmaal werkt. <g>

Groeten,

Ronald



Bericht 16 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Michel Uphoff (Sysop)Datum:14-04-2008
Aan:Ronald BeukerMsgID:3801.16
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
>> Waarom is het eigenlijk beter om de omvang vast te zetten? <<
Vaste omvang = geen uitzetten of krimpen van de swapfile, dus geen fragmentatie mogelijk.
>> 'Hoge getallen = niet goed'? <<
Geen verkeerd uitgangspunt. Meest interessant in algemene zin zijn CPU-tijd (wat belast de processor het meest en blijft dat binnen de perken) , IO gelezen en geschreven bytes (is er iets dat zeer veel bytes verstouwt, en is dat zinnig), piek geheugen gebruik (wat laat het geheugen eventueel vollopen).
>> Heb jij trouwens wel eens van VivaldiFramework.exe gehoord? <<Da's een onderdeel van de (Dell?) SAS RAID Storage Manager, MEER

Michel Uphoff (NLcomputer)
Homepage


Gewijzigd 14/04/2008 16:47 CET door Michel Uphoff (Sysop)


Bericht 17 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:06-05-2008
Aan:Ronald BeukerMsgID:3801.17
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Hieronder de output van de query. Ik heb zo'n donkerbruin vermoeden dat dit niet heel best is. <g>

C'est grâve, docteur? ;-)  Ou ce trouve le button pour défragmenter toutes ça? (Waar zit de knop om dit te defragmenteren? <g>)
Oui, c'est très grave. En dan mag je van geluk spreken dat ik geen idee heb hoe je "rampzalig" in het Frans zegt. Een citaatje uit Books Online:
The value for avg_fragmentation_in_percent should be as close to zero as possible for maximum performance. However, values from 0 percent through 10 percent may be acceptable.
Jij hebt een groot aantal indexen met fragmentatie van boven de 70 procent, met een maximum van bijna 99 procent - ik denk dat je die kan insturen voor een plaatsje in het Guinness Book of Records!
Hoogste tijd om wat aan die indexen te doen. In principe zijn er twee manieren om index fragmentatie te lijf te gaan:
* "reorganize": reorganiseren van de index (ruwweg vergelijkbaar met het defragmenteren van je harde schijf terwijl je het systeem gewoon blijft gebruiken - systeem hoeft niet off line, het heeft weinig impact op performance, maar je behaalt niet het maximale rendement)
* "rebuild": de index geheel opnieuw opbouwen (tot en met SQL Server 2000 betekende dit dat je tijdens de operatie geen beschikking hebt over de index en geen wijzigingen in de tabel kan doen; vanaf SQL Server 2005 kan dit ook online, mits je een enterprise edition licentie hebt, al heeft het natuurlijk wel gevolgen voor je performance tijdens de rebuild).
Nog een stukje Books Online:
After the degree of fragmentation is known, use the following table to determine the best method to correct the fragmentation.
avg_fragmentation_in_percent value Corrective statement
> 5% and < = 30% ALTER INDEX REORGANIZE
> 30%ALTER INDEX REBUILD WITH (ONLINE = ON)*
* Rebuilding an index can be executed online or offline. Reorganizing an index is always executed online. To achieve availability similar to the reorganize option, you should rebuild indexes online.
Hoogste tijd dus om al je indexen te herbouwen met een ALTER INDEX opdracht met de REBUILD optie. Gebruik de ONLINE = ON optie als je een enterprise edition licentie hebt en geen maintenance window kunt gebruiken voor deze operatie. Heb je wel een maintenance window, doe het dan in die periode en doe het dan niet online, want offline gaat het sneller.
Wat je ook moet doen is in SQL Server Management Studio op zoek gaan naar de wizard voor maintenance plans. Die kan je stap voor stap begeleiden in het maken van een maintenance plan dat automatisch periodiek wordt uitgevoerd en waar bijvoorbeeld dit soort operaties in worden opgenomen, zelfs afhankelijk van de fragmentatie op dat moment. Echte experts vinden dat de wizard ze te weinig controle geeft over de maintenance operaties, maar ik denk dat het voor jou een hele stap vooruit zal zijn. Want op basis van de percentages in jouw bericht gok ik dat je nog nooit eerder aan onderhoud van indexen hebt gedacht :)
En overigens vraag ik me af of al die indexen echt nodig zijn, en of zelfs die TMP tabellen misschien wel helemaal weg kunnen - maar ik meen dat we het daar eerder over hebben gehad, al staan de details me niet meer zo voor de geest.
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis
Forum Manager NL Computer Forum
Microsoft Certified Solutions Expert (MCSE) - Business Intelligence

Offline Ronald

  • Forum Manager
  • *****
  • Berichten: 1.856
  • Geslacht: Man
    • NL Computer Forum
Re: Versnellen SQL query mogelijk?
« Reactie #3 Gepost op: 1 januari 2010, 17:48:31 »
Bericht 18 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:06-05-2008
Aan:Ronald BeukerMsgID:3801.18
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Het geheugen is 4.0 GB ECC DDR2 667 MHz. De processor is een 64-bits Dual Core AMD Opteron 2210 met Core Speed 1.8 Ghz
Heb je de 64-bits versie van SQL Server geïnstalleerd? En zo nee, heb je dan AWE ingeschakeld? De 32 bits edities van SQL Server hebben AWE nodig om meer dan 3 GB te kunnen gebruiken, dus als het antwoord op beide vragen nee is, dan zit 1 GB geheugen de hele dag duimen te draaien op die server.....
Fysiek is het 1 schijf
Ik weet dat je vraag over het wisselbestand gaat, maar voor SQL Server is het het beste om aparte schijven (of nog liever RAID arrays) te hebben voor systeemdisk (operating systeem, programmabestanden -inclusief die van SQL Server-, swap file), datafiles, logfiles, datafiles van tempdb, en logfiles van tempdb.
Als je de server alleen voor SQL Server gebruikt, dan zou je als het goed is niet al te veel swap file gebruik moeten zien. SQL Server managet zelf zijn geheugen gebruik en probeert swapping te voorkomen.
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis


Bericht 19 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:06-05-2008
Aan:Michel Uphoff (Sysop)MsgID:3801.19
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Michel,
Dat geheugen (dat in feite op 333MHZ draait) is geen bottleneck. Natuurlijk is 800 of -als het door het bordje ondersteund wordt- 1066 Mhz geheugen sneller, maar in de praktijk merk je er bitter weinig van
Hierbij wel de aantekening dat SQL Server in vergelijking met andere programma's veel intensiever gebruik maakt van het geheugen, dus ik denk dat je sneller geheugen op een SQL Server machine eerder zult merken dan op een "gewone" desktop of een server.
Zet verder eens een tijdje taakbeheer aan
Goede tip. Ronald - als je nog steeds performance problemen ziet, laat het even weten. Ik moet nog wel ergens een overzichtje hebben van de specifieke SQL Server counters die je moet toevoegen om ook een beeld te krijgen van wat SQL Server precies aan bottlenecks tegenkomt (of veroorzaakt <g>).
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis


Bericht 20 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Hugo KornelisDatum:06-05-2008
Aan:Ronald BeukerMsgID:3801.20
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Ronald,
Ik klik met rechts op een tabel en kies Design
Brrrr. Wil je dat niet meer doen? Leer alsjeblieft tabellen te maken met CREATE TABLE en te wijzigen met ALTER TABLE. Ik zeg dit niet uit een soort van snobisme, maar omdat de scripts die de table designer maakt en uitvoert dramatisch slecht zijn. Wijzigingen die met een eenvoudige ALTER TABLE kunnen worden uitgevoerd worden vaak gescript als een rename van de tabel, maken van een nieuwe tabel, kopiëren van alle bestaande rijen en dan verwijderen van de oude tabel. Op je testsysteem merk je dat niet, maar als je dit doet op de productie versie van je 40 TB database, dan is de belangrijkste tabel opeens een paar uur offline. Oeps....
Plus, ik heb ook wel eens scripts gezien waarbij de foutafhandeling niet goed was, zodat je in het regste geval, bij bijvoorbeeld een stroomstoring op exact het "goede" moment, de volledige inhoud van je tabel kwijt kan raken (gezien in SQL Server 2000; nog niet in SQL Server 2005, maar ook niet hard gezocht en ik steek mijn hand er liever niet voor in het vuur).
Vervolgens heb ik linksboven een knopje 'Manage Indexes and Keys'. Vervolgens kom ik in een vester dat 'Indexes/Keys' heet
Ik heb even getest; die lijkt in elk geval wel compleet te zijn.
Zo stond er vandaag opeens een '14-4-2008' string in een kolom die normaal gesproken alleen data in '14-04-08' formaat bevat
O joepie. Data cleansing is so much fun :-D
Ik heb nog even gekeken of ik een manier kon bedenken om je CASE constructie wat overzichtelijker te maken, maar afgezien van het verwijderen van (SELECT en ) rond de CASE expressies heb ik alleen maar andere ingewikkelde zaken kunnen verzinnen. Misschien kan het iets beter als ik er meer tijd in steek, maar het blijft een draak. Het beste dat je kan doen is een flinke lap kommentaar, lijkt mij :)
Groetjes,
Hugo Kornelis, SQL Server MVP

--
Kijk ook eens op mijn blog: http://sqlblog.com/blogs/hugo_kornelis


Bericht 21 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Michel Uphoff (Sysop)Datum:10-05-2008
Aan:AllenMsgID:3801.21
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Hugo,
>> dus ik denk dat je sneller geheugen op een SQL Server machine eerder zult merken dan op een "gewone" desktop of een server. <<
De redenatie intensiever memory gebruik profiteert meer van sneller geheugen dan niet intensief gebruik is natuurlijk juist, maar het is wel ernstig relatief. Er is meer dan de kloksnelheid alleen dat de snelheid van geheugen bepaalt (timing parameters, dual of single channel), en de geheugensnelheid is van redelijk beperkte invloed op de uiteindelijk prestatie, ook bij geheugenintensieve app's.
Het verschil tussen 667 en 800 MHz geheugen is in de regel te verwaarlozen en zelfs het verschil tussen 667 en 1066 MHz geheugen is meestal beperkt tot slechts 4-8% snelheidsverbetering bij geheugenhongerige apps. Maar het verschil tussen diverse merken geheugen en de timing instellingen kan groter zijn. Zo is 667 MHz 3-3-3 geheugen in de regel sneller dan 800 MHz 5-5-5
Hier een performance grafiekje voor verschillende geheugentypes en een geheugenintensieve applicatie:


Michel Uphoff (NLcomputer)
Homepage

Bijlagen :

IMG0017542.gif
16KB


Bericht 22 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:25-05-2008
Aan:Hugo KornelisMsgID:3801.22
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Beste Hugo,
>> Heb je de 64-bits versie van SQL Server geïnstalleerd? En zo nee, heb je dan AWE ingeschakeld? <<
Het was en is een 32-bits versie, en AWE (ik moet steeds denken aan die geluidskaart van vroeger <g>) stond nog niet aan. Ik kon het aanvinken, dus ik heb dat maar gedaan.
Bedankt voor de tips, dus!
Groeten,
Ronald (Sysop)


Bericht 23 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:25-05-2008
Aan:Hugo KornelisMsgID:3801.23
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Beste Hugo,
>> Op je testsysteem merk je dat niet, maar als je dit doet op de productie versie van je 40 TB database, dan is de belangrijkste tabel opeens een paar uur offline. Oeps.... <<
Nou, 40 TB duurt nog wel 'even', maar ik snap je punt. <g>
Maar als je nou het datatype aanpast met de design modus van Management Studio (rechtermuisknop op de tabel en dan Design), past SQL Server dan ook stiekem die onhandige procedure toe die jij beschrijft? Of wordt er dan wél een (snellere?) ALTER TABLE toegepast?
Deze week heb ik het datatype van 1 kolom verandert van int in nvarchar(255). Het bleek nl. tóch voor te kunnen komen dat iemand handmatig iets invoert dat nou net géén geheel getal is. Via de design modus lukte dat niet eens: na een minuut kwam er een time out, en gaf Management Studio het op. Toen heb ik maar dit gedaan:
1. Nieuwe tijdelijke tabel gemaakt, daarin alle data overgepompt (zodat dit een identieke kopie was, met daarin nog het int datatype).
2. Oorspronkelijke tabel geleegd met TRUNCATE TABLE en het  datatype van die ene kolom aangepast van int naar nvarchar(255).
3. De data vanuit de tijdelijke tabel terug geïmporteerd met een query die bij die ene kolom een CAST commando toepast tbv de conversie naar nvarchar.
Dat werkte, en snel ook (halve minuut ofzo voor een paar honderdduizend rijen en een stuk of 20 kolommen).
Je voelt de vraag alweer aankomen: zou jij dit ook zo hebben gedaan? Of wat is jouw taktiek als je een 'flink gevulde' tabel met veel rijen en veel kolommen hebt, waarvan 1 kolom een ander datatype moet krijgen?
Bij tabellen die niet zo heel groot zijn, is het trouwens wel een fluitje van een cent om in de designmodus e.e.a. aan te passen en dan op Save te klikken.
Groeten,
Ronald
 


Bericht 24 van 24

NL Computer Forum ~ SQL & Programmeren
Van:Ronald BeukerDatum:26-07-2008
Aan:Hugo KornelisMsgID:3801.24
Onderwerp:Versnellen SQL query mogelijk?Forum:ws-nlcomputer

Hoi Hugo,
>> Ik moet nog wel ergens een overzichtje hebben van de specifieke SQL Server counters die je moet toevoegen om ook een beeld te krijgen van wat SQL Server precies aan bottlenecks tegenkomt (of veroorzaakt <g>). <<
Op zich loopt de betreffende server wel lekker door. Maar ik ben nog wel benieuwd naar die specifieke SQL Server counters! Kan je dat nog ergens vinden?
Groeten,
Ronald (Sysop)
Forum Manager NL Computer Forum
Microsoft Certified Solutions Expert (MCSE) - Business Intelligence