1.非标准操作类

1.1 vb_dump -h 远程备份: 查询失败:ERROR: unrecognized configuration parameter "enable_duplicate_indexnames"

• 数据库版本：Vastbase G100 2.2 Build 15.8

• 兼容模式：A

• 问题现象
  使用2.2 Build 15.6中的vb_dump工具，通过指定-h参数去备份远端2.2 Build 15.8的数据，执行发生报错，两边都是A兼容模式，报错内容为

• 问题原因
  原因是这个参数是2.2.15 psu8引入的，之前的版本识别不了。

• 解决办法
  不同版本之间不要使用vb_dump进行远端备份。
  不仅是因为参数不识别的原因，还因为不同版本元数据、系统表等也存在差异。

1.2 vb_dump源库100G+,备份文件3G+，恢复后数据不完全

• 数据库版本：Vastbase G100 2.2 Build 10.11

• 兼容模式：A

• 问题现象
  目标库导入存在value too long报错

以cm_mbox表为例进行排查，违反了非空约束。
在源端查看表结构、数据及兼容模式，源端为B兼容模式

查看目标端兼容模式，发现是A兼容模式。
在目标端重建库指定兼容模式为B，重新导入没有报错，查询两边数据一致。

查看表统计信息，发现源端表数据update频繁，存在膨胀，create table as select*from 原表，实际只有30MB。

• 问题原因
  1.恢复数据不全原因: 源库为B兼容模式，目标库为A兼容模式，导入数据存在value too long及违反非空约束相关报错，导致部分数据未导入成功。
  2.备份数据量不一致原因:源库表DML频繁，存在很多dead元组，表膨胀严重，因此备份文件大小和看到的库表大小差异很大。

• 解决办法
  重建目标端数据库指定兼容模式为B兼容模式，重新导入数据即可。

1.3 包名加引号时无法被vb_dump导出

• 数据库版本： Vastbase G100 2.2 Build 15.7
• 兼容模式：A
• 问题现象：

• 问题原因：
  问题原因
  "my_pkg.package_test"并不表示在my_pkg这个schema下建立包package_test，而是表示在public下建立名为"my_pkg.package_test"的包，dump语句中只添加的-n参数规定只导出my_pkg下的对象，所以在public下的"my_pkg.package test"无法被导出。

• 解决方法：
  改成"my_pkg"."package_test"

1.4 备库vb_dump导出数据报错ERROR:canceling statement due to conflict with recovery

• 数据库版本：Vastbase G100 2.2 Build 15.5
• 问题现象
  由于与恢复操作冲突，正在取消语句命令。

• 问题原因
  客户数据库为集群环境，使用备节点进行vb_dump导出操作，此时如果WAL回放与vb dump查询相同的对象，此时wal日志回放会等待查询执行完成，但等待时间由参数max_standby_streaming_delay确定（默认是3s），wal回放线程在等待超过max_standby_streaming_delay参数配置的时间，wal回放线程会杀掉备节点的查询进程，来保障wal回放顺利进行。

• 解决办法

• vb_dump操作避免在备节点执行，存在概率造成导出线程中断。(物理备份恢复也是一样)

• 如必须在备节点完成，则选择业务低峰操作，或在vb_dump操作前临时增大max_standby_streaming_delay参数值，操作后回调，无需重启即可生效。

2.参数配置类

2.1 MySQL兼容模式lower_case_table_names=1时，vb_dump导出大写的表报错 no

matching tables were found for pattern "S1.Tea'

• 数据库版本：Vastbase G100 2.2 Build 15.7
• 兼容模式：B
• 问题现象：

• 问题原因
  vb dump中即使添加双引号，获取到的字符串也是双引号内的内容如Tea，由于设置的lower_case_table_names =1对象名统一使用小写样式保存，会导致对象找不到。
• 解决办法
  参考官网说明，使用反斜杠转义。
  如果携带双引号，则只会获取双引号内的内容，即 -t Tea 和 -t"Tea"的效果是一样的，又因为
  lowercase tablenames 设置为1（大小写不敏感），因此查询时会全部转为小写，要导出大写的表按照规避方法即可 -t"Tea"

• 成功案例

2.2 vb_restore -p 5432 -f /data/backup/tcxc_test.dmp -d test_db报错:必须为gs_restore指定转储文件名/路径

• 数据库版本：Vastbase G100 2.2 Build 10 commit 14301
• 兼容模式：A
• 问题现象：vb_dump 导出，在其他库上还原vb_restore失败。

• 问题原因
  vb_restore恢复时直接指定备份文件即可，不需要加-f(-f 指定生成脚本的输出文件，-d和-f不能同时使用)

• 解决办法
  -d和-f不同时使用。

2.3 备库开启极致rto后，vb_dump报错:ERROR SETTRANSACTION ISOLATION LEVEL must be called before any query

• 数据库版本：Vastbase G100 2.2 Build 15.7
• 兼容模式：A
• 问题原因
  极致RTO不支持商用，建议不要上生产。
• 解决办法
  关闭备库极致RTO。

3.已修复缺陷

3.1 SQL Server兼容模式下，vb_dump导出包含关键字top的表报错，查询失败: ERROR:syntax error at or near "top"

• 问题原因
  MSSOL兼容模式的导出场景下，缺少检测名称是否是关键词的逻辑
• 解决办法
  升级数据库至Vastbase G100 2.2 Build 15.7或以上版本。
  规避方案:在vb_exclude_reserved_words中配置top，屏蔽关键字(但需要重启数据库生效，且涉及top关键字的功能可能无法使用，需要结合实际业务场景考虑)。

