cleanup the tempdb

Is there currently a way to cleanup the tempdb?
Tried dbcc shrinkfile , but no luck.
Can't restart the server ,because it's on production.
What makes tempDB big ?
and tempDB is in Simple mode , but not truncating it .
ThanksDid you post to enough groups<g>? Tempdb is used for all sorts <pun
intended> of things during the normal operation of the database. What makes
it so big (by the way how big is it?) depends on what your doing but it is
most likely the result of a large join or sort operation. You might want to
check to see if you have a long running open tran as well. If it got that
big once it is most likely going to get that big again (unless it was a
mistake) so you shouldn't bother to shrink it until you know for sure. Next
time you see a lot of activity in it you can investigate to see what is
happening at the time with profiler, sp_who etc.
--
Andrew J. Kelly
SQL Server MVP
"Abraham" <binu_ca@.yahoo.com> wrote in message
news:eADnDxBQDHA.1556@.TK2MSFTNGP10.phx.gbl...
> Is there currently a way to cleanup the tempdb?
> Tried dbcc shrinkfile , but no luck.
> Can't restart the server ,because it's on production.
> What makes tempDB big ?
> and tempDB is in Simple mode , but not truncating it .
> Thanks
>

checkpoint on tempdb

It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPD
B
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.

checkpoint on tempdb

It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPDB
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
--
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.

checkpoint on tempdb

It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
was applied) the following situation started occuring:
- There is a simple scripted trace running on the server that captures
STMTCompleted and BatchCompleted events;
- A scheduled tasks fires every minute and captures the results using
::fn_trace_gettable function;
- tempdb is in Simple recovery mode (doh, that's the only mode that this
database can be in), but without explicitly issuing CHECKPOINT or BACKUP LOG
TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
While investigating the issue I set 3502 trace flag on, and also discovered
that even after explicitly issuing CHECKPOINT the entry about the checkpoint
on tempdb is not made.
As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job that
runs every minute. But what's interesting is that exactly the same scenario
with exactly the same trace works fine in 818 build, and space used in TEMPDB
log device gets periodically cleared without having to explicitly issue any
checkpoint-related commands.
Is it a bug in SP4? And why 3502 trace flag does not post the entry for
TEMPDB (dbid 2)?
Any pointers would be appreciated.
Thanks for reporting this problem.
TF3502 does not post entry in the errorlog for tempdb. This has been the
case since SQL 7.0.
There is another way to find out if there has been a checkpoint:
use tempdb
select * from ::fn_dblog(null, null)
This dumps the log since the last checkpoint.
Can you try that and let us know if there is indeed no checkpoint log
record? Or you could send me the data+log file of your tempdb in a zip file
and I will take a look. But that file may be huge.
This could be a bug. In the mean time I will ask the devs around here to see
if
anybody knows.
Finally, please note that both TF3502 and fn_dblog are undocumented
commands. There might be issues with using them on production systems. You
could open a case with Microsoft Product Support if you are not comfortable
with diagnosing the problem on your own.
Wei Xiao [MSFT]
SQL Server Storage Engine Development
http://blogs.msdn.com/weix
This posting is provided "AS IS" with no warranties, and confers no rights.
"Robert Djabarov" <Robert Djabarov@.discussions.microsoft.com> wrote in
message news:B1CA9B5B-34B2-46D2-927B-01815B92E912@.microsoft.com...
> It appears that after applying SP4 (the box has 4GB of RAM, so no post-SP4
> was applied) the following situation started occuring:
> - There is a simple scripted trace running on the server that captures
> STMTCompleted and BatchCompleted events;
> - A scheduled tasks fires every minute and captures the results using
> ::fn_trace_gettable function;
> - tempdb is in Simple recovery mode (doh, that's the only mode that this
> database can be in), but without explicitly issuing CHECKPOINT or BACKUP
> LOG
> TEMPDB WITH TRUNCATE_ONLY space used in the log device continues growing.
> While investigating the issue I set 3502 trace flag on, and also
> discovered
> that even after explicitly issuing CHECKPOINT the entry about the
> checkpoint
> on tempdb is not made.
> As a workaround I added BACKUP LOG TEMPDB WITH TRUNCATE_ONLY to the job
> that
> runs every minute. But what's interesting is that exactly the same
> scenario
> with exactly the same trace works fine in 818 build, and space used in
> TEMPDB
> log device gets periodically cleared without having to explicitly issue
> any
> checkpoint-related commands.
> Is it a bug in SP4? And why 3502 trace flag does not post the entry for
> TEMPDB (dbid 2)?
> Any pointers would be appreciated.

Checkpoint and TempDB

