Oracle數(shù)據(jù)庫優(yōu)化思路和9個典型問題分別是什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

成都創(chuàng)新互聯(lián)公司是一家專業(yè)的成都網(wǎng)站建設公司，我們專注網(wǎng)站建設、成都網(wǎng)站制作、網(wǎng)絡營銷、企業(yè)網(wǎng)站建設，賣鏈接，一元廣告為企業(yè)客戶提供一站式建站解決方案，能帶給客戶新的互聯(lián)網(wǎng)理念。從網(wǎng)站結構的規(guī)劃UI設計到用戶體驗提高，創(chuàng)新互聯(lián)力求做到盡善盡美。

       系統(tǒng)上線前，對于基礎架構的技術審核可能需要伴隨一系列整改和優(yōu)化，其中數(shù)據(jù)庫層面的整改和優(yōu)化是最重要的一項。

1.安裝時（文檔 ID 1525820.1）

其實Oracle官方對于Oracle的通用最佳實踐提供的非常詳細，針對不同平臺、針對不同版本、針對不同用途等都會有相應一套實施的最佳實踐。

例如：

1）RAC 和 Oracle Clusterware 最佳實踐和初學者指南（平臺無關部分）
Document 810394.1 

RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent)

2）特定平臺的詳細最佳實踐

Document 811306.1 

RAC and Oracle Clusterware Best Practices and Starter Kit (Linux)

3）操作系統(tǒng)配置注意事項

4）虛擬化注意事項

5）存儲注意事項

6）網(wǎng)絡注意事項

7）特定硬件注意事項

2.測試及系統(tǒng)上線之前

這個過程當中，根據(jù)特定的應用場合及測試結果以及我們對數(shù)據(jù)庫理解的不同可能會產(chǎn)生一些以行業(yè)背景為區(qū)分的行業(yè)經(jīng)驗及行業(yè)實踐。

典型問題：

1）關于重做日志的配置優(yōu)化應該做哪些點？應該如何做？

首先、接觸過數(shù)據(jù)庫的人相信對這個概念都不陌生。數(shù)據(jù)庫在做SQL更新的時候，首先要將事務執(zhí)行過程記入重做日志當中，然后才會把日志刷入磁盤，將數(shù)據(jù)更新持久化。一條數(shù)據(jù)提交之后成功的標準時日志落到磁盤，而不是真正的數(shù)據(jù)落盤。因此日志的配置（大小、數(shù)量）直接決定著數(shù)據(jù)庫讀寫的性能，如果日志大小非常大，那么會造成歸檔切換時間非常長，一旦這時候發(fā)生了不可恢復的DB災難，那么通過備份恢復的數(shù)據(jù)流失量或者說RPO就會較大。日志大小非常小的話，勢必會造成日志頻繁切換，AWR里面有大量的日志切換事件，這樣對數(shù)據(jù)庫的性能會有較大影響。因此根據(jù)性能測試的AWR報告中日志切換的等待事件、和切換頻度來決定其數(shù)據(jù)量和大小是否需要調整。一般的OLTP建議（10組、500M）。

接著，我們還需要考慮與其相關的參數(shù)設置。

比如說“_use_adaptive_log_file_sync”，它直接決定了日志落盤的方式，對于日志緩沖區(qū)的數(shù)據(jù)落盤的方式，11g增加一種新的方式就是polling的方式，傳統(tǒng)方式是post/wait方式。oracle底層自動判斷何時用何種方法來完成lgwr進程的寫任務。對于post/wait方式來講，客戶端做了commit之后，需要等待事件完成。oracle一旦完成會通知用戶進程，用戶進程立刻感知。但是這一通知post，會耗費大量CPU資源。polling是oracle前臺進程啟動檢查任務，自動檢查后臺lgwr寫入情況，耗費CPU資源比較少，但是用戶進程并不一定能立刻感知。所以兩種方法各有千秋。但是關鍵是后臺實現(xiàn)兩種方法切換的時候要耗費系統(tǒng)性能，尤其在繁忙的時候頻繁切換的話反而會導致數(shù)據(jù)庫性能下降。awr出現(xiàn)大量‘Log file sync’。Bug 13707904。

比如說“archive_lag_target”，它決定了我們是否開啟日志強制切換功能，為了減少故障時數(shù)據(jù)損失，可以設置ARCHIVE_LAG_TARGET參數(shù)，強制進行日志切換。這個參數(shù)的缺省值是0，即為不啟用該參數(shù)。建議設置值為1800。

