bitmap 的一点探究

biti_rainy

最初由 ncgxq 发布
[B]嗯，好象是WebIV上的吧，我都记不清是从哪儿倒腾来的了，还有X$表的定义那些的，净是些mht文档。反正一个个都标着Confidential - Internal Use Only，其实资料多了也不是什么好事，能静下心看懂一本书比东一榔头西一棒子要好多了。 [/B]

所以我几乎不看 DSI

ncgxq

是啊，最基本的概念都搞不清楚却想去研究Oracle的内部细节也太可笑了。举个最简单的例子，redo log中记录了数据块的改变，很多人就想当然地把回滚块给排除在外了。就我遇到的情况，至少有80%的人是这么认为的

最初由 biti_rainy 发布
[B]

所以我几乎不看 DSI [/B]

biti_rainy

最初由 ncgxq 发布
[B]是啊，最基本的概念都搞不清楚却想去研究Oracle的内部细节也太可笑了。举个最简单的例子，redo log中记录了数据块的改变，很多人就想当然地把回滚块给排除在外了。就我遇到的情况，至少有80%的人是这么认为的
[/B]

我倒不是说这个意思
基本概念倒是应该很清楚了

只是，internal 的东西，是通过思考、实验，不停的trace/dump 得来的，这样才能融入自己的概念体系，靠看来的，是没什么意义的

ncgxq

最初由 biti_rainy 发布
[B]

我倒不是说这个意思
基本概念倒是应该很清楚了

只是，internal 的东西，是通过思考、实验，不停的trace/dump 得来的，这样才能融入自己的概念体系，靠看来的，是没什么意义的 [/B]

在internal的看法上我们并无不同，在使用上我们略有不同，但也是殊途同归吧。你是利用internal进一步深化，我着重于利用internal来印证一些基本概念，尽量使理论变得更直白一些。如用bbed、datafile dump、logfile dump结合起来演示redo的生成、锁、不同存储参数对块空间使用的影响等

NinGoo

这次终于看明白了

cainiao2

呵呵,受益非浅!

wx_jacky

关于BITMAP索引，以前一直没有什么接触。我也是这次在项目中才用到，本来觉得一个数据列的值较少。因此在这个列上面建立了BITMAP索引，但是在实际的应用中却发现性能上面出现了很多的问题。好像ORACLE对于BITMAP索引的引用不是很稳定，有时候用有时候不用。请问各位是否也出现过这样的情况，就像楼主分析的那样我们的表更新插入频繁，虽然这些列值建立了BITMAP索引。执行计划也用到了，但是稳定性不好

NinGoo

更新频繁的列不适合用bitmap index

ftai65

ding

hanjs

最初由 NinGoo 发布
[B]这次终于看明白了 [/B]

能否帮忙解释下

*** 2007-11-09 19:15:32.000
*** SESSION ID9.23) 2007-11-09 19:15:32.000
Start dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762
buffer tsn: 0 rdba: 0x0040c64a (1/50762)
scn: 0x0000.000ac6df seq: 0x01 flg: 0x00 tail: 0xc6df0601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump:  0x0040c64a
Object id on Block? Y
seg/obj: 0x7668  csc: 0x00.ac6de  itc: 2  flg: -  typ: 2 - INDEX
     fsl: 0  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x02   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.000ac6de

Leaf block dump
===============
header address 87691356=0x53a105c
kdxcolev 0
KDXCOLEV Flags = - - -
kdxcolok 0
kdxcoopc 0x80: opcode=0: iot flags=--- is converted=Y
kdxconco 4
kdxcosdc 0
kdxconro 5
kdxcofbo 46=0x2e
kdxcofeo 7918=0x1eee
kdxcoavs 7872
kdxlespl 0
kdxlende 0
kdxlenxt 0=0x0
kdxleprv 0=0x0
kdxledsz 0
kdxlebksz 8036
row#0[8013] flag: -----, lock: 0
col 0; len 1; (1):  80
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 10 42 08
row#1[7990] flag: -----, lock: 0
col 0; len 2; (2):  c1 02
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 0f
col 3; len 3; (3):  c9 21 84
row#2[7966] flag: -----, lock: 0
col 0; len 2; (2):  c1 03
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 42 08 01
row#3[7942] flag: -----, lock: 0
col 0; len 2; (2):  c1 04
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 84 10 02
row#4[7918] flag: -----, lock: 0
col 0; len 2; (2):  c1 05
col 1; len 6; (6):  00 40 c6 42 00 00
col 2; len 6; (6):  00 40 c6 42 00 17
col 3; len 4; (4):  ca 08 21 04
----- end of leaf block dump -----
End dump data blocks tsn: 0 file#: 1 minblk 50762 maxblk 50762


row#0的80，怎么定位是0的呢？？