Oracle

      Oracle 傳統的Export與Import依舊被保留到11g，而且9i與10g有很多依舊使用Export與Import方式進行備份與恢複的企業。從Oracle 7.3開始，傳統的exp匯出程式提供兩種的匯出路徑方式，一個是傳統路徑匯出(Conventional Path Export)，一個是直接路徑匯出(Direct Path Export)。本文即是因最近客戶的傳統匯入匯出效能問題對此進行描述。 1、兩者的差異    a、 Conventional path Export  

    最近有網友對Oracle SGA記憶體自動管理特性不是很清楚，可能是由於當時翻譯的 Oracle 10g SGA 的自動化管理 比較生澀，下面依舊是針對這個問題給出在Oracle 10g環境中描述，並給出樣本以便更好的理解。 1、相關參數描述a、參數SHARED_POOL_SIZE SHARED_POOL_SIZE = integer [K | M | G] Default value    If SGA_TARGET is set: If the parameter is not

    Oracle RAC 用戶端容錯移轉(failover)，當採用TAF方式時，對於已經建立串連的用戶端，在串連的執行個體或節點出現故障時，用戶端無需再次發出串連請求，仍然可以繼續之前的資料庫操作，此稱之為透明容錯移轉。本文描述基於Oracle 10g rac，用戶端TAF方式的容錯移轉並給出樣本。  下面是一些關於這方面的基礎參考連結：  有關負監聽配置，載均衡(load balance)以及Oracle service請參考    ORACLE RAC 監聽配置

      最近有網友提到為什麼在dba_hist_sql_plan中無法查看到sql語句的曆史執行計畫，對於這個問題是由於預設情況下，Oracle 設定的闕值並非捕獲所有的sql語句，所以無法看到某些sql曆史執行計畫乃正常現象。在Oracle 9i的時候，我們可以通過設定不同的快照level獲得不同程度的詳細資料。也可以單獨配置收集sql的闕值，如指定sql的執行次數，磁碟讀的次數，解析調用的數量等。所有超出這個設定的sql語句都收集到snapshot之中。Oracle

    Oracle RAC 叢集最突出的表現就是高可用性，這些內容主要包括load balance以及failover，通過這些技術使得單點故障不影響用戶端端應用程式對資料庫的正常訪問，以及通過建立service實現節點間負載平衡。本文主要描述Oracle 10g rac環境下的Oracle failover測試。    下面是一些關於這方面的基礎參考或相關連結：  有關負監聽配置，載均衡(load balance)以及Oracle service請參考    ORACLE RAC 監聽配置

    Oracle RAC中，除了基於用戶端的TAF方式之外，還有基於伺服器端的TAF方式，可以把服務端的TAF方式看作是用戶端TAF方式的一個升級版吧。伺服器端的TAF，當然是需要在伺服器端進行配置了，這個是通過Service來完成的。本文主要描述Oracle 10g rac 下通過service方式設定管理員端的TAF。  下面是一些關於這方面的基礎參考連結：  有關負監聽配置，載均衡(load balance)請參考    ORACLE RAC 監聽配置 (listener.ora

    聚簇因子是 Oracle 統計資訊中在CBO最佳化器模式下用於計算cost的參數之一，決定了當前的SQL語句是否走索引，還是全表掃描以及是否作為嵌套串連外部表格等。如此這般，那到底什麼是聚簇因子，那些情況下會影響到聚簇因子，以及如何提高聚簇因子？本文將對此展開描述。 1、堆表的儲存方式    Oralce

    最近有同事在使用傳統的imp工具匯入資料時，總是提示收到skipping table的提示，也就是表被跳過，而不是被重建。即使是將目標資料庫上的表對象刪除，仍然無法匯入。因此記錄一下，供大家參考。 1、匯入時的skipping table提示oracle@SZDB:~> imp goex_admin/xxx file=sy-trans-20130509-2.DMP log=tmp.log full=y ignore=y show=yImport: Release 10.2.0.3.

    和ROWNUM一樣，ROWID是一個偽列，即是一個非使用者定義的列，而又實際儲存於資料庫之中。每一個表都有一個ROWID列，一個ROWID值用於唯一確定資料庫表中的的一條記錄。因此通過ROWID 方式來訪問資料也是 Oracle 資料庫訪問資料的實現方式之一。一般情況下，ROWID方式的訪問一定以索引訪問或使用者指定ROWID作為先決條件，因為所有的索引訪問方式最終都會轉換為通過ROWID來訪問資料記錄。(註：index full scan 與index fast full

    通常情況下，使用者提交一條SQL語句，總會存在這樣或那樣的等待事件。也就是說由於所需資源被佔用導致進程不得不處於等待狀態。Oracle為我們提供了擷取這些等待事件的可用視圖。根據這些視圖可以得知哪些事件導致該SQL語句效率低下而採取相應的修改或調整。本文基於Oracle 10g描述了如何通過視圖v$session_wait，v$session_event，以及v$system_event去擷取等待事件的相關資訊。 1、等待事件相關參數  timed_statistics   

     Oracle DB_FILE_MULTIBLOCK_READ_COUNT是Oracle比較重要的一個全域性參數，可以影響系統層級及sessioin層級。主要是用於設定最小化表掃描時Oracle一次按順序能夠讀取的資料區塊數。通常情況下，我們看到top events中的等待事件db file scattered read時會考慮到增加該參數的值。但是否增加了DB_FILE_MULTIBLOCK_READ_COUNT的值就一定可以減少db file scattered read?

      在開發環境及UAT環境經常碰到需要清除歸檔日誌的情形，對於這個問題方法有很多。可以直接使用rm方式清除歸檔日誌，也可以使用find命令來尋找合格記錄來清除歸檔日誌，或者直接寫個shell指令碼來搞定。這樣在DEV或者UAT還可以，但是在Prod環境還是建議使用RMAN提供的命令來搞定比較妥當。因為rm，find方式刪除了實際的歸檔日誌也釋放了空間，但對應的儲存在控制檔案中的歸檔資訊並沒有徹底清除。依舊佔用著一些空間未能及時清除而需要控制檔案通過age

   最近在匯出schema層級的資料時被hang住，不得不停止當前的匯出作業，如果你有類似的問題，請繼續往下看。  1、問題描述    匯出整個schema時資料庫被hang住，如下所示    符號">"是由SecureCRT設定的每300秒發送一次    oracle@Dev-DB-04:~> expdp goex_admin/xxx directory=db_dump_dir dumpfile=gobo2.dmp logfile=gobo2.log

    Oracle提供的等待事件檢視使得我們可以擷取指定session以及執行個體層級等待事件的詳細資料，這些視圖分別是v$session_wait，v$session_event，以及v$system_event。然而這幾個視圖對於曆史等待事件無能為力。對此，Oracle也提供了曆史等待事件檢視v$session_wait_history，同時視圖v$session_wait_class，v$system_wait_class也提供了基於等待類別的效能分析，下面是基於Oracle

Oracle 11g RAC安裝時，在第一個節點執行root.sh時遭遇了CRS-0184/PRCR-1070，Google了很多文章也沒有找到解決辦法。嗚嗚，還是靜下心來看日誌！！最後的發現原來是一個不經意的小問題，如下面的描述。 1、故障現象#安裝環境[root@linux1 ~]# more /etc/issueEnterprise Linux Enterprise Linux Server release 5.5 (Carthage)Kernel \r on an

在缺乏的視覺化檢視來監控資料庫效能的情形下，常用的指令碼就派上用場了，下面提供幾個關於Oracle效能相關的指令碼供大家參考。以下指令碼均在Oracle 10g測試通過，Oracle 11g可能要做相應調整。 1、尋找最多BUFFER_GETS開銷的SQL 陳述式--filename: top_sql_by_buffer_gets.sql--Identify heavy SQL (Get the SQL with heavy BUFFER_GETS)SET LINESIZE 190COL

      通常情況下，在Oracle RAC

    Oracle

      如果在Oracle 11g RAC環境下使用dbca建立單一實例資料庫後，Oracle會自動將其註冊到預設的1521連接埠及監聽器。大多數情況下我們使用的為非預設監聽器以及非預設的監聽連接埠。而且在Oracle 11g RAC環境中，對於叢集監聽器的配置由grid使用者來接管了。基於這種情形的單一實例非預設監聽及連接埠該如何配置呢？本文給出瞭解決方案，並且使用了靜態及動態兩種註冊方法。           

      Oracle Data Guard邏輯備庫是利用主庫的一個備份首先建立一個物理備庫，然後再將其轉換為邏輯備庫。這之後主庫將日誌傳遞到備庫，備庫利用logminer從主庫的日誌中解析出主庫所執行過的SQL，在備庫上重新執行一遍，從而保證與主庫的資料在邏輯上保持一致。與物理備庫相對應的是，物理備庫使用的是redo apply，邏輯備庫使用的是sql