tempdb.mdf maakt alle schijfruimte op

[McWolf82]

Sinds vanmorgen het probleem dat op een Windows Server 2008 R2 Standard met SQL Server 2008 R2 een tempdb.mdf wordt aangemaakt van maar liefst 129 GB! De database staat onder de System databases.

Als ik de properties open van de database en ik ga naar 'Files' dan is dat veld leeg, er staan dus helemaal geen 'Database files'.

Ik ben helemaal niet bekend met SQL laat ik dat vooropstellen, dus ik zou het waarderen als er in lekentaal kan worden uitgelegd wat het precies doet, maar voornamelijk hoe ik er voor kan zorgen dat die database niet zo groot wordt.

In de Windows logboeken vind ik het volgende:

Could not allocate space for object '<temporary system object: 422213795708928>' in database 'tempdb' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.

Het probleem is dat de D:\ partitie waar de tempdb.mdf zo groot is nu nog maar 10 MB vrije schijfruimte heeft.
Als ik de SQL Server instance herstart, dan is de tempdb.mdf weer 15 GB en heb ik weer ruim 100 GB aan schijfruimte, maar een uur later was de tempdb.mdf weer 129 GB.
Nu kan ik niet elke keer de SQL Server instance gaan herstarten, dus een oplossing zou heel mooi zijn.

Op die server draait Exact, die heb ik ook al gebeld, maar die zeggen hierbij niet te kunnen ondersteunen want het is geen Exact database.
Iemand een idee wat ik kan doen?

[Sjoak]

Als je een extra disk mount en die tmpdb daar op laat tempen?

[McWolf82]

Sjoak schreef op maandag 15 augustus 2016 @ 14:02:
Als je een extra disk mount en die tmpdb daar op laat tempen?

Zojuist ingelogd met ander domain administrator account en nu kan ik wel de Database files zien van tempdb database.

Er is geen andere locale disk waar die tempdb op kan worden gezet, dan zou ik een iSCSI target moeten maken op een NAS, als dat al mogelijk is, en dan de tempdb bestanden verplaatsen, maar daar komt ook nog wel e.e.a. bij kijken zag ik.

Autogrowth staat op 'By 10 percent, unrestricted growth' voor tempdb.mdf en templog.ldf.
De vraag is dus waarom die tempdb.mdf zo groot wordt, ik snap dat die oneindig groeit met deze instellingen, maar stel ik zet 'enable autogrowth' uit en ik zet 'maximum file size' op 50 GB, is dat een optie?

[chaoscontrol]

McWolf82 schreef op maandag 15 augustus 2016 @ 14:11:
[...]
maar stel ik zet 'enable autogrowth' uit en ik zet 'maximum file size' op 50 GB, is dat een optie?

Ja. Zie je vanzelf wat er omvalt.

[McWolf82]

chaoscontrol schreef op maandag 15 augustus 2016 @ 14:13:
[...]

Ja. Zie je vanzelf wat er omvalt.

Bedankt voor je reactie, maar is het wel/niet aan te raden? Iets laten omvallen is natuurlijk niet de bedoeling.

[chaoscontrol]

Met 10mb vrije ruimte werkt het toch niet echt goed.

[Viper®]

The tempdb system database is a global resource that is available to all users connected to the instance of SQL Server and is used to hold the following:
Temporary user objects that are explicitly created, such as: global or local temporary tables, temporary stored procedures, table variables, or cursors.
Internal objects that are created by the SQL Server Database Engine, for example, work tables to store intermediate results for spools or sorting.
Row versions that are generated by data modification transactions in a database that uses read-committed using row versioning isolation or snapshot isolation transactions.
Row versions that are generated by data modification transactions for features, such as: online index operations, Multiple Active Result Sets (MARS), and AFTER triggers.

MSDN: tempdb Database

Ik vermoed dat een gebruiker of toepassing (Exact?) tijdelijke data wegschrijft

