10
We observed that TempDB increased rapidly and continuously for about 1 hr. We got to know that there was some transaction that was coming from Dynamics AX application (from USER AOS Servers) which need space in TempDB. Is there any way we could check which process resulted in Temp DB increase and the user who was running the process.
It seems to me that you still didn't look at the data in TempDB.
You said that most of the space is taken by DocuRef, but that's about the AX database, right? You have a problem in a different database, TempDB, and that's what you should explore.
Hi Andre,
Thanks for your time to reply on this!
Our challenge is also the same , we are unable to find the user or process which caused the temp DB grown in the production environment as we have multiple users and AOS .
Is there any alternative method to find out the root cause, which helps to avoid this issue in near future.
Thanks in advance!
When it stopped growing, it would be hard to find out what happened. Are you aware if someone tried to start a huge process or report?
Current size: 832 GB
Amount of available space in database : 815 GB
TempDB was set to autogrowth by every 1000 MB
We observed growth of 444 GB in Temp DB, during the 1 hr of time where tempdb was increased rapdily and increased the drive size for temp db drives.
Thanks Andre for the reply,
During the issue , it was observed that around 443 GB was increased for one hour only ...Post that it stopped automatically .
Could you share some insights that how to find which transaction caused/user caused this issue ?
What might be the possible reasons of this abnormal Temp DB growth ?
And could you also suggest on how to maintain the max free space to avoid any performance issues ?
Thanks in advance!
Hi Teja,
Can you tell a bit more on the initial and the current size of the Temp DB? Some processes could indeed consume quite some Temp DB size. Usually at customers we tried to set a large fixed (initial) size to get the best performance out of the Temp DB.
Thanks for the suggestion, But do you suggest any alternate method as we use multiple AOS servers and user sessions
Maybe you should look at the actual data in the table.
You could also use tracing, although it's a bit difficult to work with if you have multiple AOS servers and many users sessions.
Thanks for the quick reply Martin
Version: AX 2012 R3 CU13
Environment: Production
Found that DOCUREF table is taking most space and causing this issue but unable to find the user and process for which it caused
Which environment in which version of AX are you talking about?
If you have access to the database, you should be able to find out which tables are consuming most space. It should give you some idea about which process it's related to.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,280
Super User 2024 Season 2
#2
Martin Dráb
230,214
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (