Oracle執(zhí)行計劃SQL語句執(zhí)行效率問題查找與解決方法

1、Oracle的SQL語句執(zhí)行效率問題查找與解決方法一、識別占用資源較多的語句的方法(4 種方法)1. 測試組和最終用戶反饋的與反應(yīng)緩慢有關(guān)的問題。2. 利用V_$SQLARE視圖提供了執(zhí)行的細節(jié)。(執(zhí)行、讀取磁盤和讀取緩沖區(qū)的次數(shù))? 數(shù)據(jù)列EXECUTION：執(zhí)行次數(shù)DISK_READS讀盤次數(shù)COMMAND_TYP命令類型(3:select,2:insert;6:update;7delete;47:pl/sql程序單元)OPTIMIZER_MODE優(yōu)化方式SQL_TEX：T Sql 語句SHARABLE_MEM占用 shared pool 的內(nèi)存多少 BUFFER_GETS讀取緩沖區(qū)的次數(shù)

2、? 用途1、幫忙找出性能較差的 SQL語句2、幫忙找出最高頻率的 SQL3、幫忙分析是否需要索引或改善聯(lián)接3. 監(jiān)控當前 Oracle 的 session ，如出現(xiàn)時鐘的標志，表示此進程中的 sql 運行時間較長。4. Trace 工具：a) 查看數(shù)據(jù)庫服務(wù)的初始參數(shù)： timed_statistics 、 user_dump_dest 和 max_dump_file_sizeb) Step 1: alter session set sql_trace=truec) Step 2: run sql ；d) Step 3: alter session set sql_trace=falsee)

3、Step 4: 使用 “ TKPRO”F 轉(zhuǎn)換跟蹤文件f) Parse，解析數(shù)量大通常表明需要增加數(shù)據(jù)庫服務(wù)器的共享池大小，query 或 current 提取數(shù)量大表明如果沒有索引，語句可能會運行得更有效，disk 提取數(shù)量表明索引有可能改進性能，library cache 中多于一次的錯過表明需要一個更大的共享池大小二、如何管理語句處理和選項? 基于成本( Cost Based) 和基于規(guī)則( Rule Based) 兩種優(yōu)化器， 簡稱為 CBO 和 RBO ? Optimizer Mode 參數(shù)值 :Choose：如果存在訪問過的任何表的統(tǒng)計數(shù)據(jù)，則使用基于成本的 Optimizer,目

4、標是獲得最優(yōu)的通過量。 如果一些表沒有統(tǒng)計數(shù)據(jù)， 則使用估計值。 如果沒有可用的統(tǒng)計數(shù) 據(jù)，則將使用基于規(guī)則的 OptimizerAll_rows ：總是使用基于成本的 Optimizer ，目標是獲得最優(yōu)的通過量First_rows_n :總是使用基于成本的 Optimizer ，目標是對返回前 N行“n”可以是1， 10， 100 或者 1000)獲得最優(yōu)的響應(yīng)時間First_rows ：用于向后兼容。使用成本與試探性方法的結(jié)合，以便快速傳遞前幾行RULE總是使用基于規(guī)則的 Optimizer三、使用數(shù)據(jù)庫特性來獲得有助于查看性能的處理統(tǒng)計信息(解釋計劃和AUTOTRAC)ENo1: Ex

5、plain PlanA) 使用 Explain 工具需要創(chuàng)建 Explain_plan 表，這必須先進入相關(guān)應(yīng)用表、視圖和索引的所有者的帳戶內(nèi) . (D:oracleora92rdbmsadminutlxplan)B) 表結(jié)構(gòu)：STATEMENT.：為一條指定的 SQL語句確定特定的執(zhí)行計劃名稱。如果在 EXPLANPLAN 語句中沒有使用 SET STATEMENT.,那么此值會被設(shè)為NULLOPERATION在計劃的某一步驟執(zhí)行的操作名稱，例如：Filters ，Index，Table，MargeJoins and Table 等。OPTION對 OPERATION!作的補充，例如：對一個

