zhouweifeng

«	八月 2008	»
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

===========================================================

X$BH

===========================================================

X$BH里的几个字段的含义：

state:

0, FREE, no valid block image
1, XCUR, a current mode block, exclusive to this instance
2, SCUR, a current mode block, shared with other instances
3, CR, a consistent read (stale) block image
4, READ, buffer is reserved for a block being read from disk
5, MREC, a block in media recovery mode
6, IREC, a block in instance (crash) recovery mode

SQL> select
2 o.object_name,
3 decode(state,0,'free',1,'xcur',2,'scur',3,'cr', 4,'read',5,'mrec',
4 6,'irec',7,'write',8,'pi') state,
5 count(*) blocks
6 from x$bh b, dba_objects o
7 where b.obj = o.data_object_id
8 and o.object_name = 'WWF_TEST'
9 group by o.object_name, state
10 order by blocks desc;

OBJECT_NAME STATE BLOCKS
-------------------- ----- ----------
WWF_TEST xcur 19

FREE: not currently in use
XCUR: exclusive
SCUR: shared current
CR: CR block
READ: being read from disk
MREC: in media recovery mode
IREC: in instance recovery mode
WRITE: writing to disk
PI: past image block involved in cache fusion block transfer

lru_flag
LRU_FLAG=2，表示块在LRU list的冷端，
LRU_FLAG=8，表示块在LRU list的热端
LRU_FLAG=0，表示没有标识。

隐含参数_db_aging_hot_criteria表示了如果tch大于这个数，那么
该块将被移到LRU list的热端。缺省为2.
隐含参数_db_percent_hot_default表示热端占整个buffer的比例，
缺省为50%.
SQL> select i.ksppinm parameter, v.ksppstvl VAL
2 from x$ksppi i, x$ksppcv v
3 where i.indx = v.indx
4 and i. ksppinm in ('_db_percent_hot_default',
5 '_db_aging_hot_criteria');

PARAMETER VAL
---------------------------------------
_db_percent_hot_default 50
_db_aging_hot_criteria 2

在对一个有着接近四十万条记录的表执行完全表扫描后，

执行如下命令：
alter session set events 'immediate trace name buffers level 4';

节选导出的文件：
CHAIN: 1112 LOC: 0x6A66685C HEAD: [657ddef0,657ddef0]
BH (0x657DDEF0) file#: 11 rdba: 0x02c04087 (11/16519) class 1 ba: 0x65208000
set: 3 dbwrid: 0 obj: 30908 objn: 30908
hash: [6a66685c,6a66685c] lru: [657dde7c,657ddff4]
LRU flags: moved_to_tail
ckptq: [NULL] fileq: [NULL]
st: XCURRENT md: NULL rsop: 0x00000000 tch: 0
flags: only_sequential_access
LRBA: [0x0.0.0] HSCN: [0xffff.ffffffff] HSUB: [255] RRBA: [0x0.0.0]
buffer tsn: 12 rdba: 0x02c04087 (11/16519)
scn: 0x0000.000af5f5 seq: 0x02 flg: 0x04 tail: 0xf5f50602
frmt: 0x02 chkval: 0x6af6 type: 0x06=trans data
Block header dump: 0x02c04087
Object id on Block? Y
seg/obj: 0x78bc csc: 0x00.af5ee itc: 3 flg: - typ: 1 - DATA
fsl: 0 fnx: 0x0 ver: 0x01

可以看到，state为XCURRENT，
flags为only_sequential_access
LRU flags为: moved_to_tail
表示该数据块经历了依次全表扫描，它被移到LRU的冷端，随时都可能被age out。

查询快（11，16519）块的flag，得到：
SQL> select class, flag, state, lru_flag from x$bh
2 where dbarfil = 11 and dbablk = 16519;

CLASS FLAG STATE LRU_FLAG
---------- ---------- ---------- ----------
1 524288 1 3