2）關于ORACLE的內存管理應該關注那些點？應該如何配置？

首先，ORACLE通用的兩種內存管理方式AMM&ASMM，從Oracle 11g開始，ORACLE默認使用AMM(自動內存管理)，即讓數(shù)據(jù)庫完全管理SGA、PGA的大小，而對于管理員只需要設置一個總的大?。╩emory_target），數(shù)據(jù)庫會動態(tài)的調整SGA、PGA的大小以及其中包含的各個組件大小，如Database buffer cache、Shared pool等。這個特性設計的初衷是好的，它希望避免不正確的SGA和PGA設置導致的內存使用不平衡的性能問題。但是在實際應用過程中，這個特性是不是一定非常出色呢？AMM中在數(shù)據(jù)庫啟動是會有一個固定比例來分配SGA/PGA 大?。簊ga_target =memory_target *60% 
pga_aggregate_target=memory_target *40%。

但是在并發(fā)較高，數(shù)據(jù)庫非常繁忙的場合下，自動內存調整的速度很可能趕不上大量會話對內存的請求的速度。另外當PGA隨著會話不斷增加而需求量猛增的情況下，它會首先搶占SGA，導致數(shù)據(jù)庫性能故障。在高并發(fā)的數(shù)據(jù)庫場景中并不建議使用AMM。采用10g更為成熟的自動共享內存管理(ASMM)和自動PGA管理。手動調整內存參數(shù)，具體可以參照以下：

//關閉內存自動管理

memory_target=0

memory_max_target=0

//設置SGA為固定值，可以根據(jù)性能測試中的AWR報告中的建議

sga_max_size=XG

sga_target=XG

//設置PGA等參數(shù)

pga_aggregate_target=XG

large_pool_size=256M

另外很重要的一個參數(shù)，“_shared_pool_reserved_pct”，如果這個參數(shù)設置小了，很可能導致ORA04031，TROUBLESHOOTING ORA-4031 - Simple Guide and Basic Approach to Solve the issue (文檔 ID 1416817.1)

3）關于Linux系統(tǒng)下的大頁配置？

在 Linux 環(huán)境中實施 HugePage 能夠極大地提高內核性能。對于內存較大的系統(tǒng)，效果尤其明顯。一般而言，系統(tǒng)中的 RAM 越大，系統(tǒng)啟用 Hugepage 后獲得的好處也越大。這是因為內核為映射和維護內存頁表所要做的工作量會隨著系統(tǒng)內存的增大而增加。啟用 Hugepage 能夠顯著地降低內核要管理的頁面數(shù)，而且能提高系統(tǒng)的效率。經(jīng)驗表明，如果未啟用 Hugepage，內核擠占關鍵的 Oracle Clusterware 或 Real Application Clusters 守護進程的情況會很常見，而這會導致實例或節(jié)點驅逐出現(xiàn)。具體配置方法可以參照：HugePages on Linux: What It Is... and What It Is Not... (文檔 ID 361323.1)

4）關于SQL解析相關的參數(shù)優(yōu)化？

首先、在Oracle中每條SQL語在執(zhí)行之前都需要經(jīng)過解析，這里面又分為軟解析和硬解析。在Oracle中存在兩種類型的SQL語句，一類為 DDL語句(數(shù)據(jù)定義語言)，他們是從來不會共享使用的，也就是每次執(zhí)行都需要進行硬解析。還有一類就是DML語句(數(shù)據(jù)操縱語言)，他們會根據(jù)情況選擇要么進行硬解析，要么進行軟解析。

一般我們希望我們的AWR報告中硬解析偏少，而軟解析偏多。因為硬解析的代價會非常高。為了減少帶綁定變量的sql的解析時間，oracle 9i引入的綁定變量窺測的功能。也就是在同一個SQL的變量被賦于不同值時采用同一個游標，這樣雖然節(jié)省了sql的解析時間。大家有沒有通過功能的打開或者關閉實際觀察過AWR中的軟硬解析數(shù)目的實際狀況呢？其實對于綁定變量窺測這個特性以及后來的自適應游標等特性，都是oracle為了找到最優(yōu)執(zhí)行計劃而啟用的一些新特性，但是在實際應用過程中，對于不同量級不同特性的業(yè)務場景也曾經(jīng)因此出現(xiàn)了很多bug。

understanding and Diagnosing ORA-00600 [12333] / ORA-3137 [12333] Errors (ID 389713.1)

