關於ORACLE的一點總結

[每天進步一點點]關於RAC心跳線：1、心跳線的作用是用來同步例項1和例項2之間資料的；2、故障點轉移；3、負載均衡，兩個節點同時工作。在RMAN備份時，在例項1分配一個通道，另一個通道分配在例項2上，兩個節點同時工作，速度更快。




[每天進步一點點]在RAC中，我們有時會看到一個例項不工作了，那很可能就是心跳線斷了。在ORACLE RAC中，如果心跳線斷了，這樣兩邊節點的資料就不同步了，這時候只能有一個例項工作，另一個例項必須關閉，以保持資料的唯一性。他們是透過搶表決盤（個數為單數）來決定誰工作的，誰搶到誰工作，另一個就自動關閉了。


[每天進步一點點]對於RAC結構，還是使用業務分割的方式為好，這樣某個業務固定地使用某個例項，它訪問的資料塊就固定地存在於某個例項的記憶體中，這樣例項之間的GC等待事件（Global Cache RAC例項間的記憶體資料塊等待）就會大幅度降低，有助於提供SQL的執行效率。如果RAC結構使用的是負載均衡的模式，這樣每個例項都會被各種應用的會話連線，大量的資料塊需要在各個例項的記憶體中被複製或者鎖定，這樣就產生了大量的GC等待事件。


[每天進步一點點]1、對於RAC結構，我們需要分析每一個例項的AWR報告，才能對資料庫的效能做出一個客觀的評價。2、RAC環境中，動態效能檢視以GV$開頭，能看到例項1和例項2合在一起的結果，所以有時會看到重複的結果集；3、v$是看單例項自己的；4、OCR是叢集登錄檔，相當於叢集的引數檔案，如果OCR壞了，叢集就起不起來了；5、在單例項中，tnsname.ora裡面的service_name就等於DBNAME,但是在RAC裡面，可以把instance1和instance2起個名字叫service_name=s1，那麼客戶端在tnsname.ora裡面連線時直接寫service_name=s1，就表示連線的是instance1和instance2，從而實現了負載均衡和故障轉移。（首先失效，轉移到可用節點）；6作業系統叫卷組，oracle叫asm磁碟組；在RAC中，引數檔案在instance1和instance2中都有，裡面為pfile=引到共享儲存；7、oracle 10g用raw和檔案系統，oracle 11g用檔案系統和asm磁碟組，不支援raw；8、oracle 10g OCR和表決盤不能放共享儲存，oracle 11g可以放共享儲存。




[每天進步一點點]在一個AWR報告中，其實效能問題可能只是由一個原因引起的，比如說是磁碟I/O能力不夠，在AWR報告的各個部分都會向我們呈現出由這個效能問題所引起的屬於它覆蓋範疇的問題，即一個原因引起很多的表象，當我們從這這個部分一時確定不了問題時，可能從另外一部分的效能資料中就找到了問題出現的原因。這也說明了AWR報告完全不需要順序地從頭讀到尾，不論從哪個部分，只要找到了問題的起因，這個AWR報告就算是讀完了，完全沒有必要每個部分都讀一遍，那樣只能讓自己的思路更加混亂。




[每天進步一點點]關於最佳化的一點思路：在AWR報告中，最重要的部分是TOP 5 Time Event 部分，這個部分必看，如果這一部分顯示前五位等待時間一共也沒有等待多長時間（比如第一位的等待時間在1個小時的採集週期中才發生了幾分鐘的等待），那麼我覺得這個AWR報告就沒有必要再看下去了，因為看起來系統的狀態非常好，幾乎沒有太長的等待操作，所以不需要做效能上的最佳化。另外，對於OLTP系統，如果有長時間的等待，那麼必須引起注意，找到到原因。但是對於OLAP系統，產生這麼長時間的等待也並不一定就是SQL效能上有了問題，因為在OLAP資料庫中，本身就執行著一些執行時間非常長的SQL，他們要掃描很多的資料塊或者索引塊，因此產生等待是合理的，對於這個awr報告來說，我們只能知道有一些SQL執行的時間比較長，至於這些SQL是否真的還有最佳化的餘地，我們需要將SQL語句找到，透過檢視他們的執行計劃（如sql_trace或10046事件或set autot trace exp stat）,結合SQL中引用的表的分析情況，來斷定他的執行計劃是否是最優的。如果經過判定這些SQL的執行計劃都是最優的，那麼這個等待的時間在資料庫層面是合理的。如果這個等待時間使用者依然無法忍受，那就需要從業務級別來做修改了，比如重寫SQL，重新規劃資料庫等。




