热门标签 | HotTags
当前位置:  开发笔记 > 数据库 > 正文

物理读之LRU(最近最少被使用)的深入解析-mysql教程

一组LRU链表包括LRU主链,LRU辅助链,LRUW主链,LRUW辅助链,称为一个WorkSet(工作组)如下图:650)this.srcwww.68idc.cnhelpuploadsallimg15121410060LM3-0.jpgtitle111.pngaltwKioL1PXLA_RrQwAAAE_O1bng

一组 LRU 链表包括 LRU 主链, LRU 辅助链, LRUW 主链, LRUW 辅助链,称为一个 WorkSet( 工作组 ) 如下图: 650) this.width=650;" src="http://www.68idc.cn/help/uploads/allimg/151214/10060LM3-0.jpg" title="111.png" alt="wKioL1PXLA_RrQwAAAE_O1bng

一组LRU链表包括LRU主链,LRU辅助链,LRUW主链,LRUW辅助链,称为一个WorkSet(工作组)如下图:

wKioL1PXLA_RrQwAAAE_O1bngXE780.jpg

sys@ZMDB> selectCNUM_SET,CNUM_REPL,ANUM_REPL,CNUM_WRITE,ANUM_WRITE from x$kcbwds whereCNUM_SET>0;

CNUM_SET CNUM_REPL ANUM_REPL CNUM_WRITE ANUM_WRITE

---------- ---------- ---------- --------------------

15221 15221 3796 0 0

15221 15221 3783 0 0

CNUM_SET:工作组总的buffer总数量

