内部视图:interval view x$kvii 介绍

内部视图x$kvii

554078    kslerb    event range base
873    kslnbe    # of base events
285    kslnbesess    # of base events in session
382    kslltl    number of latches
2    ksbcpu_static    initial number of CPUs in the system
4096    kcbswc    DBWR max outstanding writes
1    kcbnwp    number of DBWR processes
204    kcbscw    DBWR write chunk
1    kctsat    true if Statically Allocated Thread
1    kctthr    THRead mounted by this instance – zero if none
1    ktsinm    sga shadow value of instance_number
0    rfragns    Global request id for site

其中kslltl为Oracle中父闩的数量,即kslltl=select count(*) from v$latch;

ksbcpu_static记录了当前cpu的内核总数。

kcbswc为Oracle单位时间内所能写出的最大块数Largest # blocks you can write at any given time)实际受限于物理写出能力。

kctthr为当前实例的线程号。

关于这些视图的研究仍有诸多不明确。

附Oracle kernel 层次:

Kernel Subsystems:

OPI Oracle Program Interface
KK Compilation Layer – Parse SQL, compile PL/SQL
KX Execution Layer – Bind and execute SQL and PL/SQL
K2 Distributed Execution Layer – 2PC handling
NPI Network Program Interface
KZ Security Layer – Validate privs
KQ Query Layer
RPI Recursive Program Interface
KA Access Layer
KD Data Layer
KT Transaction Layer
KC Cache Layer
KS Services Layer
KJ Lock Manager Layer
KG Generic Layer
KV Kernel Variables (eg. x$KVIS and X$KVII)
S or ODS Operating System Dependencies

关于Oracle中supplemental log的补充说明

在上一篇关于Oracle补全日志的介绍中漏写了关于最小补全日志(minimal supplemental log)与表级补全日志的关系;表级补全日志需要在最小补全日志打开的情况下才起作用,即若一个数据库没有开最小补全日志或之前drop supplemental log data操作则即便指定了表级补全日志,实际在重做日志输出的过程中描述的记录仍只记录rowid和相关列值。

打开最小补全日志的命令如下:

在上一篇关于Oracle补全日志的介绍中漏写了关于最小补全日志(minimal supplemental log)与表级补全日志的关系;表级补全日志需要在最小补全日志打开的情况下才起作用,即若一个数据库没有开最小补全日志或之前drop supplemental log data操作则即便指定了表级补全日志,实际在重做日志输出的过程中描述的记录仍只记录rowid和相关列值。

打开最小补全日志的命令如下:

Alter database add supplemental log data;

其次若如之前叙述的因表上的列数过多(超过200个),则应检查视图 dba_logstdby_not_unique, 该视图记录了在数据库中没有主键或没有唯一索引并且列非空的索引(tables in the primary database that do not have a primary key or unique index with NOT NULL columns)的表。如使用以下SQL:

select owner, table_name, bad_column

from dba_logstdby_not_unique

where table_name not in

(select table_name from dba_logstdby_unsupported);

TSMSYS    SRS$    Y
HTEST    TEST    N
HGET    GETMAXID    N
HGET    HUSER    N
SCOTT    BONUS    N
SCOTT    SALGRADE    N

其中bad_column列较为关键。若该字段为 Y,表示一个表列被使用大数据类型定义,例如CLOB或BLOB。sql apply尝试维护这些表,但是你必须要保证表中除这列外的其他列的单值性。就是说,注意,如果一个表中有两行除了LOB列外,其他的值完全相同,这样表 的改动就不能被逻辑备用数据库应用,sql apply会停止。N,表示表中包含足够的列信息,需要用来在逻辑备用数据库中维护表的。

针对前文叙述的在表上列较多的情况下(超过200个列),且不能添加主键和唯一非空索引的表,我们需要特别关注。但实际如果我们想了解一个段在一定段内产生的重做量却十分困难。(method :check  how much redo generated by one segment)

已知的研究方法例如logmnr工具,和dump redologs以及oradebug都无法提供足够的信息帮助统计。

仅有的方法是通过logmnr估算,v$logmnr_contents视图中记录的rbablk与rbabyte,为重做日志中的块偏移量(redo log中512byte为一个快)与字节偏移量,通过计算差值结合data_obj#列,可以大致估算某个段上一定时间内的重做量:

