使用 extract_sqlaudit_proc 存过分析ob性能问题

小至尖尖2024-08-10 20:49

最近在某个金融单位核心系统项目做ob的性能压测，期间遇到不少问题，现场两周了每天都加班到凌晨一两点左右，真的是累死。🤢🤢

我其实进ob之前有心理预期，卷就卷吧，八九点下班也能接受，没想到真到了干项目的情况下，天天凌晨下班，真怕不知道啥时候会猝死。😂😂

ob被挺多人诟病的是gv$ob_sql_audit视图，如果有大量的事物在数据库里面执行，这个视图保存的内容很快就会被刷掉，而且做查询分析速度非常慢，随便一条加个谓词过滤的语句估计都要执行个几分钟才能出结果，很难分析出业务接口到底是哪个事物的SQL缓慢。

虽然可以通过ob_sql_audit_percentage参数调大gvob_sql_audit视图保存的内容，但是如果连续的高并发压测情况下，一样也会把里面的内容很快刷新，所以我们需要将gvob_sql_audit数据持久化到数据表里面，添加合适的索引用来分析server层不同场景业务接口的sql语句，到底慢在哪个环节，来进行针对性的调优。

所以我到了现场了解情况以后，花半天时间编写和调试extract_sqlaudit_proc这个存储过程来帮我抓server层的数据，这个过程后续帮我分析不同场景的性能问题省了很多功夫。

1、xz_sql_audit表、extract_sqlaudit_proc 过程代码

重点提示：这个方案仅在oracle 租户上使用。

