常见非空闲等待事件:影响性能-性能优化

合集下载

Oracle数据库DBA面试题及答案_经典

Oracle数据库DBA面试题及答案_经典

1.OracleDBA面试题之一解释冷备份和热备份的不同点以及各自的优点解答:热备份针对归档模式的数据库,在数据库仍旧处于工作状态时进行备份。

而冷备份指在数据库关闭后,进行备份,适用于所有模式的数据库。

热备份的优点在于当备份时,数据库仍旧可以被使用并且可以将数据库恢复到任意一个时间点。

冷备份的优点在于它的备份和恢复操作相当简单,并且由于冷备份的数据库可以工作在非归档模式下,数据库性能会比归档模式稍好。

(因为不必将archive log写入硬盘)2. 你必须利用备份恢复数据库,但是你没有控制文件,该如何解决问题呢?解答:重建控制文件,用带backup control file 子句的recover 命令恢复数据库。

3. 如何转换init.ora到spfile?解答:使用create spfile from pfile 命令4. OracleDBA面试题:解释data block , extent 和 segment的区别(这里建议用英文术语)解答:data block是数据库中最小的逻辑存储单元。

当数据库的对象需要更多的物理存储空间时,连续的data block就组成了extent . 一个数据库对象拥有的所有extents 被称为该对象的segment.5. 给出两个检查表结构的方法解答:1、DESCRIBE命令2、DBMS_METADATA.GET_DDL 包6. 怎样查看数据库引擎的报错解答:alert log.7. 比较truncate和delete 命令解答:两者都可以用来删除表中所有的记录。

区别在于:truncate是DDL操作,它移动HWK,不需要 rollback segment .而Delete是DML操作需要rollback segment 且花费较长时间.8. 使用索引的理由解答:快速访问表中的data block9. 给出在STAR SCHEMA中的两种表及它们分别含有的数据解答:Fact tables 和dimension tables. fact table 包含大量的主要的信息而dimension tables 存放对fact table 某些属性描述的信息10. FACT Table上需要建立何种索引?解答:位图索引(bitmap index)11.OracleDBA面试题:给出两种相关约束?解答:主键和外键12. 如何在不影响子表的前提下,重建一个母表解答:子表的外键强制实效,重建母表,激活外键13. 解释归档和非归档模式之间的不同和它们各自的优缺点解答:归档模式是指你可以备份所有的数据库 transactions并恢复到任意一个时间点。

statspack报告的分析

statspack报告的分析

statspack报告的分析调整STATSPACK 的收集门限Statspack 有两种类型的收集选项:级别(level):控制收集数据的类型门限(threshold):设置收集的数据的阈值。

1.级别(level)Statspack 共有三种快照级别,默认值是5a.level 0: 一般性能统计。

包括等待事件、系统事件、系统统计、回滚段统计、行缓存、SGA、会话、锁、缓冲池统计等等。

b.level 5: 增加SQL 语句。

除了包括level0 的所有内容,还包括SQL 语句的收集,收集结果记录在stats$sql_summary 中。

c.level 10: 增加子锁存统计。

包括level5 的所有内容。

并且还会将附加的子锁存存入stats$lathc_children 中。

在使用这个级别时需要慎重,建议在Oracle support 的指导下进行。

可以通过statspack 包修改缺省的级别设置SQL>execute statspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);通过这样的设置,以后的收集级别都将是0 级。

如果你只是想本次改变收集级别,可以忽略i_modify_parameter 参数。

SQL>execute statspack.snap(i_snap_level=>10);2.快照门限快照门限只应用于stats$sql_summary 表中获取的SQL 语句。

因为每一个快照都会收集很多数据,每一行都代表获取快照时数据库中的一个SQL 语句,所以stats$sql_summary 很快就会成为Statspack 中最大的表。

门限存储在stats$statspack_parameter 表中。

