当然学习还是不能丢，总结也是学习，我看了看最近的公众号留言和微信留言，也积累了不少问题了，简单总结一下。
问题1：问题基于之前的一篇文章 一次性能突发情况的紧急修复(r9笔记第18天)
讲讲sqlt吧
把原库执行计划关键信息拿出来，替换目标库，这个怎么做（类似的另一个问题）
使用sqlt手工创建sql_profile(r4笔记第37天)
而正统的解释是：SQLT也叫作SQLTXPLAIN，是Oracle Server Technologies Center of Expertise - ST CoE 提供的一款工具，可以通过MOS ID【ID 215187.1】了解更多并下载
问题2：问题基于之前的一篇文章 服务器迁移的两种方式浅谈(r9笔记第15天)
问下那个数据量在10T左右逻辑数据泵导入会不会太慢，而且有些以前数据库的字段值改变了大小长度，经常在同样版本的数据库导入时报错，这个怎么办？
答：10T的数据量逻辑导入维护时长是个大问题，可能物理迁移的方式要好一些，比如XTTS,逻辑的OGG也可以考虑。如果字段长度大小不统一，前提需要时目标端的字段长度大于源端的，一种是使用OGG来配置兼容，另外一种就是逻辑导入，只导入数据
问题3：还是基于文章 服务器迁移的两种方式浅谈(r9笔记第15天)
在第二个方案中，怎么在机房三中搭建一主一备保证和机房一中的数据一致呢
答：这种方案迁移方式较多，OGG逻辑同步，Datapump逻辑导入，或者主从切换，重建备库都可以
建议一些命令和执行结果能不能截图，这样读起来跟方便。
问题4：ORA-00600的delete报错
这个问题是帮一个网友解答的，网友开门见山，就问了下面的问题。
网友问：我做了一个delete语句报错了，报错如下：
对于这类的问题，看起来确实是个硬骨头，delete抛ORA-00600着实罕见。所以可以借助搜索引擎或者Metalink来找到一些有价值的信息。看看错误的编码代表哪里出问题了。
带着侥幸，看到一篇相关的文章，是说可能是rename导致的此类问题，文章中是drop操作导致，和delete还是有一些差别。
可以参考 Doc ID 1612402.1，所以也是带着疑惑问他，是否dba_mview_logs中存在物化视图日志的信息，网友反馈是没有，但是我又提供了一个语句 ，在obj$中查看是有信息的。说明数据字典中的信息出现了不一致的情况。对于这类问题Oracle的一个建议就是使用重建物化视图日志，使用with rowid的方式来创建，然后删除，这种方法在这个网友的场景中也是可以的。所以问题是相似的。
官方的解释如下：
Cause
Dictionary information related to a materialized view log defined on the table is partly missing due to a rename of a table while a materialized view log was still defined on it and afterwards trying to drop the table.
The MLOG$ entry didn't exist but the MLOG$_... segment in OBJ$ still existed, and the table referenced in its flags that it uses a materialized view log.
Solution
To implement a solution for this issue please execute the following steps in the given order:
drop the MLOG$_... segment from the database using a DROP TABLE command
create a new materialized view log using CREATE MATERIALIZED VIEW LOG ON <table> WITH ROWID;
drop the table with the materialized view log defined on it