根據(jù)自己的業(yè)務系統(tǒng)特點，做大量的性能測試和業(yè)務測試，根據(jù)參數(shù)的關閉打開對比awr報告當中顯示出的軟硬解析比率以及執(zhí)行計劃數(shù)據(jù)決定是否打開或者關系相應功能特性。如下參數(shù)：

"_optim_peek_user_binds"

"_optimizer_adaptive_cursor_sharing"

"_optimizer_extended_cursor_sharing"

"_optimizer_extended_cursor_sharing_rel"

"_optimizer_use_feedback"

接著，與之相關的幾個參數(shù)：open_cursors、session_cached_cursors 這兩個參數(shù)決定著應用會話可以控制打開以及緩存的游標數(shù)量，如果數(shù)量不足，就會引起SQL解析的性能問題。這兩個參數(shù)要根據(jù)v$resource_limit視圖中的值的情況進行調整，避免資源設置不合理導致的性能問題。

還有，與執(zhí)行解析執(zhí)行計劃相關的幾個參數(shù)，_b_tree_bitmap_plans、有時將B-Tree索引進行BITMAP轉換來進行SQL執(zhí)行，往往會生成極其惡劣的執(zhí)行計劃，導致CPU100%。

Select Fails With ORA-600 [20022] (文檔 ID 1202646.1)

建議可以關掉。

5）如何避免數(shù)據(jù)庫集群節(jié)點之間的激烈競爭？

數(shù)據(jù)庫節(jié)點之間的競爭有很多，包括鎖（各種粒度鎖）的競爭以及數(shù)據(jù)的傳輸?shù)取Ｍ耆苊飧偁幠蔷褪チ薘AC的意義了，RAC本身就是希望能在兩個節(jié)點并行執(zhí)行任務。

如果特別極致的并行一定引起嚴重的性能問題，如果完全禁止，既無法做到又失去了集群本來的意義。所以我們只能在一定程度上去平衡：

首先、關于DRM，oracle的DRM特性從理論上來看，它是為了避免節(jié)點間的數(shù)據(jù)量傳輸，避免節(jié)點間的鎖等待事件頻繁發(fā)生。DRM的極致是做到請求節(jié)點和Master節(jié)點統(tǒng)一化。但是實踐中，這個特性引起了很多的BUG、反而導致了節(jié)點間的競爭出現(xiàn)了性能故障。Bug 6018125 - Instance crash during dynamic remastering or instance reconfiguration (Doc ID 6018125.8)。所以建議關閉。

接著、關于參數(shù)“parallel_force_local”，ORACLE RAC為了實現(xiàn)多節(jié)點并行處理是花費了很大代價的，假設一個集群當中有三個節(jié)點，對于某一個數(shù)據(jù)塊兒讀寫，有一個Master、有一個請求者、有一個擁有者，請求者向Master請求數(shù)據(jù)塊兒的最新版本，Master把請求轉發(fā)給擁有者，擁有者按照請求信息把數(shù)據(jù)塊兒傳送給申請者，然后加鎖進行讀寫。這一過程是需要有大量的數(shù)據(jù)傳輸和競爭存在的，一旦這個事情成為多數(shù)，那么勢必造成節(jié)點間的通訊負載過大，造成大量的鎖等待時間，嚴重影響數(shù)據(jù)庫整體性能。尤其是在做跨數(shù)據(jù)中心高可用的場合下。因此我們只要做到業(yè)務級別的并發(fā)處理，而不要追求一個SQL級別的絕對并發(fā)。物極必反的道理就在于此。因此把參數(shù)打開，使得進程級別并發(fā)實現(xiàn)本地化處理，不要跨節(jié)點處理。在官方文檔 ID 1536272.1當中，必須優(yōu)化的參數(shù)就包括這個。

6）關于數(shù)據(jù)庫的自動任務？

Oracle 11g 數(shù)據(jù)庫有三個預定義自動維護任務：

Automatic Optimizer Statistics Collection（自動優(yōu)化器統(tǒng)計信息收集）：

收集數(shù)據(jù)庫中所有無統(tǒng)計信息或僅有過時統(tǒng)計信息的 Schema 對象的 Optimizer（優(yōu)化器）統(tǒng)計信息。QL query optimizer（SQL 查詢優(yōu)化器）使用此任務收集的統(tǒng)計信息提高 SQL 執(zhí)行的性能。

Automatic Segment Advisor（自動段指導）：

識別有可用回收空間的段，并提出如何消除這些段中的碎片的建議。您也可以手動運行 Segment Advisor 獲取更多最新建議，或獲取 Automatic Segment Advisor 沒有檢查到的那些有可能做空間回收的段的建議。

