文章归档

Oracle 11g内置的IO测试包

这两天部门有个同事上新系统, 感觉Orion进行压力测试比较麻烦, 我印象中, Oracle 11g引入了一个进行IO压力测试的包, 具体的过程名包含Calibrat,就到自己测试环境的@?/rdbms/admin目录下查找了一把,得到了下列这些内容..

–catrm.sql 是Resource Manager的基础包, 包含resource manager相关的系统视图信息,
–通过这些视图可以知道当前Calibration进行的状态,以及Calibration结束之后系统的相关的统计信息.
catrm.sql:Rem vkolla 01/23/07 – use DBA_RSRC_IO_CALIBRATE
catrm.sql:Rem vkolla 11/13/06 – remove DBA_RSRC_IO_CALIBRATE
catrm.sql:Rem suelee 06/11/06 – Add IO calibration tables
catrm.sql:– create the view DBA_RSRC_IO_CALIBRATE
catrm.sql:create [...]

关于Active Standby恢复时延的一个简单测试

前一天通过duplicate active database 创建好standby之后,,今天简单的测试了一下active standby的apply 效率..

1. 准备工作, 将standby以active standby模式启动.

–Oracle文档要求standby logfile的数量至少比online logfile多一组. 所以我们在此创建4组standby logfile.
alter database add standby logfile group 4 (‘+data’) size 50m;
alter database add standby logfile group 5 (‘+data’) size 50m;
alter database add standby logfile group 6 (‘+data’) size 50m;
alter database add standby logfile group 7 (‘+data’) size 50m;

–将重启standby,并以active standby模式打开.
shutdown immediate;
startup mount;
alter database open read [...]

在Oracle 11gR2中Duplicate active standby.

0. 通过安装好数据库环境, 如果使用ASM的话, 也配置好ASM的环境.
1. 在主库与standby数据库配置好listener与tns配置.在我的环境中为dbmain与dbstby

dbmain 库上的配置

