oracle常见等待事件及处理方法

我们可以通过视图v$session_wait来查看系统当前的等待事件，以及与等待事件相对应的资源的相关信息

看书笔记db file scattered read DB ,db file sequential read DB,free buffer waits,log buffer space,log file switch,log file sync

我们可以通过视图v$session_wait来查看系统当前的等待事件，以及与等待事件相对应的资源的相关信息，从而可确定出产生瓶颈的类型及其对象。v$session_wait的p1、p2、p3告诉我们等待事件的具体含义，根据事件不同其内容也不相同，下面就一些常见的等待事件如何处理以及如何定位热点对象和阻塞会话作一些介绍。

<1> db file scattered read DB 文件分散读取(太多索引读,全表扫描-----调整代码,将小表放入内存)

这种情况通常显示与全表扫描相关的等待。当全表扫描被限制在内存时，它们很少会进入连续的缓冲区内，而是分散于整个缓冲存储器中。如果这个数目很大，就表明该表找不到索引，或者只能找到有限的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端（cold end），所以应尽量存储较小的表，以避免一次又一次地重复读取它们。

==================================================

该类事件的p1text=file#,p1是file_id，p2是block_id,通过dba_extents即可确定出热点对象(表或索引)

select owner,segment_name,segment_type

from dba_extents

where file_id = &file_id

and &block_id between block_id and block_id + &blocks - 1;

==================================================

<2> db file sequential read DB 文件顺序读取(表连接顺序不佳-----调整代码,特别是表连接)

这一事件通常显示单个块的读取(如索引读取)。这种等待的数目很多时，可能显示表的连接顺序不佳，或者不加选择地进行索引。对于大量事务处理、调整良好的系统，这一数值大多是很正常的，但在某些情况下，它可能暗示着系统中存在问题。你应当将这一等待统计量与Statspack 报告中的已知问题（如效率较低的SQL）联系起来。检查索引扫描，以保证每个扫描都是必要的，并检查多表连接的连接顺序。DB_CACHE_SIZE 也是这些等待出现频率的决定因素。有问题的散列区域（Hash-area）连接应当出现在PGA 内存中，但它们也会消耗大量内存，从而在顺序读取时导致大量等待。它们也可能以直接路径读／写等待的形式出现。

=================================================== 该类事件的p1text=file#,p1是file_id，p2是block_id,通过dba_extents即可确定出热点对象(表或索引)

select owner,segment_name,segment_type

from dba_extents

where file_id = &file_id

and &block_id between block_id and block_id + &blocks - 1;

==================================================

<3> free buffer waits 释放缓冲区等待(增大DB_CACHE_SIZE,加速检查点,调整代码)

这种等待表明系统正在等待内存中的缓冲，因为内存中已经没有可用的缓冲空间了。如果所有SQL 都得到了调优，这种等待可能表示你需要增大DB_BUFFER_CACHE。释放缓冲区等待也可能表示不加选择的SQL 导致数据溢出了带有索引块的缓冲存储器，没有为等待系统处理的特定语句留有缓冲区。这种情况通常表示正在执行相当多数量的DML（插入／更新／删除），并且数据库书写器(DBWR)写的速度不够快，缓冲存储器可能充满了相同缓冲器的多个版本，从而导致效率非常低。为了解决这个问题，可能需要考虑增加检查点、利用更多的DBWR 进程，或者增加物理磁盘的数量。

<4> buffer busy waits 缓冲区忙等待(BUFFER热块)

这是为了等待一个以非共享方式使用的缓冲区，或者正在被读入缓冲存储器的缓冲区。缓冲区忙等待不应大于1%。检查缓冲等待统计部分（或V$WAITSTAT）:

A、如果等待处于字段头部，应增加自由列表（freelist）的组数，或者增加pctused到pctfree 之间的距离。

B、如果等待处于回退段（undo）头部块，可以通过增加回滚段(rollback segment)来解决缓冲区的问题；

C、如果等待处于回退段（undo）非头部块上，就需要降低驱动一致读取的表中的数据密度,或者增大DB_CACHE_SIZE；

D、如果等待处于数据块，可以将数据移到另一数据块以避开这个"热"数据块、增加表中的自由列表或使用LMT表空间；

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

为了防止与数据块相关的缓冲忙等待，也可以使用较小的块：在这种情况下，单个块中的记录就较少，所以这个块就不是那么"繁忙"。在执行DML(插入/更新/删除)时,Oracle DBWR 就向块中写入信息，包括所有对块状态"感兴趣"的用户(感兴趣的事务表，ITL)。为减少这一

