搜文章
推荐 原创 视频 Java开发 iOS开发 前端开发 JavaScript开发 Android开发 PHP开发 数据库 开发工具 Python开发 Kotlin开发 Ruby开发 .NET开发 服务器运维 开放平台 架构师 大数据 云计算 人工智能 开发语言 其它开发
Lambda在线 > 东面而视 > oracle 常用SQL查询(三)——ORACLE锁的管理

oracle 常用SQL查询(三)——ORACLE锁的管理

东面而视 2018-03-01

ORACLE里锁有以下几种模式:

0none

1null      空 

2Row-S     行共享(RS):共享表锁  

3Row-X     行专用(RX):用于行的修改

4Share     共享锁(S):阻止其他DML操作

5S/Row-X   共享行专用(SRX):阻止其他事务操作

6exclusive 专用(X):独立访问使用

数字越大锁级别越高影响的操作越多。

一般的查询语句如select ... from ... ;是小于2的锁有时会在v$locked_object出现。

select ... from ... for update;      2的锁。

当对话使用for update子串打开一个游标时,

所有返回集中的数据行都将处于行级(Row-X)独占式锁定,

其他对象只能查询这些数据行,不能进行updatedeleteselect...for update操作。

insert / update / delete ... ;      3的锁。 

没有commit之前插入同样的一条记录会没有反应

因为后一个3的锁会一直等待上一个3的锁我们必须释放掉上一个才能继续工作。

创建索引的时候也会产生3,4级别的锁。

locked_mode2,3,4不影响DML(insert,delete,update,select)操作

DDL(alter,drop)操作会提示ora-00054错误。

有主外键约束时 update / delete ... ; 可能会产生4,5的锁。

DDL语句时是6的锁。

DBA角色查看当前数据库里锁的情况可以用如下SQL语句:

select object_id,session_id,locked_mode from v$locked_object;

select t2.username,t2.sid,t2.serial#,t2.logon_time 

from v$locked_object t1,v$session t2 

where t1.session_id=t2.sid order by t2.logon_time;

如果有长期出现的一列,可能是没有释放的锁。

我们可以用下面SQL语句杀掉长期没有释放非正常的锁:

alter system kill session 'sid,serial#';

如果出现了锁的问题某个DML操作可能等待很久没有反应。

当你采用的是直接连接数据库的方式,

也不要用OS系统命令 $kill process_num 或者 $kill -9 process_num来终止用户连接,

因为一个用户进程可能产生一个以上的锁OS进程并不能彻底清除锁的问题。

记得在数据库级别用alter system kill session 'sid,serial#';杀掉不正常的锁。

5:42 PM | Add a comment | Permalink | Blog it | Oracle

July 18

利用STATSPAGK调整ORACLE性能

一、摘要

  大部分DBA都利用数据缓冲区命中率,latch free wait time等指标来做数据库性能调整。ORACLE提供的几个简单工具如STATSPACK(或以前版本的BSTAT/ESTAT)中包含了DBA 所需要的主要指标。但如何有效地利用这些数据调整性能?从那里开始调整?本文使用YAPP性能优化方法,结合STATSPACK提供的数据,给出了应该采取的调整步骤。

