作者 | JiekeXu

来源 |公众号 JiekeXu DBA之路（ID: JiekeXu_IT）

如需转载请联系授权 | (个人微信 ID：JiekeXu_DBA)

大家好，我是 JiekeXu,很高兴又和大家见面了,今天和大家一起来看看 Oracle 故障处理|V$ACTIVE_SESSION_HISTORY 视图没有数据?，欢迎点击上方蓝字“JiekeXu DBA之路”关注我的公众号，标星或置顶，更多干货第一时间到达！

事情是这样的，一套 Linux 平台四节点的 Oracle 11g RAC 环境通过搭建 ADG 环境，然后在目标端的 19c RAC 的节点一通过 DBUA 的方式升级到 19c,由于做过预升级演练操作，整个升级过程算是比较顺利，很成功的就完成了升级到 19c 的操作，同平台 Linux 两节点 RAC，RU 补丁是 19.15，接着就是按照 19c 参数实践修改参数，GI 添加集群资源和数据库，均是很流畅的完成了所有操作，但是后面发现收集 ASH 报告时没有数据。

从 Oracle 10g 开始引入，ASH（Active Session History）以 v$session 为基础，每秒钟采样一次，记录活动会话等待的事件。ASH 记录的信息也可以通过 v$active_session_history 视图来访问，而 dba_hist_active_sess_history 是 v$active_session_history 的持久化视图，他通过 mmon 进程将 v$active_session_history 中的信息每十秒采集一次到 awr snapshot 中。可以参考下图来理解 ASH。

可是查询 v$ACTIVE_SESSION_HISTORY 视图没有数据，视图 DBA_HIST_ACTIVE_SESS_HISTORY 的数据也不会变，一直都是 99 条，说明没有数据进入。这就有点恐怖了，难道是升级出现了问题吗？赶紧回忆整个升级过程及相关步骤，又 check 了一次没有问题，难道是配置上的问题吗？配置这一块也是没有问题的，演练环境和生产环境都是一样的问题，ASH 相关视图没有数据，这就需要进一步去排查了。

SQL*Plus: Release 19.0.0.0.0 - Production on Thu Mar 9 17:06:15 2023
Version 19.15.0.0.0


Copyright (c) 1982, 2022, Oracle.  All rights reserved.


Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.15.0.0.0


17:06:16 SQL> select count(*) from v$ACTIVE_SESSION_HISTORY;


  COUNT(*)
----------
         0
17:06:38 SQL> select count(*) from DBA_HIST_ACTIVE_SESS_HISTORY;


  COUNT(*)
----------
        99
17:08:38 SQL> select count(*) from DBA_HIST_ACTIVE_SESS_HISTORY;


  COUNT(*)
----------
        99
17:10:45 SQL> select count(*) from AWR_PDB_ACTIVE_SESS_HISTORY;


  COUNT(*)
----------
        99
17:11:51 SQL> select count(*) from v$ACTIVE_SESSION_HISTORY;


  COUNT(*)
----------
         0
17:11:59 SQL> select count(*) from v$ACTIVE_SESSION_HISTORY;


  COUNT(*)
----------
         0
17:12:39 SQL> select owner,view_name from dba_views where view_name like '%ACTIVE%';

后面又检查了最佳实践参数，发现和 ASH 相关的一个隐含参数 _ash_size 做了修改，默认此参数为 1048618 也就是 1M 大小，但是出问题的这个环境却是 512M，这个是根据参数文件最佳实践修改后的值，这个参数是指 ash buffer 的大小，如果 ash buffer 满了，则会强制刷新到 ASH 表，如果数据库负载较高的话，默认的 ash buffer 可能不够进而导致大量的强制刷新，最终可能导致数据库出现性能问题，所以我们需要调整一下这个参数大小。活动会话历史记录(ASH)如果执行了紧急刷新，比较频繁，这可能意味着 ASH 规模过小。如果经常出现紧急刷的问题，可以考虑通过将 _ASH_SIZE 的值设置为足够大的值来增加 ASH 大小。可以通过运行以下查询来监视 ASH 大小和自实例启动以来的紧急刷新总数:

19:22:14 SYS@test> select total_size,awr_flush_emergency_count from v$ash_info;


TOTAL_SIZE AWR_FLUSH_EMERGENCY_COUNT
---------- -------------------------
  33554432                         0


19:23:57 SYS@test> show parameter ash_size
19:24:06 SYS@test> set line 345 
19:24:51 SYS@test> col NAME for a45
19:24:51 SYS@test> col VALUE for a20
19:24:51 SYS@test> col DESCRIPTION for a60
19:24:51 SYS@test> select a.ksppinm name, b.ksppstvl value,a.ksppdesc description from x$ksppi a, x$ksppcv b 
19:24:51   2  where a.indx = b.indx and a.ksppinm = '&name';
Enter value for name: _ash_size
old   2: where a.indx = b.indx and a.ksppinm = '&name'
new   2: where a.indx = b.indx and a.ksppinm = '_ash_size'


NAME                                          VALUE                DESCRIPTION
--------------------------------------------- -------------------- ------------------------------------------------------------
_ash_size                                     1048618              To set the size of the in-memory Active Session History buff
                                                                   ers
19:24:57 SYS@test> select 1048618/1024/1024 MB from dual;


        MB
----------
1.00004005


==============出问题的这个环境是 512M ==============
19:25:36 SQL> set line 345 
19:25:37 SQL> col NAME for a45
19:25:37 SQL> col VALUE for a20
19:25:37 SQL> col DESCRIPTION for a60
19:25:37 SQL> select a.ksppinm name, b.ksppstvl value,a.ksppdesc description from x$ksppi a, x$ksppcv b 
19:25:37   2  where a.indx = b.indx and a.ksppinm = '&name';
Enter value for name: _ash_size
old   2: where a.indx = b.indx and a.ksppinm = '&name'
new   2: where a.indx = b.indx and a.ksppinm = '_ash_size'


NAME                                          VALUE                DESCRIPTION
--------------------------------------------- -------------------- ------------------------------------------------------------
_ash_size                                     536870912            To set the size of the in-memory Active Session History buffers
                                                                 
Elapsed: 00:00:00.00
19:25:50 SQL> show parameter _ash_size


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_ash_size                            big integer 512M
19:26:14 SQL> select 536870912/1024/1024 MB from dual;


        MB
----------
       512

所以当时升级后调整参数的时候想的是内存比较大，将这个值调整到了 512M，可是导致了 v$ACTIVE_SESSION_HISTORY 视图没有数据，最后查询 MOS 时，有篇文章介绍到“No Data in V$ACTIVE_SESSION_HISTORY When Size is _ASH_SIZE=1G (Doc ID 2268127.1)” _ASH_SIZE 设置为 1G 太大导致没有数据，而且由于未公开的 BUG 20185439 ，这个值不能超过 256M 的大小。

This is due to following bug that was closed as not a bug:


This is an underscore parameter for a good reason.
It does not work above a certain number - do not use more than 256M.
Theoretically it is dynamic (responds to ALTER SYSTEM), but there are issues
with that as well.


Bug 20185439 - NO DATA IN V$ACTIVE_SESSION_HISTORY WHEN _ASH_SIZE=1G

注意：
您可以提交一个更高的值，但内部调整为254Mb。一旦达到254，你尝试设置更高的大小，错误ORA-2097将被转储.
You can submit a higher value but internally it is adjusted to 254Mb. Once 254 has been reached, and you try to set higher size, error
ORA-2097 will be dumped:
1. alter system set "_ash_size"=100m; verified it was set to 100 MB
2. alter system set "_ash_size"=300m; verified it was set to 250 MB
3. alter system set "_ash_size"=400m;
ORA-2097: parameter cannot be modified because specified value is invalid