区域的等待，可以增加initrans，这样会在块中创建空间，从而使你能够使用多个ITL槽。你也可以增加该块所在表中的pctfree(当根据指定的initrans 建立的槽数量不足时，这样可以使ITL 信息数量达到maxtrans 指定的数量）。

<6> enqueue

enqueue 是一种保护共享资源的锁定机制。该锁定机制保护共享资源，如记录中的数据，以避免两个人在同一时间更新同一数据。enqueue 包括一个排队机制，即FIFO(先进先出)排队机制。注意：Oracle 的latch 机制不是FIFO。Enqueue 等待通常指的是ST enqueue、HW enqueue、TX4 enqueue 和TM enqueue。

A、ST enqueue 用于空间管理和字典管理的表空间的分配。利用LMT，或者试图对区域进行预分配，或者至少使下一个区域大于有问题的字典管理的表空间。

B、HW enqueue 与段的高水位标记一起使用；手动分配区域可以避免这一等待。

C、TX4 enqueue是最常见的enqueue 等待，通常是以下三个问题之一产生的结果:

第一个问题是唯一索引中的重复索引，需要执行提交（commit）/回滚（rollback）操作来释放enqueue。

第二个问题是对同一位图索引段的多次更新。因为单个位图段可能包含多个行地址(rowid),所以当多个用户试图更新同一段时,你需要执行提交或回滚操作,以释放enqueue。

第三个问题，也是最可能发生的问题是多个用户同时更新同一个块。如果没有自由的ITL槽，就会发生块级锁定。通过增大initrans 和/或maxtrans以允许使用多个ITL槽，或者增大表上的pctfree 值，就可以很轻松地避免这种情况。

D、TM enqueue 在DML 期间产生，以避免对受影响的对象使用DDL。如果有外来关键字，一定要对它们进行索引，以避免这种常见的锁定问题。

<7> log buffer space 日志缓冲空间(写REDO慢-----增大log_buffer,redo log file放

到快速磁盘上)

当日志缓冲(log buffer)写入重做日志(redo log)的速度比LGWR 的写入速度慢，或者是当日志转换(log switch)太慢时，就会发生这种等待。为解决这个问题，可以增大日志文件的大小，或者增加日志缓冲器的大小，或者使用写入速度更快的磁盘。甚至可以考虑使用固态磁盘，因为它们的速度很高。

<8> log file switch 日志文件转换(归档慢-----增加或者扩大重做日志)

有两种情况：

A、log file switch (archiving needed)

当日志切换的时候由于日志组循环使用了一圈但日志归档还没有完成，通常是io有严重问题，可增大日志文件和增加日志组，调整log_archive_max_processes

B、log file switch (checkpoint incomplete)

当日志切换的时候由于日志组循环使用了一圈但将被使用的日志组中的checkpoint还没有完成造成，通常是io有严重问题，可增大日志文件和增加日志组

<9> log file sync 日志文件同步(提交太频繁----批量提交)

当用户commit的时候通知lgwr写日志但lwgr正忙，造成的可能原因是commit太频繁或者lgwr一次写日志时间太长（可能是因为一次log io size 太大），可调整_log_io_size，结合log_buffer,使得(_log_io_size*db_block_size)*n = log_buffer,这样可避免和增大log_buffer引起冲突;放置日志文件于高速磁盘上

<10> library cache pin

该事件通常是发生在先有会话在运行PL/SQL,VIEW,TYPES等object时,又有另外的会话执行重新编译这些object,即先给对象加上了一个共享锁,然后又给它加排它锁,这样在加排它锁的会话上就会出现这个等待。P1,P2可与x$kglpn和x$kglob表相关

X$KGLOB (Kernel Generic Library Cache Manager Object)

X$KGLPN (Kernel Generic Library Cache Manager Object Pins)

-- 查询X$KGLOB,可找到相关的object,其SQL语句如下

(即把V$SESSION_WAIT中的P1raw与X$KGLOB中的KGLHDADR相关连)

select kglnaown,kglnaobj from X$KGLOB

where KGLHDADR =(select p1raw from v$session_wait

where event='library cache pin')

-- 查出引起该等待事件的阻塞者的sid

select sid from x$kglpn , v$session

where KGLPNHDL in

(select p1raw from v$session_wait

where wait_time=0 and event like 'library cache pin%')

and KGLPNMOD <> 0

and v$session.saddr=x$kglpn.kglpnuse

-- 查出阻塞者正执行的SQL语句

select sid,sql_text

from v$session, v$sqlarea

where v$session.sql_address=v$sqlarea.address

and sid=<阻塞者的sid>

这样,就可找到"library cache pin"等待的根源，从而解决由此引起的性能问题。

<11> library cache lock

该事件通常是由于执行多个DDL操作导致的,即在library cache object上添加一个排它锁

后,又从另一个会话给它添加一个排它锁,这样在第二个会话就会生成等待。可通过到基表x$kgllk中查找其对应的对象。

-- 查询引起该等待事件的阻塞者的sid、会话用户、锁住的对象

select b.sid,https://www.sodocs.net/doc/3c16668646.html,er_name,a.kglnaobj

from x$kgllk a , v$session b

where a.kgllkhdl in

(select p1raw from v$session_wait

where wait_time=0 and event = 'library cache lock')

and a.kgllkmod <> 0

and b.saddr=a.kgllkuse

当然也可以直接从v$locked_objects中查看，但没有上面语句直观根据sid可以到v$process中查出pid，然后将其kill或者其它处理。

<5> latch free (等待LATCH FREE)

latch是一种低级排队机制(它们被准确地称为相互排斥机制),用于保护系统全局区域(SGA)中共享内存结构。latch 就像是一种快速地被获取和释放的内存锁。latch 用于防止共享内存结构被多个用户同时访问。如果latch 不可用，就会记录latch 释放失败。大多数latch 问题都与以下操作相关：不能使用邦定变量（库缓存latch）、重复生成问题（重复分配latch）、缓冲存储器竞争问题（缓冲器存储LRU 链），以及缓冲存储器中的"热"块（缓冲存储器链）。也有一些latch 等待与bug（程序错误）有关，如果怀疑是这种情况，可以检查MetaLink 上的bug 报告。

该事件的热点对象可通过以下语句查找，其中&2值是v$session_wait中的P1RAW，x$bh 中的字段Hladdr表示该block buffer在哪个cache buffer chain latch 上，可以通过

v$latch_children定位哪些segment是热点块。

=================================================== select a.hladdr, a.file#, a.dbablk, a.tch, a.obj, b.object_name

from x$bh a, dba_objects b

where (a.obj = b.object_id or a.obj = b.data_object_id)

and a.hladdr = &2

union

select hladdr, file#, dbablk, tch, obj, null

from x$bh

where obj in

(select obj from x$bh

where hladdr = &2

minus

select object_id from dba_objects

minus

select data_object_id from dba_objects)

and hladdr = &2

order by 4;

==================================================== ***Latch 问题及可能解决办法

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

* Library Cache and Shared Pool (未绑定变量---绑定变量,调整shared_pool_size)

每当执行SQL或PL/SQL存储过程,包,函数和触发器时,这个Latch即被用到.Parse操作中此Latch也会被频繁使用.

* Redo Copy (增大_LOG_SIMULTANEOUS_COPIES参数)

重做拷贝Latch用来从PGA向重做日志缓冲区拷贝重做记录.

* Redo Allocation (最小化REDO生成,避免不必要提交)

此Latch用来分配重做日志缓冲区中的空间,可以用NOLOGGING来减缓竞争.

* Row Cache Objects (增大共享池)

数据字典竞争.过度parsing.

* Cache Buffers Chains (_DB_BLOCK_HASH_BUCKETS应增大或设为质数)

"过热"数据块造成了内存缓冲链Latch竞争.

* Cache Buffers Lru Chain (调整SQL，设置DB_BLOCK_LRU_LATCHES,或使用多个缓冲区池)

扫描全部内存缓冲区块的LRU(最近最少使用)链时要用到内存缓冲区LRU链Latch.太小内存缓冲区、过大的内存缓冲区吞吐量、过多的内存中进行的排序操作、DBWR速度跟不上工作负载等会引起此Latch竞争。

<12> db file parallel write

与DBWR进程相关的等待,一般代表了I/O能力出现了问题. 通常与配置的多个DBWR进程或者DBWU的I/O slaves个数有关.当然也可能意味着设备上存在着I/O竞争

<13> db file single write

表示在检查点发生时与文件头写操作相关的等待.通常与检查点同步数据文件头时文件号的紊乱有关.

<14> direct path read 和direct path write

表示与直接I/O读相关的等待.当直接读数据到PGA内存时,direct path read 出现.这种类型的读请求典型地作为:排序IO(为排序不能在内存中完成的时候),并行Slave查询或者预先读请求等. 通常这种等待与I/O能力或者I/O竞争有关.

<15> free buffer inspected

表示在将数据读入数据调整缓存区的时候等待进程找到足够大的内在空间通常这类等待表示数据调整缓存区偏小.

<16> library cache load lock

表示在将对象装载到库高速缓存时出现了等待.这种事件通常代表着发生了负荷尔蒙很重的语句重载或者装载,可能由于SQL语句没有共享或者共享池区域编小造成的.

<17> log file parallel write

表示等待LGWR向操作系统请求I/O开始直到完成IO.在触发LGWR写的情况下如3秒、1/3、1MB、DBWR写之前可能发生.这种事件发生通常表示日志文件发生了I/O竞争或者文件所在的驱动器较慢

<18> log file single write

表示写日志文件头块时出现了等待.一般都是发生在检查点发生时.

<19> transaction

表示发生了一个阻塞回滚操作的等待

<20> undo segment extension

表示在等待回滚段的动态扩展.这表示可能事务量过大,同时也意味着可能回滚段的寝大小不是最优,MINEXTENTS设置得偏小.考虑减少事务,或者使用最小区数更大的回滚段.

Oracle常见错误诊断

内容摘要：Oracle的这类错误在ORALCE的文档中有具体说明，但原因及措施说明不具体，本文当着重说明如何解决这类错误。

1、ORA-12571、ORA-03113、ORA-03114、ORA-01041

特征:客户端(代理或应用服务器)有时报这类断连错误

原因:假如偶然出现一次，则可能为网络原因或用户异常中止，假如经常出现则为客户端与服务端的字符集不一致。

措施:假如偶然出现，可在服务端的协议配置文件PROTOCOL.ORA中增加一行

TCP.NODELAY=YES;

假如经常出现，则为客户端与服务端字符集不一致或网络原因。

客户端的字符集在注册表里定义: HKEY__LOCAL__MACHINE/SOFTWARE/ORACLE/NLS__LANG

在客户端注册表中的TCP参数项中设置TCPMAXDATARETRANSMITIONS=20。

2、ORA-01000

特征:达到会话答应的最大游标数

原因:达到会话答应的最大游标数

措施:有两种解决方法:

(1)在初始化文件INIT.ORA文件中增加OPEN_CURSORS的数量，一般要求大于200。

(2)在应用级，与开发工具有关，例如设置MAXOPEN_CURSORS等。

3、ORA-01545

特征:某个回滚段不可用

原因:(1)当使回滚段ONLINE时，但回滚段不可用，例如回滚段所在表空间OFFLINE;

(2) 当使回滚段ONLINE时，但回滚段已ONLINE，例如回滚段被使用两次，典型的案例如OPS方式时，回滚段不能公有;

(3)删除回滚段时，回滚段中有活动的事务;

措施:(1)确保回滚段可

(2)从初始化文件INIT.ORA的参数ROLLBACK)SEGMENTS中删除指定的回滚段。

