- IBM DB2 9.7 Advanced Application Developer Cookbook
- Sanjay Kumar Mohankumar Saraswatipura
- 1054字
- 2021-08-20 15:42:22
Creating Declared Global Temporary Tables (DGTTs)
Declared Global Temporary Tables (also known as DGTTs) are used to store temporary results within an application. Because these tables are only used for temporary storage, they do not persist. They do not appear in the system catalog either. And because they don't persist, they can't be shared with other applications. When the application using this table terminates, any data in the table is deleted and the table is dropped.
Another key difference between DGTTs and regular tables is that the rows in a DGTT cannot be locked, as the temporary tables can't be shared among different applications. In this recipe, we will create a declared global temporary table.
Getting ready
- To create a declared global temporary table, we need a user temporary table space.
- To create a declared global temporary table, we need at least one of the following authorities/privileges:
USE
privilege onUSER TEMPORARY TABLE SPACE
DBADM
authoritySYSADM
authoritySYSCTRL
authority
How to do it...
In this section, we will see how to create the declared global temporary tables:
- Before we can create any temporary table, we need a user temporary table space. It's always recommended to create temporary table spaces as
MANAGED BY SYSTEM
. If this clause is specified, then the table space is controlled by the operating system. Use theCREATE TABLESPACE
command to create a temporary tablespace:CREATE USER TEMPORARY TABLESPACE user_temp_tbsp MANAGED BY SYSTEM USING ('c:\user_tbsp')
- Use the following command to create a DGTT. This statement defines a temporary table called
sal_rise_temp:
DECLARE GLOBAL TEMPORARY TABLE sal_rise_temp (empno INT, sal_rise_date DATE, updated_sal BIGINT, manager_empno INTEGER) ON COMMIT DELETE ROWS NOT LOGGED IN user_temp_tbsp
- We can also use the
LIKE
clause to create a temporary table similar to the existing regular table:
DECLARE GLOBAL TEMPORARY TABLE emp_temp LIKE EMPLOYEE ON COMMIT DELETE ROWS NOT LOGGED IN user_temp_tbsp
How it works...
ON COMMIT DELETE ROWS:
If this option is specified, then the rows in the temporary table are deleted on everyCOMMIT
.NOT LOGGED:
If this option is specified, the insert, update, and delete operations are not logged. Only creation and dropping are logged. If this option is specified, then DB2 uses an internalTRUNCATE
to delete the rows in the table. If any cursor with theWITH HOLD
clause is open, then DB2 will delete one row at a time. The default isLOGGED
, which logs everything.
If the temporary table is defined without specifying any table space name, then DB2 looks for the existing user's temporary table space that has the smallest sufficient page size over which the user has USE
privilege. If table spaces with these criteria are present more than once, then DB2 decides which to choose.
There's more...
We can create more than one temporary table with the same name in different applications unlike regular tables. This becomes very advantageous in designing applications for concurrent users.
The temporary tables can also get benefits from row compression. The compression is enabled for a declared temporary table. If DB2 thinks it can benefit from the compression of a temporary table, then the data will be compressed. This is completely transparent to the user and nothing's especially needed to enable the compression for temporary tables. The indexes on the temporary tables are also eligible for compression.
The errors in operation during a unit of work using a declared temporary table do not cause the unit of work to be completely rolled back. However, an error in operation in a statement changing the contents of a declared temporary table will delete all the rows in that table.
The schema for declared global temporary table is always SESSION
. We always need to qualify a temporary table with this schema or else DB2 will look for a table in the current schema.
To select the data from a temporary table temp_tbl
, we can use following command:
SELECT * FROM SESSION.temp_tbl
The preceding statement selects all records from the temp_tbl
temporary table.
For all declared global temporary tables, the schema name is always SESSION
. We can also create a regular table with the schema name as SESSION
. In such cases, if we have a regular table (as in SESSION
schema) and a temporary table with the same name, then DB2 will resolve the reference to the temporary table rather than the regular table. Hence, it is never recommended to create regular tables in the SESSION
schema to avoid confusion.
The declared temporary tables are dropped when the application terminates the database connection. We can also drop them explicitly, by using the DROP
command. For example:
DROP TABLE SESSION.temp_tbl
To drop a temporary table, we must specify SESSION
as a schema name. Once the temporary table is dropped, it can no longer be referenced even if the transaction is not committed.
If a temporary table is defined within a transaction, then with the ROLLBACK
command, the temporary table is also dropped. Otherwise, it is available until the application disconnects from the database. If we want to use a temporary table and its data across the transactions, then there is only one thing to think about, which is whether or not we want to preserve the data in the temporary table once it exits a transaction. This behavior can be specified by using the ON COMMIT
clause:
DECLARE GLOBAL TEMPORARY TABLE sal_rise_temp (empno INT, sal_rise_date DATE, updated_sal BIGINT, manager_empno INTEGER) ON COMMIT DELETE ROWS NOT LOGGED IN user_temp_tbsp
If the ON COMMIT DELETE ROWS
clause is specified, then the rows will be deleted on COMMIT
. This is the default. If the ON COMMIT PRESERVE ROWS
clause is specified, then the rows will not be deleted on COMMIT
.
We can use the SYSIBMADM.ADMINTEMPTABLES
administrative view and the SYSPROC.ADMIN_GET_TEMP_TABLES
table function to get information about the temporary table present in the database. The results can be filtered by specifying conditions, such as TEMPTABTYPE='D'
or TEMPTABTYPE= 'C'
. We can also filter the results through the application handle or application name:
SELECT TABSCHEMA, TABNAME, ONCOMMIT, ONROLLBACK, INSTANTIATION_TIME FROM SYSIBMADM.ADMINTEMPTABLES WHERE TEMPTABTYPE = 'D' AND INSTANTIATOR = SYSTEM_USER SELECT TABSCHEMA, TABNAME, ONCOMMIT, ONROLLBACK, INSTANTIATION_TIME FROM TABLE (SYSPROC.ADMIN_GET_TEMP_TABLES(APPLCATION_HANDLE, TABSCHEMA, TABNAME)) AS T
The sample output is as follows:

- Visual Basic 6.0程序設(shè)計(jì)計(jì)算機(jī)組裝與維修
- Learning Spring 5.0
- Java完全自學(xué)教程
- 編程卓越之道(卷3):軟件工程化
- 深入淺出Windows API程序設(shè)計(jì):編程基礎(chǔ)篇
- 深度學(xué)習(xí):Java語言實(shí)現(xiàn)
- Swift 4 Protocol-Oriented Programming(Third Edition)
- RESTful Java Web Services(Second Edition)
- Illustrator CC平面設(shè)計(jì)實(shí)戰(zhàn)從入門到精通(視頻自學(xué)全彩版)
- 創(chuàng)意UI:Photoshop玩轉(zhuǎn)APP設(shè)計(jì)
- 人人都能開發(fā)RPA機(jī)器人:UiPath從入門到實(shí)戰(zhàn)
- Software-Defined Networking with OpenFlow(Second Edition)
- Mastering OpenStack
- Learning Alfresco Web Scripts
- Cinder:Begin Creative Coding