一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)的生命周期可以分成設(shè)計(jì) 開(kāi)發(fā)和成品三個(gè)階段 在設(shè)計(jì)階段進(jìn)行數(shù)據(jù)庫(kù)性能優(yōu)化的成本最低 收益最大 在成品階段進(jìn)行數(shù)據(jù)庫(kù)性能優(yōu)化的成本最高 收益最小 數(shù)據(jù)庫(kù)的優(yōu)化可以通過(guò)對(duì)網(wǎng)絡(luò) 硬件 操作系統(tǒng) 數(shù)據(jù)庫(kù)參數(shù)和應(yīng)用程序的優(yōu)化來(lái)進(jìn)行 最常見(jiàn)的優(yōu)化手段就是對(duì)硬件的升級(jí) 據(jù)統(tǒng)計(jì) 對(duì)網(wǎng)絡(luò) 硬件 操作系統(tǒng) 數(shù)據(jù)庫(kù)參數(shù)進(jìn)行優(yōu)化所獲得的性能提升 全部加起來(lái)只占數(shù)據(jù)庫(kù)系統(tǒng)性能提升的 %左右 其余的 %系統(tǒng)性能提升來(lái)自對(duì)應(yīng)用程序的優(yōu)化 許多優(yōu)化專家認(rèn)為 對(duì)應(yīng)用程序的優(yōu)化可以得到 %的系統(tǒng)性能的提升
10年積累的網(wǎng)站設(shè)計(jì)制作、做網(wǎng)站經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有蘇仙免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
一 數(shù)據(jù)庫(kù)性能的優(yōu)化
數(shù)據(jù)庫(kù)設(shè)計(jì)是應(yīng)用程序設(shè)計(jì)的基礎(chǔ) 其性能直接影響應(yīng)用程序的性能 數(shù)據(jù)庫(kù)性能包括存儲(chǔ)空間需求量的大小和查詢響應(yīng)時(shí)間的長(zhǎng)短兩個(gè)方面 為了優(yōu)化數(shù)據(jù)庫(kù)性能 需要對(duì)數(shù)據(jù)庫(kù)中的表進(jìn)行規(guī)范化 規(guī)范化的范式可分為第一范式 第二范式 第三范式 BCNF范式 第四范式和第五范式 一般來(lái)說(shuō) 邏輯數(shù)據(jù)庫(kù)設(shè)計(jì)會(huì)滿足規(guī)范化的前 級(jí)標(biāo)準(zhǔn) 但由于滿足第三范式的表結(jié)構(gòu)容易維護(hù)且基本滿足實(shí)際應(yīng)用的要求 因此 實(shí)際應(yīng)用中一般都按照第三范式的標(biāo)準(zhǔn)進(jìn)行規(guī)范化 但是 規(guī)范化也有缺點(diǎn) 由于將一個(gè)表拆分成為多個(gè)表 在查詢時(shí)需要多表連接 降低了查詢速度
由于規(guī)范化有可能導(dǎo)致查詢速度慢的缺點(diǎn) 考慮到一些應(yīng)用需要較快的響應(yīng)速度 在設(shè)計(jì)表時(shí)應(yīng)同時(shí)考慮對(duì)某些表進(jìn)行反規(guī)范化 反規(guī)范化可以采用以下幾種方法
分割表
分割表包括水平分割和垂直分割
水平分割是按照行將一個(gè)表分割為多個(gè)表 這可以提高每個(gè)表的查詢速度 但查詢 更新時(shí)要選擇不同的表 統(tǒng)計(jì)時(shí)要匯總多個(gè)表 因此應(yīng)用程序會(huì)更復(fù)雜
垂直分割是對(duì)于一個(gè)列很多的表 若某些列的訪問(wèn)頻率遠(yuǎn)遠(yuǎn)高于其它列 就可以將主鍵和這些列作為一個(gè)表 將主鍵和其它列作為另外一個(gè)表 通過(guò)減少列的寬度 增加了每個(gè)數(shù)據(jù)頁(yè)的行數(shù) 一次I/O就可以掃描更多的行 從而提高了訪問(wèn)每一個(gè)表的速度 但是由于造成了多表連接 所以應(yīng)該在同時(shí)查詢或更新不同分割表中的列的情況比較少的情況下使用
保留冗余列
當(dāng)兩個(gè)或多個(gè)表在查詢中經(jīng)常需要連接時(shí) 可以在其中一個(gè)表上增加若干冗余的列 以避免表之間的連接過(guò)于頻繁 由于對(duì)冗余列的更新操作必須對(duì)多個(gè)表同步進(jìn)行 所以一般在冗余列的數(shù)據(jù)不經(jīng)常變動(dòng)的情況下使用
增加派生列
派生列是由表中的其它多個(gè)列計(jì)算所得 增加派生列可以減少統(tǒng)計(jì)運(yùn)算 在數(shù)據(jù)匯總時(shí)可以大大縮短運(yùn)算時(shí)間
二 應(yīng)用程序性能的優(yōu)化
應(yīng)用程序的優(yōu)化通?？煞譃閮蓚€(gè)方面 源代碼和SQL語(yǔ)句 由于涉及到對(duì)程序邏輯的改變 源代碼的優(yōu)化在時(shí)間成本和風(fēng)險(xiǎn)上代價(jià)很高 而對(duì)數(shù)據(jù)庫(kù)系統(tǒng)性能的提升收效有限 因此應(yīng)用程序的優(yōu)化應(yīng)著重在SQL語(yǔ)句的優(yōu)化 對(duì)于海量數(shù)據(jù) 劣質(zhì)SQL語(yǔ)句和優(yōu)質(zhì)SQL語(yǔ)句之間的速度差別可以達(dá)到上百倍 可見(jiàn)對(duì)于一個(gè)系統(tǒng)不是簡(jiǎn)單地能實(shí)現(xiàn)其功能就行 而是要寫(xiě)出高質(zhì)量的SQL語(yǔ)句 提高系統(tǒng)的可用性
下面就某些SQL語(yǔ)句的where子句編寫(xiě)中需要注意的問(wèn)題作詳細(xì)介紹 在這些where子句中 即使某些列存在索引 但是由于編寫(xiě)了劣質(zhì)的SQL 系統(tǒng)在運(yùn)行該SQL語(yǔ)句時(shí)也不能使用該索引 而同樣使用全表掃描 這就造成了響應(yīng)速度的極大降低
IS NULL 與 IS NOT NULL
不能用null作索引 任何包含null值的列都將不會(huì)被包含在索引中 即使索引有多列的情況下 只要這些列中有一列含有null 該列就會(huì)從索引中排除 也就是說(shuō)如果某列存在空值 即使對(duì)該列建索引也不會(huì)提高性能
任何在where子句中使用is null或is not null的語(yǔ)句優(yōu)化器是不允許使用索引的
聯(lián)接列
對(duì)于有聯(lián)接的列 即使最后的聯(lián)接值為一個(gè)靜態(tài)值 優(yōu)化器不會(huì)使用索引的 例如 假定有一個(gè)職工表（employee） 對(duì)于一個(gè)職工的姓和名分成兩列存放（FIRST_NAME和LAST_NAME） 現(xiàn)在要查詢一個(gè)叫喬治？布什（Gee Bush）的職工 下面是一個(gè)采用聯(lián)接查詢的SQL語(yǔ)句
select * from employee where first_name|| ||last_name = Gee Bush
上面這條語(yǔ)句完全可以查詢出是否有Gee Bush這個(gè)員工 但是這里需要注意 系統(tǒng)優(yōu)化器對(duì)基于last_name創(chuàng)建的索引沒(méi)有使用
當(dāng)采用下面這種SQL語(yǔ)句的編寫(xiě) Oracle系統(tǒng)就可以采用基于last_name創(chuàng)建的索引
Select * From employee where first_name = Gee and last_name = Bush
遇到下面這種情況又如何處理呢？如果一個(gè)變量（name）中存放著Gee Bush這個(gè)員工的姓名 對(duì)于這種情況我們又如何避免全程遍歷使用索引呢？可以使用一個(gè)函數(shù) 將變量name中的姓和名分開(kāi)就可以了 但是有一點(diǎn)需要注意 這個(gè)函數(shù)是不能作用在索引列上 下面是SQL查詢腳本
select * from employee where first_name = SUBSTR（ name INSTR（ name ） ）
and last_name = SUBSTR（ name INSTR（ name ）+ ）
帶通配符（%）的like語(yǔ)句
同樣以上面的例子來(lái)看這種情況 目前的需求是這樣的 要求在職工表中查詢名字中包含Bush的人 可以采用如下的查詢SQL語(yǔ)句
select * from employee where last_name like %Bush%
這里由于通配符（%）在搜尋詞首出現(xiàn) 所以O(shè)racle系統(tǒng)不使用last_name的索引 在很多情況下可能無(wú)法避免這種情況 但是一定要心中有底 通配符如此使用會(huì)降低查詢速度 然而當(dāng)通配符出現(xiàn)在字符串其他位置時(shí) 優(yōu)化器就能利用索引 例如 在下面的查詢中索引得到了使用
select * from employee where last_name like c%
Order by語(yǔ)句
Order by語(yǔ)句決定了Oracle如何將返回的查詢結(jié)果排序 Order by語(yǔ)句對(duì)要排序的列沒(méi)有什么特別的限制 也可以將函數(shù)加入列中（象聯(lián)接或者附加等） 任何在Order by語(yǔ)句的非索引項(xiàng)或者有計(jì)算表達(dá)式都將降低查詢速度
仔細(xì)檢查order by語(yǔ)句以找出非索引項(xiàng)或者表達(dá)式 它們會(huì)降低性能 解決這個(gè)問(wèn)題的辦法就是重寫(xiě)order by語(yǔ)句以使用索引 也可以為所使用的列建立另外一個(gè)索引 同時(shí)應(yīng)絕對(duì)避免在order by子句中使用表達(dá)式
NOT
我們?cè)诓樵儠r(shí)經(jīng)常在where子句使用一些邏輯表達(dá)式 如大于 小于 等于以及不等于等等 也可以使用and（與） or（或）以及not（非） NOT可用來(lái)對(duì)任何邏輯運(yùn)算符號(hào)取反 下面是一個(gè)NOT子句的例子
…… where not （status = VALID ）
如果要使用NOT 則應(yīng)在取反的短語(yǔ)前面加上括號(hào) 并在短語(yǔ)前面加上NOT運(yùn)算符 NOT運(yùn)算符包含在另外一個(gè)邏輯運(yùn)算符中 這就是不等于（）運(yùn)算符 換句話說(shuō) 即使不在查詢where子句中顯式地加入NOT詞 NOT仍在運(yùn)算符中 見(jiàn)下例
…… where status INVALID
再看下面這個(gè)例子
select * from employee where salary
對(duì)這個(gè)查詢 可以改寫(xiě)為不使用NOT的語(yǔ)句
select * from employee where salary or salary
雖然這兩種查詢的結(jié)果一樣 但是第二種查詢方案會(huì)比第一種查詢方案更快些 第二種查詢?cè)试SOracle對(duì)salary列使用索引 而第一種查詢則不能使用索引
IN和EXISTS
有時(shí)候會(huì)將一列和一系列值相比較 最簡(jiǎn)單的辦法就是在where子句中使用子查詢 在where子句中可以使用兩種格式的子查詢
第一種格式是使用IN操作符 …… where column in（select * from …… where ……）
第二種格式是使用EXIST操作符 …… where exists （select X from ……where ……）
絕大多數(shù)人會(huì)使用第一種格式 因?yàn)樗容^容易編寫(xiě) 而實(shí)際上第二種格式要遠(yuǎn)比第一種格式的效率高 在Oracle中可以將幾乎所有的IN操作符子查詢改寫(xiě)為使用EXISTS的子查詢
第二種格式中 子查詢以 select X 開(kāi)始 運(yùn)用EXISTS子句不管子查詢從表中抽取什么數(shù)據(jù)它只查看where子句 這樣優(yōu)化器就不必遍歷整個(gè)表而僅根據(jù)索引就可完成工作（這里假定在where語(yǔ)句中使用的列存在索引） 相對(duì)于IN子句來(lái)說(shuō) EXISTS使用相連子查詢 構(gòu)造起來(lái)要比IN子查詢困難一些
通過(guò)使用EXISTS Oracle系統(tǒng)會(huì)首先檢查主查詢 然后運(yùn)行子查詢直到找到第一個(gè)匹配項(xiàng) 這就節(jié)省了時(shí)間 Oracle系統(tǒng)在執(zhí)行IN子查詢時(shí) 首先執(zhí)行子查詢 并將獲得的結(jié)果列表存放在一個(gè)加了索引的臨時(shí)表中 在執(zhí)行子查詢之前 系統(tǒng)先將主查詢掛起 待子查詢執(zhí)行完畢 存放在臨時(shí)表中以后再執(zhí)行主查詢 這也就是使用EXISTS比使用IN通常查詢速度快的原因
同時(shí)應(yīng)盡可能使用NOT EXISTS來(lái)代替NOT IN 盡管二者都使用了NOT（不能使用索引而降低速度） 但NOT EXISTS要比NOT IN查詢效率更高
lishixinzhi/Article/program/Oracle/201311/17060
在公路建設(shè)中，通過(guò)建立多條車道可以提高道路的流量。其實(shí)這個(gè)道理在Oracle數(shù)據(jù)庫(kù)中也行得通。即可以將關(guān)鍵數(shù)據(jù)文件存儲(chǔ)在多塊硬盤(pán)上，以提高Oracle數(shù)據(jù)庫(kù)的性能?？上У氖?，不少數(shù)據(jù)庫(kù)管理員沒(méi)有意識(shí)到這一點(diǎn)。在這篇文章中筆者就以O(shè)racle11G為例，說(shuō)明如何通過(guò)在硬盤(pán)之間分布關(guān)鍵數(shù)據(jù)文件來(lái)提高性能。 一、在硬盤(pán)之間分布關(guān)鍵數(shù)據(jù)文件的基本原則。
在傳統(tǒng)的文件系統(tǒng)上(即不是在裸機(jī)上)部署Oracle數(shù)據(jù)庫(kù)，可以通過(guò)將關(guān)鍵的數(shù)據(jù)文件分布到多個(gè)可用的文件系統(tǒng)上或者不同的硬盤(pán)上來(lái)提高數(shù)據(jù)庫(kù)的性能。具體的來(lái)說(shuō)，需要遵循如下幾個(gè)原則。
一是對(duì)于表來(lái)說(shuō)，往往包含兩個(gè)部分，即基本表與索引表。只要為基本表中的字段創(chuàng)建了索引，其對(duì)應(yīng)的就有一張索引表。當(dāng)用戶訪問(wèn)表中的數(shù)據(jù)時(shí)，應(yīng)用系統(tǒng)需要同時(shí)訪問(wèn)到索引表與數(shù)據(jù)表。此時(shí)我們可以將這兩張表比喻成兩輛車。如果現(xiàn)在只有一個(gè)車道(即將他們同時(shí)存放在一個(gè)硬盤(pán)或者文件系統(tǒng)中)，那么兩輛車必須前后行使。而如果現(xiàn)在有兩個(gè)車道(即將基本表與其相對(duì)應(yīng)的索引表存放在不同的硬盤(pán)或者文件系統(tǒng)中)，那么這兩輛車就可以并排行使。顯然，后者的效率更高。為此筆者建議，可將經(jīng)常需要訪問(wèn)的表和與之對(duì)應(yīng)的索引表分開(kāi)來(lái)存放。
二是可以將日志文件也分開(kāi)來(lái)存放。不光光是數(shù)據(jù)表與索引表存在著這種狀況。其實(shí)在日志文件管理中也是如此。只要條件允許，那么最好能夠?qū)⒙?lián)機(jī)重做日志和歸檔日志與其它數(shù)據(jù)文件存放在不同的硬盤(pán)或者文件系統(tǒng)上。因?yàn)楫?dāng)用戶往數(shù)據(jù)庫(kù)中寫(xiě)入數(shù)據(jù)時(shí)，需要同時(shí)往數(shù)據(jù)文件與重做日志文件中寫(xiě)入數(shù)據(jù)。此時(shí)如果將它們分開(kāi)來(lái)存放，那么就相當(dāng)于有了多條車道，分別往不同的文件中寫(xiě)入數(shù)據(jù)。這無(wú)疑就可以提高數(shù)據(jù)寫(xiě)入的效率，從而提高數(shù)據(jù)庫(kù)的性能。
二、哪些文件最好能夠分開(kāi)存放?
在講到硬盤(pán)之間分布關(guān)鍵數(shù)據(jù)文件的基本原則的時(shí)候，筆者舉了幾個(gè)需要分開(kāi)存放的幾個(gè)案例。但是在實(shí)際工作中，并不僅僅局限于上面提到的這些文件。筆者認(rèn)為，如果條件允許的話，那么可以考慮將如下文件放置在不同的硬盤(pán)上。
一是表空間，如臨時(shí)表空間、系統(tǒng)表空間、UNDO表空間等等。這三個(gè)表空間可能系統(tǒng)會(huì)同時(shí)進(jìn)行訪問(wèn)。為此需要將其分開(kāi)來(lái)存放。二是數(shù)據(jù)文件和索引文件。上面提到過(guò)，需要將經(jīng)常訪問(wèn)的數(shù)據(jù)文件與其對(duì)應(yīng)的索引文件存放在不同的硬盤(pán)上。因?yàn)檫@兩類文件在訪問(wèn)數(shù)據(jù)時(shí)也可能會(huì)同時(shí)訪問(wèn)到。三是操作系統(tǒng)盤(pán)與數(shù)據(jù)庫(kù)文件單獨(dú)存放。顯然Oracle系統(tǒng)肯定是與操作系統(tǒng)同時(shí)運(yùn)行的。為了避免他們之間的I/Q沖突，就需要將Oracle部署在操作系統(tǒng)盤(pán)以外的磁盤(pán)上。四是聯(lián)機(jī)重做日志文件。這個(gè)文件比較復(fù)雜，不但要將其與其他文件分開(kāi)來(lái)存放。而且還需要注意的是，最好能夠?qū)⑵浯娣旁谛阅茏罴训挠脖P(pán)上。
最后需要說(shuō)明的一點(diǎn)是，增加磁盤(pán)也會(huì)增加成本。這不光光是購(gòu)買磁盤(pán)所需要的花費(fèi)，還包括管理的成本。所以這之間也會(huì)涉及到成本與性能之間的一個(gè)均衡問(wèn)題。如果企業(yè)的數(shù)據(jù)不是很多，或者主要是涉及到查詢操作，那么這么設(shè)計(jì)的話，就可能不怎么合理。因?yàn)橥度胍笥诨貓?bào)。
三、如何確定是否需要將文件分開(kāi)來(lái)存放?
在實(shí)際工作中，企業(yè)的數(shù)據(jù)是一個(gè)從少到多的過(guò)程。也就是說(shuō)，剛開(kāi)始使用數(shù)據(jù)庫(kù)的時(shí)候，可能數(shù)據(jù)量比較少，此時(shí)出于成本的考慮，沒(méi)有將相關(guān)文件存放在不同的磁盤(pán)上。但是隨著工作的深入，用戶會(huì)發(fā)現(xiàn)數(shù)據(jù)庫(kù)的性能在逐漸的降低。此時(shí)管理員就需要考慮，能夠采取這種多建車道的措施，來(lái)提高數(shù)據(jù)庫(kù)性能。當(dāng)然在采取這個(gè)措施之前，管理員需要先進(jìn)性評(píng)估。此時(shí)評(píng)估所需要用到的一個(gè)指標(biāo)就是磁盤(pán)的I/O爭(zhēng)用。
磁盤(pán)爭(zhēng)用通常發(fā)生在有多個(gè)進(jìn)程試圖同時(shí)訪問(wèn)一個(gè)物理磁盤(pán)的情況下。如現(xiàn)在用戶需要訪問(wèn)某個(gè)數(shù)據(jù)表中的數(shù)據(jù)，此時(shí)系統(tǒng)需要訪問(wèn)索引文件與數(shù)據(jù)表文件。如果將它們放置在同一磁盤(pán)上，那么在訪問(wèn)時(shí)就會(huì)發(fā)生I/O沖突。所以評(píng)估I/O沖突的嚴(yán)重程度，可以幫我們來(lái)確定是否需要將關(guān)鍵文件存放在不同的磁盤(pán)上。
將I/O平均的分布到多個(gè)可用的磁盤(pán)上，這可以有效的減少磁盤(pán)之間的爭(zhēng)用情況，提高數(shù)據(jù)存儲(chǔ)與讀取的性能。從而提高Oracle等應(yīng)用程序的效率。在實(shí)際工作中，數(shù)據(jù)庫(kù)控制文件中有兩個(gè)參數(shù)可以用來(lái)幫助我們?cè)u(píng)估這個(gè)指標(biāo)。這兩個(gè)參數(shù)是文件平均讀取時(shí)間和文件平均寫(xiě)入時(shí)間。不過(guò)在使用這兩個(gè)參數(shù)的時(shí)候，其只評(píng)估所有與數(shù)據(jù)庫(kù)相關(guān)聯(lián)的文件。管理員如果有需要的話，也可以通過(guò)下面的查詢語(yǔ)句來(lái)查詢數(shù)據(jù)文件是否存在I/O問(wèn)題。查詢的語(yǔ)法與結(jié)果如下圖所示：
從如上的查詢結(jié)果中可以看出某個(gè)數(shù)據(jù)文件是否繁忙，數(shù)據(jù)文件之間是否存在著/I/O沖突文件。這里需要注意的是，這個(gè)結(jié)果是一個(gè)動(dòng)態(tài)的結(jié)果。在不同的時(shí)刻、用戶進(jìn)行不同的操作時(shí)往往會(huì)得出不同的結(jié)論。為此筆者建議，在使用這個(gè)數(shù)據(jù)的時(shí)候，最好能夠多跟蹤幾次。然后分析多次運(yùn)行的結(jié)果。只有如此，才能夠得到比較合乎情理的判斷。 通常情況下，管理員根據(jù)上面的結(jié)果可以得出三種結(jié)論。
第一種結(jié)論是上面這些數(shù)據(jù)文件都不是很忙。即文件的平均讀取時(shí)間與寫(xiě)入時(shí)間都比較短，表示這兩個(gè)文件都是比較空閑的。此時(shí)正常情況下，數(shù)據(jù)庫(kù)的性能應(yīng)該是不錯(cuò)的。也就是說(shuō)，如果此時(shí)數(shù)據(jù)庫(kù)的性能不理想的話，那么就不是磁盤(pán)的I/O所造成的。管理員應(yīng)該從其他角度來(lái)改善數(shù)據(jù)庫(kù)的性能。
第二種結(jié)論是每個(gè)數(shù)據(jù)庫(kù)文件都非常的繁忙。此時(shí)有可能是讀取時(shí)間或者寫(xiě)入時(shí)間比較長(zhǎng)，或者說(shuō)兩個(gè)時(shí)間都比較長(zhǎng)。當(dāng)多個(gè)數(shù)據(jù)文件同時(shí)比較繁忙并且他們處于同一磁盤(pán)的話，那么管理員就需要考慮購(gòu)買新的磁盤(pán)，然后將上面提到的這些關(guān)鍵文件重新整理，讓他們部署在不同的磁盤(pán)上。
第三種結(jié)論是某幾個(gè)特定的數(shù)據(jù)文件比較繁忙，而其他數(shù)據(jù)文件還可以。此時(shí)管理員如果成本受到限制，那么也不需要重新購(gòu)買硬盤(pán)。在磁盤(pán)上的物理寫(xiě)入和讀取次數(shù)上如果出現(xiàn)比較大的差異，就表明某個(gè)磁盤(pán)負(fù)載過(guò)大，即有很嚴(yán)重的I/O沖突。此時(shí)最好能夠?qū)⑦@個(gè)磁盤(pán)中的文件進(jìn)行調(diào)整，如將某些文件移動(dòng)到另外的一塊I/O相對(duì)不怎么嚴(yán)重的磁盤(pán)上。不過(guò)在采取這個(gè)操作的時(shí)候，需要注意一點(diǎn)。對(duì)于聯(lián)機(jī)重做日志文件來(lái)說(shuō)，即使其所在的磁盤(pán)I/O沖突比較低，或者訪問(wèn)這個(gè)文件的時(shí)間比較短，但是也不建議將其他數(shù)據(jù)文件轉(zhuǎn)移到其所在的磁盤(pán)上來(lái)。因?yàn)橥ǔＧ闆r下，為了保障數(shù)據(jù)庫(kù)的性能，我們都建議將聯(lián)機(jī)重做日志文件單獨(dú)存放，并且還需要講起放置在性能比較高的硬盤(pán)上。
總之，將關(guān)鍵的Oracle數(shù)據(jù)庫(kù)文件分開(kāi)放置。如此的話可以有效避免磁盤(pán)爭(zhēng)用成為Oracle數(shù)據(jù)庫(kù)系統(tǒng)的性能瓶頸。
一 SGA
Shared pool tunning
Shared pool的優(yōu)化應(yīng)該放在優(yōu)先考慮 因?yàn)橐粋€(gè)cache miss在shared pool中發(fā)生比在data buffer中發(fā)生導(dǎo)致的成本更高 由于dictionary數(shù)據(jù)一般比library cache中的數(shù)據(jù)在內(nèi)存中保存的時(shí)間長(zhǎng) 所以關(guān)鍵是library cache的優(yōu)化
Gets （parse）在namespace中查找對(duì)象的次數(shù)
Pins （execution）在namespace中讀取或執(zhí)行對(duì)象的次數(shù)
Reloads (reparse)在執(zhí)行階段library cache misses的次數(shù) 導(dǎo)致sql需要重新解析
） 檢查v$librarycache中sql area的gethitratio是否超過(guò) ％ 如果未超過(guò) ％ 應(yīng)該檢查應(yīng)用代碼 提高應(yīng)用代碼的效率
Select gethitratio from v$librarycache where namespace= sql area ;
) v$librarycache中reloads/pins的比率應(yīng)該小于 ％ 如果大于 ％ 應(yīng)該增加參數(shù)shared_pool_size的值
Select sum(pins) executions sum(reloads) cache misses sum(reloads)/sum(pins) from v$librarycache;
reloads/pins %有兩種可能 一種是library cache空間不足 一種是sql中引用的對(duì)象不合法
）shared pool reserved size一般是shared pool size的 ％ 不能超過(guò) ％ V$shared_pool_reserved中的request misses＝ 或沒(méi)有持續(xù)增長(zhǎng) 或者free_memory大于shared pool reserved size的 % 表明shared pool reserved size過(guò)大 可以壓縮
）將大的匿名pl/sql代碼塊轉(zhuǎn)換成小的匿名pl/sql代碼塊調(diào)用存儲(chǔ)過(guò)程
）從 i開(kāi)始 可以將execution plan與sql語(yǔ)句一起保存在library cache中 方便進(jìn)行性能診斷 從v$sql_plan中可以看到execution plans
）保留大的對(duì)象在shared pool中 大的對(duì)象是造成內(nèi)存碎片的主要原因 為了騰出空間許多小對(duì)象需要移出內(nèi)存 從而影響了用戶的性能 因此需要將一些常用的大的對(duì)象保留在shared pool中 下列對(duì)象需要保留在shared pool中
a 經(jīng)常使用的存儲(chǔ)過(guò)程
b 經(jīng)常操作的表上的已編譯的觸發(fā)器
c Sequence 因?yàn)镾equence移出shared pool后可能產(chǎn)生號(hào)碼丟失
查找沒(méi)有保存在library cache中的大對(duì)象
Select * from v$db_object_cache where sharable_mem and
type in ( PACKAGE PROCEDURE FUNCTION PACKAGE BODY ) and kept= NO ;
將這些對(duì)象保存在library cache中
Execute dbms_shared_pool keep( package_name );
對(duì)應(yīng)腳本 dbmspool sql
)查找是否存在過(guò)大的匿名pl/sql代碼塊 兩種解決方案
A．轉(zhuǎn)換成小的匿名塊調(diào)用存儲(chǔ)過(guò)程
B．將其保留在shared pool中
查找是否存在過(guò)大的匿名pl/sql塊
Select sql_text from v$sqlarea where mand_type= and length(sql_text) ;
）Dictionary cache的優(yōu)化
避免出現(xiàn)Dictionary cache的misses 或者misses的數(shù)量保持穩(wěn)定 只能通過(guò)調(diào)整shared_pool_size來(lái)間接調(diào)整dictionary cache的大小
Percent misses應(yīng)該很低 大部分應(yīng)該低于 ％ 合計(jì)應(yīng)該低于 ％
Select sum(getmisses)/sum(gets) from v$rowcache;
若超過(guò) ％ 增加shared_pool_size的值
Buffer Cache
）granule大小的設(shè)置 db_cache_size以字節(jié)為單位定義了default buffer pool的大小
如果SGA M granule= M 否則granule＝ M 即需要調(diào)整sga的時(shí)候以granule為單位增加大小 并且sga的大小應(yīng)該是granule的整數(shù)倍
) 根據(jù)v$db_cache_advice調(diào)整buffer cache的大小
SELECT size_for_estimate buffers_for_estimate estd_physical_read_factor estd_physical_reads
FROM v$db_cache_advice WHERE NAME= DEFAULT AND advice_status= ON
AND block_size=(SELECT Value FROM v$parameter WHERE NAME= db_block_size );
estd_physical_read_factor=
) 統(tǒng)計(jì)buffer cache的cache hit ratio % 如果低于 ％ 可以用下列方案解決
◆增加buffer cache的值
◆使用多個(gè)buffer pool
◆Cache table
◆為 sorting and parallel reads 建獨(dú)立的buffer cache
SELECT NAME value FROM v$sysstat WHERE NAME IN ( session logical reads
physical reads physical reads direct physical reads direct(lob) );
Cache hit ratio= (physical reads physical reads direct physical reads direct (lob))/session logical reads;Select (phy value dir value lob value)/log value from v$sysstat log v$sysstat phy v$sysstat dir v$sysstat LOB where log name= session logical reads and phy name= physical reads and dir name= physical reads direct and lob name= physical reads direct (lob) ;
影響cache hit ratio的因素 全表掃描 應(yīng)用設(shè)計(jì) 大表的隨機(jī)訪問(wèn) cache hits的不均衡分布
）表空間使用自動(dòng)空間管理 消除了自由空間列表的需求 可以減少數(shù)據(jù)庫(kù)的競(jìng)爭(zhēng)
其他SGA對(duì)象
）redo log buffer
對(duì)應(yīng)的參數(shù)是log_buffer 缺省值與 OS相關(guān) 一般是 K 檢查v$session_wait中是否存在log buffer wait v$sysstat中是否存在redo buffer allocation retries
A 檢查是否存在log buffer wait
Select * from v$session_wait where event= log buffer wait ;
如果出現(xiàn)等待 一是可以增加log buffer的大小 也可以通過(guò)將log 文件移到訪問(wèn)速度更快的磁盤(pán)來(lái)解決
B
Select name value from v$sysstat where name in
( redo buffer allocation retries redo entries )
Redo buffer allocation retries接近 小于redo entries 的 ％ 如果一直在增長(zhǎng) 表明進(jìn)程已經(jīng)不得不等待redo buffer的空間 如果Redo buffer allocation retries過(guò)大 增加log_buffer的值
C 檢查日志文件上是否存在磁盤(pán)IO競(jìng)爭(zhēng)現(xiàn)象
Select event total_waits time_waited average_wait from v$system_event
where event like log file switch pletion% ;
如果存在競(jìng)爭(zhēng) 可以考慮將log文件轉(zhuǎn)移到獨(dú)立的 更快的存儲(chǔ)設(shè)備上或增大log文件
D 檢查點(diǎn)的設(shè)置是否合理
檢查alert log文件中 是否存在 checkpoint not plete
Select event total_waits time_waited average_wait from v$system_event
where event like log file switch (check% ;
如果存在等待 調(diào)整log_checkpoint_interval log_checkpoint_timeout的設(shè)置
E 檢查log archiver的工作
Select event total_waits time_waited average_wait from v$system_event
where event like log file switch (arch% ;
如果存在等待 檢查保存歸檔日志的存儲(chǔ)設(shè)備是否已滿 增加日志文件組 調(diào)整log_archiver_max_processes
F DB_block_checksum=true 因此增加了性能負(fù)擔(dān) （為了保證數(shù)據(jù)的一致性 oracle的寫(xiě)數(shù)據(jù)的時(shí)候加一個(gè)checksum在block上 在讀數(shù)據(jù)的時(shí)候?qū)hecksum進(jìn)行驗(yàn)證）
）java pool
對(duì)于大的應(yīng)用 java_pool_size應(yīng)= M 對(duì)于一般的java存儲(chǔ)過(guò)程 缺省的 M已經(jīng)夠用了
）檢查是否需要調(diào)整DBWn
lishixinzhi/Article/program/Oracle/201311/17744
幾個(gè)簡(jiǎn)單的步驟大幅提高Oracle性能 我優(yōu)化數(shù)據(jù)庫(kù)的三板斧數(shù)據(jù)庫(kù)優(yōu)化的討論可以說(shuō)是一個(gè)永恒的主題 資深的Oracle優(yōu)化人員通常會(huì)要求提出性能問(wèn)題的人對(duì)數(shù)據(jù)庫(kù)做一個(gè)statspack 貼出數(shù)據(jù)庫(kù)配置等等 還有的人認(rèn)為要抓出執(zhí)行最慢的語(yǔ)句來(lái)進(jìn)行優(yōu)化 但實(shí)際情況是 提出疑問(wèn)的人很可能根本不懂執(zhí)行計(jì)劃 更不要說(shuō)statspack了 而我認(rèn)為 數(shù)據(jù)庫(kù)優(yōu)化 應(yīng)該首先從大的方面考慮 網(wǎng)絡(luò) 服務(wù)器硬件配置 操作系統(tǒng)配置 Oracle服務(wù)器配置 數(shù)據(jù)結(jié)構(gòu)組織 然后才是具體的調(diào)整 實(shí)際上網(wǎng)絡(luò) 硬件等往往無(wú)法決定更換 應(yīng)用程序一般也無(wú)法修改 因此應(yīng)該著重從數(shù)據(jù)庫(kù)配置 數(shù)據(jù)結(jié)構(gòu)上來(lái)下手 首先讓數(shù)據(jù)庫(kù)有一個(gè)良好的配置 然后再考慮具體優(yōu)化某些過(guò)慢的語(yǔ)句 我在給我的用戶系統(tǒng)進(jìn)行優(yōu)化的過(guò)程中 總結(jié)了一些基本的 簡(jiǎn)單易行的辦法來(lái)優(yōu)化數(shù)據(jù)庫(kù) 算是我的三板斧 呵呵 不過(guò)請(qǐng)注意 這些不一定普遍使用 甚至有的會(huì)有副作用 但是對(duì)OLTP系統(tǒng) 基于成本的數(shù)據(jù)庫(kù)往往行之有效 不妨試試 （注 附件是Burleson寫(xiě)的用來(lái)報(bào)告數(shù)據(jù)庫(kù)性能等信息的腳本 本文用到） 一．設(shè)置合適的SGA 常常有人抱怨服務(wù)器硬件很好 但是Oracle就是很慢 很可能是內(nèi)存分配不合理造成的 ( )假設(shè)內(nèi)存有 M 這通常是小型應(yīng)用 建議Oracle的SGA大約 M 其中 共享池（SHARED_POOL_SIZE）可以設(shè)置 M到 M 根據(jù)實(shí)際的用戶數(shù) 查詢等來(lái)定 數(shù)據(jù)塊緩沖區(qū)可以大致分配 M M i下需要設(shè)置DB_BLOCK_BUFFERS DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于數(shù)據(jù)塊緩沖區(qū)大小 i 下的數(shù)據(jù)緩沖區(qū)可以用db_cache_size來(lái)直接分配 ( )假設(shè)內(nèi)存有 G Oracle 的SGA可以考慮分配 M 共享池分配 M到 M 數(shù)據(jù)緩沖區(qū)分配 M到 M ( )內(nèi)存 G SGA可以考慮分配 G 共享池 M到 M 剩下的給數(shù)據(jù)塊緩沖區(qū) ( )內(nèi)存 G以上 共享池 M到 M就足夠啦 再多也沒(méi)有太大幫助 (Biti_rainy有專述)數(shù)據(jù)緩沖區(qū)是盡可能的大 但是一定要注意兩個(gè)問(wèn)題 一是要給操作系統(tǒng)和其他應(yīng)用留夠內(nèi)存 二是對(duì)于 位的操作系統(tǒng) Oracle的SGA有 G的限制 有的 位操作系統(tǒng)上可以突破這個(gè)限制 方法還請(qǐng)看Biti的大作吧 二．分析表和索引 更改優(yōu)化模式 Oracle默認(rèn)優(yōu)化模式是CHOOSE 在這種情況下 如果表沒(méi)有經(jīng)過(guò)分析 經(jīng)常導(dǎo)致查詢使用全表掃描 而不使用索引 這通常導(dǎo)致磁盤(pán)I/O太多 而導(dǎo)致查詢很慢 如果沒(méi)有使用執(zhí)行計(jì)劃穩(wěn)定性 則應(yīng)該把表和索引都分析一下 這樣可能直接會(huì)使查詢速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 對(duì)于少于 萬(wàn)的表 可以考慮分析整個(gè)表 對(duì)于很大的表 可以按百分比來(lái)分析 但是百分比不能過(guò)低 否則生成的統(tǒng)計(jì)信息可能不準(zhǔn)確 可以通過(guò)DBA_TABLES的LAST_ANALYZED列來(lái)查看表是否經(jīng)過(guò)分析或分析時(shí)間 索引可以通過(guò)DBA_INDEXES的LAST_ANALYZED列 下面通過(guò)例子來(lái)說(shuō)明分析前后的速度對(duì)比 （表CASE_GA_AJZLZ大約有 萬(wàn)數(shù)據(jù) 有主鍵）首先在SQLPLUS中打開(kāi)自動(dòng)查詢執(zhí)行計(jì)劃功能 (第一次要執(zhí)行\(zhòng)RDBMS\ADMIN\utlxplan sql來(lái)創(chuàng)建PLAN_TABLE這個(gè)表)SQL SET AUTOTRACE ONSQLSET TIMING ON通過(guò)SET AUTOTRACE ON 來(lái)查看語(yǔ)句的執(zhí)行計(jì)劃 通過(guò)SET TIMING ON 來(lái)查看語(yǔ)句運(yùn)行時(shí)間 SQL select count(*) from CASE_GA_AJZLZ;COUNT(*) 已用時(shí)間: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………請(qǐng)注意上面分析中的TABLE ACCESS(FULL) 這說(shuō)明該語(yǔ)句執(zhí)行了全表掃描 而且查詢使用了 秒 這時(shí)表還沒(méi)有經(jīng)過(guò)分析 下面我們來(lái)對(duì)該表進(jìn)行分析 SQL *** yze table CASE_GA_AJZLZ pute statistics;表已分析 已用時(shí)間: : : 然后再來(lái)查詢 SQL select count(*) from CASE_GA_AJZLZ;COUNT(*) 已用時(shí)間: : : Execution Plan SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= )…………………………請(qǐng)注意 這次時(shí)間僅僅用了 秒！這要?dú)w功于INDEX(FAST FULL SCAN) 通過(guò)分析表 查詢使用了PK_AJZLZ索引 磁盤(pán)I/O大幅減少 速度也大幅提升！下面的實(shí)用語(yǔ)句可以用來(lái)生成分析某個(gè)用戶的所有表和索引 假設(shè)用戶是GAXZUSR SQL set pagesize SQL spool d:\ *** yze_tables sql;SQL select *** yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ;SQL spool offSQL spool spool d:\ *** yze_indexes sql;SQL select *** yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ;SQL spool offSQL @d:\ *** yze_tables sqlSQL @d:\ *** yze_indexes sql解釋 上面的語(yǔ)句生成了兩個(gè)sql文件 分別分析全部的GAXZUSR的表和索引 如果需要按照百分比來(lái)分析表 可以修改一下腳本 通過(guò)上面的步驟 我們就完成了對(duì)表和索引的分析 可以測(cè)試一下速度的改進(jìn)啦 建議定期運(yùn)行上面的語(yǔ)句 尤其是數(shù)據(jù)經(jīng)過(guò)大量更新 當(dāng)然 也可以通過(guò)dbms_stats來(lái)分析表和索引 更方便一些 但是我仍然習(xí)慣上面的方法 因?yàn)槌晒εc否會(huì)直接提示出來(lái) 另外 我們可以將優(yōu)化模式進(jìn)行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 對(duì)于OLTP系統(tǒng) 可以改成FIRST_ROWS 來(lái)要求查詢盡快返回結(jié)果 這樣即使不用分析 在一般情況下也可以提高查詢性能 但是表和索引經(jīng)過(guò)分析后有助于找到最合適的執(zhí)行計(jì)劃 三．設(shè)置cursor_sharing=FORCE 或SIMILAR 這種方法是 i才開(kāi)始有的 oracle 不支持 通過(guò)設(shè)置該參數(shù) 可以強(qiáng)制共享只有文字不同的語(yǔ)句解釋計(jì)劃 例如下面兩條語(yǔ)句可以共享 SQL SELECT * FROM MYTABLE WHERE NAME= tom SQL SELECT * FROM MYTABLE WHERE NAME= turner 這個(gè)方法可以大幅降低緩沖區(qū)利用率低的問(wèn)題 避免語(yǔ)句重新解釋 通過(guò)這個(gè)功能 可以很大程度上解決硬解析帶來(lái)的性能下降的問(wèn)題 個(gè)人感覺(jué)可根據(jù)系統(tǒng)的實(shí)際情況 決定是否將該參數(shù)改成FORCE 該參數(shù)默認(rèn)是exact 不過(guò)一定要注意 修改之前 必須先給ORACLE打補(bǔ)丁 否則改之后oracle會(huì)占用 %的CPU 無(wú)法使用 對(duì)于ORACLE i 可以設(shè)置成SIMILAR 這個(gè)設(shè)置綜合了FORCE和EXACT的優(yōu)點(diǎn) 不過(guò)請(qǐng)慎用這個(gè)功能 這個(gè)參數(shù)也可能帶來(lái)很大的負(fù)面影響！ 四．將常用的小表 索引釘在數(shù)據(jù)緩存KEEP池中 內(nèi)存上數(shù)據(jù)讀取速度遠(yuǎn)遠(yuǎn)比硬盤(pán)中讀取要快 據(jù)稱 內(nèi)存中數(shù)據(jù)讀的速度是硬盤(pán)的 倍！如果資源比較豐富 把常用的小的 而且經(jīng)常進(jìn)行全表掃描的表給釘內(nèi)存中 當(dāng)然是在好不過(guò)了 可以簡(jiǎn)單的通過(guò)ALTER TABLE tablename CACHE來(lái)實(shí)現(xiàn) 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般來(lái)說(shuō) 可以考慮把 數(shù)據(jù)塊之內(nèi)的表放在keep池中 當(dāng)然要根據(jù)內(nèi)存大小等因素來(lái)定 關(guān)于如何查出那些表或索引符合條件 可以使用本文提供的access sql和access_report sql 這兩個(gè)腳本是著名的Oracle專家 Burleson寫(xiě)的 你也可以在讀懂了情況下根據(jù)實(shí)際情況調(diào)整一下腳本 對(duì)于索引 可以通過(guò)ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)來(lái)釘在KEEP池中 將表定在KEEP池中需要做一些準(zhǔn)備工作 對(duì)于ORACLE i 需要設(shè)置DB_KEEP_CACHE_SIZE 對(duì)于 i 需要設(shè)置buffer_pool_keep 在 i中 還要修改db_block_lru_latches 該參數(shù)默認(rèn)是 無(wú)法使用buffer_pool_keep 該參數(shù)應(yīng)該比 * *CPU數(shù)量少 但是要大于 才能設(shè)置DB_KEEP_CACHE_BUFFER buffer_pool_keep從db_block_buffers中分配 因此也要小于db_block_buffers 設(shè)置好這些參數(shù)后 就可以把常用對(duì)象永久釘在內(nèi)存里 五．設(shè)置optimizer_max_permutations 對(duì)于多表連接查詢 如果采用基于成本優(yōu)化(CBO) ORACLE會(huì)計(jì)算出很多種運(yùn)行方案 從中選擇出最優(yōu)方案 這個(gè)參數(shù)就是設(shè)置oracle究竟從多少種方案來(lái)選擇最優(yōu) 如果設(shè)置太大 那么計(jì)算最優(yōu)方案過(guò)程也是時(shí)間比較長(zhǎng)的 Oracle 和 i默認(rèn)是 建議改成 對(duì)于 i 已經(jīng)默認(rèn)是 了 六．調(diào)整排序參數(shù) ( ) SORT_AREA_SIZE:默認(rèn)的用來(lái)排序的SORT_AREA_SIZE大小是 K 通常顯得有點(diǎn)小 一般可以考慮設(shè)置成 M（ ） 這個(gè)參數(shù)不能設(shè)置過(guò)大 因?yàn)槊總€(gè)連接都要分配同樣的排序內(nèi)存 ( ) SORT_MULTIBLOCK_READ_COUNT:增大這個(gè)參數(shù)可以提高臨時(shí)表空間排序性能 該參數(shù)默認(rèn)是 可以改成 來(lái)對(duì)比一下排序查詢時(shí)間變化 注意 這個(gè)參數(shù)的最大值與平臺(tái)有關(guān)系 七．調(diào)整其它幾個(gè)關(guān)鍵的性能參數(shù) 很多人認(rèn)為使用oracle數(shù)據(jù)庫(kù) 系統(tǒng)的默認(rèn)參數(shù)就是最好的 其實(shí)不是這樣 lishixinzhi/Article/program/Oracle/201311/16704
問(wèn) oracle進(jìn)程內(nèi)存占用一直增加 達(dá)到 G左右的時(shí)候就會(huì)連接失敗 監(jiān)聽(tīng)進(jìn)程死掉 或者CPU達(dá)到 % 如何解決?
Peak Wong
Oracle性能調(diào)優(yōu)一直是一個(gè)很有意思的命題 增強(qiáng)硬件配置是一種方法 但我們平時(shí)遇到的最多的問(wèn)題是如何在沒(méi)辦法增強(qiáng)硬件配置的情況下 將數(shù)據(jù)庫(kù)性能優(yōu)化 這里給出一個(gè)思維流程 希望對(duì)各位有益
PATCH是否都打了 ORACLE系統(tǒng)內(nèi)存參數(shù)是否太大 超出OS的MEMORY
查查是不是程序沒(méi)有關(guān)閉連接導(dǎo)致連接數(shù)不斷上升引起的 你是什么操作系統(tǒng)?
服務(wù)器都作了什么設(shè)置呢?比如sga的分配 是什么情況呢?
要進(jìn)行調(diào)優(yōu) 及參數(shù)設(shè)置
啟動(dòng) Enterprise Management Console 以SYS/**** as SYSDBA身份進(jìn)入系統(tǒng)
ORACLE i調(diào)優(yōu)只涉及如下幾個(gè)參數(shù)
a) processes = ;
b) open_links = ;
c)open_cursors = ;
d)sessions= ;
e) parallel_automatic_tuning=true
f) undo_retention=
g) undo_management=AUTO
請(qǐng)確保在 SPFILE 中保存 在Oracle i缺省的啟動(dòng)參數(shù)是spfile 不要用pfile文件啟動(dòng)數(shù)據(jù)庫(kù)
物理內(nèi)存大于 G以上的通用設(shè)置:
啟動(dòng) Enterprise Management Console 以SYS/**** as SYSDBA身份進(jìn)入系統(tǒng)
配置SGA和PGA大小方法如下
物理內(nèi)存大于 G以上的通用設(shè)置
中文名 參數(shù)名 參數(shù)值 設(shè)置方法
SGA的最大大小 Sga_max_size M 例程 配置 內(nèi)存項(xiàng)卡
日志緩沖區(qū) Log_buffer 例程 配置 一般信息選項(xiàng)卡 所有初始化參數(shù)
大型池 Large_pool_size M 例程 配置 內(nèi)存項(xiàng)卡
Java池 Java_pool_size M 例程 配置 一般信息選項(xiàng)卡 所有初始化參數(shù)
共享池 Shared_pool_size M 例程 配置 內(nèi)存項(xiàng)卡
數(shù)據(jù)緩沖區(qū)高速緩存 Db_cache_size M 例程 配置 內(nèi)存項(xiàng)卡
Keep池 Db_keep_cache_size M 例程 配置 一般信息選項(xiàng)卡 所有初始化參數(shù)
Pga自動(dòng)管理 workarea_size_policy AUTO 例程 配置 一般信息選項(xiàng)卡 所有初始化參數(shù)
總計(jì)pga目標(biāo) pga_aggregate_target M 例程 配置 內(nèi)存項(xiàng)卡
說(shuō)明:
此內(nèi)存設(shè)置不包含在數(shù)據(jù)庫(kù)服務(wù)器上的其它應(yīng)用程序的物理內(nèi)存的大小 如果有其它的應(yīng)用程序 可以參照下面的計(jì)算: sga_max_size+ pga_aggregate_target+應(yīng)用程序物理內(nèi)存+OS物理內(nèi)存 = 系統(tǒng)物理內(nèi)存* % 如果服務(wù)器上只有Oracle服務(wù)器 在 G以上物理內(nèi)存的服務(wù)器上Oracle內(nèi)存參數(shù)都可以參照上面的設(shè)置 如果服務(wù)器上有其它的應(yīng)用 而服務(wù)器總的物理內(nèi)存大于 請(qǐng)自己計(jì)算后再選擇的方案
sga_max_size+ pga_aggregate_target = G 在 bit操作系統(tǒng)上有這個(gè)限制
lishixinzhi/Article/program/Oracle/201311/17386
1、使用兩邊加‘%’號(hào)的查詢，Oracle是不通過(guò)索引的，所以查詢效率很低。
例如：select count(*) from lui_user_base t where t.user_name like '%cs%';
2、like '...%'和 like'%...'雖然走了索引，但是效率依然很低。
3、有人說(shuō)使用如下sql，他的效率提高了10倍，但是數(shù)據(jù)量小的時(shí)候
select count(*) from lui_user_base where rowid in (select rowid from lui_user_base t where t.user_name like '%cs%')
我拿100w跳數(shù)據(jù)做了測(cè)試，效果一般，依然很慢，原因：
select rowid from lui_user_base t where t.user_name like '%cs%' ? 這條sql執(zhí)行很快，那是相當(dāng)?shù)目欤欠诺絪elect count(*) from lui_user_base where rowid in（）里后，效率就會(huì)變的很慢了。
4、select count(*) from lui_user_base t where instr(t.user_name,'cs') 0
這種查詢效果很好，速度很快，推薦使用這種。因?yàn)槲覍?duì)oracle內(nèi)部機(jī)制不是很懂，只是對(duì)結(jié)果做了一個(gè)說(shuō)明。
5、有人說(shuō)了用全文索引，我看了，步驟挺麻煩，但是是個(gè)不錯(cuò)的方法，留著備用：
對(duì)cmng_custominfo 表中的address字段做全文檢索：
1，在oracle9201中需要?jiǎng)?chuàng)建一個(gè)分詞的東西：
BEGIN
ctx_ddl.create_preference ('SMS_ADDRESS_LEXER', 'CHINESE_LEXER');
--ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer'); 不用
end;
2，創(chuàng)建全文檢索：
CREATE INDEX INX_CUSTOMINFO_ADDR_DOCS ON cmng_custominfo(address) INDEXTYPE IS CTXSYS.CONTEXT PARAMETERS ('LEXER SMS_ADDRESS_LEXER');
3，查詢時(shí)候，使用：
select * from cmng_custominfo where contains (address, '金色新城')1;
4，需要定期進(jìn)行同步和優(yōu)化：
同步：根據(jù)新增記錄的文本內(nèi)容更新全文搜索的索引。
begin
ctx_ddl.sync_index('INX_CUSTOMINFO_ADDR_DOCS');
end;
優(yōu)化：根據(jù)被刪除記錄清除全文搜索索引中的垃圾
begin
ctx_ddl.optimize_index('INX_CUSTOMINFO_ADDR_DOCS', 'FAST');
end;
5，采用job做步驟4中的工作：
1)該功能需要利用oracle的JOB功能來(lái)完成
因?yàn)閛racle9I默認(rèn)不啟用JOB功能，所以首先需要增加ORACLE數(shù)據(jù)庫(kù)實(shí)例的JOB配置參數(shù):
job_queue_processes=5
重新啟動(dòng)oracle數(shù)據(jù)庫(kù)服務(wù)和listener服務(wù)。
2)同步 和 優(yōu)化
--同步 sync:
variable jobno number;
BEGIN
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.sync_index(''INX_CUSTOMINFO_ADDR_DOCS'');',
SYSDATE, 'SYSDATE + (1/24/4)');
commit;
END;
--優(yōu)化
variable jobno number;
begin
DBMS_JOB.SUBMIT(:jobno,'ctx_ddl.optimize_index(''INX_CUSTOMINFO_ADDR_DOCS'',''FULL'');', SYSDATE, 'SYSDATE + 1');
commit;
END;
其中， 第一個(gè)job的SYSDATE + (1/24/4)是指每隔15分鐘同步一次，第二個(gè)job的SYSDATE + 1是每隔1天做一次全優(yōu)化。具體的時(shí)間間隔，可以根據(jù)應(yīng)用的需要而定。
6，索引重建
重建索引會(huì)刪除原來(lái)的索引，重新生成索引，需要較長(zhǎng)的時(shí)間。
重建索引語(yǔ)法如下：
ALTER INDEX INX_CUSTOMINFO_ADDR_DOCS REBUILD;
據(jù)網(wǎng)上一些用家的體會(huì)，oracle重建索引的速度也是比較快的，有一用家這樣描述：
Oracle 的全文檢索建立和維護(hù)索引要比ms sql server都要快得多，筆者的65萬(wàn)記錄的一個(gè)表建立索引只需要20分鐘，同步一次只需要1分鐘。
因此，也可以考慮用job的辦法定期重建索引。
重慶分公司
重慶分公司