select total_size from v$ash_info;

按照 MOS 修改这个值为 254M 大小，且可以在线修改，但是好像没有生效，那就在测试环境先重启一下，再观察观察。当重启完成后，查看视图就已经有数据了，只不过重启之前的数据还是没有捕获到，这个就没办法了，只能这样了。

19:45:19 SQL> alter system set "_ash_size"=254M;


System altered.


19:45:42 SQL> select NUM_CHUNKS, TOTAL_SIZE, FIXED_SIZE, FLAGS from X$KEWAM;


NUM_CHUNKS TOTAL_SIZE FIXED_SIZE      FLAGS
---------- ---------- ---------- ----------
       127  266338304  266338304        145


19:45:53 SQL>  show parameter _ash_size


NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
_ash_size                            big integer 254M
19:46:05 SQL> select count(*) from AWR_PDB_ACTIVE_SESS_HISTORY;


19:54:15 SQL> select count(*) from v$ACTIVE_SESSION_HISTORY;


  COUNT(*)
----------
         0
19:54:21 SQL> 
19:58:25 SQL> shu immediate 
Database closed.
Database dismounted.
ORACLE instance shut down.


19:59:03 SQL> startup
ORACLE instance started.


Total System Global Area 1.6106E+10 bytes
Fixed Size                 13864464 bytes
Variable Size            3892314112 bytes
Database Buffers         1.2080E+10 bytes
Redo Buffers              120352768 bytes
Database mounted.
Database opened.
19:59:35 SQL> select count(*) from v$ACTIVE_SESSION_HISTORY;


  COUNT(*)
----------
       105
20:02:17 SQL> select count(*) from v$ACTIVE_SESSION_HISTORY;


  COUNT(*)
----------
       107
20:03:42 SQL> select NUM_CHUNKS, TOTAL_SIZE, FIXED_SIZE, FLAGS from X$KEWAM;


NUM_CHUNKS TOTAL_SIZE FIXED_SIZE      FLAGS
---------- ---------- ---------- ----------
       127  266338304  266338304         16

到这里，这个问题也就算解决了，对于生产环境我们要有敬畏之心，修改每个参数需要知道他的大概含义，这样才能够有效快速的诊断问题，就比如 _ash_size 这个参数默认值太小，有性能问题，修改调整过大又会出现 BUG 20185439 导致性能视图没有数据，那么今天就这样吧，小伙伴们再见啦。

全文完，希望可以帮到正在阅读的你，如果觉得此文对你有帮助，可以分享给你身边的朋友，同事，你关心谁就分享给谁，一起学习共同进步~~~

欢迎关注我的公众号【JiekeXu DBA之路】，第一时间一起学习新知识！

————————————————————————————
公众号：JiekeXu DBA之路
CSDN ：https://blog.csdn.net/JiekeXu
墨天轮：https://www.modb.pro/u/4347
腾讯云：https://cloud.tencent.com/developer/user/5645107
————————————————————————————

Oracle 表碎片检查及整理方案

OGG|Oracle GoldenGate 基础

2022 年公众号历史文章合集整理

2021 年公众号历史文章合集整理

2020 年公众号历史文章合集整理

Oracle 19c RAC 遇到的几个问题

OGG|Oracle 数据迁移后比对一致性

Oracle 故障处理|V$ACTIVE_SESSION_HISTORY 视图没有数据?

Oracle 表碎片检查及整理方案

OGG|Oracle GoldenGate 基础

2022 年公众号历史文章合集整理

2021 年公众号历史文章合集整理

2020 年公众号历史文章合集整理

Oracle 19c RAC 遇到的几个问题

利用 OGG 迁移 Oracle11g 到 19C

OGG|Oracle GoldenGate 微服务架构

Oracle 查询表空间使用率超慢问题一则

国产数据库|TiDB 5.4 单机快速安装初体验

Oracle ADG 备库停启维护流程及增量恢复

猜你喜欢