Operations within tempdb are minimally logged. This enables transactions to be rolled back. tempdb is re-created every time SQL Server is started so that the system always starts with a clean copy of the database. Temporary tables and stored procedures are dropped automatically on disconnect, and no connections are active when the system is shut down. Therefore, there is never anything in tempdb to be saved from one session of SQL Server to another. Backup and restore operations are not allowed on tempdb.

Vandaar dat bij je herstart je tempdb gewoon weer leeg is

Er zijn queries om te kijken wie welke data aangemaakt heeft: http://dba.stackexchange....ing-which-temporary-table

[ Voor 26% gewijzigd door Viper® op 15-08-2016 14:22 ]

[Roel_1983]

McWolf82 schreef op maandag 15 augustus 2016 @ 14:15:
[...]

Bedankt voor je reactie, maar is het wel/niet aan te raden? Iets laten omvallen is natuurlijk niet de bedoeling.

Je zult toch op een manier moeten uitzoeken waar die grote hoeveelheid data vandaan komt.

Er zijn natuurlijk allerlei mogelijkheden binnen SQL Server zelf om via diverse querys te kijken wat er in de database staat en waar het vandaan komt, of door welke gebruiker het erin gezet is, maar daar is wat meer kennis voor nodig.

Edit : zie de laatste link in bovenstaande post.

En http://dba.stackexchange....ile-ever-increasing#56706

Maar wat draait er verder op die server, of hoe kan er data worden opgevraagd / weggeschreven in de databases?

Enkel via Exact?

[ Voor 9% gewijzigd door Roel_1983 op 15-08-2016 14:52 ]

[Vorkie]

Ben jij / of je collega, toevallig een upgrade aan het doen van Exact?

[pistole]

Als je de server even opnieuw opstart, of de SQL services even herstart dan wordt de tempdb weggegooid en opnieuw aangemaakt. Als het goed is heb je dan je ruimte weer terug.

[McWolf82]

SQL Server service vanmorgen herstart, dan is er weer voldoende schijfruimte, namelijk 123 GB, maar die schijfruimte is een uur later weer op.
Vanmorgen om 11.45 uur was tempdb.mdf 129 GB, toen SQL Server service herstart, was die nog 15 GB, maar alweer aan het groeien denk ik en om 12.55 uur weer 129 GB.
Er is ook geen Exact upgrade uitgevoerd en op de server draait alleen Exact, geen andere applicaties.

Net 5 GB vrij kunnen maken op D:\, maar ik zie tempdb.mdf niet verder groeien zeg maar.

Zoals aangegeven is mijn kennis zeer beperkt als het gaat om SQL, ik heb dan ook geen idee hoe ik die queries moet uitvoeren en waar ik dan naar moet kijken.

[ Voor 10% gewijzigd door McWolf82 op 15-08-2016 15:16 ]

[Viper®]

SQL query kan je in principe makkelijk via sql server management studio uitvoeren, mits je de juiste rechten hebt.

Maar aangezien je kennis beperkt is is het misschien beter om dit op te pakken samen met iemand met verstand van databases.

[chaoscontrol]

McWolf82 schreef op maandag 15 augustus 2016 @ 15:12:
SQL Server service vanmorgen herstart, dan is er weer voldoende schijfruimte, namelijk 123 GB, maar die schijfruimte is een uur later weer op.
Vanmorgen om 11.45 uur was tempdb.mdf 129 GB, toen SQL Server service herstart, was die nog 15 GB, maar alweer aan het groeien denk ik en om 12.55 uur weer 129 GB.
Er is ook geen Exact upgrade uitgevoerd en op de server draait alleen Exact, geen andere applicaties.

Net 5 GB vrij kunnen maken op D:\, maar ik zie tempdb.mdf niet verder groeien zeg maar.

Zoals aangegeven is mijn kennis zeer beperkt als het gaat om SQL, ik heb dan ook geen idee hoe ik die queries moet uitvoeren en waar ik dan naar moet kijken.