(3)可以将回滚段所在表空间删除，取消UNDO事务

4、ORA-0165x

特征:表空间没有足够的空间供分配

原因:表空间已满;存储参数不合理，NEXT太小;没有连续的区间

措施:假如表空间已满，则需为表空间增加文件;假如存储参数不合理，则需增加INITIAL 和NEXT;假如没有连续的区间，需要合并空闲的表空间。

查看空间碎片用DBA_FREE_SPACE

5、ORA-01555

特征:当前会话无法读到以前版本的数据

原因:原因很多，主要原因有下列:回滚段太小、太少;回滚段冲突;交叉提交(FETCH_ACROSS)

措施:增加回滚段数量;

6、ORA-04031

特征:共享池内存区内存不够，或产生内存碎片

原因:当试图装载一个大包时或执行一个较大的存储过程时，而共享池没有连续的内存空间。

措施:假如是内存不够，则增加SHARE)POOL_SIZE;

假如是内存碎片，执行alter system flush share_pool

7、ORA-04091

特征:触发器工作不正常

原因:一个行触发读取或修改变化的表(正在修改、插入)时，产生这种错误。

措施:检查触发器脚本，保证引用完整性

8、ORA-01242、ORA-01113

特征:介质故障导致数据库宕机

原因:介质故障。

措施:检查硬件故障;修改dbshut脚本，将其中的STARTUP命令修改为: Startup open recover

alter database open

Oracle数据库buffer busy wait等待事件

当会话意图访问缓冲存储器中的数据块，而该数据块正在被其它会话使用时产生buffer busy waits事件。其它会话可能正在从数据文件向缓冲区存储器度曲同样的数据块，或正在缓冲存储器中对其进行修改。 为了确保读取器会话拥有与获得所有更改或无更改的数据块一致的映像，正在修改该数据块的会话在其标题中标记一个标志，让其他会话知道有一个更改正在进行而等候更改的的完成。 视图v$waitstat不是OWI的组件，但其为没一类缓冲区提供了有用的等待统计。遭遇buffer busy等待事件最常见的缓冲区类为块、段标题、撤消块、撤消标题。 显示一个查询v$waitstat视图的采样输出： 具体示例如下： SELECT * FROM V$waitstat WHERE COUNT>0; CLASS COUNT TIME ------------------ ---------- ---------- data block 4170082 1668098 segment header 116 98 undo header 916 1134 undo block 2087 1681 1、等待参数 buffer wait busy的等待参数描述如下： P1 在Oracle 8及其以后版本的数据库里，P1显示询问数据块驻留的绝对文件号。 P2 进程需要访问的实际块号。 P3 在Oracle10g以前的版本中，着是表示等待原因的数字。Oracle在内河代码中在 多个地方用不同的原因码提交。该原因码取决于版本。 2、等待时间 100厘秒或1秒。 · Oracle会话正在等待钉住一个缓冲区。必须在读取或修改缓冲区前将它钉住。在任何

数据库(Oracle)运维工作内容及常用脚本命令