sql 复制代码 
-- 创建分析表
CREATE TABLE XZ_SQL_AUDIT(
 C_ID							  							NUMBER(38),				-- 唯一ID
 C_RQ_TIME					      				TIMESTAMP,				-- 请求时间
 C_BATCH_ID						  					NUMBER(38),				-- 插入批次	
 C_NAME							  						VARCHAR2(100),			-- 场景名称
 C_FLAG							  						CHAR(2),					-- s 为拉取单个事务，m 为拉取多个事务（压测）
 SVR_IP                           VARCHAR2(46)      ,
 SVR_PORT                         NUMBER(38)        ,
 REQUEST_ID                       NUMBER(38)        ,
 SQL_EXEC_ID                      NUMBER(38)        ,
 TRACE_ID                         VARCHAR2(128)     ,
 SID                              NUMBER(38)        ,
 CLIENT_IP                        VARCHAR2(46)      ,
 CLIENT_PORT                      NUMBER(38)        ,
 TENANT_ID                        NUMBER(38)        ,
 EFFECTIVE_TENANT_ID              NUMBER(38)        ,
 TENANT_NAME                      VARCHAR2(64)      ,
 USER_ID                          NUMBER(38)        ,
 USER_NAME                        VARCHAR2(64)      ,
 USER_GROUP                       NUMBER(38)        ,
 USER_CLIENT_IP                   VARCHAR2(46)      ,
 DB_ID                            NUMBER(38)        ,
 DB_NAME                          VARCHAR2(128)     ,
 SQL_ID                           VARCHAR2(32)      ,
 QUERY_SQL                        CLOB              ,
 PLAN_ID                          NUMBER(38)        ,
 AFFECTED_ROWS                    NUMBER(38)        ,
 RETURN_ROWS                      NUMBER(38)        ,
 PARTITION_CNT                    NUMBER(38)        ,
 RET_CODE                         NUMBER(38)        ,
 QC_ID                            NUMBER(38)        ,
 DFO_ID                           NUMBER(38)        ,
 SQC_ID                           NUMBER(38)        ,
 WORKER_ID                        NUMBER(38)        ,
 EVENT                            VARCHAR2(64)      ,
 P1TEXT                           VARCHAR2(64)      ,
 P1                               NUMBER(38)        ,
 P2TEXT                           VARCHAR2(64)      ,
 P2                               NUMBER(38)        ,
 P3TEXT                           VARCHAR2(64)      ,
 P3                               NUMBER(38)        ,
 WAIT_CLASS_ID                    NUMBER(38)        ,
 WAIT_CLASS#                      NUMBER(38)        ,
 WAIT_CLASS                       VARCHAR2(64)      ,
 STATE                            VARCHAR2(19)      ,
 WAIT_TIME_MICRO                  NUMBER(38)        ,
 TOTAL_WAIT_TIME_MICRO            NUMBER(38)        ,
 TOTAL_WAITS                      NUMBER(38)        ,
 RPC_COUNT                        NUMBER(38)        ,
 PLAN_TYPE                        NUMBER(38)        ,
 IS_INNER_SQL                     NUMBER(38)        ,
 IS_EXECUTOR_RPC                  NUMBER(38)        ,
 IS_HIT_PLAN                      NUMBER(38)        ,
 REQUEST_TIME                     NUMBER(38)        ,
 ELAPSED_TIME                     NUMBER(38)        ,
 NET_TIME                         NUMBER(38)        ,
 NET_WAIT_TIME                    NUMBER(38)        ,
 QUEUE_TIME                       NUMBER(38)        ,
 DECODE_TIME                      NUMBER(38)        ,
 GET_PLAN_TIME                    NUMBER(38)        ,
 EXECUTE_TIME                     NUMBER(38)        ,
 APPLICATION_WAIT_TIME            NUMBER(38)        ,
 CONCURRENCY_WAIT_TIME            NUMBER(38)        ,
 USER_IO_WAIT_TIME                NUMBER(38)        ,
 SCHEDULE_TIME                    NUMBER(38)        ,
 ROW_CACHE_HIT                    NUMBER(38)        ,
 BLOOM_FILTER_CACHE_HIT           NUMBER(38)        ,
 BLOCK_CACHE_HIT                  NUMBER(38)        ,
 DISK_READS                       NUMBER(38)        ,
 RETRY_CNT                        NUMBER(38)        ,
 TABLE_SCAN                       NUMBER(38)        ,
 CONSISTENCY_LEVEL                NUMBER(38)        ,
 MEMSTORE_READ_ROW_COUNT          NUMBER(38)        ,
 SSSTORE_READ_ROW_COUNT           NUMBER(38)        ,
 DATA_BLOCK_READ_CNT              NUMBER(38)        ,
 DATA_BLOCK_CACHE_HIT             NUMBER(38)        ,
 INDEX_BLOCK_READ_CNT             NUMBER(38)        ,
 INDEX_BLOCK_CACHE_HIT            NUMBER(38)        ,
 BLOCKSCAN_BLOCK_CNT              NUMBER(38)        ,
 BLOCKSCAN_ROW_CNT                NUMBER(38)        ,
 PUSHDOWN_STORAGE_FILTER_ROW_CNT  NUMBER(38)        ,
 REQUEST_MEMORY_USED              NUMBER(38)        ,
 EXPECTED_WORKER_COUNT            NUMBER(38)        ,
 USED_WORKER_COUNT                NUMBER(38)        ,
 SCHED_INFO                       VARCHAR2(16384)   ,
 PS_CLIENT_STMT_ID                NUMBER(38)        ,
 PS_INNER_STMT_ID                 NUMBER(38)        ,
 TX_ID                            NUMBER(38)        ,
 SNAPSHOT_VERSION                 NUMBER(38)        ,
 REQUEST_TYPE                     NUMBER(38)        ,
 IS_BATCHED_MULTI_STMT            NUMBER(38)        ,
 OB_TRACE_INFO                    VARCHAR2(4096)    ,
 PLAN_HASH                        NUMBER(38)        ,
 PARAMS_VALUE                     CLOB              ,
 RULE_NAME                        VARCHAR2(256)     ,
 TX_INTERNAL_ROUTING              NUMBER            ,
 TX_STATE_VERSION                 NUMBER(38)        ,
 FLT_TRACE_ID                     VARCHAR2(1024)    ,
 NETWORK_WAIT_TIME                NUMBER(38),       
PRIMARY KEY(C_ID,C_BATCH_ID))
PARTITION BY RANGE(C_BATCH_ID)
(
PARTITION P10 VALUES LESS THAN (10),
PARTITION P20 VALUES LESS THAN (20),
PARTITION P30 VALUES LESS THAN (30),
PARTITION P40 VALUES LESS THAN (40),
PARTITION P50 VALUES LESS THAN (50),
PARTITION P60 VALUES LESS THAN (60),
PARTITION P70 VALUES LESS THAN (70),
PARTITION P80 VALUES LESS THAN (80),
PARTITION P90 VALUES LESS THAN (90),
PARTITION P100 VALUES LESS THAN (100),
PARTITION P110 VALUES LESS THAN (110),
PARTITION P120 VALUES LESS THAN (120),
PARTITION P130 VALUES LESS THAN (130),
PARTITION P140 VALUES LESS THAN (140),
PARTITION P150 VALUES LESS THAN (150),
PARTITION P160 VALUES LESS THAN (160),
PARTITION P170 VALUES LESS THAN (170),
PARTITION P180 VALUES LESS THAN (180),
PARTITION P190 VALUES LESS THAN (190),
PARTITION P200 VALUES LESS THAN (200)
);
sql 复制代码 
CREATE OR REPLACE PROCEDURE extract_sqlaudit_proc(
    P_NAME VARCHAR2,
    p_FLAG CHAR,
    P_START_TIME VARCHAR2, -- 开始时间
    p_END_TIME VARCHAR2 -- 结束时间
)
  /*
    extract_sqlaudit_proc
    作者：小至尖尖
    时间：2024-08-01
    用途：用于拉取gv$ob_sql_audit视图数据
  */
    IS
    V_NAME       VARCHAR2(100) := UPPER(P_NAME); -- 场景名称 
    V_FLAG       CHAR(2)       := UPPER(p_FLAG); -- s 为拉取单个事务，m 为拉取多个事务（压测），
    V_MAX_BATCH  INT;
    V_START_TIME VARCHAR2(100) := P_START_TIME; --开始时间
    V_END_TIME   VARCHAR2(100) := p_END_TIME; --结束时间
    /*
     V_NAME:场景名称
     V_FLAG:S为拉取单个事务，M为拉取多个事务（压测）
     V_MAX_BATCH:记录批次数
    */
    V_SQL        VARCHAR2(4000);
    V_FLAG_EXCEPTION EXCEPTION;
