一、架构对比
1. 物理存储结构
Oracle 10g的LOB存储机制基本和11g的BasicFile方式一致,具体参见附录的Oracle数据库LOB物理存储结构。
在默认的enable storage in row的模式下,BasicFile LOB列中,存放着两个layer Locator Layer(20字节)和Inode Layer(16字节)。Locator包括了控制信息和10字节的LOB ID,in-line存储的情况下包含实际的LOB 数据(最大3964字节),out-of-line存储的情况下,至多包含12个4字节关联DBAs(参见附录),如果LOB过大,将使用Locator包含的LOBID指向LOB index来寻找数据chunks(固定大小),并且通过LOB index结构来实现chunks的读取一致性。
Enable storage in row in-line LOB:

Enable storage in row out-of-line LOB:

SecureFile LOB列中,也存放着Locator Layer和Inode Layer。Locator的内容和BasicFile里是一样的。而Inode Layer包含了RCI Header和Inode部分,其中Inode部分包含了指向LOB数据chunks(可变大小)的指针,同时实现了如普通数据块一样的UNDO,减少了对LOB index的依赖。(RCI即表Segment里存储的LOB列的所有数据,RCI Header里存储的是SecureFile的LOB控制信息。)
Enable storage in row in-line LOB:

Enable storage in row out-of-line LOB:

2. 可变Chunk
在BasicFile的LOB中,Chunk的大小是一定的,最小跟DB Block的大小一样,最大为32KB。当chunk比LOB的数据小很多的情况下,访问LOB就会产生很多IO,而chunk比LOB的数据大很多的情况下,又会产生对存储空间的浪费。
在SecureFile中,chunk的size是可变的,由Oracle自动动态分配,最小跟DB Block的大小一样,最大为64MB。这样在存储较小的LOB时,使用比较小的chunk;在存储比较大的LOB时,会使用比较大的chunk。注意不是说一个LOB就放在一个chunk里,而是oracle根据LOB data的数据大小会自动决定chunk数和chunk的size。
由AWR可以看到,可变chunk特性使得SecureFile在LOB的IO上有一定的优势:
BasicFile:

SecureFile:

3. LOB index
如上所述,在LOB数据的存储方式上,两种LOB有很大的区别。BasicFile的存储方式不可避免的会产生LOB index竞争,成为瓶颈。
在SecureFile中,LOB index只有在使用重复消除功能时才会使用。 简而言之,SecureFile中只要不使用重复消除功能就没LOB index什么事,自然性能就上去了。
具体实例请参阅高并发测试的AWR报告分析部分。

4. 空闲空间搜索
在BasicFile里,关于有空间的使用情况的信息是保存在LOB index和LOB segment里的。在INSERT或UPDATE操作LOB segment时,以下面的顺序来搜索空闲空间:
(1) 在LOG segment的管理区搜索空闲空间,如果没有,转下一步。
(2) 访问LOB index,把可以释放的空间(如已经commit的transaction使用的UNDO)释放掉,并更新索引entry。如果不存在这种可以释放的空间,转下一步。
(3) 将HWM升高,扩大LOB segment,使用新分配的空间
由此可见,BasicFile的LOB在搜索空闲空间时,可能会去扫描LOB index。因此LOB index的竞争,或者在LOB数据很多的情况下,搜索LOB index的空闲空间这个操作本身都会造成时间上的花费,如下面测试AWR报告中表现出来的高“enq: HW-contention”等待。
而SecureFile将其放入了shared pool,这比BasicFile空闲空间管理的效率有了质的提高。 Shared Pool里的这个内存结构叫In-memory dispenser,它把空闲空间的信息cache在内存里,因此速度要比访问LOB index快了N个数量级。In-memory dispenser负责接受前台进程对于LOB空间的请求,并进行chunk的分配。
在In-memory dispenser中管理的空闲空间不是全部,而只是一部分而已,它的信息由后台进程SMCO/Wnnn来定期的更新。SMCO/Wnnn监视SecureFile LOB segment的使用情况,根据需要保证空闲空间的供应。注意SMCO/Wnnn也负责普通的ASSM表空间的空间动态分配。
(1) SMCO进程(Space Management Coordinator)。负责前瞻式(Proactive)的空间分配,它动态产生slave进程Wnnn来完成实际的工作。
(2) Wnnn(SMCO Worker)每10分钟扫描一遍LOB segment的状态,根据需要把空chunk移动到In-memory dispenser中。如果这样空chunk还是不够,则扩大LOB segment。

