台灣最大程式設計社群網站
線上人數
725
 
會員總數:245213
討論主題:189087
歡迎您免費加入會員
討論區列表 >> Oracle >> <轉載oracle電子報>關於剩餘資料塊的檢驗 之3
[]  
[我要回覆]
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
<轉載oracle電子報>關於剩餘資料塊的檢驗 之3
價值 : 10 QP  點閱數:2081 回應數:0

樓主

SHOYO
門外漢
0 7
28 0
發送站內信

from: http://www.performance-insight.com/china/html/ora3/backissues_cs.html

<關於剩餘資料塊的檢驗 之3>
∼∼∼∼讀者的疑問∼∼∼∼
有位讀者問道:coalesce(結合)會自動執行嗎?Oracle的版本不同coalesce的動作就會不同嗎?只要看了這次的介紹,大家應該就能明白這兩個問題的答案。

接著上次的內容,這次要繼續介紹剩餘資料塊的檢驗。
進行「coalesce(結合)」有下面三種時間點:

1. 執行alter tablespace <表空間名>coalesce 的時候
2. 每隔5分鐘smon會自動執行一次(僅限於設定為表空間pctincrease 0以外的表空間)
3. 不論是否設定為pctincrease 0,假如不執行coalesce,就沒有足夠的空閒空間分配為extent

目前為止已經說明了1.和2.,這次我們要檢驗並說明3.的情況。為了檢驗第三種情況,要事先準備10個剩餘資料塊,每個剩餘資料塊包含20個相連資料塊。這是因為我希望各位讀者想像每20個資料塊就有一個extent邊界。

此外,coalesce是以表空間為單位,所以即使在某些TABLE中指定了一些pctincrease值,對表空間來說,還是由pctincrease是不是0決定是否進行coalesce。接下來,我們來看看smon執行coalesce的時候為了鎖定對象表空間所執行的SQL語句。下面是在Oracle 8.1的環境得到的結果。

下面是檢查剩餘資料塊狀況的SQL語句及其執行的結果。檢查剩餘資料塊的情況時,我們使用DBA_FREE_SPACE視圖。
*************************************************************
SELECT TABLESPACE_NAME,BLOCK_ID,BYTES,BLOCKS 
>FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='CRE20'
ORDER BY BLOCK_ID;

TABLESPACE_NAME  BLOCK_ID  BYTES  BLOCKS
----------------------------------------
CRE20            2         40960  20
CRE20            22        40960  20
CRE20            42        40960  20
CRE20            62        40960  20
CRE20            82        40960  20
CRE20            102       40960  20
CRE20            122       40960  20
CRE20            142       40960  20
CRE20            162       40960  20
CRE20            182       40960  20
*************************************************************



要判斷資料塊是否連續,只要看BLOCK_ID+BLOCKS是不是下一行的BLOCK_ID就行了。(例如:第1行的BLOCK_ID=2 + BLOCKS=20等於下一行的BLOCK_ID=22)在這種狀態下執行create table建立30個initial資料塊,剩餘資料塊的狀態如下。 (如果db_block_size=2k就指定INITIAL 60k)

*************************************************************
TABLESPACE_NAME  BLOCK_ID  BYTES  BLOCKS
----------------------------------------
CRE20            2         40960  20
CRE20            52        20480  10 (確定BLOCK_ID 22∼51是INITIAL)
CRE20            62        40960  20
CRE20            82        40960  20
CRE20            102       40960  20
CRE20            122       40960  20
CRE20            142       40960  20
CRE20            162       40960  20
CRE20            182       40960  20
*************************************************************



含有BLOCK_ID 22到51這30個資料塊的表被建立,所以剩餘資料塊在物理上被切斷了。不論再怎麼結合,實際上不相鄰的剩餘資料塊永遠不會合併在一起。

通常每隔5分鐘smon就會自動執行的結合動作一下子就結束了, 但是我曾經看過有的site會持續不斷的執行結合動作。那是正在進行大型的表的truncate處理或drop table處理步驟很多的site。持續不斷進行結合,每個instance中唯一的ST enqueue會不停重複等待狀態。在這種site,就在表空間指定pctincrease為0,不要讓smon執行結合,可以減輕系統的負荷。因為Oracle資料庫內部有一項功能,不管有沒有設定pctincrease為0,都會在必要的時候將內部相鄰的extent互相結合。

本篇文章發表於2005-04-20 12:49
別忘捐VP感謝幫助你的人 新手會員瞧一瞧
目前尚無任何回覆
   

回覆
如要回應,請先登入.