flag为524288，也就是第20位被置为1，因为执行了“only_sequential_access”。
flag中，每位代表如下含义：
bit bit
0 buffer_dirty 14 stale
1 notify_after_change 15 deferred_ping
2 mod_started 16 direct_access
3 block_has_been_logged 17 hash_chain_dump
4 temp_data 18 ignore_redo
5 being_written 19 only_sequential_access
6 waiting_for_write 20 prefetched_block
7 multiple_waiters 21 block_written_once
8 recovery_reading 22 logically_flushed
9 unlink_from_lock 23 resilvered_already
10 down_grade_lock 25 redo_since_read
11 clone_being_written 29 plugged_from_foreign_db
12 reading_as_CR 30 flush_after_writing
13 gotten_in_current_mode

查看全文

zhouwf0726 发表于:2007.03.30 13:07 ::分类: ( oracle体系结构 ) ::阅读:(512次) :: 评论 (0) :: 引用 (0)

===========================================================

Oracle System Change Number (SCN) Number(转)

===========================================================

SCN是當Oracle資料更新後，由DBMS自動維護去累積遞增的一個數字。當一個交易commit時，LGWR會將log buffer寫入redo log file，同時也會將該筆交易的 SCN同步寫入到redo log file內(wait-until-completed)。因此當你commit transaction時，在交易成功的訊息返回之前，LGWR必須先完整的完成上述行為之後，否則你是看不到提交成功的回應訊息。

我們可以查詢目前系統最新的SCN

select dbms_flashback.get_system_change_number from dual;

可以理解的，這裡返回的SCN，也是目前redo log file最新的SCN紀錄。因為commit後的交易才會有SCN，而一旦commit就會立刻寫入redo log file中。

CHECKPOINT 和 SCN 的關連

checkpoint發生的目的就是要把儲存在buffer內的已提交交易寫回disk，否則一旦發生crash，需要進行recovery時，你就必須花很多的時間從redo log file內最後的SCN交易開始進行recovery，這樣在商業應用上是很浪費時間和沒有效率的。

重點在於當commit一個交易時，只會立刻將redo buffer寫入redo log file內，但是並不會馬上將該update後的block(dirty block)同步寫回disk datafile中，這是為了減少過多disk IO的考量，所以採取batch的方式寫入。

When a checkpoint occurs, Oracle must update the headers of all datafiles to record the details of the checkpoint. This is done by the CKPT process. The CKPT process does not write blocks to disk; DBWn always performs that work.

在shutdown normal or shutdown immediate下，也就是所謂的clean shutdown，checkpoint也會自動觸發，並且把SCN紀錄寫回。當發生checkpoint時，會把SCN寫到四個地方去。三個地方於control file內，一個在datafile header。

Control file三個地方為

1.System checkpoint SCN ===========> (SYSTEM CHECKPOINT SCN in control file)

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
--------------------
292767

2.Datafile checkpoint SCN ===============> (DATAFILE CHECKPOINT SCN in control file)

SQL> select name,checkpoint_change#
from v$datafile where name like '%users01%';

NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 292767

3.Stop SCN ======================> (STOP SCN in control file)

SQL> select name,last_change#
from v$datafile where name like '%users01%';

NAME LAST_CHANGE#
----------------------------------- ------------
/u02/oradata/OMFD1/users01.dbf

正常datafile在read-write mode咦飨拢琇ast_change#一定是NULL

另外一個地方在datafile header內

4.Start SCN ================================> (DATAFILE HEADER)

SQL> select name,checkpoint_change#
from v$datafile_header where name like '%users01%';

NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 292767

為什麼儲存在CONTROL FILE中要分為兩個地方(SYSTEM CHECKPOINT SCN,DATAFILE CHECKPOINT SCN ?) 當你把一個tbs設為read-only時，他的SCN會凍結停止，此時DATAFILE CHECKPOINT SCN是不會再遞增改變的，但是整體的SYSTEM CHECKPOINT SCN卻仍然會不斷遞增前進。
所以，這就是為什麼需要分別在兩個地方儲存SCN。

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

正常shutdown database後，SCN會發生什麼變化？

我們可以把資料庫開在mount mode

select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
--------------------
293184

select name,checkpoint_change#,last_change# from v$datafile where name like '%user%';

NAME CHECKPOINT_CHANGE# LAST_CHANGE#
----------------------------------- -------------------- --------------
/u02/oradata/OMFD1/users01.dbf 293184 293184

