【面試虐菜】—— Oracle知識整理《收穫，不止Oracle》

標籤：style   blog   color   io   os   使用   ar   strong   檔案   

普通堆表不足之處：

    表更新有日誌開銷    表刪除有瑕疵    表記錄太大檢索較慢    索引回表讀開銷很大    有序插入難有序讀出  DELETE產生的undo最多，redo也最多，因為undo也需要redo保護  全域暫存資料表：1 高效刪除記錄　　基於事務的全域暫存資料表commit或者session串連退出後，自動刪除　　基於回話的全域暫存資料表在退出回話後自動刪除 2 針對不同的會話資料獨立，不同的session訪問全域暫存資料表，看到的結果不同 全域暫存資料表在程式的一次調用執行過程中，需要多次清空記錄再插入記錄，就考慮使用基於是無敵額  分區表

--分區表刪除alter table range_part_tab truncate partition p9; --分區表交換alter table range_part_tab exchange partition p9 with table mid_table; --分區表的分割alter table range_part_tab split partition p_max at(to_date(‘2013-02-01‘,‘YYYY-MM-DD‘))into (partition p2013_01,partition p_max); --分區表合并alter table range_part_table merge partitions p2013_01,p_max into partition p_max;

 SCN，保證資料一致讀，解決了讀一致性的問題，避免使用鎖   Oracle開啟與關閉過程1 startup nomount 尋找定位 參數檔案(SGA共用記憶體段開啟，後台進程開啟)2 alter database mount 尋找定位 控制檔案（其中包含 資料檔案 記錄檔 檢查點資訊等）3 alter database open 尋找定位 資料檔案 記錄檔等  關閉正好是開啟的逆過程：全部命令融合在shutdown immediate裡面database closed.database dismounted.oracle instance shut down. 各檔案尋找位置：show parameter spfile;show parameter control; sqlplus "/ as sysdba"select file_name from dba_data_files;select group#,member from v$logfile;show parameter recovery;setlinesize 1000;show parameter dump; cd /home/oracle/admin/itmtest/bdumpls -lart alert* OLTP傾向於讓塊的尺寸小一些：因為如果塊太大，容易導致大量並發查詢及更新操作都指向同一個資料區塊，從而產生熱點塊競爭。 Leaf 主要儲存了 key column value 以及 具體能定位到資料區塊所在位置的rowid  索引特點：    高度比較低    儲存索引列還有rowid    本身是有序的 MIN MAX的索引最佳化：INDEX FULL SCAN(MIN\MAX)

    select max(object_id) from t;    select max,min from (select max(object_id) max from t) a,(select min(object_id) min from t) b;

 

索引回表讀（TABLE ACCESS BY INDEX ROWID）如

select * from t where object_id <=5;

因為是select * 查詢完索引列後，還需要返回查詢其他全部的值 INDEX RANGE SCAN 針對索引高度較低這個特性實現的一種範圍掃描，在返回記錄很少時相當高效。 INDEX FAST FULL SCAN 針對整個索引的全掃描，一次讀取多個索引塊INDEX FULL SCAN 針對整個索引的全掃描，一次讀取一個索引塊，有利於資料的排序，在count*的場合很適用，但是邏輯讀增加了 

Union，對兩個結果集進行並集操作，不包括重複行，同時進行預設規則的排序；

Union All，對兩個結果集進行並集操作，包括重複行，不進行排序；

 

主外鍵：

    1 主鍵本身是一種索引

    2 可以保證表中主鍵所在列的唯一性

    3 可以有效限制外鍵依賴的表的記錄的完整性

 

如果某個表建立的索引過多，插入資料的時候會很慢。可以刪除索引後，插入，再建立索引。可以最佳化很大一部分的時間。

 

索引過多，對三種操作的影響：

1 對insert影響最大，只要有索引，就會變慢，越多越慢。

2 對delete來說，有好有壞，在海量資料刪除較少資料的時候，很有用。但是過多的索引，也會使得其他的索引進行更新時代價變大。

3 對update的影響最小。

 

建立索引會引起整個表的鎖，使得表被掛起，任何操作無法執行。

 

alter index 索引名 monitoring usage;

select * from v$object_usage；--查詢索引是否被使用alter index 索引名 nomonitoring usage;--解鎖索引監控

 

位元影像索引允許儲存為空白值（缺點，進行插入的時候，同一個索引的值相同，是插不進去的）

 

建立位元影像索引適合的兩個條件：1 位元影像索引列大量重複 2 該表極少更新

 

為什麼位元影像索引只適用於低基數值，但是對頻繁更新的列不適用。
原因在於，PROCESSED_FLAG列只有兩個值：Y和N。對於插入到表中的記錄，該列值為N（表示未處理）。其他進程讀取和處理這個記錄時，就會把該列值從N更新為Y。這些進程要很快地找出PROCESSED_FLAG列值為N的記錄，所以開發人員知道，應該對這個列建立索引。他們在別處瞭解到，位元影像索引適用於低基數（low-cardinality）列，所謂低基數列就是指這個列只有很少的可取值，所以看上去位元影像索引是一個很自然的選擇。
不過，所有問題的根由正是這個位元影像索引。採用位元影像索引，一個鍵指向多行，可能數以百計甚至更多。如果更新一個位元影像索引鍵，那麼這個鍵指向的數百條記錄會與你實際更新的那一行一同被有效地鎖定。
所以，如果有人插入一條新記錄（PROCESSED_FLAG列值為N），就會鎖定位元影像索引中的N鍵，而這會有效地同時鎖定另外數百條PROCESSED_FLAG列值為N的記錄（以下記作N記錄）。此時，想要讀這個表並處理記錄的進程就無法將N記錄修改為Y記錄（已處理的記錄）。原因是，要想把這個列從N更新為Y，需要鎖定同一個位元影像索引鍵。實際上，想在這個表中插入新記錄的其他會話也會阻塞，因為它們同樣想對這個位元影像索引鍵鎖定。簡單地講，開發人員實現了這樣一組結構，它一次最多隻允許一個人插入或更新！
可以用一個簡單的例子說明這種情況。在此，使用兩個會話來展示阻塞很容易發生：

ORA10G> create table t ( processed_flag varchar2(1) );Table created.ORA10G> create bitmap index t_idx on t(processed_flag);Index created.ORA10G> insert into t values ( ‘N‘ );1 row created.

現在，如果在另一個SQL*Plus會話中執行以下命令：

ORA10G> insert into t values ( ‘N‘ );

這條語句就會“掛起”，直到在第一個阻塞會話中發出COMMIT為止。

【面試虐菜】—— Oracle知識整理《收穫，不止Oracle》