April 9, 2010 at 4:13 am
Great article and in my experience with table variables its usually devs not implementing them properly in complex queries 😉 I shall ensure part of this article goes into our best practices just to hammer the point home 🙂
April 9, 2010 at 4:28 am
Hi Wayne ,
great article and here some problems i encountered while working with
#temp for further articles with the same focus.
1. Creating a #temptable within a SP as select .. into #temptable will lock the tempdb for the time until the #temptable is created.(may take a while for large data amounts)
The same statement as TSql script will not lock tempdb.
2. Creating a #temptable as select expression,.. into #temptable will generate a not null constraint on the expression column.
regards
Matthias Kroll
April 9, 2010 at 4:31 am
Gianluca Sartori (4/9/2010)
Thanks for clarifying Wayne. So, it works the same as permanent tables: I was fearing that a different behaviour could apply.I wrote that because I use indexes on temp tables in some of my procedures ad I've never seen problems in concurrency, but that sentence in your article made me think.
Yes, it is misleading. I added this to the first post in this thread as an "Article errata". Thanks for pointing it out.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 9, 2010 at 4:33 am
Knight (4/9/2010)
Great article
Thanks
I shall ensure part of this article goes into our best practices just to hammer the point home 🙂
:blush: Thanks again!
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 9, 2010 at 7:22 am
Are there any concerns when using a local temp table (#sometable) and connection pooling? Is it possible for a user to hop on a previously used connection and session and view data unrelated to that user?
Eddie
April 9, 2010 at 7:28 am
matt32 (4/9/2010)
Hi Wayne ,great article and here some problems i encountered while working with
#temp for further articles with the same focus.
1. Creating a #temptable within a SP as select .. into #temptable will lock the tempdb for the time until the #temptable is created.(may take a while for large data amounts)
The same statement as TSql script will not lock tempdb.
2. Creating a #temptable as select expression,.. into #temptable will generate a not null constraint on the expression column.
regards
Matthias Kroll
Regarding #1, please see Paul Randall's blog about how he changed this in SQL 2005. Specifically see item #3.
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 9, 2010 at 7:47 am
WayneS (4/9/2010)
matt32 (4/9/2010)
1. Creating a #temptable within a SP as select .. into #temptable will lock the tempdb for the time until the #temptable is created.(may take a while for large data amounts)Regarding #1, please see Paul Randall's blog about how he changed this in SQL 2005. Specifically see item #3.
Actually, Matthias was referring to a SQL Server 6.5 behaviour which was fixed in SQL Server 7 :w00t:
See http://www.simple-talk.com/community/blogs/tony_davis/archive/2009/10/28/75834.aspx for the gory details.
BTW Wayne, did this article change much between publications? It seems more comprehensive than previously - or is my memory playing tricks again?
Paul
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 9, 2010 at 8:12 am
Paul White NZ (4/9/2010)
BTW Wayne, did this article change much between publications? It seems more comprehensive than previously - or is my memory playing tricks again?Paul
No changes at all. They say that your memory is the first thing to .... hey, what was I talking about again?
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 9, 2010 at 8:15 am
WayneS (4/9/2010)
No changes at all. They say that your memory is the first thing to .... hey, what was I talking about again?
Oh :blush: 🙁 :crying:
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 9, 2010 at 8:25 am
Thx Wayne for the link to Paul Randall.
I had this issue some month ago with a customers 2005 db.
heavy data load using a SP with select .. into #temp. During this time no one could start any App using tempdb (eg activity monitor within SSMS also Toad for SQLServer cant get a connection).
the solution was :
1. create #temp before insert
2. create #temp not within a sp
and what wonder no more locks on tempdb ... so i think there is this days a issue with that
select .. into #temp and it's not really solved with 2005. (all SP's installed)
If you have the time and large data tables .. test it by your own.
regards Matthias
April 9, 2010 at 8:27 am
Great article but I had one question. The reference about when temp tables can cause recompilations takes you to an article relevant to SQL Server 2000 and when stored procedures are recompiled. I thought that, as of SQL Server 2005, only individual statements within the proc were recompiled and not the entire stored procedure. Wouldn't that, theoretically, reduce the recompilation overhead? Also, what if the temp table is used in a join. Would that force a recompile of the statement performing the JOIN?
I apologize, I'd test this myself but I'm swamped so I'm hoping you (or someone else here) might have an answer off the top of your head.
"Beliefs" get in the way of learning.
April 9, 2010 at 8:28 am
matt32 (4/9/2010)
2. Creating a #temptable as select expression,.. into #temptable will generate a not null constraint on the expression column.
Has anyone ever heard of this before?
I tried to duplicate it with this code, but I don't get an error.
USE AdventureWorks
GO
if OBJECT_ID('tempdb..#Test2') IS NOT NULL DROP TABLE #Test2
select top 50 *, TestCalc = PerAssemblyQty*50
into #Test2
from Production.BillOfMaterials
insert into #test2
select top 5 ProductAssemblyID, ComponentID, StartDate, EndDate, UnitMeasureCode,
BOMLevel, PerAssemblyQty, ModifiedDate, NULL
from Production.BillOfMaterials
select *
from #test2
Matthias, do you have some code that demonstrates this?
Edit: typo, added database
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
April 9, 2010 at 8:40 am
Hi Wayne
select top 1
1 as nr,
name as colname into #tmptable
from sys.all_columns
select * from #tmptable
insert into
#tmptable
select null, 'what'
you will get a not null constraint violation ...
April 9, 2010 at 8:52 am
matt32 (4/9/2010)
so i think there is this days a issue with thatselect .. into #temp and it's not really solved with 2005.
It was the phrasing of your original statement that made me think you were referring to the SELECT INTO tempdb modern myth. I see now that English is not your first language, so I understand.
You will find lots of other details on Paul's blog about tempdb allocation contention. Creating several equally-sized tempdb files seems to cure all problems. Anyway, read about it 🙂
Paul White
SQLPerformance.com
SQLkiwi blog
@SQL_Kiwi
April 9, 2010 at 8:55 am
Matthias, I've never seen this before. Very interesting.
If you're interested, I just found a way to work around this.
select top 1
CONVERT(int, 1) as nr,
name as colname into #tmptable
from sys.all_columns
Wayne
Microsoft Certified Master: SQL Server 2008
Author - SQL Server T-SQL Recipes
Viewing 15 posts - 91 through 105 (of 163 total)
You must be logged in to reply to this topic. Login to reply