BEGIN

    IF V_FLAG != 'S' AND V_FLAG != 'M' THEN
        RAISE V_FLAG_EXCEPTION;
    END IF;


    -- 找到最大批次数加1
    SELECT NVL(MAX(C_BATCH_ID), 0) + 1 INTO V_MAX_BATCH FROM XZ_SQL_AUDIT;
    -- 将传进来的值转换成字符串时间戳格式。
    V_START_TIME := TO_CHAR(TO_TIMESTAMP(V_START_TIME, 'YYYY-MM-DD HH24:MI:SS:FF6'), 'YYYY-MM-DD HH24:MI:SS:FF6');
    V_END_TIME := TO_CHAR(TO_TIMESTAMP(V_END_TIME, 'YYYY-MM-DD HH24:MI:SS:FF6'), 'YYYY-MM-DD HH24:MI:SS:FF6');

    V_SQL := '
        insert /*+ ENABLE_PARALLEL_DML PARALLEL(100)*/ into XZ_SQL_AUDIT
        select (:1 * 10000000000)+i , scn_to_timestamp(x.request_time * 1000),:2,:3,:4,
        x.SVR_IP,
		x.SVR_PORT,
		x.REQUEST_ID,
		x.SQL_EXEC_ID,
		x.TRACE_ID,
		x.SID,
		x.CLIENT_IP,
		x.CLIENT_PORT,
		x.TENANT_ID,
		x.EFFECTIVE_TENANT_ID,
		x.TENANT_NAME,
		x.USER_ID,
		x.USER_NAME,
		x.USER_GROUP,
		x.USER_CLIENT_IP,
		x.DB_ID,
		x.DB_NAME,
		x.SQL_ID,
		x.QUERY_SQL,
		x.PLAN_ID,
		x.AFFECTED_ROWS,
		x.RETURN_ROWS,
		x.PARTITION_CNT,
		x.RET_CODE,
		x.QC_ID,
		x.DFO_ID,
		x.SQC_ID,
		x.WORKER_ID,
		x.EVENT,
		x.P1TEXT,
		x.P1,
		x.P2TEXT,
		x.P2,
		x.P3TEXT,
		x.P3,
		x.WAIT_CLASS_ID,
		x.WAIT_CLASS#,
		x.WAIT_CLASS,
		x.STATE,
		x.WAIT_TIME_MICRO,
		x.TOTAL_WAIT_TIME_MICRO,
		x.TOTAL_WAITS,
		x.RPC_COUNT,
		x.PLAN_TYPE,
		x.IS_INNER_SQL,
		x.IS_EXECUTOR_RPC,
		x.IS_HIT_PLAN,
		x.REQUEST_TIME,
		x.ELAPSED_TIME,
		x.NET_TIME,
		x.NET_WAIT_TIME,
		x.QUEUE_TIME,
		x.DECODE_TIME,
		x.GET_PLAN_TIME,
		x.EXECUTE_TIME,
		x.APPLICATION_WAIT_TIME,
		x.CONCURRENCY_WAIT_TIME,
		x.USER_IO_WAIT_TIME,
		x.SCHEDULE_TIME,
		x.ROW_CACHE_HIT,
		x.BLOOM_FILTER_CACHE_HIT,
		x.BLOCK_CACHE_HIT,
		x.DISK_READS,
		x.RETRY_CNT,
		x.TABLE_SCAN,
		x.CONSISTENCY_LEVEL,
		x.MEMSTORE_READ_ROW_COUNT,
		x.SSSTORE_READ_ROW_COUNT,
		x.DATA_BLOCK_READ_CNT,
		x.DATA_BLOCK_CACHE_HIT,
		x.INDEX_BLOCK_READ_CNT,
		x.INDEX_BLOCK_CACHE_HIT,
		x.BLOCKSCAN_BLOCK_CNT,
		x.BLOCKSCAN_ROW_CNT,
		x.PUSHDOWN_STORAGE_FILTER_ROW_CNT,
		x.REQUEST_MEMORY_USED,
		x.EXPECTED_WORKER_COUNT,
		x.USED_WORKER_COUNT,
		x.SCHED_INFO,
		x.PS_CLIENT_STMT_ID,
		x.PS_INNER_STMT_ID,
		x.TX_ID,
		x.SNAPSHOT_VERSION,
		x.REQUEST_TYPE,
		x.IS_BATCHED_MULTI_STMT,
		x.OB_TRACE_INFO,
		x.PLAN_HASH,
		x.PARAMS_VALUE,
		x.RULE_NAME,
		x.TX_INTERNAL_ROUTING,
		x.TX_STATE_VERSION,
		x.FLT_TRACE_ID,
		x.NETWORK_WAIT_TIME
         from(select /*+ PARALLEL(100) query_timeout(50000000000)  */
        rownum i, a.* from GV$OB_SQL_AUDIT a where
		query_sql not like ''%用来排除不需要的表名，例如压测期间其他微服务的发起的远程调度任务，提前跟业务方确认好，如果有多个则继续添加 and query_sql not like%''
	    and query_sql not like ''%table_name_1%''   -- 排除的表
	    and query_sql not like ''%table_name_2%''
	    and query_sql not like ''%table_name_3%''
	    and query_sql not like ''%table_name_4%''
	    and query_sql not like ''%table_name_5%''
		and query_sql not like ''%ob_sql_audit%''      -- 排除掉ob_sql_audit的查询sql
		and TENANT_NAME <> ''sys''
		and query_sql not like ''%extract_sqlaudit_proc%''    -- 排除掉extract_sqlaudit_proc的查询sql
		) x ';
    -- 添加过滤条件
    V_SQL := V_SQL || ' where to_char(scn_to_timestamp((request_time * 1000)),''YYYY-MM-DD hh24:mi:ss:ff6'') >=' || ''''
        || V_START_TIME || '''' || ' AND ' ||
             '  to_char(scn_to_timestamp((request_time * 1000)),''YYYY-MM-DD hh24:mi:ss:ff6'') <= '
        || '''' || V_END_TIME || '''' || ';';

    EXECUTE IMMEDIATE V_SQL USING V_MAX_BATCH,V_MAX_BATCH,V_NAME,V_FLAG;
    COMMIT;

    DBMS_OUTPUT.PUT_LINE(P_START_TIME || ' ~ ' || p_END_TIME || '时间段可以查询 XZ_SQL_AUDIT 表C_BATCH_ID：' ||
                         V_MAX_BATCH);

    /*
             -- 调试代码
     dbms_output.put_line(V_NAME);
     dbms_output.put_line(V_MAX_BATCH);
     dbms_output.put_line(V_START_TIME);
     dbms_output.put_line(V_END_TIME);
     dbms_output.put_line(V_SQL);
*/
EXCEPTION
    WHEN V_FLAG_EXCEPTION THEN
        DBMS_OUTPUT.PUT_LINE('p_FLAG参数传入的值错误，S：为拉取单个事务、M:为拉取多个事务（压测）');

