oracle11g分割槽中的兩大陷阱
1.個別場景不能從根本上提高查詢速度
在Oracle10g時不支援自動生成分割槽，技術人員都是手動建立一年或者半年的分割槽或者當超過限制時把資料都load到最大值分割槽，但是一年半年過後要麼出現數據無法插入或者某個分割槽資料劇增，這個時候出現了Oracle11g的自動分割槽功能，但是自動分割槽名稱不能人為設定。如果說資料量過大或者出現跨分割槽查詢會出現效能問題。
舉個栗子：線上有一個日誌儲存系統，每天大概儲存1000W左右的資料，支援分頁排序並且按照日期查詢功能（如果不排序，這個資料量對於Oracle是小ks）於是我們採用了分割槽+覆蓋索引（如果想進一步瞭解.....）查詢的的功能，效能稍微提升。但是一段時間後發現還是拖死系統。(因為這就是CAP問題，想從根本上解決問題，請建議公司採用nosql（habase、ELK）實現)。
如果有這樣一種這樣場景，工資小於等於5000，大於5000並且小於等於12000，大於12000並且小於25000，大於等於25000分別按照這些工資級別建立分割槽則非常高效，因為可以指定分割槽進行查詢（
select * from TBL_OPR_CNT partition(5000_part);），因為指定分割槽查詢，效率直接提升。
由此得知，關係資料庫效率高低，在於我們如何發揮它的長處。
2. 手動對錶進行move操作，或者刪除表分割槽會導致索引失效
在實際線上環境，常常當發現效能出現問題時，這個時候才採取分割槽的解決方案，但是分割槽表一般都是全域性索引，然後直接在原表採取分割槽功能，用了一段時間產生了歷史分割槽資料，然後刪除了其中一部分歷史分割槽，發現數據無法插入了。如下錯誤：
jdbc.exception.UncategorizedSQLException: uncategorized SQLException for SQL [insert into AUDITS(C_ID,N_PERSON_ID,C_NAME,C_CODE,C_DEPT,N_LOG_TIME,C_LOG_TYPE,C_CONTENT,C_RESULT,C_SN,N_DEPT_ID) values(?,?,?,?,?,?,?,?,?,?,?)]; SQL state [72000]; error code [1502]; ORA-01502: index 'AUDITS_PK' or partition of such index is in unusable state ; caused by: ORA-01502: index 'AUDITS_PK' or partition of such index is in unusable state
採取如下方法重建索引解決處理。
select index_name,index_type,tablespace_name,table_type,status from user_indexes where index_name='AUDITS_PK';
alter session set skip_unusable_indexes=false;
alter index AUDITS_PK rebuild;
commit;
3.其出現這個問題的根本原因和解決方法是什麼呢？
移動或者刪除表空間或者分割槽後，基於該table的索引會自動失效UNUSABLE；此時訪問或操作該table時，會報ORA-01502異常；無論唯一還是普通索引都要通過重建解決。
解決方法：在使用表分割槽時儘量建立本地索引.( 例如：
create index AUDITS_PK on AUDITS(id) local;--因為id是分割槽鍵，所以這樣就建立了一個有字首的本地索引) 這樣在刪除分割槽後則索引不會出現失效