让我们了结一下各种门限:a. executions_th 这是SQL 语句执行的数量(默认值是100)b. disk_reads_tn 这是SQL 语句执行的磁盘读入数量(默认值是1000)c. parse_calls_th 这是SQL 语句执行的解析调用的数量(默认值是1000)d. buffer_gets_th 这是SQL 语句执行的缓冲区获取的数量(默认值是10000)任何一个门限值超过以上参数就会产生一条记录。

如何进行系统性能优化测试提升系统的响应速度与吞吐量

如何进行系统性能优化测试提升系统的响应速度与吞吐量

如何进行系统性能优化测试提升系统的响应速度与吞吐量作为现代软件开发中至关重要的一环,系统性能优化测试对于确保系统的高效运行和提升用户体验至关重要。

本文将介绍一些常用的系统性能优化测试方法,以帮助您提升系统的响应速度与吞吐量。

一、分析性能瓶颈在进行系统性能优化测试之前,我们首先需要分析系统的性能瓶颈,以便有针对性地进行优化。

常见的性能瓶颈包括:CPU利用率、内存使用情况、磁盘IO速度、网络带宽等。

通过使用性能监控工具,我们可以实时监控系统的性能指标,并找出系统存在的瓶颈点。

二、负载测试负载测试是一种用来测试系统在各种负载条件下的性能表现的方法。

通过模拟多个并发用户对系统进行访问,可以模拟真实的生产环境,并观察系统在高负载情况下的性能表现。

在进行负载测试时,我们可以使用工具如Apache JMeter、LoadRunner等,来模拟大量用户对系统进行访问,并记录系统的响应时间、吞吐量等性能指标。

三、压力测试压力测试是一种用来测试系统在极限负载情况下的性能表现的方法。

通过模拟大量并发用户对系统进行访问,可以测试系统在高压力条件下的稳定性和可靠性。

压力测试常用的指标包括系统的最大并发用户数、承载量、错误率等。

在进行压力测试时,我们可以使用工具如Apache JMeter、LoadRunner等,来模拟大量用户对系统进行高频访问,并观察系统的性能表现。

四、响应时间测试响应时间是衡量系统性能的重要指标之一。

通过测量用户发起请求到系统给出响应的时间,我们可以评估系统的响应速度。

在进行响应时间测试时,我们可以使用工具如Apache JMeter、LoadRunner等,模拟用户对系统进行请求,并记录系统的响应时间。

在测试过程中,我们可以调整不同的负载条件,观察系统的响应时间是否符合预期。

五、代码优化在进行系统性能优化测试时,我们经常会发现系统的性能瓶颈是由代码或算法造成的。

针对性地进行代码优化对于提升系统的性能至关重要。

IO操作对软件性能优化的影响与优化方法(七)

IO操作对软件性能优化的影响与优化方法(七)

IO操作对软件性能优化的影响与优化方法概述:在软件开发中,IO操作(输入输出操作)不可避免地与性能优化密切相关。

本文将探讨IO操作对软件性能的影响以及一些优化方法。

一、IO操作对软件性能的影响:1. 延迟:IO操作通常比内存读写速度慢几个数量级,可能导致程序等待IO操作完成的时间增加,从而降低软件性能。

2. 并发:多个IO操作同时进行时,可能会引发阻塞或竞争,进而导致性能下降。

3. 空间占用:IO操作消耗磁盘空间,如果频繁进行大量的IO操作,将占用大量的磁盘空间,对系统性能产生负面影响。

二、IO操作的优化方法:1. 异步IO:采用异步IO操作可以减少程序在等待IO操作期间的阻塞时间,提高并发性能。

2. 缓存:合理使用缓存可以减少对磁盘IO的频繁访问。

将常用的数据缓存在内存中,减少磁盘IO的次数,提高性能。

3. 批量IO:将多个IO操作批量处理,减少IO操作的次数和开销。

例如,将多个小文件合并成一个大文件进行批量写入。

