May 17, 2010 at 5:12 am
Hi Experts,
i have an issue wen i create a temp table it take
1 sec to create a temp table in temp db also wen i check it from the perfmon
the active temp tables shows more the 16 lacs of temp table
the table name in the tempdb shows as this #table_________________
May 17, 2010 at 10:03 am
temp tables are also created by other processes that perform sorts as part of their operation
May 18, 2010 at 12:38 am
yes but wat i m staying here is
there is a procedure in which there are around 30 more procedure which are getting called
Eg create procedure abcdef
(
begin
exec ab ---doing some operations creatin 5 temp table doing some updation,insertion etc
exec abc ---doing some operations creatin 5 temp table doing some updation,insertion etc
exec abe ---doing some operations creatin 5 temp table doing some updation,insertion etc
exec abd ---doing some operations creatin 5 temp table doing some updation,insertion etc
end
)
what i know that after the procedure is exec the temp tables gets destroyed from the tempdb.
but here in this senario the temp tables are not getting getting destroyed from tempdb.
they are getting dropped wen the abcdef procedure gets executed completly.
Also wen we r running this procedure from different session we are getting blocking on tempdb
while creating a temp tables within the procedures
May 18, 2010 at 3:32 am
looks like you are using global temporary tables which may cause blocking:
http://databases.aspfaq.com/database/should-i-use-a-temp-table-or-a-table-variable.html
May 18, 2010 at 5:48 am
no not using global temp tables ...
May 20, 2010 at 12:35 am
waiting for the reply...Jeff can u help in this process
May 20, 2010 at 5:27 am
Temp tables last for the length of the process that created them. That wrapper proc is the process, so as long as it's running, you'll keep those temp tables. You can explicitly drop temp tables too.
What are the procs doing? It doesn't sound like you're using the temp tables in an efficient manner.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 20, 2010 at 5:49 am
Your process was involved in unresolved deadlock, therefore, the tables were not dropped and blocked the creating table process in tempdb.
This might be the bug in sqlserver 2005.
create proc proc1
as
begin
create table #abcd ( i int)
drop table #abcd
end
go
BEGIN TRAN
go
DECLARE @I INT
SET @I = 1
WHILE @I < 5000
BEGIN
EXEC proc1
SET @I = @I + 1
END
go
Select count(*) from tempdb.sys.tables
go
If you notice the last output, the tempdb now has 5000 temp tables. From a programmer perspective, as soon as a stored procedure finishes, the temp table scope is over and it is destroyed. In SQL2005 we do a deferred drop, but that doesn’t kick in until transaction is over.
Because of the begin tran command, the temp tables are not dropped and hence tempdb locks not released. However, these tables are no longer accessible even to the SPID which created it, but are still present in tempdb.
Saby DBA
May 20, 2010 at 6:00 am
yes saby i m gettin blocking in the tempdb.
Grant there are procedure with begin and tran
E.g
proc ssa
(
Begin tran
exec procedure1
-----create some temp table and do some updation,insertion etc on temp table and physical table as there are more than 5 tables in each proc ...
exec procedure2 -----create some temp table and do some updation,insertion etc on temp table and physical table as there are more than 5 tables in each proc ...
exec procedure3-----create some temp table and do some updation,insertion etc on temp table and physical table as there are more than 5 tables in each proc ...
commit
run with diffrent sessions got the blocking while creating a temp table
and one more thing is that the table creation takes 2 secs to create which is really more time.
it destroy the table after the 1 procedure get fully exec till commit.
May 20, 2010 at 6:26 am
Saby, I'm confused. Where did you get deadlocks in this situation. We're talking about blocking. That's not the same thing as deadlocks.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 20, 2010 at 6:27 am
samsql (5/20/2010)
yes saby i m gettin blocking in the tempdb.Grant there are procedure with begin and tran
E.g
proc ssa
(
Begin tran
exec procedure1
-----create some temp table and do some updation,insertion etc on temp table and physical table as there are more than 5 tables in each proc ...
exec procedure2 -----create some temp table and do some updation,insertion etc on temp table and physical table as there are more than 5 tables in each proc ...
exec procedure3-----create some temp table and do some updation,insertion etc on temp table and physical table as there are more than 5 tables in each proc ...
commit
run with diffrent sessions got the blocking while creating a temp table
and one more thing is that the table creation takes 2 secs to create which is really more time.
it destroy the table after the 1 procedure get fully exec till commit.
Yes, that procedure that is calling all the other procedures will hold those temp tables in place until it completes. It doesn't matter that those procedures have transactions of their own, the wrapper proc acts as the main transaction and the temp tables will be held until it commits or rolls back.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
May 22, 2010 at 8:22 pm
in SQL Server 2005+, they no longer drop all temp tables from the tempDB. A small cache of 16 temp tables are saved in a special area of cache. This was done to prevent the overhead of constantly allocating new tables for systems that create a lot of temp tables. If an unused table exists in cache, it will use one of them, if not, it creates a new one.
This is why you will see temp tables hang around. You can read more about that on Paul Randal's blog: Misconceptions around TF-1118
If you are experiencing tempDB contention, then you likely do not have your tempDB configured per best practices. Your data files should all be the same size, and you should have multiple data file, somewhere from 1/4 to 1 data file per logical processor. I would suggest starting with 1/4 to 1/2 data file per CPU and increase it if contention persists. You should also separate your tempDB files to a dedicated drive separate from the other databases' files.
When you are experiencing heavy blocking in the tempDB, you can use the script on my blog for determining if the contention is on allocation pages (GAM, SGAM, PFS) or data pages: Breaking Down TempDB Contention
May 31, 2010 at 3:42 am
Samsql,Grant i had a discussion with MS Team this is fixed in SQL 11 version but not sure about 2008 R2..
They are making an hotfix for it for sqlserver 2005.will let u know once it is launches.
June 8, 2010 at 3:33 am
Hi sam below is the KB for ur issue
KB Article Number(s): 2133566
June 6, 2011 at 1:01 am
saby (6/8/2010)
Hi sam below is the KB for ur issueKB Article Number(s): 2133566
'
Hey , can you please post the actual link for the hotfix?
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply