compdigit44
asked on
SQL 2012 TempDB Large Log File
Our SQL 2012 cluster is used to host our SharePoint 2012 DB's only. I know ou server is not setup correctly and doing my best to correct things from past admins..
Anyway I have noticed the TempDB is divided up into 6 files 1GB each but the single tempdb log file is 130GB!!!!!
Why is this and how can I correct it???
Anyway I have noticed the TempDB is divided up into 6 files 1GB each but the single tempdb log file is 130GB!!!!!
Why is this and how can I correct it???
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I just checked and the TempDB is set to a simple recovery model..
I have read that a large tempdb log can be caused by uncommitted changes. How can I check for this?
I have read that a large tempdb log can be caused by uncommitted changes. How can I check for this?
ASKER
I hate to say this but I made an ID10T mistake!!!
I thought my log files size was in GB come to find out it was only 120MB...... :o)
Please keep posted thought because I have a number of other question I will be opening a question for.
I thought my log files size was in GB come to find out it was only 120MB...... :o)
Please keep posted thought because I have a number of other question I will be opening a question for.
Hi,
just some more comments:
It is common best practice to create multiple files for the temp db with a fixed size - to enforce/enable better parallelism. Normally you create a dedicated file per 1-2 cores (meaning 1 CPU Quad Core with 2 threads for each code (8 overall threads) should have 2-4 files.
Second, SharePoint is using the tempdb internally very heavily - so a good tempdb setup will increase the overall performance dramatically (or make it unusable if the SQL config is bad) - e.g. each and every security trimmed "list" (search, list elements, documents, actions ...) will be stored inside of temporary table variables inside the called stored procedures. These variables are normally stored inside the tempdb until the end of the stored procedures. Therefore a single search or list view can have a lot of I/O to the tempdb.
HTH
Rainer
just some more comments:
It is common best practice to create multiple files for the temp db with a fixed size - to enforce/enable better parallelism. Normally you create a dedicated file per 1-2 cores (meaning 1 CPU Quad Core with 2 threads for each code (8 overall threads) should have 2-4 files.
Second, SharePoint is using the tempdb internally very heavily - so a good tempdb setup will increase the overall performance dramatically (or make it unusable if the SQL config is bad) - e.g. each and every security trimmed "list" (search, list elements, documents, actions ...) will be stored inside of temporary table variables inside the called stored procedures. These variables are normally stored inside the tempdb until the end of the stored procedures. Therefore a single search or list view can have a lot of I/O to the tempdb.
HTH
Rainer
ASKER
Great tip!!!!!!!!!!!! :o)
And I forgot to answer your question. It is because the database was setup with the default Full Recovery Model and no Transaction Log backups have been done.