还不算晕的专栏

有时候在关闭数据库时，发出shutdown immediate;命令后一直未关闭，查看ALERT日志，在等待一段时间后日志中有提示：SHUTDOWN: waiting for active calls to complete.原因是有些进程无法被PMON进程清理，导致SHUTDOWN时无法关闭而HANG住。==》根据观察，在ORACLE10G及以上版本，会是如下提示：Activ

1.Buffer cache中的LRU链表概念：oracle在hash chain中未搜索到所需要的buffer时，ORACEL 服务进程会发出I/O调用，到磁盘的数据文件中读取相应数据块--除了直接路径读外，此时会将数据块的内容拷贝到buffer cache 内存中--同时会构造一个buffer header。在将数据块拷贝到buffer cache中时，假如buffer cache是空的，直接拿一个空的内存数据块来用即可。但是如果buffer cache中的内存数据块全都被用掉了，没有空的内存数据

SGA中Latch 的分类和查询SGA中Latch分两类：（1）愿意等的LATCH(willing-to_wait)（2）不愿意等 immediateCBC 多个BH组成 Cache Buffer Chain (CBC)CBC latch出现的原因：1.CBC latch保护不同的链表、不同BH2.CBC latch保护同一链表下同一BH例如：CBC Latch的查

X$BH    SYS用户可查询buffer header数据,可以从数据库的数据字典表中查询得到,这张字典表就是x$bh,其中的bh就是指buffer headers,每个buffer在x$bh中都存在一条记录.buffer header中存储每个buffer容纳的数据块的文件号,块地址,状态等重要信息,根据这些信息,结合dba_extents视图,可以很容易地找到每个buffer对应的

这个过程中可以发现和推断：比如进程A在BH上加buffer pin 独占锁时，此时CBC latch已经释放，在高并发环境下，此时如有进程B获取CBC latch，在hash chain上找到BH，准备加锁时，发现bh上已经加了独占锁，就发生了buffer busy waits要注意的是Buffer pin 上的共享锁不会阻塞独占锁，独占锁会阻塞独占锁--即当前读时，再有进程来当前读。独占锁也会阻塞共享锁--即当前读阻塞一致性读

服务器进程在扫描LRU主列时，将脏块移动到LRUW列。当扫描到一个阀值（10G/11G是40%- _db_block_max_scan_pct参数决定）时会停止扫描同时通知DBWR写脏块-写脏块完后的块重新挂载到辅助LRU列，就得到了空闲buffer。DBWR进程写脏块完成前，服务器进程等待空闲buffer时出现free buffer waits等待事件

1.working set与Latch:cache buffers lru chain：每个working set都具有它自己的一组LRU和LRUW链表（LRU和LRUW链表总是成对出现的）。ORACLE为了提高buffer cache性能（大内存），使用了多个working set每个working set都由一个名为“Latch:cache buffers lru chain”的latch来保护，每一个lru latch对应一个working set。而每个被加载到buffer cache的bu

buffer header：每一个数据块在被读入buffer cache时，都会先在buffer cache中构造一个buffer header，buffer header与数据块一一对应。buffer header包含的主要信息有：1） 该数据块在buffer cache中实际的内存地址。就是上图中的虚线箭头所表示的意思。2） 该数据块的类型，包括data、segment header、undo header、undo block等等。3） 该buffer header所在的hash chain，是

1.检查点概念--chkpoint检查点是一个数据库事件，存在的意义在于减少崩溃恢复crash recovery时间.检查点事件由后台进程CKPT触发，当检查点发生时，CKPT通知DBWR进程将脏数据库dirtybuffer写出到数据文件上，更新数据文件头及控制文件上的检查点信息。数据文件头的SCN是CHECKPOINT SCN.

1.CBC latch产生的原理：一次逻辑读时CBC latch锁及Buffer pin锁的获取和释放过程如下：1.加Latch X2.进入hash chain，在相应的BH上加Buffer pin S (0-->1)3.释放Latch X4.进行逻辑读--也就是通过BH中的buffer adderss找到数据块在内存中真实位置 ---假如读了1MS5.加Latch X6.释放Buffer pin S (1-->0) 0:没锁 1:共享锁 2:独占锁7.释放Latch X

1.为什么要使用buffer cache？？？buffer cache就是一块含有许多数据块的内存区域，这些数据块主要都是数据文件里的数据块内容的拷贝。从buffer cache中读取一个数据块一般需要100ns左右，从一般的存储硬盘中读取一个数据块需要10ms；所以大概算一下，从内存中读取数据块比从硬盘中快近十万倍。故oracle在读取数据块时，先在buffer cache中查找，如

Buffer Header结构图及简介图1：buffer header：每一个数据块在被读入buffer cache时，都会先在buffer cache中构造一个buffer header，buffer header与数据块一一对应。buffer header包含的主要信息有：1） 该数据块在buffer cache中实际的内存地址。就是上图中的虚线箭头所表示的意思。