We are running SQL 2005, SP1, on Windows 2003.
Occasionally we have a TempDB log that starts growing exponentially. We run
DBCC OpenTran across all databases, we look for high rowcounts on tempdb..
sysindexes for objects like '#%', but nothing shows its face. This happens
very infrequently, and since nothing definitive is found, we reluctantly sto
p
and restart services.
One thing I would like information on is the checkpoint process, suspecting
that the automatic checkpoint is not occurring in TempDB, and thus, all of a
sudden we have rapid growth.
Is there any way to verify at the time, if checkpoint is on/off, working/not
working?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200701/1I have a similar problelm. We have some in-house databases and some
that we have unfortunately inherited. One of them pulls in millions of
records into tables that are temporary using #tablename. Our company is
not going to pay to change the application at this point, so I have to
deal with it. What I did is create a simple job that checks the size of
the temp db file. I am on 2000 so I used sysfiles. When the size in our
case exceeds 15 gigs, I just use msdb.db.sp_start_job to kick off a job
to shrink the temp db. I think it probably runs about 3X a week, but
has been working to keep everything under control. I also set a max
size of 20 gigs so it doesn't eat up all the space it has on its drive.
Maybe these ideas will help. At least you wouldn't have to stop/start
services and manually intervene. My shrinks generally occur at 2-4 a.m.
when I am sleeping
cbrichards via droptable.com wrote:
> We are running SQL 2005, SP1, on Windows 2003.
> Occasionally we have a TempDB log that starts growing exponentially. We ru
n
> DBCC OpenTran across all databases, we look for high rowcounts on tempdb..
> sysindexes for objects like '#%', but nothing shows its face. This happens
> very infrequently, and since nothing definitive is found, we reluctantly s
top
> and restart services.
> One thing I would like information on is the checkpoint process, suspectin
g
> that the automatic checkpoint is not occurring in TempDB, and thus, all of
a
> sudden we have rapid growth.
> Is there any way to verify at the time, if checkpoint is on/off, working/n
ot
> working?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200701/1|||Thanks Kristina, but that does not address my issue, as I suspect the
Checkpoint is not working. Since I suspect that the checkpoint process is no
t
occurring on TempDB, I need to know if there is a way to verify my suspicion
s
at the time the crisis is occurring.
This Thread is not closed. Please HELP!!
Message posted via http://www.droptable.com|||To capture CHECKPOINT you need to run profiler.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c32652e33427@.uwe...
> Thanks Kristina, but that does not address my issue, as I suspect the
> Checkpoint is not working. Since I suspect that the checkpoint process is
> not
> occurring on TempDB, I need to know if there is a way to verify my
> suspicions
> at the time the crisis is occurring.
> This Thread is not closed. Please HELP!!
> --
> Message posted via http://www.droptable.com
>|||So I am in the middle of a crisis, my tempdb log is growing at about 2 gig a
minute, and the quickest way to determine if my CHECKPOINT is working is to
run Profiler?
What EventClass and Columns would I use?
Within those EventClasses and Columns you recommend, what am I looking for?
I take it I would filter the Profiler on DatabaseID = 2?
Uri Dimant wrote:[vbcol=seagreen]
>To capture CHECKPOINT you need to run profiler.
>
>[quoted text clipped - 4 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200701/1|||Hi
You can restart SQL Server and it will create a new tempdb database
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c576f9f33a54@.uwe...
> So I am in the middle of a crisis, my tempdb log is growing at about 2 gig
> a
> minute, and the quickest way to determine if my CHECKPOINT is working is
> to
> run Profiler?
> What EventClass and Columns would I use?
> Within those EventClasses and Columns you recommend, what am I looking
> for?
> I take it I would filter the Profiler on DatabaseID = 2?
> Uri Dimant wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200701/1
>|||Wow!
Am I not making sense!!
Please somebody...address my questions.
This case is not closed!!!
Uri Dimant wrote:[vbcol=seagreen]
>Hi
>You can restart SQL Server and it will create a new tempdb database
>
>[quoted text clipped - 16 lines]
Message posted via http://www.droptable.com|||Does this help?
http://support.microsoft.com/kb/317375/
If this is urgent you should open a support case.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c60e0873cbc4@.uwe...
> Wow!
> Am I not making sense!!
> Please somebody...address my questions.
> This case is not closed!!!
> Uri Dimant wrote:
> --
> Message posted via http://www.droptable.com
>|||While that is a good link, and I have it bookmarked, my initial question tha
t
started this thread is still not being addressed:
****************************************
************************************
***************************************
One thing I would like information on is the checkpoint process, suspecting
that the automatic checkpoint is not occurring in TempDB, and thus, all of a
sudden we have rapid growth.
Is there any way to verify at the time of the crisis, if checkpoint is on/of
f,
working/not
working?
****************************************
************************************
***************************************
Roger Wolter[MSFT] wrote:[vbcol=seagreen]
>Does this help?
>http://support.microsoft.com/kb/317375/
>If this is urgent you should open a support case.
>
>[quoted text clipped - 14 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200701/1|||Hi
> Is there any way to verify at the time of the crisis, if checkpoint is
> on/off,
> working/not
> working?
1)
You can monitor the number of pages flushed by a checkpoint
using PerfMon - SQLServer:Buffer Manager object, Checkpoint
pages/sec counter
2)
You can start SQL Server with the
traceflag 3502. With this trace falg on, whenever a checkpoint occurs, it
will be recorded in the SQL Server error log, along with the time of the
checkpoint.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c62ef5fc5f05@.uwe...
> While that is a good link, and I have it bookmarked, my initial question
> that
> started this thread is still not being addressed:
> ****************************************
**********************************
****************************************
*
> One thing I would like information on is the checkpoint process,
> suspecting
> that the automatic checkpoint is not occurring in TempDB, and thus, all of
> a
> sudden we have rapid growth.
> Is there any way to verify at the time of the crisis, if checkpoint is
> on/off,
> working/not
> working?
> ****************************************
**********************************
****************************************
*
> Roger Wolter[MSFT] wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forum...server/200701/1
>

Checkpoint and TempDB

