Oracle數(shù)據(jù)庫(kù)優(yōu)化思路和9個(gè)典型問(wèn)題分別是什么，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。
系統(tǒng)上線(xiàn)前，對(duì)于基礎(chǔ)架構(gòu)的技術(shù)審核可能需要伴隨一系列整改和優(yōu)化，其中數(shù)據(jù)庫(kù)層面的整改和優(yōu)化是最重要的一項(xiàng)。
其實(shí)Oracle官方對(duì)于Oracle的通用最佳實(shí)踐提供的非常詳細(xì)，針對(duì)不同平臺(tái)、針對(duì)不同版本、針對(duì)不同用途等都會(huì)有相應(yīng)一套實(shí)施的最佳實(shí)踐。
例如：
1）RAC 和 Oracle Clusterware 最佳實(shí)踐和初學(xué)者指南（平臺(tái)無(wú)關(guān)部分）
Document 810394.1
RAC and Oracle Clusterware Best Practices and Starter Kit (Platform Independent)
2）特定平臺(tái)的詳細(xì)最佳實(shí)踐
Document 811306.1
RAC and Oracle Clusterware Best Practices and Starter Kit (Linux)
3）操作系統(tǒng)配置注意事項(xiàng)
4）虛擬化注意事項(xiàng)
5）存儲(chǔ)注意事項(xiàng)
6）網(wǎng)絡(luò)注意事項(xiàng)
7）特定硬件注意事項(xiàng)
這個(gè)過(guò)程當(dāng)中，根據(jù)特定的應(yīng)用場(chǎng)合及測(cè)試結(jié)果以及我們對(duì)數(shù)據(jù)庫(kù)理解的不同可能會(huì)產(chǎn)生一些以行業(yè)背景為區(qū)分的行業(yè)經(jīng)驗(yàn)及行業(yè)實(shí)踐。
典型問(wèn)題：
1）關(guān)于重做日志的配置優(yōu)化應(yīng)該做哪些點(diǎn)？應(yīng)該如何做？
首先、接觸過(guò)數(shù)據(jù)庫(kù)的人相信對(duì)這個(gè)概念都不陌生。數(shù)據(jù)庫(kù)在做SQL更新的時(shí)候，首先要將事務(wù)執(zhí)行過(guò)程記入重做日志當(dāng)中，然后才會(huì)把日志刷入磁盤(pán)，將數(shù)據(jù)更新持久化。一條數(shù)據(jù)提交之后成功的標(biāo)準(zhǔn)時(shí)日志落到磁盤(pán)，而不是真正的數(shù)據(jù)落盤(pán)。因此日志的配置（大小、數(shù)量）直接決定著數(shù)據(jù)庫(kù)讀寫(xiě)的性能，如果日志大小非常大，那么會(huì)造成歸檔切換時(shí)間非常長(zhǎng)，一旦這時(shí)候發(fā)生了不可恢復(fù)的DB災(zāi)難，那么通過(guò)備份恢復(fù)的數(shù)據(jù)流失量或者說(shuō)RPO就會(huì)較大。日志大小非常小的話(huà)，勢(shì)必會(huì)造成日志頻繁切換，AWR里面有大量的日志切換事件，這樣對(duì)數(shù)據(jù)庫(kù)的性能會(huì)有較大影響。因此根據(jù)性能測(cè)試的AWR報(bào)告中日志切換的等待事件、和切換頻度來(lái)決定其數(shù)據(jù)量和大小是否需要調(diào)整。一般的OLTP建議（10組、500M）。
接著，我們還需要考慮與其相關(guān)的參數(shù)設(shè)置。
比如說(shuō)“_use_adaptive_log_file_sync”，它直接決定了日志落盤(pán)的方式，對(duì)于日志緩沖區(qū)的數(shù)據(jù)落盤(pán)的方式，11g增加一種新的方式就是polling的方式，傳統(tǒng)方式是post/wait方式。oracle底層自動(dòng)判斷何時(shí)用何種方法來(lái)完成lgwr進(jìn)程的寫(xiě)任務(wù)。對(duì)于post/wait方式來(lái)講，客戶(hù)端做了commit之后，需要等待事件完成。oracle一旦完成會(huì)通知用戶(hù)進(jìn)程，用戶(hù)進(jìn)程立刻感知。但是這一通知post，會(huì)耗費(fèi)大量CPU資源。polling是oracle前臺(tái)進(jìn)程啟動(dòng)檢查任務(wù)，自動(dòng)檢查后臺(tái)lgwr寫(xiě)入情況，耗費(fèi)CPU資源比較少，但是用戶(hù)進(jìn)程并不一定能立刻感知。所以?xún)煞N方法各有千秋。但是關(guān)鍵是后臺(tái)實(shí)現(xiàn)兩種方法切換的時(shí)候要耗費(fèi)系統(tǒng)性能，尤其在繁忙的時(shí)候頻繁切換的話(huà)反而會(huì)導(dǎo)致數(shù)據(jù)庫(kù)性能下降。awr出現(xiàn)大量‘Log file sync’。Bug 13707904。
比如說(shuō)“archive_lag_target”，它決定了我們是否開(kāi)啟日志強(qiáng)制切換功能，為了減少故障時(shí)數(shù)據(jù)損失，可以設(shè)置ARCHIVE_LAG_TARGET參數(shù)，強(qiáng)制進(jìn)行日志切換。這個(gè)參數(shù)的缺省值是0，即為不啟用該參數(shù)。建議設(shè)置值為1800。
2）關(guān)于ORACLE的內(nèi)存管理應(yīng)該關(guān)注那些點(diǎn)？應(yīng)該如何配置？
首先，ORACLE通用的兩種內(nèi)存管理方式AMM&ASMM，從Oracle 11g開(kāi)始，ORACLE默認(rèn)使用AMM(自動(dòng)內(nèi)存管理)，即讓數(shù)據(jù)庫(kù)完全管理SGA、PGA的大小，而對(duì)于管理員只需要設(shè)置一個(gè)總的大小（memory_target），數(shù)據(jù)庫(kù)會(huì)動(dòng)態(tài)的調(diào)整SGA、PGA的大小以及其中包含的各個(gè)組件大小，如Database buffer cache、Shared pool等。這個(gè)特性設(shè)計(jì)的初衷是好的，它希望避免不正確的SGA和PGA設(shè)置導(dǎo)致的內(nèi)存使用不平衡的性能問(wèn)題。但是在實(shí)際應(yīng)用過(guò)程中，這個(gè)特性是不是一定非常出色呢？AMM中在數(shù)據(jù)庫(kù)啟動(dòng)是會(huì)有一個(gè)固定比例來(lái)分配SGA/PGA 大?。簊ga_target =memory_target *60%
pga_aggregate_target=memory_target *40%。
但是在并發(fā)較高，數(shù)據(jù)庫(kù)非常繁忙的場(chǎng)合下，自動(dòng)內(nèi)存調(diào)整的速度很可能趕不上大量會(huì)話(huà)對(duì)內(nèi)存的請(qǐng)求的速度。另外當(dāng)PGA隨著會(huì)話(huà)不斷增加而需求量猛增的情況下，它會(huì)首先搶占SGA，導(dǎo)致數(shù)據(jù)庫(kù)性能故障。在高并發(fā)的數(shù)據(jù)庫(kù)場(chǎng)景中并不建議使用AMM。采用10g更為成熟的自動(dòng)共享內(nèi)存管理(ASMM)和自動(dòng)PGA管理。手動(dòng)調(diào)整內(nèi)存參數(shù)，具體可以參照以下：
//關(guān)閉內(nèi)存自動(dòng)管理
memory_target=0
memory_max_target=0
//設(shè)置SGA為固定值，可以根據(jù)性能測(cè)試中的AWR報(bào)告中的建議
sga_max_size=XG
sga_target=XG
//設(shè)置PGA等參數(shù)
pga_aggregate_target=XG
large_pool_size=256M
另外很重要的一個(gè)參數(shù)，“_shared_pool_reserved_pct”，如果這個(gè)參數(shù)設(shè)置小了，很可能導(dǎo)致ORA04031，TROUBLESHOOTING ORA-4031 - Simple Guide and Basic Approach to Solve the issue (文檔 ID 1416817.1)
3）關(guān)于Linux系統(tǒng)下的大頁(yè)配置？
在 Linux 環(huán)境中實(shí)施 HugePage 能夠極大地提高內(nèi)核性能。對(duì)于內(nèi)存較大的系統(tǒng)，效果尤其明顯。一般而言，系統(tǒng)中的 RAM 越大，系統(tǒng)啟用 Hugepage 后獲得的好處也越大。這是因?yàn)閮?nèi)核為映射和維護(hù)內(nèi)存頁(yè)表所要做的工作量會(huì)隨著系統(tǒng)內(nèi)存的增大而增加。啟用 Hugepage 能夠顯著地降低內(nèi)核要管理的頁(yè)面數(shù)，而且能提高系統(tǒng)的效率。經(jīng)驗(yàn)表明，如果未啟用 Hugepage，內(nèi)核擠占關(guān)鍵的 Oracle Clusterware 或 Real Application Clusters 守護(hù)進(jìn)程的情況會(huì)很常見(jiàn)，而這會(huì)導(dǎo)致實(shí)例或節(jié)點(diǎn)驅(qū)逐出現(xiàn)。具體配置方法可以參照：HugePages on Linux: What It Is... and What It Is Not... (文檔 ID 361323.1)
4）關(guān)于SQL解析相關(guān)的參數(shù)優(yōu)化？
首先、在Oracle中每條SQL語(yǔ)在執(zhí)行之前都需要經(jīng)過(guò)解析，這里面又分為軟解析和硬解析。在Oracle中存在兩種類(lèi)型的SQL語(yǔ)句，一類(lèi)為 DDL語(yǔ)句(數(shù)據(jù)定義語(yǔ)言)，他們是從來(lái)不會(huì)共享使用的，也就是每次執(zhí)行都需要進(jìn)行硬解析。還有一類(lèi)就是DML語(yǔ)句(數(shù)據(jù)操縱語(yǔ)言)，他們會(huì)根據(jù)情況選擇要么進(jìn)行硬解析，要么進(jìn)行軟解析。
一般我們希望我們的AWR報(bào)告中硬解析偏少，而軟解析偏多。因?yàn)橛步馕龅拇鷥r(jià)會(huì)非常高。為了減少帶綁定變量的sql的解析時(shí)間，oracle 9i引入的綁定變量窺測(cè)的功能。也就是在同一個(gè)SQL的變量被賦于不同值時(shí)采用同一個(gè)游標(biāo)，這樣雖然節(jié)省了sql的解析時(shí)間。大家有沒(méi)有通過(guò)功能的打開(kāi)或者關(guān)閉實(shí)際觀(guān)察過(guò)AWR中的軟硬解析數(shù)目的實(shí)際狀況呢？其實(shí)對(duì)于綁定變量窺測(cè)這個(gè)特性以及后來(lái)的自適應(yīng)游標(biāo)等特性，都是oracle為了找到最優(yōu)執(zhí)行計(jì)劃而啟用的一些新特性，但是在實(shí)際應(yīng)用過(guò)程中，對(duì)于不同量級(jí)不同特性的業(yè)務(wù)場(chǎng)景也曾經(jīng)因此出現(xiàn)了很多bug。
understanding and Diagnosing ORA-00600 [12333] / ORA-3137 [12333] Errors (ID 389713.1)
根據(jù)自己的業(yè)務(wù)系統(tǒng)特點(diǎn)，做大量的性能測(cè)試和業(yè)務(wù)測(cè)試，根據(jù)參數(shù)的關(guān)閉打開(kāi)對(duì)比awr報(bào)告當(dāng)中顯示出的軟硬解析比率以及執(zhí)行計(jì)劃數(shù)據(jù)決定是否打開(kāi)或者關(guān)系相應(yīng)功能特性。如下參數(shù)：
"_optim_peek_user_binds"
"_optimizer_adaptive_cursor_sharing"
"_optimizer_extended_cursor_sharing"
"_optimizer_extended_cursor_sharing_rel"
"_optimizer_use_feedback"
接著，與之相關(guān)的幾個(gè)參數(shù)：open_cursors、session_cached_cursors 這兩個(gè)參數(shù)決定著應(yīng)用會(huì)話(huà)可以控制打開(kāi)以及緩存的游標(biāo)數(shù)量，如果數(shù)量不足，就會(huì)引起SQL解析的性能問(wèn)題。這兩個(gè)參數(shù)要根據(jù)v$resource_limit視圖中的值的情況進(jìn)行調(diào)整，避免資源設(shè)置不合理導(dǎo)致的性能問(wèn)題。
還有，與執(zhí)行解析執(zhí)行計(jì)劃相關(guān)的幾個(gè)參數(shù)，_b_tree_bitmap_plans、有時(shí)將B-Tree索引進(jìn)行BITMAP轉(zhuǎn)換來(lái)進(jìn)行SQL執(zhí)行，往往會(huì)生成極其惡劣的執(zhí)行計(jì)劃，導(dǎo)致CPU100%。
Select Fails With ORA-600 [20022] (文檔 ID 1202646.1)
建議可以關(guān)掉。
5）如何避免數(shù)據(jù)庫(kù)集群節(jié)點(diǎn)之間的激烈競(jìng)爭(zhēng)？
數(shù)據(jù)庫(kù)節(jié)點(diǎn)之間的競(jìng)爭(zhēng)有很多，包括鎖（各種粒度鎖）的競(jìng)爭(zhēng)以及數(shù)據(jù)的傳輸?shù)?。完全避免?jìng)爭(zhēng)那就失去了RAC的意義了，RAC本身就是希望能在兩個(gè)節(jié)點(diǎn)并行執(zhí)行任務(wù)。
如果特別極致的并行一定引起嚴(yán)重的性能問(wèn)題，如果完全禁止，既無(wú)法做到又失去了集群本來(lái)的意義。所以我們只能在一定程度上去平衡：
首先、關(guān)于DRM，oracle的DRM特性從理論上來(lái)看，它是為了避免節(jié)點(diǎn)間的數(shù)據(jù)量傳輸，避免節(jié)點(diǎn)間的鎖等待事件頻繁發(fā)生。DRM的極致是做到請(qǐng)求節(jié)點(diǎn)和Master節(jié)點(diǎn)統(tǒng)一化。但是實(shí)踐中，這個(gè)特性引起了很多的BUG、反而導(dǎo)致了節(jié)點(diǎn)間的競(jìng)爭(zhēng)出現(xiàn)了性能故障。Bug 6018125 - Instance crash during dynamic remastering or instance reconfiguration (Doc ID 6018125.8)。所以建議關(guān)閉。
接著、關(guān)于參數(shù)“parallel_force_local”，ORACLE RAC為了實(shí)現(xiàn)多節(jié)點(diǎn)并行處理是花費(fèi)了很大代價(jià)的，假設(shè)一個(gè)集群當(dāng)中有三個(gè)節(jié)點(diǎn)，對(duì)于某一個(gè)數(shù)據(jù)塊兒讀寫(xiě)，有一個(gè)Master、有一個(gè)請(qǐng)求者、有一個(gè)擁有者，請(qǐng)求者向Master請(qǐng)求數(shù)據(jù)塊兒的最新版本，Master把請(qǐng)求轉(zhuǎn)發(fā)給擁有者，擁有者按照請(qǐng)求信息把數(shù)據(jù)塊兒傳送給申請(qǐng)者，然后加鎖進(jìn)行讀寫(xiě)。這一過(guò)程是需要有大量的數(shù)據(jù)傳輸和競(jìng)爭(zhēng)存在的，一旦這個(gè)事情成為多數(shù)，那么勢(shì)必造成節(jié)點(diǎn)間的通訊負(fù)載過(guò)大，造成大量的鎖等待時(shí)間，嚴(yán)重影響數(shù)據(jù)庫(kù)整體性能。尤其是在做跨數(shù)據(jù)中心高可用的場(chǎng)合下。因此我們只要做到業(yè)務(wù)級(jí)別的并發(fā)處理，而不要追求一個(gè)SQL級(jí)別的絕對(duì)并發(fā)。物極必反的道理就在于此。因此把參數(shù)打開(kāi)，使得進(jìn)程級(jí)別并發(fā)實(shí)現(xiàn)本地化處理，不要跨節(jié)點(diǎn)處理。在官方文檔 ID 1536272.1當(dāng)中，必須優(yōu)化的參數(shù)就包括這個(gè)。
6）關(guān)于數(shù)據(jù)庫(kù)的自動(dòng)任務(wù)？
Oracle 11g 數(shù)據(jù)庫(kù)有三個(gè)預(yù)定義自動(dòng)維護(hù)任務(wù)：
Automatic Optimizer Statistics Collection（自動(dòng)優(yōu)化器統(tǒng)計(jì)信息收集）：
收集數(shù)據(jù)庫(kù)中所有無(wú)統(tǒng)計(jì)信息或僅有過(guò)時(shí)統(tǒng)計(jì)信息的 Schema 對(duì)象的 Optimizer（優(yōu)化器）統(tǒng)計(jì)信息。QL query optimizer（SQL 查詢(xún)優(yōu)化器）使用此任務(wù)收集的統(tǒng)計(jì)信息提高 SQL 執(zhí)行的性能。
Automatic Segment Advisor（自動(dòng)段指導(dǎo)）：
識(shí)別有可用回收空間的段，并提出如何消除這些段中的碎片的建議。您也可以手動(dòng)運(yùn)行 Segment Advisor 獲取更多最新建議，或獲取 Automatic Segment Advisor 沒(méi)有檢查到的那些有可能做空間回收的段的建議。
Automatic SQL Tuning Advisor（自動(dòng) SQL 優(yōu)化指導(dǎo)）：檢查高負(fù)載 SQL 語(yǔ)句的性能，并提出如何優(yōu)化這些語(yǔ)句的建議。您可以配置此指導(dǎo)，自動(dòng)應(yīng)用建議的SQL profile。
關(guān)于統(tǒng)計(jì)信息收集，數(shù)據(jù)庫(kù)是有其自己的默認(rèn)啟動(dòng)時(shí)間，11g是在22:00-2:00之間，假設(shè)這個(gè)時(shí)間跟我們的跑批時(shí)間有沖突的話(huà)，我們可以修改器具體執(zhí)行時(shí)間。但是這個(gè)任務(wù)必須保留。
關(guān)于其他的兩個(gè)優(yōu)化指導(dǎo)，其實(shí)要看我們實(shí)際工作中用到的幾率是否很高，是否有價(jià)值留著給我們提供一些優(yōu)化的理論指導(dǎo)。一般感覺(jué)用不好的話(huà)意義不大，還不如不用。
7）關(guān)于安全方面的幾個(gè)配置優(yōu)化？
首先，是數(shù)據(jù)庫(kù)要不要保留審計(jì)？如何保留。假設(shè)不打開(kāi)，那么將來(lái)出來(lái)安全問(wèn)題，我們無(wú)法尋找線(xiàn)索；假設(shè)打開(kāi)，那么很可能因?yàn)槭沟脤徲?jì)日志占用大量的存儲(chǔ)空間，甚至影響數(shù)據(jù)庫(kù)IO性能。一般情況下還是需要對(duì)一些基本登錄行為的審計(jì)，但是我們可以把日志位置修改制定到操作系統(tǒng)層面減少數(shù)據(jù)庫(kù)層因此的性能壓力，而且應(yīng)該定期轉(zhuǎn)儲(chǔ)，減少碎文件太多而把文件系統(tǒng)i節(jié)點(diǎn)用光的極端情況。可以通過(guò)對(duì)參數(shù)"AUDIT_TRAIL"以及adump參數(shù)的調(diào)整來(lái)實(shí)現(xiàn)此項(xiàng)優(yōu)化。
接著，alert日志和trace文件的控制參數(shù)。
“MAX_DUMP_FILE_SIZE”，它決定了這些文件的大小限制，默認(rèn)情況下是unlimited，如果生成了很大的文件，就會(huì)達(dá)到OS對(duì)文件上限的要求，導(dǎo)致寫(xiě)入失敗。
最后，所有這些重定給OS或者本來(lái)就依靠OS的日志文件也好、審計(jì)文件也好。一定得注意其對(duì)OS的i節(jié)點(diǎn)資源使用情況的一個(gè)把握，不要出現(xiàn)df -h正常但是df -i 不正常的情況。這個(gè)往往是非常容易忽視的一點(diǎn)。無(wú)論是從監(jiān)控上還是從OS對(duì)用戶(hù)資源參數(shù)的限定上都要有一個(gè)明確的把握。
8）關(guān)于ADG的關(guān)注點(diǎn)？
ADG本身作為容災(zāi)的一個(gè)手段，那么其本身會(huì)有很多點(diǎn)需要我們監(jiān)控。比如說(shuō)主備庫(kù)的狀態(tài)、日志的切換狀況、數(shù)據(jù)之間有沒(méi)有GAP等等。但是我想說(shuō)的是我們非常容易忽略的地方。
首先，關(guān)于備庫(kù)的RMAN參數(shù)設(shè)置，
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
這個(gè)參數(shù)設(shè)置是保護(hù)沒(méi)有被應(yīng)用的日志不被刪除，在11g的高版本實(shí)際上已經(jīng)不需要再設(shè)置了，但是低版本的就需要注意了。具體可以參照文檔 ID 1577382.1
9）其他在管理數(shù)據(jù)庫(kù)時(shí)應(yīng)該注意的點(diǎn)？
例如：
表空間的數(shù)據(jù)文件是否采用了自動(dòng)擴(kuò)展的方式？
表空間的數(shù)據(jù)文件是否都用了ASM的方式？
ASM的冗余方式是否一致？
應(yīng)用用戶(hù)的默認(rèn)密碼策略是不是已經(jīng)取消了180天的限制等等。
數(shù)據(jù)庫(kù)的監(jiān)控指標(biāo)是否覆蓋了（集群、服務(wù)、監(jiān)聽(tīng)、ASM、表空間、性能等所有應(yīng)該涵蓋的方面）？
OS層面的監(jiān)控是否已經(jīng)啟用？尤其是私網(wǎng)之間的通訊、CPU、內(nèi)存的監(jiān)控等？是Nmon還是osw，他們的日志是定期循環(huán)還是持續(xù)不斷增長(zhǎng)等等？
數(shù)據(jù)庫(kù)巡檢的體系是否完善？日巡檢月度巡檢的內(nèi)容是否經(jīng)過(guò)精心設(shè)計(jì)？是否已經(jīng)實(shí)現(xiàn)了自動(dòng)化等等？強(qiáng)烈建議日巡檢工作實(shí)現(xiàn)腳本自動(dòng)化，任務(wù)定時(shí)執(zhí)行，日志統(tǒng)一整合到共享文件系統(tǒng)上，有條件的可以進(jìn)行整合入庫(kù)，按照自己的巡檢機(jī)制和體系實(shí)現(xiàn)按需調(diào)入調(diào)出。
看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道，感謝您對(duì)創(chuàng)新互聯(lián)的支持。
重慶分公司
重慶分公司