Exact even bellen?

[Brahiewahiewa]

McWolf82 schreef op maandag 15 augustus 2016 @ 14:00:
...Op die server draait Exact, die heb ik ook al gebeld, maar die zeggen hierbij niet te kunnen ondersteunen want het is geen Exact database...

@TS: je hebt geen verstand van SQL, dus huur iemand in die dat wel heeft en probeer er iets van te leren

[rc5proxy]

Check ook even wat ze precies in Exact aan het doen zijn:
het normale werk ?
of zijn ze bv een kwartaal afsluiting aan het uitvoeren oude projecten aan het afsluiten ?

ik neem aan dat dit vandaag voor het eerst voorkomt dus check gewoon bij de gebruikers of er iets speciaals gebeurd !!

[Enforcer]

Wij kunnen helaas niet zien wat er op 'jouw omgeving' gebeurd, waardoor niemand op dit moment een eenduidig antwoord kan geven. Dat je niks van SQL weet kunnen we ook indenken, we zijn namelijk niet allemaal DBA'ers, maar als SysAdmin (althans daar ga ik vanuit) kun je wel degelijk van dit soort situaties leren en in ieder geval wat kennis van SQL op doen. Op Google zijn vele resultaten te vinden over hoe je dit probleem moet aanpakken. Zoek eens op Google - find queries causing the TempDB.

Als er maar 1 database op je SQL omgeving staat en die is van Exact kun je er gewoon vanuit gaan dat het iets met Exact te maken heeft.
Om het probleem als SysAdmin op te lossen > vergroot schijfruimte.
Om het probleem snel structureel op te lossen > huur een DBA'er / Exact specialist in (of leer zelf van Google, met de daarbij behorende risico's).

[ Voor 3% gewijzigd door Enforcer op 15-08-2016 20:06 ]

[McWolf82]

Vanmorgen heb ik Exact gebeld toen dit probleem zich voordeed, maar die zegt dat het niet met Exact te maken heeft omdat het geen Exact database is. Als dat wel zo is, aangezien er alleen Exact op deze server draait, dan ga ik ze weer bellen of ze op z'n minst mee kunnen kijken.

De partitie waar de databases op staan is 300 GB, stel dat ik die vergroot naar 500 GB, dan weet ik nog niet of dat genoeg is, aangezien die tempdb.mdf gewoon de vrije schijfruimte pakt die nodig is blijkbaar. Dus dat is vooralsnog geen optie. Ik moet weten wat dit veroorzaakt.
I.i.g. bedankt voor de reacties.

[Gomez12]

Als jij en je collega's echt niets kunnen bedenken dan zou ik hem gewoon limiteren op een 10GB en gewoon wachten wat er klapt.

In wezen klapt er nu ook voortdurend iets als jij de server opnieuw opstart, maar dat kan bijv best een kwartier verwijderd zijn van de actie die de gebruiker opgestart heeft. Door hem op 10GB te zetten breng je de tijd tussen actie en klappen naar beneden zodat je een interne mail eruit kan doen dat iedereen die een foutmelding krijgt deze even bij jou moet melden.

[McWolf82]

Gisteravond om 22.00 uur de SQL Server service herstart, tempdb.mdf was toen nog maar 7 MB, vanochtend was deze 15 MB, naarmate er medewerkers aan het werk gingen, schoot de database weer naar ditmaal zelfs 135 GB.

Nu heb ik een query gevonden die aangeeft welk tempdb object die ruimte inneemt. http://blog.sqlauthority....-consuming-my-tempdb-now/

De uitkomst zie ik dus in SQL Management Studio, er staat een loginaam bij en een programma, Exact.

[ Voor 9% gewijzigd door McWolf82 op 16-08-2016 09:45 ]

[Palthe]