[每天進步一點點]在oracle RAC中，重要的核心技術是快取融合。快取融合是指把兩個機器例項的記憶體當做一個記憶體來管理。我們知道，在oracle 單例項中，SGA裡有一個列表，它對應著buffer cache有哪些髒資料塊，如果客戶端發出一條SQL語句，但buffer cache裡面沒有該對應的髒資料塊，那麼DB就需要到磁碟中讀取資料檔案來查詢該資料塊。那麼在RAC中是怎麼處理的呢？在RAC中，透過心跳線，兩個機器的SGA的髒資料塊列表都更新，互相同步對方的髒資料塊列表，這樣，例項1的髒資料塊列表就有例項2的髒資料塊資訊，假如我在例項1上做了一條update，但是髒資料塊在例項2上，那麼就把例項2的髒資料塊同步到例項1上，這樣例項1就不用在去磁碟尋找資料塊了，減少了磁碟I/O，這就是RAC的快取融合技術。對於這項技術，據瞭解，其他任何一個資料庫都沒有該技術，可以說也是區別於其他資料庫的一項重要技術。




[每日一得]對於DG,STANDBY_FILE_MANAGEMENT 用來控制是否自動將 Primary資料庫增加表空間或資料檔案的改動，傳播到物理 Standby 資料庫。AUTO自動，MANUAL手動，預設是手動。如果 Primary 資料庫重新命名了一個或多個資料檔案，該項修改並不會自動傳播到 Standby 資料庫，只能手工操作。DG原來也不智慧。




著名的Oracle技術專家Tom Kyte在他的論壇（asktom.oracle.com)裡曾經就STATSPACK說過這樣一句話：“沒人教過我怎麼看statspack報告，我自己也沒有學過，但我拿過一份statspack的報告，就可以很容易地看懂它，因為我已經掌握了這些知識，我知道Oracle是如何工作的”。






[每天進步一點點]a、ASH報告是AWR報告的一部分，它側重於當前資料中活動會話的資訊分析，當我們使用$ORACLE_HOME/rdbms/admin/ashrpt.sql指令碼生成了一個ASH報告後，對報告進行分析，發現一些相關的效能問題，比如我們發現某個會話的活動非常頻繁，或者某個程式可能有效能問題，這時候就可以使用ashrpti.sql指令碼來特別針對這些需要分析的物件生成ASH效能分析報告，這樣就可以將分析的範圍縮小很多，更有利於對問題的定位。
b、在AWR報告中，我們需要客觀地對待這些效能指標，不要覺得有些地方稍微有些效能問題，就把問題擴大化，只要使用者能夠忍系統的效能，就沒有理由去主動地最佳化它，畢竟系統的穩定性是第一位的。
c、AWR和ASH報告的使用場景：當我們需要對資料庫系統做整體效能評估時，需要分析AWR效能報告；當我們需要對一些活動的會話或者歷史的會話做分析時，使用ASH更加方便，這樣可以排除很多不需要的資訊干擾，更容易定位到問題所在。




CBO模式的選擇：對於一個OLAP系統，資料庫上執行著的基本都是報表作業，執行的基本是聚合類SQL操作，比如group by，這時候CBO設定成all_rows是恰當的。但如果這個OLAP系統上面設定成all_rows模式後，該資料庫還執行著一些使用者分頁查詢的業務，那麼使用者一般會抱怨查詢慢，針對這種情況，開發人員可以在開發階段針對分頁操作的SQL透過Hint的方式將最佳化模式轉為first_rows，這樣就會大大提高資料的處理速度，比如/*+ first_rows(10) */




關於表分割槽的最佳化：1、當查詢的範圍正好落在某個分割槽的時候，這時候分割槽的效率自然是高於沒有分割槽的；2、但當查詢的範圍跨越幾個分割槽時，這時候分割槽可能不是最優的。比如我們把查詢的範圍擴大到分割槽表的13個分割槽，讓CBO使用index_ffs的方式掃描，我們建立另一張非分割槽表，表結構和上述分割槽表一樣，並且讓CBO強制使用index_ffs的方式訪問非分割槽表上的全域性索引，結果發現，使用分割槽索引比全域性索引慢很多。為什麼呢，分割槽索引之所以掃描了更多的資料塊，是因為分割槽索引在做index_ffs時只能在本地索引上進行，如果涉及其他的分割槽，還要按照訪問索引的方式去訪問其他索引，比如先找到分割槽索引的根資料塊，再找到最左邊的葉塊，然後執行index_ffs操作，這樣，查詢跨過的分割槽越多，這種額外代價就越大；而在這種情況下，全域性索引只需要定位到一個葉塊，然後執行一次index_ffs就能掃描所有的索引葉塊，這樣，全域性索引的效能就好於分割槽索引^_^。