二、YAPP性能优化方法

  YAPP提供了另一种数据库性能调整方法,它不使用命中率等指标来衡量数据库的性能而是通过响应时间来衡量:

  Response time = service time + wait time

  即用户面对的响应时间由服务时间和等待时间组成。服务时间是处理你的请求实际使用的CPU时间,等待时间即等待资源可用所花费的时间。例如如果执行一个需要查找索引的SQL语句,CPU时间可能包括buffer cache中的索引数据块的处理时间,扫描该数据块找到所需行的时间等,此过程中ORACLE可能需要从盘上读数据,此时可能出现磁盘等待。

  YAPP方法的主要思路是找出service timewait time的主要组成部分,然后进行排序并根据顺序调整。因此在IO不是引起问题的原因时,你不会做出象数据缓冲区命中率太低,最好增加缓冲的结论’,SQL语句的CPU处理时间为20分钟时,你也不会做出必须将latchwait time减少20的调整决定。另外用YAPP做优化时,你可以通过减少整个时间(如用更快的磁盘)或单位时间(如减少访问磁盘次数)。因此我们称YAPP为基于时间的调优方法,基本步骤如下:

  (1)、得到服务时间和等待时间及其组成部分 

  (2)、将所有组成部分排序 

  (3)、依次优化每个部分 

  (4)、对表中的每一项,减少每次执行的代价或执行次数

  STATSPACKbstat/estat中的数据完全能满足基于时间而不是基于命中率的优化方法。然而实际上要找出所有耗时的部分有些困难,在分析细节时servicewait本身并不精确,例如当你等待磁盘IO时,实际是从OS的缓冲中读写,实际上它是service (即CPU)时间,因此响应时间更好的表达为:

  Response time = time compnent1+….+time componentn

  用户感知的响应时间由一系列时间成分组成,所谓性能优化就是优化最耗时的成分,依次类推。从ORACLE instance的角度,请求一般含三个部分:client (如SQLPLUSTUXEDO),前台进程(如LOCAL = NO的服务进程),后台进程(如DBWR)。

三、ORACLE中的时间记录

  所有的ORACLE进程(前台和后台)都会将所使用的CPU时间(service time)和各种等待事件所费时间记录下来,这些信息记录在SGA,用户可通过V$▁视图访问这些数据。这种数据分为session级和system级,用户可访问V$SYSTEM▁EVENTV$SYSSTAT等视图来获取这些信息。ORACLESTATSPACK工具(老版本中的BSTAT/ESTAT)就是查询这些视图来收集,计算和生成性能数据。要在ORACLE中产生时间记录,DBA必须在INIT.ORA中将TIMED▁STATISTICS设置为TRUE或通过ALTERSYSTEM将其定义为TRUE8i以前的版本中时间单位为1/100秒。9i以后时间单位为1/1,000,000(微秒)。本文主要面向system级的数据,但使用的方法适用于session级的数据。

  在基于时间的优化方法中,最重要的视图是V$SYSTEM▁EVENTV$SYSSTATV$LATCHV$SQLAREAV$SYSSTAT记录使用的CPU时间,V$SYSTEM▁EVENT记录进程等待时间花费的间,V$SQLAREA能用于找出最耗资源的SQL语句,而V$LATCH则可用于各种LATCH的等待信息。这些视图的详细结构和含义见Sewer Reference Mannual

四、利用STATSPACK优化性能

  前一节所说的V$▁ 中记录的数据都是系统启动后的累加值,从某一个时间点看这些累加值没有实际意义。只有每隔一段时间对这些累加值取样,计算出抽样之间的差别对优化才有价值。ORACLESTATSPACK就是完成定期取样的工作,一般可用ORACLEJOB来自动完成定期取样。数据收集完成后,DBA可以运行STATSPACK带的SPREPORT生成某两个取样点之间的差别。STATSPACK生成的报告中含有各种数据,包括上述四个视图中的数据。

  1、从STATSPACK报告中找出晌应时间组成部分

  基于时间的优化方法YAPP就是要找出最值得优化(最耗时)的成分。我们需找出前台进程使用的sevice time及等待事件花费的时间,service time信息可以从V$SYSSTAT中得到而事件等待花费的时间可从V$SYSTEM▁EVENT中得到。在STATSPACK报告中它们分别在 '''' Instance Activity Stats for DB '''' 和 '''' Wait Eventsfor DB '''' 一节中。尤其要注意三个时间成分:

  CPU used by this session Total CPU time spent. 

  Recursive cpu usage 

  Time spent doing recursive work in the foreground .   

  This includes data dictionary lookup and any PL /SQL work, including time spent 