Nu nog query informatie en dan kan je aan de tabel wel zien welk proces de groei veroorzaakt. Wellicht kan de financiële club bij jullie dan wel een workaround verzinnen of Exact mag iets bedenken om de groei te voorkomen. Je hebt dan "bewijs" dat Exact het veroorzaakt, maar Exact zal ook de actieve query willen weten. Mocht dat niet lukken met bovenstaande kun je eventueel nog een profiler laten mee lopen.

[McWolf82]

Exact gebeld, maar die geven wederom aan dat ze niet mee kunnen kijken en ook geen queries uitvoeren bijvoobeeld, vind ik een vreemd verhaal, het probleem ontstaat doordat er in Exact een opdracht wordt gegeven, er wordt simpelweg op een knop gedrukt om e.e.a te genereren m.b.t. artikelen/voorraad en daardoor ontstaan er problemen ben ik inmiddels achter.

Exact verwees me zelfs door naar Microsoft, aangezien SQL een product is van Microsoft, moest ik het daar maar navragen.
Inmiddels de SQL Server service herstart, tempdb.mdf is nu 8 MB, de klant aangegeven om de opdracht die ze uitvoeren in Exact i.i.g. vandaag niet te starten, als het probleem dan namelijk niet terugkomt dan heeft het dus daarmee te maken,

[chaoscontrol]

McWolf82 schreef op dinsdag 16 augustus 2016 @ 11:24:
Exact gebeld, maar die geven wederom aan dat ze niet mee kunnen kijken en ook geen queries uitvoeren bijvoobeeld, vind ik een vreemd verhaal, het probleem ontstaat doordat er in Exact een opdracht wordt gegeven, er wordt simpelweg op een knop gedrukt om e.e.a te genereren m.b.t. artikelen/voorraad en daardoor ontstaan er problemen ben ik inmiddels achter.

Exact verwees me zelfs door naar Microsoft, aangezien SQL een product is van Microsoft, moest ik het daar maar navragen.
Inmiddels de SQL Server service herstart, tempdb.mdf is nu 8 MB, de klant aangegeven om de opdracht die ze uitvoeren in Exact i.i.g. vandaag niet te starten, als het probleem dan namelijk niet terugkomt dan heeft het dus daarmee te maken,

Ik zou mij niet zo makkelijk laten afschepen. Is de inrichting van de server niet volgens een Exact installatiehandleidng gedaan o.i.d.?

Anders je baas even laten bellen, die betaald er voor.

[Palthe]

Is de actie met het genereren van voorraad wel elke keer afgerond? Of stop jij mssql elke keer tijdens de actie? En hoe groot is de Exact db? Staat dit enigzins in verhouding met de groei? Kunnen zij het genereren nog parametriseren binnen Exact waardoor de actie wat minder omvangrijk wordt?
En ik zou bij Exact even doorvragen naar een specialist. De reactie lijkt mij typisch een van een eerste lijn medewerker. Natuurlijk heeft dit met SQL te maken. Maar Exact trapt iets af waardoor de tempdb zo enorm groeit, dat verzint mssql heus niet zelf. Oplossing moet toch echt vanuit Exact komen, niet vanuit microsoft.
Je bent toch niet aan het reindexen of zo in een maintenance plan?

[Rolfie]

McWolf82 schreef op dinsdag 16 augustus 2016 @ 11:24:
Exact gebeld, maar die geven wederom aan dat ze niet mee kunnen kijken en ook geen queries uitvoeren bijvoobeeld, vind ik een vreemd verhaal, het probleem ontstaat doordat er in Exact een opdracht wordt gegeven, er wordt simpelweg op een knop gedrukt om e.e.a te genereren m.b.t. artikelen/voorraad en daardoor ontstaan er problemen ben ik inmiddels achter.

