java - 创建索引时 Liquibase 缓慢

Question

我最近将我的 Java Liquibase 版本从 3.5.3 升级到 3.6.3
我有一个非常繁重的环境，其中有很多数据库和表(我使用的是 Oracle)。
在这种环境下，我试图执行一个巨大的变更日志文件，我在其中创建表和索引。
在下面找到更改日志的一小部分。

<databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.2.xsd">
    
    ...
    ...
    ...

   <changeSet author="me" id="tableCreation78">
        <preConditions onFail="MARK_RAN">
            <not>
                <tableExists  tableName="MY_TABLE_NAME" />
            </not>
        </preConditions>
        <comment>Creating table MY_TABLE_NAME</comment>
        <createTable tableName="MY_TABLE_NAME">
            <column name="M_ID" type="bigint">
                <constraints nullable="false" primaryKey="true" primaryKeyName="PK_MY_TABLE_NAME_190" />
            </column>
            <column name="M_FORMAT" type="int" />
        </createTable>
    </changeSet>

    ...
    ...
    ...

    <changeSet author="me" id="indexCreation121">
        <preConditions onFail="MARK_RAN">
            <tableExists tableName="MY_TABLE_NAME"/>
            <not>
                <indexExists tableName="MY_TABLE_NAME" columnNames="M_FEEDER_ID"/>
            </not>
        </preConditions>
        <comment>Creating index for MY_TABLE_NAME</comment>
        <createIndex tableName="MY_TABLE_NAME" indexName="MY_INDEX_NAME">
            <column name="M_ID_INDEX"/>
        </createIndex>
    </changeSet>
    
    ...
    ...
    ...

</databaseChangeLog>

在 Liquibase 3.5.3 ，创建索引过去很快。
当我迁移到 Liquibase 3.6.3 ，我的性能出现了严重的倒退。
过去只需 1-2 分钟即可完成，现在最多需要 20 分钟才能完成。
变更日志没有定义唯一约束。
在调试时，我注意到两个版本之间的众多差异之一。在 3.5.3 , listConstraints和 listColumns来自 UniqueConstraintSnapshotGenerator 的方法不被称为。
在 3.6.3 版本，这些方法被调用了很多，即使在变更日志中没有定义唯一的约束。我猜测它们来自先前定义的环境表。
其中一些查询(见下文)使用完全相同的参数被多次调用。不知道是不是 里加的维护步骤3.6.3 . 2020-08-13 17:03:52,270 INFO [main] select ucc.owner as constraint_container, ucc.constraint_name as constraint_name, ucc.column_name, f.validated as constraint_validate from all_cons_columns ucc INNER JOIN all_constraints f ON ucc.owner = f.owner AND ucc.constraint_name = f.constraint_name where ucc.constraint_name='UC' and ucc.owner='DB' and ucc.table_name not like 'BIN$%' order by ucc.position我不确定这是否是回归的原因，但老实说，我没有想法。
有谁知道这是否可能是这种回归的原因？
他们是否在 Liquibase 中添加了新的维护步骤 3.6.3 这可能会导致如此大的性能下降？
非常感谢!

Answer 1

您可能需要对 Oracle 数据字典执行维护。使用 Liquibase 的数据库倾向于删除和创建比普通 Oracle 数据库更多的对象，这可能会导致元数据查询的性能问题。
首先，收集固定对象(V$ 对象)和数据字典(ALL_ 对象)的优化器统计信息。此信息有助于 Oracle 为元数据查询构建良好的执行计划。以下语句将需要几分钟，但可能只需要每年运行一次:

begin
    dbms_stats.gather_fixed_objects_stats;
    dbms_stats.gather_dictionary_stats;
end;
/

数据字典查询问题的另一个比较常见的原因是回收站中有大量对象。回收站非常适用于生产系统，它可以让您立即从丢错表中恢复过来。但在开发环境中，如果数以千计的对象不断被删除但没有被清除，这些旧对象可能会减慢某些元数据查询的速度。

--Count the number of objects in the recycle bin.
select count(*) from dba_recyclebin;
--Purge all of them if you don't need them. Must be run as SYS.
purge dba_recyclebin;

这是针对某些数据字典问题的两种快速且轻松的解决方案。如果这没有帮助，您可能需要调整特定的 SQL 语句，这可能需要大量信息。例如 - 您的系统对 ALL_CONS_COLUMNS 运行该查询需要多长时间？ (在我的数据库中，它运行的时间远少于一秒。)
运行 Liquibase，然后使用如下所示的查询来查找最慢的元数据查询:

select elapsed_time/1000000 seconds, executions, sql_id, sql_fulltext, gv$sql.*
from gv$sql
order by elapsed_time desc;