v$session,v$session_wait,v$session_wait_history,v$active_session_history

1、v$session:连接将产生会话,当前会话的信息保存在v$session中,连接断开后消失

2、v$session_wait:将当前会话中正在等待的会话状态复制一份到视图,断开后消失(等待会话生命周期最后1次等待,一个session对应一条记录);

3、v$session_wait_history:保存每个活动session在v$session_wait中最近10次的等待事件(等待会话生命周期最后10次等待);

4、ASH(v$active_session_history):在内存中保存,每秒从v$session_wait中采样一次(等待会话每秒的快照)

5、AWR:ASH数据每小时将数据采样写入存到磁盘中AWR(dba_hist..),默认保留7天,每小时一次

6. v$session_event: v$session_wait记录的是活动session当前正在等待的资源信息,是实时信息的记录,v$session_wait的实时等待结束之后才能被记入v$session_event. 表示"现在","曾经"。

7. v$system_event提供的是自实例启动以来所有等待时间的总和,包括等待的总次数,总超时,是所有会话的在所有等待事件上的汇总。

8. v$event_name: 数据库字典, 查询等待事件的参数说明:

select * from v$event_name where name = 'db file scattered read';

9. v$sys_time_model 数据库系统整体在基于time的标准上整体的运行状况.

10. v$sess_time_model 查询视图来获得具体的session等待信息.

 

[当前状态]v$session / v$session+v$session_wait

[最近状态]v$session_wait_history

[启动至今]v$session_event

 

从10g开始v$session包含了v$session_wait的所有字段,所以对于当前状态,10g以后可以直接查看v$session,而10g之前可通过v$session和v$session_wait关联达到同样的效果。

 

v$session_wait_history 记录了每个active session的最近10次的等待事件。如果查询某个session的等待事件频繁发生,则反映在v$session_wait_history的最近10条记录上则几乎是同一个等待事件。

 

