Maclean’s Oracle Database Tech Blog Archives

内部视图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…

在上一篇关于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);…

服务器仅有一个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

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引起的。

Session1 Session2 Session3 Session4 Session5 Session6 Session7 Session8

I. 使用恢复目录存储RMAN备份记录 Oracle 官方建议把恢复目录建议于独立的数据库中。如果把恢复目录与其他一些数据混杂在某库中，若该库失败则恢复目录一起丢失，这将导致恢复异常困难。 在恢复目录中登记某个库被称作注册（registration）.可以在恢复目录中注册多个目标库。举例来说，你可以注册数据库 prod1,prod2,和prod3在一个单独的由用户catowner拥有的目录中，而该目录位于一个叫catdb的数据库中。 因为RMAN通过DBID即数据库的身份证来分辨各个库。每个在恢复目录中注册过的目标库都有一个唯一的DBID. 恢复目录主要包括以下RMAN的使用情况信息： l  数据文件和归档日志的备份集和备份片 l  数据文件的拷贝 l  归档日志及其拷贝 l  目标库中的表空间和数据文件 l  储存的脚本 l  RMAN的永久性配置 恢复目录保存了目标库控制文件中重要的RMAN操作原数据。同步恢复目录保证与控制文件中当前信息同步。 RMAN 创建快照控制文件，即临时控制文件，当每次需要做全局同步时。快照临时文件保证了RMAN同步时的一致性读。数据库服务进程保证同时只有一个快照临时文件的存在，这对于保证RMAN操作不受其他进程干扰是必要的。 丢失恢复目录将导致严重的恢复问题。如何备份恢复目录可参考一般数据库的备份方式。 关于恢复目录的兼容性，可以通过查询恢复目录用户模式下的rcver表了解参与恢复目录使用端的版本号，示例： SQL> SELECT * FROM rcver; VERSION ———— 08.01.05.00 09.00.01.00 10.02.01.00 只要是8i之后版本一般不存在兼容性问题。 II 管理恢复目录 创建恢复目录 管理恢复目录中的目标库记录 同步恢复目录 恢复目录模式下的控制文件管理 备份恢复目录 导入和导出恢复目录 增强恢复目录可用性 查询恢复目录视图 更新恢复目录 删除恢复目录 创建恢复目录，创建恢复目录分成三步： 配置恢复目录所在数据库 创建恢复目录拥有者 创建恢复目录本身 配置恢复目录数据库 若使用恢复目录，RMAN要求维护恢复目录所在模式。恢复目录储存在当前模式的默认表空间中，注意SYS不能是恢复目录的拥有者。我们强烈建议恢复目录数据库使用归档模式。同时必须分配足够的空间给恢复目录所在模式，恢复目录所占用的空间取决于使用恢复目录的目标数据库的数量。适当地为恢复目录库规划容量是必要的。应当保证恢复目录库和目标数据库的不占用同一磁盘。 创建目录拥有者…

在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)的属性有所改变。

首先创建一个包括序列号与时间戳的表，通过对该表插入当前时间戳并记录插入操作的开始时间，进行中时间，与结束时间，以便与重做日志中的时间戳对比。 表的定义如下： 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:…

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…