We are running SQL 2005, SP1, on Windows 2003.
Occasionally we have a TempDB log that starts growing exponentially. We run
DBCC OpenTran across all databases, we look for high rowcounts on tempdb..
sysindexes for objects like '#%', but nothing shows its face. This happens
very infrequently, and since nothing definitive is found, we reluctantly stop
and restart services.
One thing I would like information on is the checkpoint process, suspecting
that the automatic checkpoint is not occurring in TempDB, and thus, all of a
sudden we have rapid growth.
Is there any way to verify at the time, if checkpoint is on/off, working/not
working?
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1I have a similar problelm. We have some in-house databases and some
that we have unfortunately inherited. One of them pulls in millions of
records into tables that are temporary using #tablename. Our company is
not going to pay to change the application at this point, so I have to
deal with it. What I did is create a simple job that checks the size of
the temp db file. I am on 2000 so I used sysfiles. When the size in our
case exceeds 15 gigs, I just use msdb.db.sp_start_job to kick off a job
to shrink the temp db. I think it probably runs about 3X a week, but
has been working to keep everything under control. I also set a max
size of 20 gigs so it doesn't eat up all the space it has on its drive.
Maybe these ideas will help. At least you wouldn't have to stop/start
services and manually intervene. My shrinks generally occur at 2-4 a.m.
when I am sleeping :)
cbrichards via SQLMonster.com wrote:
> We are running SQL 2005, SP1, on Windows 2003.
> Occasionally we have a TempDB log that starts growing exponentially. We run
> DBCC OpenTran across all databases, we look for high rowcounts on tempdb..
> sysindexes for objects like '#%', but nothing shows its face. This happens
> very infrequently, and since nothing definitive is found, we reluctantly stop
> and restart services.
> One thing I would like information on is the checkpoint process, suspecting
> that the automatic checkpoint is not occurring in TempDB, and thus, all of a
> sudden we have rapid growth.
> Is there any way to verify at the time, if checkpoint is on/off, working/not
> working?
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1|||Thanks Kristina, but that does not address my issue, as I suspect the
Checkpoint is not working. Since I suspect that the checkpoint process is not
occurring on TempDB, I need to know if there is a way to verify my suspicions
at the time the crisis is occurring.
This Thread is not closed. Please HELP!!
--
Message posted via http://www.sqlmonster.com|||To capture CHECKPOINT you need to run profiler.
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6c32652e33427@.uwe...
> Thanks Kristina, but that does not address my issue, as I suspect the
> Checkpoint is not working. Since I suspect that the checkpoint process is
> not
> occurring on TempDB, I need to know if there is a way to verify my
> suspicions
> at the time the crisis is occurring.
> This Thread is not closed. Please HELP!!
> --
> Message posted via http://www.sqlmonster.com
>|||So I am in the middle of a crisis, my tempdb log is growing at about 2 gig a
minute, and the quickest way to determine if my CHECKPOINT is working is to
run Profiler?
What EventClass and Columns would I use?
Within those EventClasses and Columns you recommend, what am I looking for?
I take it I would filter the Profiler on DatabaseID = 2?
Uri Dimant wrote:
>To capture CHECKPOINT you need to run profiler.
>> Thanks Kristina, but that does not address my issue, as I suspect the
>> Checkpoint is not working. Since I suspect that the checkpoint process is
>[quoted text clipped - 4 lines]
>> This Thread is not closed. Please HELP!!
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1|||Hi
You can restart SQL Server and it will create a new tempdb database
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6c576f9f33a54@.uwe...
> So I am in the middle of a crisis, my tempdb log is growing at about 2 gig
> a
> minute, and the quickest way to determine if my CHECKPOINT is working is
> to
> run Profiler?
> What EventClass and Columns would I use?
> Within those EventClasses and Columns you recommend, what am I looking
> for?
> I take it I would filter the Profiler on DatabaseID = 2?
> Uri Dimant wrote:
>>To capture CHECKPOINT you need to run profiler.
>> Thanks Kristina, but that does not address my issue, as I suspect the
>> Checkpoint is not working. Since I suspect that the checkpoint process
>> is
>>[quoted text clipped - 4 lines]
>> This Thread is not closed. Please HELP!!
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1
>|||Wow!
Am I not making sense!!
Please somebody...address my questions.
This case is not closed!!!
Uri Dimant wrote:
>Hi
>You can restart SQL Server and it will create a new tempdb database
>> So I am in the middle of a crisis, my tempdb log is growing at about 2 gig
>> a
>[quoted text clipped - 16 lines]
>> This Thread is not closed. Please HELP!!
--
Message posted via http://www.sqlmonster.com|||Does this help?
http://support.microsoft.com/kb/317375/
If this is urgent you should open a support case.
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6c60e0873cbc4@.uwe...
> Wow!
> Am I not making sense!!
> Please somebody...address my questions.
> This case is not closed!!!
> Uri Dimant wrote:
>>Hi
>>You can restart SQL Server and it will create a new tempdb database
>> So I am in the middle of a crisis, my tempdb log is growing at about 2
>> gig
>> a
>>[quoted text clipped - 16 lines]
>> This Thread is not closed. Please HELP!!
> --
> Message posted via http://www.sqlmonster.com
>|||While that is a good link, and I have it bookmarked, my initial question that
started this thread is still not being addressed:
*******************************************************************************************************************
One thing I would like information on is the checkpoint process, suspecting
that the automatic checkpoint is not occurring in TempDB, and thus, all of a
sudden we have rapid growth.
Is there any way to verify at the time of the crisis, if checkpoint is on/off,
working/not
working?
*******************************************************************************************************************
Roger Wolter[MSFT] wrote:
>Does this help?
>http://support.microsoft.com/kb/317375/
>If this is urgent you should open a support case.
>> Wow!
>[quoted text clipped - 14 lines]
>> This Thread is not closed. Please HELP!!
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1|||Hi
> Is there any way to verify at the time of the crisis, if checkpoint is
> on/off,
> working/not
> working?
1)
You can monitor the number of pages flushed by a checkpoint
using PerfMon - SQLServer:Buffer Manager object, Checkpoint
pages/sec counter
2)
You can start SQL Server with the
traceflag 3502. With this trace falg on, whenever a checkpoint occurs, it
will be recorded in the SQL Server error log, along with the time of the
checkpoint.
"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:6c62ef5fc5f05@.uwe...
> While that is a good link, and I have it bookmarked, my initial question
> that
> started this thread is still not being addressed:
> *******************************************************************************************************************
> One thing I would like information on is the checkpoint process,
> suspecting
> that the automatic checkpoint is not occurring in TempDB, and thus, all of
> a
> sudden we have rapid growth.
> Is there any way to verify at the time of the crisis, if checkpoint is
> on/off,
> working/not
> working?
> *******************************************************************************************************************
> Roger Wolter[MSFT] wrote:
>>Does this help?
>>http://support.microsoft.com/kb/317375/
>>If this is urgent you should open a support case.
>> Wow!
>>[quoted text clipped - 14 lines]
>>>
>>> This Thread is not closed. Please HELP!!
> --
> Message posted via SQLMonster.com
> http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1
>|||Thanks Uri. I appreciate the info.
Uri Dimant wrote:
>Hi
>> Is there any way to verify at the time of the crisis, if checkpoint is
>> on/off,
>> working/not
>> working?
>1)
>You can monitor the number of pages flushed by a checkpoint
>using PerfMon - SQLServer:Buffer Manager object, Checkpoint
>pages/sec counter
>2)
>You can start SQL Server with the
>traceflag 3502. With this trace falg on, whenever a checkpoint occurs, it
>will be recorded in the SQL Server error log, along with the time of the
>checkpoint.
>> While that is a good link, and I have it bookmarked, my initial question
>> that
>[quoted text clipped - 22 lines]
>>>
>>> This Thread is not closed. Please HELP!!
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200701/1

