库缓存锁的常见原因有哪些？

分类：编程技术时间：2024-02-20 15:59 浏览：0 评论：0

库缓存锁的常见原因有哪些？相信很多没有经验的人对于解决这个问题都束手无策。本文总结了问题的原因和解决方案。通过这篇文章，希望你能解决这个问题。

库缓存锁定的常见原因

库缓存故障排除：锁定、固定和加载锁定（文档 ID 444560.1）

一般可以理解，alter table或者 alter package/procedure 会在 X 模式下持有库缓存锁，从而导致阻塞。
但常见问题也有以下原因：

1）用户名密码错误：

一般需要通过ASH或SSD/hang分析获取p3 执行名称空间分析。

1.事件：'库缓存锁定'
等待时间：43分12秒
等待ID：9 p1：'句柄地址'=0 x7000003117dfca0
                                  bsp ; p2: '锁定地址'=0x700000310866c80
                                   p3: '100*mode+namespace'= 0x4f0003
                * 等待 #1 和 #2 之间的时间：0.000164 秒

< ================= p3: '100*mode+namespace'=0x4f0003

mode=3
namespace=4f

十六进制：4f =>十进制：79
< br/>select * FROM V$DB_OBJECT_CACHE;

SQL> 从 x$kglob 中选择不同的 KGLHDNSP,KGLHDNSD;

KGLHDNSP KGLHDNSD
----- -------------------------------------------------- -------------------------------------------------- -------------------------------------------------- -------- />         1 表/过程
         3 触发器
        52 调度程序最早开始时间
        64 版本
        69 DBLINK
         2 主体
        10 队列
        79 帐户状态
23 规则集
24 资源管理器
73 架构
74 DBINSTANCE
51 调度程序全局属性
38 规则评估上下文
82 SQL AREA BUILD
75 SQL AREA STATS
5 CLUSTER
18 PUB SUB 内部信息

<===== =79 ACCOUNT_STATUS

ACCOUNT_STATUS 表示库缓存锁定位于帐户上。可能是您使用错误的用户名和密码登录，或者当时有人更改了用户（这种可能性极低）。

您可以使用以下SQL来确认错误的用户名和密码登录：
select username,
os_username,
userhost,
client_id,
trunc(timestamp),
count(*) failed_logins
来自 dba_audit_trail
其中 returncode=1017 和 --1017 是无效的用户名/密码
timestamp < sysdate -7
按用户名、os_username、userhost、client_id、trunc(timestamp) 分组；

或者运行以下sql：
SELECT "USERNAME", "OS_USERNAME", "USERHOST", "EXTENDED_TIMESTAMP",returncode FROM "SYS"."DBA_AUDIT_SESSION" WHERE returncode != 0;< br/>
当然，您必须确保审计已打开，并且存在审计 CREATE SESSION 操作

要打开审计：
Alter system setaudit_trail=DBscope= sp文件;
r启动数据库

审计CREATE SESSION;
审计ALTER USER;

检查：
显示参数audit_trail
select * from DBA_STMT_AUDIT_OPTS;

2）统计信息正在被收集，这是人们容易忽视的。他们通常会查看last_ddl_time，但忽略last_analyzed。
检查脚本如下：

例如，EMP遇到库缓存锁中的表名：
selectowner， object_name,object_type,to_char(last_ddl_time,'yyyy-mm-dd hh34:mi:ss') from dba_objects where object_name='EMP';

select table_name,to_char(last_analyzed,'yyyy-mm- dd hh34:mi:ss') from dba_tables where table_name='EMP';

还需要检查所有依赖对象，因为Oracle对象之间是有关联的，一个对象失败就会导致导致一系列失败。
selectowner,object_name,object_type,to_char(last_ddl_time,'yyyy-mm-dd hh34:mi:ss') ddl_time from dba_objects where object_name in
(
select p.name
从 sys.obj$ d, sys.dependency$ dep,sys.obj$ p
其中 d.obj# = dep.d_obj# 和 p.obj# = dep.p_obj#
开始with d.name='EMP'
按之前的 dep .p_obj#=dep.d_obj#)
按 ddl_time desc 排序；

select table_name,to_char(last_analyzed,' yyyy-mm-dd hh34:mi:ss') from dba_tables where table_name in
(
select p.name
from sys.obj$ d, sys.dependency$ dep, sys.obj $ p
其中 d.obj# = dep.d_obj# 和 p.obj# = dep.p_obj#
以 d.name='EMP' 开始
通过之前的 dep.p_obj# 连接=dep.d_obj#)
order by last_analyzed desc;

典型用户示例：
select to_char(last_analyzed,'yyyy-mm-dd hh34:mi:ss') from dba_tables where table_name='XXXXX';
- -2014-11-25 16:52:50
<=============在发布时间收集统计信息< br/>
2014-11-25 16:52:52 16620 c34q5c8gf6kum 库缓存锁
2014-11-25 16:52:52 16643 c34q5c8gf6kum 库缓存锁
<==== ==问题从16:52:52开始，统计时间为16:52:50

3) Wrong语句解决方案Parse（parse失败）
这是一个通常很难注意到的问题，因为在AWR中往往找不到解析后的语句（因为它没有通过parse）。注意AWR中的“解析失败经过时间”。 ”

事件等待时间平均等待（毫秒）% 数据库时间等待类
库缓存锁定 6,714,208 363,093 54 67.14 并发
库缓存：互斥体 X 11,977,886 99,050 8 18.31并发
DB CPU 38,971 7.21
数据库文件顺序读取 350,069 2,465 7 0.46 用户 I/O
日志文件同步 217,673 1,969 9 0.36 提交

统计名称时间 (s) 占 DB 时间的百分比
sql 执行所用时间 537,418.09 99.37
解析所用时间 467,101.99 86.37
失败解析所用时间 460,663.79 85.18 <=========== =====解析失败所用时间太长。这意味着问题是由解析失败引起的。