首页 星云 工具 资源 星选 资讯 热门工具
:

PDF转图片 完全免费 小红书视频下载 无水印 抖音视频下载 无水印 数字星空

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

编程知识
2024年08月10日 19:39

最近在某个金融单位核心系统项目做ob的性能压测，期间遇到不少问题，现场两周了每天都加班到凌晨一两点左右，真的是累死。🤢🤢
我其实进ob之前有心理预期，卷就卷吧，八九点下班也能接受，没想到真到了干项目的情况下，天天凌晨下班，真怕不知道啥时候会猝死。😂😂
ob被挺多人诟病的是gv$ob_sql_audit视图，如果有大量的事物在数据库里面执行，这个视图保存的内容很快就会被刷掉，而且做查询分析速度非常慢，随便一条加个谓词过滤的语句估计都要执行个几分钟才能出结果，很难分析出业务接口到底是哪个事物的SQL缓慢。
虽然可以通过ob_sql_audit_percentage参数调大gv$ob_sql_audit视图保存的内容，但是如果连续的高并发压测情况下，一样也会把里面的内容很快刷新，所以我们需要将gv$ob_sql_audit数据持久化到数据表里面，添加合适的索引用来分析server层不同场景业务接口的sql语句，到底慢在哪个环节，来进行针对性的调优。
所以我到了现场了解情况以后，花半天时间编写和调试extract_sqlaudit_proc这个存储过程来帮我抓server层的数据，这个过程后续帮我分析不同场景的性能问题省了很多功夫。

1、xz_sql_audit表、extract_sqlaudit_proc 过程代码

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

-- 创建分析表
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)
);

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;

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 ;
/

image.png
这张表为了迎合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执行期间一些重要的事件间隔如下：

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响应时间会在同一时刻发生突刺现象。
qps低谷.png
tps低谷.png
tps响应突刺.png
可以通过以下SQL，来定位QPS、TPS低谷期间的范围前后15秒左右的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

image.png
可以看到，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。
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语句。
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)

image.png

5、结束语

extract_sqlaudit_proc 过程起到的帮助是将gv$ob_sql_audit数据拉到xz_sql_audit表里面，但是如何分析出对项目人员有效的数据，还是取决于你对gv$ob_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层的消耗分别使用的多少时间。🤞🤞🤞

From:https://www.cnblogs.com/yuzhijian/p/18352759
本文地址: http://shuzixingkong.net/article/972
0评论
提交 加载更多评论
其他文章 [rCore学习笔记 024]多道程序与协作式调度
写在前面 本随笔是非常菜的菜鸡写的。如有问题请及时提出。 可以联系：1160712160@qq.com GitHhub：https://github.com/WindDevil （目前啥也没有 本节重点 主要是对&#160;任务&#160;的概念进行进一步扩展和延伸：形成 任务运行状态：任务从开始到
[rCore学习笔记 024]多道程序与协作式调度 [rCore学习笔记 024]多道程序与协作式调度 [rCore学习笔记 024]多道程序与协作式调度
Java IO 流详解
概述 流是一个抽象的概念，代表了数据的无结构化传递。流的本质是数据在不同设备之间的传输。在 Java 中，数据的读取和写入都是以流的方式进行的 在 Java 中，根据数据流向的不同，可以将流分为输入（Input）流和输出（Output）流。根据单位的不同，可以将流分为字节流和字符流。根据等级的不同，
 # games101 作业3分析 详解bump mapping
games101 作业3分析 详解bump mapping 代码分析 整体代码结构 其实变化还是不大 主要是引入了vertexshader（什么都没做） 与 fragmentshader（使用了不同的着色方法 直接用法线作为rgb 使用blingphong光照模型 纹理贴图 bumpmapping
# games101 作业3分析 详解bump mapping # games101 作业3分析 详解bump mapping # games101 作业3分析 详解bump mapping
巨简单！弄懂递归的原理-带括号加法题而已
“递归”第5行代码这里你把它想成带括号的数学题，有括号先算括号内，直到没有括号，括号内的运算后的值在再与括号外的值运算
巨简单！弄懂递归的原理-带括号加法题而已 巨简单！弄懂递归的原理-带括号加法题而已
代码随想录Day11
150. 逆波兰表达式求值 给你一个字符串数组 tokens ，表示一个根据 逆波兰表示法 表示的算术表达式。 请你计算该表达式。返回一个表示表达式值的整数。 注意： 有效的算符为 &#39;+&#39;、&#39;-&#39;、&#39;*&#39; 和 &#39;/&#39; 。 每个操作数（运
代码随想录Day11 代码随想录Day11
[考试记录] 2024.8.10 csp-s 模拟赛18
80 + 20 + 0 + 70 = 170 第三题应该有 10 分暴力的，但我没打。 T1 星际旅行 题面翻译 总共有n个节点，m条路径，要求其中m-2条路径走两遍，剩下2条路径仅走一遍，问不同的路径总数有多少，如果仅走一遍的两条边不同则将这两条路径视为不同。 样例 #1 样例输入 #1 5 4
[考试记录] 2024.8.10 csp-s 模拟赛18 [考试记录] 2024.8.10 csp-s 模拟赛18
朋友吐槽我为什么这么傻不在源生成器中用string.GetHashCode, 而要用一个不够优化的hash方法
明明有更好的hash方法 有位朋友对我吐槽前几天我列举的在源生成器的生成db映射实体的优化点 提前生成部分 hashcode 进行比较 所示代码 public static void GenerateReadTokens(this IDataReader reader, Span&lt;int&gt
 Turbo Sparse:关于LLM稀疏性的探索
本文地址：https://www.cnblogs.com/wanger-sjtu/p/18352898 关于llama稀疏性的观察 llama原始模型的FFN计算过程为： \[f(x) = \text{silu}(xW_{Gate}) \odot xW_{UP} \times W_{Down} \]
Turbo Sparse:关于LLM稀疏性的探索 Turbo Sparse:关于LLM稀疏性的探索 Turbo Sparse:关于LLM稀疏性的探索
本站由星云主机提供云计算服务

网站建设一条龙服务、小程序开发、企业网站建设、定制开发，网络安全检测与维护 业务合作联系QQ:九六九五七三七