END;
sql 复制代码 
begin 
yzj.extract_sqlaudit_proc(
    P_NAME => 'OB 4522场景：网银借款 200并发',	  			-- 压测场景名称
    p_FLAG => 'm',							   			 						  -- s 为拉取单个事务，m 为拉取多个事务（压测）
    P_START_TIME => '2024-08-10 18:00:00',     			  -- 压测开始时间
    p_END_TIME => '2024-08-10 18:59:00'        			  -- 压测结束时间
);
end ;
/

这张表为了迎合ob的特性而且还需要保存大量数据，我设计成分区表，c_batch_id 是这张表的核心字段。

每次执行extract_sqlaudit_proc后，c_batch_id 都会加1，存过自动执行，例如上面调用过程后，通过查询：select * from xz_sql_audit where c_batch_id = 1; ，可以将2024-08-10 18:00:00 ~ 2024-08-10 18:59:00 这段时间的所有数据查出来。呦西，是不是很方便呢。😁😁
温馨提示：如果在obclient黑屏执行，建议提前 set serveroutput on ; 选项打开，存过会提示这段时间的数据使用的c_batch_id是什么。

2、通过 xz_sql_audit 表分析案例一

sql执行期间一些重要的事件间隔如下：

sql 复制代码 
SELECT /*+ PARALLEL(80) */ 
	a.TX_ID									事务ID,	
	B.GG									SQL统计次数,
	round(a.ELAPSED_TIME) 最大总执行时间,			
	round(a.ELAPSED_TIME) 平均总执行时间,
	round(a.ELAPSED_TIME) 最小总执行时间,
	round(  max(a.net_time)			)		最大RPC接收到时间,
	round(  max(a.net_wait_time)	)  		最大请求接收的时间,
	round(  max(a.QUEUE_TIME)		)      	最大队列时间,
	round(  max(a.DECODE_TIME)		)     	最大出队列解析时间,
	round(  max(a.get_plan_time)	)   	最大获取计划时间,
	round(  max(a.execute_time)		)    	最大执行时间,
	round(  max(a.RETRY_CNT)		)		最大重试次数,
	round(  max(a.RPC_COUNT)		)		最大RPC次数,
	round(  avg(a.net_time)			)		平均RPC接收到时间,
	round(  avg(a.net_wait_time)	)  		平均请求接收的时间,
	round(  avg(a.QUEUE_TIME)		)      	平均队列时间,
	round(  avg(a.DECODE_TIME)		)     	平均出队列解析时间,
	round(  avg(a.get_plan_time)	)   	平均获取计划时间,
	round(  avg(a.execute_time)		)    	平均执行时间,
	round(  avg(a.RETRY_CNT)		)		平均重试次数,
	round(  avg(a.RPC_COUNT)		)		平均RPC次数,
	round(  min(a.net_time)			)		最小RPC接收到时间,
	round(  min(a.net_wait_time)	)  		最小请求接收的时间,
	round(  min(a.QUEUE_TIME)		)      	最小队列时间,
	round(  min(a.DECODE_TIME)		)     	最小出队列解析时间,
	round(  min(a.get_plan_time)	)   	最小获取计划时间,
	round(  min(a.execute_time)		)    	最小执行时间,
	round(  min(a.RETRY_CNT)		)		最小重试次数,
	round(  min(a.RPC_COUNT)		)		最小RPC次数
