I have a doubt Why Should we use temporary table is there any special thing in temporary table and where should we use the temporary tables. Can you please explain me or any reference thank you.
When writing T-SQL code, you often need a table in which to store data temporarily when it comes time to execute that code. You have four table options: normal tables, local temporary tables, global temporary tables and table variables. Each of the four table options has its own purpose and use, and each has its benefits and issues:
* Normal tables are exactly that, physical tables defined in your database.
* Local temporary tables are temporary tables that are available only to the session that created them. These tables are automatically destroyed at the termination of the procedure or session that created them.
* Global temporary tables are temporary tables that are available to all sessions and all users. They are dropped automatically when the last session using the temporary table has completed. Both local temporary tables and global temporary tables are physical tables created within the tempdb database.
* Table variables are stored within memory but are laid out like a table. Table variables are partially stored on disk and partially stored in memory. It's a common misconception that table variables are stored only in memory. Because they are partially stored in memory, the access time for a table variable can be faster than the time it takes to access a temporary table.
Which one to use:
* If you have less than 100 rows generally use a table variable. Otherwise use a temporary table. This is because SQL Server won't create statistics on table variables.
* If you need to create indexes on it then you must use a temporary table.
* When using temporary tables always create them and create any indexes and then use them. This will help reduce recompilations. The impact of this is reduced starting in SQL Server 2005 but it's still a good idea.
Please refer this page
http://www.sqlteam.com/article/temporary-tables
There are many uses for temporary tables. They can be very useful in handling data in complex queries. Your question is vague, and does not really have an answer, but I am linking to some temporary table documentation.
They have most of the same capabilities of table, including constraints and indexing. They can be global or limited to current scope. They can also be inefficient, so be cautious as always.
http://www.sqlservercentral.com/articles/T-SQL/temptablesinsqlserver/1279/
http://msdn.microsoft.com/en-us/library/aa258255%28SQL.80%29.aspx
Temporary tables can be created at runtime and can do the all kinds of operations that one normal table can do. But, based on the table types, the scope is limited. These tables are created inside tempdb database.
SQL Server provides two types of temp tables based on the behavior and scope of the table. These are:
•Local Temp Table
•Global Temp Table
Local Temp Table
Local temp tables are only available to the current connection for the user; and they are automatically deleted when the user disconnects from instances. Local temporary table name is stared with hash ("#") sign.
Global Temp Table
Global Temporary tables name starts with a double hash ("##"). Once this table has been created by a connection, like a permanent table it is then available to any user by any connection. It can only be deleted once all connections have been closed.
When to Use Temporary Tables?
•When we are doing large number of row manipulation in stored procedures.
•This is useful to replace the cursor. We can store the result set data into a temp table, then we can manipulate the data from there.
•When we are having a complex join operation.
Points to Remember Before Using Temporary Tables -
•Temporary table created on tempdb of SQL Server. This is a separate database. So, this is an additional overhead and can causes performance issues.
•Number of rows and columns need to be as minimum as needed.
•Tables need to be deleted when they are done with their work.
Alternative Approach: Table Variable-
Alternative of Temporary table is the Table variable which can do all kinds of operations that we can perform in Temp table. Below is the syntax for using Table variable.
When to Use Table Variable Over Temp Table -
Tablevariable is always useful for less data. If the result set returns a large number of records, we need to go for temp table.
Related
I'm working on updating a legacy stored procedure (which calls several other child stored procedures.) Within a transaction, it manipulates data in about a dozen or so tables and performs lots of calculations in the process, sometimes triggering lock escalation up to a table lock. This process could take 20 minutes or more to complete in some cases. Obviously, locking tables for that long is a big no no. So I'm working on a 2-stage plan to the reduce the blocking caused by this sproc in phase 1 and completely rewrite it to be more efficient and not take an inordinate amount of time in phase 2.
In order to reduce the blocking, wherever there is manipulation on the database tables, I plan to move that manipulation into a temporary table. By doing all of the work in temporary table and then updating the real tables with the final results at the very end of the process, I should be able to reduce the time spent blocking other users, significantly. (That's the "quick fix" for phase 1.)
Here's my issue: some of these temp table might have 100,000 rows or more in them while I use them for various calculations. Because of this I would like to generate indexes on the temp tables to keep performance up. And since these are temp tables that are created within a stored procedure, they need to have unique names to avoid errors if multiple users execute the sproc at the same time. I know that I can manually declare the temp tables using CREATE TABLE statements, and if I do that I can specify an index without a name and let SQL Server create the name for me. What I'm hoping to be able to do is use SELECT * INTO to generate the temp table and find another way to get SQL Server to auto-generate index names. I'm sure you're asking "Why?" My company has several changes in store for the system that I'm working with. If I can manage to use the SELECT INTO method, then, if a column gets added or resized or whatever, then there won't be an issue with the developers needing to know that they have to go back into these stored procedures and change their temp table definitions to match. Using SELECT INTO will automatically keep the temp tables matching the layout of the "real" tables.
So, does anyone know of a way to get SQL Server to auto-generate the name for an index on a temp table (aside from doing it as part of the CREATE TABLE syntax)?
Thank you!
And since these are temp tables that are created within a stored procedure, they need to have unique names to avoid errors if multiple users execute the sproc at the same time.
No they don't. Each session will have their own temp tables, and they will be automatically cleaned up.
And indexes don't have global name scope, so each temp table can have the same index names. eg
create procedure TempTest
as
begin
select * into #t from sys.objects
create index foo on #t(name)
waitfor delay '00:00:10'
select * from #t
end
And you can run
exec temptest
go 10
from multiple sessions.
What is best practice for handling the dropping of a temp table. I have read that you should explicitly handle the drop and also that sql server should handle the drop....what is the correct method? I was always under the impression that you should do your own clean up of the temp tables you create in a sproc, etc. But, then I found other bits that suggest otherwise.
Any insight would be greatly appreciated. I am just concerned I am not following best practice with the temp tables I create.
Thanks,
S
My view is, first see if you really need a temp table - or - can you make do with a Common Table Expression (CTE). Second, I would always drop my temp tables. Sometimes you need to have a temp table scoped to the connection (e.g. ##temp), so if you run the query a second time, and you have explicit code to create the temp table, you'll get an error that says the table already exists. Cleaning up after yourself is ALWAYS a good software practice.
EDIT: 03-Nov-2021
Another alternative is a TABLE variable, which will fall out of scope once the query completes:
DECLARE #MyTable AS TABLE (
MyID INT,
MyText NVARCHAR(256)
)
INSERT INTO
#MyTable
VALUES
(1, 'One'),
(2, 'Two'),
(3, 'Three')
SELECT
*
FROM
#MyTable
CREATE TABLE (Transact-SQL)
Temporary tables are automatically dropped when they go out of scope, unless explicitly dropped by using DROP TABLE:
A local temporary table created in a stored procedure is dropped automatically when the stored procedure is finished. The table can be referenced by any nested stored procedures executed by the stored procedure that created the table. The table cannot be referenced by the process that called the stored procedure that created the table.
All other local temporary tables are dropped automatically at the end of the current session.
Global temporary tables are automatically dropped when the session that created the table ends and all other tasks have stopped referencing them. The association between a task and a table is maintained only for the life of a single Transact-SQL statement. This means that a global temporary table is dropped at the completion of the last Transact-SQL statement that was actively referencing the table when the creating session ended.
I used to fall into the crowd of letting the objects get cleaned up by background server processes, however, recently having issues with extreme TempDB log file growth has changed my opinion. I'm not sure if this has always been the case with every version of SQL Server, but since moving to SQL 2016 and putting the drives on a PureStorage SSD array, things run a bit differently. Processes are typically CPU bound rather than I/O bound, and explicitly dropping the temp objects results in no issues with log growth. While I haven't dug in too deeply as to why, I suspect it's not unlike garbage collection in the .NET world where it's synchronous when called explicitly and asynchronous when left to the system. This would matter because the explicit drop would release the storage in the log file, and make it available at the next log backup, whereas this appears to not be the case when not explicitly dropping the object. On most systems this is likely not a big issue, but on a system supporting a high volume ERP and web storefront with many concurrent transactions, and heavy TempDB use, it has had a big impact. As for why to create the TempDB objects in the first place, with the amount of data in most of the queries, it would spill over into TempDB storage anyway, so it's usually more efficient to create the object with the necessary indexes rather than let the system handle it automatically.
In a multi-threaded scenario where each thread creates its own set of tables and the number of threads is throttled, not dropping your own tables means that the governor will consider your thread done and spawn more threads... however the temp tables are still around (and thus the connections to the server) thus you'll exceed the limits of your governor. if you manually drop the temp tables then the thread doesn't finish until they've been dropped and no new threads are spawned, thus maintaining the governor's ability to keep from overwhelming the SQL engine
As per my view. No need to drop temp tables explicitly. SQL server will handle to drop temp tables stored in temp db in case of shorage of space to process query.
What are the difference between a #myTable and a declare #myable table
In a stored procedure, you often have
a need for storing a set of data
within the procedure, without
necessarily needing that data to
persist beyond the scope of the
procedure. If you actually need a
table structure, there are basically
four ways you can "store" this data:
local temporary tables (#table_name),
global temporary tables
(##table_name), permanent tables
(table_name), and table variables
(#table_name).
Should I use a #temp table or a #table variable?
Both local and global temporary tables
are physical tables within the tempdb
database, indexes can be created
.Because temp tables are physical
tables, you can also create a primary
key on them via the CREATE TABLE
command or via the ALTER TABLE
command. You can use the ALTER TABLE
command to add any defaults, new
columns, or constraints that you need
to within your code.
Unlike local and global temporary
tables, table variables cannot have
indexes created on them. The exception
is that table variables can have a
primary key defined upon creation
using the DECLARE #variable TABLE
command. This will then create a
clustered or non-clustered index on
the table variable. The CREATE INDEX
command does not recognize table
variables. Therefore, the only index
available to you is the index that
accompanies the primary key and is
created upon table variable
declaration. Also transaction logs are not recorded for the table variables. Hence, they are out of scope of the transaction mechanism
Please see:
TempDB:: Table variable vs local temporary table
Table Variables In T-SQL
It is often said that #table variables are kept in memory as opposed to tempdb; this is not necessarily correct.
Table variables do not have statistics, and this can affect performance in certain situations.
Table variables are all well and good when dealing with relatively small datasets, but be aware that they do not scale well. In particular, a change in behaviour between SQL Server 2000 and SQL Server 2005 resulted in performance dropping through the floor with large datasets.
This was a particularly nasty gotcha for me on one particular occasion with a very complex stored procedure on SQL Server 2000. Research and testing indicated that using table variables was the more performant approach. However, following an upgrade to SQL Server 2008 performance degraded considerably. It took a while to cotton on to the use of table variables as the culprit because all the prior testing etc had ruled out temp tables as being any faster. However, due to this change between SQL Server versions, the opposite was now true and following a significant refactoring, what was taking well into double digit hours to complete started completing in a couple of minutes!
So be aware that there is no definitive answer as to which is best - you need to assess your circumstances, carry out your own testing, and make your decision based on your findings. And always re-evaluate following a server upgrade.
Read this article for more detailed information and sample timings - http://www.sql-server-performance.com/articles/per/temp_tables_vs_variables_p1.aspx
Update: On a separate note, be aware that there is also a third type of temporary table - ##xyz. These are global and visible to all SQL Server connections and not scoped to the current connection like regular temporary tables. They are only dropped when the final connection accessing it is closed.
'#myTable is a temporary table and benefits from being able to have constraints and indexes etc and uses more resources.
#myTable is a table variable that you define as having one or more columns. They use less resources and are scoped to the procedure you use them in.
In most cases where a temp table is used a table variable could be used instead which may offer performance benefits.
The table #tabel1 is a local temporary table stored in tempdb.
##table1 is global temporary table stored in tempdb.
and #table is table variable.
Check the link for their differences
What would be more efficient in storing some temp data (50k rows in one and 50k in another) to perform come calculation. I'll be doing this process once, nightly.
How do you check the efficiency when comparing something like this?
The results will vary on which will be easier to store the data, in disk (#temp) or in memory (#temp).
A few excerpts from the references below
A temporary table is created and populated on disk, in the system database tempdb.
A table variable is created in memory, and so performs slightly better than #temp tables (also because there is even less locking and logging in a table variable). A table variable might still perform I/O to tempdb (which is where the performance issues of #temp tables make themselves apparent), though the documentation is not very explicit about this.
Table variables result in fewer recompilations of a stored procedure as compared to temporary tables.
[Y]ou can create indexes on the temporary table to increase query performance.
Regarding your specific case with 50k rows:
As your data size gets larger, and/or the repeated use of the temporary data increases, you will find that the use of #temp tables makes more sense
References:
Should I use a #temp table or a #table variable?
MSKB 305977 - SQL Server 2000 - Table Variables
There can be a big performance difference between using table variables and temporary tables. In most cases, temporary tables are faster than table variables. I took the following tip from the private SQL Server MVP newsgroup and received permission from Microsoft to share it with you. One MVP noticed that although queries using table variables didn't generate parallel query plans on a large SMP box, similar queries using temporary tables (local or global) and running under the same circumstances did generate parallel plans.
More from SQL Mag (subscription required unfortunately, I'll try and find more resources momentarily)
EDIT: Here is some more in depth information from CodeProject
I'm using SQL Server 2000, and many of the stored procedures it use temp tables extensively. The database has a lot of traffic, and I'm concerned about the thread-safety of creating and dropping temp tables.
Lets say I have a stored procedure which creates a few temp tables, it may even join temp tables to other temp tables, etc. And lets also say that two users execute the stored procedure at the same time.
Is it possible for one user to run the sp and which creates a temp table called #temp, and the another user runs the same sp but gets stopped because a table called #temp already exists in the database?
How about if the same user executes the same stored procedure twice on the same connection?
Are there any other weird scenarios that might cause two users queries to interfere with one another?
For the first case, no, it is not possible, because #temp is a local temporary table, and therefore not visible to other connections (it's assumed that your users are using separate database connections). The temp table name is aliased to a random name that is generated and you reference that when you reference your local temp table.
In your case, since you are creating a local temp table in a stored procedure, that temp table will be dropped when the scope of the procedure is exited (see the "remarks section").
A local temporary table created in a stored procedure is dropped automatically when the stored procedure completes. The table can be referenced by any nested stored procedures executed by the stored procedure that created the table. The table cannot be referenced by the process which called the stored procedure that created the table.
For the second case, yes, you will get this error, because the table already exists, and the table lasts for as long as the connection does. If this is the case, then I recommend you check for the existence of the table before you try to create it.
Local-scope temp tables (with a single #) are created with an identifier at the end of them that makes them unique; multiple callers (even with the same login) should never overlap.
(Try it: create the same temp table from two connections and same login. Then query tempdb.dbo.sysobjects to see the actual tables created...)
Local temp tables are thread-safe, because they only exist within the current context. Please don't confuse context with current connection (from MSDN: "A local temporary table created in a stored procedure is dropped automatically when the stored procedure is finished"), the same connection can safely call two or more times a stored procedure that creates a local temp table (like #TMP).
You can test this behavior by executing the following stored procedure from two connections. This SP will wait 30 seconds so we can be sure the two threads will be running their over their own versions of the #TMP table at the same time:
CREATE PROCEDURE myProc(#n INT)
AS BEGIN
RAISERROR('running with (%d)', 0, 1, #n);
CREATE TABLE #TMP(n INT);
INSERT #TMP VALUES(#n);
INSERT #TMP VALUES(#n * 10);
INSERT #TMP VALUES(#n * 100);
WAITFOR DELAY '00:00:30';
SELECT * FROM #TMP;
END;
The short answer is:
Isolation of temporary tables is guaranteed per query, and there's
nothing to worry about either in regard to threading, locks, or
concurrent access.
I'm not sure why answers here talk about a significance of 'connections' and threads as these are programming concepts, whereas query isolation is handled at the database level.
Local temporary objects are separated by Session in SQL server. If you have two queries running concurrently, then they are two completely separate sessions and won't intefere with one another. The Login doesn't matter, so for example if you are using a single connection string using ADO.NET (meaning that multiple concurrent queries will use the same SQL server 'login'), your queries will all still run in separate sessions. Connection Pooling also doesn't matter. Local temporary objects (Tables and Stored Procedures) are completely safe from being seen by other sessions.
To clarify how this works; while your code has a single, common name for the local temporary objects, SQL Server appends a unique string to each object per each session to keep them separate. You can see this by running the following in SSMS:
CREATE TABLE #T (Col1 INT)
SELECT * FROM tempdb.sys.tables WHERE [name] LIKE N'#T%';
You will see something like the following for the name:
T_______________00000000001F
Then, without closing that query tab, open up a new query tab and paste in that same query and run it again. You should now see something like the following:
T_______________00000000001F
T_______________000000000020
So, each time your code references #T, SQL Server will translate it to the proper name based on the session. The separation is all handled auto-magically.
Temp tables are tied to the session, so if different users run your procedure simultaneously there's no conflict...
Temp tables are created only in the context of the query or proc that creates them. Each new query gets a context on the database that is free of other queries' temp tables. As such, name collision is not a problem.
If you look in the temps database you can see the temporary tables there, and they have system generated names. So other than regular deadlocks you should be OK.
unless you use two pound signs ##temp the temp table will be local and only exists for that local connection to the user
First let's make sure you are using real temp tables, do they start with # or ##? If you are creating actual tables on the fly and then dropping and recreating them repeatedly, you will indeed have problems with concurrent users. If you are createing global temp tables (ones that start with ##) you can also have issues. If you do not want concurrency issues use local temp tables (They start with #). It is also a good practice to explicitly close them at the end of the proc (or when they are no longer needed by the proc if you are talking long multi-step procs) and to check for existence (and drop if so) before creating.