6、表的操作，OPERATIONS能是TABLEACCESS 但 OPTION可能為 by ROWID或 FULL。Object_Owner :擁有此 database Object 的 Schema名或 Oracle 帳戶名。O ： Database Object 名Object_type ：類型，例如：表、視圖、索引等等ID:指明某一步驟在執(zhí)行計劃中的位置。PARENT_ID指明從某一操作中取得信息的前一個操作。通過對與ID和PARENT_ID使用Connect By 操作，我們可以查詢整個執(zhí)行計劃樹。C) EXPLAIN搜索路徑解釋? 全表掃描( Full Table S

7、cans ) ( 無可用索引 ,大量數(shù)據(jù) ,小表 , 全表掃描 hints,HWM(High Water Mark), Rowid 掃描 )? 索引掃描索引唯一掃描( Index Unique Scans )索引范圍掃描( Index Range Scans ) 索引降序范圍掃描( Index Range Scans Descending ) 索引跳躍掃描( Index Skip Scans ) 全索引掃描( Full Scans ) 快速全索引掃描( Fast Full Index Scans ) 索引連接( Index Joins ) 位圖連接( Bitmap Joins )? 如何選擇訪

8、問路徑：CBO首先檢查 WHER子句中的條件以及 FROMF句，確定有哪些訪問路徑是可用的。然后CBO使用這個訪問路徑產(chǎn)生一組可能的執(zhí)行計劃，再通過索引、表的統(tǒng)計信息評估每個計劃的成本，最后優(yōu)化器選擇成本最低的一個。? 表的連接方式：Nested Loops 會循環(huán)外表(驅(qū)動表) ，逐個比對和內(nèi)表的連接是否符合條件。在驅(qū) 動表比較小， 內(nèi)表比較大， 而且內(nèi)外表的連接列有索引的時候比較好。當 SORT_AREA空間不足的時候，Oracle也會選擇使用 NL。基于Cost的Oracle優(yōu)化器(CBO)會自動選擇較小的表做外表。 (優(yōu)點：嵌套循環(huán)連接比其他連接方法有優(yōu)勢, 它可以快速地從結(jié)果集中提取

9、第一批記錄 , 而不用等待整個結(jié)果集完全確定下來。缺點： 如果內(nèi)部行源表 (讀取的第二張表(內(nèi)表)已連接的列上不包含索引,或者索引不是高度可選時, 嵌套循環(huán)連接效率是很低的。如果驅(qū)動行源表(從驅(qū)動表中提取的記錄 )非常龐大時 ,其他的連接方法可能更加有效 。)SORT-mergeJOIN,將兩表的連接列各自排序然后合并，只能用于連接列相等的情況，適合兩表大小相若的情況 (在缺乏數(shù)據(jù)的選擇性或者可用的索引時 , 或者兩個源表都 過于龐大 (超過記錄數(shù)的 5%)時, 排序合并連接將比嵌套循環(huán)連更加高效。但是,排列合并連接只能用于等價連接 (WHERE D.deptno=E.dejptno, 而不是

10、 WHERE D.deptno>=E.deptno) 。排列合并連接需要臨時的內(nèi)存塊 ,以用于排序 (如果 SORT_AREA_SIZ設(shè)置得太小的話)。這將導致在臨時表空間占用更多的內(nèi)存和磁盤I/O。HASH JOIN在其中一表的連接列上作散列，因此只有另外一個表做排序合并，理論上比SORT JOIN會快些，需要有足夠的內(nèi)存，而且打開了SORT_JOIN_ENABL參數(shù)。（當缺少有用的索引時，哈希連接比嵌套循環(huán)連接更加有效。哈希連接可能比排序 合并連接更快，因為在這種情況下只有一張源表需要排序。哈希連接也可能比嵌套 循環(huán)連接更快，因為處理內(nèi)存中的哈希表比檢索BJ樹索引更加迅速。和排序合并

11、連接、群集連接一樣，哈希連接只能用于等價連接。和排序合并連接一樣，哈希連接 使用內(nèi)存資源，并且當用于排序內(nèi)存不足時，會增加臨時表空間的I/O （這將使這種連接方法速度變得極慢）。最后，只有基于代價的優(yōu)化器才可以使用哈希連接。）索引連接：No2: AUTOTRACE? set autotrace 使用步驟：1、以system登錄2、創(chuàng)建 plustrace 角色;<your_oracle_home>sqlplusadminplustrce.sql3、 向常規(guī)用戶授予權(quán)限：gran tplustrace to <user id>4、如果沒有 plan_table 也要創(chuàng)建:

12、<your_oracle_home>rdbmsadminutlxplan.sql ? set autotrace 選項on顯示查詢結(jié)果，執(zhí)行計劃，統(tǒng)計數(shù)據(jù)on statistics顯示查詢結(jié)果，統(tǒng)計數(shù)據(jù)，不顯示執(zhí)行計劃on expla in顯示查詢結(jié)果，執(zhí)行計劃，不顯示統(tǒng)計數(shù)據(jù)trace only顯示執(zhí)行計劃和統(tǒng)計結(jié)果，但不包括查詢結(jié)果trace only statistics僅顯示統(tǒng)計數(shù)據(jù)在用戶級別和系統(tǒng)級別上生成的遞歸調(diào)用的數(shù)量。ecursive callsOracle維護了一些用于內(nèi)部處理的表。 當oracle需要 對這些表進行更改時，它就會在內(nèi)部生成一個 SQL語 句，然后

13、這個語句再生成一個遞歸調(diào)用。db block gets請求一個CURRENT的次數(shù)con siste nt gets為一塊請求 consistent read的次數(shù)physical reads從磁盤讀取得數(shù)據(jù)塊總數(shù)。這個數(shù)量等于“直接物理 讀取”的值加上讀入緩沖區(qū)的所有數(shù)據(jù)塊redo size生成的重做的總數(shù)量（以字節(jié)為單位）bytes sen t via SQL * Net to clie nt從前臺進程發(fā)送給客戶的總字節(jié)數(shù)bytes received via SQL * Net rom clie nt通過Oracle Net從客戶接收的總字節(jié)數(shù)SQL*Net roun dtrips to/

14、from clie nt發(fā)送給客戶和從客戶接收的Oracle Net消息的總數(shù)sorts (memory)完全在內(nèi)存中執(zhí)行并且不需要任何磁盤寫入的排序操 作的數(shù)量sorts (disk)至少需要一個磁盤寫入的排序操作的數(shù)量ows processed在操作過程中處理的行數(shù)四、最后，使用計時特性來測量和比較處理時間Set tim ing onV$sessi on_event應(yīng)觀注一下eve nt這列，這是我們調(diào)優(yōu)的關(guān)鍵一列，下面對常出現(xiàn)的 event做以簡要的說明：a、buffer busy waits， free buffer waits這兩個參數(shù)所標識是dbwr是否夠用的問題，與10很大相關(guān)的

15、，當v$session_wait中的free buffer wait的條目很小或沒有的時侯，說明你的系統(tǒng)的dbwr進程決對夠用，不用調(diào)整；free buffer wait的條目很多，你的系統(tǒng)感覺起來一定很慢， 這時說明你的dbwr已經(jīng)不夠用了，它產(chǎn)生的 wio已經(jīng)成為你的數(shù)據(jù)庫性能的瓶頸，這時的 解決辦法如下：a.1增加寫進程，同時要調(diào)整 db_block_lru_latches參數(shù)示例：修改或添加如下兩個參數(shù)db_writer_processes=4db_block_lru_latches=8a、 2開異步IO, IBM這方面簡單得多，hp則麻煩一些，可以與 Hp工程師聯(lián)系。b、db fil

16、e sequential read，指的是順序讀，即全表掃描，這也是我們應(yīng)該盡量減少的部分，解決方法就是使用索引、sql調(diào)優(yōu)，同時可以增大db_file_multiblock_read_count這個參數(shù)。c、db file scattered read,這個參數(shù)指的是通過索引來讀取，同樣可以通過增加 db_file_multiblock_read_count 這個參數(shù)來提高性能。d、latch free,與栓相關(guān)的了，需要專門調(diào)節(jié)。e、其他參數(shù)可以不特別觀注。本文的目的：1、說一說 Oracle的Optimizer及其相關(guān)的一些知識。2、 回答一下為什么有時一個表的某個字段明明有索引，當觀察

17、一些SQL的執(zhí)行計劃時，發(fā)現(xiàn)確不走索引的問 題。3、如果你對 FIRST_ROWS 、 ALL_ROWS 這兩種模式有疑惑時也可以看一下這篇文章。開始吧 :Oracle 在執(zhí)行一個 SQL 之前 ,首先要分析一下語句的執(zhí)行計劃 ,然后再按執(zhí)行計劃去執(zhí)行。分析語句的執(zhí)行 計劃的工作是由優(yōu)化器 (Optimizer) 來完成的。 不同的情況 ,一條 SQL 可能有多種執(zhí)行計劃 ,但在某一時點 , 一 定只有一種執(zhí)行計劃是最優(yōu)的 ,花費時間是最少的。相信你一定會用Pl/sql Developer 、 Toad 等工具去看一個語句的執(zhí)行計劃 ,不過你可能對 Rule 、Choose 、First ro

18、ws 、 All rows 這幾項有疑問 ,因為我當初也是這樣 的, 那時我也疑惑為什么選了以上的不同的項 ,執(zhí)行計劃就變了 ?1、優(yōu)化器的優(yōu)化方式Oracle 的優(yōu)化器共有兩種的優(yōu)化方式 ,即基于規(guī)則的優(yōu)化方式 (Rule-Based Optimization, 簡稱為 RBO) 和基 于代價的優(yōu)化方式 (Cost-Based Optimization, 簡稱為 CBO) 。A、RBO 方式： 優(yōu)化器在分析 SQL 語句時 ,所遵循的是 Oracle 內(nèi)部預(yù)定的一些規(guī)則。 比如我們常見的 ,當一 個 where 子句中的一列有索引時去走索引。B、CBO 方式：依詞義可知 ,它是看語句的代價

19、(Cost) 了 ,這里的代價主要指 Cpu 和內(nèi)存。優(yōu)化器在判斷是 否用這種方式時 ,主要參照的是表及索引的統(tǒng)計信息。 統(tǒng)計信息給出表的大小、 有少行、每行的長度等信息。 這些統(tǒng)計信息起初在庫內(nèi)是沒有的 ,是你在做 analyze 后才出現(xiàn)的 ,很多的時侯過期統(tǒng)計信息會令優(yōu)化器做 出一個錯誤的執(zhí)行計劃 ,因些我們應(yīng)及時更新這些信息。 在 Oracle8 及以后的版本 ,Oracle 列推薦用 CBO 的 方式。我們要明了 ,不一定走索引就是優(yōu)的 ,比如一個表只有兩行數(shù)據(jù) ,一次 IO 就可以完成全表的檢索 , 而此時走索 引時則需要兩次10,這時對這個表做全表掃描(full table sc

20、an)是最好的。2、優(yōu)化器的優(yōu)化模式 (Optermizer Mode)優(yōu)化模式包括 Rule,Choose,Firstrows,All rows 這四種方式 ,也就是我們以上所提及的。如下我解釋一下：Rule:不用多說，即走基于規(guī)則的方式。Choolse: 這是我們應(yīng)觀注的 ,默認的情況下 0racle 用的便是這種方式。指的是當一個表或或索引有統(tǒng)計信 息,則走 CB0 的方式,如果表或索引沒統(tǒng)計信息 ,表又不是特別的小 ,而且相應(yīng)的列有索引時 ,那么就走索引 , 走 RB0 的方式。First Rows: 它與 Choose 方式是類似的 ,所不同的是當一個表有統(tǒng)計信息時,它將是以最快的方

21、式返回查詢的最先的幾行 ,從總體上減少了響應(yīng)時間。All Rows: 也就是我們所說的 Cost 的方式 ,當一個表有統(tǒng)計信息時 ,它將以最快的方式返回表的所有的行,從總體上提高查詢的吞吐量。沒有統(tǒng)計信息則走基于規(guī)則的方式。3、如何設(shè)定選用哪種優(yōu)化模式a、 Instance 級別 我們可以通過在 init<SID>.ora 文件中設(shè)定 OPTIMIZER_MODE=RULE 、OPTIMIZER_MODE=CHOOSE 、 OPTIMIZER_MODE=FIRST_ROWS 、 OPTIMIZER_MODE=ALL_ROWS 去選用 3 所提的四種方式 ,如果 你沒設(shè)定 OPTIM

22、IZER_MODE 參數(shù)則默認用的是 Choose 這種方式。B 、Sessions 級別來設(shè)定。通過 SQL> ALTER SESSION SET OPTIMIZER_MODE=<Mode>C、語句級別這些需要用到 Hint, 比如:SQL> SELECT /*+ RULE */ a.userid,2 ,3 b.depart_name4 FROM tf_f_yhda a,5 tf_f_depart b6 WHERE a.userid=b.userid;4、為什么有時一個表的某個字段明明有索引,當觀察一些語的執(zhí)行計劃確不走索引呢？如何解決呢？A 、不走索引大

23、體有以下幾個原因早你在Instance級別所用的是 all_rows的方式早你的表的統(tǒng)計信息（最可能的原因）早你的表很小，上文提到過的Oracle的優(yōu)化器認為不值得走索引。B 、解決方法早可以修改init<SID>.ora 中的OPTIMIZER_MODE 這個參數(shù)，把它改為Rule或Choose,重起數(shù)據(jù)庫。也 可以使用 4 中所提的 Hint.早刪除統(tǒng)計信息SQL>analyze table table_name delete statistics;早表小不走索引是對的，不用調(diào)的。5、其它相關(guān)A 、如何看一個表或索引是否是統(tǒng)計信息SQL>SELECT * FROM

24、user_tables2 WHERE table_name=<table_name>3 AND num_rows is not null;SQL>SELECT * FROM user_indexes2 WHERE table_name=<table_name>AND num_rows is not null;b、如果我們先用CBO的方式，我們應(yīng)及時去更新表和索引的統(tǒng)計信息，以免生形不切合實的執(zhí)行計劃SQL> ANALYZE TABLE table_name COMPUTE STATISTICS;SQL> ANALYZE INDEX index_name

25、 ESTIMATE STATISTICS;具體的 ANALYZE 語句請參照 Oracle8i/9i 的 refrence 文檔. 確保最優(yōu)的索引使用：對于改善查詢的速度，這是特別重要的。有時Oracle 可以選擇多個索引來進行查詢，調(diào)優(yōu)專家必須檢查每個索引并且確保 Oracle 使用正確的索引。它還包括 bitmap 和基于函數(shù)的索 引的使用。. 確保最優(yōu)的 JOIN 操作：有些查詢使用 NESTED LOOP join 快一些，有些則是 HASH join 快一些， 另外一些則是 sort-merge join 更快。這些規(guī)則看來簡單，不過它們占 SQL 調(diào)優(yōu)任務(wù)的 90% ，并且它們也無

26、需完全懂得 Oracle SQL 的內(nèi) 部運作。以下我們來簡單概覽以下 Oracle SQL 的優(yōu)化。我們首先簡要查看 Oracle 的排序，并且看一看排序操作是如何影響性能的。調(diào)整 Oracle 的排序操作排序是 SQL 語法中一個小的方面，但很重要，在 Oracle 的調(diào)整中，它常常被忽略。當使用 create index、ORDER BY或者GROUP BY的語句時，Oracle 數(shù)據(jù)庫將會自動執(zhí)行排序的操作。通常，在以下 的情況下 Oracle 會進行排序的操作：使用 Order by 的 SQL 語句使用 Group by 的 SQL 語句在創(chuàng)建索引的時候進行 table join

27、時，由于現(xiàn)有索引的不足而導致 SQL 優(yōu)化器調(diào)用 MERGE SORT當與 Oracle 建立起一個 session 時，在內(nèi)存中就會為該 session 分配一個私有的排序區(qū)域。如果 該連接是一個專用的連接 (dedicated connection) ，那么就會根據(jù) init.ora 中 sort_area_size 參數(shù)的 大小在內(nèi)存中分配一個 Program Global Area (PGA) 。如果連接是通過多線程服務(wù)器建立的，那么排序的 空間就在 large_pool 中分配。不幸的是，對于所有的 session ，用做排序的內(nèi)存量都必須是一樣的，我 們不能為需要更大排序的操作分配

28、額外的排序區(qū)域。因此，設(shè)計者必須作出一個平衡，在分配足夠的排序 區(qū)域以避免發(fā)生大的排序任務(wù)時出現(xiàn)磁盤排序( disk sorts )的同時，對于那些并不需要進行很大排序 的任務(wù)， 就會出現(xiàn)一些浪費。 當然，當排序的空間需求超出了 sort_area_size 的大小時， 這時將會在 TEMP 表空間中分頁進行磁盤排序。磁盤排序要比內(nèi)存排序大概慢 14，000 倍。上面我們已經(jīng)提到，私有排序區(qū)域的大小是有 init.ora 中的 sort_area_size 參數(shù)決定的。每個排序 所占用的大小由 init.ora 中的 sort_area_retained_size 參數(shù)決定。當排序不能在分配的

29、空間中完成時， 就會使用磁盤排序的方式，即在Oracle 實例中的臨時表空間中進行。磁盤排序的開銷是很大的，有幾個方面的原因。首先，和內(nèi)存排序相比較，它們特別慢；而且磁盤排 序會消耗臨時表空間中的資源。Oracle 還必須分配緩沖池塊來保持臨時表空間中的塊。無論什么時候，內(nèi)存排序都比磁盤排序好， 磁盤排序?qū)钊蝿?wù)變慢， 并且會影響 Oracle 實例的當前任務(wù)的執(zhí)行。 還有， 過多的磁盤排序?qū)?free buffer waits 的值變高，從而令其它任務(wù)的數(shù)據(jù)塊由緩沖中移走。接著，讓我們看一下 Oracle 的競爭，并且看一下表的存儲參數(shù)的設(shè)置是如何影響SQL UPDATE和INSERT