4. 压缩技术:对需要进行IO操作的数据进行压缩处理,减少IO的数据量。

在数据存储和传输方面,采用压缩算法可以减少IO操作的时间和磁盘空间占用。

5. 文件格式优化:选择适合自身需求的文件格式,避免使用过于庞大的、不必要的文件格式。

优化文件格式能够减少IO操作的时间和空间占用。

6. 磁盘分区与磁盘读写策略:合理地进行磁盘分区和磁盘读写策略的设置,可以提高IO操作的效率。

根据数据的访问频率和大小等因素,将数据存储在不同的硬盘分区,以便更高效地进行IO操作。

三、案例分析:以一个文件读取和写入的场景为例,考虑如何通过优化IO操作提高软件性能。

1. 采用异步IO:使用异步IO来实现并行的文件读取和写入操作,充分利用CPU资源,减少等待时间。

2. 使用缓存:将读取的数据存储在内存缓存中,在下一次需要相同数据的时候直接从缓存中读取,避免了频繁的磁盘IO操作。

3. 批量IO操作:在写入文件时,将多个小数据块合并成一个较大的数据块,通过批量写入减少IO操作次数。

后端性能优化:如何提高服务器的响应速度和吞吐量

后端性能优化:如何提高服务器的响应速度和吞吐量

后端性能优化:如何提高服务器的响应速度和吞吐量先进的技术、高效的算法与合理的调优是提高服务器的响应速度和吞吐量的关键。

后端性能优化是一个综合性的工程,需要从硬件、操作系统、网络、数据库、中间件以及业务代码角度共同思考。

本文将从这几个方面详细介绍如何优化后端性能,以提高服务器的响应速度和吞吐量。

一、硬件优化服务器的性能直接受硬件配置的影响。

因此,提高服务器性能的首要任务就是对硬件进行合适的优化。

常见的硬件优化包括:1. CPU优化:选择高性能的CPU,比如采用多核多线程的CPU,能够有效提高服务器的运算能力。

2.内存优化:合理配置内存大小,可以减少由于内存不足导致的频繁磁盘读写,从而提高性能。

3.磁盘和存储优化:选择高速的磁盘和存储设备,比如固态硬盘,能够提高数据读写速度,从而加快服务器的响应速度。

4.网卡优化:选择高性能的网卡,能够提高数据传输速度,从而提高服务器的吞吐量。

5.服务器整体架构优化:选择合适的机箱、风扇、散热系统等设备,能够保证服务器的稳定性,从而提高服务器的稳定性和性能。

二、操作系统优化操作系统是服务器的核心,合理配置操作系统能够提高服务器的响应速度和吞吐量。

常见的操作系统优化包括:1.内核优化:调整系统内核参数,比如调整文件句柄数、网络缓冲区大小等,能够提高系统的性能。

2.磁盘IO优化:配置磁盘IO调度算法,选择合适的IO调度算法,能够提高磁盘读写性能,从而加快数据访问速度。

3.网络优化:调整网络参数,比如调整TCP连接数限制、调整TCP 缓冲区大小等,能够提高网络传输效率,从而提高服务器的吞吐量。

4.内存管理优化:合理配置内存大小,选择合适的内存调度算法,能够减少内存碎片,提高系统的稳定性和性能。

5.安全配置优化:合理配置防火墙、安全软件等,能够保障系统的安全性,从而提高服务器的稳定性和性能。

三、网络优化网络是服务器与客户端之间的桥梁,优化网络能够提高服务器的响应速度和吞吐量。

性能优化提升应用的响应速度和资源利用率

性能优化提升应用的响应速度和资源利用率

性能优化提升应用的响应速度和资源利用率在信息技术不断发展的今天,人们对于软件应用的要求也越来越高。

一个优秀的应用不仅要具备丰富的功能,还需要有良好的性能,以保证用户的体验和工作效率。

性能优化是确保应用程序在运行时具有高效的响应速度和充分利用系统资源的关键。

