问题定位

1.不一致问题

1. 真的是问题吗？ 首先，取得不一致的用例，了解这个用例是怎么测试 数据一致性的，确认问题是真的存在，防止无效的投入。了解用例不是无用功，不了解用例，也没办法确认错误出现场景少了/多了哪些数据。

2. 问题可以复现吗？ 可以复现的问题都是好问题，如果问题好复现，单线程可以复现，gdb 跟踪一下即可。如果是并发下才可以复现，考虑加日志，列存的日志可以放在 锁行之后，更新/删除/插入修改之前，把数据打出来。根据日志分析

3. 环境可以重新拉起吗？ 对于不可复现的问题，如果环境还在，并且根据用例确定了丢失/新增的数据，可以备份环境，在自己本机上拉起。关闭转换和后台任务，后台任务可能会产生redo，破坏环境，所有必须保证备份环境后再拉起，同时关闭后台任务。

对于结果不一致的问题，可以使用闪回查询的方式，二分查找scn，找到不一致时的scn，dump redo 文件，找到这个scn提交时发生的事务，根据这个事务，一般可以定位到问题发生的原因。

 select * from table xxx as of scn xxxx ;

scn 0 ；

t1 insert  1;

commit；

scn1 

t2 insert 2 ;

commit;

scn 2

1. redo 还在吗？ 对于瞬时不一致，可以在redo 文件中打印出redo 操作的数据。从而查找到不一致发生时，查询的数据发生的变化，根据这些信息定位不一致问题。

2. 尝试复现吧！ 如果什么都没剩下，只有一个不一致的输出结果，只能尝试复现。同时分析用例结果，根据结果排查可能出现不一致的模块

2.内存泄露分析

解决思路
复现，内存泄露最先想到的办法应该是编译一个asan 包复现，一般比较容易可以复现出泄露堆栈。跟着堆栈一般可以找到泄露点。
如果无法复现，可能出错场景，需要并发/特殊的执行计划/出错 才能复现，可以构造收集统计信息，随机出错场景复现。
以上方法尝试过后，还是无法定位，考虑根据core dump 查找到没有释放的内存，根据内存的特征查找到泄露的内存结构体，根据结构体排查代码

了解内存结构，分析字段含义

3.利用redo分析问题

（1）使用工具，将redo文件和归档文件解析出来。
（2）发生core的时候，内存中可能还有没来得及持久化的redo，也能够解析出来，帮助定位。
（3）需要阅读代码找到redo记录的格式，根据格式以及core中的关键信息，过滤查找解析出来的redo文件中我们想要看的redo内容。

4. 大页内存

Linux 内核里，大页内存有个 overcommit 选项，允许换出不常用的大页内存，使得进程可以创建超出物理内存限制的大页内存，但这需要进程预先申请大页内存，但不是频繁访问大页内存，否则会有性能问题。