数据库（Oracle）运维工作内容及常用脚本命令2013-08-09 0个评论来源：LHDZ_BJ的专栏 收藏我要投稿数据库（Oracle）运维工作内容及常用脚本命令 1、系统资源状况： --内存及CPU资源 --linux,solaris,aix vmstat 5 --说明： 1）观察空闲内存的数量多少，以及空闲内存量是否稳定，如果不稳定就得想办法来解决，怎么解决还得看具体情况，一般可以通过调整相关内存参数来解决，各种操作系统输出指标、解释及内存调整参数及方法不完全一样； 2)观察CPU资源利用情况，首先，需要观察CPU上运行的任务数，也就是vmstat输出中位于第一列上的指标，如果该指标持续大于CPU核心数，应该引起注意；如果该指标持续大于CPU核心数的两倍，那么应该引起重视；如果持续为CPU 核心数的多倍，系统一般会出现应用可感知的现象，必须立刻想办法解决。当然，在观察该指标的同时，还要结合CPU利用率的指标情况，如：用户使用百分比,系统使用百分比,空闲百分比等指标，如果空闲百分比持续低于20%，应该引起注意；如果持续低于10%，应该引起重视；如果持续为0，系统一般会出现应用可感知的现象，应该立刻想办法解决问题； 3）CPU用户使用百分比和系统使用百分比的比例，也是应该注意的。一般来说，在一个状态正常的系统上，用户使用百分比应该比系统使用百分比大很多，几倍到十几倍甚至更高，如果系统使用百分比持续接近用户使用百分比，甚至大于用户使用百分比，说明系统的状态是不正常的，可能是硬件或者操作系统问题，也可能是应用问题。 --IO状况 --linux,solaris iostat -dx 5 --aix iostat 5 --说明：

Oracle 常见的33个等待事件

Oracle 常见的33个等待事件 一．等待事件的相关知识： 1.1 等待事件主要可以分为两类，即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件。 1). 空闲等待事件指ORACLE正等待某种工作，在诊断和优化数据库的时候，不用过多注意这部分事件。 2). 非空闲等待事件专门针对ORACLE的活动，指数据库任务或应用运行过程中发生的等待，这些等待事件是在调整数据库的时候需要关注与研究的。 在Oracle 10g中的等待事件有872个，11g中等待事件1116个。我们可以通过v$event_name 视图来查看等待事件的相关信息。 1.2 查看v$event_name视图的字段结构： SQL> desc v$event_name; 名称是否为空? 类型 ----------------------------------------- -------- --------------- EVENT# NUMBER EVENT_ID NUMBER NAME VARCHAR2(64) PARAMETER1 VARCHAR2(64) PARAMETER2 VARCHAR2(64) PARAMETER3 VARCHAR2(64) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) 1.3 查看等待事件总数： SQL> select count(*) from v$event_name; COUNT(*) ---------- 1116 1.4 查看等待事件分类情况： /* Formatted on 2010/8/11 16:08:55 (QP5 v5.115.810.9015) */ SELECT wait_class#, wait_class_id, wait_class,

Oracle笔试常见选择题

Oracle笔试常见选择题A 1、答案（每题10分，有多选）： 12345678910 2、 1、在EMPLOYEES 和DEPARTMENTS表里检查下列数据。EMPLOYEES LAST_NAME DEPARTMENT_ID SALARY Getz 10 3000 Davis 20 1500 King 20 2200 Davis 30 5000 Kochhar 5000 DEPARTMENT_ID DEPARTMENT_NAME 10 Sales 20 Marketing 30 Accounts 40 Administration 如果你想获得所有的employees，不管他们是否匹配部门表中的部门，那么下面选项中哪个查询语句是正确的？ A．SELECT last_name,department_name FROM employees,departments(+); B．SELECT last_name,department_name FROM employees JOIN departments(+); C．SELECT last_name,department_name FROM employees(+) e JOIN departments d ON(e.department_id = d.department_id); D．SELECT last_name,department_name FROM employees e RIGHT OUTER JOIN departments d ON (e.department_id = d.department_id); E．SELECT last_name,department_name FROM employees(+),departments ON (e.department_id = d.department_id); F．SELECT last_name,department_name FROM employees e LEFT OUTER JOIN departments d ON (e.department_id = d.department_id); 2、查看下列EMPLOYEES表的结构。

log file sync(日志文件同步) 与 Log file parallel write 等待事件

log file sync(日志文件同步) 与 Log file parallel write 等待事件 log file sync(日志文件同步)等待事件具有一个参数:buffer#。在Oracle Database 10g中，这种等待事件位于Commit等待下面。当处理log file sync等待事件时，注意下面的思想： ◎ log file sync 等待时间和事务中指(提交或回滚)相关 ◎当进程在log file sync事件上花费大量时间时，这通常表明过多的提交或短事务。 触发LGWR进程的条件有： 1. 用户提交 2. 有1/3重做日志缓冲区未被写入磁盘 3. 有大于1M的重做日志缓冲区未被写入磁盘 4. 3秒超时 5. DBWR 需要写入的数据的SCN大于LGWR记录的SCN，DBWR 触发LGWR写入。 触发DBWR进程的条件有： 1. DBWR超时，大约3秒 2. 系统中没有多余的空缓冲区来存放数据 3. CKPT 进程触发DBWR 由用户提交和回滚初始化的写入称为同步写入；其余的写入成为后台写入。log file sync 等待只和同步写入有关。换句话说，用户进程可能正在处理一个大型的事务并生成许多触发LGWR以执行后台写入的大量重做条目，但用户会话从来不需要等待后台写入的完成。然而，一旦用户会话提交或回滚它的事务且 _WAIT_FOR_SYNC参数是TRUE时，进程提交LGWR并在log file sync事件上等待LGWR将当前重做条目(包括提交标记)刷新到日志文件。在这种日志同步期间，LGWR进程在log file parallel write事件上等待同步写入的完成，同时用户会话在log file sync事件上等待同步进程的完成。 一旦进程进入log file sync等待，就有两种可能性。 一种可能性是LGWR在日志同步完成时提交前台进程时。 另一种情况是在等待已超时的时候(一般在1秒内)，在这个时刻，前台进程检查当前日志SCN(System Change Number,系统改变号)，确定它的提交是否已经传递到磁盘。如果是的话，进程继续处理，否则进程就重新进入等待。

美丽在等待中绽放,巧妙对待班级丢东西事件