可以看到儲存在control file中的三個SCN位置都是相同，注意此時的stop scn不會是NULL，而是等於start scn

我們也來查詢datafile header SCN:

select name,checkpoint_change# from v$datafile_header where name like '%users01%';

NAME CHECKPOINT_CHANGE#
----------------------------------- --------------------
/u02/oradata/OMFD1/users01.dbf 293184

當clean shutdown 時，checkpoint會進行，並且此時datafile的stop scn和start scn會相同。等到我門開啟資料庫時，Oracle檢查datafile header中的start scn和存於control file中的datafile的scn是否相同，如果相同，接著檢查start scn和stop scn是否相同，如果仍然相同，資料庫就會正常開啟，否則就需要recovery... 等到資料庫開啟後，儲存在control file中的stop scn就會恢復為NULL值，此時表示datafile是open在正常模式下了。

如果不正常SHUTDOWN (shutdown abort)，則mount資料庫後，你會發現stop scn並不是等於其他位置的scn，而是等於NULL，這表示Oracle在shutdown時沒有進行checkpoint，下次開機必須進行crash recovery。

crash recovery

必須先進行roll forward(從redo log file中從目前的start SCN開始，重做後面的已提交之交易)
再從roll back segment 做rollback未完成(dead transaction)交易

檢驗controlfile中的SCN會等於datafile header的SCN

select 'controlfile' "SCN location",name,checkpoint_change#
from v$datafile where name like '%users01%'
union
select 'file header',name,checkpoint_change#
from v$datafile_header where name like '%users01%';

SCN location NAME CHECKPOINT_CHANGE#
-------------- ----------------------------------- --------------------
controlfile /u02/oradata/OMFD1/users01.dbf 293188
file header /u02/oradata/OMFD1/users01.dbf 293188

crash recovery vs media recovery

啟動資料庫時，如果發現STOP SCN = NULL，表示需要進行crash recovery；啟動資料庫時，如果發現有datafile header的START SCN 不等於儲存於CONTROLFILE的DATAFILE SCN，表示需要進行Media recovery

STOP SCN equal NULL ==> NEED CRASH RECOVERY
DATAFILE HEADER START SCN not equal CONTROLFILE SCN ==> NEED MEDIA RECOVERY

RECOVERY DATABASE 兩種常見問題

1) RECOVER DATABASE UNTIL CANCEL ==> OPEN DATABASE RESETLOG

==> DATAFILE HEADER SCN一定會小於CONTROLFILE的DATAFILE SCN

如果你有進行RESTORE DATAFILE，則該RESTORE的DATAFILE HEADER SCN一定會小於目前CONTROLFILE的DATAFILE SCN，此時會無法
開啟資料庫，必須進行media recovery~~重做archive log直到該datafile header的SCN=current scn

restore datafile後，可以mount database然後去檢查controlfile and datafile header的SCN

SCN location NAME CHECKPOINT_CHANGE#
-------------- ----------------------------------- --------------------
controlfile /u02/oradata/OMFD1/users01.dbf 313551
file header /u02/oradata/OMFD1/users01.dbf 313401

2) RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE; ===> OPEN DATABASE RESETLOG

==> DATAFILE HEADER SCN一定會大於CONTROLFILE的DATAFILE SCN

如果只是某TABLE被DROP掉，沒有破壞資料庫整體資料結構，還可以用INCOMPLETE RECOVERY解決如果是某個TABLESPACE OR DATAFILE被DROP掉，因為檔案結構已經破壞，目前的CONTROL FILE內已經沒有該DATAFILE的資訊，就算你只RESTORE DATAFILE然後進行INCOMPLETE RECOVERY也無法救回被DROP的DATA FILE。

只好RESOTRE 之前備份的CONTROL FILE(裡頭被DROP DATAFILE Metadata此時還存在)，不過RESTOREC CONTROL FILE後此時Oracle會發現CONTROL FILE內的SYSTEM SCN會小於目前的DATAFILE HEADER SCN，也不等於目前儲存於LOG FILE內的SCN，此時就必須使用RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE到DROP DATAFILE OR DROP TABLESPACE之前的SCN。