by SQL inside 

  PL/SQL parse time cpu 

  CPU time spent parsing SQL statements

  Recursive cpu usageparse time cpu CPUCPU used by this session的组成部分,除此之外的CPU时间我们一律定义为other CPU

  下一步需找出wait time的组成部分,最简单的方法就是找出 '''' Top5Wait Events '''' 下的5个等待事件,另一种方法即在 '''' Wait events for DB '''' 一节中找出最主要的事件。

  下面是根据STATSPACK报告的数据,用基于YAPP方法的优化步骤:

  (1)、找出parse time cpu所花费的时间 

  (2)、找出CPU used by this session的值,减去parse time cpu,得出other CPU 

  (3)、找出最耗时的等待事件 

  (4)、将1—3的成分倒序排序,从第一项开始优化 

  (5)、如果最耗时的等待事件不是latch free,见Tuning possibilities for wait events 

  (6)、如果最耗时的等待事件是latch free,见Tuning possibilities for  latches 

  (7)、如果最耗时的成分是与CPU有关的成分,Tuning possibilities for CPU

  2Tuning possibilities for CPU

  recursive cpu usage  如果处理大量的PLSQL此成分可能很高,本文不深入讨论此问题产生的原因,但你需要找出你所有的PLSQL,包括存储过程。找出CPU开销最大的PLSQL过程并对其优化。如果PLSQL中的主要工作是完成过程处理而非执行SQL,高开销的recursive cpu usage可能是需要优化的成分。

  parse time cpu  分析(parsingSQL是一个开销很大的,它可以通过SQL语句的重用来避免。在预编译程序中,可通过增加MAXOPENCURSORS参数减少这部分开销。V$SQLPARSE▁CALLSEXECUTIONS可用来找出经常parse的语句。

  Other cpu  其它CPU主要用于处理缓冲区中的缓冲。一般而言,SQL语句花费的CPU时间与访问的缓冲区个数成比例,因此可以从V$SQL中的buffer gets得到SQL所防问的缓冲区个数,在STATSPACK中,可以查看 '''' SQL ordered by Gets for DB ''''。应对清单中的SQL语句优化。在bstat /estat报告中没有SQL语句,需定期查询V$SQLAREA,找出buffer gets增加最快的语句。9iV$SQL中含有CPU▁T|ME字段,记录语句所花费的时间。

  3Tuning possibilities for wait events

  db file scattered read  ORACLE全表扫描时,一次需读多个数据块,此时使用这一等待事件。i n i t .o r a中的db▁ file▁mutiblock▁read▁count定义了多数据块读取时,一次能读取的最大块数。一般此参数定义为4—16,与数据库大小无关。但值越大DB▁BLOCK▁SlZE应越小。如果db file scattered read所占比例较大,必须减少IO的代价(如使用更快的磁盘,均衡IO分布),或减少全表扫描的次数(优化SQL语句)。参见下面IO优化。

  db file sequential read  表示ORACLE顺序读数据块,一般出现在读索引。如果db file sequential read等待很长,必须减少IO的代价(如使用更快的磁盘,均衡IO分布),或增加缓冲区。参见下面IO优化。

  buffer busy waits  多个进程访问(修改)缓冲区中同一数据块时出现此等待事件。当表没有free lists而对表并行插入时,或回滚段个数太少时,会出现此事件,V$WA|TSTAT及 

STATSPACK报告可辅助找出原因。

  latch free  见下节。

  Enqueue  一般为应用程序使用的锁,例如SEELECT ... FOR UPDATE。如果此部分占用的时间较大,需分析应用系统,尤其是长时间占有锁资源的代码。要分析每个锁的等待时间不太可能,虽然V$LOCK记录了每种所等待的次数。

  log file sync  任何时候一个事物提交时,它将通知LGWRLOG▁BUFFER写入日志文件,如果此部分占用时间较长,应减少COMMIT的次数,此外应使用性能更好的IO系统,另一个相关的事件是'''' log buffer parallel write '''' ,也与IO系统或CPU资源太少有关。

  free buffer wait   当一个SESSION需要空闲缓冲区但不能获取时,出现此等待事件。它将通知DBWR将脏的缓冲区写入数据文件。需要确定是否需要优化IO系统或者增加DBWR的个数,如果此事件不是由于IO系统性能引起的,可考虑增加缓冲区。

  rdbms ipc message  这些事件为空闲事件,一般应占主要的时间。''''

  pmon timer

  smon timer

  SQL*Net message 

  from client

  Tuning possibilities for latches

  shared pool   parsing,尤其是hard parsing时。如果应用程序使用常量而不是BIND变量,可能会对此latch大量竞争,8.1.6以后可在init.ora中设置cursor▁sharingforce来减少hard parsing和对此latch的竞争,应用程序应保证只分析一次,执行多次。

  library cache  soft parsinghard parsing时都会大量使用此latch,如有可能应修改应用程序,减少竞争。在init.ora中设置cursor▁sharingforce可减少soft parsinghard parsing需要的library cache。此外定义session▁cached▁cursors也能减少同一sessionsoft parsinglibrary cache的竞争。此外还可以定义cursor▁space▁for▁time=true

  mw cache  row cache保护字典信息,如表和列的信息。hard parsing需要row cache 。在init.ora中设置cursor▁sharingforce可减少竞争。

  cache buffer chain   保护缓冲区的hash chain,用于对缓冲区的每次访问。一般可通过减少访问缓冲区次数来减少对l|atch的竞争。利用X$BH可以找出某些hash chain是否有许多的缓冲区,经常会有热块(如root index block)可能引起竞争。

  cache buffer lru chain  数据缓冲一组LRU块组成的链。每一个由一个cache buffer lru  chain 保护通过增加db▁ block▁lru▁latches可减少竞争。

  4Tuning possibilities for I/O 

如果db file scattered/sequential read等直接的事件或file writeDBWR/LGWR)等非直接事件占用的时间比例较大,需要检查IO的效率。STATSPACK报告中有一节为 ''''Tablespace IO Summary for DB'''' 其中列出了表空间名称和它们的lO rate。另一节'''' file IO Statistics for DB''''列出了每个数据文件和它们的IO rate。首先应检查IO rate是否在期望的范围,其次应检查IO分布。如果IO rate 在可接受的范围(带cache的文件2—10ms或裸设备的每次IO 5—20ms)而且所有的数据文件IO  rate相似,那么可以肯定IO系统的性能符合要求。这种情况下减少每次IO代价没有必要,应该减少IO的次数(增加缓冲区或优化SQL)。然而如果IO rate大大超出合理范围或分布不合理,你需要重组IO子系统,如使用更多的磁盘驱动器,修改结构(如不使用RAID5),或IO重新分布。

五、值得注意的地方

  虽然ORACLE的统计和等待事件可以为你找出系统瓶颈提供了很好的数据,但有些情况这些数据可能会误导用户:

  ·ORACLE 8i以前的版本时间单位是1/100秒,但在某些特别|的系统中其精度不够。因而某些发生过的事件可能没有记录,而某些发生时间并不很长的事件记录的时间要比实际的时间长。这个问题在9i中不会出现(计量单位是1/1,000,000秒)。

  ·ORACLE前台进程花费的CPU时间记录比较粗糙,CPU used by this session远远大于实际使用配的时间,唯一能做的估计是所用CPU时间与所访问的缓冲区个数成比例,但在运行大的PLSQL,复杂的表达式,表连接时这种估计是不精确的。一般而言,这类估计在OLTP类型的应用系统是有效的,对DSS系统这种估计是不精确的。

  ·V$SYSSTAT视图包含前台和后台进程时间的总和,然而CPU时间成分中只有前台进程所用的时间值得注意,某些后台进程(尤其是DBWRLGWR)使用了大量的CPU,导致前台进程统计配的不精确。

  ·某些时间没有计算。如SQL*NET的时间,但它影响响应时间。

  ·YAPP中只考虑了ORACLE前台进程使用的时间,如果ORACLE所用的时间只占响应时间的很小部分,优化ORACLE不会带来任何性能改进。

六、IBSTAT/ESTAT的使用

  STATSPACK只有8.1.6以后的版本才有,如果使用的老的版本只有BSTAT/ESTAT,两者的主要区别是:

  ·BSTAT/ESATDBA直接手工运行而不通过ORACLE JOB自动运行,每运行一次只收集一个时间间隔的数据。

  ·BSTAT/ESAT没有SQL语句的信息,如果OTHER CPU是开销最大的成分,需要查询V$SQL找出最耗资源的SQL

  ·没有TOP5 WAIT EVENT,需查找视图找出最耗时的事件。

[关闭窗口]

1:41 PM | Add a comment | Permalink | Blog it | Oracle

Oracle性能调优实践中的几点心得

很多的时侯,做Oracle DBA的我们,当应用管理员向我们通告现在应用很慢、数据库很慢的时侯,我们到数据库时做几个示例的Select也发现同样的问题时,有些时侯我们会无从下手,因为我们认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了,实际中性能优化最根本的出现点也都集中在IO,这是影响性能最主要的方面,由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法,下面把我的一点实践经验与大家分享一下,本文测重于Unix环境。

一、通过操作系统的一些工具检查系统的状态,比如CPU、内存、交换、磁盘的利用率,根据经验或与系统正常时的状态相比对,有时系统表面上看起来看空闲这也可能不是一个正常的状态,因为cpu可能正等待IO的完成。除此之外我们还应观注那些占用系统资源(cpu、内存)的进程。

1、如何检查操作系统是否存在IO的问题?使用的工具有sar,这是一个比较通用的工具。

  Rp1#Sar -u 2 10

  即每隔2秒检察一次,共执行20次,当然这些都由你决定了。

  示例返回:

  HP-UX hpn2 B.11.00 U 9000/800    08/05/03

  18:26:32    %usr    %sys    %wio   %idle

  18:26:34      80       9      12       0

  18:26:36      78      11      11       0

  18:26:38      78       9      13       1

  18:26:40      81      10       9       1

  18:26:42      75      10      14       0

  18:26:44      76       8      15       0

  18:26:46      80       9      10       1

  18:26:48      78      11      11       0

  18:26:50      79      10      10       0

  18:26:52      81      10       9       0

  Average       79      10      11       0

    其中的%usr指的是用户进程使用的cpu资源的百分比,%sys指的是系统资源使用cpu资源的百分比,%wio指的是等待io完成的百分比,这是值得我们观注的一项,%idle即空闲的百分比。如果wio列的值很大,如在35%以上,说明你的系统的IO存在瓶颈,你的CPU花费了很大的时间去等待IO的完成。Idle很小说明系统CPU很忙。像我的这个示例,可以看到wio平均值为11说明io没什么特别的问题,而我的idle值为零,说明我的cpu已经满负荷运行了。

当你的系统存在IO的问题,可以从以下几个方面解决

  ♀联系相应的操作系统的技术支持对这方面进行优化,比如hp-ux在划定卷组时的条带化等方面。

  ♀查找Oracle中不合理的sql语句,对其进行优化

  ♀Oracle中访问量频繁的表除合理建索引外,再就是把这些表分表空间存放以免访问上产生热点,再有就是对表合理分区。

2、关注一下内存。

    常用的工具便是vmstat,对于hp-unix来说可以用glance,Aix来说可以用topas,当你发现vmstatpi列非零,memory中的free列的值很小,glance,topas中内存的利用率多于80%时,这时说明你的内存方面应该调节一下了,方法大体有以下几项。

  ♀划给Oracle使用的内存不要超过系统内存的1/2,一般保在系统内存的40%为益。

  ♀为系统增加内存

  ♀如果你的连接特别多,可以使用MTS的方式

  ♀打全补丁,防止内存漏洞。

3、如何找到点用系用资源特别大的Oraclesession及其执行的语句。

Hp-unix可以用glance,top

IBM AIX可以用topas

些外可以使用ps的命令。

通过这些程序我们可以找到点用系统资源特别大的这些进程的进程号,我们就可以通过以下的sql语句发现这个pid正在执行哪个sql,这个sql最好在pl/sql developer,toad等软件中执行<>中的spid换成你的spid就可以了。

SELECT a.username,

       a.machine,

       a.program,

       a.sid,

       a.serial#,

       a.status,

       c.piece,

       c.sql_text

  FROM v$session a,

       v$process b,

       v$sqltext c

 WHERE b.spid=  

   AND b.addr=a.paddr

   AND a.sql_address=c.address(+)

 ORDER BY c.piece    

   我们就可以把得到的这个sql分析一下,看一下它的执行计划是否走索引,对其优化避免全表扫描,以减少IO等待,从而加快语句的执行速度。

提示:我在做优化sql时,经常碰到使用in的语句,这时我们一定要用exists把它给换掉,因为Oracle在处理In时是按Or的方式做的,即使使用了索引也会很慢。

比如:

SELECT  col1,col2,col3 FROM table1 a 

 WHERE a.col1 not in (SELECT  col1 FROM table2)

       可以换成:

SELECT  col1,col2,col3 FROM table1 a 

 WHERE not exists

 (SELECT  'x'  FROM table2 b

WHERE  a.col1=b.col1)

4、另一个有用的脚本:查找前十条性能差的sql.

 SELECT * FROM 

  (

   SELECT PARSING_USER_ID

          EXECUTIONS,

          SORTS,

          COMMAND_TYPE,

          DISK_READS,

          sql_text

      FROM  v$sqlarea

     ORDER BY disk_reads DESC 

   )  

  WHERE ROWNUM<10 ;

 

二、迅速发现Oracle Server的性能问题的成因,我们可以求助于v$session_wait这个视图,看系统的这些session在等什么,使用了多少的IO。以下是我提供的参考脚本:

脚本说明:查看占io较大的正在运行的session

 SELECT se.sid,

       se.serial#,

       pr.SPID,

       se.username,

       se.status,

       se.terminal,

       se.program,

       se.MODULE,

       se.sql_address,

       st.event,

       st.p1text,

       si.physical_reads,

       si.block_changes 

  FROM v$session se,

       v$session_wait st,

       v$sess_io si,

       v$process pr

 WHERE st.sid=se.sid 

   AND st.sid=si.sid

   AND se.PADDR=pr.ADDR

   AND se.sid>6

   AND st.wait_time=0 

   AND st.event NOT LIKE '%SQL%'

 ORDER BY physical_reads DESC

对检索出的结果的几点说明:

1、我是按每个正在等待的session已经发生的物理读排的序,因为它与实际的IO相关。

2、你可以看一下这些等待的进程都在忙什么,语句是否合理?

  Select sql_address from v$session where sid=;

  Select * from v$sqltext where address=;

执行以上两个语句便可以得到这个session的语句。

你也以用alter system kill session 'sid,serial#';把这个session杀掉。

3、应观注一下event这列,这是我们调优的关键一列,下面对常出现的event做以简要的说明:

abuffer busy waitsfree buffer waits这两个参数所标识是dbwr是否够用的问题,与IO很大相关的,当v$session_wait中的free buffer wait的条目很小或没有的时侯,说明你的系统的dbwr进程决对够用,不用调整;free buffer wait的条目很多,你的系统感觉起来一定很慢,这时说明你的dbwr已经不够用了,它产生的wio已经成为你的数据库性能的瓶颈,这时的解决办法如下:

a.1增加写进程,同时要调整db_block_lru_latches参数

示例:修改或添加如下两个参数

  db_writer_processes=4

  db_block_lru_latches=8

a.2开异步IOIBM这方面简单得多,hp则麻烦一些,可以与Hp工程师联系。

bdb file sequential read,指的是顺序读,即全表扫描,这也是我们应该尽量减少的部分,解决方法就是使用索引、sql调优,同时可以增大db_file_multiblock_read_count这个参数。

cdb file scattered read,这个参数指的是通过索引来读取,同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。

dlatch free,与栓相关的了,需要专门调节。

e、其他参数可以不特别观注。

 

 

SMON: Parallel transaction recovery tried 引发的问题

 

 SMON: Parallel transaction recovery tried 这个一般是在具有在跑大数据量的 transaction的时候kill掉了进程而导致 smon 去清理 回滚段时导致的。

这个在业务高峰期的时候,如果发现这个,有可能导致 SMON 占用了 100% cpu 而导致 系统 hang 在那边。

即使你shutdown immediate ,oracle 也会等待 smon 清理完毕才能关机,而这个等待过程也许是漫长的。

如果你 shutdown abort,那么oracle会马上shutdown ,但是,当你startup的时候,有可能就会很慢,因为 smon 会接着清理 undo,这个等待过程也许是很漫长的:

— — — —————————————————————————————————— 

Completed: ALTER DATABASE   MOUNT

Thu Aug 26 22:43:57 2010

ALTER DATABASE OPEN

Thu Aug 26 22:43:57 2010 

Beginning crash recovery of 1 threads

Thu Aug 26 22:43:57 2010 

Started first pass scan

Thu Aug 26 22:43:57 2010

Completed first pass scan

 402218 redo blocks read, 126103 data blocks need recovery

Thu Aug 26 22:45:05 2010

Restarting dead background process QMN0

QMN0 started with pid=16

Thu Aug 26 22:45:19 2010

Started recovery at

 Thread 1: logseq 13392, block 381202, scn 0.0

Recovery of Online Redo Log: Thread 1 Group 3 Seq 13392 Reading mem 0

  Mem# 0 errs 0: /zxindata/oracle/redolog/redo03.dbf

Recovery of Online Redo Log: Thread 1 Group 1 Seq 13393 Reading mem 0

  Mem# 0 errs 0: /zxindata/oracle/redolog/redo01.dbf

Thu Aug 26 22:45:21 2010

Completed redo application 

Thu Aug 26 22:48:35 2010

Ended recovery at

 Thread 1: logseq 13393, block 271434, scn 2623.1377219707

 126103 data blocks read, 115641 data blocks written, 402218 redo blocks read

Crash recovery completed successfully 

________________________________________________

看红色标注的那个,等待了 3 分钟才做完 recovery。

那如何才能让它快呢,metalink(238507.1 ) 有给出一些做法:

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

1. Find SMON's Oracle PID:

Example:

SQL> select pid, program from v$process where program like '%SMON%';

       PID PROGRAM

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

         6 oracle@stsun7 (SMON) 

2. Disable SMON transaction cleanup:

SVRMGR> oradebug setorapid 

SVRMGR> oradebug event 10513 trace name context forever, level 2 

3. Kill the PQ slaves that are doing parallel transaction recovery. 

You can check V$FAST_START_SERVERS to find these.

4. Turn off fast_start_parallel_rollback:

alter system set fast_start_parallel_rollback=false; 

If SMON is recovering, this command might hang, if it does just control-C out of it.  You may need to try this many times to get this to complete (between SMON cycles).

5. Re-enable SMON txn recovery:

SVRMGR> oradebug setorapid 

SVRMGR> oradebug event 10513 trace name context off 

——————————————————————————————————

以上的思路主要是要把 SMON 并行 recovery 的功能给改成非并行,主要

是 fast_start_parallel_rollback 这个参数的作用。

There are cases where parallel transaction recovery is not as fast as serial transaction recovery, because the pq slaves are interfering with each other. This depends mainly on the  type of changes that need to be made during rollback and usually may happen when rolling back INDEX Updates in parallel. 

 

参考至:http://hi.baidu.com/%CC%D8%B0%AE%C0%B6%C1%AB%BB%A8/blog/item/9af29302b820fab22eddd439.html

如有错误,欢迎指正

 

Kill session

 alter system kill session 'sid,serial#' ;

被kill掉的session,状态会被标记为killed,Oracle会在该用户下一次touch时清除该进程.

我们发现当一个session被kill掉以后,该session的paddr被修改,如果有多个session被kill,那么多个session

SQL> select saddr,sid,serial#,paddr,username,status from v$session where username is not null;

SADDR           SID    SERIAL# PADDR    USERNAME                       STATUS

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

542E0E6C         11        314 542B70E8 EYGLE                          INACTIVE

542E5044         18        662 542B6D38 SYS                            ACTIVE

 

 

SQL> alter system kill session '11,314';

 

System altered.


版权声明:本站内容全部来自于腾讯微信公众号,属第三方自助推荐收录。《oracle 常用SQL查询(三)——ORACLE锁的管理》的版权归原作者「东面而视」所有,文章言论观点不代表Lambda在线的观点, Lambda在线不承担任何法律责任。如需删除可联系QQ:516101458

文章来源: 阅读原文

相关阅读

关注东面而视微信公众号

东面而视微信公众号:LookToTheEast_China

东面而视

手机扫描上方二维码即可关注东面而视微信公众号

东面而视最新文章

精品公众号随机推荐