Exact verwees me zelfs door naar Microsoft, aangezien SQL een product is van Microsoft, moest ik het daar maar navragen.
Inmiddels de SQL Server service herstart, tempdb.mdf is nu 8 MB, de klant aangegeven om de opdracht die ze uitvoeren in Exact i.i.g. vandaag niet te starten, als het probleem dan namelijk niet terugkomt dan heeft het dus daarmee te maken,

Wat een bulls**** verhaal. Als Exact met SQL werkt en zeker als dit mee geleverd wordt door Exact (weet ik niet zeker) moet dit gewoon door Exact ondersteund worden.
Iets in de Exact database wil heel veel data weg schrijven in de tempdb.
Je zal dit moeten onderzoeken (beter Exact zal dit moeten onderzoeken).

Je spreekt momenteel niet met de juiste mensen bij Exact.

[nescafe]

De tempdb kun je shrinken: SSMS > tempdb > Tasks > Shrink > Files

Direct via een query (new query):

SQL:

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 0, TRUNCATEONLY)
GO
DBCC SHRINKFILE (N'templog' , 0, TRUNCATEONLY)
GO

Dit kan onder werktijd (truncate only) en bespaart je een service restart.

Kijk daarna even bij de gebruiker welke bewerking precies dit gedrag veroorzaakt. De omschrijving "een knop gedrukt om e.e.a te genereren m.b.t. artikelen/voorraad" is te globaal om na te gaan wat er exact misgaat. Maak screenshots.

Als je een stappenplan heb, voer deze dan uit en houd in de gaten of deze bewerking tempdb doet groeien. Maak screenshots van de bestanden + grootte voor en na (in Explorer). Hierna kun je hem weer shrinken met bovenstaande code.

Start hierna SQL Profiler en voer de stappen nogmaals uit met de profiler ingeschakeld. Sla de trace op als een .trc-bestand.

Op deze manier heb jij er het meeste aan gedaan om een analyse mogelijk te maken en voorkom je dat een helpdesker deze stappen alsnog met jou uit moet voeren. Wat mij betreft gooi je alles in een zip en stuur je het linea recta naar de helpdesk, al dan niet van de Exact-partner als die in beeld is.

[McWolf82]

De actie met het genereren van voorraad wordt niet afgerond, de tempdb groeit totdat er geen schijfruimte meer is en binnen Exact blijft het proces ook gewoon draaien, maar kan dit simpelweg niet afronden omdat de tempdb niet verder kan groeien.
Na uren wachten besluit ik dan maar om de SQL Server service te herstarten omdat er ook door het gebrek aan schijfruimte andere problemen ontstaan zoals geen synchronisatie meer van wijzigingen tussen Exact Globe en Exact Synergy.
De tempdb shrinken heb ik (nog) niet gedaan, is op dit moment ook even geen reden toe, maar bedankt voor de tip.

In totaal gaat het om 175 GB aan Exact databases, waarvan de grootste 100 GB is.
Vandaag wordt de actie in Exact die het probleem veroorzaakt niet meer uitgevoerd, tot op heden is de vrije schijfruimte niet gezakt.
Morgen gaan we weer testen door de actie in Exact te starten, komt het probleem dan meteen terug dan is de volgende actie weer bellen met Exact.
Dan is het overduidelijk dat het komt door een actie in Exact en dan zal ik ook de klant vragen wat ze precies doen in Exact en screenshots maken.

[nescafe]

Kijk ook even of en welke maintenance plans er zijn gepland en of deze correct worden uitgevoerd en afgerond (SSMS > Management > Maintenance plans > View History en SSMS > SQL Server Agent > Jobs > View History).

[McWolf82]

Het maintenance plan draait goed. De onderdelen Check Database Integrity, Backup Up Database (Full), Back Up Database (Transaction Log), Maintenance Cleanup Task en Shrink Database Task hebben allemaal een groen vinkje.

Exact heb ik wederom gesproken en ze nu willen nu dan toch een kopie van de database ontvangen waarin dit probleem zich voordoet, dus die zal ik ze toesturen.

[Koffie]

Move PNS > WSS