v$session_event 则记录了实例启动至今所有等待事件的等待次数、等待时间等的统计信息。可以根据等待次数或者等待时间进行排序,类似AWR report或者Statspack中的TOP 5 Waits,就可以大致反映出常态下数据库主要在等待哪些操作的完成,从而给数据库的进一步优化提供方向。

 
<think>好的,我需要帮助用户了解如何根据V$ARCHIVED_LOG视图来定位产生大量归档日志的SQL语句。首先,我应该回忆一下Oracle数据库的相关知识,尤其是关于归档日志和性能调优的部分。 用户提到使用V$ARCHIVED_LOG,这个视图主要存储了归档日志的信息,比如日志序列号、归档时间、文件路径等。但直接从这个视图可能无法直接定位到具体的SQL,因为归档日志的大小通常与数据库的事务量、redo生成量有关,而redo又由DML操作产生。所以,可能需要通过其他关联视图来追踪问题。 接下来,应该考虑如何将归档日志的高生成量与具体的SQL语句联系起来。可能的步骤包括: 1. **确定高归档日志生成的时间段**:查看V$ARCHIVED_LOG中的FIRST_TIME和NEXT_TIME,找出归档日志量突增的时间段。 2. **关联到会话和SQL**:在问题时间段内,数据库的活动会话可能执行了大量生成redo的DML操作。需要查询如V$SESSION、V$SQL等动态性能视图,找出在此期间消耗大量redo的SQL。 不过,V$ARCHIVED_LOG本身可能不直接提供这些信息,所以需要结合其他视图。例如: - **V$SQL**:查看SQL语句的执行次数、磁盘读取、缓冲区获取等统计信息。 - **V$SQLSTATS** 或 **DBA_HIST_SQLSTAT**(如果启用了AWR):提供历史SQL性能数据。 - **V$ACTIVE_SESSION_HISTORY (ASH)**:可以分析活动会话的历史数据,找出高负载的SQL。 - **AWR报告**:生成指定时间段的AWR报告,分析redo size排名靠前的SQL。 另外,高redo生成的常见原因包括大批量的DML操作(如INSERT、UPDATE、DELETE)、索引维护、LOB操作等。需要指导用户如何通过查询这些视图来识别问题SQL。 可能需要分步骤说明: 1. 首先确认归档日志增长的时间点。 2. 使用AWR报告或ASH分析该时段的TOP SQL。 3. 检查这些SQL的redo生成量,可以通过V$SQL的REDO_SIZE字段,但需要注意这可能不是所有情况都适用,因为V$SQL中的统计是累计值。 4. 可能需要结合时间范围,查找在特定时间段内执行次数多或单次执行产生大量redo的SQL。 还需要注意权限问题,用户可能需要访问这些动态视图的权限,如SELECT_CATALOG_ROLE或特定的权限。 可能还需要提到使用LogMiner工具来分析归档日志,直接解析日志内容找出对应的SQL,但这种方法比较复杂,适合详细分析。 总结步骤大致为: 1. 确定问题时间段。 2. 使用AWR/ASH找出该时段的高负载SQL。 3. 分析这些SQL的执行计划和资源消耗,特别是redo大小。 4. 优化相关SQL以减少redo生成。 可能需要检查是否有长时间运行的事务未提交,导致redo无法释放,或者批量操作没有分批提交,导致redo激增。 在回答时,要确保步骤清晰,可能涉及的具体SQL查询示例,例如查询V$SQL中按redo_size排序的语句,或者生成AWR报告的方法。</think>根据Oracle数据库特性,通过归档日志定位高负载SQL的步骤如下: $$red\_size = \sum_{i=1}^{n}(redo\_generated\_by\_sql_i)$$ **步骤1:确定高负载时间段** ```sql SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME, BLOCKS*BLOCK_SIZE/1024/1024 MB FROM V$ARCHIVED_LOG ORDER BY FIRST_TIME DESC; ``` 通过该查询找出归档日志量突增的具体时间段(关注MB列异常值) **步骤2:关联AWR分析SQL** ```shell # 生成AWR报告 exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); @?/rdbms/admin/awrrpt.sql ``` 在报告「SQL ordered by Executions」和「SQL ordered by Elapsed Time」部分查找可疑SQL **步骤3:实时监控活跃SQL** ```sql SELECT sql_id, executions, elapsed_time/1e6 "Elapsed(s)", disk_reads, buffer_gets, rows_processed, regexp_replace(sql_text, '[[:space:]]+',' ') sql_text FROM v$sqlstats WHERE last_active_time BETWEEN :start AND :end ORDER BY elapsed_time DESC; ``` **步骤4:深度分析SQL特征** ```sql SELECT sql_id, SUM(redo_size)/1024/1024 "Redo(MB)", COUNT(*) execs, ROUND(SUM(redo_size)/COUNT(*)/1024) "KB/exec" FROM DBA_HIST_SQLSTAT WHERE snap_id BETWEEN &begin_snap AND &end_snap GROUP BY sql_id HAVING SUM(redo_size)/1024/1024 > 100 -- 筛选生成超过100MB redo的SQL ORDER BY 2 DESC; ``` **优化建议**: 1. 对于批量DML操作,使用`NOLOGGING`模式(需权衡数据可恢复性) 2. 拆分大事务为小批次提交,例如: ```sql BEGIN FOR i IN 1..100000 LOOP INSERT /*+ APPEND */ INTO tab VALUES(...); IF MOD(i,1000)=0 THEN COMMIT WRITE BATCH NOWAIT; END IF; END LOOP; COMMIT; END; ``` 3. 检查索引设计是否合理,过多索引会加大DML的redo生成量 **附加工具**: - 使用LogMiner解析归档日志(需要开启补充日志): ```sql EXEC DBMS_LOGMNR.ADD_LOGFILE('/archive/ARC0001_123456.001', OPTIONS => DBMS_LOGMNR.NEW); EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG); SELECT sql_redo FROM V$LOGMNR_CONTENTS WHERE seg_owner = '问题表所属用户'; ``` **注意**:高日志生成往往伴随以下特征SQL: - 高频执行的UPDATE语句(特别是更新大字段) - 未带WHERE条件的全表更新 - 使用CLOB/BLOB字段的DML操作 - 分区表维护操作(ALTER TABLE...TRUNCATE PARTITION)
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值