Checkpoint and TempDB

We are running SQL 2005, SP1, on Windows 2003.
Occasionally we have a TempDB log that starts growing exponentially. We run
DBCC OpenTran across all databases, we look for high rowcounts on tempdb..
sysindexes for objects like '#%', but nothing shows its face. This happens
very infrequently, and since nothing definitive is found, we reluctantly stop
and restart services.
One thing I would like information on is the checkpoint process, suspecting
that the automatic checkpoint is not occurring in TempDB, and thus, all of a
sudden we have rapid growth.
Is there any way to verify at the time, if checkpoint is on/off, working/not
working?
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200701/1
I have a similar problelm. We have some in-house databases and some
that we have unfortunately inherited. One of them pulls in millions of
records into tables that are temporary using #tablename. Our company is
not going to pay to change the application at this point, so I have to
deal with it. What I did is create a simple job that checks the size of
the temp db file. I am on 2000 so I used sysfiles. When the size in our
case exceeds 15 gigs, I just use msdb.db.sp_start_job to kick off a job
to shrink the temp db. I think it probably runs about 3X a week, but
has been working to keep everything under control. I also set a max
size of 20 gigs so it doesn't eat up all the space it has on its drive.
Maybe these ideas will help. At least you wouldn't have to stop/start
services and manually intervene. My shrinks generally occur at 2-4 a.m.
when I am sleeping
cbrichards via droptable.com wrote:
> We are running SQL 2005, SP1, on Windows 2003.
> Occasionally we have a TempDB log that starts growing exponentially. We run
> DBCC OpenTran across all databases, we look for high rowcounts on tempdb..
> sysindexes for objects like '#%', but nothing shows its face. This happens
> very infrequently, and since nothing definitive is found, we reluctantly stop
> and restart services.
> One thing I would like information on is the checkpoint process, suspecting
> that the automatic checkpoint is not occurring in TempDB, and thus, all of a
> sudden we have rapid growth.
> Is there any way to verify at the time, if checkpoint is on/off, working/not
> working?
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200701/1
|||Thanks Kristina, but that does not address my issue, as I suspect the
Checkpoint is not working. Since I suspect that the checkpoint process is not
occurring on TempDB, I need to know if there is a way to verify my suspicions
at the time the crisis is occurring.
This Thread is not closed. Please HELP!!
Message posted via http://www.droptable.com
|||To capture CHECKPOINT you need to run profiler.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c32652e33427@.uwe...
> Thanks Kristina, but that does not address my issue, as I suspect the
> Checkpoint is not working. Since I suspect that the checkpoint process is
> not
> occurring on TempDB, I need to know if there is a way to verify my
> suspicions
> at the time the crisis is occurring.
> This Thread is not closed. Please HELP!!
> --
> Message posted via http://www.droptable.com
>
|||So I am in the middle of a crisis, my tempdb log is growing at about 2 gig a
minute, and the quickest way to determine if my CHECKPOINT is working is to
run Profiler?
What EventClass and Columns would I use?
Within those EventClasses and Columns you recommend, what am I looking for?
I take it I would filter the Profiler on DatabaseID = 2?
Uri Dimant wrote:[vbcol=seagreen]
>To capture CHECKPOINT you need to run profiler.
>[quoted text clipped - 4 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200701/1
|||Hi
You can restart SQL Server and it will create a new tempdb database
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c576f9f33a54@.uwe...
> So I am in the middle of a crisis, my tempdb log is growing at about 2 gig
> a
> minute, and the quickest way to determine if my CHECKPOINT is working is
> to
> run Profiler?
> What EventClass and Columns would I use?
> Within those EventClasses and Columns you recommend, what am I looking
> for?
> I take it I would filter the Profiler on DatabaseID = 2?
> Uri Dimant wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200701/1
>
|||Wow!
Am I not making sense!!
Please somebody...address my questions.
This case is not closed!!!
Uri Dimant wrote:[vbcol=seagreen]
>Hi
>You can restart SQL Server and it will create a new tempdb database
>[quoted text clipped - 16 lines]
Message posted via http://www.droptable.com
|||Does this help?
http://support.microsoft.com/kb/317375/
If this is urgent you should open a support case.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c60e0873cbc4@.uwe...
> Wow!
> Am I not making sense!!
> Please somebody...address my questions.
> This case is not closed!!!
> Uri Dimant wrote:
> --
> Message posted via http://www.droptable.com
>
|||While that is a good link, and I have it bookmarked, my initial question that
started this thread is still not being addressed:
************************************************** ************************************************** ***************
One thing I would like information on is the checkpoint process, suspecting
that the automatic checkpoint is not occurring in TempDB, and thus, all of a
sudden we have rapid growth.
Is there any way to verify at the time of the crisis, if checkpoint is on/off,
working/not
working?
************************************************** ************************************************** ***************
Roger Wolter[MSFT] wrote:[vbcol=seagreen]
>Does this help?
>http://support.microsoft.com/kb/317375/
>If this is urgent you should open a support case.
>[quoted text clipped - 14 lines]
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums.aspx/sql-server/200701/1
|||Hi
> Is there any way to verify at the time of the crisis, if checkpoint is
> on/off,
> working/not
> working?
1)
You can monitor the number of pages flushed by a checkpoint
using PerfMon - SQLServer:Buffer Manager object, Checkpoint
pages/sec counter
2)
You can start SQL Server with the
traceflag 3502. With this trace falg on, whenever a checkpoint occurs, it
will be recorded in the SQL Server error log, along with the time of the
checkpoint.
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:6c62ef5fc5f05@.uwe...
> While that is a good link, and I have it bookmarked, my initial question
> that
> started this thread is still not being addressed:
> ************************************************** ************************************************** ***************
> One thing I would like information on is the checkpoint process,
> suspecting
> that the automatic checkpoint is not occurring in TempDB, and thus, all of
> a
> sudden we have rapid growth.
> Is there any way to verify at the time of the crisis, if checkpoint is
> on/off,
> working/not
> working?
> ************************************************** ************************************************** ***************
> Roger Wolter[MSFT] wrote:
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums.aspx/sql-server/200701/1
>