二、吞吐量测试
1、测试目标说明
在吞吐量测试中,选择0.1M、1M、10M、100M四个级别的文件作为对象,测试四种模式下的单线程读写能力。考察目标为无压力情况下,SecureFile存储方式的性能优势。

2、NOCACHE+LOGGING存储选项
(1)PLSQL测试结果:

(2)JAVA测试结果:

(3)结果说明:
SecureFile存储方式与BasicFile存储方式性能对比情况:
PLSQL:写提升2~3倍,读提升3~4倍。
JAVA:写提升3~4倍,读当文件大于10M,性能开始提升,否则没有性能优势。
由趋势可见,1M~10M区间性能提升梯度较大,为读写性能优势明显区域,当大于100M,则性能提升趋于平稳,甚至下降。

3、NOCACHE+NOLOGGING存储选项
(1)PLSQL测试结果:

(2)JAVA测试结果:

(3)结果说明:
SecureFile存储方式与BasicFile存储方式性能对比情况:
PLSQL与JAVA测试结果和趋势对比与nocache+logging模式相仿,然而写性能较前者又有一定程度提升。

4、CACHE+LOGGING存储选项
(1)PLSQL测试结果:

(2)JAVA测试结果:

(3)结果说明:
SecureFile存储方式与BasicFile存储方式性能对比情况:
PLSQL与JAVA的测试结果均显示在cache+logging的模式下,SecureFile存储方式并无读写性能优势,甚至处于劣势。

5、CACHE+NOLOGGING存储选项
(1)PLSQL测试结果:

(2)JAVA测试结果:

(3)结果说明:
仅有SecureFile存储方式支持cache+nologging模式,不具可比性。

三、高并发测试
1、测试目标说明
在高并发测试中,选择40KB文件作为测试对象,定义一个标准事务:1行insert+1行select读取+1行LOB字段update+1行select读取,选择100路、200路、300路、500路、1000路分别进行50次事务轮询,测试四种模式下的多线程事务处理能力。考察目标高压力情况下,SecureFile存储方式的TPS处理优势。

2、NOCACHE存储选项
(1)测试结果:

(2)结果分析:
三种存储方式,在NOLOGGING的情况下,均表现出更优的TPS处理能力。而SecureFile方式在较另两者更优,并随着并发数的增加,其优势呈明显上升趋势。

3、CACHE存储选项
(1)测试结果:

(2)结果分析:
在LOGGING情况下,SecureFile不具有明显优势,且消耗SGA资源,不推荐使用,NOLOGGING仅SecureFile支持,不具可比性。

4、AWR报告分析
AWR报告为BasicFile和SecureFile在默认存储选项NOCACHE+LOGGING,500路并行50次轮询事务的情况下抓取,详见附录。
(1) CPU使用情况对比:
BasicFile:

SecureFile:

可以看到,BasicFile实际使用的系统CPU资源较SecureFile更高,而Oracle真正使用的CPU较低,说明BasicFile更多在OWI事件的等待。
(2) Top5等待事件对比:
BasicFile:

SecureFile:

在Top5的等待事件中,可以看到BasicFile的82.01%等待时间(总计63,633s)在等待写入LOB,而实际LOB的写入总量两者是一样的,可见SecureFile在高并发情况下的写入能力更强。同时也验证了CPU对比分析的结果。
另外,值得关注的是BasicFile中的“enq: HW-contention”等待事件,而在SecureFile中并未出现,是因为SecureFile的可变Chunk和空闲空间搜索的新特性,使得性能提升。
(3) Segment读写情况对比:
BasicFile:



可以看到,BasicFile在写LOB的同时,确实是需要维护LOBINDEX的,也就是说LOB Block是通过LOBINDEX寻址的。所以在LOBINDEX上会出现LOCK WAIT和ITL WAIT。
SecureFile:


而SecureFile LOB Block更接近于普通的Data Block,不需要LOBINDEX的寻址,也不需要在写入LOB的同时维护LOBINDEX,避免了LOBINDEX的LOCK WAIT和ITL WAIT。

