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

普通堆表不足之處：

    表更新有日志開銷

    表刪除有瑕疵

    表記錄太大檢索較慢

    索引回表讀開銷很大

    有序插入難有序讀出

 

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/bdump

ls -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為止。