另一種特殊狀況就是，萬一不幸地所有CONTROL FILE都遺失了，也必須用這種方式救回，所以請做MULTIPLEXING。

查看全文

zhouwf0726 发表于:2007.03.25 09:58 ::分类: ( oracle体系结构 ) ::阅读:(815次) :: 评论 (0) :: 引用 (0)

===========================================================

select操作产生redo---oracle延迟块清除

===========================================================

有时候我们在执行select操作的时候也可能会产生redo，其一个可能原因就是oracle块清除。

查看全文

zhouwf0726 发表于:2007.03.19 14:56 ::分类: ( oracle体系结构 ) ::阅读:(731次) :: 评论 (3) :: 引用 (0)

===========================================================

Oracle的全文检索技术(转)

===========================================================

Oracle一直致力于全文检索技术的研究，当Oracle9i Rlease2发布之时，Oracle数据库的全文检索技术已经非常完美，Oracle Text使Oracle9i具备了强大的文本检索能力和智能化的文本管理能力。Oracle Text是Oracle9i采用的新名称，在Oracle8/8i中它被称作Oracle interMedia Text。使用Oracle Text，可以方便而有效地利用标准的SQL工具来构建基于文本的新的开发工具或对现有应用程序进行扩展。应用程序开发人员可以在任何使用文本的Oracle数据库应用程序中充分利用Oracle Text搜索，应用范围可以是现有应用程序中可搜索的注释字段，也可是实现涉及多种文档格式和复杂搜索标准的大型文档管理系统。Oracle Text支持Oracle数据库所支持的大多数语言的基本全文搜索功能。
虽然大多数大型数据库都支持全文检索，但Oracle在这方面无疑是最出色的。Oracle能搜索多种格式的文档，如Word,Execl,PowerPoint,Html,PDF等等。但在使用中也发现有遗憾的地方，Oracle Text无论使用何种过滤器（INSO_FILTER或NULL_FILTER）及何种词法分析器（BASIC_LEXER, CHINESE_VGRAM_LEXER还是CHINESE_LEXER）都不能检索出中文内容的文本文档（TXT,RTF）。查看全文

zhouwf0726 发表于:2007.03.05 10:38 ::分类: ( oracle体系结构 ) ::阅读:(538次) :: 评论 (0) :: 引用 (0)

===========================================================

ORACLE DSI(转)

===========================================================

什么是DSI?.
就把这做为第一个题目.

DSI是Data Server Internals的缩写,是Oracle公司内部用来培训Oracle售后工程师使用的教材.
这样的文档上通常都印着:Oracle Confidential:For internal Use Only.

所以传播这类文档通常是为Oracle所禁止的,但是因为一些特殊的原因,这些文档在民间也多有流传.
你可以从Google找到一些相关信息.但是关于任何DSI教材的交流,索取都是相当敏感的.

很多人因为文档机密所以趋之若鹜,这也许是不适当的.
对于初学者,这些文档是不适宜的,因为从这里开始相对艰深,这些教材需要阅读者具有相当深厚的技术基础;初学者应该从基础学起,当你打好基础之后,也学有一天,你就可以来阅读这些文档.

DSI可以称得上是Oracle的终极培训教程.
统统被标记为:Oracle Confidential.

最近,这些DSI教程纷纷现身江湖,现在推荐一些链接给大家:

DSI301-308 + DSI401
DSI401~DSI403
DSI401e + DSI404
DSI405 Performance Tuning
DSI408 Real Application Clusters Internals

DSI虽然是好教材,但是内容极深,没有深厚的基础是不适合阅读的,尤其是初学者,过早涉猎这些教材反而没有多大益处.

所以当这些东西出现时,大家有兴趣的可以收藏,闲暇时可以翻阅,但是切记万丈高楼从地起,学习一定要打牢基础.

其实Oracle的官方文档是我们学习最好的开始和基础教程.而Tahiti站点更是我们应该经常学习的地方.

zhouwf0726 发表于:2007.01.22 17:58 ::分类: ( oracle体系结构 ) ::阅读:(697次) :: 评论 (0) :: 引用 (0)

===========================================================

LMT和DMT下存储参数的异同(转)

===========================================================

