oracle全局变量

CREATE GLOBAL TEMPORARY TABLE TABLENAME (

COL1 VARCHAR2(10),

COL2 NUMBER

) ON COMMIT PRESERVE(DELETE) ROWS ;

这种临时表不占用表空间，而且不同的 SESSION 之间互相看不到对方的数据

在会话结束后表中的数据自动清空，如果选了 DELETE ROWS ，则在提交的时候即清空数据， PRESERVE 则一直到会话结束

 

 

在 Oracle8i 中，可以创建以下两种临时表：

(1) 会话特有的临时表

CREATE GLOBAL TEMPORARY <TABLE_NAME> (<column specification>)

ON COMMIT PRESERVE ROWS ；

 

(2) 事务特有的临时表

CREATE GLOBAL TEMPORARY <TABLE_NAME> (<column specification>)

ON COMMIT DELETE ROWS ；

CREATE GLOBAL TEMPORARY TABLE MyTempTable

所建的临时表虽然是存在的，但是你试一下 insert 一条记录然后用别的连接登上去 select ，记录是空的，明白了吧，我把下面两句话再贴一下：

--ON COMMIT DELETE ROWS 说明临时表是事务指定，每次提交后 ORACLE 将截断表（删除全部行）

--ON COMMIT PRESERVE ROWS 说明临时表是会话指定，当中断会话时 ORACLE 将截断表。

冲突的问题更本不用考虑 .

 

临时表只是保存当前会话 (session) 用到的数据，数据只在事务或会话期间存在。

 

通过 CREATE GLOBAL TEMPORARY TABLE 命令创建一个临时表，对于事务类型的临时表，

数据只是在事务期间存在，对于会话类型的临时表，数据在会话期间存在。

 

会话的数据对于当前会话私有。每个会话只能看到并修改自己的数据。 DML 锁不会加到

临时表的数据上。下面的语句控制行的存在性。

 

● ON COMMIT DELETE ROWS 表名行只是在事务期间可见

● ON COMMIT PRESERVE ROWS 表名行在整个会话期间可见

 

可以对临时表创建索引，视图，出发器，可以用 export 和 import 工具导入导出表的

定义，但是不能导出数据。表的定义对所有的会话可见。

 

例如：

CREATE GLOBAL TEMPORARY TABLE TEMP_TAB1(

table_name VARCHAR2(20),

primary_key VARCHAR2(100),

field VARCHAR2(1000))

ON COMMIT PRESERVE ROWS;

 

CREATE GLOBAL TEMPORARY TABLE TEMP_TAB2(

table_name VARCHAR2(20),

primary_key VARCHAR2(100),

field VARCHAR2(1000))

ON COMMIT DELETE ROWS;

 

===============================================================================================

 

近年我做的项目中较少使用临时表 Temporary Table ，其实 Temp Table 还是可以有比较广泛的应用的。

 

Temp Table 的特点

 

（ 1 ） 多用户操作的独立性：对于使用同一张临时表的不同用户， ORACLE 都会分配一个独立的 Temp Segment ，这样就避免了多个用户在对同一张临时表操作时发生交叉，从而保证了多个用户操作的并发性和独立性；

 

（ 2 ） 数据的临时性：既然是临时表，顾名思义，存放在该表中的数据是临时性的。 ORACLE 根据你创建临时表时指定的参数（ On Commit Delete Rows / On Commit Preserve Rows ），自动将数据 TRUNCATE 掉。

 

Temp Table 数据的时效性

 

（ 1 ） On Commit Delete Rows ： 数据在 Transaction 期间有效，一旦 COMMIT 后，数据就被自动 TRUNCATE 掉了；

 

SQL> CREATE GLOBAL TEMPORARY TABLE QCUI_Temp_Trans

 

2 ON COMMIT DELETE ROWS

 

3 AS

 

4 SELECT * FROM t_Department;

 

表已创建。

 

―――――――――――――――――――――――――――――――――

 

SQL> INSERT INTO QCUI_Temp_Trans

 

2 SELECT * FROM t_Dept;

 

已创建 4 行。

 

――――――――――――――――――――――――――――――

 

SQL> SELECT * FROM QCUI_Temp_Trans;

 

DEPTID DEPTNAME

 

---------- --------------------

 

101 销售部

 

201 财务部

 

301 货运部

 

401 采购部

 

――――――――――――――――――――――――――――――

 

SQL> commit;

 

提交完成。

 

――――――――――――――――――――――――――――――

 

SQL> SELECT * FROM QCUI_Temp_Trans;

 

未选定行

 

――――――――――――――――――――――――――――――

 

（ 2 ） On Commit Preserve Rows ：数据在 Session 期间有效，一旦关闭了 Session 或 Log Off 后，数据就被 ORACLE 自动 Truncate 掉。

 

SQL> CREATE GLOBAL TEMPORARY TABLE QCUI_Temp_Sess

 

2 ON COMMIT PRESERVE ROWS

 

3 AS

 