[oracle@dbmain admin]$ cat listener.ora
LISTENER =
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=dbmain)(PORT=1521))
)
SID_LIST_LISTENER=
(SID_LIST=
(SID_DESC=
(SID_NAME=dbmain)
(ORACLE_HOME=/opt/app/oracle/products/11.2.0)
)
)
[oracle@dbmain admin]$ cat tnsnames.ora
dbmain =
(DESCRIPTION =
(ADDRESS_LIST =
[...]

闪存表空间 VS 数据库Flash Cache

本文翻译自Guy Harrison的blog: Flash tablespace vs. DB Flash Cache, 这是他写的关于Flash Cache系列文章的最后一篇,另外还会翻译两篇Kevin Closson写的关于Flash Cache的相关文章.
之前两篇关于Flash Cache的文章如下:

数据库Flash Cache(II)
使用Oracle 11GR2 数据库Flash Cache

闪存表空间 VS 数据库Flash Cache

在这篇文章中,我将根据我最近针对使用SSD作为数据文件的存储以及使用Oracle 11GR2数据库Flash Cache所做的测试,给出一份两者的性能对比.
有时,我的整个职业生涯看上去都是在等待旋转磁盘的终结.这项技术是如此古老,能力限制如此明确,如此机械.因此,SSD作为一种数据库存储介质越来越可行(Oracle 11GR2已经直接支持这一点),这个事实令人振奋.
使用SSD作为数据库存储的一部分确实会产生很大的问题,但是,理解闪存SSD的性能特征却是非常重要的,它可以帮助我们确保不会不当地使用它.
SSD有以下两个特征:

基于闪存的SSD使用与常见的USB盘相似的闪存技术,这种USB盘已经在小容量移动数据存储领域替代软盘.闪存RAM比较便宜,提供不需要电池备份的持久存储,因此其耗电量也很低.
基于DDR RAM的SSD使用本质上与服务器核心内存差别不大的内存模块.这种RAM需要有持久存储(如磁盘或闪存RAM)和内部电池来支撑.在发生电力故障的时候,电池可以提供足够的电力来保证可以将RAM内存中的内容写到持久存储.

DDR SSD非常昂贵(以及$$/GB这个级别),以致于目前无法作为专业的数据库设备使用.但是,基于闪存的SSD磁盘越来越称为机械磁盘的一个可行的替代选项.

读,写以及擦写操作

闪存盘存储是按照页(一般为4K)以及块(一般为256K)来组织的.对于读操作来讲,闪存盘可以从单个页(page)快速返回结果.往一个页中写数据要慢很多(可能要慢10倍).然而,只有在块中刚好有一个空闲的页的往页写才能达到这个速度.如果我们需要往整个块写数据,必须先清除块内的内容才可以.维基百科关于SSD的条目给出了下面这个关于查找/写以及擦写的时间:

当一个闪存SSD盘渐渐填满数据时,需要清除操作的块级别的写操作的比例逐渐增加,闪存SSD的写性能也相应下降.

TRIM API函数

高端的闪存SSD支持一种叫做TRIM的API,这个功能使得OS可以主动提前清除整个块,从而写操作可以在只有一个页级别的IO内完成.大部分高端的SSD盘还支持一种防磨损算法,这种算法可以在设备上移动热点页以避免块级别出现故障的风险.闪存盘在块变得不可靠之前只支持一定次数的擦写操作,加入磁盘可以自动将热点页在物理存储上移动时,这个缺陷就可以得到缓解.

MLC vs SLC

廉价的闪存盘一般都使用MLC(Multi-Level-Cell)技术,它可以实现在一个单元中存储两位的数据,而使用SLC时一个单元中只能保存一位数据.MLC的效果是以牺牲性能的代价来提高数据密度,特别是写性能.从数据丢失的角度讲,MLC也是更加不可靠的.如果你关心写性能,那么或许你应该避免使用基于MLC的SSD.
通常,如果你想要一个高性能的闪存SSD的话(如果它不是高性能的,干嘛还要它呢?),你就应该选择基于SLC的闪存SSD,并且是支持TRIM API以及有着好的防磨损能力的SSD.在我的测试中,我使用一个Intel X-25 E 32GB的SSD盘.它大概需要600澳元(大概534美元).

读写速度差异的问题

假设大部分数据库都是读比写多,我们还需要担心闪存SSD在查找时间与写时间方面的差异吗?毫无疑问答案是YES.对于一个Oracle数据库来讲,当通过Buffer Cache处理事务活动时,一个设备的读能力与往这个设备的写能力之间有很大的不匹配会非常有害.
这个问题与Buffer Cache中的数据的缓存有关.如果往Buffer Cache中放入数据块比从里面写出简单很多,那么Buffer Cache就很可能会被脏块填满,从而出现free buffer waits等待.下图展示了free buffer waits是如何出现的:

如果使用的是廉价的闪存盘,那么写速度就会比读速度慢更多,最终free buffer waits等待将成为事务活动高峰时期的限制因素.

Oracle数据库Flash Cache

Oracle的数据库Flash Cache提供了另外一种利用闪存SSD的途径. 它不是将整个数据文件放到闪存上,而是将闪存作为二级缓存使用.Flash Cache可以非常大从而加快经常被访问的数据块的读速度.但是,如果闪存盘非常繁忙的话,Oracle就只是尽量少写缓存.这样,我们就可以得到闪存来优化读操作的好处,而不用承担多少写操作带来的损失.
我在前一篇文章中总结了Flash Cache的处理算法,下面是我在那篇文章中使用的图表,它概括了当数据库使用Flash Cache时一个数据块的生命周期.

这个架构的关键点是,只有在DBWR没有超负荷时,它才会往Flash Cache中写入数据块.当DBWR逐渐变得繁忙时,往Flash Cache中的写操作将被忽略(这将会降低Flash Cache的效率),它可以防止Buffer Cache被脏块填满,从而导致free buffer waits等待事件的出现.

闪存盘的读性能

让我们来看在实际操作中它是如何表现的.下面来看当我们针对如下情况执行500,000次随机索引读取时的性能对比:

1. 一个在机械磁盘上的表,不使用Flash [...]

segment compression的一点测试与说明

11g 的segment compression在内部存储上几乎没有变化..

对于新的compression for OLTP 新增了下面图中所示的相关处理, 也就是当block 达到一定的full程度的时候会触发一次compress动作,
将使用的空间降下来, 过一段时间, 由于dml操作的原因, block会再度达到指定的full 程度, 又会再一次触发compress动作.. 具体到什么时候
不会触发compress或者到什么程度触发compress我还不清楚..

图片来自Oracle的白皮书.(见附件, page 6).

关于Oracle9i–11g的compression 功能 ( 特别推荐 )
下面这两篇文章对Oracle Segment Compression介绍的非常深入, 有兴趣的同学可以深入看看.
http://www.laoxiong.net/dissect_compressed_block_part1.html
http://www.laoxiong.net/dissect_compressed_block_part.html

附件的DataSegmentCompression.ppt为JulianDyke的文档(具体实现介绍见page 32-36). (这一段介绍可以与上面老熊的文章部分吻合, 应该可以促进部分了解..)

另外还有部分关于row data/column data的相关介绍.. 可以参考DSI 402e Data Types and Block Structures(pages 96, 103-106)

另外还有几篇可参考文件
Oracle的sement compression白皮书(见附件)

冯春培最早在cnoug上发的帖子(在itpub也贴了),, 还有汪海对这个帖子的深度跟帖..
http://www.cnoug.org/viewthread.php?tid=3553

汪海早年关于这个问题的帖子.
http://wzwanghai.spaces.live.com/blog/cns!56626E237AFBD116!206.entry
http://www.orawh.com/78.html

eygle的介绍文章, 可看可不看, 深度理解看最上面的帖子, 使用介绍看杨保秋的blog.
http://www.eygle.com/archives/2006/06/oracle9ir2_nf_table_compress.html

黄玮 blog, 工作于OCCL 东方海外, 这篇介绍的也不错,,
http://www.hellodba.com/Doc/data_compress.htm

杨保秋的blog, 含有相关使用说明,介绍,场景使用
http://space.itpub.net/9134/viewspace-179724
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179725
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179730
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179731
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179737
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179739
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179744
http://space.itpub.net/?uid-9134-action-viewspace-itemid-179745

表压缩的原理
http://www.oratea.cn/2008/03/31/54.html
压缩表的原理(续1)
http://www.oratea.cn/2008/05/23/116.html
压缩表的原理(续2)
http://www.oratea.cn/2008/05/30/122.html

后面是我自己针对这个的一个测试结果.