假设当前数据库的DB_BLOCK_SIZE为D（K），建表的DDL设定了INITIAL为T,MINEXTENTS为S,PCTINCREASE为P,NEXT为N
本文的DB_BLOCK_SIZE=8K
1、字典管理
MIN_EXTENT：可以是大于0的任意整数
PCT_INCREASE：
INITIAL:，则如果建表时设定的INITIAL设定的值大于2*D，则实际INITIAL=CEIL(T/D)*D；如果建表时设定的INITIAL设定的值小于等于2*D，则实际INITIAL值为2*D。
如：EXP-1
create table test1
(
a number
)
tablespace system--字典管理表空间
storage
(
initial 1k
next 1k
minextents 4
pctincrease 20
);

在这个例子中，实际INITIAL为16K；

EXP-2
create table test2
(
a number
)
tablespace system--字典管理表空间
storage
(
initial 100k
next 100k
minextents 4
pctincrease 20
);
在这个例子中，实际的INITIAL=CEIL(100/8)*8=104

NEXT：
如果S=1,则实际的NEXT=CEIL(INITIAL*(1+P/100)/N)*N,其中INITIAL为实际值，而不是设定值；
如果S>1，则NEXT的实际值为S=1的情况下的第S+1个extent的值
EXP-3
create table test1
(
a number
)
tablespace system--字典管理表空间
storage
(
initial 100k
next 100k
minextents 1
pctincrease 20
);

在本例中，实际的NEXT=CEIL(104*1.2/8)*8=128
EXP-4
create table test1
(
a number
)
tablespace system--字典管理表空间
storage
(
initial 100k
next 100k
minextents 4
pctincrease 20
);

在本例中，实际的NEXT=192。
第二个EXTENT=INITIAL=104

SQL> select ceil(104*1.2/8)*8 from dual;（第3个EXTENT）

CEIL(124.8/8)*8
---------------
128

SQL> select ceil(128*1.2/8)*8 from dual;（第4个EXTENT）

CEIL(128*1.2/8)*8
-----------------
160

SQL> c/128/160
1* select ceil(160*1.2/8)*8 from dual;（第5个EXTENT）
SQL> /

CEIL(160*1.2/8)*8
-----------------
192

在本例中，NEXT=192K

2、本地管理

在创建表空间和创建表时，都可以设置storage参数。其中表的storage参数的优先级大于表空间的参数。如果建表时没有指定storage，则oracle会继承表所对应的表空间的存储参数。

INITIAL
LMT下，oracle在表空间一级不能设定NEXT, PCTINCREASE, MINEXTENTS, MAXEXTENTS，但在段一级可以设定这几个参数（如在建表、索引的时候）。如果在段一级设定了这几个参数，则这几个参数将用来计算段的INITIAL值，此时段的INITIAL值将不是设定值，而是通过计算得到。
如果LMT表空间不是UNIFORM，则：
EXP-5
create table test
(
a number
)
storage
(
initial 100k
next 100k
minextents 4
pctincrease 100
);

该表所在表空间为本地管理的，这个表的实际的INITIAL为832K。
在LMT下，extent都是以64K为基本单位的，其初始的extent一般为64K。在本例中，MINEXTENTS为4，则前四个extent的实际大小分别为：
104K-104K-208K-416K(PCTINCREASE 100，参考DICT下INITIAL的计算方法)
所以，本例中INITIAL=104+104+208+416=832K。由于LMT下的EXTENT最小单位是64K，832刚好是64的倍数，所以oracle分配13个extents给INITIAL；如果计算得到的INITIAL不是64K的整数倍，oracle会按一下方法计算并分配：
CEIL(INITIAL/64)*64

如果LMT是UNIFORM(UNIT SIZE=16K)，则
EXP-6
create table test
(
a number
)
tablespace t_uniform
storage
(
initial 100k
next 100k
minextents 4
);

则INITIAL=104+104+104+104=416，建表时oracle分配了26个extent给test

LMT下，PCTINCREASE, NEXT参数将不复存在（不能修改）

http://space6212.itpub.net/post/12157/230765

zhouwf0726 发表于:2006.12.28 11:46 ::分类: ( oracle体系结构 ) ::阅读:(581次) :: 评论 (3) :: 引用 (0)

