1、在合并过程中出了问题，比如磁盘空间不足，那么冻结的内存和new memtable这块怎么处理呢？会一直hang在这里么？

【答】

磁盘空间，靠初始化参数datafile_size/datafile_disk_percentage 指定。

合并过程中，存在写入放大现象：
即旧的stable, 只有在转储/合并完成之后，才会释放。这意味着在合并过程中，如果宏块不能重用的话，在最坏情况下可能需要占用2倍Partition存储大小的存储空间。对于一些超大的Partition以及空间不足的场景，可能存在风险。

当磁盘空间满了后，合并状态报 ERRPR，这个observer就没有办法恢复了。只能通过drop/add 补副本的方式来修复。

2、会不会出现这种情况：某台observer上的数据发生了变更，需要写到其他的observer的sstable里面去？为什么？

【答】一定会啊。
因为 sstable上的事务的同步流程是通过clog日志流把变更回放到follower的observer位置。follower的observer位置，一定是在其他的observer上。

3、OB有没有子游标的概念？因为Oracle里面如果同一个执行计划有很多个子游标的话，会造成CPU的开销很高，客户有这个顾虑。
【答】

OB里没有child cursor的概念。

4、负责RPC通信能不能用独立的网卡，跟业务网卡分离开？如果不能分离，那么如何监控RPC的流量？

【答】

现在没有这个的实现；但是备份恢复已经有功能能用和RPC通信的不同网卡了。

监控RPC的流量：
gv$obrpc_incoming和gv$obrpc_outgoing中获取的RPC累计值，以及OCP上的瞬时值趋势。
或者tars(等操作系统命令看OS级网络相关指标。

5、除了range分区之外，其他的分区类型是不是可以进行分区的增减？客户说有人给他的资料说其它类型的也可以，所以需要确认一下。
手册上的语法是这样的：
    | ADD PARTITION (range_partition_list)
    | DROP PARTITION (partition_name_list)

【答】
range分区
range column分区都可以。
并且最后一个partition不能是maxvalue.

6、在课件SQL调优里面，有一页提到"建表后再创建索引，是同步生效，表中数据量大时需要等待一段时间"。
6.1 DDL是异步操作，所以前台会立刻返回执行成功对吧？

【答】

是的。命令行会立刻返回执行成功。

6.2 我们用什么方法能知道这个索引什么时候建立完成能够生效？

【答】

check _all_local_index_status if AVAILABLE，但不能看进度。

6.3 这句话里面的“同步生效”怎么理解呢？既然是要等一段时间，就不是同步呀。

【答】

指的是DDL部分。

OB 2.x上索引创建的命令会立刻返回结果，可是索引的构建过程是异步的。
这是因为：目前OB创建索引分两个阶段，
第一，RS完成创建索引DDL；

第二，build index并更新索引状态。

现阶段，OB是异步建索引，也就是在第一阶段就客户端返回。

7、remote模式下，在远端的数据是要回到负责分发的第一个observer上面再返回给obproxy？

【答】

是的。就是以上逻辑。对于那条SQL来说，response time 变差了；但是这次会帮助纠正location cache,就准了。

8、distributed模式，是不是所有的数据还要汇总到负责分发的observer，比如做排序啥的。

【答】

是的。
用mapper和reducer方式实现的。
1. master将map和reduce任务分发到这些机器，并监控他们的状态。
2. mapper将中间结果分片存储在本地，在执行完分配到的任务后，向master汇报中间结果位置以及相关信息。
3. 等所有的mapper完成后，master向所有的reduce通知中间结果的位置与信息。
4. reducer通过master通知的信息远程拉取mapper生成的数据并处理。

9、OB在合并完之后，会刷新执行计划，这个刷新是把plan_cache整个清空，还是在原有的基础上做一些淘汰或者更新，我测试环境看了下是整个清空了

【答】

是的，合并会清空整个 plan cache 。

10、在用mysql客户端连的时候要加-c来保证hint生效，我如果是外部业务用jdbc连，应该怎么处理，还是用jdbc连不存在这个问题？

【答】

jdbc不存在这个问题，这是MySQL客户端的问题。

11、在集群合并的过程中，是否可以进行DDL操作？进一步，需要和不需要重写数据的DDL分别是否可以？

【答】

在集群合并的过程中，可以进行DDL操作。需要和不需要重写数据的DDL都可以。 这是因为OB有多版本schema的概念，能保存旧版schema形态。 某session发起DDL后，RS调度执行，并持久化保存这些多版本schema信息保存在 内部表中，然后异步刷新到其他的server. 合并过程，其存储格式，需要读取到对应时间的schema信息。 不依赖当前的ddl状态。

12、read-only和Log-only这两种zone是否参与DDL？

【答】

不参与。就是异步地从内部表中刷出这些信息。

13、“基于规则的查询改写并不能总是把 SQL 往“好”的方向进行改写，所以需要代价模型来判断。”，“基于代价的改写之后可能又会重新触发基于规则的改写”，那么这两个地方触发的机制分别是什么呢？

【答】

基于规则的改写，就是看代码上是否存在那些 可以被改写的形态，有，则尝试改之。改写一直到 SQL 不能被改写为止或者迭代次数达到预先设定的阀值

14、关于“全局索引模式是没有回表的”的解释。

【答】

全局索引模式是没有回表的原因是：没有和全局索引对应的一张全局表，从全局索引主要找到目标数据所在的分区信息和 rowkey。

所以看执行计划的时候， 对于全局索引看不到回表的信息。

Is_index_back=false 总是看到的是这个， 然后根据全局索引拿到的信息再去查找分区表的时候， 再用 table lookup 算子。