checkdb filling up tempdb

Hello all,
I have a 10 gig SQL 2000 sp3 database that is having the following problem.
The tempdb which is on the c drive is expanding past two gigs when I run my
checkdb maintenance job. This is filling the c drive and bringing down my
app. I am going to move the tempdb to another drive that has more room but
my question is why would an integrity check fill up the tempdb? I assume
this is the problem since the time stamps for the job and problem are
identical.
TIA
jjThis is By Design. Any of the DBCC checks require space in tempdb for
processing check information - this is documented in Books Online. The
amount of space is proportional to the size of the database being checked,
and the amount of active transaction log for that database. You can use the
WITH ESTIMATEONLY option to find out the minimum amount of space required in
tempdb, not counting that dependant on the transaction log size.
From the numbers you've given, it sounds like you either have a large
active log or one very large table in the database.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"jj" <jeff_detoro@.urmc.rochester.edu> wrote in message
news:eFjJS2V1DHA.2700@.TK2MSFTNGP11.phx.gbl...
> Hello all,
> I have a 10 gig SQL 2000 sp3 database that is having the following
problem.
> The tempdb which is on the c drive is expanding past two gigs when I run
my
> checkdb maintenance job. This is filling the c drive and bringing down my
> app. I am going to move the tempdb to another drive that has more room but
> my question is why would an integrity check fill up the tempdb? I assume
> this is the problem since the time stamps for the job and problem are
> identical.
> TIA
> jj
>

CHECKDB causes tempdb to grow

We run a DBCC CHECKDB statement against each of our
databases once a week (during off-hours). It runs
successfully, but each morning after it runs I end up
having to shrink tempdb's data and log files.
I know that CHECKDB uses alot of tempdb, but why doesn't
it shrink back down on its own when CHECKDB is finished?
Thank you!
Susan Jones
DBCC checkdb ususally doesn't use a lot of space like DBCC DBREINDEX. But if
tempdb does not shrink automatically, check open transactions using DBCC
OPENTRAN.
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones
|||Unless autoshrink is turned on, no database will automatically shrink...
This uses lots of resources, and fragments the databases ( an issue for user
databases.)
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones
|||IN addition to the other comments why would you want to shrink the files
when it obviously needs to be that large to operate properly. By shrinking
the files you incur overhead in both the grow and shrink phases which is
unnecessary if you just leave it alone.
Andrew J. Kelly SQL MVP
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones

CHECKDB causes tempdb to grow

We run a DBCC CHECKDB statement against each of our
databases once a week (during off-hours). It runs
successfully, but each morning after it runs I end up
having to shrink tempdb's data and log files.
I know that CHECKDB uses alot of tempdb, but why doesn't
it shrink back down on its own when CHECKDB is finished?
Thank you!
Susan JonesDBCC checkdb ususally doesn't use a lot of space like DBCC DBREINDEX. But if
tempdb does not shrink automatically, check open transactions using DBCC
OPENTRAN.
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones|||Unless autoshrink is turned on, no database will automatically shrink...
This uses lots of resources, and fragments the databases ( an issue for user
databases.)
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones|||IN addition to the other comments why would you want to shrink the files
when it obviously needs to be that large to operate properly. By shrinking
the files you incur overhead in both the grow and shrink phases which is
unnecessary if you just leave it alone.
--
Andrew J. Kelly SQL MVP
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones

CHECKDB causes tempdb to grow

We run a DBCC CHECKDB statement against each of our
databases once a week (during off-hours). It runs
successfully, but each morning after it runs I end up
having to shrink tempdb's data and log files.
I know that CHECKDB uses alot of tempdb, but why doesn't
it shrink back down on its own when CHECKDB is finished?
Thank you!
Susan JonesDBCC checkdb ususally doesn't use a lot of space like DBCC DBREINDEX. But if
tempdb does not shrink automatically, check open transactions using DBCC
OPENTRAN.
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones|||Unless autoshrink is turned on, no database will automatically shrink...
This uses lots of resources, and fragments the databases ( an issue for user
databases.)
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones|||IN addition to the other comments why would you want to shrink the files
when it obviously needs to be that large to operate properly. By shrinking
the files you incur overhead in both the grow and shrink phases which is
unnecessary if you just leave it alone.
Andrew J. Kelly SQL MVP
"Susan" <sjones@.sartox.com> wrote in message
news:7dea01c48493$ad643120$a401280a@.phx.gbl...
> We run a DBCC CHECKDB statement against each of our
> databases once a week (during off-hours). It runs
> successfully, but each morning after it runs I end up
> having to shrink tempdb's data and log files.
> I know that CHECKDB uses alot of tempdb, but why doesn't
> it shrink back down on its own when CHECKDB is finished?
> Thank you!
> Susan Jones

Check Temp table size?

I have a tempdb which fills up the disk frequently. I want to determine the
size of each object in the tempdb.
I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename" does
not exist error. I got the temp table names from INFORMATION_SCHEMA.TABLES.
Since the temp tables only valid for their own session, how can I check its
size of temp tables through Query Analyzer?
Another question is how to analyze the log file space usage? The log file
for my TempDB grows dramatically fast too. I need understand the reason.
Thanks a lot,
FL
EXEC tempdb..spaceused '#temptablename'
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> I have a tempdb which fills up the disk frequently. I want to determine
the
> size of each object in the tempdb.
> I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename" does
> not exist error. I got the temp table names from
INFORMATION_SCHEMA.TABLES.
> Since the temp tables only valid for their own session, how can I check
its
> size of temp tables through Query Analyzer?
> Another question is how to analyze the log file space usage? The log file
> for my TempDB grows dramatically fast too. I need understand the reason.
> Thanks a lot,
> FL
>
>
>
>
|||Thanks.
It did not solve my problem. Maybe my question was not clear. The
#temptablename was created in the stored procedure. Since it is a local temp
table, I can not access it from the Query Analyzer. What is the workaround?
I know if it is a global temp table I can access it.
FL
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23sIQO391EHA.1396@.tk2msftngp13.phx.gbl...[vbcol=seagreen]
> EXEC tempdb..spaceused '#temptablename'
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "FLX" <nospam@.hotmail.com> wrote in message
> news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> the
does[vbcol=seagreen]
> INFORMATION_SCHEMA.TABLES.
> its
file
>
|||You want to check the size of a temp table created in a stored procedure,
from query analyzer OUTSIDE the scope of the stored procedure?
I don't think this is possible, unless you manually inspect
tempdb..sysobjects and guess which table is from the specific stored
procedure scope you are interested in. What do you expect will happen when
the stored procedure is being executed by 12 different people
simultaneously? Since the temp table only lives for the scope of the stored
procedure, why do you care aout its size OUTSIDE of that scope?
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:u46sZM$1EHA.4004@.tk2msftngp13.phx.gbl...
> Thanks.
> It did not solve my problem. Maybe my question was not clear. The
> #temptablename was created in the stored procedure. Since it is a local
temp
> table, I can not access it from the Query Analyzer. What is the
workaround?[vbcol=seagreen]
> I know if it is a global temp table I can access it.
> FL
>
>
>
> "Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
> news:%23sIQO391EHA.1396@.tk2msftngp13.phx.gbl...
determine[vbcol=seagreen]
> does
check[vbcol=seagreen]
> file
reason.
>
|||> I don't think this is possible, unless you manually inspect
> tempdb..sysobjects and guess which table is from the specific stored
> procedure scope you are interested in.
This is unfortunate.