一、了解性能指标在进行性能优化之前,我们需要了解一些性能指标,以便更好地评估应用的性能。

以下是一些常见的性能指标:1. 响应时间:指用户发出请求后,应用程序完成相应操作所需的时间。

响应时间越短,用户的等待时间越少,体验越好。

2. 吞吐量:指单位时间内应用程序能够处理的请求数量。

吞吐量越高,应用程序的处理能力越强。

3. CPU利用率:指应用程序在运行过程中对CPU资源的利用程度。

高CPU利用率表示应用程序在运行时占用了大量的CPU资源,可能导致系统性能下降。

4. 内存利用率:指应用程序在运行过程中对内存资源的利用程度。

高内存利用率可能导致系统出现内存泄漏或者频繁的内存交换,从而影响系统性能。

了解这些性能指标可以帮助我们更准确地分析应用程序的性能问题,并有针对性地进行优化。

二、性能优化策略1. 代码优化:对应用程序的代码进行优化是性能优化的基础。

首先,我们可以通过减少不必要的代码,精简算法等来提高应用程序的执行效率。

其次,可以优化代码的结构,提高程序的可读性和维护性,从而减少bug的出现。

2. 并行计算:利用多线程或者分布式计算等方式,将应用程序的计算任务分解成多个子任务并行执行,可以提高应用程序的运行速度,充分利用多核处理器和分布式系统的资源。

3. 数据库优化:数据库是应用程序的重要组成部分,对数据库进行优化可以提高应用的性能。

例如,通过使用索引和合理的数据库表设计,可以加快查询速度;通过合理规划和优化SQL语句,可以降低数据库的负载。

4. 缓存优化:缓存可以缓解应用程序对其他资源的压力,提高响应速度。

合理使用缓存机制,可以将常用的数据或者计算结果存储在缓存中,减少对后端资源的访问。

云服务的性能分析与优化

云服务的性能分析与优化

云服务的性能分析与优化随着信息化时代的到来,云计算技术的发展越来越受到人们的关注。

云计算包含基础设施、平台和软件服务,它为用户提供了更佳的安全性、可靠性和性能的保障。

因此,越来越多的企业开始采用云计算,而云服务的性能分析与优化是保证其顺利运行的关键因素之一。

一、云服务的性能问题云服务的性能问题主要体现在以下几个方面:1.网络延迟:网络延迟是云服务性能问题的主要因素。

大部分云计算服务是基于Internet实现的,而Internet速度的快慢会影响云服务的动态响应和延迟时间。

此外,时区和语言的差异也会影响用户体验。

2.资源分配不均:在云服务中,资源分配不均可能会导致某些用户的需求无法得到满足。

此外,资源分配不当还可能导致云服务的性能下降或崩溃。

3.系统安全性:云服务的安全性是用户选择的关键因素之一。

随着云服务的发展,安全漏洞的风险也越来越高。

对于那些存储敏感信息的用户来说,安全问题尤其重要。

二、云服务性能分析为解决云服务性能问题,需要对其进行分析。

云服务的性能分析是云计算服务提供商评估其服务的关键过程。

以下是云服务性能分析中需要考虑的几个关键因素:1.资源利用率:资源利用率是衡量云服务运行效率的关键指标。

对于某些资源紧缺的云服务,资源利用率的提升可以显著改善其性能。

2.响应时间:响应时间是云服务性能的重要指标之一。

响应时间短的云服务往往会更受用户青睐。

3.吞吐量:吞吐量是衡量云服务处理数据量的指标。

对于需要处理大量数据的用户来说,选择高吞吐量的云服务是必要的。

4.网络延迟:网络延迟是衡量云服务性能的另一个重要指标。

较低的网络延迟可以显著提高云服务的性能和用户体验。

三、云服务性能优化以下是一些常见的云服务性能优化方法:1.缓存:使用缓存可以减少对服务的请求次数,从而降低网络延迟和响应时间。