FROM XZ_SQL_AUDIT a inner join 
	(SELECT COUNT(to_char(substr(query_sql,1,2000))) gg, 
			   C_BATCH_ID, 
			   TX_ID 
		FROM XZ_SQL_AUDIT GROUP BY C_BATCH_ID,TX_ID ) b 
	ON  a.TX_ID = b.TX_ID and a.C_BATCH_ID = b.C_BATCH_ID 
WHERE a.C_BATCH_ID = 2				-- 改成相应的c_batch_id
GROUP BY a.TX_ID,B.GG ORDER BY 3 DESC;

该SQL能够分析出服务端不同事物内sql的运行链路，看看top sql到底在哪个哪个环节上耗时高，是队列、网络、获取计划步骤，还是执行的阶段慢，具体问题具体分析。
sql内所有字段通过上图从左到右进行执行顺序来进行分析，方便项目人员能立马定位到耗时的步骤。

3、通过 xz_sql_audit 表分析案例二

压测期间遇到个怪问题，QPS每隔个2分钟会发生低谷现象，TPS响应时间会在同一时刻发生突刺现象。



可以通过以下SQL，来定位QPS、TPS低谷期间的范围前后15秒左右的SQL访问流量。

sql 复制代码 
select  /*+ PARALLEL(62) */ 
   to_char(a.c_rq_time,'YYYY-MM-DD HH24:MI:SS') c_date,
		case when a.plan_type = 0 then '内部计划' when a.plan_type = 1 then '本地计划'  when a.plan_type = 2 then '远程计划'  when a.plan_type = 3 then '分布式计划' else null end plan_type,
		count(1) cnt
		from XZ_SQL_AUDIT a
    where a.C_BATCH_ID=2  and c_rq_time between to_timestamp('2024-08-06 19:22:00','YYYY-MM-DD HH24:MI:SS') and to_timestamp('2024-08-06 19:22:15','YYYY-MM-DD HH24:MI:SS')