5、SecureFile的BUG_16003813说明
(1) BUG的表现特征:

在Top 5的等待事件中,可以看到存在非常高的“latch: enqueue hash chains”,这是很不正常的。
通过MOS确认为Oracle的BUG:
Bug 13395403 “enqueue hash chains” latch contention on Securefile blob DMLs – superseded
Bug 13775960 “enqueue hash chains” latch contention for delete/insert Securefile workload
修复BUG的PATCH:
补丁程序16003813: MERGE REQUEST ON TOP OF Database PSU 11.2.0.3.4 FOR BUGS 13395403 13775960
先决版本要求:Oracle 11.2.0.3.4,该补丁不包含在PSU补丁中,需另外打补丁。

附录
1、LOB物理存储结构
(1)10g数据库传统LOB:

tab 0, row 0, @0x1efa
tl: 103 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [11]  61 6c 65 78 30 31 2e 64 6f 63 78
col  2: [84]
 00 54 00 01 01 0c 00 00 00 01 00 00 00 01 00 00 06 88 6e 31 00 40 05 00 00
 00 00 0c 1a a0 00 00 00 00 00 02 44 c0 00 0d 44 c0 00 0e 44 c0 00 0f 44 c0
 00 10 44 c0 00 0c 44 c0 00 1c 44 c0 00 1d 44 c0 00 1e 44 c0 00 1f 44 c0 00
 20 44 c0 00 1a 44 c0 00 1b

(2)11g数据库BasicFile LOB:

tab 0, row 0, @0x1efa
tl: 103 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [11]  61 6c 65 78 30 31 2e 64 6f 63 78
col  2: [84]
 00 54 00 01 01 0c 00 00 00 01 00 00 00 01 00 00 00 ac 75 3d 00 40 05 00 00
 00 00 0c 1a a0 00 00 00 00 00 02 3b 80 00 85 3b 80 00 86 3b 80 00 87 3b 80
 00 83 3b 80 00 84 3b 80 00 96 3b 80 00 97 3b 80 00 91 3b 80 00 92 3b 80 00
 93 3b 80 00 94 3b 80 00 95
LOB
Locator:
  Length:        84(84)
  Version:        1
  Byte Length:    1
  LobID: 00.00.00.01.00.00.00.ac.75.3c
  Flags[ 0x01 0x0c 0x00 0x00 ]:
    Type: BLOB
    Storage: BasicFile
    Enable Storage in Row
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: ReadWrite
  Inode:
    Size:     64
    Flag:     0x05 [ Valid InodeInRow(ESIR) ]
    Future:   0x00 (should be '0x00')
    Blocks:   12
    Bytes:    6816
    Version:  00000.0000000002
    DBA Array[12]:
      0x3b800085 0x3b800086 0x3b800087 0x3b800083
      0x3b800084 0x3b800096 0x3b800097 0x3b800091
      0x3b800092 0x3b800093 0x3b800094 0x3b800095

(3)11g数据库SecureFile LOB:

tab 0, row 0, @0x1f2d
tl: 58 fb: --H-FL-- lb: 0x1  cc: 3
col  0: [ 2]  c1 02
col  1: [11]  61 6c 65 78 30 31 2e 64 6f 63 78
col  2: [39]
 00 54 00 01 01 0c 00 80 00 01 00 00 00 01 00 00 00 ac 77 f5 00 13 40 90 00
 0d 22 00 01 97 d0 01 00 02 3b 80 00 91 0d
LOB
Locator:
  Length:        84(39)
  Version:        1
  Byte Length:    1
  LobID: 00.00.00.01.00.00.00.ac.77.f5
  Flags[ 0x01 0x0c 0x00 0x80 ]:
    Type: BLOB
    Storage: SecureFile
    Characterset Format: IMPLICIT
    Partitioned Table: No
    Options: ReadWrite
  SecureFile Header:
    Length:   19
    Old Flag: 0x40 [ SecureFile ]
    Flag 0:   0x90 [ INODE Valid ]
    Layers:
      Lengths Array: INODE:13
      INODE:
        22 00 01 97 d0 01 00 02 3b 80 00 91 0d
Trackback

no comment untill now

Add your comment now

切换到手机版