30、 語句的性能的 調(diào)整 Oracle 的競爭Oracle 的其中一個優(yōu)點時它可以管理每個表空間中的自由空間。 Oracle 負責處理表和索引的空間管 理，這樣就可以讓我們無需懂得 Oracle 的表和索引的內(nèi)部運作。不過，對于有經(jīng)驗的 Oracle 調(diào)優(yōu)專家 來說，他需要懂得 Oracle 是如何管理表的 extent 和空閑的數(shù)據(jù)塊。對于調(diào)整擁有高的 insert 或者 update 的系統(tǒng)來說，這是非常重要的。要精通對象的調(diào)整， 你需要懂得 freelists 和 freelist 組的行為， 它們和 pctfree 及 pctused 參數(shù)的 值有關(guān)。這些知識對于企業(yè)資源計劃( ERP )

31、的應(yīng)用是特別重要的，因為在這些應(yīng)用中，不正確的表設(shè)置 通常是 DML 語句執(zhí)行慢的原因。對于初學者來說，最常見的錯誤是認為默認的 Oracle 參數(shù)對于所有的對象都是最佳的。除非磁盤的 消耗不是一個問題，否則在設(shè)置表的 pctfree 和 pctused 參數(shù)時，就必須考慮平均的行長和數(shù)據(jù)庫的塊大 小，這樣空的塊才會被有效地放到 freelists 中。當這些設(shè)置不正確時， 那些得到的 freelists 也是 "dead" 塊，因為它們沒有足夠的空間來存儲一行，這樣將會導致明顯的處理延遲。Freelists 對于有效地重新使用 Oracle 表空間中的空間是很重要的，它和