当请求的数据在缓存中有效时,直接从缓存中获取数据也可以避免一些资源的浪费。

2.负载均衡:负载均衡技术可以将请求均匀地分布到不同的服务器中,使服务器不会由于资源分配不均或网络上的延迟而崩溃。

如何进行性能优化减少代码的执行时间

如何进行性能优化减少代码的执行时间

如何进行性能优化减少代码的执行时间一、概述性能优化是软件开发中非常重要的一环,它旨在提高程序的执行效率和响应速度。

在本文中,将介绍一些常见的性能优化技巧,以减少代码的执行时间。

二、算法优化1. 选择合适的算法:不同的算法对于同一问题的解决方式可能存在差异,选择合适的算法可以大大减少代码执行的时间。

2. 减少循环次数:在循环中进行频繁的计算可能会导致性能下降,可以通过合理设置循环条件或者减少循环次数来优化程序的性能。

3. 使用空间换时间的策略:可以使用缓存或者索引等数据结构来加速代码的执行,虽然会占用更多的内存空间,但是可以减少代码执行的时间。

三、代码结构优化1. 减少函数调用次数:函数调用会产生一定的开销,过多的函数调用会降低程序的性能,可以通过减少函数的调用次数来提高执行效率。

2. 减少代码重复:重复的代码会导致冗余的计算,可以将重复的代码封装为函数或者将其放在循环外部,以减少计算次数。

3. 优化条件判断:可以通过重新排列条件判断的顺序,将出现频率较高的条件判断放在前面,减少无效的判断,提高代码执行效率。

四、数据结构优化1. 使用合适的数据结构:选择合适的数据结构可以提高代码的执行效率,比如使用哈希表可以快速查找数据,使用数组可以提高数据的访问速度等。

2. 优化内存分配:频繁的内存分配和释放会导致性能下降,可以预先分配一块足够的内存空间,避免频繁的内存分配操作。

3. 使用缓存:将频繁访问的数据存放在缓存中,可以提高数据的读取速度,减少代码的执行时间。

五、并发优化1. 多线程或者多进程:使用多线程或者多进程可以将任务分解成多个子任务,并行执行,提高程序的执行效率。

2. 锁优化:对于共享资源的访问,使用合适的锁机制可以避免多个线程同时访问,减少资源竞争,提高执行效率。

六、工具优化1. 使用性能分析工具:通过使用性能分析工具可以找出代码的瓶颈所在,优化性能。

2. 编译优化:使用合适的编译选项可以进行代码优化,提高代码的执行效率。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

一些常见的非空闲等待事件有:.. db file scattered read.. db file sequential read.. buffer busy waits.. free buffer waits.. enqueue.. latch free.. log file parallel write.. log file sync下面结合AWR和statspack中的一些等待事件进行讲述。

--收集整理--Top 5 Wait Events~~~~~~~~~~~~~~~~~ Wait % TotalEvent Waits Time (cs) Wt Time-------------------------------------------- ------------ ------------ -------db file scattered read 26,877 12,850 52.94db file parallel write 472 3,674 15.13log file parallel write 975 1,560 6.43direct path write 1,571 1,543 6.36control file parallel write 652 1,290 5.31-------------------------------------------------------------1).. db file scattered read: DB文件分散读取。

--一次读取多个块--可能full scan这个等待事件很常见,经常在top5中出现,这表示,一次从磁盘读数据进来的时候读了多于一个block 的数据,而这些数据又被分散的放在不连续的内存块中,因为一次读进来的是多于一个block的。

通常来说我们可以认为是全表扫描类型的读,因为根据索引读表数据的话一次只读一个block,如果这个数字过大,就表明该表找不到索引,或者只能找到有限的索引,可能是全表扫描过多,需要检查sql是否合理的利用了索引,或者是否需要建立合理的索引。

