Greenplum与其他所有关系型数据库一样，拥有一套管理数据库内部对象及关联关系的元数据表，我们称之为Greenplum系统表。Greenplum的产品内核是基于postgresql数据库基础上开发完成的，因此，Greenplum系统表很多继承于postgresql数据库。
Greenplum的系统表大致可分为这几类：
1.数据库内部对象的元数据，如：pg_database、pg_namespace、pg_class、pg_attribute、pg_type、pg_exttable等。
这类系统表既涵盖了全局的对象定义，也涵盖了每个数据库内的各种对象定义。这类系统表的元数据不是分布式的存储，而是每一个数据库实例（不论是master实例还是segment实例）中都各有一份完整的元数据。但也有例外，如：gp_distribution_policy（分布键定义）表则只在master上才有元数据。
对于这类系统表，各个实例之间元数据保持一致十分重要。
2. 维护Greenplum集群状态的元数据，如：gp_segment_configuration、gp_configuration_history、pg_stat_replication等。
这类系统表主要由master实例负责维护，就如segment实例状态管理的两张表gp_segment_configuration和gp_configuration_history的数据是由master的专用进程fts负责维护的。
3. Persistent table，如：gp_persistent_database_node、gp_persistent_filespace_node、gp_persistent_relation_node、gp_persistent_tablespace_node。
这类系统表同样是存在于每一个数据库实例中。在每个实例内，persistenttable与pg_class/pg_relation_node/pg_database等系统表有着严格的主外键关系。这类系统表也是primary实例与mirror实例之间实现同步的重要参考数据。
在Greenplum集群出现故障时，会有可能导致系统表数据有问题。系统表出现问题会导致很多种故障产生，如：某些数据库对象不可用，实例恢复不成功，实例启动不成功等。针对系统表相关的问题，我们应该结合各个实例的日志信息，系统表的检查结果一起定位问题，本文将介绍一些定位、分析及解决问题的方法和技巧。
检查工具
Greenplum提供了一个系统表检查工具gpcheckcat。该工具在$GPHOME/bin/lib目录下。该工具必须要在Greenplum数据库空闲的时候检查才最准确。若在大量任务运行时，检查结果将会受到干扰，不利于定位问题。因此，在使用gpcheckcat前建议使用限制模式启动数据库，确保没有其他应用任务干扰。
分析方法和处理技巧
1、遇到临时schema的问题，命名为pg_temp_XXXXX，可以直接删除。通过gpcheckcat检查后，会自动生成对临时schema的修复脚本。由于临时schema的问题会干扰检查结果，因此，处理完后，需要再次用gpcheckcat检查。
2、如遇个别表对象元数据不一致的情况，通常只会影响该对象的使用，不会影响到整个集群。如果只是个别实例中存在问题，可以通过Utility模式连接到问题实例中处理。处理原则是尽量不要直接更改系统表的数据，而是采用数据库的手段去解决，如：drop table/alter table等。
3、persistent table问题，这类问题往往比较棘手，影响也比较大。依据gpcheckcat的检查结果，必须把persistent table以外的所有问题修复完之后，才可以着手处理persistent table的问题。
针对persistent table再展开讲述几种问题的处理技巧：
（1）报错的Segment实例日志中出现类似信息
| "FATAL","XX000","Number of freeTIDs 191, do not match maximum free order number 258, for 'gp_persistent_relation_node' |
该错误可能会导致实例启动失败，数据库实例恢复失败等情况。首先可在问题的实例（postgresql.conf）中设置参数gp_persistent_skip_free_list=true。让出问题的实例先启动起来。再进行gpcheckcat检查。在gpcheckcat的结果中应该能找到类似的问题：
| [INFO]:- [FAIL] gp_persistent_relation_node <=> gp_relation_node [ERROR]:-gp_persistent_relation_node <=> gp_relation_node found 442 issue(s) …… [ERROR]:-sdw5:40000:/data1/primary/gpseg24 [ERROR]:- relfilenode | ctid | persistent_tid [ERROR]:- 13795767 | (205,18) | None [ERROR]:- 13795768 | (205,17) | None [ERROR]:- 13795769 | (7444,134) | None [ERROR]:- 13799293 | (89,226) | None …… [INFO]:-[FAIL] gp_persistent_relation_node <=> pg_class [ERROR]:-gp_persistent_relation_node <=> pg_class found 442 issue(s) …… [ERROR]:-sdw5:40000:/data1/primary/gpseg24 [ERROR]:- relfilenode | nspname | relname | relkind | relstorage [ERROR]:- 13795741 | None | None | None | None [ERROR]:- 13795741 | None | None | None | None [ERROR]:- 13795741 | None | None | None | None [ERROR]:- 13795741 | None | None | None | None …… |
从上述检查结果可以看出persistent table的部分数据和其他系统表对应关系不正确。处理方法就是要修复persistent table数据。
（2）报错的实例日志中出现类似信息
| FATAL:Global sequence number 1131954 less than maximum value 1131958 found in scan ('gp_persistent_relation_node') |
该问题可能会导致实例启动失败。可在问题的实例（postgresql.conf）中设置参数gp_persistent_repair_global_sequence=true，便可修复相应问题，让相应实例正常启动。
（3）报错的实例日志中出现类似信息
| Persistent 1663/17226/21248339, segment file #1, current new EOF is greater than update new EOF for Append-Only mirror resync EOFs recovery (current new EOF 1419080, update new EOF 1416416), persistent serial num 5725616 at TID (3353,1) |
该问题会出现在AO表中，表示个别实例上的数据文件被损坏。问题可能会导致进程PANIC，实例启动失败。首先可在问题的实例（postgresql.conf）中设置参数gp_crash_recovery_suppress_ao_eof=true。让出问题的实例先启动起来。再进行gpcheckcat检查。确定问题所在并修复。而通常出问题的AO表已经损坏，建议rename或者删除。
（4）在gpcheckcat的检查结果中如果出现如下信息
| [INFO]:-[FAIL] gp_persistent_relation_node <=> filesystem [ERROR]:-gp_persistent_relation_node <=> filesystem found 52 issue(s) …… [ERROR]:-sdw1:40000:/data1/primary/gpseg0 [ERROR]:- tablespace_oid | database_oid | relfilenode_oid | segment_file_num | filesystem | persistent | relkind | relstorage [ERROR]:- 17001 | 272379 | 121899432 | 0 | t | f | None | None [ERROR]:- 17012 | 272379 | 121692973 | 1 | t | f | r | c [ERROR]:- 17012 | 272379 | 121693149 | 1 | t | f | r | c [ERROR]:- 17012 | 272379 | 121694359 | 1 | t | f | r | c …… |
检查结果表明文件系统中存在部分数据文件在系统表中没有对应的关系，也就是文件系统中有多余的数据文件。这种情况不会影响Greenplum集群的正常运作，可以暂时忽略不处理。
修复persistent table表的问题，不可手工修改，只能够使用Greenplum提供的修复工具gppersistentrebuild进行修复。工具提供了备份功能，在操作修复之前必须要执行备份操作。然后通过gppersistentrebuild，指定待修复的实例的contentid进行修复。
另外，如果primary实例与mirror实例之间是处于changetracking状态。一旦primary实例进行了persistent table的修复操作，primary实例与mirror实例之间只能执行全量恢复操作（gprecoverseg -F）。
上面所介绍的一些GUC参数，都是在修复系统表过程中临时增加的参数，待集群恢复正常之后，请将所修改过的GUC参数值恢复回原有默认状态。
本文所介绍的系统表的维护和修复技巧，希望可以帮助Greenplum DBA在故障发生时更有效的分析和定位问题。一旦出现故障，仍需第一时间寻求售后服务工程师和专业服务工程师的支持。