博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Oracle Data Guard压缩归档测试(二)(r12笔记第27天)
阅读量:2448 次
发布时间:2019-05-10

本文共 2136 字,大约阅读时间需要 7 分钟。

昨天对Data Guard的归档压缩进行了一个初步的测试,我今天又做了一些补充。

   1.昨天测试的是默认50M的redo,如果redo增大,在IO bound的场景中,是否有很大的变化

   2.对于归档压缩来说,数据量如果增大,是否会有较大的抖动,昨天测试的是20G的数据量,初始化了50%

   3.对于整个数据初始化的过程中,主备的延迟到底有多大,是否有延迟回落的现象。

   我们一个一个来做解答。

首先是redo的大小调整,我们需要设置redo大小为200M,备库的standby logfile也是200M。

然后是生成的数据量,我们这次测试时间长一些,测试的过程尽量完整一些,数据量也大一些,所以调整为50G.

最后的主备的延迟,这个我们先不去查看数据字典里的数据,我们手工DIY一下,如果在 高性能MySQL 这本书中,测试主从延迟,是有一种实现方式,采用federated存储引擎,达到Oracle中类似db link的数据访问。而在Oracle中,实现起来就很简单了。

我们创建一个DB link,然后在主库中创建一个表

create table sysbench_dba.sync_delay(insert_time timestamp);

然后在备库中反问主库的这个表,对比备库的时间戳即可,假设我们指定的DBA账户是sysbench_dba

sqlplus -s / as sysdba <<EOF

set time on
set head off
set feedback off
col pri_timestamp format a35
col std_timestamp format a35
col diff_timestamp format a35
set linesize 150
delete from sync_delay@sync_link;
insert into sysbench_dba.sync_delay@sync_link select systimestamp from dual;
commit;
with pri_timestamp as (select insert_time from sysbench_dba.sync_delay@sync_link)
select (select insert_time from pri_timestamp)pri_timestamp,systimestamp std_timestamp,(select insert_time from pri_timestamp)-systimestamp diff_timestamp from dual;
EOF

运行这个脚本之后,会得到如下的结果。三列分别是主库时间,备库时间,最后是时间差,即延迟。

07-APR-17 10.37.43.330302 AM        07-APR-17 10.37.48.557999 AM +08:00 -000000000 00:00:05.227697这个算出来的会有一些因素的干扰,但是本身也能够说明一些情况。

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆

接下来我们初始化数据,这次创建50G的数据,预期的数据量大概是100G左右。

# ./oewizard  -s -c oewizard.xml -allindexes  -ts users -tc 16 -v -cl -scale 50 -create开启归档压缩设置。

edit database sdataguru set property RedoCompression='ENABLE';

edit database dataguru set property RedoCompression='ENABLE';

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆

IO wait的对比,左边是压缩归档,右边是不压缩。数据量相同。可以看到几乎没有差别。

0ced4cb6-1100-4128-8cab-8eedb942b3ac.png

网络带宽,这个指标蛮有意思,我来详细解读一下。

左边是压缩归档,右边是为压缩。为什么左边的部分中间有些中断呢,是因为swingbench初始化数据的过程中,前期是插入数据,然后补充约束关系,创建索引。整体来看压缩归档的均值在50M左右,峰值150M,而未压缩归档的均值要高一些,近100M

,峰值300M左右。

8f9e7059-0362-4ae5-a6b7-a8cd82e1b585.png

而这个数据和之前的redo 50M的对比是怎么样呢,就是下面的4个方框。第一个代表是50M redo开启压缩,第二个代表50M redo不压缩, 第三个代表 200M redo压缩, 第四个代表 200M redo未压缩。

2fd803bd-8c37-4c8a-b127-84bd744d3cb1.png

通过这个数据能够看出一个大题的体量。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23718752/viewspace-2136834/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-2136834/

你可能感兴趣的文章
gpu驱动程序_如何从错误的GPU驱动程序更新中恢复
查看>>
esp now_Google带回Google Now(内部)排序助手
查看>>
如何防止视频在Chrome中自动播放
查看>>
如何使用Synology NAS下载文件(并避免在夜间开启计算机)
查看>>
使用批处理脚本上传ftp_通过批处理脚本将文件上传到FTP站点
查看>>
linux下如何更改主机名_如何在不重新启动的情况下更改Linux主机名
查看>>
pxe网络启动引导程序_如何使用PXE设置网络可引导实用程序光盘
查看>>
凌乱的yyy_如何清理凌乱的Internet Explorer上下文菜单
查看>>
Laravel Eloquent:API资源
查看>>
在React中使用Font Awesome 5
查看>>
React Hooks入门
查看>>
盖茨比乔布斯_用盖茨比快速浏览WordPress站点
查看>>
vue.js表单验证_Vue.js中的模板驱动表单验证
查看>>
软件测试结束标志_使用功能标志进行生产中的测试
查看>>
css网格_在CSS网格中放置,跨度和密度
查看>>
火狐动态调试css_使用Firefox开发工具调试CSS网格
查看>>
服务周期性工作内容_使服务工作者生命周期神秘化
查看>>
nuxt.js 全局 js_在Nuxt.js应用中实现身份验证
查看>>
具有NgClass和NgStyle的Angular 2+类
查看>>
网络抓取_使用ScrapeStack轻松进行网络抓取
查看>>