当全表扫描被限制在内存时,它们很少会进入连续的缓冲区内,而是分散于整个缓冲存储器中。

尽管在特定条件下执行全表扫描可能比索引扫描更有效,但如果出现这种等待时,最好检查一下这些全表扫描是否必要,是否可以通过建立合适的索引来减少对于大表全表扫描所产生的大规模数据读取。

对于经常使用的小表,应该尽量把他们pin 在内存中,避免不必要的老化清除及重复读取。

2).. db file sequential read: DB文件连续读取。

--一次读取一块,单块,可能表的连接顺序不好,索引使用不好。

--sql优化通常显示单个块的读取(通常指索引读取),表示的是读进磁盘的block被放在连续的内存块中。

事实上大部分基本代表着单个block的读入,可以说象征着 IO 或者说通过索引读入的比较多。

因为一次IO若读进多个的block,放入连续的内存块的几率是很小的,分布在不同block的大量记录被读入就会遇到此事件。

因为根据索引读数据的话,假设100条记录,根据索引,不算索引本身的读,而根据索引每个值去读一下表数据,理论上最多可能产生100 buffer gets,而如果是full table scan,则100条数据完全可能在一个block 里面,则几乎一次就读过这个block了,就会产生这么大的差异。

这种等待的数目很多时,可能显示表的连接顺序不佳,或者不加选择地进行索引。

对于高级事务处理(high-transaction)、调整良好(welltuned)的系统,这一数值很大是很正常的,但在某些情况下,它可能暗示着系统中存在问题。

你应当将这一等待统计量与Statspack 报告中的已知问题(如效率较低的SQL)联系起来。

检查索引扫描,以保证每个扫描都是必要的,并检查多表连接的连接顺序。

DB_CACHE_SIZE 也是这些等待出现频率的决定因素。

有问题的散列区域(Hash-area)连接应当出现在PGA 内存中,但它们也会消耗大量内存,从而在顺序读取时导致大量等待。

它们也可能以直接路径读/写等待的形式出现。

表明有许多索引读取:调优代码(特别是连接)3).. Free Buffer Wait: 释放缓冲区。

这种等待表明系统正在等待内存中的缓冲,因为内存中已经没有可用的缓冲空间了。

如果所有SQL 都得到了调优,这种等待可能表示你需要增大DB_BUFFER_CACHE。

释放缓冲区等待也可能表示不加选择的SQL 导致数据溢出了带有索引块的缓冲存储器,没有为等待系统处理的特定语句留有缓冲区。

这种情况通常表示正在执行相当多数量的DML(插入/更新/删除),并且可能说明DBWR 写的速度不够快,缓冲存储器可能充满了相同缓冲器的多个版本,从而导致效率非常低。

为了解决这个问题,可能需要考虑增加检查点、利用更多的DBWR 进程,或者增加物理磁盘的数量。

4).. Buffer Busy Wait: 缓冲区忙。

该等待事件表示正在等待一个以unshareable方式使用的缓冲区,或者表示当前正在被读入buffer cache。

也就是当进程想获取或者操作某个block的时候却发现被别的进程在使用而出现等待。

一般来说Buffer Busy Wait不应大于1%。

检查缓冲等待统计部分(或V$WAITSTAT),看一下等待是否位于段头。

如果是,可以考虑增加自由列表(freelist,对于Oracle8i DMT)或者增加freelist groups.其修改语法为:SQL> alter table sp_item storage (freelists 2);对于Oracle8i而言,增加freelist参数,在很多时候可以明显缓解等待,如果使用LMT,也就是 Local Manangement Tablespace,区段的管理就相对简单。

还可以考虑修改数据块的pctusedpctfree值,比如增大pctfree可以扩大数据的分布,在某种程度上就可以减少热点块的竞争。

如果这一等待位于undo header,可以通过增加回滚段(rollback segment)来解决缓冲区的问题。

