分布式数据库承担高并发，海量数据，多租户能力，但是配套的问题查询重要手段gv$sql_audit全是内存态，不用太高的并发就被刷没了，并且是集群级，一个租户qps过高，其他租户也没了，有问题只能observer.log里一点点查，太不方便了
3.x版本中最近压测，查问题查到崩溃。
查了下，4.1应该还是内存态。。。
应该还早。。。持久化需要很大成本的
我觉得没有成本啊，分区存储，一级二级分区都用上，按照小时分区存储都可以。持久化存储多久，这个都可以设置参数的。
现在内存刷新也是定时任务清理，持久化分区存储一样可以。
磁盘占用不应该算成本，当遇到问题解决不了，那才是大成本。
是不是可以自己用触发器、物化视图等手段实现
ob应该不支持物化视图吧。
建一张物理表，然后对现有试图通过触发器在插入其他物理表？
还真么有探索过，感觉挺费劲
官方没有实现持久化，只能自己想办法了，这种方法我记得是有个大佬meetup的时候说的，我自己也没有真正实现过
哪一期，我去找找分享稿，看看咋搞的
我好像是在开发者大会上一个分会场里听到的，他也就是一句话描述了下，说可以用类似触发器，存储过程，物化视图等方式自己去实现。
关于物化视图，我这没有企业版，你可以试试oracle模式下有没有，我在官方文档里搜到了相关的语句，但是没有明确说明支持物化视图。
看楼主的意思是希望使用sql_audit来帮助查找在数据库运行时遇到的一些问题。当前OceanBase正在开发一些诊断工具，比如查找业务抖动、新SQL上线导致数据库卡顿，或者其它的问题。希望能够通过这些诊断工具来帮助定位问题，此功能预计可以在9月份上线第一期。
sql audit 持久化对查问题的帮助仅限于让性能数据保存的更久，不能直接解决问题。
如果对问题诊断有什么想法或者需求，也可以提出来聊一下。
是的，解决问题前提是要定位问题，gv$sql_audit可以有效帮助定位问题，但是对于分布式数据库，大并发，海量数据情况下，gv$sql_audit保持不了多久，很快刷没有了，就确实了定位问题的手段，又该怎么解决问题吗？
当然是希望提供更多工具，帮助定位问题，解决问题。并且提供足够长时间可以回溯。半夜/周末/放假遇到问题，有些问题是不会立即就有条件查，事后什么都查不到，那就无法定位，更谈不上解决问题。
我认为多一个sql诊断，并不能解决问题。
分析一段时间内，一个事务层面的问题，sql诊断做不到，还的从gv$sql_audit上去分析。
我记得去年年初，纪老师再一次直播中，就说会做，但是一年过去了，还没有。。。
企业版OCP有事务诊断 
SQL_AUDIT已经因为高并发，高QPS被刷没有了，也能吗？
如果租户内存大，淘汰速度还是快到来不及采集，就算做到持久化，一般存储也不一定 hold 得住的。如果你想回溯半夜/周末/放假遇到问题，那保存周期起码得8小时吧。先看看 1 小时最大需要多大存储空间，单算sql_audit 里的 sql_text 长度 最大 65535，假设单机 QPS 20000，
20000 QPS * 65535 * 3600 秒 / 1024 / 1024 / 1024 = 4394G.
另外，想查问题还得看执行计划吧，如果全是动态SQL，plan_stat 计划缓存数据量也差不多这么大（计划试图里的query_sql（65535）, statement （4096））。还要plan_explain 视图没算呢。。
这么看想持久化 1h，极端情况下，光 sql_audit 就得准备4T，按小时分区的话，4T 单分区 hold不住。如果还要存执行计划得8T。个人看法：采集解决不了的问题，持久化也难解决，就算能解决也得牺牲不菲的成本和稳定性。
都是那么长sql肯定存储多，我们oltp类型，没有那么长sql，业务两万多tps，数据库百万qps，就已经很难看到sql_audit了，很难分析
可以试试把内存搞大点，调整 sql_audit 占用内存大小。
个人看法: 磁盘不是没有消耗的，即使SQL不长，按小时持久化，一天估计也得至少2T的擦写，虽然占用不了多少空间，但是其实比较消耗磁盘寿命。
我也挺期待持久化功能，但是希望内核开发持久化的时候，想办法省点资源消耗，别玩几天把磁盘整报废了。
磁盘我可以好多点，12块3.84T，但是sys租户的内存大了，业务租户就会少了，内存更昂贵并且有限
企业版的有sqlauditstore工具
我们测试了的，也会丢数据。
并且sql_audit有85个字段，持久化只有43个字段，有些重要信息没有持久化。
10秒50000条，并发高了，数据丢了，我们就是丢了，找不到问题原因，然后才需要持久化。
获取时间调短，数量弄多，这个工具扛不住。并且是持久化为csv并且.tar.gz打包，用起来也不好，sql进行处理相对好一点，处理csv还是很麻烦的