美丽在等待中绽放 ——巧妙对待班级“丢东西”事件 说到班内出现的“丢东西”现象，每一个老师都非常的头疼，因为这样的问题处理起来特别棘手，处理轻了起不到作用，处理重了又会损伤学生的自尊心。可这样尴尬的事情却也难免会发生，我们班主任该如何应对呢？我想，对于一个孩子来说，拿别人的东西，多数是由于一时好奇、冲动，而班主任如果因此就将其视为“另类”甚至以“小偷”的名义严厉惩罚，这个学生可能会失去更多的朋友，甚至破罐破摔，这又怎能起到帮助学生的作用呢？ 我始终坚信面对问题班主任不是逃避责任放任自流，更不能对学生恶语相加，而应当采用正确的方法了解事情真相、剖析学生心理、运用班主任计谋、灵活的应对突发状况，才能够做到“知己知彼，百战不殆”。 面对犯错的学生，唯有宽容才能赢得理解，唯有尊重才会启迪心灵。为此我愿意等待学生美好心灵的回归，我愿给予给予学生最可贵的信任与鼓励。 记得我刚接班时，班内就发生了一件“学习机”丢失事件，事情发生在一个下午，下课铃声刚响，我班的一位男同学就急匆匆跑到我的面前说他的学习机找不到了。我当时一听非常生气，可转念一想既然事已发生，我们就要认真面对，这也是对同学们进行教育的一个契机。 于是，我首先安抚这位同学，老师一定会认真处理。然后细致的询问事情经过，最后了解到这学习机十分有可能是被同学拿了。此时我想为了学生的成长，既要找到学习机解决问题，又要对犯错误的学生一个警醒，还能够对全班同学起到教育作用。 我首先来到教室，让全班学生帮助寻找，给犯错误的学生一个弥补的机会。 但是过了十分钟仍然不见“学习机”的影子！看来这位学生正在做着激烈的思想斗争，还没有找到正确的方向，我的工作还要更进一步。 于是我请全班同学每人不署名写两句话给我，第一句话是对此事的看法，第二句话是将看到的细节写出来。我相信孩子的内心是最单纯的，犯错误的学生在写的过程肯定会露出蛛丝马迹，而普通同学也会因这次丢东西事件提高预防意识。 最后一节课，我再次来到班里，非常严肃的对同学们说：“老师的手中拿着同学们写得情况细节，但是老师并没有打开看，因为老师知道世上没有一个人不犯错误，但关键在于他是不是勇于承认错误，

Oracle 数据库日常巡检

Oracle 数据库日常巡检 阅读目录 ? 1. 检查数据库基本状况 ? 2. 检查Oracle相关资源的使用情况 ? 3. 检查Oracle数据库备份结果 ? 4. 检查Oracle数据库性能 ? 5. 检查数据库cpu、I/O、内存性能 ? 6. 检查数据库安全性 ?7. 其他检查 1. 检查数据库基本状况 包含：检查Oracle实例状态，检查Oracle服务进程，检查Oracle监听进程，共三个部分。 1.1. 检查Oracle实例状态 select instance_name,host_name,startup_time,status,database_status from v$instance; 其中“STATUS”表示Oracle当前的实例状态，必须为“OPEN”；“DATABASE_STATUS”表示Oracle当前数据库的状态，必须为“ACTIVE”。1.2. 检查Oracle在线日志状态 select group#,status,type,member from v$logfile; 输出结果应该有3条以上（包含3条）记录，“STATUS”应该为非“INVALID”，非“DELETED”。注：“STATUS”显示为空表示正常。 1.3. 检查Oracle表空间的状态 select tablespace_name,status from dba_tablespaces; 输出结果中STATUS应该都为ONLINE。 1.4. 检查Oracle所有数据文件状态 select name,status from v$datafile; 输出结果中“STATUS”应该都为“ONLINE”。或者： select file_name,status from dba_data_files; 输出结果中“STATUS”应该都为“AVAILABLE”。 1.5. 检查无效对象

oracle常见等待事件及处理方法

我们可以通过视图v$session_wait来查看系统当前的等待事件，以及与等待事件相对应的资源的相关信息 看书笔记db file scattered read DB ,db file sequential read DB,free buffer waits,log buffer space,log file switch,log file sync 我们可以通过视图v$session_wait来查看系统当前的等待事件，以及与等待事件相对应的资源的相关信息，从而可确定出产生瓶颈的类型及其对象。v$session_wait的p1、p2、p3告诉我们等待事件的具体含义，根据事件不同其内容也不相同，下面就一些常见的等待事件如何处理以及如何定位热点对象和阻塞会话作一些介绍。 <1> db file scattered read DB 文件分散读取(太多索引读,全表扫描-----调整代码,将小表放入内存) 这种情况通常显示与全表扫描相关的等待。当全表扫描被限制在内存时，它们很少会进入连续的缓冲区内，而是分散于整个缓冲存储器中。如果这个数目很大，就表明该表找不到索引，或者只能找到有限的索引。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端（cold end），所以应尽量存储较小的表，以避免一次又一次地重复读取它们。 ================================================== 该类事件的p1text=file#,p1是file_id，p2是block_id,通过dba_extents即可确定出热点对象(表或索引) select owner,segment_name,segment_type from dba_extents

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

一些常见的非空闲等待事件有: .. 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 % Total Event Waits Time (cs) Wt Time -------------------------------------------- ------------ ------------ ------- db file scattered read 26,877 12,850 52.94 db file parallel write 472 3,674 15.13 log file parallel write 975 1,560 6.43 direct path write 1,571 1,543 6.36 control file parallel write 652 1,290 5.31 ------------------------------------------------------------- 1）.. db file scattered read: DB文件分散读取。--一次读取多个块--可能full scan 这个等待事件很常见，经常在top5中出现，这表示，一次从磁盘读数据进来的时候读了多于一个block 的数据，而这些数据又被分散的放在不连续的内存块中，因为一次读进来的是多于一个block的。 通常来说我们可以认为是全表扫描类型的读，因为根据索引读表数据的话一次只读一个block，如果这个数字过大，就表明该表找不到索引，或者只能找到有限的索引，可能是全表扫描过多，需要检查sql是否合理的利用了索引，或者是否需要建立合理的索引。 当全表扫描被限制在内存时，它们很少会进入连续的缓冲区内，而是分散于整个缓冲存储器中。尽管在特定条件下执行全表扫描可能比索引扫描更有效，但如果出现这种等待时，最好检查一下这些全表扫描是否必要,是否可以通过建立合适的索引来减少对于大表全表扫描所产生的大规模数据读取。对于经常使用的小表，应该尽量把他们pin 在内存中，避免不必要的老化清除及重复读取。

Oracle常见问题及其解决方法(doc 10页)

Oracle常见问题及其解决方法(doc 10页)

