关于config shard的状态不正常的处理

我写关于12.2 sharding database的文章已经好久了，今天再次把环境启动了起来，启动了主机之后，依次启动了listener和shardcat数据库和shard node数据库实例。检查shard状态的时候，发现报错：

（a）问题一：status显示warnings：

遇到这样的情况，我们可以使用recover shard的命令。注意recover shard -h出来的帮助是错误的。

正确的用法应该是recover shard -shard 。

我们运行这个命令，发现是gsm没有启动：

启动后，稍等片刻（大约10秒），检查状态就恢复成正常了(在这里，我们还没有真正用到recover shard，在下面一个问题时才正常用到)：

所以，重新启动之后，需要启动的有database，listener，和gsm。

（b）问题二：state显示ddl error
然后，在接着的实验中，我drop掉shardcat上的一个duplicate table，发现此时shard状态又不正常了。config shard的state显示ddl error。

首先，在shardcat上操作，drop掉duplicate表

发现此时数据并没有同步，在shard node上，还是可以查询到数据：

此时检查shard状态，变成DDL error：

我们可以在gsm的alertlog中看到一些提示信息：
（注：gsm的日志位置在/u01/ora12c/app/oracle/diag/gsm/sdb1/sharddirector1/trace/alert_shardcat.log）

其实，从这个log中，我们只是看到有ORA-01031 insufficient privileges的报错，但究竟是什么权限不足，我们还是得通过config shard命令来进一步看：

我们看到这个last failed ddl，是alter database link的时候出现权限不足。

所以我们找到了原因，进行修复：

可以看到，在修复问题的基础上，运行recover shard -shard 之后，就恢复了正常。

注意需要注意的是，如果root cause没找到，不知道是database link的权限问题，仅仅运行recover shard是没有效果的。

另外我们也要注意，除了一开始给app_schema的相关权限（一开始赋予的权限，见『创建Oracle sharding database』），我们还要给app_schema于alter database link的权限。