1. 臨時表
1) 概念
a) 臨時表跟永久表最大的區別就是表中的數據不會永遠的存在
b) Oracle臨時表分爲會話級臨時表和事務級臨時表。
c) 會話臨時表，結束或中斷會話時清空數據。
create global temporary table XXX()
on commit preserve rows;d) 事務臨時表，commit之後清空數據。
on commit delete rows;2) 原理
a) 臨時表不會爲它們的塊生成redo。因此，對臨時表的操作不是“可恢復的” 。修改臨時表中的一個塊時，不會將這個修改記錄到重做日誌文件中。不過，臨時表確實會生成 undo，而且這個 undo 會計入日誌。因此，臨時表也會生成一些redo。
b) 這是因爲你能回滾到事務中的一個 SAVEPOINT。由於undo數據必須建立日誌，因此臨時表會爲所生成的undo生成一些重做日誌。這樣似乎很糟糕。但是，在臨時表上運行的 SQL 語句主要是 INSERT 和SELECT。幸運的是，INSERT 只生成極少的 undo（需要把塊恢復爲插入前的“沒有”狀態，而存儲“沒有”不需要多少空間），另外SELECT根本不生成undo。
c) Oracle的臨時表還保證了多用戶操作的獨立性：對於使用同一張臨時表的不同用戶，ORACLE都會分配一個獨立的Temp Segment，這樣就避免了多個用戶在對同一張臨時表操作時發生交叉，從而保證了多個用戶操作的併發性和獨立性；
3) 應用優化
a) 當多表關聯，且存在小表時。可以採用將大表關聯得到比較小的結果集合存放在臨時表中，再用臨時表去關聯小表。
b) 如果某個數據集在這個會話期間需多次使用，建議使用臨時表。
2. 物化視圖
1) 概念
視圖是一個虛擬表（也可以認爲是一條語句），基於它創建時指定的查詢語句返回的結果集。每次訪問它都會導致這個查詢語句被執行一次。爲了避免每次訪問都執行這個查詢，可以將這個查詢結果集存儲到一個物化視圖（也叫實體化視圖）。
2) 類型
物化視圖的類型：ON DEMAND、ON COMMIT
a) on demand
根據需要（ON DEMAND）：物化視圖會在顯式請求的情況下進行刷新（可以通過手工調用，也可以通過運行按照指定的時間間隔的任務)。這意味着從基礎表修改到物化視圖刷新這段時間內，物化視圖中可能包含失效的數據。
b) on commit
在提交時（ON COMMIT)：物化視圖會在基礎表修改所在的同一個事務裏進行自動刷新，也就是說，物化視圖總是包含最新的數據；（這種方式比較少用）
3) 刷新
a) 完全刷新（COMPLETE）
會刪除表中所有的記錄（如果是單表刷新，可能會採用TRUNCATE的方式），然後根據物化視圖中查詢語句的定義重新生成物化視圖。
b) 快速刷新（FAST）
採用增量刷新的機制，只將自上次刷新以後對基表進行的所有操作刷新到物化視圖中去。
c) FORCE方式
這是默認的數據刷新方式。Oracle會自動判斷是否滿足快速刷新的條件，如果滿足則進行快速刷新，否則進行完全刷新。
4) 語法
create materialized view view_name
refresh [fast|complete|force]
[
on [commit|demand] |
start with (start_time) next (next_time)
]
AS subquery;5) 示例
a) 創建MATERIALIZED VIEW：
create materialized view mv_materialized_test refresh force on demand start with sysdate next
to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),'10:25:00'),'dd-mm-yyyy hh24:mi:ss') as
select * from user_info;
--這個物化視圖在每天10：25進行刷新 b) 修改刷新時間：
alter materialized view mv_materialized_test refresh force on demand start with sysdate
next to_date(concat(to_char(sysdate+1,'dd-mm-yyyy'),' 23:00:00'),'dd-mm-yyyy hh24:mi:ss');
或
alter materialized view mv_materialized_test refresh force on demand start with sysdate
next trunc(sysdate,'dd')+1+1/24; -- 每天1點刷新