diff --git "a/\350\277\201\347\247\273\345\256\236\346\210\230+\344\271\230\351\243\216\347\240\264\346\265\252\346\211\254\345\270\206\350\265\267\350\210\252.md" "b/\350\277\201\347\247\273\345\256\236\346\210\230+\344\271\230\351\243\216\347\240\264\346\265\252\346\211\254\345\270\206\350\265\267\350\210\252.md"
new file mode 100644
index 0000000000000000000000000000000000000000..9a0fefd6cac8aabf4e68342560079be5bb100018
--- /dev/null
+++ "b/\350\277\201\347\247\273\345\256\236\346\210\230+\344\271\230\351\243\216\347\240\264\346\265\252\346\211\254\345\270\206\350\265\267\350\210\252.md"
@@ -0,0 +1,38 @@
+
+【前言】
+接触ob也有快两年的时间了，客户生产也上线了6套生产环境了，在高考期间刚完成了两套新核心系统的迁移上线，趁现在整理下回顾下这些时间的努力和心得。毕竟独自看到世间的美景而无人分享，应该是一种遗憾吧？
+【前期准备】
+废话不多说直接上干货吧。
+很多同学不知道如何上手，如果是开源版本社区有很多大佬的实战文章来学习，如果想学习企业版可以做下阿里云的实验。
+https://edu.aliyun.com/lab/courses?pageNumber=1&_search=oceanbase
+里面有比较详细的实验手册，还有云环境练习。帮助大家熟悉操作。如果不想花费大洋去练习也可以看下我以前写的这篇文章
+https://zhuanlan.zhihu.com/p/372670472
+当然如果在私有环境练习可能会遇到很多问题，比如suse环境有好多坑要去踩，可以看下我之前记录的一些坑
+https://zhuanlan.zhihu.com/p/374215220
+【上线测试】
+上线前的准备很重要，毕竟君子藏器于身，待之以动。
+生产数据迁移可以有很多方式，比如通过dbcat+datax+obdumper的方式迁移，或者选择oms，一般我们生产上线的迁移都是通过oms迁移数据，然后dbcat+obdumper（obload）导入数据库对象。
+那主要需要测试什么那？
+1.数据的准确性
+我们是从oracle迁移到ob，oracle的数据库格式是gbk，ob是utf-8虽然oms可以进行转换，但是oracle库中本身数据存在乱码字符和非法时间（比如2022-02-00，正常是没事2月0日的），这类数据无法迁移，只能测试阶段通过oms校验得到明细去oracle端修改成合法的数据，在真正上线的时候才不会有问题。
+2.同步的效率和准确性
+因为上线割接时间限制，无法割接当晚完成全量的一次迁移，所以要提前同步数据，然后通过oms一直增量同步数据，oms增量是通过解析源端归档来进行同步，如果源端单个归档比较大，解析效率就有问题，我们源端通过设置archive_lag_target参数限制归档单个大小不超过2G来规避的。当然在月结的过程中仍然有效率问题，我们通过oms拉取多个解析store同时解析多个时间段的归档来优化了一些效率。
+因为源端数据来源于adg我们在上线前停了几次adg的应用，来保证源端数据的静止，来进行校验保证数据的一致性，oms版本不同可能有不同的问题，我们遇到了一种，因为我们有个系统adg主库是两节点，备库是一节点，造成oms拉取归档解析只解析了一个节点的归档，造成数据丢失，这种可以通过升级组件修改拉取store的参数来解决。
+3.默认的oms迁移参数设置虽然也不低，但是满足不了我们的需求，需要在oms参数设置里修改大点。
+4.反向的验证，因为上线之后oracle环境也要同步跑一段时间，防止因意外需要回退，那就要保证ob数据能实时同步回oracle环境，就需要验证反向同步的准确性，我们在上线前进行了三次模拟割接，包括上线当晚，分别挑选了一些表的ddl验证，包括无主键表、有主键表、无主键分区表、有主键分区表的验证，因为在去年的时候发生过反向验证update无法同步的情况，所以比较注意。大家还要注意现在oms虽然支持一些ddl操作同步，但是truncate分区这中操作无法同步可能造成数据不一致。
+5.ddl禁用，oms虽然支持ddl操作但是像上面说的一些truncate分区的操作无法同步，所以在上线前尽量禁止ddl操作，避免因此造成的数据不一致情况。在上线后反向同步时关掉允许ddl同步的开关，如果有表结构变更让同步链路报错，去处理比较好，跟业务人员说清楚情况，发脚本评审，两侧都执行就好了。
+6.*业务测试*
+一个新的数据库肯定会有与原来数据库不同的地方，所以一定要进行充分的业务测试，比如oracle有dblink的在ob端都要进行修改，有些特殊的dbms函数ob也是不支持的，需要用其他函数或者其他方法修改
+7.表结构和对象
+oracle因为有些字段类型（比如long，rowid之类的）和临时表无法迁移，需要业务确认修改ob端的结构或者重新构造。还有数据库对象在迁移过程中有些报错需要人工干预去修改。
+8.性能测试
+性能测试也很重要，需要提前测试相关业务的效率问题，提前进行优化，包括绑outline和创建新的索引等。有个比较经典的场景就是oracle因为有skip scan的索引扫描方式，所以where条件中只使用索引第二列也可以走索引，但是ob不可以，就需要新建索引或者调整sql。
+【上线】
+万事具备只欠东风
+其实如果前期测试和工作充分，在上线时遇到的问题就很少了。需要注意的就是在上线后，多让业务反馈，有什么问题及其解决，因为在测试阶段很多场景或者低频操作是测试不到的，可能还需要上线后保障、优化，我们遇到过迁移上线后有个别对象权限缺失或者sql需要优化的情况，比较容易解决。
+【总结】
+OB国产化数据库还在成长，在探索的过程中都是摸着石头过河，操作的每一步都要不断测试，也在不断出现新的问题。生态圈的完善本身也是在不断碰撞、修改中完善的。我们踩过的坑都会成为OB进步完善的台阶，后续的同仁再使用相关产品的时候将减少甚至不会遇到我们的问题。
+我相信ob的星星之火终会燎原
+行之所向，莫问远方。
+
+