group by to_char(a.c_rq_time,'YYYY-MM-DD HH24:MI:SS'),a.plan_type
order by 2,1

可以看到，19:22:00 这个时间段sql还是有54008的访问量，但是下一秒直接掉到14028的访问量。

但是这个案例最后石锤的是，在同网段的机器上使用benchmarkSQL压测一点问题都没，但是在跨网段的应用的压测机器上发起benchmarkSQL压测，完美复现这个现象。

所以有可能是跨网段，或者网络不稳定等一些的因素造成的QPS波谷，TPS响应尖刺的问题，其实目前还未排除清楚，只是往网络方向排查。

但是上面的分析sql流量的方法也能起到一定的佐证的效果，遇到一个问题要多维度层面和手段来排除，最后确定最终根源。

4、通过 xz_sql_audit 表分析案例三

客户核心系统是JAVA开发的微服务架构，应用机器就有8台，后面还有上百台虚拟机在运行各种辅助的服务。

应用层面的事务管理方式是采用TCC分布式事务模型，采用事务补偿的机制（应用层提供回滚方案，不需要数据库进行回滚）。

这种分布式事务模型优缺点如下：

  • 优点：
    • 业务层逻辑的实现往往只需要写简单的点查SQL，不需要写复杂的SQL。
  • 缺点：
    • 事务量巨大，一个事务里面包含非常多点查SQL。
    • 回滚逻辑是应用提供，如果期间发生TCP断链，可能会导致数据不一致。
    • 业务逻辑非常复杂，很考验开发人员对业务的理解能力。

像TCC这种分布式事务模型，如果跑在集中式数据库下，性能杠杠的。😁😁😁

由于事务量多，在原有的gv$ob_sql_audit视图下，很难分析出单个交易场景里面的SQL是由哪些组成，在不清楚业务接口的单交易的模型情况下，更不用说如何来优化这个接口。

我这边是这样跟业务人员沟通的：

  1. 让业务开发人员发起某个场景下的单笔交易的任务。
  2. 让业务人员提供交易开始时间和结束时间，最好精确到微秒，实在不行精确到毫秒也行。
  3. 然后我使用extract_sqlaudit_proc存过来收集对应的时间点，例如业务开发发起的交易任务，开始时间和结束时间为：2024-08-10 20:01:01.123 ~ 2024-08-10 20:01:01.500 (一笔交易毫秒级别)，那我可以对开始时间和结束时间分别加1秒来扩大收集在这个时间段的所有SQL。
sql 复制代码 
begin 
yzj.extract_sqlaudit_proc(
    P_NAME => 'OB 4522场景：网银借款 单笔交易',	  				-- 压测场景名称
    p_FLAG => 's',							   			 							   -- s 为拉取单个事务，m 为拉取多个事务（压测）
    P_START_TIME => '2024-08-10 20:01:00.123',     			 -- 交易开始时间
    p_END_TIME => '2024-08-10 20:01:02.123'        			 -- 交易结束时间
);
end ;
/
  1. 然后我使用extract_sqlaudit_proc存过来收集对应的时间点，例如业务开发发起的交易任务，开始时间和结束时间为：2024-08-10 20:01:01.123 ~ 2024-08-10 20:01:01.500 (一笔交易毫秒级别)，那我可以对开始时间和结束时间分别加1秒来扩大收集在这个时间段的所有SQL。
  2. 还需要跟业务开发确定好这笔交易开始执行的表的SQL语句和事务结束执行的表的SQL语句，或者是SQL都行，最好是有标志性能确定是属于这个交易里面的操作。
  3. 最后使用以下SQL来分析单笔交易的所有事务的数量和不同事务包含的SQL语句。