CNUM_REPL:工作组中LRUbuffer总数量(主LRU+LRU

ANUM_REPL:工作组中辅LRUBUFFER的数量

通过隐含参数查到BUFFER的总的个数是30442,正好与上面的CNUM_SET=15221+15221

sys@ZMDB>@?/rdbms/admin/show_para

Enter value for p: _db_block_buffers

old 12: AND upper(i.ksppinm) LIKEupper('%&p%')

new 12: AND upper(i.ksppinm) LIKEupper('%_db_block_buffers%')

P_NAME P_DESCRIPTION P_VALUE ISDEFAULT ISMODIFIEDISADJ

------------------------------------------------------------------------------------------------------------------------ --------- ---------- -----

_db_block_buffers Number of database blocks cached inmemory: hidden 30442 TRUE FALSE FALSE

Parameter

我们用以下语句查下数据库中buffer所在LRU的状态

sys@ZMDB> select lru_flag,count(*) from x$bh group by lru_flag;

LRU_FLAG COUNT(*)

---------- ----------

6 208

2 10

4 7122

8 15199

0 7646

我们对LRU_FLAG=62480等做出解释,举个例子,对于6是什么含义呢?

首先要在x$bh中找到lru_flag=6的任意的一个BUFFER

sys@ZMDB> select LRU_FLAG,LOWER(BA)from x$bh where lru_flag=6 andrownum=1;

LRU_FLAG LOWER(BA)

---------- ----------------

6 0000000081dae000

DUMP buffer_cacheBH信息,如下命令:

sys@ZMDB>alter session set events'immediate trace name buffers level 1';

Session altered.

ys@ZMDB> col value for a85

sys@ZMDB> select * from v$diag_info where name='Default TraceFile';

INST_ID NAME VALUE

---------- ---------------------------------------------------------------------------------------------------------------------------------------

1 Default Trace File /u01/app/oracle/diag/rdbms/zmdb/zmdb/trace/zmdb_ora_13235.trc

通过BA=81dae000搜索trace文件,

/u01/app/oracle/diag/rdbms/zmdb/zmdb/trace/zmdb_ora_13235.trc

得到如下内容:

BH (0x81fe7e38) file#: 1 rdba: 0x0040ace1 (1/44257) class: 1 ba:0x81dae000

set: 6 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc:0,25

dbwrid: 0 obj: 421 objn: 423 tsn: 0 afn: 1hint: f

hash: [0x9ef9d710,0x853f8da8] lru:[0x81fe7df0,0x81fe8050]

lru-flags: moved_to_tail on_auxiliary_list

ckptq: [NULL] fileq: [NULL] objq: [NULL]objaq: [NULL]

st: CR md: NULL fpin: 'kdswh06: kdscgr' tch:1

cr: [scn: 0x0.80350f4d],[xid: 0x0.0.0],[uba:0x0.0.0],[cls: 0x0.80350f4d],[sfl: 0x0],[lc: 0x0.8034c532]

flags: block_written_once redo_since_read

LRU_FLAG=6的意思是lru-flags: moved_to_tail on_auxiliary_list,就是向LRU的辅助链表的尾部移动,这有可能是SMONLRU的主链表上的非脏块、TCH<=1并且状态是非PINBUFFER被挂接到LRU辅助链表的尾部。

根据以上的方法同理可以解释出LRU_FLAG的含义:

LRU_FLAG

0==>LRU-主链冷端的头部,这个比较特殊他在DUMP没有显示LRU_FLAG

2==>LRU-主链冷端的尾部,lru-flags:moved_to_tail

4==>LRU-辅助链,lru-flags:on_auxiliary_list

6==>LRU-辅助链的尾部,lru-flags:moved_to_tail on_auxiliary_list

8==>LUR-主链热端,lru-flags:hot_buffer

当发生物理读时,Oracle会从LRU辅助链表找空闲的BUFFER,然后把LRU辅助的链上的BUFFER挂接到LRU主链的冷端头,实验如下:

首先要保证有LRU辅助链上的BUFFER,即有LRU_FLAG=6LRU_FLAG=4,如果数据库刚刚启来,可能没有LRU_FLAG=6LRU_FLAG=4,那需要做大量的物理读操作,才会有LRU_FLAG=6LRU_FLAG=4

sys@ZMDB> alter system flush buffer_cache;

System altered.

sys@ZMDB> selectlru_flag,count(*) from x$bh group by lru_flag;

LRU_FLAG COUNT(*)

---------- ----------

6 208

4 30009

0 2

第一次DUMP整个BUFFER CACHE:

sys@ZMDB> alter session set events'immediate trace name bufferslevel 1';

/u01/app/oracle/diag/rdbms/zmdb/zmdb/trace/zmdb_ora_13480.trc

发生物理读

gyj@ZMDB> conn gyj/gyj

Connected.

gyj@ZMDB> set autot on;

gyj@ZMDB> select id,name,dbms_rowid.rowid_relative_fno(rowid) file#,dbms_rowid.rowid_block_number(rowid)block# from gyj_t1 where id=1;

ID NAME FILE# BLOCK#

---------- ---------------------------------------- ----------

1 gyj1 7 139

Execution Plan

----------------------------------------------------------

Plan hash value: 59758809

----------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

----------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 14 | 68 (0)| 00:00:01 |

|* 1 | TABLE ACCESS FULL| GYJ_T1 | 1| 14 | 68 (0)| 00:00:01 |

----------------------------------------------------------------------------

Predicate Information(identified by operation id):

---------------------------------------------------

1 - filter("ID"=1)

Statistics

----------------------------------------------------------

1 recursive calls

1 db block gets

254 consistent gets

248 physical reads

0 redo size

733 bytes sent via SQL*Net to client

523 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

sys@ZMDB> selectLRU_FLAG,lower(BA),TCH from x$bh where file#=7 and dbablk=139;

LRU_FLAG LOWER(BA) TCH

---------- --------------------------

0 000000007d1b2000 1

4 0000000078558000 0

4 0000000085f68000 0

物理读完成后,再次dump整个buffer cache,

sys@ZMDB>alter session set events'immediate trace name buffers level 1';

/u01/app/oracle/diag/rdbms/zmdb/zmdb/trace/zmdb_ora_13511.trc

BA=7d1b2000,搜索第一次DUMPtrace文件

/u01/app/oracle/diag/rdbms/zmdb/zmdb/trace/zmdb_ora_13480.trc

BH (0x7d3e8098) file#: 3 rdba:0x00c0586b (3/22635) class: 34 ba: 0x7d1b2000

set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc:0,25

dbwrid:0 obj: -1 objn: 0 tsn: 2 afn: 3 hint: f

hash: [0x9efa7570,0x9efa7570] lru:[0x7f7f5d30,0x7d3e8050]

lru-flags: on_auxiliary_list

ckptq: [NULL] fileq: [NULL] objq: [NULL]objaq: [NULL]

st: FREE md: NULL fpin: 'ktuwh03: ktugnb'tch: 0 lfb: 33

flags:

BA=7d1b2000,搜索第二次DUMPtrace文件

/u01/app/oracle/diag/rdbms/zmdb/zmdb/trace/zmdb_ora_13511.trc

BH (0x7d3e8098) file#: 7 rdba:0x01c0008b (7/139) class: 1 ba: 0x7d1b2000

set: 5 pool: 3 bsz: 8192 bsi: 0 sflg: 1 pwc:0,25

dbwrid: 0 obj: 22919 objn: 19567 tsn: 7 afn:7 hint: f

hash: [0x787e4bd8,0x9e4cda50] lru:[0x7f7f5d30,0x7d3e8050]

ckptq: [NULL] fileq: [NULL] objq:[0x9a88e518,0x7d3e8078] objaq: [0x9a88e508,0x7d3e8088]

st: XCURRENT md: NULL fpin: 'kdswh11:kdst_fetch' tch: 1

flags: only_sequential_access

LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN:[0xffff.ffffffff] HSUB: [65535]

从上面的两个trace可以得出结论ba: 0x7d1b2000

lru-flags:on_auxiliary_list(LRU_FLAG=4)LRU-主链冷端的头部,这个比较特殊在DUMP没有显示LRU_FLAG(LRU_FLAG=0)

观察LRUTCH>=2时冷端移到热端

1BUFFER手动设为100M

ALTER SYSTEM SETmemory_max_target=0 scope=spfile;

ALTER SYSTEM SET memory_target=0;

alter system set sga_target=0;

create table gyj1_t80 (idint,name char(2000));

create table gyj2_t80 (idint,name char(2000));

begin

for i in 1 .. 30000

loop

insert into gyj1_t80 values(i,'gyj'||i);

commit;

end loop;

end;

/

SQL> SQL> selectbytes/1024/1024||'M' from dba_segments where segment_name='GYJ1_T80' andowner='GYJ';

BYTES/1024/1024||'M'

-----------------------------------------

80M

begin

for i in 1 .. 30000

loop

insert into gyj2_t80 values(i,'gyj'||i);

commit;

end loop;

end;

/

create index idx_gyj1_t80m ongyj1_t80(id);

create index idx_gyj2_t80m ongyj2_t80(id);

SQL> show user;

USER is "GYJ"

SQL> conn / as sysdba

Connected.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORACLE instance started.

第一次dump

SQL> alter session set events'immediate trace name buffers level1';

Session altered.

SQL> select * fromv$diag_info where name='Default Trace File';

INST_ID NAME

---------- --------------------

VALUE

--------------------------------------------------------------------------------

1 Default Trace File

/u01/app/oracle/diag/rdbms/jfdb/jfdb/trace/jfdb_ora_7210.trc

发生一个物理读走索引

set autot on

selectid,name,dbms_rowid.rowid_relative_fno(rowid)file#,dbms_rowid.rowid_block_number(rowid) block# from gyj1_t80 where id=1;

SQL> selectid,name,dbms_rowid.rowid_relative_fno(rowid)file#,dbms_rowid.rowid_block_number(rowid) block# from gyj1_t80 where id=1;

ID NAME FILE# BLOCK#

------------------------------ ---------- ----------

1 gyj1 5 581

select LRU_FLAG,lower(BA),TCHfrom x$bh where file#=5 and dbablk=581;

SQL> select LRU_FLAG,lower(BA),TCH,decode(state,0,'free',1,'xcur',2,'scur'

2 ,3,'cr', 4,'read',5,'mrec',6,'irec',7,'write',8,'pi',9,'memory',10,'mwrite',11,

3 'donated', 12,'protected', 13,'securefile', 14,'siop',15,'recckpt', 16, 'flashf

4 ree', 17, 'flashcur', 18,'flashna') from x$bh where file#=5 anddbablk=581;

LRU_FLAG LOWER(BA) TCH DECODE(STA

---------- -------------------------- ----------

0 000000009fca8000 1 xcur

SQL> selectLRU_FLAG,lower(BA),TCH from x$bh where file#=5 and dbablk=581;

LRU_FLAG LOWER(BA) TCH

---------- --------------------------

0 000000009fca8000 5

SQL> set autot traceonly;

SQL> select /*+ index(G) */ count(name) fromgyj1_t80 G where id<=8000;

SQL> selectLRU_FLAG,lower(BA),TCH from x$bh where file#=5 and dbablk=581;

LRU_FLAG LOWER(BA) TCH

---------- --------------------------

0 000000009fca8000 6

再次发生物理读,此时LRU_FLAG=0变为8,同时TCH=8重置为0

SQL>select LRU_FLAG,lower(BA),TCH from x$bh where file#=5 and dbablk=581;

LRU_FLAG LOWER(BA) TCH

---------- ---------------- ----------

0000000009fca8000 8

SQL> select LRU_FLAG,lower(BA),TCH from x$bh where file#=5 anddbablk=581;

LRU_FLAG LOWER(BA) TCH

---------- ---------------- ----------

8000000009fca8000 0

BH (0x9ffe02a8) file#: 5 rdba: 0x01400245 (5/581) class: 1 ba:0x9fca8000

set: 5 pool: 3 bsz: 8192bsi: 0 sflg: 2 pwc: 15,19

dbwrid: 0 obj: 13537 objn:13537 tsn: 5 afn: 5 hint: f

hash:[0xb6a86de0,0xb6a86de0] lru: [0x9ffe0260,0x9ffe9a60]

lru-flags: hot_buffer

ckptq: [NULL] fileq: [NULL]objq: [0x9ffe0618,0x9ffe0028] objaq: [0x9ffe0628,0x9ffe0038]

st: XCURRENT md: NULL fpin:'kdswh05: kdsgrp' tch: 0

flags:

LRBA: [0x0.0.0] LSCN:[0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]

TCH=0时,再发生大量物理读,地址为9fca8000BUFFER就被重用了,彻底从BUFFER消失

SQL> selectLRU_FLAG,lower(BA),TCH from x$bh where file#=5 and dbablk=581;

LRU_FLAG LOWER(BA) TCH

---------- --------------------------

8 000000009fca8000 0

SQL> select LRU_FLAG,lower(BA),TCH from x$bh wherefile#=5 and dbablk=581;

no rows selected

通过实验,我们更清楚地了解到物理读LRU的基本流程,可以进一步理解物理读内部的LRU算法。

推荐阅读
  • 一、Hadoop来历Hadoop的思想来源于Google在做搜索引擎的时候出现一个很大的问题就是这么多网页我如何才能以最快的速度来搜索到,由于这个问题Google发明 ... [详细]
  • 阿里Treebased Deep Match(TDM) 学习笔记及技术发展回顾
    本文介绍了阿里Treebased Deep Match(TDM)的学习笔记,同时回顾了工业界技术发展的几代演进。从基于统计的启发式规则方法到基于内积模型的向量检索方法,再到引入复杂深度学习模型的下一代匹配技术。文章详细解释了基于统计的启发式规则方法和基于内积模型的向量检索方法的原理和应用,并介绍了TDM的背景和优势。最后,文章提到了向量距离和基于向量聚类的索引结构对于加速匹配效率的作用。本文对于理解TDM的学习过程和了解匹配技术的发展具有重要意义。 ... [详细]
  • 本文介绍了闭包的定义和运转机制,重点解释了闭包如何能够接触外部函数的作用域中的变量。通过词法作用域的查找规则,闭包可以访问外部函数的作用域。同时还提到了闭包的作用和影响。 ... [详细]
  • 本文详细介绍了SQL日志收缩的方法,包括截断日志和删除不需要的旧日志记录。通过备份日志和使用DBCC SHRINKFILE命令可以实现日志的收缩。同时,还介绍了截断日志的原理和注意事项,包括不能截断事务日志的活动部分和MinLSN的确定方法。通过本文的方法,可以有效减小逻辑日志的大小,提高数据库的性能。 ... [详细]
  • Linux服务器密码过期策略、登录次数限制、私钥登录等配置方法
    本文介绍了在Linux服务器上进行密码过期策略、登录次数限制、私钥登录等配置的方法。通过修改配置文件中的参数,可以设置密码的有效期、最小间隔时间、最小长度,并在密码过期前进行提示。同时还介绍了如何进行公钥登录和修改默认账户用户名的操作。详细步骤和注意事项可参考本文内容。 ... [详细]
  • 学习SLAM的女生,很酷
    本文介绍了学习SLAM的女生的故事,她们选择SLAM作为研究方向,面临各种学习挑战,但坚持不懈,最终获得成功。文章鼓励未来想走科研道路的女生勇敢追求自己的梦想,同时提到了一位正在英国攻读硕士学位的女生与SLAM结缘的经历。 ... [详细]
  • 生成式对抗网络模型综述摘要生成式对抗网络模型(GAN)是基于深度学习的一种强大的生成模型,可以应用于计算机视觉、自然语言处理、半监督学习等重要领域。生成式对抗网络 ... [详细]
  • 在Android开发中,使用Picasso库可以实现对网络图片的等比例缩放。本文介绍了使用Picasso库进行图片缩放的方法,并提供了具体的代码实现。通过获取图片的宽高,计算目标宽度和高度,并创建新图实现等比例缩放。 ... [详细]
  • 云原生边缘计算之KubeEdge简介及功能特点
    本文介绍了云原生边缘计算中的KubeEdge系统,该系统是一个开源系统,用于将容器化应用程序编排功能扩展到Edge的主机。它基于Kubernetes构建,并为网络应用程序提供基础架构支持。同时,KubeEdge具有离线模式、基于Kubernetes的节点、群集、应用程序和设备管理、资源优化等特点。此外,KubeEdge还支持跨平台工作,在私有、公共和混合云中都可以运行。同时,KubeEdge还提供数据管理和数据分析管道引擎的支持。最后,本文还介绍了KubeEdge系统生成证书的方法。 ... [详细]
  • 近年来,大数据成为互联网世界的新宠儿,被列入阿里巴巴、谷歌等公司的战略规划中,也在政府报告中频繁提及。据《大数据人才报告》显示,目前全国大数据人才仅46万,未来3-5年将出现高达150万的人才缺口。根据领英报告,数据剖析人才供应指数最低,且跳槽速度最快。中国商业结合会数据剖析专业委员会统计显示,未来中国基础性数据剖析人才缺口将高达1400万。目前BAT企业中,60%以上的招聘职位都是针对大数据人才的。 ... [详细]
  • Android中高级面试必知必会,积累总结
    本文介绍了Android中高级面试的必知必会内容,并总结了相关经验。文章指出,如今的Android市场对开发人员的要求更高,需要更专业的人才。同时,文章还给出了针对Android岗位的职责和要求,并提供了简历突出的建议。 ... [详细]
  • CSS3选择器的使用方法详解,提高Web开发效率和精准度
    本文详细介绍了CSS3新增的选择器方法,包括属性选择器的使用。通过CSS3选择器,可以提高Web开发的效率和精准度,使得查找元素更加方便和快捷。同时,本文还对属性选择器的各种用法进行了详细解释,并给出了相应的代码示例。通过学习本文,读者可以更好地掌握CSS3选择器的使用方法,提升自己的Web开发能力。 ... [详细]
  • 本文介绍了Java工具类库Hutool,该工具包封装了对文件、流、加密解密、转码、正则、线程、XML等JDK方法的封装,并提供了各种Util工具类。同时,还介绍了Hutool的组件,包括动态代理、布隆过滤、缓存、定时任务等功能。该工具包可以简化Java代码,提高开发效率。 ... [详细]
  • 本文介绍了C#中生成随机数的三种方法,并分析了其中存在的问题。首先介绍了使用Random类生成随机数的默认方法,但在高并发情况下可能会出现重复的情况。接着通过循环生成了一系列随机数,进一步突显了这个问题。文章指出,随机数生成在任何编程语言中都是必备的功能,但Random类生成的随机数并不可靠。最后,提出了需要寻找其他可靠的随机数生成方法的建议。 ... [详细]
  • qt学习(六)数据库注册用户的实现方法
    本文介绍了在qt学习中实现数据库注册用户的方法,包括登录按钮按下后出现注册页面、账号可用性判断、密码格式判断、邮箱格式判断等步骤。具体实现过程包括UI设计、数据库的创建和各个模块调用数据内容。 ... [详细]
author-avatar
wojijola;
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有