===========================================================

Oracle9i自动分段空间管理改善分段存储(转)

===========================================================

为了保持其最强大和最灵活数据库的地位，Oracle在最近发布的几个版本里一直都在创建新的机制来对表格和索引的存储进行简化和分块。从Oracle8i开始，Oracle开始在tablespace内部将对象管理进行自动化。第一个增强的地方原来叫做本地管理tablespace（或者简写作LMT）。在LMT里，Oracle将tablespace里的信息从数据字典的表格空间里移出去，而直接将其保存到tablespace自身里。这在Oracle9i里已经成为了一个事实的标准，因为它减轻了数据字典的负担。

表格空间的第二个主要增强的是自动分段空间管理（ASSM），它首次出现在Oracle9i里。有了ASSM，链接列表freelist被位图所取代，它是一个二进制的数组，能够迅速有效地管理存储扩展和剩余区块（free block），因此能够改善分段存储本质。

管理空间的两种方法

让我们从比较这两种空间管理开始：

本地管理tablespace（LMT）——LMT是通过把EXTENT MANAGEMENT LOCAL子句添加到tablespace的定义句法而实现的。和原来由字典管理的tablespace（DMT）不同，LMT会将扩展管理自动化，并保持Oracle DBA不会被用来指定管理扩展大小的NEXT存储参数。这个原则唯一的例外是在NEXT和MINEXTENTS一起用在表格创建的时候。

自动区段空间管理（ASSM）——ASSM的tablespace是通过将SEGMENT SPACE MANAGEMENT AUTO子句添加到tablespace的定义句法里而实现的。通过使用位图freelist取代传统单向的链接列表freelist，ASSM的tablespace会将freelist的管理自动化，并取消为独立的表格和索引指定PCTUSED、FREELISTS和FREELIST GROUPS存储参数的能力。

Oracle值得赞扬的地方是，这两个空间管理的方法都是可选的特性，而且Oracle的老手可能仍会使用更加详细的方法，只要他们愿意的话。要注意，位图区段管理在Oracle9i里是可选的，而且只能在tablespace这一层实现，这一点是十分重要的。原有的系统还能够继续使用传统方法来管理freelist。

位图freelist挑战传统的空间管理

在我讨论位图freelist和传统的空间管理之前，让我们看看位图freelist是如何实现的。我会从使用区段空间管理自动参数创建tablespace开始：

　　
　　create tablespace
　　　 asm_lmt_ts
　　datafile
　　　 'c:oracleoradatadiogenesasm_lmt.dbf'
　　size
　　　 5m
　　EXTENT MANAGEMENT LOCAL　　　 -- Turn on LMT
　　SEGMENT SPACE MANAGEMENT AUTO -- Turn on ASSM
　　;

一旦你定义好了tablespace，那么表格和索引就能够使用各种方法很容易地被移动到新的tablespace里。下面就是我进行创建的代码：

　　
　　 
　　create table
　　　 new_cust
　　tablespace
　　　 assm_lmt_ts
　　as
　　　 select * from customer;
　　 
　　alter index cust_name_idx rebuild tablespace assm_lmt_ts;

要注意，当表格或者索引被分配到这个tablespace以后，用于独立对象的PCTUSED的值会被忽略，而Oracle9i会使用位图数组来自动地管理tablespace里表格和索引的freelist。对于在LMT的tablespace内部创建的表格和索引而言，这个NEXT扩展子句是过时的，因为由本地管理的tablespace会管理它们。但是，INITIAL参数仍然是需要的，因为Oracle不可能提前知道初始表格加载的大小。对于ASSM而言，INITIAL最小的值是三个区块。

关于一个万能的方法对于Oracle来说是否是最好的方法还有一些争论。在大型数据库里，单独的对象设置会带来性能和存储上的巨大不同。

PCTFREE的问题

PCTFREE参数是用来指定数据块剩余空间大小的，这一空间为将来数据行的扩展而保留。如果PCTFREE设置得不得当，SQL的更新声明就可能导致大量的数据行碎片和断链。