>What do you expect will happen when
> the stored procedure is being executed by 12 different people
> simultaneously?
I expect 12 temp tables with unique Table Names stored in the database.
Let's say there is a temp table "#tempTable" is created in the stored
procedure. Two people simultaneously execute the stored procedure. When I
ran the following query,
use tempdb
go
select *
FROM INFORMATION_SCHEMA.TABLES
In the tablename column, I saw:
#tempTable________________________________________ __________________________
_________________________________________000000058 617
#tempTable________________________________________ __________________________
_________________________________________000000058 628
Please notice the appendix are different.

>Since the temp table only lives for the scope of the stored
> procedure, why do you care aout its size OUTSIDE of that scope?
My tempdb is too large and I want to figure out the cause. One obvious
reason is that we used too many temp tables created in the stored
procedures. I know theoritically the temp table will be automatically
dropped when the stored procedure exits. However, I don't why my tempdb size
keeps growing and can not be shrinked.
Thanks a lot.
|||>
#tempTable________________________________________ __________________________
> _________________________________________000000058 617
>
#tempTable________________________________________ __________________________
> _________________________________________000000058 628
> Please notice the appendix are different.
Yes, those suffixes are generated by SQL Server internally to track #temp
tables from different sessions. Again, you would have to guess which one is
which.

> However, I don't why my tempdb size
> keeps growing and can not be shrinked.
http://www.aspfaq.com/2446
http://www.aspfaq.com/2471
|||> > However, I don't why my tempdb size
> http://www.aspfaq.com/2446
> http://www.aspfaq.com/2471
>
Very helpful link. However, when I ran the following query:
USE tempdb
GO
EXEC sp_spaceused @.updateusage = 'TRUE'
I got the result like:
database_name
database_size unallocated space
--- --
-- --
tempdb
4425.94 MB 4140.27 MB
reserved data index_size unused
-- -- -- --
624 KB 216 KB 320 KB 88 KB
My questions are:
1. What does the unallocated space mean? Free space? Unused space? Why I can
not reclaim the such space by shrinking db?
2.The data and index add up together are only 216 + 320 = 536 KB. It is less
than 1 MB. Why my tempdb is so large (> 4GB)? Any hint?
Thanks
|||The possible reasons for tempdb growth are listed in that article. Why is
your tempdb so large? I have no idea. Probably one or more of those
reasons. Why can't you shrink it? I have no idea. What else is going on
in the system? What command are you using to shrink the database? Does it
complete successfully, or do you get an error? If you get an error, what is
it?
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:uDHsq7H2EHA.936@.TK2MSFTNGP12.phx.gbl...
> Very helpful link. However, when I ran the following query:
> USE tempdb
> GO
> EXEC sp_spaceused @.updateusage = 'TRUE'
> I got the result like:
> database_name
> database_size unallocated space
> --- --
--
> -- --
> tempdb
> 4425.94 MB 4140.27 MB
>
> reserved data index_size unused
> -- -- -- --
> 624 KB 216 KB 320 KB 88 KB
>
> My questions are:
> 1. What does the unallocated space mean? Free space? Unused space? Why I
can
> not reclaim the such space by shrinking db?
> 2.The data and index add up together are only 216 + 320 = 536 KB. It is
less
> than 1 MB. Why my tempdb is so large (> 4GB)? Any hint?
> Thanks
>
>
>

Check Temp table size?

