今天是2014-04-21,今天简单只说明一下怎么影响重做数据的一个因素,那就是i/o吞吐量,oracle的介质恢复依赖于i/o,如果i/o存在瓶颈,那么势必会影响备库的介质恢复。
那么i/o stack包含hbas,存储相关的交换机、存储物理磁盘。那么oracle建议在应用程序部署的时候,建议去验证i/o避免存在问题。但是之前有一个很刺手的问题,那就是如何去验证i/o侧吞吐量,换句话说怎么去验证i/o吞吐量更符合真实的生产环境。
In Oracle Database 11g, the Real Application Testing feature (Capture/Replay) was introduced to inject real (captured) workload into the system. However, another new 11g feature is available to help assess the I/O capability of the database's storage system, and gauge maximum IOPS and Mbytes/s.
capability i/o feature 是依据一个数据库内部的函数(dbms_resource_manager.calibrateio()),该函数是oracle database内部集成的,更能满足测试i/o问题,且在最后将输出相关报告信息。
那么执行这个包需要注意什么呢?
1、权限,必须具有sysdba执行该过程的权限,另外需要打开timed_statistics。
2、确定异步i/o在数据库的所有数据文件和临时文件都已经得到应用启动,我们可以通过v$datafile 和v$iostat_file视图关联进行、确认。
eg:
col name format a50
select name,asynch_io from v$datafile f,v$iostat_file i
where f.file#=i.file_no
and (filetype_name='Data File' or filetype_name='Temp File');
如果异步i/o没有启动,设置disk_asynch_io=true启动该功能,但默认是开启的,如果在linux中最大slots使用完毕,那么将自动关闭噶 功能,这也就是为什么虽然设置了disk_asynch_io=true了却依然没有达到效果。最大的slots可以查看/proc/sys/fs/aio-max-nr 当前使用的可以查看/proc/sys/fs/aio-nr去分别确认。
3、确保服务器只有需要测试的数据库开启,避免 其他应用软件的影响。
4、对于RAC,需要确保所有的实例都开启,因为 将会对所有节点做全面的校对,执行该过程只需在一个实例即可。
5、确保只有一个用户执行一个校对i/o的操作。可以通过v$io_calibration_status查看当前鉴定状态。
另外查看资料了解到有这么几个过程:
The calibration will run in different phases. In the first phase, small block random I/O
workload is perform