数据行在刚保存的时候还很小，而在后来进行了扩展，在这种情况下，PCTFREE的设置就显得尤其重要了。在这样的系统里，通常会把PCTFREE设置成等于95，这就告诉Oracle要为数据行今后的扩展保留95％的数据区段空间。

PCTUSED的问题

对PCTUSED不正确的设置（例如设得太小了）会导致SQL插入声明性能的急剧下降。如果数据区块剩余空间不是很多，那么在SQL插入操作的过程中就会产生过量的I/O，这是因为被重新使用的Oracle数据区块会被迅速地填满。从极端的角度来看，没有正确地设置PCTUSED会导致数据区块的剩余空间要比表格数据行的平均长度小。在这样的情况下，Oracle会五次尝试从freelist链取回区块。在五次尝试以后，Oracle会提升表格的水位，并为插入操作腾出五个新的数据块。

有了Oracle9i的ASSM，PCTUSED就不再控制表格数据块的重新链接阙值了，但是你必须依靠Oracle的判断来确定区块在什么时候会有足够的剩余空间放置到freelist里。

尽管有了本地管理的tablespace和ASSM之后Oracle9i会忽略PCTUSED、FREELISTS和FREELIST GROUPS等参数，但是当它们用于表格定义的时候，Oracle还是不会给出错误信息：

　　
　　SQL> create table
　　2 test_table
　　3 (c1 number)
　　4 tablespace
　　5 asm_test
　　6 pctfree 20 pctused 30
　　7 storage
　　8 ( freelists 23 next 5m ) ;
　　Table created.

如果你不记得带有ASSM的本地管理tablespace会略掉任何为PCTUSED、NEXT和FREELISTS所指定的值的话，这将是一个十分严重的问题。.

使用ASSM的一个巨大优势是，位图freelist肯定能够减轻缓冲区忙等待（buffer busy wait）的负担，这个问题在Oracle9i以前的版本里曾是一个严重的问题。现在让我们来仔细看看这个特性。

缓冲区不再忙等待

在没有多个freelist的时候，每个Oracle表格和索引在表格的头部都曾有一个数据块，用来管理对象所使用的剩余区块，并为任何SQL插入声明所创建的新数据行提供数据块。当数据缓冲内的数据块由于被另一个DML事务处理锁定而无法使用的时候，缓冲区忙等待就会发生。当你需要将多个任务插入到同一个表格里的时候，这些任务就被强制等待，而同时Oracle会在同时分派剩余的区块，一次一个。

有了ASSM之后，Oracle宣称显著地提高了DML并发操作的性能，因为（同一个）位图的不同部分可以被同时使用，这样就消除了寻找剩余空间的串行化。根据Oracle的测试结果，使用位图freelist会消除所有分段头部（对资源）的争夺，还能获得超快的并发插入操作。

ASSM的局限性

尽管ASSM显示出了令人激动的特性并能够简化Oracle DBA的工作，但是Oracle9i的位图分段管理还是有一些局限性的：

一旦DBA被分配之后，它就无法控制tablespace内部的独立表格和索引的存储行为。

大型对象不能够使用ASSM，而且必须为包含有LOB数据类型的表格创建分离的tablespace。

你不能够使用ASSM创建临时的tablespace。这是由排序时临时分段的短暂特性所决定的。

只有本地管理的tablespace才能够使用位图分段管理。

使用超高容量的DML（例如INSERT、UPDATE和DELETE等）的时候可能会出现性能上的问题。

zhouwf0726 发表于:2006.12.27 17:26 ::分类: ( oracle体系结构 ) ::阅读:(463次) :: 评论 (0) :: 引用 (0)

===========================================================

Latch free等待事件四(转)

===========================================================

n 尽量减每个块中的记录数。首先需要dump一些数据块来分析现在每个块中的记录数。Dump出来的跟踪文件中，nrow就是块中的记录总数。然后exp表，再truncate表，在表中插入你想要在每个块中保存的条数的记录，然后使用alter table table_name minimize records_per_block，再truncate表，最后imp回数据即可。

n 可以考虑减少块的大小。从oracle9i开始，数据库可以支持不同的块大小。例如当前块大小为16k，你可以将表及其索引移动块大小为8k的表空间中。这也会对全表扫描造成负面影响。并且，多个块大小也会使得管理更复杂。

