Exadata智能扫描性能问题常见原因

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。

当一个数据库系统的智能扫描出现了性能问题,通常有可能由以下原因导致。

  • 存储索引使用情况不理想

后面会有单独的章节来详细介绍存储索引特性,这里只简单提及存储索引的主要作用是减少IO扫描量。如果存储索引的效率比较高,则可以大大减少IO扫描量,而相同的SQL语句,如果存储索引的效率不高,则需要扫描更多的IO,即使进行智能扫描,存储节点的IO扫描仍然是不可避免的,所以存储索引的效率高,则智能扫描的效率高,同样,存储索引的效率低,则智能扫描的效率自然也会低。

  • 存储节点设置了quarantine(隔离区),导致没有过滤功能

quarantine可以阻止某些SQL语句执行智能扫描操作,这减少了存储软件崩溃的可能性,提高了存储的高可用性。下面通过示例进行演示针对某SQL语句设置quarantine时,对智能扫描的影响,见代码清单1.26

代码清单1.26 quarantine阻止智能扫描操作

代码清单1.26执行了一个SQL语句,并获取到该SQL语句的SQL_ID9htmw8y2q7rx5,在第一次执行时,该SQL语句进行了智能扫描。然后单独对该SQL_ID设置了quarantine,再次执行该SQL语句,发现Smart IO not used due to SQL Step or DB QuarantineStorage index disabled due to predicate disk passt等指标值都增加,这说明该SQL语句在第2次执行时没有使用智能IO,原因就是因为对该SQL语句设置了quarantine

同样,可以看出v$mystat视图中cell physical IO interconnect bytescell physical IO bytes eligible for predicate offload指标值相同,这说明该SQL语句合适进行智能扫描,但最终还是没有发生智能扫描,也即没有节省任何的IO,因为该SQL语句设置了quarantine,导致该SQL语句所涉及的所有数据块都无法通过智能扫描的方式传输给数据库服务器,而只能以passthru模式将所有数据块传输给数据库服务器,在存储节点无法进行数据过滤操作。

  • 由于时区升级而导致没有过滤功能

当数据库的时区处于升级模式或者不一致模式时,从计算节点向存储节点发出的IO将不会使用智能扫描,而是使用传统的IO传输方式,这将导致存储节点将所有的数据块发送到数据库所在的计算节点,而不是将合适的数据记录传输到计算节点。

可以在计算节点执行命令来检查数据库的时区升级状态是否设置为正常值,见代码清单1.27

代码清单1.27 检查数据库的时区升级状态是否正常

Oracle数据库的时区不应该长期处于升级状态,如果存在这种情况,可参考MOS文档《Exadata: RDS Performance Degrades when Database is in Timezone Upgrade Mode》(Doc ID 1583297.1)来处理时区问题,具体命令如下。

当数据库的sys.database_properties表中DST_UPGRADE_STATE属性值为NONE时,表示时区问题已经修复。

除了执行代码清单1.27中的脚本来检查数据库是否处于时区问题,还可以通过检查数据字典的方式来确认数据库目前是否存在时区问题,见代码清单1.28

代码清单1.28 通过数据字典检查数据库的时区升级状态是否正常

通过v$sysstat性能视图中的cell num smart IO sessions using passthru mode due to timezone可以评估整个数据库由于时区问题而导致SQL语句无法进行智能扫描的次数,该参数值应该为0。同样,也可以使用v$mystat性能视图来查看当前会话是否存在由于时区问题而导致SQL语句无法进行智能扫描。

  • 由于存储节点的CPU能力达到极限

数据库节点如果大量地使用智能扫描,把负载转移到存储节点一端,则可能导致存储节点的CPU负载过高,当存储节点发现CPU的占用率过高时,就会对一部分原本使用智能扫描的SQL语句不使用智能扫描,而直接将相应的数据块返回给计算节点,来缓解存储节点的CPU压力。等到存储节点的CPU负载降下来,则相应的SQL语句会再次使用智能扫描,这个特性称为”反向卸载”。

这个”反向卸载”的阀值是通过存储节点的隐含参数_cell_mpp_threshold来进行控制的,默认值为90,也即当存储节点的CPU使用率超过90%时,则存储节点就不会使用智能扫描进行过滤,而是直接将相应的数据块返回给计算节点。查看存储节点的隐含参数_cell_mpp_threshold当前设置的值,具体命令如下。

由于一些BUG的存在,在某些情况下,可能需要手动关闭这一特性,这个特性由数据库层面的隐含参数_kcfis_cell_passthru_fromcpu_enabled进行控制,默认值为true,代表开启”反向卸载”,设置为false表示关闭”反向卸载”。如果打算在会话级别关闭”反向卸载”特性,代码如下:

  • 由于存储节点的IO能力达到极限

有一个观点需要再次强调,那就是智能扫描仅仅是减少了IO的传输量,它仍然需要进行大量的IO扫描(除非存储索引特性生效),如果Exadata上的业务系统IO访问繁忙,则进行大量的智能扫描同样有可能导致存储节点的IO处理能力达到极限。

判断存储节点的IO能力是否达到极限,可以查看存储节点的OSWatherExaWatcher收集的资源使用信息,或直接调用iostat命令查看存储节点的磁盘使用情况,我们无法在计算节点上调用iostat命令查看存储节点的磁盘使用情况。

  • 由于存储节点的Flash闪存使用不理想

老版本的存储软件,智能扫描操作访问的数据块不会缓存到存储节点的FlashCache中(除非对表对象设置了KEEP属性),这就可能导致Flash闪存资源没有得到有效的利用,而底层的机械硬盘工作非常频繁,从而导致智能扫描的性能出现问题。

未经允许不得转载:Oracle一体机用户组 » Exadata智能扫描性能问题常见原因

相关推荐