3.2 vb dump备份带auto_increment序列的数据，当使用-a导出时，报错:不允许修改由

auto increment拥有的序列

• 问题原因
  auto_increment列会自动创建一个sequence，该sequence不能手动setval，全量导出时，表信息会记录autoinc对应的sequence的名字，后续导出sequence时可以忽略。仅数据导出时，表信息没有记录autoinc对应的sequence的名字，导致该sequence没有被忽略，最后导致导入报错。
• 解决办法
  升级至2.2 Build 15.8或以上版本,

3.3 vb_dump导出带有out参数的存储过程，导入时报错

• 问题描述
  vb_dump导出带有out参数的存储过程，导入时报错。
• 测试用例

导出正常：

导入报错：

• 问题原因
  sqlserver兼容模式下存储过程含0ut参数匹配时考虑不全，导致某些场景无法正确匹配
• 发布计划
  V2.2.15.8补丁

3.4 vb_restore导入大量临时表时，导入速度慢

vb_restore导入速度越来越慢，接近10000条每导入100条数据接近1分钟。由于太慢，没有完成导入。
导入数据中存在大量临时表。换成G1002215.5数据库导入，速度正常。

测试用例：

• 问题原因
  客户用到了多个全局临时表，代码原本设计中，如果一个会话中有多个临时表带有on_commit_delete，当会话中的某个事务即使只是用到了其中一张也会做所有临时表的truncate。这个逻辑本身是错误的。
• 解决方案
  在事务中新增一个hash表，当它提及某个临时表就把临时表加入这个hash表，最后做truncate的时候，通过hash表来找到与这个事务相关的临时表进行truncate。
• 发布计划
  2.2.10 PSU19

3.5 B兼容模式，lower_case_column_names=0，vb_dump返回的列名大小写不敏感

• 问题描述
  B兼容模式，lower_case_column_names=0，vb_dump返回的列名大小写不敏感
• 测试用例

• 问题原因
  本问题的场景就是关键字直接作为列名，在导出元数据的时候误判为应该带双引号，并且选择了转小写的版本。实际这种情况应该不带双引号导出。
• 发布计划
  V2.2.15.7补丁、V2.2.10.19补丁

3.6 恢复备份后索引名后面自动增加了“数字”

• 问题描述
  备份索引后，vsql恢复的时候索引名称后会被加”数字"，当使用force index时，因为找不到索引而报错。
• 测试用例
  备份中的索引DDL: CREATE INDEX idx_alarmevent_type_502047 ON ipc_alarmevent USING btree (alarmtype,cttime,ipcarea,chktimes, alarmno, procstatus);
  但是在图中可以看到，索引名变成了:idx_alarmevent_type_502047_55462

• 问题原因
  原因是B模式实现重复索引名是通过在索引名后增加关系表的oid后缀进行区分，（备份时这样做是没问题的），恢复时遗漏了 pg_get_indexdef 中截断这个后缀。
• 解决方案
  已将该特性合入2215最新版本
• 发布计划
  V2.2.15.8补丁

3.7 创建有发布或订阅的库，vb_dump导出报错Segmentation fault或invalid dumpId 32665或 invalid dumpId 0.(数字不固定)

• 问题原因
  问题原因是vb_dump对sub和pub做备份时，提前释放了object的内存
• 解决办法
  升级到2210 psu14及以上版本。2215也已修改。

3.8 去掉vastbase_sql_mode 中的ansi_quotes值，vb_dump报错

• 问题原因
  当没有启用ANSI_QUOTES时，双引号引用内容被解释为字符串。

• 解决办法
  规避方案:vastbase_sql_mode中添加ansi_quotes，导出后再修改还原参数配置
  预计2215 PSU9修复。

4.规划中

4.1 性能：vb_dump导出效率较低，和mysqldump导出相比相差时间较大

• 问题现象
  测试两张空表的导出速度如下，mysqldump耗时为0.018s，pg_dump耗时为2.011S。

测试结果:在2.2 Build 15.7、2215.8(包括重新初始化实例)、V3.0.8测试
2215.7和8均比较慢，V308效率高。

查看2215日志发现存在很多个pg_catalog.gs_is_recycle_obj函数调用。
而V3.0.8仅调用了3次该函数。

通过打开server的 log_statement，记录dump期间所有的SOL，发现几个大量被执行的SOL:
1.gs_is_recycle_obj，被执行7000+次
2.SELECT * FROM pg_proc a LEFT JOIN pg_namespace b on a.pronamespace=b.oid WHERE a.proname='gs_is_recycle_obj' and b.nspname='pg_catalog'; 查询gs_is_recycle_obj 函数是否存在，被执行 7000+次
3.select count(*) from pg_depend xxx;查询pg_depend确认package，被执行700+ 次。
4.working_version_num()函数，被执行3000+次

• 问题原因
  旧版dump代码设计问题，相当于一次简单的vb_dump，即使只导出一个表，也要执行 2W+条SQL，所以CPU被占用高。导出效率低。
• 解决办法
  计划2215 psu9、2210 psu21修复。

4.2 性能：308导出10w空表，postgres导出1分半导入1分钟，vb导出2h+导入83分钟

• 问题原因
  vb_dump代码设计原因。执行了一些无谓的sql，导致性能下降。

• 解决办法
  预计308 PSU3修复。