iSQL*Plus URL:http://10.10.43.137:5560/isqlplus Enteprise Manager 10g Database Control URL: http://information:5500/em OracleDBConsoleorcl不能启动,报错误码2解决策略 解决策略一： 修改你的主机参数文件 修改一下: C:\WINDOWS\system32\drivers\etc下的host文件. 如果没有的话就自己加一个IP和你的计算机名对应,如果已有了就把你的IP地址和你的计算机名对应起来. 如: # copyright (c) 1993-1999 microsoft corp. # # this is a sample hosts file used by microsoft tcp/ip for windows. # # this file contains the mappings of ip addresses to host names. each # entry should be kept on an individual line. the ip address should # be placed in the first column followed by the corresponding host name. # the ip address and the host name should be separated by at least one # space. # # additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # for example: # # 102.54.94.97 https://www.sodocs.net/doc/3c16668646.html, # source server # 38.25.63.10 https://www.sodocs.net/doc/3c16668646.html, # x client host 127.0.0.1 localhost 10.10.43.137 information 解决策略二： 启动电脑，到登陆界面，电脑报有个服务启动失败，电脑没有新装软件，周六还没有问题，怎么突然报这个错误？于是到事件查看器中看看什么问题，显示是OracleDBConsoleorcl启动失败，到服务里一看，确实没有启动。手动启动一下，报错误码2 我装的是10g，于是到ORACLEproduct10.2.0db_1test_orclsysmanlog目录看一下log里写了什么，打开OracleDBConsoleorclsrvc.log. log最后记录的是: 日志让看emdbconsole.nohup文件，目录里没有这个文件呀。 手动执行一下emctl.bat，于是启动控制台，执行emctl.bat istart dbconsole，报错，ORACLE_SID 没有定义，打开emctl.bat看看，这里是定义环境变量的地方，其中已经设置了这些：if not defined REMOTE_EMDROOT （set ORACLE_HOME=Ec：oracleproduct10.2.0db_1）

如何调整io等待

本文主要介绍的是在出现了I/O竞争等待的时候如何去优化Oracle数据库。对Oracle数据库进行调整优化，基本上最终都可以归结到I/O调整上，因此，了解如何来优化Oracle数据库的I/O对于一个DBA来说就显得至关重要了。 一、Oracle数据库I/O相关竞争等待简介 当Oracle数据库出现I/O相关的竞争等待的时候，一般来说都会引起Oracle数据库的性能低下，发现数据库存在I/O相关的竞争等待一般可以通过以下的三种方法来查看Oracle数据库是否存在I/O相关的竞争等待： Statpack报告中在"Top 5 Wait Events"部分中主要都是I/O相关的等待事件。 数据库的等待事件的SQL语句跟踪中主要都是I/O相关的等待事件的限制。 操作系统工具显示存储数据库文件的存储磁盘有非常高的利用率。 数据库如果发现存在I/O竞争，那我们就必须要通过各种方法来调整优化Oracle数据库。在调优数据库的过程中，其中一个重要的步骤就是对响应时间的分析，看看数据库消耗的时间究竟是消耗在具体什么上面了。对于Oracle数据库来说，响应时间的分析可以用下面公式来计算： Response Time = Service Time + Wait Time Service Time是指'CPU used by this session'的统计时间。 Wait Time是指所有消耗在等待事件上的总的时间。 如果我们使用性能调整的工具(如statpack)来调整数据库的时候，评测的则是所有响应时间中各个部分的相对影响，并且应该根据消耗的时间的多少来调整影响最严重的部分。 因为等待事件有很多，因此我们还需要去判定哪些是真的很重要的等待事件，很多调优工具比如说statpack都是列出最重要的等待事件，statpack工具的报告中的重要的等待事件都是包含在一个叫Top 5

第八章 事件取样法

第八章事件取樣法 壹、概論 事件(event)是事件取樣法的重點。 ˙事件取樣法是一種正式的觀察法，是利用事件的發生，以定義感興趣的特定事件並在觀察的情境中等待期出現。 ˙在觀察幼兒的脈絡中，事件是指可能歸屬於特定類別中的行為。 ˙例如爭吵這個事件是由一些可觀察的特定行為，像是大聲說話、各種臉部表情或為了爭奪玩具的所有權而爭論所構成。 ˙事件取樣法只選擇一種取樣，也就是特定的行為或事件。 ˙可以選擇任何一種事件，如吵架、社會互動，或依賴行為來作觀察。你先針對此事件用你可以接受的例子來定義這個事件的行為，然後找個能觀察到幼兒的位置，然後等待事件的發生並記錄。 ˙應該盡可能詳細的從頭到尾記下行為的整個過程，才能做為日後推論的詳實資料。可選擇下列任何一種方法來記錄: (1)編碼設計(coding scheme) (2)敘事描述法(narrative descriptions) (3)前兩種方法合併用 ˙事件取樣法式非常類似敘事描述法，只是事件取樣法是不考慮不符合特定事件定義中的行為。 ˙事件取樣法並不在意行為發生的時間，它也不會被必須只記錄在預定的時段內發生的行為所受限。 一、開放性對閉鎖性 ˙事件取樣法是屬於閉鎖性的方法。但是，如果能詳細的敘述並保存原始資料的話，那就可以符合開放性的條件。 二、選擇性程度 ˙因為事件取樣法中所要觀察紀錄的特定事件，是事先就經過選擇的，所以其選擇性程度極高。 三、推論的必要性 ˙事件取樣法在一開始的推論是必要的。推論是指對某一行為或一連串的行為，是否屬於某事件的特定類別所作的任何判斷。 四、優點 ˙對行為及行為的脈絡有豐富及詳細敘述的可能性。 ˙事件取樣法也具實用性，尤其適用於紀錄那些經常發生的行為。 ˙事件取樣法是「由行為和脈絡的自然單位，構成觀察的範圍」。這些「自然行為」(natural units)，可讓你研究行為及其脈絡間的關係。 ˙事件取樣法的最後一項優點是能結合敘述描述法和編碼設計，因此，它具備編

数据库常见等待事件

等待事件的相关知识 1.1 等待事件主要可以分为两类，即空闲(IDLE)等待事件和非空闲(NON-IDLE)等待事件。 1). 空闲等待事件指ORACLE正等待某种工作，在诊断和优化数据库的时候，不用过多注意这部分事件。 2). 非空闲等待事件专门针对ORACLE的活动，指数据库任务或应用运行过程中发生的等待，这些等待事件是在调整数据库的时候需要关注与研究的。 在Oracle 10g中的等待事件有872个，11g中等待事件1116个。我们可以通过v$event_name 视图来查看等待事件的相关信息。1.2 查看v$event_name视图的字段结构 SQL> desc v$event_name; 名称是否为空? 类型 ----------------------------------------- -------- --------------- EVENT#NUMBER EVENT_ID NUMBER NAME VARCHAR2(64) PARAMETER1VARCHAR2(64) PARAMETER2VARCHAR2(64) PARAMETER3VARCHAR2(64) WAIT_CLASS_ID NUMBER WAIT_CLASS#NUMBER

WAIT_CLASS VARCHAR2(64) 1.3 查看等待事件总数 11gr2: SQL> select count(*) from v$event_name; COUNT(*) ---------- 1116 10gr2 rac: sys@ORCL> select count(*) from v$event_name; COUNT(*) ---------- 889 10gr2: SQL> select count(*) from v$event_name; COUNT(*) ---------- 874 1.4 查看等待事件分类情况

