想提高Oracle性能，如何優(yōu)化數(shù)據(jù)庫(kù)？
我們今天主要向大家介紹的是如何優(yōu)化數(shù)據(jù)庫(kù)來(lái)大提高Oracle性能，以下我們就介紹幾個(gè)比較簡(jiǎn)單的步驟來(lái)大幅的提高Oracle性能，沃爾瑪你很形象將其比喻成優(yōu)化數(shù)據(jù)庫(kù)的三板斧，數(shù)據(jù)庫(kù)優(yōu)化的討論可以說(shuō)是一個(gè)永恒的主題。
資深的Oracle優(yōu)化人員通常會(huì)要求提出Oracle性能問(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寫的用來(lái)報(bào)告數(shù)據(jù)庫(kù)Oracle性能等信息的腳本，本文用到）
一．設(shè)置合適的SGA
常常有人抱怨服務(wù)器硬件很好，但是Oracle就是很慢。很可能是內(nèi)存分配不合理造成的。(1)假設(shè)內(nèi)存有512M，這通常是小型應(yīng)用。建議Oracle性能的SGA大約240M，其中：共享池（SHARED_POOL_SIZE）可以設(shè)置60M到80M，根據(jù)實(shí)際的用戶數(shù)、查詢等來(lái)定。數(shù)據(jù)塊緩沖區(qū)可以大致分配120M-150M，8i下需要設(shè)置DB_BLOCK_BUFFERS，DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于數(shù)據(jù)塊緩沖區(qū)大小。
9i 下的數(shù)據(jù)緩沖區(qū)可以用db_cache_size來(lái)直接分配。
(2)假設(shè)內(nèi)存有1G，Oracle 的SGA可以考慮分配500M：共享池分配100M到150M，數(shù)據(jù)緩沖區(qū)分配300M到400M。
(3)內(nèi)存2G，SGA可以考慮分配1.2G，共享池300M到500M，剩下的給數(shù)據(jù)塊緩沖區(qū)。
(4)內(nèi)存2G以上：共享池300M到500M就足夠啦，再多也沒(méi)有太大幫助；(Biti_rainy有專述)數(shù)據(jù)緩沖區(qū)是盡可能的大，但是一定要注意兩個(gè)問(wèn)題：一是要給操作系統(tǒng)和其他應(yīng)用留夠內(nèi)存，二是對(duì)于32位的操作系統(tǒng)，Oracle的SGA有1.75G的限制。有的32位操作系統(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)致磁盤I/O太多，而導(dǎo)致查詢很慢。如果沒(méi)有使用執(zhí)行計(jì)劃穩(wěn)定性，則應(yīng)該把表和索引都分析一下，這樣可能直接會(huì)使查詢速度大幅提升。
分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令。對(duì)于少于100萬(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大約有35萬(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 ON
- SQL>SET 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(*)
- ----------
- 346639
已用時(shí)間: 00: 00: 21.38
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE
1 0 SORT (AGGREGATE)
2 1 TABLE ACCESS (FULL) OF 'CASE_GA_AJZLZ'
……………………
請(qǐng)注意上面分析中的TABLE ACCESS(FULL)，這說(shuō)明該語(yǔ)句執(zhí)行了全表掃描。而且查詢使用了21.38秒。這時(shí)表還沒(méi)有經(jīng)過(guò)分析。下面我們來(lái)對(duì)該表進(jìn)行分析
- SQL> analyze table CASE_GA_AJZLZ compute statistics;
表已分析。已用時(shí)間: 00: 05: 357.63。然后再來(lái)查詢：
- SQL> select count(*) from CASE_GA_AJZLZ;
- COUNT(*)
- ----------
- 346639
- Execution Plan
- 0 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost=351 Card=1)
- 1 0 SORT (AGGREGATE)
- 2 1 INDEX (FAST FULL SCAN) OF 'PK_AJZLZ' (UNIQUE) (Cost=351
- Card=346351)
- …………………………
請(qǐng)注意，這次時(shí)間僅僅用了0.71秒！這要?dú)w功于INDEX(FAST FULL SCAN)。通過(guò)分析表，查詢使用了PK_AJZLZ索引，磁盤I/O大幅減少，速度也大幅提升！下面的實(shí)用語(yǔ)句可以
【編輯推薦】
