今天在学习oracle的存储过程时,发现有CREATE global TEMPORARY TABLE temp_lifecycle_id(lifecycle_id int ) ON COMMIT DELETE ROWS的语句,本身对oracle没有做过深入的研究,趁着今天有点小时间,来将此语句的用法搞搞清楚。
CREATE global TEMPORARY TABLE temp_lifecycle_id(lifecycle_id int ) ON COMMIT DELETE ROWS此语句是创建一个临时表,而这种临时表不占用表空间,而且不同的session之间互相是看不到对方的数据。在会话结束后表中的数据自动清空,如果选了delete rows,则在提交的时候即清空数据。
在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工具导入导出表的
定义,但是不能导出数据。表的定义对所有的会话可见。
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 掉了;
(2)On Commit Preserve Rows :数据在 Session 期间有效,一旦关闭了Session 或 Log Off 后,数据就被 ORACLE 自动 Truncate 掉。
注:这里要说明的是,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 并非存放在用户的表空间中,而是存放在 Schema 所指定的临时表空间中。
尽管对临时表的DML操作速度比较快,但同样也是要产生 Redo Log 的,只是同样的DML语句,比对 PERMANENT 的DML 产生的Redo Log 少。
CREATE global TEMPORARY TABLE temp_lifecycle_id(lifecycle_id int ) ON COMMIT DELETE ROWS此语句是创建一个临时表,而这种临时表不占用表空间,而且不同的session之间互相是看不到对方的数据。在会话结束后表中的数据自动清空,如果选了delete rows,则在提交的时候即清空数据。
在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工具导入导出表的
定义,但是不能导出数据。表的定义对所有的会话可见。
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 掉了;
(2)On Commit Preserve Rows :数据在 Session 期间有效,一旦关闭了Session 或 Log Off 后,数据就被 ORACLE 自动 Truncate 掉。
注:这里要说明的是,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 并非存放在用户的表空间中,而是存放在 Schema 所指定的临时表空间中。
尽管对临时表的DML操作速度比较快,但同样也是要产生 Redo Log 的,只是同样的DML语句,比对 PERMANENT 的DML 产生的Redo Log 少。