常规存储下DataGuard中HCC的DML及DDL操作

如之前稿件所写,Oracle DB的HCC特性只允许开启在Oracle Corp的exadata一体机,zfssa存储,Pillar Axiom,SuperCluster,ODA 等硬件上。在实际的客户环境中,有较多客户采用了这些硬件尤其是exadata来运行自己的生产系统,并且开启了HCC以从中受益。

根据Oracle的MAA的建议,很多客户选择为生产库搭建Dataguard来实现生产系统的容灾,但并不是所有客户都会买两台exadata来作为dataguard的主备,更多的是选择普通X86硬件+普通集中式存储来作为备库的硬件承载平台。

时常有客户询问,如果主库中使用了HCC的表或者HCC的表空间,这些数据使用DG同步到备库之后,在switchover或者failover之后,这些数据的访问和操作会怎么样?

按照早先的认知,我一般会回复,正常同步是没有问题的,HCC的表在switchover之后,不能被访问,如果需要访问,得做一个显式的“解压”操作,才可以(来自Oracle白皮书)。其实我没测试过。最近想重新拾起来技术,决定测试一下。主要是连续看到两个人的测试跟我的理解不同。

这次选用的是19c,19.2.0.1版本,主库存放在zfssa上,备库存放在普通存储上。使用dbca+dg_broker的方式搭建一个dg。dbca搭建dg真的很方便。

第一组场景,测试压缩率变化情况,先搭建DG,再创建HCC表的压缩率和先创建HCC表再搭建DG的压缩率对比。因为据说以DG创建的时间点为基准,先开启还是后开启HCC,在主库上查询到的HCC的压缩率不一样。

第二组场景,测试已有HCC表在主库时,主备库做switchover,在新主库(普通存储)上对HCC的表做insert,update,delete,select,create及truncate测试。

场景1.1,已经创建好HCC表空间的数据库,搭建DG。

过程略,只给出HCC表空间创建语法。

之后确认DG同步正常:

DG实时同步

然后,我们构造一个数据重复度较低的表,之前我选用dba_objects来构造,实际上这个表是重复度较低的,但是表才七万多行,所以我多次插入,老杨说这个不严谨,因为多次构造本身就有很多重复数据。

这个数据从哪儿来。。。

从哪儿来。。。

哪儿来。。。

甲方其实很容易获得这样的数据,我们不接触客户的生产数据,所以得不到这样的测试样例。于是,我想了一个可能有效的办法,我开启swingbench对我的实验环境压测一夜,加上我早些年给客户处理故障导入了多个awr dump(这个数据不是客户的生产数据),然后CTAS出来dba_hist_active_sess_history作为测试表。唉。我觉得这就够不重复了。。。

把这个表导入到19c的主库的非HCC表空间中。随后在HCC表空间中基于这张728MB的表创建一个HCC表:

查看创建前后大小对比:

所以大概有15倍左右的压缩率

事实上这个压缩率跟之前构造的重复数据的压缩率比起来确实小了很多。老杨是不会骗我一个小孩子的。

之前对压缩和不压缩的表采用count(*) 的方式来测试,同样是不严谨的,因为不会牵涉到解压,只是单纯的块头扫描。事实上,count含有空值列的时间基本不相上下。可能是因为数据量还是太小。这也说明count(*)的时候的时间差距明显是不对的。

稍后,我们destroy掉原有dg,drop掉主库上跟HCC相关的一切对象,然后搭建一个dg,手工创建HCC表空间。(为什么不在原环境上drop掉Hcc再新建hcc表空间呢)

过程略。还是这个SQL。

同样的源表,同样的属性,压缩率一样

所以,至少在19.2这个版本里,搭建dg前还是搭建dg后再创建hcc对象并不影响压缩率。这个一点跟网上有人的测试结果相悖。我个人觉得我这个应该经得起推敲。如果有测试后的结论请贴出来讨论噻。