I have a tempdb which fills up the disk frequently. I want to determine the
size of each object in the tempdb.
I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename" does
not exist error. I got the temp table names from INFORMATION_SCHEMA.TABLES.
Since the temp tables only valid for their own session, how can I check its
size of temp tables through Query Analyzer?
Another question is how to analyze the log file space usage? The log file
for my TempDB grows dramatically fast too. I need understand the reason.
Thanks a lot,
FLEXEC tempdb..spaceused '#temptablename'
--
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> I have a tempdb which fills up the disk frequently. I want to determine
the
> size of each object in the tempdb.
> I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename" does
> not exist error. I got the temp table names from
INFORMATION_SCHEMA.TABLES.
> Since the temp tables only valid for their own session, how can I check
its
> size of temp tables through Query Analyzer?
> Another question is how to analyze the log file space usage? The log file
> for my TempDB grows dramatically fast too. I need understand the reason.
> Thanks a lot,
> FL
>
>
>
>|||Thanks.
It did not solve my problem. Maybe my question was not clear. The
#temptablename was created in the stored procedure. Since it is a local temp
table, I can not access it from the Query Analyzer. What is the workaround?
I know if it is a global temp table I can access it.
FL
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23sIQO391EHA.1396@.tk2msftngp13.phx.gbl...
> EXEC tempdb..spaceused '#temptablename'
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "FLX" <nospam@.hotmail.com> wrote in message
> news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> > I have a tempdb which fills up the disk frequently. I want to determine
> the
> > size of each object in the tempdb.
> >
> > I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename"
does
> > not exist error. I got the temp table names from
> INFORMATION_SCHEMA.TABLES.
> > Since the temp tables only valid for their own session, how can I check
> its
> > size of temp tables through Query Analyzer?
> >
> > Another question is how to analyze the log file space usage? The log
file
> > for my TempDB grows dramatically fast too. I need understand the reason.
> >
> > Thanks a lot,
> > FL
> >
> >
> >
> >
> >
> >
> >
>|||You want to check the size of a temp table created in a stored procedure,
from query analyzer OUTSIDE the scope of the stored procedure?
I don't think this is possible, unless you manually inspect
tempdb..sysobjects and guess which table is from the specific stored
procedure scope you are interested in. What do you expect will happen when
the stored procedure is being executed by 12 different people
simultaneously? Since the temp table only lives for the scope of the stored
procedure, why do you care aout its size OUTSIDE of that scope?
--
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:u46sZM$1EHA.4004@.tk2msftngp13.phx.gbl...
> Thanks.
> It did not solve my problem. Maybe my question was not clear. The
> #temptablename was created in the stored procedure. Since it is a local
temp
> table, I can not access it from the Query Analyzer. What is the
workaround?
> I know if it is a global temp table I can access it.
> FL
>
>
>
> "Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
> news:%23sIQO391EHA.1396@.tk2msftngp13.phx.gbl...
> > EXEC tempdb..spaceused '#temptablename'
> >
> > --
> > http://www.aspfaq.com/
> > (Reverse address to reply.)
> >
> >
> >
> >
> > "FLX" <nospam@.hotmail.com> wrote in message
> > news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> > > I have a tempdb which fills up the disk frequently. I want to
determine
> > the
> > > size of each object in the tempdb.
> > >
> > > I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename"
> does
> > > not exist error. I got the temp table names from
> > INFORMATION_SCHEMA.TABLES.
> > > Since the temp tables only valid for their own session, how can I
check
> > its
> > > size of temp tables through Query Analyzer?
> > >
> > > Another question is how to analyze the log file space usage? The log
> file
> > > for my TempDB grows dramatically fast too. I need understand the
reason.
> > >
> > > Thanks a lot,
> > > FL
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>|||> I don't think this is possible, unless you manually inspect
> tempdb..sysobjects and guess which table is from the specific stored
> procedure scope you are interested in.
This is unfortunate.
>What do you expect will happen when
> the stored procedure is being executed by 12 different people
> simultaneously?
I expect 12 temp tables with unique Table Names stored in the database.
Let's say there is a temp table "#tempTable" is created in the stored
procedure. Two people simultaneously execute the stored procedure. When I
ran the following query,
use tempdb
go
select *
FROM INFORMATION_SCHEMA.TABLES
In the tablename column, I saw:
#tempTable__________________________________________________________________
_________________________________________000000058617
#tempTable__________________________________________________________________
_________________________________________000000058628
Please notice the appendix are different.
>Since the temp table only lives for the scope of the stored
> procedure, why do you care aout its size OUTSIDE of that scope?
My tempdb is too large and I want to figure out the cause. One obvious
reason is that we used too many temp tables created in the stored
procedures. I know theoritically the temp table will be automatically
dropped when the stored procedure exits. However, I don't why my tempdb size
keeps growing and can not be shrinked.
Thanks a lot.|||>
#tempTable__________________________________________________________________
> _________________________________________000000058617
>
#tempTable__________________________________________________________________
> _________________________________________000000058628
> Please notice the appendix are different.
Yes, those suffixes are generated by SQL Server internally to track #temp
tables from different sessions. Again, you would have to guess which one is
which.
> However, I don't why my tempdb size
> keeps growing and can not be shrinked.
http://www.aspfaq.com/2446
http://www.aspfaq.com/2471|||> > However, I don't why my tempdb size
> > keeps growing and can not be shrinked.
> http://www.aspfaq.com/2446
> http://www.aspfaq.com/2471
>
Very helpful link. However, when I ran the following query:
USE tempdb
GO
EXEC sp_spaceused @.updateusage = 'TRUE'
I got the result like:
database_name
database_size unallocated space
--- --
-- --
tempdb
4425.94 MB 4140.27 MB
reserved data index_size unused
-- -- -- --
624 KB 216 KB 320 KB 88 KB
My questions are:
1. What does the unallocated space mean? Free space? Unused space? Why I can
not reclaim the such space by shrinking db?
2.The data and index add up together are only 216 + 320 = 536 KB. It is less
than 1 MB. Why my tempdb is so large (> 4GB)? Any hint?
Thanks|||The possible reasons for tempdb growth are listed in that article. Why is
your tempdb so large? I have no idea. Probably one or more of those
reasons. Why can't you shrink it? I have no idea. What else is going on
in the system? What command are you using to shrink the database? Does it
complete successfully, or do you get an error? If you get an error, what is
it?
--
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:uDHsq7H2EHA.936@.TK2MSFTNGP12.phx.gbl...
> > > However, I don't why my tempdb size
> > > keeps growing and can not be shrinked.
> >
> > http://www.aspfaq.com/2446
> > http://www.aspfaq.com/2471
> >
> Very helpful link. However, when I ran the following query:
> USE tempdb
> GO
> EXEC sp_spaceused @.updateusage = 'TRUE'
> I got the result like:
> database_name
> database_size unallocated space
> --- --
--
> -- --
> tempdb
> 4425.94 MB 4140.27 MB
>
> reserved data index_size unused
> -- -- -- --
> 624 KB 216 KB 320 KB 88 KB
>
> My questions are:
> 1. What does the unallocated space mean? Free space? Unused space? Why I
can
> not reclaim the such space by shrinking db?
> 2.The data and index add up together are only 216 + 320 = 536 KB. It is
less
> than 1 MB. Why my tempdb is so large (> 4GB)? Any hint?
> Thanks
>
>
>

Check Temp table size?