数据读取之逻辑读简单解析--BUFFER CACHE一、实验数据准备--查出一条数据的ROWID,及FILE_ID,BLOCK_ID等信息BYS@ bys3>select rowid,test.* from test where rownum=1;ROWID              OBJECT_NAME   OBJECT_ID STATUS------------------

从

就以上图为例，文字描述分析一下前台进程发出查询语句时获取所需数据块的过程:注：本文不涉及SQL语句的解析部分、客户端与服务器交互等，只涉及buffer cache。这里的物理读是非直接路径读、非大表全表扫描--此点最后会有介绍。如果发出的是更新语句，只是在buffer pin上所加的锁为X独占锁，其它步骤基本一致。本文的例子只读取了一个数据块。

近期遭遇了多次客户数据库无法关闭的问题了，数据库无法关闭，一般是关闭时有事务需要回滚（可能是客户端或者JOB等）或者是关闭时使用错误关闭参数（如忘加参数默认是NORMAL）或者关闭时有其它原因。因此分享一下关闭数据库步骤的脚本，按照此脚本进行关闭数据库，基本上可以回避无法关闭问题；即使遇到无法关闭，使用kill关闭进程来关闭实例，也很少会造成数据损坏或数据丢失。--------------

在Linux中配置hugepage可以提高oracle的性能，减少oracle sga的页交换，类似于aix中的lagepage。为什么 使用大页？LINUX内存的默认块大小是4K如果SGA为：128Gselect 128*1024*1024/4 from dual;33554432个（三千多万），select 128*1024/2 from dual; 65536个每个内

最近遇到个LINUX系统内存比较大，未开 HugePages，业务有变化导致ORACLE连接数剧增至上千个，PageTables达到上百G，导致内存不足系统HANG住的案例。  因此需要开启 HugePages，操作系统是OEL6以上的。LINUX的以下版本:Red Hat Enterprise Linux 6, SUSE Linux Enterprise Server 11, and Ora

关于服务器进程与用户进程概念及v$session/V$PROCESS视图简介 ，详见：http://blog.csdn.net/q947817003/article/details/16922457本文根据性能分析的一般思路来进行：先看OS资源，确定CPU/内存消耗最多的进程，从进程找到会话，再查看会话详细信息：包括会话类型、执行的SQL等等。各种查询1.查当前会话SIDBYS

解析分为硬解析和软解析和软软解析，SQL语句第一次解析时必须进行硬解析还有一种是结果集缓存—无解析，详见：。 一句话说明硬解析与软解析的区别是：硬解析=需要生成执行计划   软解析=不需要生成执行计划在Oracle中存在两种类型的SQL语句，一类为DDL语句，不共享使用，也就是每次执行都需要进行硬解析。还有一类就是DML语句，会进行硬解析或软解析。硬解析变成软解析：绑定变量

Library cache简介Library cache最主要的功能就是存放用户提交的SQL语句，SQL语句相关的解析树（解析树也就是对SQL语句中所涉及到的所有对象的展现），执行计划，用户提交的PL/SQL程序块（包括匿名程序块，存储过程，包，函数等）以及它们转换后能够被Oracle执行的代码等，为了对这些内存结构进行管理，library cache中还存放了很多控制结构，包括lock,pi

SubPool技术及优势：从Oracle 9i开始，Shared Pool可以被分割为多个子缓冲池（SubPool）进行管理，以提高并发性，减少竞争。Shared Pool的每个SubPool可以被看作是一个Mini Shared Pool，拥有自己独立的Free List、内存结构以及LRU List、shared pool latch。同时Oracle提供多个Latch对各个子缓冲

ORA-4031错误在报ORA-4031错误的时候，有可能使用下面的SQL语句查看，发现可用的内存还是足够大的，    SQL> select POOL,NAME,BYTES from v$sgastat where NAME='free memory';     事实上，在Oracle发出4031错误之前，已经释放了不少recreatable类型的chunk了，因此会产生很多可用内存

--------未完待续生成执行计划的过程：编译器：分为三部分：2.优化器:--包括三个部分查询转换器RBO-->CBO，目前是CBO ，optimizer_mode--ALL_ROWS参数值，适合OLTP。FIRST_ROWS_N适合分页，OLAP。 查询转化器：视图合并--视图时直接用视图SQL语句对应表做基表进行连接。谓词推进，子查询非嵌套化--相关子查询；O

先来张大图：结合上图来说明一下解析的各个步骤涉及的锁。软解析、硬解析、软软解析区别的简单说明：为了将用户写的sql文本转化为oracle认识的且可执行的语句，这个过程就叫做解析过程。解析分为硬解析和软解析，SQL语句第一次解析时必须进行硬解析一句话说明硬解析与软解析的区别是：硬解析=需要生成执行计划   软解析=不需要生成执行计划在Oracle中存在两种类型

latch:library cache --desc v$librarycache;用于保护hash bucket.library cache lock保护HANDLE。library cache pin保护library cache object--LCO.从10G开始，library cache lock和library cache pin被MUTEX部分取代。暂时不讨论MUT

