oracle 等待,必看干货 | Oracle常见的等待事件说明（下）

最新推荐文章于 2023-04-21 17:47:26 发布

小仙女的仙人掌

最新推荐文章于 2023-04-21 17:47:26 发布

阅读量94

点赞数

文章标签： oracle 等待

CTO练习营 | 12月3-5日，深圳，是时刻成为优良的技巧治理者了

9a3ae92bc16f2ba72b341fe095c00b68.jpg-wh_651x-s_3048106732.jpg

16.Library cache pin

这个等待事宜和 library cache lock 一样是产生在共享池中并发操作引起的事宜。平日来讲，如不雅 Oracle 要对一些 PL/SQL 或者视钤记样的对象做从新编译，须要将这些对象 pin 到共享池中。如不雅此时这个对象被其他的用户特有，就会产生一个 library cache pin 的等待。

这个等待事宜也包含四个参数：

--Handle address: 被加载的对象的地址。

--Lock address：锁的地址。

--Mode：被加载对象的数据片段。

--Namespace：被加载对象在 v$db_object_cache 视图中 namespace 名称。

17.Log file parallel write

后台过程 LGWR 负责将 log buffer 傍边的数据写到 REDO 文件中，以重用 log buffer 的数据。如不雅每个 REDO LOG 组琅绫擎有 2 个以上的成员，那么 LGWR 过程会并行地将 REDO 信息写入这些文件中。

如不雅数据库中出现这个等待事宜的瓶颈，重要的原因可能是磁盘 I/O 机能不敷或者 REDO 文件的分布导致了 I/O 争用，比如同一个组的 REDO 成员文件放在雷同的磁盘上。

这个等待事宜有三个参数：

--Files：操作须要写入的文件个数。

--Blocks：操作须要写入的数据块个数。

--Requests：操作须要履行的 I/O 次数。

18.Log buffer space

--Current：当前的日记。

当 log buffer 中没有可用空间来存放新产生的 redo log 数据时，就会产生 log buffer space 等待事宜。如不雅数据库中新产生的 redo log 的数量大年夜于 LGWR 写入稻磁逄中的 redo log 数量，必须等待 LGWR 完成写入磁盘的操作，LGWR 必须确保 redo log 写稻磁逄成功之后，才能在 redo buffer 傍边重用这部分信息。

如不雅数据库中出现大年夜量的 log buffer space 等待事宜，可以推敲如下办法：

-- 增长 redo buffer 的大年夜小。

-- 晋升磁盘的 I/O 机能

19.Log file sequential read

这个等待事宜平日产生在对 redo log 信息进行攫取时，比如在线 redo 的归档操作，ARCH 过程须要攫取 redo log 的信息，因为 redo log 的信息是次序写入的，所以在攫取时也是按照次序的方法来攫取的。

这个等待事宜包含三个参数：

--Log#：产生等待时攫取的 redo log 的 sequence 号。

--Block#：攫取的数据块号。

--Blocks：攫取的数据块个数。

20.Log file single write

这个等待事宜产生在更新 redo log 文件的文件头时，当为日记组增长新的日记成员时或者 redo log 的 sequence 号改变时，LGWR 都邑更新 redo log 文件头信息。

--Block#：写入的数据块号。

--Blocks：写入的数据块个数。

21.Log file switch(archiving needed)

在归档模式下，这个等待事宜产生在在线日记切换(log file switch)时，须要切换的在线日记还没有被归档过程(ARCH)归档完毕的时刻。当在线日记文件切换到下一?日记时，须要确保下一?日记文件已经被归档过程归档完毕，不然不许可覆盖那个在线日记信息(不然会导致归档日记信息不完全)。出现如许的等待事宜平日是因为某种原因导致 ARCH 过程逝世掉落，比如 ARCH 过程测验测验向目标地写入一个归档文件，然则没有成功(介质掉效或者其他原因)，这时 ARCH 过程就会逝世掉落。如不雅产生这种情况，在数据库的 alert log 文件中可以找到相干的缺点信息。

这个等待事宜没有参数。

22.Log file switch(checkpoint incomplete)

当一个在线日记切换到下一?在线日记时，必须包管要切换到的在线日记上的记录的信息(比如一些脏数据块产生的 redo log)被写稻磁逄上(checkpoint)，如许做的原因是，如不雅一个在线日记文件的信息被覆盖，而依烂魅这些 redo 信息做恢复的数据块尚未被写稻磁逄上(checkpoint)，此时体系 down 掉落的话，Oracle 将没有办法进行实例恢复。

在 v$log 视图里记录了在线日记的状况。平日来说，在线日记有三种状况。

--Active: 这个日记膳绫擎保护的信息还没有完成 checkpoint。

--Inactive：这个日记膳绫擎保护的信息已完成 checkpoint。

如不雅体系中出现大年夜量的 log file switch(checkpoint incomplete)等待事宜，原因可能是日记文件太小或者日记组太少，所以解决的办法是，增长日记文件的大年夜小或者增长日记组的数量。

这个等待事宜没有参数。

23.Log file sync

这是一个用户会话行动导致的等待事宜，当一个会话发出一个 commit 敕令时，LGWR 过程会将这个事务产生的 redo log 大年夜 log buffer 琅绫擎写稻磁逄上，以确保用户提交的信息被安然地记录到数据库中。会话发出的 commit 指令后，须要等待 LGWR 将这个事务产生的 redo 成功写入稻磁逄之后，才可以持续进行后续的操作，这个等待事宜就叫作 log file sync。

27.SQL*Net message from dblink

--Log#：写入的 redo log 组的编号。

以下几种情况，可能产生这个等待：

-- 高提交频率

解决办法是简单的清除不须要的提交，事务是工作单位。工作单位应当是全部成功或全部掉败。

-- 迟缓的 I/O 子体系

较高的 IO 吞吐良可以改良 log file sync 和 log file parallel write 事宜的平均等待时光。频繁的提交会弄乱数据库构造和 IO 子体系。解决办法是将日记文件放裸设备上或绑定在 RAID 0 或 RAID 0+1 中，而不是绑定在 RAID 5 中。

-- 过大年夜的日记缓冲区

过大年夜的日记缓冲区也可能延长 log file sync 等待。大年夜型的日记缓冲区削减后台写入的数量，许可 LGWR 变得懒惰，并导致更多的重做条目聚积在日记缓冲区中。同时可声调剂参数_LOG_IO_SIZE 参数，其默认值是 LOG_BUFFER 的 1/3 或 1MB，取两者之中较小的值。换句话说，你可以具有较大年夜的日记缓冲区，但较小的_LOG_IO_SIZE 将增长后台写入，大年夜而削减 log file sync 的等待时光.