上面的测试到此结束,下面测试是本文的重点,即:测试已有HCC表在主库时,主备库做switchover测试,在新主库(普通存储)上对HCC的表做insert,update,delete,select,create及truncate测试。

我们在备库stbdb上对EHCC_ARCHIVE_LOW_LOCKING这个表进行如下测试:

1: SELECT测试

因为备库是open read only with apply的,在active dataguard的设计里,这个表的select是没问题的。事实上,HCC的表会报下面的错:

ORA-64307报错

之后,我们为了进行DML及DDL测试,理论上可以把备库变为snapshot standby读写模式来测试,但是为了贴近生产,这里做一次switchover。

切换成功,但是新的备库不能被dgmgr拉起来,手动即可,原因是?

切换之后,新的主库因为还是普通存储,对表的select的操作依然会遇到ORA-64307的报错。这个我们稍后来解决。

2:测试insert操作

事实证明,DML是不可以的,但是DDL如truncate是可以的。这与我同事告诉我的说HCC在其他机器上可以读取可以DML是不相符的。不过我这里用的是表空间级的HCC属性。(这里很尴尬,我select还没做解压测试我就把表给truncate了。。。)

主备再一次切换,恢复环境,在这个HCC的表空间上创建HCC表,再在/ehccfs上创建一个不带HCC属性的表空间,用create table时指定的HCC来再测试一次。真的枯燥。

过程略,下面是已经准备好的环境,stbdb是新的备库,在/ehccfs上有带HCC属性的EHCC_TBS_001表空间,上面有EHCC_ARCHIVE_LOW_LOCKING_001表,还有一个不带HCC属性的EHCC_TBS_002表空间,上面有EHCC_ARCHIVE_LOW_LOCKING_002表,表都是都HCC的。区别是一个在表空间级别指定,一个在表级别指定。

表大小

做switchover。

对EHCC_ARCHIVE_LOW_LOCKING_002表做select,insert,update,delete测试。

事实上都是不可以的。

最后一点,如果switchover之后,这个HCC表需要访问的话,怎么办?解压。

注意我这里引用一段oracle官方白皮书的说法:

Data Guard Primary using HCC and Standby Database on Third-Party Storage
Oracle is also occasionally asked if it is possible to utilize existing third-party storage to host standby databases for a primary database hosted on Oracle storage where HCC is used. In such a configuration, HCC compressed redo will be transported by the primary and applied at the standby on third party storage in compressed format. However, given that third-party storage is unable to support HCC, the following complications and restrictions arise:
● Active Data Guard cannot read HCC compressed tables on a third party storage.
In read-only mode, any attempt to select from an HCC table at the standby will yield the following error:
ORA-64307: hybrid columnar compression is only supported in tablespaces residing on Exadata, ZFSSA, or AXIOM storage
● Data Guard Snapshot Standby cannot read HCC compressed tables on third party storage
● Upon switchover or failover to a system using third party storage, HCC compressed tables will need to be decompressed before they can be accessed, lengthening recovery time, requiring substantially more disk space, and delivering less performance than the original primary database.
To access HCC tables you must failover to the standby and decompress using ‘alter table move’ for each HCC table. During the alter table move operation the table will be locked.

SQL> recover managed standby database finish;
SQL> alter database commit to switchover to primary;
SQL> alter database open;
SQL> alter table move ;

虽然这个白皮书是11.2的,但是我在19.2中测试完全符合白皮书。文中提到adg不能读取hcc的表,snapshot不能读取,无伦是exadata还是zfssa。想要读取必须解压。
解压之后可以读取

上文的测试没有在EXADATA真机和ZFSSA真机中进行,理论上官方提供的ZFSSA模拟器的软件特性应该是跟真机一样的,因为最新的ZFSSA的OS的bundle patch可以直接在模拟器上apply。

不放心,我尝试用隐含参数打开19.2的exadata特性,来看看是否可以访问HCC的表。

隐含参数打开exadata feature,重启
事实上,并没有什么用

测吐了。我以后要是再测HCC我是狗。

发表评论