关于Oracle 临时表,参考我的Blog:
Oracle 临时表
http://blog.csdn.net/tianlesoftware/archive/2009/10/20/4705283.aspx
对Oracle 临时表的操作,会产生redo 和undo。
先看一个示例:
SYS@anqing1(rac1)> CREATE GLOBAL TEMPORARY TABLE dave_test (id number,name varchar2(20)) ON COMMIT DELETE ROWS;
Table created.
SYS@anqing1(rac1)> set autotrace on
SYS@anqing1(rac1)> insert into dave_test values(1,'dave');
1 row created.
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------
| 0 | INSERT STATEMENT | | 1 | 100 | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------
Statistics
----------------------------------------------------------
2 recursive calls
8 db block gets
1 consistent gets
0 physical reads
284 redo size
662 bytes sent via SQL*Net to client
571 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
1 rows processed
SYS@anqing1(rac1)>
关于这些统计数据的分析,参考我的Blog:
Oracle Explain Plan
http://blog.csdn.net/tianlesoftware/archive/2010/08/20/5827245.aspx
在看下为什么对临时表操作会产生redo。
因为我们可以对临时表的操作进行回滚,即会产生undo数据; 但是所有undo都受到redo的保护,就是说假设此时数据库崩溃了,下次启动会利用redo把这些undo再次还原出来,然后利用这些undo进行反操作,撤销上次那个崩溃的事务。
这些undo里面可能有普通表的,也有临时表的, redo都会把它们恢复出来。
这个就是我们的一个数据库roll forward和 roll back的顺序问题, 在Crash recover 的时候必须先前滚,用redo 恢复出undo 之后,在用undo 回滚相关事务操作信息。简单点说REDO的作用就是记录所有的数据库更改,包括UNDO表空间在内。
Oracle 实例恢复时 前滚(roll forward) 后滚(roll back) 问题
http://blog.csdn.net/tianlesoftware/archive/2011/03/29/6286330.aspx
-------------------------------------------------------------------------------------------------------
Blog: http://blog.csdn.net/tianlesoftware
Email: dvd.dba@gmail.com
DBA1 群:62697716(满); DBA2 群:62697977(满) DBA3 群:62697850(满)
DBA 超级群:63306533(满); DBA4 群: 83829929 DBA5群: 142216823
DBA6 群:158654907 聊天 群:40132017 聊天2群:69087192
--加群需要在备注说明Oracle表空间和数据文件的关系,否则拒绝申请
来源:https://www.cnblogs.com/hibernate315/archive/2011/05/30/2399021.html