只能通过sql_audit视图来排查么？他的保留时间不太够，需要调整内存设置增加一些保留时间。还有其他方式能看吗？
v3版本这里的sql信息刷出去了，就不会转存了吧？
2 个赞
SQL_AUDIT是在内存中的，目前不会把历史数据写到磁盘，刷没有就找不到了
2 个赞
这贴感觉有点灌水了 
方法很多，自己想
归档，事务日志，sql执行计划表等都可以吧
根据您的问题，我将从以下几个方面进行解答：
-
关于排查历史时刻某条 SQL 的参数值
根据文档信息，OceanBase 数据库提供了多种视图用于 SQL 诊断（参考文档：分析 SQL 监控视图 → SQL 监控概述）。除了GV$OB_SQL_AUDIT视图外，您还可以通过以下视图获取相关信息：-
GV$OB_PLAN_CACHE_PLAN_STAT：执行计划统计信息。 -
GV$OB_PLAN_CACHE_PLAN_EXPLAIN：执行计划详细信息。 -
GV$SQL_PLAN_MONITOR：SQL 算子级统计信息，适用于 V4.0 及以上版本。 -
DBA_OB_OUTLINES和DBA_OB_CONCURRENT_LIMIT_SQL：Outline 和限流信息。
如果您需要更详细的 SQL 参数值和执行上下文，
GV$OB_SQL_AUDIT是一个重要的来源。但需要注意的是，sql_audit_memory_limit在 V4.0 版本中已被移除（参考文档：sql_audit_memory_limit），取而代之的是通过系统变量ob_sql_audit_percentage来控制 SQL Audit 内存占用比例（参考文档：ob_sql_audit_percentage）。 -
-
关于调整 SQL 审计数据的保留时间
在 OceanBase 数据库中，SQL 审计数据的保留时间主要受内存限制影响。对于 V3 版本，您可以尝试调整以下参数来增加 SQL 审计数据的保留时间：-
sql_audit_memory_limit：设置 SQL 审计数据可占用的最大内存，默认值为 3G，取值范围为[64M, +∞)（参考文档：sql_audit_memory_limit）。 - 调整方法可以通过 SQL 命令完成：
ALTER SYSTEM SET sql_audit_memory_limit='6G';
需要注意的是，V3 版本中 SQL 审计数据是存储在内存中的，当内存不足时，旧的数据会被淘汰。因此，即使调整了
sql_audit_memory_limit，也无法保证所有历史数据都能被永久保留。 -
-
关于 SQL 审计数据是否转存到磁盘
根据您的描述，在 V3 版本中，SQL 审计数据仅存储在内存中，不会自动转存到磁盘。这意味着一旦数据被淘汰出内存，就无法再通过GV$OB_SQL_AUDIT视图查询到。如果您需要长期保存 SQL 审计数据，可以考虑以下方案：-
手动导出数据：定期将
GV$OB_SQL_AUDIT中的数据导出到外部存储。 - 使用审计日志功能：OceanBase 数据库支持将审计日志写入文件或表中，具体配置方法请参考官方文档。
-
手动导出数据：定期将
-
其他方式查看历史 SQL 参数值
如果 SQL 审计数据的保留时间不足以满足需求，您可以尝试以下方法：-
闪回查询：如果目标 SQL 执行的时间范围内未超过
undo_retention设置的时间，您可以使用闪回查询功能获取历史数据（参考文档：闪回查询）。例如：SELECT * FROM your_table AS OF SNAPSHOT 'timestamp' WHERE condition; -
统计信息收集历史：虽然主要用于优化器统计信息，但您也可以通过
DBMS_STATS.PURGE_STATS或相关视图检查历史统计信息（参考文档：统计信息收集监控诊断 → 统计信息收集历史信息的清理策略）。
-
闪回查询：如果目标 SQL 执行的时间范围内未超过
总结来说，GV$OB_SQL_AUDIT 是排查历史 SQL 参数值的主要手段，但其保留时间受限于内存设置。在 V3 版本中，SQL 审计数据不会自动转存到磁盘，因此建议通过调整 sql_audit_memory_limit 或手动导出数据的方式来延长保留时间。此外，闪回查询和统计信息收集历史也是可能的补充手段。
如有进一步疑问，请提供更多细节以便深入探讨！
具体信息可参考以下文档:
1 个赞