当会话意图访问缓冲存储器中的数据块，而该数据块正在被其它会话使用时产生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）运维工作内容及常用脚本命令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个等待事件 一．等待事件的相关知识： 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笔试常见选择题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(日志文件同步)等待事件具有一个参数: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 数据库日常巡检 阅读目录 ? 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. 检查无效对象
我们可以通过视图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页)
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.doczj.com/doc/8f11983504.html, # source server # 38.25.63.10 https://www.doczj.com/doc/8f11983504.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）
本文主要介绍的是在出现了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等待锁定对象时超时 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).在读取访问对象时,通常需要获取
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的状态的信息
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.
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运行状况的重要依据及指标。等待事件的概念是在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数据库无响应故障处理方式 无响应的故障现象一般有以下几种： 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 日常维护手册 查看数据库版本 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.doczj.com/doc/8f11983504.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)",