I have a tempdb which fills up the disk frequently. I want to determine the
size of each object in the tempdb.
I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename" does
not exist error. I got the temp table names from INFORMATION_SCHEMA.TABLES.
Since the temp tables only valid for their own session, how can I check its
size of temp tables through Query Analyzer?
Another question is how to analyze the log file space usage? The log file
for my TempDB grows dramatically fast too. I need understand the reason.
Thanks a lot,
FLEXEC tempdb..spaceused '#temptablename'
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> I have a tempdb which fills up the disk frequently. I want to determine
the
> size of each object in the tempdb.
> I used EXEC sp_spaceused '#temptablename'. I got the "#temptablename" does
> not exist error. I got the temp table names from
INFORMATION_SCHEMA.TABLES.
> Since the temp tables only valid for their own session, how can I check
its
> size of temp tables through Query Analyzer?
> Another question is how to analyze the log file space usage? The log file
> for my TempDB grows dramatically fast too. I need understand the reason.
> Thanks a lot,
> FL
>
>
>
>|||Thanks.
It did not solve my problem. Maybe my question was not clear. The
#temptablename was created in the stored procedure. Since it is a local temp
table, I can not access it from the Query Analyzer. What is the workaround?
I know if it is a global temp table I can access it.
FL
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:%23sIQO391EHA.1396@.tk2msftngp13.phx.gbl...
> EXEC tempdb..spaceused '#temptablename'
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "FLX" <nospam@.hotmail.com> wrote in message
> news:e$uxjy91EHA.3368@.TK2MSFTNGP10.phx.gbl...
> the
does[vbcol=seagreen]
> INFORMATION_SCHEMA.TABLES.
> its
file[vbcol=seagreen]
>|||You want to check the size of a temp table created in a stored procedure,
from query analyzer OUTSIDE the scope of the stored procedure?
I don't think this is possible, unless you manually inspect
tempdb..sysobjects and guess which table is from the specific stored
procedure scope you are interested in. What do you expect will happen when
the stored procedure is being executed by 12 different people
simultaneously? Since the temp table only lives for the scope of the stored
procedure, why do you care aout its size OUTSIDE of that scope?
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:u46sZM$1EHA.4004@.tk2msftngp13.phx.gbl...
> Thanks.
> It did not solve my problem. Maybe my question was not clear. The
> #temptablename was created in the stored procedure. Since it is a local
temp
> table, I can not access it from the Query Analyzer. What is the
workaround?
> I know if it is a global temp table I can access it.
> FL
>
>
>
> "Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
> news:%23sIQO391EHA.1396@.tk2msftngp13.phx.gbl...
determine[vbcol=seagreen]
> does
check[vbcol=seagreen]
> file
reason.[vbcol=seagreen]
>|||> I don't think this is possible, unless you manually inspect
> tempdb..sysobjects and guess which table is from the specific stored
> procedure scope you are interested in.
This is unfortunate.

>What do you expect will happen when
> the stored procedure is being executed by 12 different people
> simultaneously?
I expect 12 temp tables with unique Table Names stored in the database.
Let's say there is a temp table "#tempTable" is created in the stored
procedure. Two people simultaneously execute the stored procedure. When I
ran the following query,
use tempdb
go
select *
FROM INFORMATION_SCHEMA.TABLES
In the tablename column, I saw:
#tempTable______________________________
____________________________________
________________________________________
_000000058617
#tempTable______________________________
____________________________________
________________________________________
_000000058628
Please notice the appendix are different.

>Since the temp table only lives for the scope of the stored
> procedure, why do you care aout its size OUTSIDE of that scope?
My tempdb is too large and I want to figure out the cause. One obvious
reason is that we used too many temp tables created in the stored
procedures. I know theoritically the temp table will be automatically
dropped when the stored procedure exits. However, I don't why my tempdb size
keeps growing and can not be shrinked.
Thanks a lot.|||>
#tempTable______________________________
____________________________________[vbc
ol=seagreen]
> ________________________________________
_000000058617
>[/vbcol]
#tempTable______________________________
____________________________________[vbc
ol=seagreen]
> ________________________________________
_000000058628
> Please notice the appendix are different.[/vbcol]
Yes, those suffixes are generated by SQL Server internally to track #temp
tables from different sessions. Again, you would have to guess which one is
which.

> However, I don't why my tempdb size
> keeps growing and can not be shrinked.
http://www.aspfaq.com/2446
http://www.aspfaq.com/2471|||> > However, I don't why my tempdb size
> http://www.aspfaq.com/2446
> http://www.aspfaq.com/2471
>
Very helpful link. However, when I ran the following query:
USE tempdb
GO
EXEC sp_spaceused @.updateusage = 'TRUE'
I got the result like:
database_name
database_size unallocated space
--- --
-- --
tempdb
4425.94 MB 4140.27 MB
reserved data index_size unused
-- -- -- --
624 KB 216 KB 320 KB 88 KB
My questions are:
1. What does the unallocated space mean? Free space? Unused space? Why I can
not reclaim the such space by shrinking db?
2.The data and index add up together are only 216 + 320 = 536 KB. It is less
than 1 MB. Why my tempdb is so large (> 4GB)? Any hint?
Thanks|||The possible reasons for tempdb growth are listed in that article. Why is
your tempdb so large? I have no idea. Probably one or more of those
reasons. Why can't you shrink it? I have no idea. What else is going on
in the system? What command are you using to shrink the database? Does it
complete successfully, or do you get an error? If you get an error, what is
it?
http://www.aspfaq.com/
(Reverse address to reply.)
"FLX" <nospam@.hotmail.com> wrote in message
news:uDHsq7H2EHA.936@.TK2MSFTNGP12.phx.gbl...
> Very helpful link. However, when I ran the following query:
> USE tempdb
> GO
> EXEC sp_spaceused @.updateusage = 'TRUE'
> I got the result like:
> database_name
> database_size unallocated space
> --- --
--
> -- --
> tempdb
> 4425.94 MB 4140.27 MB
>
> reserved data index_size unused
> -- -- -- --
> 624 KB 216 KB 320 KB 88 KB
>
> My questions are:
> 1. What does the unallocated space mean? Free space? Unused space? Why I
can
> not reclaim the such space by shrinking db?
> 2.The data and index add up together are only 216 + 320 = 536 KB. It is
less
> than 1 MB. Why my tempdb is so large (> 4GB)? Any hint?
> Thanks
>
>
>