Geweldig bedankt voor de hulp!Dekaasboer schreef op maandag 30 mei 2016 @ 19:14:
[...]
Ok, nu even interpreteren.
Ik verwijder alles waar we toch niks mee doen.
code:
1 2 3 4 cost threshold for parallelism 0 32767 5 5 max degree of parallelism 0 64 0 0 max server memory (MB) 16 2147483647 2147483647 2147483647 min server memory (MB) 0 2147483647 0 0
Je cost threshold for parralism staat op 5 en je max degree of parralism staat op 0. Dat betekent dat met een hele kleine werklast SQL de query parallel over meerdere cores zal laten lopen.
Verder staat je max en min server memory niet ingesteld. SQL zal geheugen blijven pakken totdat het vol zit en zodra een andere applicatie geheugen nodig heeft zal hij het ook direct allemaal weer afstaan.
Advies:
- cost threshold for parallelism: 50
- max degree of parallelism: 2
- Min server memory: 2000
- Max server memory 4000
code:
1 NXTdimPDM_ELT 3
De recovery mode van je database staat op simple. Indien transactionele integriteit niet super belangrijk is maakt het ook niet zoveel uit. Let wel. Men denkt vaak dat database op simple zetten de log uitschakelt en dat het daarom sneller gaat maar dat klopt niet. SQL werkt altijd via de logfiles. Echter het groei en backup gedrag is anders. Niks mee doen.
code:
1 2 3 4 tempdev 0 1024 10 1 templog 1 64 10 1 PSP2009_B 0 146856 128 0 PSP2009_B_log 1 128248 10 1
Je hebt slechts 1 tempdb file. Microsoft raad 1 tempdb per fysieke core (boven de 8 gaan andere regels gelden) Echter aan de logsize te zien wordt het toch weinig gebruikt.Je database is slechts 1,14GB maar heeft een vaste autogrowth van 1MB. Als er data geschreven wordt fragmenteert je database bestand snel. Het is ook raadzaam om de database alvast ruimte te laten inpikken (anti-shrink). Als de datafile vol zit en deze moet uitgebreid worden dat levert dit vertraging op.
- Maak een 2e tempdb file aan.
De log is 1GB. Dat zegt niet zoveel aangezien er waarschijnlijk een minimum grootte staat ingesteld. De logfile staat wel ingesteld om procentueel 10% te groeien. Het is aan te raden om daar een vaste grootte van te maken. (10mb)
- Zet je file size van de database alvast op 2gb
- Zet de autogrowth op 10mb
- Zet de autogrowth van de logfile van de database op 10mb
code:
1 CXPACKET 2356824 13408519 8283 587312
Het lijkt er op dat je server vaak staat te wachten op geparaleliseerde opdrachten. Het zetten van cost threshold for parallelism en max degree of parallelism zal hier waarschijnlijk al mee helpen.
code:
1 AIM_IMPORT_DML NULL HEAP 33,4364261168385 22468
Je hebt niet echt last van gefragmenteerde indexes. Echter deze tabel is wel een heap (geen index).
code:
1 2 3 4 5 6 7 8 9 10 5 49615020,87 2016-05-30 15:37:34.263 JOBSERVER CREATE INDEX [IX_JOBSERVER_ELEMENT_AIMKEY] ON [NXTdimPDM_ELT].[dbo].[JOBSERVER] ([ELEMENT_AIMKEY]) 5 1316461,5 2016-05-30 15:30:13.013 DOCUMENT CREATE INDEX [IX_DOCUMENT_FILE_LINKNAME] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([FILE_LINKNAME]) INCLUDE ([AIMKEY], [FILE_NAME]) 5 302155,14 2016-05-30 11:30:34.460 DOCUMENT CREATE INDEX [IX_DOCUMENT_PART_NUMBER_FILE_TYPE] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER],[FILE_TYPE]) 5 139319,4 2016-05-27 08:43:24.130 ELEMENT CREATE INDEX [IX_ELEMENT_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [ENTITY_TYPE], [SHORT_DESC], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_1_SHORT], [WORLD_GROUP]) 5 55232,12 2016-05-30 14:09:21.603 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [CREATE_USER], [OWNER], [OWNER_GROUP], [RIGHTS], [WORLD_GROUP]) [s]5 29083,2 2016-05-30 11:30:34.530 DOCUMENT CREATE INDEX [IX_DOCUMENT_PART_NUMBER] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER])[/s] 5 27058,5 2016-05-30 14:36:46.980 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR_STATUSKEY] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR],[STATUSKEY]) INCLUDE ([AIMKEY], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [WORLD_GROUP]) 5 21030,8 2016-05-25 16:40:00.753 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR_STATUSKEY] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR],[STATUSKEY]) INCLUDE ([AIMKEY], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [CUSTOM_3_NAME], [WORLD_GROUP]) 5 20075,88 2016-05-30 14:42:33.300 CONFIGURATION2 CREATE INDEX [IX_CONFIGURATION2_PROFILE] ON [NXTdimPDM_ELT].[dbo].[CONFIGURATION2] ([PROFILE]) INCLUDE ([AIMKEY], [TYPE], [NAME], [VALUE], [PARENT]) 5 15748,8 2016-05-30 15:38:01.523 ELEMENT CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [OWNER], [OWNER_GROUP], [RIGHTS], [CUSTOM_2_NAME], [WORLD_GROUP])
Er zit wat overlap tussen de suggesties voor indexes.
Ik kom uiteindelijk hier op uit. Dit zou al aardig moeten schelen:
SQL:
1 2 3 4 5 6 CREATE INDEX [IX_DOCUMENT_PART_NUMBER_FILE_TYPE] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([PART_NUMBER],[FILE_TYPE]) CREATE INDEX [IX_DOCUMENT_FILE_LINKNAME] ON [NXTdimPDM_ELT].[dbo].[DOCUMENT] ([FILE_LINKNAME]) INCLUDE ([AIMKEY], [FILE_NAME]) CREATE INDEX [IX_ELEMENT_ENTITY_TYPE_DELETE_DATE_DELETE_INITIATOR] ON [NXTdimPDM_ELT].[dbo].[ELEMENT] ([ENTITY_TYPE], [DELETE_DATE], [DELETE_INITIATOR]) INCLUDE ([AIMKEY], [CREATE_DATE], [CREATE_USER], [OWNER], [OWNER_GROUP], [RIGHTS], [WORLD_GROUP])
Al de wijzigingen die ik gesuggereerd hebt kan je via de UI doen (klik rechtermuis op de servernaam en op de namen van de databases in de managment studio) dan weet je ook gelijk waar het zit en als het niet werkt dan kan je het zelf ook terug zetten. Dit is allemaal veilig en zal je niet zomaar in de problemen brengen.
Het aanmaken van de indexen is iets anders. Bij sommige pakketten vervalt de garantie als je aan de database rommelt (sharepoint) andere pakketten ondersteunen het niet. Daar moet je altijd de index in het pakket zelf aanmaken (dynamics AX).
Daarom zou ik altijd voordat je indexen aanmaakt eerst met de leverancier van het pakket overleggen en het eerst in een testomgeving proberen.
Als je beide opties niet hebt maak dan eerst een backup van je database en maak dan de indexen aan. Kijk of het programma nog normaal werkt alvorens gebruikers er weer mee te laten werken.
Bewaar het script waarmee je de indexen hebt aangemaakt. Dan kan je ze altijd weer opzoeken en verwijderen.
Nog 1 laatste tip. Voer je wijzigingen stapsgewijs door. Wellicht maakt de ene wijziging het systeem een stuk sneller en de andere iets weer een stuk trager. Dan lijkt het per saldo hetzelfde.
Nog even over SSD's en de werking van SQL.
SQL is geen dom programma. Zelfs versie 2005 is al een geavanceerd pakket. SQL gaat zoveel mogelijk dingen cachen in het geheugen. Een SSD gaat je dus pas helpen als de bottleneck bij het schrijven van data ligt of als de database niet in het geheugen past.
Je kan overigens best snellere hdd's in de server prikken. Echter wat voor netwerk verbinding heb je? Als je bottleneck niet read IOPS is en je hebt er een 1gbit lan achter hangen schiet je natuurlijk niks op met een dikke SSD.
Ik heb stap voor stap de aanbevelingen doorgevoerd en getest (en opgeschreven wat ik heb gedaan).
Een paar stappen die ik extra gedaan heb/gedaan heb.
minimum server mem staat op 2000mb
max server mem heb ik op 8000mb gezet (heb er nu toch 16gb in zitten, kan ik t net zo goed gebruiken is mijn idee. klopt dit?)
De tempdb aanmaken via:
[sql]
ALTER DATABASE tempdb
ADD FILE (NAME = tempdev2, FILENAME = 'D:\tempdb2.mdf', SIZE = 256);
GO
[/sql]
Deze staat nu dus ook op de SSD
log file initial size op 1gb gezet en autogrowth op 10mb
Deze gaat automatisch naar Restricted File Growth van 2.097.152MB
Echter is de db nog steeds even sloom.
Hier een filmpje van wat het probleem is.
[YouTube: https://www.youtube.com/watch?v=H4GvyZBY37I]
Scientia Potentia Est
Xbox-Live GamerTag: H3llStorm666
19x Q.Cell G5 325wp op APsystems QS1