ORA-04021等待锁定对象

ORA-04021等待锁定对象时超时 2009-11-20 04:52 起因：我在执行存储过程时，又对它重新更新代码然后执行，就是执行中修改了后又执行它。原理： 一：首先先介绍下~library cache librarycache最主要的功能就是存放用户提交的SQL语句、SQL语句相关的解析树（解析树也就是对SQL语句中所涉及的所有对象的展现）、执行计划、用户提交的PL/SQL程序块（包括匿名程序块、存储过程、包、函数等）以及它们转换后能够被Oracle执行的代码等。为了对这些内存结构进行管理，library cache中还存放了很多控制结构，包括lock、pin、dependencytable等。 在library cache中存放的所有信息单元都叫做对象（object），这些对象可以分成两类：一类叫存储对象，也就是上面所说的数据库对象。它们是通过显式的 SQL语句或PL/SQL程序创建出来的，如果要删除它们，也必须通过显式的SQL命令进行删除。这类对象包括表、视图、索引、包、函数等；另一类叫做过渡对象，也就是上面所说的用户提交的SQL语句或者提交的PL/SQL匿名程序块等。这些过渡对象是在执行SQL语句或PL/SQL程序的过程中产生的，并缓存在内存里。如果实例关闭则删除，或者由于内存不足而被交换出去，从而被删除。 这些对象不能在他们被使用的时候改变,他们在被使用的时候会被一种library locks and pins的机制锁住.一个会话中,需要使用一个对象,会在该对象上先得到一个library lock(null, shared or exclusive模式的)这是为了,防止其他会话也访问这个对象(例如:重编译一个包或视图的时候,会加上exclusive类型的锁)或更改对象的定义.总的来说，library cache pin和library cache lock都是用于share pool的并发控制的。pin和lock 都可以看作是一种锁。 locks/pins会在SQL语句执行期间一直保持,在结束的时候才释放。 每个想使用或修改已经locked/pin的对象的SQL语句,将会等待事件'library cache pin'或'library cache lock'直到超时. 超时,通常发生在5分钟后,然后SQL语句会出现ORA-4021的错误.如果发现死锁,则会出现ORA-4020错误。 二：library cache pin和library cache lock成因 lock主要有三种模式: Null,share(2),Exclusive(3).在读取访问对象时,通常需要获取

oracle测试题

1. 首先:oracle 实验第一种:手工联机全库备份, 备份周期:每周做全库备份，每天做增量备份。 第一步：开启归档模式后，做全库备份 第二步：查看数据文件的所有信息，因为生产环境中不一定在一个目录下的第三步:cp数据文件

第四步：结束备份，模拟故障 第五步：恢复

第二种自动化数据库备份RMAN（生产环境中常用的备份方式）选择RMAN备份的理由： ①RMAN操作简单，自动化功能强 ②RMAN可以忽略备份后未发生改变的block，即做增量备份 不管什么备份,必须在归档模式下.所以先开归档。 第一步：开启归档模式，用rman连接本地数据库 第二步：用RMAN开始备份

第三步：创建表模拟故障，数据库不能打开了 第三步：恢复，先在RMAN 中restore恢复到备份时间点，再recover database，查日志恢复到当前。所有的备份恢复信息都存放在控制文件中。

2.保证数据完整性的手段? Oracle数据库的完整性有三个：实体完整性、参考完整性和自定义完整性。它的实现是通过5五个约束来完成的。 五个约束如下： 主键primary key 非空not null 唯一unique 检查check 外键foreign key 3.undo空间不够用怎么办（磁盘没空间） undo表空间不断扩大问题的原因： 1有较大的事务量让oracle undo 自动扩展，产生过度占有磁盘空间的情况。

2有较大事务没有收缩或者没有提交所导致。 解决方法： 第一步：查看还原表空间所在磁盘是否使用率过高，及linux 系统哪个磁盘处于比较空闲的状态 第二步：在oracle 数据库中查看所有表空间的占用率；查询undo表空间的路径。 第三步：检查还原表空间的segment的状态的信息

Oracle11g等待事件解析

10.3 Wait Events Statistics The V$SESSION, V$SESSION_WAIT, V$SESSION_HISTORY, V$SESSION_EVENT, and V$SYSTEM_EVENT views provide information on what resources were waited for, and, if the configuration parameter TIMED_STATISTICS is set to true, how long each resource was waited for. See Also: ?"Setting the Level of Statistics Collection" for information about STATISTICS_LEVEL settings ?Oracle Database Reference for a description of the V$ views and the Oracle wait events Investigate wait events and related timing data when performing reactive performance tuning. The events with the most time listed against them are often strong indications of the performance bottleneck. The following views contain related, but different, views of the same data: ?V$SESSION lists session information for each current session. It lists either the event currently being waited for, or the event last waited for on each session. This view also contains information about blocking sessions, the wait state, and the wait time. ?V$SESSION_WAIT is a current state view. It lists either the event currently being waited for, or the event last waited for on each session, the wait state, and the wait time. ?V$SESSION_WAIT_HISTORY lists the last 10 wait events for each current session and the associated wait time. ?V$SESSION_EVENT lists the cumulative history of events waited for on each session. After a session exits, the wait event statistics for that session are removed from this view. ?V$SYSTEM_EVENT lists the events and times waited for by the whole instance (that is, all session wait events data rolled up) since instance startup.

oracle的TM锁T锁知识完全普及

o r a c l e的T M锁、T X锁知识完全普及锁概念基础 数据库是一个多用户使用的共享资源。当多个用户并发地存取数据时，在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据，破坏数据库的一致性。 加锁是实现数据库并发控制的一个非常重要的技术。当事务在对某个数据对象进行操作前，先向系统发出请求，对其加锁。加锁后事务就对该数据对象有了一定的控制，在该事务释放锁之前，其他的事务不能对此数据对象进行更新操作。 在数据库中有两种基本的锁类型：排它锁（ExclusiveLocks，即X锁）和共享锁（ShareLocks，即S锁）。当数据对象被加上排它锁时，其他的事务不能对它读取和修改。加了共享锁的数据对象可以被其他事务读取，但不能修改。数据库利用这两种基本的锁类型来对数据库的事务进行并发控制。 Oracle数据库的锁类型 根据保护的对象不同，Oracle数据库锁可以分为以下几大类：DML锁（datalocks，数据锁），用于保护数据的完整性；DDL锁（dictionarylocks，字典锁），用于保护数据库对象的结构，如表、索引等的结构定义；内部锁和闩（internallocksandlatches），保护数据库的内部结构。 DML锁的目的在于保证并发情况下的数据完整性，。在Oracle数据库中，DML锁主要包括TM锁和TX锁，其中TM锁称为表级锁，TX锁称为事务锁或行级锁。 当Oracle执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁，并将实际锁定的数据行的锁标志位进行置位。这样在事务加锁前检查TX 锁相容性时就不用再逐行检查锁标志，而只需检查TM锁模式的相容性即可，大大提高了系统的效率。TM锁包括了SS、SX、S、X等多种模式，在数据库中用0－6来表示。不同的SQL操作产生不同类型的TM锁。 在数据行上只有X锁（排他锁）。在Oracle数据库中，当一个事务首次发起一个DML语句时就获得一个TX锁，该锁保持到事务被提交或回滚。当两个或多个会话在表的同一条记录上执行DML语句时，第一个会话在该条记录上加锁，其他的会话处于等待状态。当第一个会话提交后，TX锁被释放，其他会话才可以加锁。 当Oracle数据库发生TX锁等待时，如果不及时处理常常会引起Oracle数据库挂起，或导致死锁的发生，产生ORA-60的错误。这些现象都会对实际应用产生极大的危害，如长时间未响应，大量事务失败等。 悲观封锁和乐观封锁 一、悲观封锁 锁在用户修改之前就发挥作用： Select..forupdate（nowait)