create table redo_analysis nologging as

select data_obj#,  oper, rbablk*512 + rbabyte curpos,

lead(rbablk*512+rbabyte,1,0) over (order by  rbasqn, rbablk, rbabyte)

nextpos

from

( select distinct data_obj#,  operation oper,

rbasqn, rbablk, rbabyte from v$logmnr_contents

order by rbasqn, rbablk, rbabyte );

select data_obj#, oper, obj_name, sum(redosize) total_redo

from

(

select data_obj#, oper, obj.name obj_name , nextpos-curpos-1 redosize

from redo_analysis redo1, sys.obj$ obj

where (redo1.data_obj# = obj.obj# or  redo1.data_obj# = obj.dataobj#)

and  nextpos !=0 — For the boundary condition

union all

select data_obj#, oper, ‘internal ‘ , nextpos-curpos  redosize

from redo_analysis redo1

where  redo1.data_obj#=0 and  redo1.data_obj# = 0

and nextpos!=0

)

group by data_obj#, oper, obj_name

order by 4

以上估算并不准确,在有手动切换(switch logfile)日志及其他特殊情况时误差较大。

apache中多域名使用同一个ip的方法

服务器仅有一个ip ,却需要服务多个域名(实际是多个网站的服务),例如你希望使用同一个台web服务器上同时运行www.example.com与www.example.net。

可在httpd.conf配置文件中(可能位于/etc/httpd/conf或/usr/local/apache/conf目录下),添加以下条目:

Server configuration

# Ensure that Apache listens on port 80
Listen 80

# Listen for virtual host requests on all IP addresses
NameVirtualHost *:80

<VirtualHost *:80>
DocumentRoot /www/example1
ServerName www.example.com

# Other directives here

</VirtualHost>

<VirtualHost *:80>
DocumentRoot /www/example2
ServerName www.example.org

# Other directives here

</VirtualHost>

apache会就用户访问的域名对应配置中的ServerName选择合适的web目录输出html代码。以上设置中第一项即ServerName www.example.com成为默认选项。若用户访问所指定的域名不符合所有条目时采用默认项,即指向www.example.com。

apache官方的文档: http://httpd.apache.org/docs/2.2/vhosts/examples.html

ORA-12500内存耗尽一例

3月8日下午发现主机130.31.1.234无法登录,尝试登录Oracle,系统返回ORA-12500错误(TNS:listener failed to start a dedicated server process)。可能引起该错误的原因有多种,包括以下:

Oracle服务进程使用的session或process数达到了参数设置的上限,导致无法再分配新的服务进程。

系统资源耗尽,Oracle在启动新进程时调用的系统调用fork函数因资源不足而出错。

AIX下sys0对象上的属性maxuproc代表用户可以使用的最大进程数,若用户进程数接近该设定值可能导致Oracle无法启动新进程。

因主机无法远程登录,故在晚间进行了重启。重启后查看Oracle告警日志发现记录:“skgpspawn failed:category = 27142, depinfo = 12, op = fork, loc = skgpspawn3”,该段信息表示模块skgpspawn在fork一个新进程是出现了错误;由此可以判断不是由于session或process数达到参数设置的上限,因为若是session或process数不足,Oracle应当显示地返回ORA-00018(maximum number of sessions exceeded)或ORA-00020(maximum number of processes (%s) exceeded)错误。

通过在主机上查看sys0对象属性,发现maxuproc参数的设置值达到了4096,故基本可以排除因该参数不当引起连接问题的可能性。

系统资源耗尽将导致Oracle监听器无法为新的连接分配新的服务进程,而老的服务进程上的内存资源等可能一直没有得到释放;statspack是Oracle9i中反映Oracle运行性能的工具,以JOB形式在后台运行,目前设置为每两小时运行一次快照。分析快照发现,在主机重启前最后一次快照为下午14:15分开始的,之后系统进入资源紧张阶段,Oracle无法分配新的JOB(j00n)进程,故最后的快照发生在系统出现问题之前。

分析快照内容,在12:06到14:15之间,数据库参数没有改动的记录,sga_max_size设置为10GB, pga_aggregate_target设置为4GB,考虑到Oracle在启用RAC特性后SGA的实际内存使用量将会超过sga_max_size的设置,故Oracle总的内存最大使用量应控制在20GB内。而目标主机的实际物理内存达到了64GB,且专业计费系统一直以来运行良好,故可以排除因Oracle内存参数设置不当,而造成了本次问题的出现。

进一步分析快照发现这一阶段内Oracle数据库高速缓冲的命中率buffer hit为55.90,这个值要较平时水平低很多,可以判断该阶段内数据库可能执行了一些不同于日常业务的操作,这些操作引起较大的物理读表现为缓冲池的命中率明显降低。分析等待事件可以发现,db file scattered read事件即数据库多块物理读是这一阶段的主要等待事件,进一步印证了上述的判断。

通过对数据库快照的分析,证实在连接问题发生之前的短暂时间内,在P6702实例上的确有过引起较大物理读的操作,但实际Oracle使用的内存受到sga_max_size与pga_aggregate_target参数的限制应控制在20GB的范围内,且专业计费系统数据库使用裸设备数据文件,不存在过度使用文件系统缓存的可能,故可以排除由Oracle数据库导致系统资源耗尽的可能性。

因为没有该阶段内系统内存使用量的日志文件,故无法了解到目标主机上当时其他服务的实际内存使用量,但可以排除是问题因Oracle引起的。

Oracle rac进阶管理专家指导系列文档

Session1

Session2

Session3

Session4

Session5

Session6

Session7

Session8

Oracle恢复目录的管理使用简要

I. 使用恢复目录存储RMAN备份记录

  1. Oracle 官方建议把恢复目录建议于独立的数据库中。如果把恢复目录与其他一些数据混杂在某库中,若该库失败则恢复目录一起丢失,这将导致恢复异常困难。
  2. 在恢复目录中登记某个库被称作注册(registration).可以在恢复目录中注册多个目标库。举例来说,你可以注册数据库 prod1,prod2,和prod3在一个单独的由用户catowner拥有的目录中,而该目录位于一个叫catdb的数据库中。 因为RMAN通过DBID即数据库的身份证来分辨各个库。每个在恢复目录中注册过的目标库都有一个唯一的DBID.
  3. 恢复目录主要包括以下RMAN的使用情况信息:

l  数据文件和归档日志的备份集和备份片

l  数据文件的拷贝

l  归档日志及其拷贝

l  目标库中的表空间和数据文件

l  储存的脚本

l  RMAN的永久性配置

  1. 恢复目录保存了目标库控制文件中重要的RMAN操作原数据。同步恢复目录保证与控制文件中当前信息同步。
  2. RMAN 创建快照控制文件,即临时控制文件,当每次需要做全局同步时。快照临时文件保证了RMAN同步时的一致性读。数据库服务进程保证同时只有一个快照临时文件的存在,这对于保证RMAN操作不受其他进程干扰是必要的。
  3. 丢失恢复目录将导致严重的恢复问题。如何备份恢复目录可参考一般数据库的备份方式。
  4. 关于恢复目录的兼容性,可以通过查询恢复目录用户模式下的rcver表了解参与恢复目录使用端的版本号,示例:
SQL> SELECT * FROM rcver;

VERSION
------------
08.01.05.00
09.00.01.00
10.02.01.00

只要是8i之后版本一般不存在兼容性问题。

II 管理恢复目录

创建恢复目录

管理恢复目录中的目标库记录

同步恢复目录

恢复目录模式下的控制文件管理

备份恢复目录

导入和导出恢复目录

增强恢复目录可用性

查询恢复目录视图

更新恢复目录

删除恢复目录

  1. 创建恢复目录,创建恢复目录分成三步:
  • 配置恢复目录所在数据库
  • 创建恢复目录拥有者
  • 创建恢复目录本身

配置恢复目录数据库

若使用恢复目录,RMAN要求维护恢复目录所在模式。恢复目录储存在当前模式的默认表空间中,注意SYS不能是恢复目录的拥有者。我们强烈建议恢复目录数据库使用归档模式。同时必须分配足够的空间给恢复目录所在模式,恢复目录所占用的空间取决于使用恢复目录的目标数据库的数量。适当地为恢复目录库规划容量是必要的。应当保证恢复目录库和目标数据库的不占用同一磁盘。

创建目录拥有者

在合理配置恢复目录库后,我们来创建目录拥有者

使用目录库上的SYS帐号登录

假定当前有一个tool表空间来保存目录

使用temp临时表空间为用户默认临时表空间

如下步骤:

     CONNECT SYS/oracle@catdb AS SYSDBA
 SQL> CREATE USER rman IDENTIFIED BY cat
       TEMPORARY TABLESPACE temp
       DEFAULT TABLESPACE tools
    QUOTA UNLIMITED ON tools;

同时我们要授予 recovery_catalog_owner 权限给用户,该角色拥有管理创建恢复目录的权限。

   SQL> GRANT RECOVERY_CATALOG_OWNER TO rman;

创建恢复目录

在创建恢复目录用户后,使用RMAN建立恢复目录,操作如下:

$ rman

RMAN> CONNECT CATALOG rman/cat@catdb   --以目录用户连接恢复目录库

RMAN> create catalog                         — 建议恢复目录

当然也可以指定使用的表空间:

RMAN> create catalog  tablespace users;

成功建立恢复目录后,可以查询目录下已经存在的目录使用的基表。

SQL>select table_name from user_tables;

2. 管理恢复目录中的目标库记录

ü  在恢复目录中注册目标数据库

ü  在恢复目录中注销目标数据库

ü  在恢复目录中重置数据库

ü  在恢复目录中移除已删除的记录

在恢复目录中注册目标数据库

首先确定恢复目录库已经打开,从目标库主机登录:

$ rman TARGET / CATALOG rman/cat@catdb

若目标库未启动,首先启动到加载模式:

RMAN> STARTUP MOUNT;

注册目标库:

RMAN> REGISTER DATABASE;

RMAN会自动在恢复目录中记录目标库的各种信息,将目标库控制文件中的

元信息复制到恢复目录中,可以使用以下命令确认注册情况:

RMAN> REPORT SCHEMA;

Report of database schema
File Size(MB)   Tablespace       RB segs Datafile Name
---- ---------- ---------------- ------- -------------------
1        307200 SYSTEM             NO    /oracle/oradata/trgt/system01.dbf
2         20480 UNDOTBS            YES   /oracle/oradata/trgt/undotbs01.dbf
3         10240 CWMLITE            NO    ...

在恢复目录中登记备份文件

若有备份文件未在控制文件或恢复目录中存在对应的记录,则需要登记该文件,此处的(control file 为目标数据库control file)。

示例:

RMAN> CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf';
RMAN> CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf',
     '/disk1/arch_logs/archive1_732.dbf';
RMAN> CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp';

在恢复目录中登记多个目标库

可以在一个恢复目录中注册多个目标库,前提是目标库的DBID唯一。

在恢复目录中注销目标库

可以使用命令: unregister database 在RMAN中注销目标数据库。当数据库被

注销,所有的RMAN记录都会丢失,所以要小心操作。

在恢复目录中移除已经删除的记录

在9i之后版本,RMAN在删除备份文件的同时会删除在恢复目录中的对应物记

录,而9i以前版本则只将对应物记录标志为delete.可以通过运行脚本

prgrmanc.sql来删除对应物记录,该脚本储存在($ORACLE_HOME/rdbms/admin)

录下。示例如下:

% sqlplus rman/cat@catdb
SQL> @?/rdbms/admin/prgrmanc.sql删过期备份信息

同步恢复目录

当恢复目录当前状态晚于数据库控制文件中的备份信息时,则需要使用同步恢复

目录,这种情况只会出现在一段时间使用恢复目录而一段时间不使用恢复目录的

情况下,造成的时间段差异。RMAN会在您做某些操作时自动完成同步,例如

Backup命令,当然你也可以手动同步: resync catalog .

管理控制文件

数据库参数CONTROL_FILE_RECORD_KEEP_TIME决定了控制文件中记录可能被复

用的最短自然天数,因此你保证恢复目录在此期间完成同步,否则可能控制文件

中的记录丢失,则需要手动登记备份文件。CONTROL_FILE_RECORD_KEEP_TIME有

效期内需要定期同步。

备份恢复目录

备份恢复目录数据库十分重要,若恢复目录数据库丢失则所有的备份信息将丢

失,导致恢复十分困难。

备份恢复目录数据库与一般的数据库没有大的区别,以下为注意事项:

恢复目录数据库因该运行在归档模式下

使用备份策略冗余量大于一

在不同的介质上备份

不使用恢复目录记录备份信息

使用控制文件自动备份,rman中可以自动完成

结构图:

catalog

更新恢复目录

若您使用的恢复目录版本低于使用的客户端,则您需要更新恢复目录。举例来说

当前您使用了8.1版的客户端RMAN,而恢复目录是8.0版本的,则需要更新。

当恢复目录版本高于您使用的客户端,则upgrade catalog报错。更新操作实例如

下:

sqlplus> connect sys/oracle@catdb as sysdba;
sqlplus> grant TYPE to rman;
% rman TARGET / CATALOG rman/cat@catdb
UPGRADE CATALOG;

recovery catalog owner is rman

enter UPGRADE CATALOG command again to confirm catalog upgrade

UPGRADE CATALOG;

recovery catalog upgraded to version 09.02.00
DBMS_RCVMAN package upgraded to version 09.02.00
DBMS_RCVCAT package upgraded to version 09.02.00






删除恢复目录

当恢复目录不在需要时可以在所在数据库中彻底删除目录结构和数据,删除将丢

失所有注册过的备份信息,操作要小心。示例操作:

% rman TARGET / CATALOG rman/cat@catdb

Issue the DROP CATALOG command twice to confirm:

DROP CATALOG;

recovery catalog owner is rman
enter DROP CATALOG command again to confirm catalog removal

DROP CATALOG;

延迟块清除介绍

在Oracle中数据锁(这里主要指TX类型行锁)实际上是数据的属性,存储在块首部,称之为事务槽(ITL)。COMMIT操作的职责包括释放块上的锁,实际的释放方式即清除块上相应的事务槽,但这里存在一个性能的考量。设想一个UPDATE大量数据的操作,因为执行时间较长,一部分已修改的块已被缓冲池flush out写至磁盘,当UPDATE操作完成执行COMMIT操作时,则需要将那些已写至磁盘的数据块重新读入,这将消耗大量I/O,并使COMMIT操作十分缓慢;为了解决这一矛盾,Oracle使用了延迟块清除的方案,对待存在以下情况的块COMMIT操作不做块清除:

在更新过程中,被缓冲池flush out写至磁盘的块

若更新操作涉及的块超过了块缓冲区缓存的10%时,超出的部分块。

虽然COMMIT放弃对这些块的块清除(block cleanout)操作,但COMMIT操作仍会修改回滚段的段头,回滚段的段头包括了段中的事务的字典,COMMIT操作将本事务转化为非ACTIVE状态。

当下一次操作如SELECT,UPDATE,INSERT或DELETE访问到这些块时可能需要在读入后完成块清除,这样的操作称之为块延迟清除(deferred block cleanout);块延迟清除通过事务槽上的回滚段号,槽号等信息访问回滚段头的事务字典,若事务不再活跃或事务过期则完成清除块上的事务槽,事务槽清除后继续执行相应的操作。

块延迟清除的影响在SELECT操作过程中体现的最为明显。总结来说块延迟清除是COMMIT操作的一个延续,始终是一种十分轻微的操作,且该种操作是行级的,不会使段(Segment)的属性有所改变。

certifies using for pic test

1

2

重做日志时间戳说明

首先创建一个包括序列号与时间戳的表,通过对该表插入当前时间戳并记录插入操作的开始时间,进行中时间,与结束时间,以便与重做日志中的时间戳对比。

表的定义如下:

create table tim (tn int,itime timestamp);

使用以下匿名块插入数据:

declare

stime timestamp;

dtime timestamp;

etime timestamp;

begin

for i in 1 .. 10 loop

stime := systimestamp;

insert into tim values (i, systimestamp);

etime := systimestamp;

select itime into dtime from tim where tn = i;

dbms_output.put_line(‘start time: ‘ || to_char(stime,’HH24:MI:SS:FF’) || ‘ doing time: ‘ ||

to_char(dtime,’HH24:MI:SS:FF’) || ‘ end time:’ || to_char(etime,’HH24:MI:SS:FF’));

dbms_lock.sleep(2.9);

commit;

end loop;

end;

其中stime,dtime,etime,分别记录了每次插入的开始时间,进行中时间,以及结束的时间,操作结束后输出以上时间,之后休眠2.9秒,COMMIT之后继续循环。该过程输出如下:

start time: 15:10:06:986235000 doing time: 15:10:06:987493000 end time:15:10:06:987962000

start time: 15:10:09:894372000 doing time: 15:10:09:894505000 end time:15:10:09:894738000

start time: 15:10:12:796921000 doing time: 15:10:12:797057000 end time:15:10:12:797293000

start time: 15:10:15:698497000 doing time: 15:10:15:698642000 end time:15:10:15:698856000

start time: 15:10:18:601077000 doing time: 15:10:18:601222000 end time:15:10:18:601451000

start time: 15:10:21:502664000 doing time: 15:10:21:502803000 end time:15:10:21:503044000

start time: 15:10:24:405294000 doing time: 15:10:24:405435000 end time:15:10:24:405673000

start time: 15:10:27:307828000 doing time: 15:10:27:307979000 end time:15:10:27:308193000

start time: 15:10:30:209477000 doing time: 15:10:30:209619000 end time:15:10:30:209865000

start time: 15:10:33:112033000 doing time: 15:10:33:112173000 end time:15:10:33:112397000

可以看到每次循环内开始时间,进行中时间,结束时间的差值很小,证明插入是在瞬间完成的。

之后我们查看tim表中的内容:

select tn,to_char(itime,‘HH24:MI:SS:FF’) ITIME ,dump(itime,16) HEX_ITIME from tim;

TN

ITIME

HEX_ITIME

1

15:10:06:987493

Typ=180 Len=11: 78,6d,6,e,10,b,7,3a,db,f2,88

2

15:10:09:894505

Typ=180 Len=11: 78,6d,6,e,10,b,a,35,51,10,28

3

15:10:12:797057

Typ=180 Len=11: 78,6d,6,e,10,b,d,2f,82,1f,e8

4

15:10:15:698642

Typ=180 Len=11: 78,6d,6,e,10,b,10,29,a4,6e,50

5

15:10:18:601222

Typ=180 Len=11: 78,6d,6,e,10,b,13,23,d5,eb,70

6

15:10:21:502803

Typ=180 Len=11: 78,6d,6,e,10,b,16,1d,f8,2a,38

7

15:10:24:405435

Typ=180 Len=11: 78,6d,6,e,10,b,19,18,2a,72,78

8

15:10:27:307979

Typ=180 Len=11: 78,6d,6,e,10,b,1c,12,5b,62,f8

9

15:10:30:209619

Typ=180 Len=11: 78,6d,6,e,10,b,1f,c,7e,88,38

10

15:10:33:112173

Typ=180 Len=11: 78,6d,6,e,10,b,22,6,af,9f,c8

ITIME即插入操作中的时间,HEX_ITIME为ITIME在数据块中的16进制存放格式,用以与重做日志中的16进制数据对比。

我们dump当前的重做日志,该日志包括了方才所做的DML操作:

alter system dump logfile ‘/u01/oradata/orcl/redo01.log’;

查看dump所产生的跟踪文件,可以发现以下记录:

REDO RECORD – Thread:1 RBA: 0x000026.0000000c.0010 LEN: 0x02a0 VLD: 0x0d

SCN: 0x0000.000b727b SUBSCN:  1 06/14/2009 15:10:09

CHANGE #1 TYP:1 CLS: 1 AFN:1 DBA:0x0040ebf2 OBJ:51447 SCN:0x0000.000b7279 SEQ:  1 OP:13.5

KTSFRBFMT (block format) redo: Segobjd: 0x0000c8f7 type: 1 itls: 2

CHANGE #2 TYP:0 CLS: 1 AFN:1 DBA:0x0040ebf2 OBJ:51447 SCN:0x0000.000b727b SEQ:  1 OP:13.6

KTSFRBLNK (block link modify) redo:  Opcode: LSET (lock set)

Next dba: 0x0040ebf3 itli: 0

CHANGE #3 TYP:0 CLS: 1 AFN:1 DBA:0x0040ebf2 OBJ:51447 SCN:0x0000.000b727b SEQ:  2 OP:13.6

KTSFRBLNK (block link modify) redo:  Opcode: LWRT (lock write)

Next dba: 0x00000000 itli: 0

CHANGE #4 TYP:0 CLS: 4 AFN:1 DBA:0x0040ebf1 OBJ:51447 SCN:0x0000.000b726a SEQ:  1 OP:13.7

KTSFRGRP (fgb/shdr modify freelist) redo:

Opcode: HWMMV (move hwm)

NBK: 1

Opcode: LUPD_LLIST (link a list)

Slot no: 0, Count: 1

Flag: = 1 xid or slot0 ccnt:  0x0000.000.00000001 Head:  0x0040ebf2 Tail:  0x0040ebf2

CHANGE #5 TYP:0 CLS: 1 AFN:1 DBA:0x0040ebf2 OBJ:51447 SCN:0x0000.000b727b SEQ:  3 OP:11.2

KTB Redo

op: 0x01  ver: 0x01

op: F  xid:  0x0009.02b.0000015d    uba: 0x00808df4.0163.24

KDO Op code: IRP row dependencies Disabled

xtype: XA flags: 0x00000000  bdba: 0x0040ebf2  hdba: 0x0040ebf1

itli: 1  ispac: 0  maxfr: 4863

tabn: 0 slot: 0(0x0) size/delt: 18

fb: –H-FL– lb: 0x1  cc: 2

null: —

col  0: [ 2]  c1 02

col  1: [11]  78 6d 06 0e 10 0b 07 3a db f2 88

在以上重做记录(REDO RECORD)的CHANGE #5中包含了插入TIMESTAMP “col  1: [11]  78 6d 06 0e 10 0b 07 3a db f2 88”即表中第一条数据的ITIME列为15:10:06:987493,而该条重做记录的时间戳为:15:10:09,要晚于插入的进行中时间,与插入结束时间。

REDO RECORD – Thread:1 RBA: 0x000026.0000000e.0010 LEN: 0x01e4 VLD: 0x0d

SCN: 0x0000.000b727d SUBSCN:  1 06/14/2009 15:10:12

CHANGE #1 TYP:2 CLS: 1 AFN:1 DBA:0x0040ebf2 OBJ:51447 SCN:0x0000.000b727b SEQ:  5 OP:11.2

KTB Redo

op: 0x01  ver: 0x01

op: F  xid:  0x0003.026.00000141    uba: 0x00806194.0257.19

KDO Op code: IRP row dependencies Disabled

xtype: XA flags: 0x00000000  bdba: 0x0040ebf2  hdba: 0x0040ebf1

itli: 2  ispac: 0  maxfr: 4863

tabn: 0 slot: 1(0x1) size/delt: 18

fb: –H-FL– lb: 0x2  cc: 2

null: —

col  0: [ 2]  c1 03

col  1: [11]  78 6d 06 0e 10 0b 0a 35 51 10 28

以上为后一条重做记录,该记录的CHANGE #1中包含了插入TIMESTAMP” col  1: [11]  78 6d 06 0e 10 0b 0a 35 51 10 28”即ITIME列为15:10:09:894505,而该条重做记录的时间戳为:15:10:12

以上实验可以证明,重做日志中记录的时间戳并不是SQL语句提交的时间,也晚于SQL语句完成的时间,实际为重做记录由缓存形式写至在线日志文件的时间。即SQL语句的完成时间一般都要早于重做日志中相应记录的时间戳。由于LGWR进程至少3秒会写出一次的特性,重做日志中的时间戳最早为语句的结束时间,最晚为语句结束后的三秒。

同样的查询每次都产生大量物理读的调优示例

12月中旬用户反映综合传输网管库上的一个查询影响迟缓,具体现象表现为当多个用户在应用界面上同时点下查询后,结果返回耗时长,影响正常业务的运作。经过初步分析该操作主要的等待事件在db file sequential read上,为了进一步明确问题,我们在系统的高峰时段使用性能报告工具抓取了统计信息,以下为top3等待事件:

Event                               Waits   Timeouts   Time (s)   (ms)

—————————- ———— ———- ———- ——

enqueue                           542        402      1,406   2595

db file sequential read           446,099          0        391      1

db file scattered read            156,634          0        209      1

可以看到db file sequential read事件仅次于数据库队列事件为主要的数据库性能瓶颈,以下列出缓存占用较高的典型SQL:

Selecta.objectid,a.emsalarm_time,a.emsend_time,c.label_cn,c.alias,a.alarm_name,a.alm_devinfo from traph c,alarm_to_traph b,current_alarm a where a.cuid=b.related_alarm_cuid and b.related_traph_cuid=c.cuid and (c.ext_ids=’,8,’ or c.ext_ids=’,9,’ or c.ext_ids=’,12,’ or c.ext_ids=’,19,’ or c.ext_ids=’,25,’) and a.emsend_time is null and a.emsalarm_time > to_date(‘2008-11-19′,’yyyy-MM-dd’)

经过进一步追踪我们发现以上SQL正是应用界面点击查询所做的操作,这就明确了此次优化的主要目的,即分析并尽可能降低该语句所产生的物理读和逻辑读,保证应用的正常运行。

具体分析
该句查询语句涉及到三个表的连接,因为应用设计使用的是基于RULE的优化模式,故执行计划倾向于使用索引来代替全表扫描,在表与表的连接方式上倾向使用嵌套循环即(NESTED LOOP),具体执行计划如下图:

经过查询缓存池中各个表的具体缓存状况发现,表ALARM_TO_TRAPH上的索引ALARM_TO_TRAPH_INDEX1与索引TRAPH_CUID均已被缓存,而在该执行计划中需要做全表扫描操作的CURRENT_ALARM则只有部分块被缓存,充分说明了引起物理读需求的正是对CURRENT_ALARM的全表扫描操作,为了进一步证实这一点,我们做了一次10046事件的trace,该事件可以记录SQL语句执行过程中详细的等待事件以及相关信息,在trace中发现大量db file sequential read等待时间,摘录如下:

以上记录中p1,p2对应了数据文件顺序读具体发生的文件号和块号,经过查询确定以上相关文件号和数据块号具对应于表CURRENT_ALARM,至此本次性能问题的主要原因已十分明确,即CURRENT_ALARM表未被完全缓存,引起问题的可能有两种:1.表中存在大量的chained rows即链式行;2.数据库高速缓存在系统高峰时段存在瓶颈。

对于前一种可能性,我们首先分析了表的结构,CURRENT_ALARM表包括96个列,其中包括大量varchar2(255)类型的长列,理论单行长度可能达到14K字节,的确可能引起严重的链式行,为了进一步证实,我们对该表做了一次链式行扫描,操作如下:

ANALYZE TABLE CURRENT_ALARM  LIST CHAINED ROWS INTO chained_rows;

该分析操作会将表上的链式行记录到临时表chained_rows中,查询chained_rows发现没有记录,说明表CURRENT_ALARM上没有链式行的问题。其后我们通过函数计算CURRENT_ALARM表上的行长度,发现最长的一行占用1367个字节,就目前来说仍不至于发生严重的链式行问题。

经过以上分析问题已经定位到了高峰时段数据库高速缓存的使用状况上了,通过在早晨,上班高峰时段以及下班时段的进一步观察,我们发现在早晨上班之前,buffer_cache中大约有600个free块可以立即使用,在该时段做上述查询不存在物理读的操作,而在上班高峰时段free块的数量下降到个位数乃至为零,即需要加载数据块时没有可以立即使用的空闲块,同时因为其他查询更为活跃,CURRNET_ALARM表上的数据块在读入后迅速被刷出,没有被缓存住以便于下次的查询,导致了性能问题的最终产生。

总结

由于数据库高速缓存在高峰时段没有空闲块导致需要全表扫描的表未被完全缓存,进而在多用户同时查询的情况下产生大量的物理读等待,影响了正常业务的运行。针对该问题提出以下建议:

  • 增大SGA总量,增大数据库高速缓存即DB_CACHE_SIZE的空间,并扩展高速缓存的keep池,将表CURRENT_ALARM保存在keep池中,保证不被刷出。
  • 定期分析CURRENT_ALARM表的行扩展情况,从而避免可能的链式行的产生。
  • 在可能的情况下,为上述查询语句加上执行计划暗示即ALL_ROWS的hit,使其在连接方式上倾向于使用哈希连接,可以降低三分之一的逻辑读。
  • 增大数据库使用内存总量的同时可能引发CPU的使用量有一定上升,需要密切关注主机的负载情况。

[gview file=”http://askmac.cn/wp-content/uploads/resource/BUFFPOOL.pdf”]

沪ICP备14014813号-2

沪公网安备 31010802001379号