人大金仓分析型数据库系统维护（一）

目录

清理和分析

事务ID管理

系统目录维护 

常规维护

深度维护 

 查询优化分析

---

         数据库要求定期执行特定的任务来达到最优性能。这里讨论的任务都是必须的，但数据库管理员可以使用标准的UNIX工具（如cron脚本）来自动化这些任务。管理员建立适当的脚本并且检查它们是否成功执行。 

清理和分析

        数据库中使用的MVCC事务并发模型的设计意味着被删除或者被更新的数据行仍在磁盘上占据物理空间， 即便它们已经对新事务不可见。如果数据库进行了很多更新和删除，会有很多过期行存在并且它们所使用的空间必须使用VACUUM命令来回收。VACUUM命令还会收集表级的统计信息，例如行数和页面数，因此即便无需从被更新或者被删除行回收空间，也还是有必要去清理追 加优化表。

        清理一个追加优化表遵循一种和清理堆表不同的处理逻辑。在每一个实例上，会创建一个新的实例文件并且把可见行从当前实例复制到该文件中。当实例文件被拷贝完时，将会安排删除原始的实例文件并且让新的实例文件变得可用。这要求足够的可用磁盘空间用于拷贝可见行，直到原 始的实例文件被删除为止。如果一个实例文件中隐藏行和所有行的比率低于一个阈值（默认是10），该实例文件不会被紧缩。 该阈值可以通过gp_appendonly_compaction_threshold服务器配置参数配置。VACUUM FULL 忽略gp_appendonly_compaction_threshold的值并且不管该比率为多少都会重写实例文件。

事务ID管理

        MVCC事务机制依赖于比较事务ID（XID）号来判断当前数据对于其他事务的可见性。 事务ID号使用一种模2 的算法来比较，因此一个运行了超过二十亿事务的系统可能会遇到事务ID回卷，即过去的事务变成了未来的事务。这意味着过去的事务的输出变得不可见。因此，每过二十亿个事务就有必要VACUUM每个数据库中的每个表至少一次。数据库只对涉及DDL或者DML操作的事务分配XID值，通常也只有这些事务需要XID。当事务ID中相当多的一部分变得不再可用并且事务ID回卷还没有发生时，数据库会发出 下面的警告：

WARNING: database "database_name" must be vacuumed within number_of_transactions transactions

        当这个警告被发出时，需要一次VACUUM操作。如果没有执行VACUUM操作，当数据库在事务ID回卷发生前达到一个限制，它会停止创建新的事务。在停止创建事务以避免可能的数据丢失时，数据库会发出这个错误：

FATAL: database is not accepting commands to avoid wraparound data loss in database "database_name"

        数据库配置参数xid_warn_limit控制何时显示该警告。参数xid_stop_limit控制何时数据库停止创建事务。当数据库由于不频繁的VACUUM维护而达到 xid_stop_limit事务ID限制时，它会变得没有响应。为了从这种情况中恢复过来，作为数据库管理员执行下面的步骤：

• 关闭数据库
• 临时将xid_stop_limit降低10000000
• 启动数据库
• 在所有受影响的数据库上运行VACUUM FREEZE
• 将xid_stop_limit重置为原来的值
• 重启数据库

系统目录维护 

        多次使用CREATE和DROP命令的数据库更新会增长系统目录尺寸并且影响系统性能。例如，运行很多次DROP TABLE语句会降低总体系统性能，因为在目录表上的元数据查询期间会需要更多扫描时间。性能损失会在数千次或者数万次DROP TABLE语句之间发生，具体时间取决于系统。应该定期维护系统目录来回收已删除对象所占据的空间。如果长时间没有运行这种定期回收操作，那可能需要运行 一个更彻底的回收操作来清理系统目录。

常规维护

        推荐周期性地在系统目录上运行REINDEX和VACUUM来清理系统索引和表中已删除对象所占用的空间。如果常规的数据库操作包括很多DROP语句，那么每天在非峰值 时间用VACUUM命令运行一次系统目录维护是安全且适当的。可以在系统可用时执行这些操作：

• 在系统表上执行VACUUM操作
• 在系统表上执行ANALYZE操作，用以更新统计信息
• 在系统表上执行REINDEX命令以重建系统表索引。该操作移除索引膨胀并提高VACUUM性能

深度维护 

         如果很长时间都没有执行一次系统目录维护操作，该目录可能因为废弃空间而膨胀。这会导致简单的元数据 操作都会等待很长时间。在psql中用\d命令列出用户表需要超过两秒的等待，就是目录膨胀的一种征兆。

        如果发现系统目录膨胀的征兆，就必须在计划好的停机时段用VACUUM FULL执行一次深度系统目录维护操作。在这一时段中，停止系统上的所有目录活动，这种VACUUM FULL 系统目录维护过程会对系统目录加排他锁。以下是深度系统目录维护操作的步骤： 

• 停止数据库系统上的所有活动元数据操作
• 在系统表上执行REINDEX操作以重建系统表索引。该操作移除索引上的膨胀并提高 VACUUM操作性能
• 在系统表上执行VACUUM FULL命令
• 在系统表上执行ANALYZE命令以更新系统表的统计信息

 查询优化分析

        数据库使用一种基于代价的查询优化器，它依赖于数据库的统计信息。准确的统计信息帮助查询优化器 更好的评估选择度以及一个查询操作检索的行数。这些评估会帮助它选择最有效的查询计划。ANALYZE 命令会为查询优化器收集列级的统计信息。可以在同一个命令中同时执行VACUUM和ANALYZE操作。例如：

=# VACUUM ANALYZE mytable;

        当在一个显著膨胀的表上运行VACUUM ANALYZE 命令时，该命令可能会产生不正确的统计信息。对于大型的表，ANALYZE命令会从行的一个随机采样中计算统计信息。它会通过计算采样中每页的平均行数与表中实际页数的成绩来估算表中的总行数。如果采样包含很多空页，估计出的行计数可能会不准确。要从表中移除未使用的磁盘空间，可以在该表上运行命令VACUUM FULL。由于对表锁的需求， VACUUM FULL可能无法在非维护时段运行。

        作为一种临时的变通方案，可以运行ANALYZE来计算列统计信息，然后在该表上运行 VACUUM来生成准确的行计数。在cust_info表上先运行ANALYZE， 然后运行VACUUM。

ANALYZE cust_info;
VACUUM cust_info;