Automatic SQL Tuning Advisor（自動 SQL 優(yōu)化指導）：檢查高負載 SQL 語句的性能，并提出如何優(yōu)化這些語句的建議。您可以配置此指導，自動應用建議的SQL profile。

關于統(tǒng)計信息收集，數(shù)據(jù)庫是有其自己的默認啟動時間，11g是在22:00-2:00之間，假設這個時間跟我們的跑批時間有沖突的話，我們可以修改器具體執(zhí)行時間。但是這個任務必須保留。

關于其他的兩個優(yōu)化指導，其實要看我們實際工作中用到的幾率是否很高，是否有價值留著給我們提供一些優(yōu)化的理論指導。一般感覺用不好的話意義不大，還不如不用。

7）關于安全方面的幾個配置優(yōu)化？

首先，是數(shù)據(jù)庫要不要保留審計？如何保留。假設不打開，那么將來出來安全問題，我們無法尋找線索；假設打開，那么很可能因為使得審計日志占用大量的存儲空間，甚至影響數(shù)據(jù)庫IO性能。一般情況下還是需要對一些基本登錄行為的審計，但是我們可以把日志位置修改制定到操作系統(tǒng)層面減少數(shù)據(jù)庫層因此的性能壓力，而且應該定期轉儲，減少碎文件太多而把文件系統(tǒng)i節(jié)點用光的極端情況?？梢酝ㄟ^對參數(shù)"AUDIT_TRAIL"以及adump參數(shù)的調整來實現(xiàn)此項優(yōu)化。

接著，alert日志和trace文件的控制參數(shù)。

“MAX_DUMP_FILE_SIZE”，它決定了這些文件的大小限制，默認情況下是unlimited，如果生成了很大的文件，就會達到OS對文件上限的要求，導致寫入失敗。

最后，所有這些重定給OS或者本來就依靠OS的日志文件也好、審計文件也好。一定得注意其對OS的i節(jié)點資源使用情況的一個把握，不要出現(xiàn)df -h正常但是df -i 不正常的情況。這個往往是非常容易忽視的一點。無論是從監(jiān)控上還是從OS對用戶資源參數(shù)的限定上都要有一個明確的把握。

8）關于ADG的關注點？

ADG本身作為容災的一個手段，那么其本身會有很多點需要我們監(jiān)控。比如說主備庫的狀態(tài)、日志的切換狀況、數(shù)據(jù)之間有沒有GAP等等。但是我想說的是我們非常容易忽略的地方。

首先，關于備庫的RMAN參數(shù)設置，

RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

這個參數(shù)設置是保護沒有被應用的日志不被刪除，在11g的高版本實際上已經(jīng)不需要再設置了，但是低版本的就需要注意了。具體可以參照文檔 ID 1577382.1

9）其他在管理數(shù)據(jù)庫時應該注意的點？

例如：

表空間的數(shù)據(jù)文件是否采用了自動擴展的方式？

表空間的數(shù)據(jù)文件是否都用了ASM的方式？

ASM的冗余方式是否一致？

應用用戶的默認密碼策略是不是已經(jīng)取消了180天的限制等等。

數(shù)據(jù)庫的監(jiān)控指標是否覆蓋了（集群、服務、監(jiān)聽、ASM、表空間、性能等所有應該涵蓋的方面）？

OS層面的監(jiān)控是否已經(jīng)啟用？尤其是私網(wǎng)之間的通訊、CPU、內存的監(jiān)控等？是Nmon還是osw，他們的日志是定期循環(huán)還是持續(xù)不斷增長等等？

數(shù)據(jù)庫巡檢的體系是否完善？日巡檢月度巡檢的內容是否經(jīng)過精心設計？是否已經(jīng)實現(xiàn)了自動化等等？強烈建議日巡檢工作實現(xiàn)腳本自動化，任務定時執(zhí)行，日志統(tǒng)一整合到共享文件系統(tǒng)上，有條件的可以進行整合入庫，按照自己的巡檢機制和體系實現(xiàn)按需調入調出。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)-成都網(wǎng)站建設公司行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。

網(wǎng)站標題：Oracle數(shù)據(jù)庫優(yōu)化思路和9個典型問題分別是什么-創(chuàng)新互聯(lián)
瀏覽路徑：http://aaarwkj.com/article16/iohdg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設、外貿(mào)網(wǎng)站建設、定制開發(fā)、品牌網(wǎng)站制作、動態(tài)網(wǎng)站、網(wǎng)站制作

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)