32、 pctfree 及 pctused 這兩個存 儲參數(shù)的設(shè)置直接相關(guān)。通過將 pctused 設(shè)置為一個高的值，這時數(shù)據(jù)庫就會盡快地重新使用塊。不過， 高性能和有效地重新使用表的塊是對立的。在調(diào)整 Oracle 的表格和索引時，需要認真考慮究竟需要高性 能還是有效的空間重用， 并且據(jù)此來設(shè)置表的參數(shù)。 以下我們來看一下這些 freelists 是如何影響 Oracle 的性能的。當有一個請求需要插入一行到表格中時， Oracle 就會到 freelist 中尋找一個有足夠的空間來容納一 行的塊。你也許知道， freelist 串是放在表格或者索引的第一個塊中，這個塊也被稱為段頭( segmen

33、t header )。 pctfree 和 pctused 參數(shù)的唯一目的就是為了控制塊如何在 freelists 中進出。雖然 freelist link 和 unlink 是簡單的 Oracle 功能，不過設(shè)置 freelist link (pctused) 和 unlink (pctfree) 對 Oracle 的性能確實有影響。由 DBA 的基本知識知道， pctfree 參數(shù)是控制 freelist un-links 的(即將塊由 freelists 中移除)。 設(shè)置 pctfree=10 意味著每個塊都保留 10% 的空間用作行擴展。 pctused 參數(shù)是控制 freelist re-links 的 設(shè)置 pctused=40 意味著只有在塊的使用低于 40% 時才會回到表格的 freelists 中。許多新手對于一個塊重新回到 freelists 后的處理都有些誤解。其實，一旦由于一個刪除的操作而令 塊被重新加入到 freelist 中，它將會一直保留在 freelist 中即使空間的使用超過了 60% ，只有在到達 pctfree 時才會將數(shù)據(jù)塊由 freelist 中移走。表格和索引存儲參數(shù)設(shè)置的要求總結(jié)以下的一些規(guī)則是用