aparte page / extent verhouding > Forum

Forum

Unanswered

Active Topics

Forums

Forums > Forums > DBA

Subject: aparte page / extent verhouding

Prev Next

You are not authorized to post a reply.

Author

Messages

Eduard Beijnes User is Offline

Posts:37

23-07-2008 13:38:32	Alert
Hoi sqlpassers, iemand ervaring met databases waarbij tabellen op een gegeven moment gemiddeld 1 page per extent bevatten ? Op zich komen mijn collega en ik er wel uit maar is misschien wel interessant voor anderen. Bijvoorbeeld in hoeverre optimaliseren de maintenance jobs de db's. en wat voor invloed hebben clustered keys op je onderhoud van je db. Verder vraag ik me af of er een simpelere manier is om e.e.a. aan te pakken en of ik e.e.a. juist interpreteer. Dit situatie is ontstaan na een collation verandering waarvan we (collega en ik) e.e.a. aan het analyseren / uitzoeken / testen zijn. Dit alles bevindt zich op testomgevingen. Na de collation acties blijkt de database qua vulling van de database met 1/3 toegenomen te zijn. Hiermee bedoel ik dus niet de diskruimte maar de daadwerkelijke "in use" binnen de db. waar komt die data vandaan ? ik had eerst 770 mb en nu 1100 mb ? diverse zaken nagelopen en uiteindelijk zie ik op meerdere tabellen dat de page/extent verhouding slecht is (beneden 30%) in het 1100 mb bestand. een van de vele tabellen met aparte extent/page verhouding: DBCC SHOWCONTIG scanning 'X' table... Table: 'X' (770101784); index ID: 0, database ID: 10 TABLE level scan performed. - Pages Scanned................................: 128 - Extents Scanned..............................: 109 - Extent Switches..............................: 108 - Avg. Pages per Extent........................: 1.2 - Scan Density [Best Count:Actual Count].......: 14.68% ⎜:109] - Extent Scan Fragmentation ...................: 96.33% - Avg. Bytes Free per Page.....................: 549.5 - Avg. Page Density (full).....................: 93.21% het aparte is dat de page vullings graad boven de 90% is maar dat de extent vullingsgraad "ongunstig" is. Je kunt een pagina vulling van 100% hebben maar als je 100 pagina's verdeeld over 100 extents heb je eigenlijk een 12,5% vulling (1/8). Voor je leesacties van sql server niet gunstig dus. vervolgens doe ik er maintenance jobs op (reindex/rebuild) en daarna een shrink. de in beslag genomen ruimte is met 1/3 toegenomen en die wil ik terug. het geeft geen resultaat. wat de maintenance jobs doen zie ik via trace en als ik de commando's op bol zoek begrijp ik waarom dat niet geoptimaliseerd wordt. hiernaast lijkt het erop dat shrink op extent nivo werkt en niet op page level. Weet iemand hier meer van of nuttig links ? het blijkt dat de tabel geen clustered index heeft en een non clustered pk. vervolgens key gedropped en als clustered gedefinieerd (toch testsysteem): DBCC SHOWCONTIG scanning 'X' table... Table: 'X' (770101784); index ID: 1, database ID: 10 TABLE level scan performed. - Pages Scanned................................: 104 - Extents Scanned..............................: 14 - Extent Switches..............................: 13 - Avg. Pages per Extent........................: 7.4 - Scan Density [Best Count:Actual Count].......: 92.86% ⎙:14] - Logical Scan Fragmentation ..................: 0.00% - Extent Scan Fragmentation ...................: 35.71% - Avg. Bytes Free per Page.....................: 90.8 - Avg. Page Density (full).....................: 98.88% nu heb ik wel een idee wat hier gebeurt maar ik had er toch geen rekening mee gehouden dat maintenance jobs toch niet alles aanpakken. los van de aparte situatie van de extent vullingsgraad en hoe dit gekomen is. qua oplossen: probleem is dat bij de gekochte applicatie ik niet even allerlei key acties (droppen etc) handig vindt. we hebben een script generator voor de collation verandering en in dat script willen we in een bepaalde fase (wanneer alle beperkingen van een tabel eraf gehaald zijn) een kopieslag naar een tijdelijke tabel toevoegen, de bron truncaten en vervolgens de inhoud terugzetten. om een check te doen op Wat ik me afvraag is: heb je zelf zo een aparte page/extent verhouding gezien ? en wat heb je er mee gedaan ?

An ape in an suit stays an ape.

Eduard Beijnes User is Offline

Posts:37

04-08-2008 11:19:57	Alert
update: 1 gewoon shrinken laat de extend/page ratio zoals het is dus denk ik dat standaard shrink op extent nivo werkt 2 als je de optie van shrink gebruikt om je data naar een andere file te gooien zodat je de huidige kan weggooien dan komen de tabellen met veeel data weer in een 7 tot 8 pages / extent verhouding. dus in dit geval werkt sql server blijkbaar wel op page nivo. het enige is de melding dat de shrink niet volledig gedaan kan worden op je primary file en dat komt denk ik door de systeemtabellen die daar moeten blijven "zitten". aangezien je de data ook weer terug laat verplaatsen is dat geen probleem. voordeel van shrink: geen tabel veranderingen, nadeel: het duurt even.

An ape in an suit stays an ape.

You are not authorized to post a reply.

Forums > Forums > DBA > aparte page / extent verhouding

ActiveForums 3.6