當Golden Gate關閉時，還能透過info eorakk, showch看到recovery checkpoint 中scn的資訊，說明recovery checkpoint中的scn資訊是寫在磁碟checkpoint檔案上的。ls -lSr，檔案按照從小到大的順序排序；ls -ltr按時間排序；歸檔日誌是聯機日誌檔案的複製;




對於熱塊，可能是資料塊，也可能是回滾段塊。對於資料塊來講，通常是資料塊上的資料分佈不均勻導致，如果是索引的資料塊，可以透過建立反向索引來達到重新分佈資料的目的；對於回滾段資料塊，可以適當多增加幾個回滾段來避免這種爭用。




1、在開發階段，可以透過模擬一些實際的數量來估算索引和表資料的一個比例，然後做出索引所佔空間和表所佔空間的比例：
select avg_row_len from user_tables where table_name='T';


AVG_ROW_LEN
-----------
         93
表的容量：93*N（記錄數）
select segMENt_name,SEGMENT_type,bytes,owner from dba_segments where segment_name in ('T','IND_T_OBJECT_ID');






2、系統如果平時執行正常，突然停止不動了，多半是被阻止blocked住了，我通常做的第一個動作就是先看v$lock這張檢視：
QL> select sid,type,id1,id2,lmode,request,block from v$lock where sid in (143,156);


       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       156 TX     458761        525          0          6          0
       143 TM      53345          0          3          0          0
       156 TM      53345          0          3          0          0
       143 TX     458761        525          6          0          1


上圖中，產生了TX事務鎖（TX叫行鎖是誤導）的阻塞


TX，oracle資料庫並不會對某個表加上鎖或者某幾行加上鎖，鎖是以一個資料塊的屬性存在的。每個資料塊本身就儲存著自己資料塊中資料的資訊，這個地方叫ITL（interested transaction list），凡是在這個資料塊上有活動的事務，他的資訊就會記錄在這裡面供後續操作查詢，以保證事務的一致性。
TX鎖應該是一個事務鎖（稱它為行級鎖是誤導），無論這個事務做了多少操作，都只是這一個事務鎖，和他所操作的資料多少沒有關係。
什麼時候會產生TX事務鎖呢？1、對資料進行update修改的時候；2、只要需要維護事務一致性的時候，就會用到TX事務鎖，比如透過DBLINK在幾個資料庫之間處理資料時，就需要TX事務鎖倆維護事務的一致性。


上圖中，TM是表級的共享鎖，就是說每個使用者都可以以共享的方式持有它。TM鎖也並不是加在表上的一個鎖，他會在表的級別上產生影響，比如它不允許其他使用者對錶鎖DDL操作。
再重複一遍，oracle中的鎖的資訊是資料塊的一個屬性，是物理的，並不是邏輯上屬於某個表或者某個行。


可以透過v$session檢視就可以這兩個sid的使用者登陸資訊；
QL> select machine from v$session where sid in (156,146);


MACHINE
----------------------------------------------------------------
localhost.localdomain
localhost.localdomain


上述過程之能是一個故障定位，不能說是一個效能最佳化。


##################################


SQL> select sid,type,id1,id2,lmode,request,block from v$lock where sid in (143,156);


       SID TY        ID1        ID2      LMODE    REQUEST      BLOCK
---------- -- ---------- ---------- ---------- ---------- ----------
       143 TM      53347          0          3          0          0
       143 TM      53348          0          3          0          0
       143 TX     458775        525          6          0          0


SQL> select object_name,subobject_name from dba_objects where object_id in (53347,53348);


OBJECT_NAME     SUBOBJECT_NAME
--------------- ------------------------------
T
T          P1


透過上圖中，可以看出，對於TM，id1列其實就是dba_object裡面的object_id，可以是一個表，也可以是一個分割槽，此時的ID2一般為0。
而在TX事務鎖中，ID1和ID2這兩個欄位構成了這個事務在回滾段中的位置。這有什麼作用呢，他的用途是，當其他的操作需要讀取這個資料塊時，他會發現這個塊上要讀取的資料上是有活動事務的，因此需要到回滾段中去找它之前的內容的，那麼這些內容在回滾段中的什麼地方呢，這兩個值告訴你。






當你的系統有主鍵和外來鍵引用關係時，如下三種情況就需要考慮給外來鍵欄位建立索引，主鍵已經預設建立索引了。
1、主鍵上有頻繁的刪除操作；2、主鍵上有頻繁的修改操作；3、業務上經常會出現主表和從表做關聯查詢的情況。






三個簡單卻很有意義的公式：
① 開會+ 不落實 = 零
② 佈置工作 + 不檢查 = 零
③ 抓住不落實的事 + 追究不落實的人 = 落實