字典缓冲区： dictionary cache，也叫row cache;用于保存数据字典信息：如表空间相关信息、用户权限、objects信息、histogram信息等。字典缓冲区在大小无法直接调整，只能通过调整共享池大小来调整字典缓冲区大小。SYS@ bys3>select pool,name ,bytes/1024/1024 MB from v$sgastat where name

实验思路：1.数据库OPEN,，做DML操作不提交，查看检查点。2.SHUTDOWN ABORT并重启到MOUNT并查询检查点3.DUMP控制文件查看CHECKPOINT_CHANGE#/RBA4.DUMP数据文件查看CHECKPOINT_CHANGE#/RBA，与DUMP控制文件对比5.DUMP REDO日志文件，查看、对比CHECKPOINT_CHANGE#/RBA6.

LGWR,DBWR,SMON,PMON,CKPT是必需的五个后台进程。ARCH是最重要的可选后台进程。最重要的六个进程：1.LGWR重做日志写进程，LOG write 负责将重做日志缓冲区记录顺序写入重做日志文件。LGWR在下列情况下将重做日志缓冲区记录（内存）顺序写入重做日志文件（外存）中5种情况：某个事务被提交时，重做日志缓冲区中变化记录超过1M，当重做日志缓冲区中所存记录

如果动态参数文件损坏如何解决？应使用到数据库搜索应用参数文件的顺序。例子一：如果因错误设置动态参数文件中的参数导致数据库重启动时无法启动实例实验内容如下：修改参数并保存至SPFILE，关闭并重启数据库，出错。新建一个e:＼init.ora文件，首先指定原动态参数文件位置，并在下一行把错误的参数修正。因为如果参数重复设置，后读取的参数将取代先前的设置。故新参数要在指定SP

删除数据库方法1：使用DBCA图形化界面来进行。方法2：使用如下命令--LINUX系统下三条命令：SYS@bys1>startup mount exclusiveORACLE instance started.Total System Global Area  631914496 bytesFixed Size                  1338364 by

手工建库完成后，数据库中默认只有以下账户：手工建库步骤参考：http://blog.csdn.net/q947817003/article/details/16337611SQL> show userUSER is "SYSTEM"SQL> select username,account_status from dba_users;USERNAME

首先是应对ORACLE_SID,DB_NAME,存放数据文件、REDO日志、控制文件等的目录进行规划。如我的实验中：ORACLE_SID=bys3，DB_NAME为bys3，数据文件、REDO日志、控制文件均存放在/u01/oradata/bys3/实验如下:1.设置ORACLE_SID可以通过.bash_profile里查看--更改未退出会话时需要source .bash_pro

数据库实例：实例是由操作系统中的一组内存区和一系列的操作系统进程组成，数据库则是指Oracle保存数据的一系列物理结构和逻辑结构，用户在访问Oracle数据库时主要是在与实例打交道，由实例访问数据库，并返回相应的操作结果。最简单的Oracle数据库结构是由一个实例和一个数据库组成，不过对于RAC(或OPS)架构的Oracle数据库，一个数据库会对应多个实例。在Oracle数据库，实

1.监听及tnsnames.ora正常，普通用户使用服务名可以登陆数据库。[oracle@orale admin]$ cat tnsnames.ora mypl =  (DESCRIPTION =    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.22.55)(PORT = 1521))    (CONNECT_DATA =

1.关闭数据库的四个模式：shutdown   immediate;    不允许新连接，断开所有连接，ORACLE将用户未提交数据自动 回滚，强制检查点和关闭文件，重启后用户需要重新输入未提交的数据。最常用。shutdown   abort;              相当于关电源，直接关闭。在数据库重新启动时需要进行实例恢复。shutdown      normal;

使用SPFILE启动，如果想把初始化参数恢复为系统默认值，使用类似这样的语句：alter system reset db_create_file_dest ;这个语句修改的是SPFILE中的条目。从实验中执行两次重置参数的语句后的出错提示也可以验证。1.更改参数BYS@bys1>show parameter db_create_fileNAME                

源址：http://www.eygle.com/archives/2007/01/oracle_granule_size.html在《深入浅出Oracle》一书的P110页，关于Oracle的Granule我有这样一段描述:自9i开始，Oracle引入新的初始化参数db_cache_size;该参数定义主Block Size(db_block_size定义的块大小)的default

checkpoint的目的减少数据库实例恢复的时间;让内存中的脏数据及时的写到磁盘上;在安全关闭数据库时，保证所有提交的数据被写到磁盘上。ckpt进程本身只完成两件工作：1，执行检查点和更新控制文件和数据文件2，将脏缓存块写入数据文件的任务交给DBWR进程完成CKPT发送CHECKPOINT信号的触发条件：1. log_checkpoint_timeout时间达到2

一、控制文件多镜像---即多个控制文件存放在不同的位置使用静态参数文件添加或移动控制文件方法：1.利用数据字典V$CONTROLFILE来获取现有控制文件名字2.正常关闭ORACLE数据库，将新控制文件名添加到参数文件的CONTROL_FILES参数中，使用操作系统的复制命令复制现有控制文件到指定位置。3.重新启动数据库，利用数据字典V$CONTROLFILE来验证新控制文