有时间限制么？比如像Oracle那样超过undo_retention或者挤压出内存了就查不到了
2 个赞
麻烦老师以后把这种问题发到 OceanBase 技术问题 这个板块吧~
2 个赞
SQL Audit 淘汰机制
SQL Audit 淘汰机制是为了确保 gv$sql_audit 视图中的审计记录不会因为内存或记录数的限制而影响系统的性能。以下是 SQL Audit 淘汰机制的详细说明：
内存管理：
内存上限：SQL Audit 的内存上限 avail_mem_limit 由 min_memory * ob_sql_audit_percentage 计算得出，其中 min_memory 是租户资源单元定义中的最小租户内存，ob_sql_audit_percentage 是 SQL Audit 的租户内存占比。
内存检测间隔：系统后台任务每隔 1 秒会检测 SQL Audit 的内存使用情况，决定是否进行淘汰。
引用：
淘汰触发条件：
内存占用比例：
当 avail_mem_limit 在 [64M, 100M] 范围内时，内存使用达到 avail_mem_limit - 20M 时触发淘汰。
当 avail_mem_limit 在 [100M, 5G] 范围内时，内存使用达到 avail_mem_limit * 0.8 时触发淘汰。
当 avail_mem_limit 在 [5G, +∞] 范围内时，内存使用达到 avail_mem_limit - 1G 时触发淘汰。
数据条数限制：
当 SQL Audit 记录数超过 900 万条时，触发淘汰。
引用:
淘汰停止条件：
内存占用比例：
当 avail_mem_limit 在 [64M, 100M] 范围内时，内存使用降至 avail_mem_limit - 40M 时停止淘汰。
当 avail_mem_limit 在 [100M, 5G] 范围内时，内存使用降至 avail_mem_limit * 0.6 时停止淘汰。
当 avail_mem_limit 在 [5G, +∞] 范围内时，内存使用降至 avail_mem_limit - 2G 时停止淘汰。
数据条数限制：
当 SQL Audit 记录数降至 800 万条时，停止淘汰。
引用：
手动清空：
命令：可以使用 FLUSH SQL AUDIT 命令手动清空 SQL Audit 记录。
语法：
ALTER SYSTEM FLUSH SQL AUDIT [tenant_list] [GLOBAL];
说明：
如果在 tenant_list 中指定租户，则只删除指定租户的 SQL AUDIT。否则默认会删除所有租户的相关 SQL AUDIT。
如果指定了 GLOBAL，会删除所有 OBServer 上该租户的 SQL AUDIT。否则仅删除本机中相关租户的 SQL AUDIT。
引用：
日志检查：
日志路径：可以在 /home/admin/oceanbase/log 目录下的 observer.log 文件中搜索 sql audit evict record start 关键字，检查 SQL Audit 的淘汰日志。
命令：
cd /home/admin/oceanbase/log
cat observer.log | grep “sql audit evict record start”
引用：
总结
内存管理：SQL Audit 的内存上限由 min_memory * ob_sql_audit_percentage 计算得出，后台任务每秒检测内存使用情况。
淘汰触发条件：当内存使用达到特定阈值或记录数超过 900 万条时，触发淘汰。
淘汰停止条件：当内存使用降至特定阈值或记录数降至 800 万条时，停止淘汰。
手动清空：可以使用 FLUSH SQL AUDIT 命令手动清空 SQL Audit 记录。
日志检查：通过检查 observer.log 文件中的日志，可以了解 SQL Audit 的淘汰情况。
SQL Audit 淘汰机制
淘汰数据的方式
FIFO 淘汰原则：
描述：SQL Audit 淘汰机制遵循 FIFO（First In First Out，先进先出）的原则，即优先淘汰最早的记录。
解释：当内存使用或记录数达到淘汰阈值时，系统会首先淘汰最早的审计记录，以释放空间给新的记录。
引用：
内存和记录数双重限制：
描述：SQL Audit 的淘汰机制不仅依赖于内存使用情况，还受到记录数的限制。
内存限制：
触发条件：
当 avail_mem_limit 在 [64M, 100M] 范围内时，内存使用值达到 avail_mem_limit - 20M 时触发淘汰。
当 avail_mem_limit 在 [100M, 5G] 范围内时，内存使用值达到 avail_mem_limit * 0.8 时触发淘汰。
当 avail_mem_limit 在 [5G, +∞] 范围内时，内存使用值达到 avail_mem_limit - 1G 时触发淘汰。
停止条件：
当 avail_mem_limit 在 [64M, 100M] 范围内时，内存使用值降至 avail_mem_limit - 40M 时停止淘汰。
当 avail_mem_limit 在 [100M, 5G] 范围内时，内存使用值降至 avail_mem_limit * 0.6 时停止淘汰。
当 avail_mem_limit 在 [5G, +∞] 范围内时，内存使用值降至 avail_mem_limit - 2G 时停止淘汰。
记录数限制：
触发条件：当 SQL Audit 记录数超过 900 万条时，触发淘汰。
停止条件：当 SQL Audit 记录数降至 800 万条时，停止淘汰。
定期检测：
描述：系统后台任务每隔 1 秒会检测 SQL Audit 的内存使用情况和记录数，决定是否进行淘汰。
解释：这种定期检测机制确保系统能够及时响应内存和记录数的变化，避免因资源不足而导致的性能问题。
引用：
总结
FIFO 淘汰原则：SQL Audit 淘汰机制遵循 FIFO 原则，优先淘汰最早的记录。
内存和记录数双重限制：淘汰机制不仅依赖于内存使用情况，还受到记录数的限制。
定期检测：系统后台任务每隔 1 秒会检测 SQL Audit 的资源使用情况，决定是否进行淘汰。
SQL Audit 淘汰机制：批量淘汰还是一条条淘汰
SQL Audit 淘汰机制在实际操作中通常是逐条淘汰的，而不是一次性批量淘汰大量记录。这种逐条淘汰的方式有助于更精细地控制内存和记录数的使用，避免一次性删除大量数据对系统性能造成冲击。以下是详细的解释：
逐条淘汰：
描述：当 SQL Audit 记录达到淘汰条件时，系统会逐条淘汰最早的记录，直到满足停止淘汰的条件。
优点：
精细控制：逐条淘汰可以更精确地控制内存和记录数的使用，避免一次性删除大量数据导致的资源波动。
稳定性：逐条淘汰对系统性能的影响较小，可以更平稳地进行资源管理。
淘汰条件：
内存使用：
触发条件：
当 avail_mem_limit 在 [64M, 100M] 范围内时，内存使用值达到 avail_mem_limit - 20M 时触发淘汰。
当 avail_mem_limit 在 [100M, 5G] 范围内时，内存使用值达到 avail_mem_limit * 0.8 时触发淘汰。
当 avail_mem_limit 在 [5G, +∞] 范围内时，内存使用值达到 avail_mem_limit - 1G 时触发淘汰。
停止条件：
当 avail_mem_limit 在 [64M, 100M] 范围内时，内存使用值降至 avail_mem_limit - 40M 时停止淘汰。
当 avail_mem_limit 在 [100M, 5G] 范围内时，内存使用值降至 avail_mem_limit * 0.6 时停止淘汰。
当 avail_mem_limit 在 [5G, +∞] 范围内时，内存使用值降至 avail_mem_limit - 2G 时停止淘汰。
记录数：
触发条件：当 SQL Audit 记录数超过 900 万条时，触发淘汰。
停止条件：当 SQL Audit 记录数降至 800 万条时，停止淘汰。
定期检测：
描述：系统后台任务每隔 1 秒会检测 SQL Audit 的内存使用情况和记录数，决定是否进行淘汰。
解释：这种定期检测机制确保系统能够及时响应资源变化，逐条淘汰记录以维持资源的合理使用。
示例
假设 avail_mem_limit 为 100M，内存使用值达到 80M 时触发淘汰，系统会逐条淘汰最早的记录，直到内存使用值降至 60M 时停止淘汰。
[2025-06-09 10:00:00] INFO [SQL_AUDIT] Memory usage reached 80M, starting to evict records.
[2025-06-09 10:00:01] INFO [SQL_AUDIT] Evicted record with timestamp 2025-06-08 10:00:00.
[2025-06-09 10:00:02] INFO [SQL_AUDIT] Evicted record with timestamp 2025-06-08 10:00:01.
…
[2025-06-09 10:00:10] INFO [SQL_AUDIT] Memory usage dropped to 60M, stopping eviction.
总结
逐条淘汰：SQL Audit 淘汰机制通常采用逐条淘汰的方式，优先淘汰最早的记录，以精细控制内存和记录数的使用。
淘汰条件：当内存使用或记录数达到特定阈值时，触发淘汰；当内存使用或记录数降至特定阈值时，停止淘汰。
定期检测：系统后台任务每隔 1 秒检测资源使用情况，决定是否进行淘汰。
2 个赞
：批量淘汰还是一条条淘汰
2 个赞
又学习了
2 个赞
oracle sql相关的是 AWR 的保存期吧，
跟undo retention没有关系吧。
2 个赞
这种一致性查询,照理说应该保存快照
嗯嗯好的
要是sqlaudit每隔一段时间能保存快照就好了
感谢分享
保存不了吧，Oracle也实现不了好像
oracle的dba_hist快照有类似功能
想那么多干啥？？这种事情丢给OCP就完事了，反正大部分情况下都是看的慢SQL，你想保留或查询多久就多久，只要资源够大。
1 个赞
学习了