更新日期：2024年09月11日
检查数据库运行日志
数据库运行时，某些操作在执行过程中可能会出现错误，数据库依然能够运行。但是此
GBase 8c 管理员指南
南大通用数据技术股份有限公司
35
时数据库中的数据可能已经发生不一致的情况。建议按月检查GBase 8c 运行日志，及时发
现隐患。
前提条件
收集日志的主机网络通畅且未宕机，数据库安装用户互信正常。
日志收集工具依赖操作系统工具如gstack 等。
如果未安装该工具，
则提示错误后，
跳过
该收集项。
操作步骤
步骤1 以管理员用户gbase，登录数据库主节点。
步骤2 使用gs_collector 命令收集数据库日志，格式：
gs_collector --begin-time="begin_time" --end-time="end_time" [-h] [-f] [-o] [-l]
[--keyword=KEYWORD]
其中参数说明：
begin_time 参数：指定日志的开始时间
end_time 参数：指定为日志的结束时间
-h 参数：指定要连接到主机的名称
-f 参数：指定列出要连接到所有主机名称的文件
-o 参数：指定收集日志文件的存储路径
-l 参数：指定读取日志文件的路径
--keyword=KEYWORD 参数：指定存储日志文件的密码
步骤3 根据步骤2 的界面输出提示，进入相应的日志收集目录，解压收集的日志，并
检查数据库日志。
示例
以--begin-time 与--end-time 为参数执行gs_collector 命令。
GBase 8c 管理员指南
南大通用数据技术股份有限公司
36
[gbase@gbase8c ~]$ gs_collector --begin-time="20160616 01:01"
--end-time="20160616 23:59"
当显示类似如下信息表示日志已经归档。
……
Successfully collected files.
All results are stored in
/home/gbase/gbase8c/log/collector_20220818_165907.tar.gz.
以--begin-time，--end-time 与-h 为参数执行gs_collector 命令。
[gbase@gbase8c ~]$ gs_collector --begin-time="20160616 01:01"
--end-time="20160616 23:59" -h host_name
当显示类似如下信息表示日志已经归档。
……
Successfully collected files.
All results are stored in
/home/gbase/gbase8c/log/collector_20220818_173304.tar.gz.
以--begin-time，--end-time 与-f 为参数执行gs_collector 命令。
[gbase@gbase8c ~]$ gs_collector --begin-time="20160616 01:01"
--end-time="20160616 23:59" -f /opt/software/gbase/output
当显示类似如下信息表示日志已经归档。
……
Successfully collected files.
All results are stored in
/home/gbase/gbase8c/log/collector_20220818_173901.tar.gz.
以--begin-time，--end-time 与--keyword 为参数执行gs_collector 命令。
[gbase@gbase8c ~]$ gs_collector --begin-time="20160616 01:01"
--end-time="20160616 23:59" --keyword="os"
当显示类似如下信息表示日志已经归档。
……
Successfully collected files.
All results are stored in
/home/gbase/gbase8c/log/collector_20220818_174000.tar.gz.
以--begin-time，--end-time 与-o 为参数执行gs_collector 命令。
GBase 8c 管理员指南
南大通用数据技术股份有限公司
37
[gbase@gbase8c ~]$ gs_collector --begin-time="20160616 01:01"
--end-time="20160616 23:59" -o /home/gbase/gbase8c/log/output
当显示类似如下信息表示日志已经归档。
Successfully collected files.
All results are stored in
/home/gbase/gbase8c/log/output/collector_20220818_175622.tar.gz.
以--begin-time，--end-time 与-l 为参数（文件名必须以.log 为后缀）执行gs_collector 命
令。
[gbase@gbase8c ~]$ gs_collector --begin-time="20160616 01:01"
--end-time="20160616 23:59" -l /home/gbase/gbase8c/log/logfile.log
当显示类似如下信息表示日志已经归档。
Successfully collected files.
All results are stored in
/home/gbase/gbase8c/log/collector_20220818_175871.tar.gz.
MOT VACUUM 清理
使用VACUUM 进行垃圾收集，并有选择地分析数据库，如下所示。
【Postgres】
在Postgres 中，VACUUM 用于回收死元组占用的存储空间。在正常的Postgres 操作中，
删除的元组或因更新而作废的元组不会从表中物理删除。只能由VACUUM 清理。因此，需
要定期执行VACUUM，特别是在频繁更新的表上。
【MOT 扩展】
MOT 不需要周期性的VACUUM 操作，因为新元组会重用失效元组和空元组。只有当
MOT 的大小急剧减少，并且不计划恢复到原来大小时，才需要VACUUM 操作。
例如，应用程序定期（如每周一次）大量删除表数据的同时插入新数据，这需要几天时
间，并且不一定是相同数量的行。在这种情况下，可以使用VACUUM。
对MOT 的VACUUM 操作总是被转换为带有排他表锁的VACUUM FULL。
支持的语法和限制
按规范激活VACUUM 操作。
VACUUM [FULL | ANALYZE] [ table ];
只支持FULL 和ANALYZE VACUUM 两种类型。
VACUUM 操作只能对整个MOT 进行。
不支持以下Postgres VACUUM 选项：
FREEZE
VERBOSE
Column specification
LAZY 模式（部分表扫描）
GBase 8c V5 开发者手册
南大通用数据技术股份有限公司
471
此外，不支持以下功能：
AUTOVACUUM