sql 复制代码 
SELECT *
FROM (SELECT TO_CHAR(b.trans_start_time, 'YYYY-MM-DD HH24:MI:SS.FF6')      单笔事务开始时间,
             TO_CHAR(b.trans_end_time, 'YYYY-MM-DD HH24:MI:SS.FF6')        单笔事务结束时间,
             ROW_NUMBER() OVER (PARTITION BY a.tx_id ORDER BY a.c_rq_time) sql事务内执行顺序,
             a.tx_id                                                       事务ID,
             TO_CHAR(a.c_rq_time, 'YYYY-MM-DD HH24:MI:SS.FF6')             sql请求执行时间,
             TO_CHAR(SUBSTR(a.query_sql, 1, 2000))                         sql语句,
             a.net_time                                                    RPC接收到时间,
             a.net_wait_time                                               请求接收的时间,
             a.QUEUE_TIME                                                  队列时间,
             a.DECODE_TIME                                                 出队列解析时间,
             a.get_plan_time                                               获取计划时间,
             a.execute_time                                                执行时间,
             a.RETRY_CNT                                                   重试次数,
             a.RPC_COUNT                                                   RPC次数,
             a.ELAPSED_TIME                                                总执行时间
      FROM xz_sql_audit a
               INNER JOIN (SELECT MIN(c_rq_time) trans_start_time,
                                  MAX(c_rq_time) trans_end_time
                           FROM xz_sql_audit
                           WHERE c_batch_id = 6                -- c_batch_id 自己环境去看，记得要改
                             AND (
                                       query_sql LIKE '%insert%in_log%'   -- 交易开始的SQL语句操作
                                   OR query_sql LIKE '%update%in_log%')	  -- 交易结束的SQL语句操作
                          ) b
                          ON a.c_rq_time >= b.trans_start_time AND a.c_rq_time <= b.trans_end_time AND a.c_batch_id = 6)

5、结束语

extract_sqlaudit_proc 过程起到的帮助是将gvob_sql_audit数据拉到xz_sql_audit表里面，但是如何分析出对项目人员有效的数据，还是取决于你对gvob_sql_audit表的理解还有个人的SQL能力。

SQL能力过关的情况下，才能写出不同场景所需要的数据的分析SQL，而不是只局限于一两个场景下的分析。

还有一点，你要写啥SQL分析，就对xz_sql_audit加相应的索引即可，能加速sql的分析效率，机器资源够的情况下，分析sql多加点并发，比gv$ob_sql_audit快多了，极大提高了工作效率。

我现在还在搞obproxy的日志分析脚本，将xz_sql_audit表数据的开始结束时间传入个脚本，来将obproxy的日志形成结构化数据导入到obproxy_audit表，后面可以写sql来分析一笔业务交易，server层和proxy层的消耗分别使用的多少时间。🤞🤞🤞

相关推荐
lzhlizihang1 小时前
【Hive sql 面试题】求出各类型专利top 10申请人，以及对应的专利申请数（难）
大数据·hive·sql·面试题
威哥爱编程2 小时前
SQL Server 数据太多如何优化
数据库·sql·sqlserver
Mephisto.java3 小时前
【大数据学习 | kafka高级部分】kafka的kraft集群
大数据·sql·oracle·kafka·json·hbase
Mephisto.java3 小时前
【大数据学习 | kafka高级部分】kafka的文件存储原理
大数据·sql·oracle·kafka·json
数新网络7 小时前
《深入浅出Apache Spark》系列②：Spark SQL原理精髓全解析
大数据·sql·spark
师太，答应老衲吧9 小时前
SQL实战训练之，力扣：2020. 无流量的帐户数（递归）
数据库·sql·leetcode
NiNg_1_23412 小时前
高级 SQL 技巧详解
sql
OceanBase数据库官方博客19 小时前
在OceanBase 中，实现自增列的4种方法
oceanbase·分布式数据库·运维管理
全栈开发圈19 小时前
新书速览|Spark SQL大数据分析快速上手
sql·数据分析·spark
WeeJot嵌入式19 小时前
数据库----SQL
数据库·sql
热门推荐
01【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总02(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明03组基轨迹建模 GBTM的介绍与实现（Stata 或 R）04【AIGC】重塑未来的科技巨轮05全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）06【经验分享】Ubuntu22.04安装微信(linux官方版)07基于YOLOv10深度学习的CT扫描图像肾结石智能检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测08Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO09RAG 实践- Ollama+RagFlow 部署本地知识库10红米手机使用google play