Nonstop Database, HiRDB Version 9 Installation and Design Guide
A temporary table contains specific data for a particular transaction or SQL session and is not available to be accessed by other users. In general, therefore, HiRDB does not acquire locks for table operations other than when a temporary table is instantiated. This subsection explains locking for temporary tables.
When a temporary table is instantiated, HiRDB acquires the locks shown in the following table.
Table 12-29 Locks acquired when a temporary table is instantiated
| Resource type name | Description | Unlock timing | |
|---|---|---|---|
| Transaction-specific temporary table | SQL session-specific temporary table | ||
| RDAR | RDAREA (table and index#1 storage RDAREA) | When the transaction is completed | When the DISCONNECT statement is completed |
| TABL | Table | ||
| RATM | User directory table information | ||
| RAIM | User directory index information#1 | ||
| SBMB | User directory segment information | ||
| TEMP | Temporary table instantiation control information | After the temporary table has been instantiated#2 | |
| TPID | User-specific ID management (temporary table) | When the DISCONNECT statement is completed | |
| RDAS | RDAREA status management | After the temporary table has been instantiated#2 | |
| RRAM, TRAL, TRAI |
RDAREA management information | ||
| PTBL | Table for preprocessing | When the DISCONNECT statement is completed | |
When the following SQL statements are executed, a lock is acquired only for the preprocessing table (PTBL):
Note that executing the following SQL statements on a temporary table will not lock pages, rows, or key values:
If you are performing an operation on a temporary table and, at the same time, you execute any of the following operations, a lock-release wait status or an execution error might result:
All Rights Reserved. Copyright (C) 2012, 2015, Hitachi, Ltd.