如果等待位于undo block上,我们可能需要检查相关应用,适当减少大规模的一致性读取,或者降低一致性读取(consistent read)的表中的数据密度或者增大DB_CACHE_SIZE。

如果等待处于data block,可以考虑将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布(可以增加pctfree 值,扩大数据分布,减少竞争),以避开这个"热点"数据块,或者可以考虑增加表中的自由列表或使用本地化管理的表空间(Locally Managed Tablespaces)。

如果等待处于索引块,应该考虑重建索引、分割索引或使用反向键索引。

反向键索引在很多情况下,可以极大地缓解竞争,其原理有点类似于hash分区的功效。

反向键索引(reverse key index)常建在一些值是连续增长的列上,例如列中的值是由sequence产生的。

为了防止与数据块相关的缓冲忙等待,也可以使用较小的块:在这种情况下,单个块中的记录就较少,所以这个块就不是那么"繁忙";或者可以设置更大的pctfree,使数据扩大物理分布,减少记录间的热点竞争。

在执行DML (insert/update/ delete)时,Oracle 向数据块中写入信息,对于多事务并发访问的数据表,关于ITL的竞争和等待可能出现,为了减少这个等待,可以增加initrans,使用多个ITL槽。

从本质上讲,这个等待事件的产生仅说明了一个会话在等待一个Buffer(数据块),但是导致这个现象的原因却有很多种。

常见的两种是:当一个会话视图修改一个数据块,但这个数据块正在被另一个会话修改时。

当一个会话需要读取一个数据块,但这个数据块正在被另一个会话读取到内存中时。

Oracle 操作的最小单位是块(Block),即使你要修改一条记录,也需要对这条记录所在的这个数据块做操作。

当你对这个数据块做修改时,其他的会话将被阻止对这个数据块上的数据做修改(即使其他用户修改的不是当前用户修改的数据),但是可以以一致性的方式读取这个数据块(from undo)。

当前的用户修改完这个数据块后,将会立即释放掉加在这个数据块上的排他锁,这样另一个会话就可以继续修改它。

修改操作是一个非常短暂的时间,这种加锁的机制我们叫Latch。

当一个会话修改一个数据块时,是按照以下步骤来完成的:以排他的方式获得这个数据块(Latch)修改这个数据块。

释放Latch。

Buffer busy waits等待事件常见于数据库中存在的热快的时候,当多个用户频繁地读取或者修改同样的数据块时,这个等待事件就会产生。

如果等待的时间很长,我们在AWR或者statspack 报告中就可以看到。

这个等待事件有三个参数。

查看有几个参数我们可以用以下SQL:SQL> select name, parameter1, parameter2, parameter3 from v$event_name where name=''buffer busy waits'';NAME PARAMETER1 PARAMETER2 PARAMETER3-------------------- ---------- ---------- ----------buffer busy waits file# block# class#在下面的示例中,查询的方法和这个一样,所以其他事件对参数的查询将不做过多的说明。

File#: 等待访问数据块所在的文件id号。

Blocks:等待访问的数据块号。

ID:在10g之前,这个值表示一个等待时间的原因,10g之后则表示等待事件的类别。

5).. latch free: latch释放latch 是一种低级排队机制,用于保护SGA 中共享内存结构。

latch就像是一种快速地被获取和释放的内存锁。

latch用于防止共享内存结构被多个用户同时访问。

如果latch不可用,就会记录latch释放失败(latch free miss)。

有两种与闩有关的类型:立刻和可以等待。

假如一个进程试图在立刻模式下获得闩,而该闩已经被另外一个进程所持有,如果该闩不能立刻可用的话,那么该进程就不会为获得该闩而等待。

它将继续执行另一个操作。

大多数latch 问题都与以下操作相关:没有很好的是用绑定变量(library cache latch)、重作生成问题(redo allocation latch)、缓冲存储器竞争问题(cache buffers LRU chain),以及buffer cache中的存在"热点"块(cache buffers chain)。

相关文档
最新文档