Oracle常见等待事件说明

Oracle的等待事件是衡量Oracle运行状况的重要依据及指标。等待事件的概念是在Oracle7.0.1.2中引入的，大致有100个等待事件。在Oracle 8.0中这个数目增加到了大约150个，在Oracle8i中大约有200个事件,在Oracle9i中大约有360个等待事件。主要有两种类别的等待事件，即空闲(idle)等待事件和非空闲(non-idle)等待事件。 空闲事件指Oracle正等待某种工作,在诊断和优化数据库的时候,我们不用过多注意这部分事件。 常见的空闲事件有: ? dispatcher timer ? lock element cleanup ? Null event ? parallel query dequeue wait ? parallel query idle wait - Slaves ? pipe get ? PL/SQL lock timer ? pmon timer- pmon ? rdbms ipc message ? slave wait ? smon timer ? SQL*Net break/reset to client ? SQL*Net message from client ? SQL*Net message to client ? SQL*Net more data to client ? virtual circuit status ? client message 非空闲等待事件专门针对Oracle的活动,指数据库任务或应用运行过程中发生的等待，这些等待事件是我们在调整数据库的时候应该关注与研究的。 一些常见的非空闲等待事件有: ? db file scattered read

Oracle数据库无响应故障处理方式

Oracle数据库无响应故障处理方式 Oracle数据库无响应故障处理方式 无响应的故障现象一般有以下几种： 1.Oracle的进程在等待某个资源或事件 这种现象一般可以从V$SESSION_WAT、V$LATCH、V$LATCHHOLDER 等动态视图中检查进程正在等待的资源或事件，而被等待的资源或 事件，一直都不能被获取，甚至是很长时间都不可获得。如果这个 正在等待的进程持有了其他的资源，则会引起其他的进程等待，这 样就很可能引起实例中大范围的会话发生等待。由于进程在等待资 源或事件时，通常都处于SLEEP状态，消耗的CPU资源非常少(在等 待latch时要稍微多消耗一些CPU资源)，所以从OS来看，CPU的 消耗并不高，甚至是非常低。 这种因为等待而引起的个别进程Hang，相对比较容易处理。 2.OracleProcessSpins 所谓Spin，就是指Oracle进程中的代码在执行某个过程时，陷 入了循环。在V$SESSION视图中，往往可以看到Hang住的会话，一 直处于“ACTIVE”状态。对于这样的会话，用“altersystemkillsession‘sid,serial#’”命令也不能完全断开 会话，会话只能被标记为“killed”，会话会继续消耗大量的CPU。进程Spins由于是在做循环，CPU的消耗非常大，从OS上明显可以 看到这样的进程，通常会消耗整个CPU的资源。 而对于这样的Hang住的会话，处理起来相对比较复杂，并且为 了从根本上解决问题，需要超过DBA日常维护所需要的技能。 从故障范围来看，无响应故障可以分为以下几种情况： 1.单个或部分会话(进程)Hang住

ORACLE数据库日常维护手册(最全+最实用)

ORACLE 日常维护手册 查看数据库版本 SELECT*FROM V$VERSION; 查看数据库语言环境 SELECT USERENV('LANGUAGE')FROM DUAL; 查看ORACLE实例状态 SELECT INSTANCE_NAME,HOST_NAME,STARTUP_TIME,STATUS,DATABASE_STATUS FROM V$INSTANCE; 查看ORACLE监听状态 lsnrctl status 查看数据库归档模式 SELECT NAME,LOG_MODE,OPEN_MODE FROM V$DATABASE; 查看回收站中对象 SELECT OBJECT_NAME,ORIGINAL_NAME,TYPE FROM RECYCLEBIN; 清空回收站中对象 PURGE RECYCLEBIN; 还原回收站中的对象 FLASHBACK TABLE"BIN$GOZUQZ6GS222JZDCCTFLHQ==$0" TO BEFORE DROP RENAME TO TEST;

闪回误删除的表 FLASHBACK TABLE AAA TO BEFORE DROP; 闪回表中记录到某一时间点 ALTER TABLE TEST ENABLE ROW MOVEMENT; FLASHBACK TABLE TEST TO TIMESTAMP TO_TIMESTAMP('2009-10-15 21:17:47','YYYY-MM-DD HH24:MI:SS'); 查看当前会话 SELECT SID,SERIAL#,USERNAME,PROGRAM,MACHINE,STATUS FROM V$SESSION; 查看DDL锁 SELECT* FROM DBA_DDL_LOCKS WHERE OWNER ='FWYANG'; 检查等待事件 SELECT SID, https://www.sodocs.net/doc/3c16668646.html,ERNAME, EVENT, WAIT_CLASS, T1.SQL_TEXT FROM V$SESSION A, V$SQLAREA T1 WHERE WAIT_CLASS <>'Idle' AND A.SQL_ID = T1.SQL_ID; 检查数据文件状态 SELECT FILE_NAME,STATUS FROM DBA_DATA_FILES; 检查表空间使用情况 SELECT UPPER(F.TABLESPACE_NAME) "表空间名", D.TOT_GROOTTE_MB "表空间大小(M)", D.TOT_GROOTTE_MB - F.TOTAL_BYTES "已使用空间(M)", TO_CHAR(ROUND((D.TOT_GROOTTE_MB -F.TOTAL_BYTES)/D.TOT_GROOTTE_MB *100, 2), '990.99') "使用比", F.TOTAL_BYTES "空闲空间(M)",