将Oracle Exadata工作负载迁移到Azure存储索引

我要简化客户的一切,因为我们将复杂的环境引入到在Exadata上运行的Azure和Oracle数据库中,这是这些挑战的很大一部分。使数据库与工程功能脱钩是我工作的关键部分,并且对于Oracle 19c,如果数据库在较早的版本上,则使客户在终端版本上运行并不是升级的唯一原因。

正如我在其他帖子,博客和文章中讨论的那样,当丢失单元节点卸载,混合列压缩(HCC),使用稀疏克隆的精简克隆,闪存缓存,闪存日志记录等时,我有多种方法来解决延迟问题,但是需要存储索引是Exadata独有的,根本无法进行比较。

对于不熟悉此数据库云服务器功能的用户,存储索引是一种自动功能,它基于在每个数据库中运行的SQL语句的where子句。这些索引仅在存储单元的内存中创建,跟踪每个数据块中列的最小值和最大值。

同样,这都是基于使用情况的,因此运行更多查询时,索引值更新的频率就越高,并且如果Exadata或IBM的关机后再启动,驻留在内存中的存储索引将不得不随时间重建。数据库。存储索引的目的是为任何给定的值集标识范围内的块,并消除对可能不存在数据的单元节点或磁盘的不必要的IO调用。

为了从存储索引中获得最佳性能,存在一些要求,例如,设计合理的表中的谓词和干净排序的数据(请考虑按顺序填充的列)。

没有你,我不知所措

如果从该功能不再存在的工程系统中丢失了这一宝贵功能,我们该怎么办?您可以通过更改spfile值来禁用登台或测试区域上的存储索引来预先测试性能:

SQL>alter system set _KCFIS_STORAGEIDX_DISABLED=TRUE;

这可以告诉您在没有可用存储索引的情况下数据库的性能如何,并且可以提供一些见解,但是请记住,此时仍将启用单元节点卸载的IO优势,(第二点讨论我们将不再继续进入这里。)

19c中的自主/自动索引

随着Oracle版本19c的推出,我们现在在Oracle企业版中又提供了一个Exadata功能-自主/自动索引(我已经看到它同时使用了两个名称)这对19c的添加可以帮助减少增加的IO和性能损失当我们通过自动创建,测试,打开良好的索引而从Exadata迁移时,如果不是有益的,则在无需任何人工干预的情况下将其删除。这将有助于:

  1. 数据库处于Exadata上时可能缺少的索引会增加表扫描和将数据卸载到单元节点的可能性。
  2. 创建替代索引,以补充不再具有存储索引优势的性能。

这项新的19c功能受以下功能支持: DBMS_AUTO_INDEX 并且默认情况下在19c中处于关闭状态。首先验证禁用状态,然后将其打开:

SQL>SELECT con_id, parameter_name, parameter_value
FROM cdb_auto_index_config where parameter_name = 'AUTO_INDEX_MODE';

SQL>EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE','IMPLEMENT');
SQL>EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE','REPORT ONLY');

要再次禁用它,操作很简单,如下所示:

SQL>EXEC DBMS_AUTO_INDEX.CONFIGURE('AUTO_INDEX_MODE','OFF');

启用后,该作业将识别候选索引并以不可见状态创建索引,并从执行的SQL执行一些测试以查看索引是否有好处。如果索引未通过测试,则索引将处于不可见状态,对用户或应用程序完全透明。

如果发现索引是有益的,则将其转换为可见状态并成为数据库的一部分。创建这些索引后,您可以通过其命名约定快速识别它们,该命名约定始终以“ SYS”开头或使用以下查询:

SQL>SELECT owner, index_name, index_type, table_owner, table_name
FROM dba_indexes
WHERE auto = 'YES'
ORDER BY owner, index_name;

这些索引完全由Oracle管理,因此请勿尝试移动,重建它们等.Oracle将为您管理这些索引的生命周期,包括如果不再值得删除它们。

现实检查

现在,我想清楚一点-这不是Exadata中存储索引的替代品,但是可以选择卸载和使用存储索引,因此我一直遇到迁移数据库中丢失的大量索引,这些索引可能会提高性能-这是只是Exadata上的Oracle数据库发生什么情况的本质。

甲骨文 数据库在云中获得成功的最大机会是消除多余的IO,因为它们本质上是IO的重载。在理想的情况下,这可以通过优化SQL来解决,但很少有足够的时间用于开发或供应商愿意进行会产生最大影响的更改。相反,我更有可能推荐一种重要的分区策略,或者在离开Exadata时采用适当的分区策略以消除更多的IO。那些将Oracle高级分区,高级压缩和自动索引相结合的客户,在迁移到云中以实现Oracle在Azure上的IaaS上取得令人难以置信的成功时,已经显示出Exadata工作负载的IO需求显着下降。

希望您和您一切都好,周末愉快!

dbakevlar

http://about.me/dbakevlar