SQL Database groeit van 40GB naar 116GB na Maintenance plan

[De_Bastaard]

Een van onze klanten heeft wat problemen met een applicatie, waarvan we denken dat de performance van SQL een mogelijke oorzaak is.

Nu hebben we samen met de leverancier al gekeken naar de databases, en zagen dat er een hoge fragmentatie was op nagenoeg alle relevante tabellen.

Klant aangeraden om een de tabellen te rebuilden, reorganizen en "update statistics" te doen. Dat hebben ze gedaan, maar nu is de DB van 40GB naar 116GB gegroeid. De fragmentatie is wel verdwenen

We hebben klanten van een vergelijkbare grootte, met evenveel records in de database ... maar daar is de DB zelf maar 30 of 40GB. 116 is echt extreem veel.

Hebben jullie enig idee hoe dit kan? Ik dacht zelf dat het wellicht kwam doordat er opnieuw Indexes e.d. zijn aangemaakt die er voorheen niet waren en dat die misschien nu veel ruimte in nemen?

- Transaction log is maar 5GB;
- Er is weinig ruimte te behalen met het shrinken van de DB, 8GB ofzo.

Even de context, het gaat hier om een DMS van pakweg 4 miljoen documenten.

SQL Server 2005.

[Cyphax]

Je kunt opvragen hoe groot een en ander is met sp_spaceused. Voer die eens uit, en kijk dan eens waar de meeste ruimte naartoe gaat?

[CMD-Snake]

De_Bastaard schreef op vrijdag 15 februari 2013 @ 11:12:
maar nu is de DB van 40GB naar 116GB gegroeid.

De database is dus met een factor 2,9 gegroeid. Dat is wel extreem.

Staat autogrowth aan? Dan sta je in feite toe dat er zulke extreme groei plaats kan vinden in een DB.

[De_Bastaard]

Hi Cyphax,

Spaceused heb ik al gedaan, en ik zie dat het vrij verspreid is over alle tabellen. Vooral de meest gebruikte tabellen zijn gewoon erg groot vergeleken met andere klanten.

Kan het zijn dat SQL wat ruimte nodig heeft gehad om die Indices op te bouwen als deze voorheen niet (of niet goed) aanwezig waren? En dat die space misschien nu moet worden vrij gegeven?

[Cyphax]

CMD-Snake schreef op vrijdag 15 februari 2013 @ 11:25:
[...]

De database is dus met een factor 2,9 gegroeid. Dat is wel extreem.

't Kan erger: http://dba.stackexchange....dexes-db-now-10x-the-size

De_Bastaard schreef op vrijdag 15 februari 2013 @ 11:26:
Kan het zijn dat SQL wat ruimte nodig heeft gehad om die Indices op te bouwen als deze voorheen niet (of niet goed) aanwezig waren? En dat die space misschien nu moet worden vrij gegeven?

In het linkje een paar regels hierboven hebben ze het over de fill-factor als mogelijke oorzaak. Wat is de fill-factor van die dingen?

[De_Bastaard]

Dat zal ik even moeten controleren, klant is pas maandag weer bereikbaar voor verder troubleshooten

[CMD-Snake]

Cyphax schreef op vrijdag 15 februari 2013 @ 11:31:
't Kan erger: http://dba.stackexchange....dexes-db-now-10x-the-size

Zo... Stevige database ineens.

De_Bastaard schreef op vrijdag 15 februari 2013 @ 11:12:
- Er is weinig ruimte te behalen met het shrinken van de DB, 8GB ofzo.

Is dit voor of na dit extreme onderhoud?

[De_Bastaard]

Na het onderhoud

[CMD-Snake]

De_Bastaard schreef op vrijdag 15 februari 2013 @ 11:52:
Na het onderhoud

Okay.

Maar is de klant niet rustig begonnen met het onderhoud? Als je fragmentatie hebt kan je gewoon shrink db doen en dan wordt in ieder geval de data meer naar de bovenkant van de bestanden verplaatst. Kan soms al je probleem oplossen.

Ze konden ook nog eerst de diagnostische tools draaien en kijken wat daar uit kwam.

Wie weet hebben ze inderdaad een fout gemaakt met de fill factor van de indexes.

[De_Bastaard]

Ik zal die fill factor maandag even controleren inderdaad.

Ze zijn niet rustig begonnen met een maintenance plan. Voorheen hadden ze er geen, waarna wij hebben gezegd doe eerst rebuild/reorganize en update statistics en eventueel daarna een backup. Maar, na die eerste 3 was de DB dus al gigantisch

[De_Bastaard]

Voor het gemak heb ik dat met die Fill Factor even getest op een test DB en dat zou goed een van de oorzaken kunnen zijn :-)

Mijn DB Ging van 1.2 GB naar 4GB met een 90% Free Space setting

[Againzender]

Ik zou ook als eerste even naar de fill factor kijken. Misschien heeft iemand in het verleden gedacht dat het wel leuk was daar wat aan te lopen veranderen...

Nieuwsgierig: een DMS met 4M documenten... staan die docs in de DB, of is dit met EBS (2005 tenslotte) gedaan? Of lost de applicatie dit op wbt de opslag van de bestanden?

[De_Bastaard]

In SQL Staat per document een verwijzing naar de locatie van het document op een filestore. Server applicatie haalt dat document dan weer op en stuurt het naar de client.