另外，从oracle9iR2开始，也可以通过增加隐含参数_spin_count的值来解决热点块导致的cache buffers chains latch争用。最后，也可以通过隐含参数_db_block_hash_buckets来增加hash bucket的数量，从oracle8i开始，一般不建议采用这种办法，如果实在要用，请保证_db_block_hash_buckets的值为一个质数，否则，oracle也会自动采用大于你提供的值的最小的质数值。

Cache buffers chains latch争用原因三 ―― 过长的hash chain

多个数据块可能分配到同一个hash bucket上。这些块组成一个链表(hash chain)。在一个大型系统中，一个hash bucket中可能有上百个数据块。从一个hash chain链表中搜索某个块，需要获得cache buffers chains latch，串行的进行。如果链表太长，使得latch持有时间相应增加，可能导致其他进程请求cache buffers chains latch失败。

在oracle8.0之前，由于hash latch，hash bucket，hash chain之间是1:1:1的关系，很容易计算一个hash chain的长度，等于一个latch需要保护的数据块数。通过下面的查询可以知道一个hash chain上的数据块数。一般而言，一个hash chain链表上超过10个数据块就认为太长了。

Select hladdr, count(*)
from x$bh
group by hladdr
order by 2;

从oracle8i起，hash latch和hash bucket之间的关系变成了1:m。这样就很难计算某个hash chain具体的长度了。只能计算一个hash latch需要保护多少个数据块。而一个hash latch可能同时保护多个hash chain链表。上面的那个查询的结果变成了每个hash latch需要保护的数据块数。在你判断一个hash latch保护的数据块是否过量之前，需要先得到hash latch和hash bucket的比值。在下面的例子中，每个hash latch保护125个hash chain。如果你想要每个hash chain上不超过10个数据块，则每个hash latch保护的数据块不能超过1250个。通过隐含参数_db_block_hash_buckets可以增加hash bucket的数目，这样可以减少每个hash chain上的数据块数（因为hash bucket和hash chain之间是1:1的关系）。从oracle8i开始，一般不建议这么做。

_db_block_hash_buckets = 128021

_db_block_hash_latches = 1024

ratio = 128021 / 1024 = 125

Cache buffers lru chain latch

除了hash chain，缓冲头同样组成一个列表，这个列表指向其他的列表比如lru，lruw和ckpt-q。Lru和lruw列表并不是什么新东西，他们是数据缓冲区中最早的两个链表。Lru列表包含了不同状态的缓存块，而lruw就是俗称的“脏表”，只包含脏数据块。Lru和lruw列表是互斥的，他们合称一个工作集(a working set)。每个工作集由一个cache buffers lru chain latch保护。换句话说，数据缓冲区中工作集的个数是由cache buffers lru chain latch的个数决定的。通过内部视图x$kcbwds (kernel cache buffer working sets descriptors)可以知道工作集的个数。我们注意到x$kcbwds 的set_latc的值就是v$latch_children的addr列。

lru + lruw = a working set

Select set_id, set_latch 

from   x$kcbwds 

order by set_id;



    set_id set_latc

　　---------- --------

         1 247e299c

         2 247e2e68

         3 247e3334

         4 247e3800

         5 247e3ccc

         6 247e4198

         7 247e4664

         8 247e4b30



select addr 

from   v$latch_children 

where name = ’cache buffers lru chain’ 

order by addr;



addr

--------

247e299c

247e2e68

247e3334

247e3800

247e3ccc

247e4198

247e4664

247e4b30

一般来讲，当进程需要查找可用的缓存空间时，需要访问lru列表。后台进程DBWn则会将lruw列表中的干净块移到lru列表中，也会将lru中的脏块移到lruw列表中。在一个工作集中进行以上的任何操作都需要先获得cache buffers lru chain latch。

各个数据缓冲区中（包括不同块大小的缓冲区，keep池和recycle

«	八月 2008					»
一	二	三	四	五	六	日
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Powered by:
Blog Provider:
Designed by:

«	八月 2008					»
一	二	三	四	五	六	日
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

«	八月 2008					»
一	二	三	四	五	六	日
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31