倾力大奉献——ASSM内部存储研究大揭密

dazhoufei · 发表于 2004-8-2 10:54

收藏，好文章。

ncgxq · 发表于 2004-8-2 16:10

不知道有这个的专题讨论，我上传了两个文档，好象有点用处吧：
http://www.itpub.net/showthread. ... 1678659#post1678659

southsouth · 发表于 2004-12-25 00:55

Piner:
能否进一步解释？
“使用超高容量的DML（例如INSERT、UPDATE和DELETE等）的时候可能会出现性能上的问题。“

liuliu009 · 发表于 2005-3-29 15:08

好文章，值得学习

李迪 · 发表于 2005-6-23 10:57

樓主﹐想你請教一個問題﹐我們現在是9204,我建立了一個表空間﹐它是 local,auto,uniform = 1M,然后﹐我在上面建立了一個表﹐但是我們發現這個表擴張的實在太快了﹐問有沒有辦法﹐將這個表的NEXT 從新設定為10M?

piner · 发表于 2005-6-24 13:19

除非你重构该表

李迪 · 发表于 2005-6-24 21:15

最初由 piner 发布
[B]除非你重构该表 [/B]

你指的重構就是從建吧﹐就拿上面這個例子來說﹐我只有從構一個表﹐并且這個表只可以在TABLESPACE 的NEXT 為10M的TABLESPACE,才可以滿足這個表的NEXT 是10M

baikejia · 发表于 2005-6-27 22:45

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

好像可以。
我们用的hp oracle9.2.0.5.0的数据库的ASSM就可以放LOB

foreverlee · 发表于 2006-3-7 11:54

最初由 piner 发布
[B]是的

你的这个结果是很有代表性的，因为开始extent中block太多
一个1级块管理不过来，所以出现了2个1级块。

然后才是1个2级块，最后是段头
所以可以看到4个Metadata的块 [/B]

是的可以看他第11个块的dump结果

*** 2004-07-14 11:57:24.000
Start dump data blocks tsn: 23 file#: 4 minblk 11 maxblk 11
buffer tsn: 23 rdba: 0x0100000b (4/11)
scn: 0x0000.00603507 seq: 0x02 flg: 0x00 tail: 0x35072102
frmt: 0x02 chkval: 0x0000 type: 0x21=SECOND LEVEL BITMAP BLOCK
Dump of Second Level Bitmap Block
number: 4 nfree: 4 ffree: 0 pdba: 0x0100000c
opcode:1
xid:
L1 Ranges :
--------------------------------------------------------
0x01000009 Free: 5 Inst: 1
0x0100000a Free: 5 Inst: 1
0x01000089 Free: 5 Inst: 1
0x0100008a Free: 5 Inst: 1

--------------------------------------------------------
End dump data blocks tsn: 23 file#: 4 minblk 11 maxblk 11

0x01000009 Free: 5 Inst: 1
0x0100000a Free: 5 Inst: 1
表示的就是First level bitmap block的地址

[精华] 倾力大奉献——ASSM内部存储研究大揭密