从数据安全性来看，对表记录的操作写日志是不可避免的，否则备份恢复就无从谈起了.

现实中真的有一部分应用对表的某些操作是不需要恢复的，比如运算过程中临时处理的中间结果集，这时就可以考虑用全局临时表来实现。

全局临时表的类型

“全局临时表分为两种类型，一种是基于会话的全局临时表（on commitpreserve rows），一种是基于事务的全局临时表（on commit deleterows）：

观察各类DML的redo量

全局临时表无论插入、修改还是删除，都还是要写日志：

无论插入、更新还是删除，操作普通表产生的日志都比全局临时表要多。

DML操作针对全局临时表来说，只是产生的日志要少得多，而不是不会产生。

全局临时表的两大重要特性

1.高效删除记录

全局临时表有两个重要的特点。一是高效删除记录，基于事务的全局临时表 COMMIT 或者 SESSION 连接退出后，临时表记录自动删除；

基于会话的全局临时表则是SESSION连接退出后，临时表记录自动删除，都无须手动去操作。

二是针对不同会话数据独立，不同的SESSION访问全局临时表，看到的结果不同。

这两点既是全局临时表最重要的特点，也是最有用的特点，在某些特定的场合可发挥出巨大的作用。

测试基于事务的全局临时表COMMIT后，记录是否已经删除了，并查看产生日志的情况

基于事务的全局临时表插入了55 721行，COMMIT后，再查这个表时记录就没了。

用COMMIT方式删除全局临时表记录所产生的日志量才304 116-303976=140字节，比起之前的直接用delete方式操作产生的日志量16 541 396字节，几乎可以忽略不计了。

140字节这个日志量其实是COMMIT 动作本身产生的，所以基本可以理解为全局临时表的 COMMIT 或者退出 SESSION 的方式不会产生日志，这是Oracle的全局临时表的一种特性。

测试基于会话的全局临时表的运行情况：

基于会话的全局临时表在COMMIT后表的记录依然存在，和基于事务的临时表真是不一样。140是COMMIT动作本身产生的redo，因为现在304 176304 036也是等于140。

测试退出会话，再重新连接后，记录情况：

记录真的没有了。

全局临时表在程序的一次调用执行过程中需要多次清空记录再插入记录，就要考虑用基于事务的，这时COMMIT可以把结果快速清理了，否则用delete效率低下。如果不存在这种情况，就用基于会话的，更简单，连COMMIT的动作都省了。

基于会话的全局临时表的应用会更多一些，少数比较复杂的应用，涉及一次调用中需要清空记录再插入等复杂动作时，才考虑用基于事务的全局临时表。

全局临时表的第二个重要特点，针对不同会话是独立的

先进入一个 SID=975的会话，完成全局临时表的插入，查看当前有记录

再登录一个SID=973的新连接，发现同样是这个 t_tmp_session 表，记录为0，对该表插入一条记录，在当前会话中查询到该表就只有一条记录：

这时回到SID=975的会话再去查看t_tmp_session表，会发现那个会话查询的记录依然是55 721条。