對於我們這個專案來說，資料庫的訪問的效能決定了資料提供的效能。優化的大致的原理只有兩個：一是資料分塊存放，便於資料的轉儲和管理；二是中間處理，提高資料提供的速度。
基於上面兩個根本的原理，借助於資料倉儲的概念，列舉資料庫的優化方式：
1． 分割槽
在資料倉儲中，事實表，索引表，維度表分處於三個不同的表空間當中（在部署的時候，最好是部署到不同的磁碟上）。這樣子做的原因就是便於併發操作，其實資料倉儲和普通的資料庫之間沒有嚴格的界限，主要還是部署上，當然oracle本身會為資料倉儲中的「事實表」生成「知識庫」等操作，保證更快的資料提供效率，其實可以借助於job和外部程式來排程儲存過程實現。基於這個思路，本專案資料庫中的索引將和事實表分開維護，當然這稱不上分割槽（）。真正的分割槽是指下面的內容。
分割槽就是partition/subpartition，對於事實表本身來說，以月為單位作partition掛載到不同表空間上。具體的示例如下：
create table t_lognode_record(……
callin_hh number(2) not null,
callin_dd number(2) not null,
callin_month number(2) not null,
callin_year number(4) not null,
month_mod number(1) not null
)partition by list (month_mod)
(partition p0 values (0) tablespace ts0,
partition p1 values (1) tablespace ts1,
partition p2 values (default) tablespace ts2
);上述的**中以month_mod欄位作為分割槽標準，將t_lognode_record分到三個不同的表空間（ts0，ts1，ts2）中，這裡有乙個技巧，month_mod = 月份mod3,這樣子可以不需要人工的維護哪個月分入哪個分割槽。當然簡單的以月作為分割槽之後，對於我們當前的資料庫來說還是遠遠不夠的，因為即使是乙個月的資料依然是很巨大的，那麼需要我們做subpartition，做法的示例為：
create table t_lognode_record(……
callin_dd number(2) not null,
month_mod number(1) not null
)partition by range(month_mod)
subpartition by list(callin_dd)
subpartition template
(subpartition subp1 values (1),
subpartition subp2 values (2),
subpartition subp3 values (3))(
partition p0 values less than (1),
partition p1 values less than (2),
partition p2 values less than (3)
);分割槽方式有三種：range（範圍），list（列表分割槽），hash（雜湊分割槽），需要解釋的hash分割槽，是oracle呼叫內建的hash函式來完成對資料的平均分布，保證分割槽內部的資料量相同，所以只需要制定分割槽的數量即可。
對於復合分割槽來說。不是所有分割槽格式都可以巢狀的，oracle只支援範圍列表分割槽，範圍雜湊分割槽，特別的範圍分割槽可以支援多個欄位range by(field1,field2)。對於本專案中用到的分割槽方式，只有示例中給出的兩種，至於分割槽的好處，請檢視google,^_^。給出操作的sql示例如下：
select * from t_lognode_record partition(p0)
update t_lognode_record partition(p0) t set……
insert語句沒有影響。當然上述的操作可以像普通的sql語句一樣，不指定分割槽也可以進行，但在查詢的時候請盡量能確定分割槽和子分割槽subpartition，這樣子會讓查詢的速度提高百倍。可以刪除指定的分割槽drop或者truncate, export和import分割槽中資料，但是當進行分割槽的刪除操作的時候，會使全域性的索引（index）實效，需要重新建立。
2． 維度
dimension這個算是oracle的高階功能了,在plsql developer沒有辦法找到這個物件（但是可以執行語句來生成該物件，但是無法進行後期的維護），只能在toad中有它的身影。它是表明資料維度字段之間的大小關係。典型的自然是下面的年月日了。
create table dim_time
(d_year varchar2(4) not null,
d_quater varchar2(2) not null,
d_month varchar2(2) not null,
d_day date not null
)create dimension dim_time
level year is (dim_time.d_year)
level quater is (dim_time.d_quater)
level month is (dim_time.d_month)
level day is (dim_time.d_day)
hierarchy y_q_m_d
(day child of
month child of
quater child of year
)hierarchy y_m_d
(day child of
month child of year
) 建立了兩條繼承關係y_q_m_d和y_m_d。當dim_time本身的統計，以及與其他表作聯合查詢然後彙總時，月的彙總資料自動以日彙總的資料為基礎，這樣子大大提高資料彙總的速度。
可以為一張表建立多個維度表，乙個維度中可以有多個繼承關係。維度極大程度上提高了資料彙總的速度，使我們這個專案的資料統計分析的利器。
3． 物化檢視（快照）
物化檢視materialized view。值得高興的是plsql developer和toad上同時擁有了這個物件的存在（toad上可能將這個稱為快照snapshots），但是令人鬱悶的事情產生了，在plsql developer上寫成的materialized view在toad中無法識別，看來還要兩個都用才可以。
物化檢視，顧名思義擁有檢視的屬性，它是建立在實際表的基礎上，將實際表中的資料抽象展示，甚至建立的方式都幾乎一樣。但是它成為物化，就意味著它是實體物件，從某種意義上將，它更像乙個中間表，可以像**一樣直接查詢其中的資料（甚至就在table列表中可以看到它），但是它不僅僅是中間表，因為它可以影響原始表的資料，並且oracle可以自動將針對原始表的查詢彙總語句直接重定向到物化檢視上，來提公升查詢的速度。
create materialized view mv_log_record
refresh force
on demand
enable query rewrite
asselect t. node_id, count(*) as call_times
from t_lognode_record t
group by t. t_lognode_record
上面的sql語句就已經在t_lognode_record表上建立乙個物化檢視。refresh的引數 force表示強制重新整理，還可以選擇的引數有fast和complete兩種，fast是最快的重新整理方式，表示增量重新整理（要做到增量重新整理，必須在物化檢視中包含唯一性的標示的字元，如主鍵和rowid等，當然即使包含了也不一定可以做到快速重新整理，因為我們專案中沒有涉及到要重新整理的物化檢視，在此就不多言了）；complete表示完整的資料重新整理，重新生成物化檢視；force是選擇性的重新整理，根據實際的情況來選擇是force還是complete。
on demand表示重新整理觸發的條件。上面的物化檢視只有在使用者發起查詢請求時，才會去重新整理資料，即將原始表中的資料取到物化檢視的表中。還有一種方式就是 on commit，當使用者操作原始資料時，就重新整理對應的物化檢視，這種方式適合對於即時性要求高的專案。如果需要做定時的重新整理，就要用到下面的方式：
refresh fast start with sysdate
next sysdate + 1/48。
物化檢視是可以跨越多個表的，也可以直接的查詢物化試圖，例如你可以：
select * from mv_log_record.
總結在上述的三種方法中，屬於資料庫效能優化的主要手段，當然還有很多可以做的細節的優化，例如盡量不要在你要查詢的字段上面允許為空，盡量將聯合查詢的關係控制為number型等等。
對了，如果做了維度表，做了物化試圖，你去查詢原始表的時候速度一定會增加麼？答案是「不」，你要做的乙個重要的事情，就是告訴oracle，它可以主動的優化查詢，語句如下：
alter session set query_rewrite_enabled=true;
alter session set query_rewrite_integrity=trusted;
要把這三個優化的手段寫得很清楚，這麼簡單的幾句話是不可以的。只是讓大家了解乙個專案的資料庫的部署和稍微高階一點的優化方式。
資料倉儲的三種模型
星型模型是我們開發中比較常用一種模型 由一張大的事實表和多個維度表組成 當我們需要查詢的時候 我們可以通過維度表上的某個確定維度進行快速查詢 雪花模型是星型模型的拓展 每乙個維度表都可以向外連線多個詳細類別表 由一張大的事實維度表和維度表和詳細類別表組成，詳細類別表是對事實表的詳細描述 多個事實表共...
資料倉儲三種基礎粒度
資料倉儲三種基礎粒度 事務 定期快照和累計式快照這三種測量型別是用於任務指定事實表的粒度的選項。這三種都是很有用的，並且通常需要最少兩種型別才能得到業務的完整圖景。1 代表空間和時間上某個點的事務粒度。事務粒度的事實表代表著即將發生的原子操作 記錄僅在事務發生時才存在 2 代表不斷重複的有規律時間段...
資料倉儲之三種事實表
在 資料倉儲領域有乙個概念叫transaction fact table，中文一般翻譯為 事務事實表 事務事實表是維度建模的 資料倉儲 中三種基本 型別事實表中的一種，另外兩種分別是週期快照事實表和累積快照事實表。事務事實表與週期快照事實表 累積快照事實表使用相同的一致性維度，但是它們在描述業務事實...