4 SELECT * FROM t_Department;

 

表已创建。

 

――――――――――――――――――――――――――――――

 

SQL> Select * from QCUI_Temp_Sess;

 

DEPTID DEPTNAME

 

---------- --------------------

 

101 销售部

 

301 货运部

 

401 采购部

 

201 财务部

 

――――――――――――――――――――――――――――――

 

SQL> exit

 

――――――――――――――――――――――――――――――

 

C:Documents and SettingsQCUI>sqlplus sqltrainer@ibm

 

――――――――――――――――――――――――――――――

 

SQL> SELECT * FROM QCUI_Temp_Sess;

 

未选定行

 

――――――――――――――――――――――――――――――

 

注：这里要说明的是， ORACLE Truncate 掉的数据仅仅是分配给不同 Session 或 Transaction 的 Temp Segment 上的数据，而不是将整张表数据 TRUNCATE 掉。

 

Temp Table 的应用

 

Temp Table 就我理解而言，主要有两方面应用。

 

对于一个电子商务类网站，不同消费者在网站上购物，就是一个独立的 SESSION ，选购商品放进购物车中，最后将购物车中的商品进行结算。也就是说，必须在整个 SESSION 期间保存购物车中的信息。同时，还存在有些消费者，往往最终结账时放弃购买商品。如果，直接将消费者选购信息存放在最终表（ PERMANENT ）中，必然对最终表造成非常大的压力。

 

因此，对于这种案例，就可以采用创建临时表（ ON COMMIT PRESERVE ROWS ）的方法来解决。数据只在 SESSION 期间有效，对于结算成功的有效数据，转移到最终表中后， ORACLE 自动 TRUNCATE 临时数据；对于放弃结算的数据， ORACLE 同样自动进行 TRUNCATE ，而无须编码控制，并且最终表只处理有效订单，减轻了频繁的 DML 的压力。

 

Temp Table 的另一个应用，就是存放数据分析的中间数据。

 

Temp Table 存放在哪儿？

 

Temp Table 并非存放在用户的表空间中，而是存放在 Schema 所指定的临时表空间中。

 

SQL> Select Table_Name, Tablespace_Name

 

2 From User_Tables

 

3 Where Table_Name Like 'QCUI%';

 

TABLE_NAME TABLESPACE_NAME

 

------------------------------ ------------------------------

 

QCUI_TEMP_SESS

 

QCUI_TEMP_TRANS

 

――――――――――――――――――――――――――――――

 

可见这两张临时表并未存放在用户的表空间中。

 

用户 SQLTRAINER 的临时表空间是 TEMP , 用户创建的临时表是存放在 TEMP 表空间中的。下面来证明

 

SQL> SELECT UserName, Default_Tablespace def_ts, Temporary_Tablespace temp_ts

 

2 FROM User_Users;

 

USERNAME DEF_TS TEMP_TS

 

------------------------------ ------------------ ----------

 

SQLTRAINER ts_ORASQLTraining TEMP

 

――――――――――――――――――――――――――――――

 

SQL> connect system/manager@ibm

 

已连接。

 

SQL> alter tablespace temp offline;

 

表空间已更改。

 

――――――――――――――――――――――――――――――

 

SQL> connect sqltrainer/sqltrainer@ibm

 

已连接。

 

SQL> INSERT INTO QCUI_Temp_Sess

 

2 SELECT * FROM t_Department;

 

INSERT INTO QCUI_Temp_Sess

 

*

 

ERROR 位于第 1 行 :

 

ORA-01542: 表空间 'TEMP' 脱机，无法在其中分配空间

 

――――――――――――――――――――――――――――――

 

对 Temp Table 的 DML 操作是否不产生 Redo Log ？

 

尽管对临时表的 DML 操作速度比较快，但同样也是要产生 Redo Log 的，只是同样的 DML 语句，比对 PERMANENT 的 DML 产生的 Redo Log 少。

 

SQL> Set AutoTrace On

 

SQL> CREATE GLOBAL TEMPORARY TABLE QCUI_Temp_Sess_AllObj

 

2 ON COMMIT PRESERVE ROWS

 

3 AS

 

4 SELECT * FROM All_Objects;

 

表已创建。

 

SQL> INSERT INTO QCUI_Temp_Sess_AllObj

 

2 SELECT * FROM All_Objects;

 

已创建 21839 行。

 

Statistics

 

----------------------------------------------------------

 

……

 

168772 redo size

 

……

 

――――――――――――――――――――――――――――――

 

SQL> CREATE TABLE QCUI_ALL_OBJECTS

 

2 AS

 

3 SELECT * FROM All_Objects

 

4 WHERE 1 = 0;

 

表已创建。

 

SQL> INSERT INTO QCUI_All_Objects

 

2 SELECT * FROM ALL_Objects;

 

已创建 21839 行。

 

Statistics

 

----------------------------------------------------------

 

……

 

2439044 redo size

 

……――――――――――――――――――――――――――――――