星期三 四月 02, 2014

Oracle数据库坏块(corruption)-物理坏块




概述

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

数据库坏块(corruption) 的类型可以按照坏块所属对象的不同,分为用户数据坏块,数据字典坏块,Undo坏块,控制文件坏块,Redo坏块,Lob坏块,index坏块等等;也可以按照坏块产生的原因,分为物理坏块(physical corruption)和逻辑坏块(logical corruption )。

本文主要讨论用户数据发生物理坏块(physical corruption)分析和解决方法。


物理坏块

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

常见的物理坏块(Physical Block Corruptions)有块头和块尾信息不一致(Fractured/Incomplete),checksum值无效,数据块信息全部为0等情况,并且可能伴随错误ORA-1578和ORA-1110



为了及时发现物理坏块和准确定位坏块产生的原因,oracle建议设置初始化参数DB_BLOCK_CHECKSUM=TYPICAL(默认值)。一般情况下,物理坏块是由于底层OS/disk系统错误/损坏,导致数据块被修改,数据块标志为坏块(corruption)。



Case分享

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

数据块的Checksum值无效是一种常见的物理坏块,当数据库初始化参数DB_BLOCK_CHECKSUM=TYPICAL(默认值)时,DBWR进程将数据块写入disk时会计算数据块的Checksum,并且将Checksum值记录在数据块的位置offset 16和17;当从disk读取该数据块时,oracle重新计算数据块的Checksum,并且与记录在数据块中的Checksum做异或运算(Xor),如果异或结果为非0,说明数据块被修改过,数据块为坏块(corruption)。



1. 当前数据库初始化参数配置DB_BLOCK_CHECKSUM=TYPICAL,因此从disk读取数据块时校验checksum:

SQL> show parameter DB_BLOCK_CHECKSUM



NAME                                 TYPE        VALUE

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

db_block_checksum                    string      TYPICAL



2. 查询表dept时发现有坏块,报错信息ORA-1578和ORA-1110,坏块为file # 4, block # 133



SQL> select * from dept;

 select * from dept

*

ERROR at line 1:

ORA-01578: ORACLE data block corrupted (file # 4, block # 133)

ORA-01110: data file 4: '/u01/app/oracle/oradata/orcl/users01.dbf'



3. 出现以上错误的同时在alert log中也有详细错误信息,这些错误信息说明数据块(file # 4, block # 133)损坏的原因是checksum无效。数据块中记录的checksum值为0x8167(这个值是上一次DBWR写入磁盘时计算的),读取数据块时重新计算得到的checksum是0x8122,checksum值异或运算(Xor)的结果是0x45 (computed block checksum)。由于两次checksum值不同(即异或结果为非0),说明数据块被修改过,数据块为坏块(corruption)。



Alert log错误信息:

Hex dump of (file 4, block 133) in trace file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20892.trc

Corrupt block relative dba: 0x01000085 (file 4, block 133)

Bad check value found during multiblock buffer read  <<<<<<<<<<<<<< 说明坏块的原因是checksum无效

Data in bad block:

 type: 6 format: 2 rdba: 0x01000085

 last change scn: 0x0000.0023d69a seq: 0x5 flg: 0x06

 spare1: 0x0 spare2: 0x0 spare3: 0x0

 consistency value in tail: 0xd69a0605

 check value in block header: 0x8167   <<<<<<<<<<<<<< 数据块中记录的checksum值为0x8167

 computed block checksum: 0x45         <<<<<<<<<<<<<< 0x8167与0x8122异或运算(Xor)的结果是0x45

Reading datafile '/u01/app/oracle/oradata/orcl/users01.dbf' for corruption at rdba: 0x01000085 (file 4, block 133)

Reread (file 4, block 133) found same corrupt data (no logical check)

Sun Mar 23 22:53:40 2014

Corrupt Block Found

         TSN = 4, TSNAME = USERS

         RFN = 4, BLK = 133, RDBA = 16777349

         OBJN = 14343, OBJD = 14343, OBJECT = DEPT, SUBOBJECT = 

         SEGMENT OWNER = JAMES, SEGMENT TYPE = Table Segment         <<<<<<<<<<<<<< 坏块对应的object ID

Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_20892.trc  (incident=182595):

ORA-01578: ORACLE data block corrupted (file # 4, block # 133)

ORA-01110: data file 4: '/u01/app/oracle/oradata/orcl/users01.dbf'



4.1 对应的orcl_ora_20892.trc中也有数据块的信息,其中数据块上记录的checksum值是0x8167(chkval)

Block dump from disk:

buffer tsn: 4 rdba: 0x01000085 (4/133)

scn: 0x0000.0023d69a seq: 0x05 flg: 0x06 tail: 0xd69a0605

frmt: 0x02 chkval: 0x8167 type: 0x06=trans data

Hex dump of block: st=0, typ_found=1


4.2 通过dd也查看数据块中记录的checksum值, offset 16,17 对应的是checksum值0x8167

$ dd if=/u01/app/oracle/oradata/orcl/users01.dbf bs=8192 count=1 skip=133 of=/tmp/dd133.out



$ od -x /tmp/dd133.out

0000000 a206 0000 0085 0100 d69a 0023 0000 0605

0000020 8167 0000 0001 0000 3807 0000 2fef 000c

^^^^



5. 修复数据坏块的方法可以通过备份恢复或者DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过坏块。

5.1 方法#1 RMAN数据块恢复:

RMAN> run {blockrecover datafile 4 block 133;}



SQL> select * from dept;



    DEPTNO DNAME          LOC

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

        10 ACCOUNTING     DALIAN

        20 RESEARCH       DALLAS

        30 SALES          CHICAGO

        40 OPERATIONS     BOSTON



5.2 方法#2 DBMS_REPAIR.SKIP_CORRUPT_BLOCKS跳过坏块,然后将dept表中的其他数据导出重建表

SQL> alter session set db_file_multiblock_read_count=1;

SQL> execute DBMS_REPAIR.SKIP_CORRUPT_BLOCKS('JAMES','DEPT'); 


SQL> create table dept_new as select * from dept;

参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"分享:Oracle数据库坏块(corruption)-物理坏块"���





星期三 三月 26, 2014

也来谈谈tnsping


[Read More]

星期二 三月 25, 2014

如何利用RMAN Debug和10046 Trace来诊断RMAN问题?

     在做Support的这些年,我很大的收获是掌握了许多troubleshooting问题的方法和工具,对于每一类问题,都可以大体归类出一些诊断方法。无论问题多么复杂,像扒洋葱一样,一层层去掉无关的,留下关键的,同时借助于一些诊断工具,层层深入,最后找到问题的核心。

     在这篇文章中,我想介绍一下如何对RMAN的问题做debug。 我们借助于下面这个场景,说明如何Debug RMAN 问题


在11.2.0.4上,物理备库上执行归档备份时,出现了下面的错误:

[oracle@test1 ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Tue Mar 25 13:58:59 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: R11204 (DBID=2001766638, not open)

RMAN> backup archivelog all;

Starting backup at 25-MAR-14
using target database control file instead of recovery catalog
RMAN-06820: WARNING: failed to archive current log at primary database<==============报错无法连接到主库
Connect identifier for DB_UNIQUE_NAME R11204 not configured

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=58 RECID=1 STAMP=842172838  <==============后面的归档备份还是成功的
input archived log thread=1 sequence=59 RECID=2 STAMP=842172838
input archived log thread=1 sequence=60 RECID=3 STAMP=842172928
input archived log thread=1 sequence=61 RECID=4 STAMP=842173275
input archived log thread=1 sequence=62 RECID=5 STAMP=842175748
input archived log thread=1 sequence=63 RECID=6 STAMP=842182033
input archived log thread=1 sequence=64 RECID=7 STAMP=842185463
input archived log thread=1 sequence=65 RECID=9 STAMP=842432288
input archived log thread=1 sequence=66 RECID=8 STAMP=842432286
input archived log thread=1 sequence=67 RECID=10 STAMP=842432291
input archived log thread=1 sequence=68 RECID=11 STAMP=842432322
channel ORA_DISK_1: starting piece 1 at 25-MAR-14
channel ORA_DISK_1: finished piece 1 at 25-MAR-14
piece handle=/u01/app/oracle/fast_recovery_area/SDY/backupset/2014_03_25/o1_mf_annnn_TAG20140325T135903_9m2hlj0p_.bkp tag=TAG20140325T135903 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 25-MAR-14


注:11.2.0.4有一个新的特性,就是备库上备份归档时,它会连接到主库上,让主库进行一次log switch,所以上面的错误是备库无法连接到主库进行log switch,上面最主要的错误是“Connect identifier for DB_UNIQUE_NAME R11204 not configured ”,看起来是备库要连接主库时需要用到的连接串没有配置正确。这时我们的疑问是这个连接串是在哪里设置的?


首先我们用一下Rman Debug:

[oracle@test1 ~]$ rman target / debug trace=/tmp/rman_debug
RMAN>  backup archivelog all;

RMAN-03090: Starting backup at 25-MAR-14
RMAN-06009: using target database control file instead of recovery catalog
RMAN-06820: WARNING: failed to archive current log at primary database
RMAN-06613: Connect identifier for DB_UNIQUE_NAME R11204 not configured
...


针对生成的/tmp/rman_debug,我们发现连接串用了为空“lprimary_db_cs = NULL”

DBGSQL:       TARGET> begin   :lprimary_db_cs :=     sys.dbms_backup_restore.get_connect_identifier       (dbuname=> :primary_dbunam
e); end;
DBGSQL:          sqlcode = 0
DBGSQL:           B :lprimary_db_cs = NULL《==========这是主库的连接串
DBGSQL:           B :primary_dbuname = R11204
  DBGRCVMAN: getConfig: configurations exists for this site
RMAN-06820: WARNING: failed to archive current log at primary database
DBGMISC:      ENTERED krmkursr [14:08:50.007]

也就是RMAN调用了一个内部的包 sys.dbms_backup_restore.get_connect_identifier来获得在备库连接主库时需要用到的串。这时我们需要知道这个串是在哪里设置的,为何为空。

接下来,针对RMAN进行10046 trace:

[oracle@test1 ~]$ rman target / debug trace=/tmp/rman_debug

Recovery Manager: Release 11.2.0.4.0 - Production on Mon Mar 17 09:00:00 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

RMAN-06568: connected to target database: R11204 (DBID=2001766638, not open)

RMAN> sql "alter session set tracefile_identifier=''rman_10046''";

RMAN-06009: using target database control file instead of recovery catalog
RMAN-06162: sql statement: alter session set tracefile_identifier=''rman_10046''

RMAN> sql "alter session set events ''10046 trace name context forever,level 12''";

RMAN-06162: sql statement: alter session set events ''10046 trace name context forever,level 12''

RMAN> backup archivelog all;
RMAN-03090: Starting backup at 25-MAR-14
RMAN-06820: WARNING: failed to archive current log at primary database
RMAN-06613: Connect identifier for DB_UNIQUE_NAME R11204 not configured
...


查看生成的trace file,这个文件在udump下:
$cd /u01/app/diag/rdbms/sdy/SDY/trace
$ls -ltr
-rw-r----- 1 oracle oinstall 1037463 Mar 25 14:11 SDY_ora_3792_rman_10046.trc

PARSING IN CURSOR #140366085001120 len=119 dep=0 uid=0 oct=47 lid=0 tim=1395736859520777 hv=3388798669 ad='7ec65738' sqlid='7pwt2c34
ztxqd'
begin   :lprimary_db_cs :=     sys.dbms_backup_restore.get_connect_identifier       (dbuname=> :primary_dbuname); end;
END OF STMT
PARSE #140366085001120:c=0,e=285,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,plh=0,tim=1395736859520776
BINDS #140366085001120:
 Bind#0
  oacdty=01 mxl=2000(1536) mxlc=00 mal=00 scl=00 pre=00
  oacflg=01 fl2=1000000 frm=01 csi=873 siz=2128 off=0
  kxsbbbfp=7fa986a27f08  bln=2000  avl=00  flg=05
 Bind#1
  oacdty=01 mxl=128(90) mxlc=00 mal=00 scl=00 pre=00
  oacflg=01 fl2=1000000 frm=01 csi=873 siz=0 off=2000
  kxsbbbfp=7fa986a286d8  bln=128  avl=06  flg=01
  value="R11204"
*** ACTION NAME:(0000018 STARTED189) 2014-03-25 14:10:59.521

WAIT #140366085001120: nam='control file sequential read' ela= 10 file#=0 block#=1 blocks=1 obj#=-1 tim=1395736859521532
WAIT #140366085001120: nam='control file sequential read' ela= 4 file#=0 block#=16 blocks=1 obj#=-1 tim=1395736859521566
WAIT #140366085001120: nam='control file sequential read' ela= 4 file#=0 block#=18 blocks=1 obj#=-1 tim=1395736859521580
WAIT #140366085001120: nam='control file sequential read' ela= 4 file#=0 block#=281 blocks=1 obj#=-1 tim=1395736859521594
WAIT #140366085001120: nam='control file sequential read' ela= 4 file#=0 block#=1 blocks=1 obj#=-1 tim=1395736859521614
WAIT #140366085001120: nam='control file sequential read' ela= 3 file#=0 block#=16 blocks=1 obj#=-1 tim=1395736859521627
WAIT #140366085001120: nam='control file sequential read' ela= 2 file#=0 block#=18 blocks=1 obj#=-1 tim=1395736859521638
WAIT #140366085001120: nam='control file sequential read' ela= 3 file#=0 block#=281 blocks=1 obj#=-1 tim=1395736859521650
krsd_get_primary_connect_string: found pcs '' by FAL_SERVER lookup <====================用FAL_SERVER找到了连接串''


所以这个10046 trace,很清楚地告诉我们它是从参数FAL_SERVER上获得了连接串''。

这时,连接到备库,查看参数FAL_SERVER,它的值的确为空:
SQL> show parameter fal

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
fal_client                           string
fal_server                           string 

到此,我们通过RMAN debug和10046 trace,获得了我们想要的信息。

总结一下:

如果在执行RMAN命令后,遇到了性能问题或者需要深入跟踪一个错误,那么可以考虑使用rman debug:

$ rman target <connection> catalog <connection> debug trace=/tmp/rmanDebug.trc log=/tmp/rmanLog.txt
run {
...Run your backup commands here
}


如果还需要跟进一步的跟踪可以再使用10046 trace:

$ rman target <connection> catalog <connection> debug trace=/tmp/rmanDebug.trc log=/tmp/rmanLog.txt
RMAN> sql "alter session set tracefile_identifier=''rman_10046''";
RMAN> sql "alter session set events ''10046 trace name context forever,level 12''";
RMAN> run-your-commands;
RMAN> exit;


需要注意的是,上面的这些方法可能会生成大量文件,需要考虑对磁盘空间的压力以及对RMAN的性能的影响。


可以参考MOS文档:RMAN: Quick Debugging Guide (Doc ID 1198753.1)

如何安装11.2单机Grid Infrastructure(Oracle Restart)?

本文通过图示给出了安装单机的11.2 Grid Infrastructure (也称Oracle Restart)的步骤。


在11.2及之上,如果要使用ASM,必须安装集群件Grid Infrastructure; 在11.2之前,ASM 不属于集群件,可以单独安装ASM。

请下载:How_To_Install_Standalone_GI(OracleRestart).pdf

星期一 三月 24, 2014

如何在各个平台上配置NTP的微调模式

对于11.2之前的版本,很多环境的重启原因(top5的情况)是由于NTP调整时间的步伐过大导致的,所以RAC环境中,我们建议用户如果使用NTP,需要配置成微调模式;

具体重启的原因,请大家参考Allen Gao写的博客 :如何诊断节点重启问题


这里介绍几个主流linux和unix平台上NTP微调的配置方法:


For Linux :


1.请确确认各节点的ntp包已经安装 ,我这里是个4.2.2的版本


[oracle@nascds10 ~]$ rpm -qa | grep ntp


ntp-4.2.2p1-9.el5_4.1


2.请编辑各个节点的ntp.conf文件


[oracle@nascds10 ~]$ su - root


Password:


[root@nascds10 ~]#  vi /etc/ntp.conf


#New ntp server added by Robinson


server  192.168.1.128 prefer  <<<<===========这里是时钟服务器


restrict 192.168.7.0  mask 255.255.255.255 nomodify notrap #基于网段的限制(限制在网段192.168.7.0)


broadcastdelay 0.008


[root@nascds11 ~]# vi /etc/ntp.conf


#New ntp server added by Robinson


server 192.168.7.71 prefer


broadcastdelay 0.008


3、配置ntpd的参数,我们主要强调的是要配置成"微调的模式" 也就是在options中要加入 -x的选项


[root@nascds10 ~]# vi /etc/sysconfig/ntpd


#The following item added by Robinson


#Set to 'yes' to sycn hw clock after successful ntpdate


SYNC_HWCLOCK=yes  


OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


[root@nascds11 ~]# vi /etc/sysconfig/ntpd


The following item added by Robinson


SYNC_HWCLOCK=yes


OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid"


4、自动启动配置


[root@nascds10 ~]# chkconfig ntpd on


[root@nascds11 ~]# chkconfig ntpd on


5、重启一下,使最新配置生效


[root@nascds10 ~]# service ntpd restart


Shutting down ntpd: [  OK  ]


ntpd: Synchronizing with time server: [  OK  ]


Syncing hardware clock to system time [  OK  ]


Starting ntpd: [  OK  ]


[root@nascds11 ~]# service ntpd restart


Shutting down ntpd: [  OK  ]


ntpd: Synchronizing with time server: [  OK  ]


Syncing hardware clock to system time [  OK  ]


Starting ntpd: [  OK  ]


6、检查ntpd进程的状态


[root@nascds10 ~]# ntpq -p


      remote           refid      st t when poll reach   delay   offset  jitter


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


  LOCAL(0)        .LOCL.          10 l   40   64    1    0.000    0.000   0.001


[root@nascds11 ~]# ntpq -p


      remote           refid      st t when poll reach   delay   offset  jitter


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


  test.oracle.com  .INIT.          16 u   60   64    0    0.000    0.000   0.000


  LOCAL(0)        .LOCL.          10 l   59   64    1    0.000    0.000   0.001




For Aix:




1. NTP的同步设置  编辑 /etc/ntp.conf文件, 内容如下:


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


#broadcastclient


server 192.168.5.2 


driftfile /etc/ntp.drift


tracefile /etc/ntp.trace


slewalways yes


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


我们这里还是要强调微调slewalways  ,这个值的默认设置是no,也就是说如果您不设置,NTP最大可一次调整1000秒. 根据IBM的官方说明,如果我们不指定slewthreshold  那么默认值是 0.128 seconds. 如果想特别设置,请指定slewthreshold 的值,注意单位是second




2.在NTP客户端启动xntpd守护进程


# startsrc -s xntpd



3. 查询xntpd的状态


当 system peer 不为 'insane' 时, 表明客户端已与服务器端成功地进行了同步.


# lssrc -ls xntpd


Program name: --/usr/sbin/xntpd


Version: -------3


Leap indicator: 00 (No leap second today.) Sys peer: ------192.168.5.2 ...




关于更多的关于IBM的平台上NTP的设置,可以参考IBM的官方文档解释:


http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/ntp.conf.htm



For HP  UX:



NTP在HP上的配置,是比较省心的,不容易导致RAC重启的,因为HP上的NTP默认的就是微调的模式


1、首先我们还是要编辑ntp的配置文件 /etc/rc.config.d/netdaemons,把 XNTPD 设定为1表示启动


   export XNTPD=1


2、编辑配置文件 /etc/ntp.conf ,配置好时间同步服务器


   server 192.168.5.2      #  第一个地址是主服务器


   server 192.168.5.3      #  第二个地址是备用服务器


3、启动ntp的进程


   # /sbin/init.d/xntpd start


4、检查NTP的状态


   # /usr/sbin/ntpq -p


  这个命令您会看到同步的地址


  如果出现的结果是No association ID's returned 那么表示您失败了


关于HP主机上NTP的模式,有3种如下,在HP 平台的man page中有详细的说明:


模式1:offset below 128 milliseconds

This is the normal operating regime of NTP. A properly configured NTP hierarchy (with reasonable networking) can operate for years without ever approaching the 128 millisecond upper limit. All time adjustments are small and smooth (known as slewing), and nobody even notices the slew adjustments unless they have a cesium clock or a GPS clock and expensive instrumentation to make sophisticated measurements (HP/Agilent makes the instruments).

模式2:offset above 128 milliseconds

This regime is often encountered at power-on because, those battery-backed real-time clocks they put in computers are not too great. Because NTP is quite capable of keeping the offset below one millisecond all the time it is running, many users want to get into the normal regime quickly when an offset above 128 millisecond is encountered at startup. So in this situation NTP will (fairly quickly) make a single step change, and is usually successful in getting the offset well below 128 millisecond so there will be no more of the disruptive step changes.


模式3:offset above 1000 seconds


This is so far out of the normal operating range that NTP decides something is terribly wrong and human intervention is required. The daemon shuts down.


For Solars:


我这没有测试的平台,不过在KM (How to Configure NTP or Windows Time for Oracle Clusterware (Doc ID 1056693.1))里找到了配置的办法,这里还有Windows的配置方式


检查配置:


/usr/bin/svcs ntp


STATE          STIME    FMRI


online          7:39:29 svc:/network/ntp:default


ps -ef|grep ntp


root 21212     1   0   Feb 02 ?           0:33 /usr/lib/inet/xntpd



配置/etc/inet/ntp.conf 启用slewalaways


grep 'slewalways|pll' /etc/inet/ntp.conf


slewalways yes


disable pll


启动:


/usr/sbin/svcadm enable ntp

星期五 三月 21, 2014

如何诊断rac环境下sysdate 返回错误时间问题

最近处理了一些rac环境下访问sysdate返回错误时间的问题,而这种问题往往出现在数据库链接是通过Listener创建的情况下,而且,大部分情况下都是和时区设置相关的。在这篇文章中我们会针对如何诊断这种问题进行解释。这篇文章适用于版本11.2.0.2 及以上版本。

首先,对问题当中涉及到的知识进行介绍。
1. 从版本11.2.0.2 开始oracle 集群(GI)开始拥有了自己的时区和一些其他配置,这些配置保存在配置文件<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt中。
例如:
TZ=Asia/Shanghai
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
TNS_ADMIN=
ORACLE_BASE=
我们能看到变量TZ 用于定义集群的时区。当然,这个集群的时区是在安装GI时从操作系统获得的。既然集群有了时区,那么我们就需要保证GI的时区和操作系统的设置是一致的,并且当操作系统的时区发生改变时,GI的时区也需要改变。而修改集群时区的基本步骤是(修改<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件,重启节点)。
2. 当数据库或者listner 使用srvctl 命令或者随着GI启动被启动时,环境变量会继承GI的时区。您也可以通过下面的命令来手动设置数据库和listener资源的环境变量。
srvctl setenv database -d <dbname> -t 'TZ=<时区>'
srvctl setenv listener -l <listenername> -t 'TZ=<时区>'
3. sysdate返回的值并不依赖于数据库的时区设置,oracle 只是简单的从操作系统获取系统时间返回(例如:调用os 函数gettimeofday)。所以,修改数据库的时区对于这种问题并没有帮助。而对应的服务器进程所使用的环境变量TZ才会影响返回的系统时间。


接下来,我们简单介绍一下客户端通过listener 连接到数据库时会经过那些过程。我们会通过一个具体的例子来解释。在这个例子中,我们使用sqlplus 创建数据库链接,并对listener进程搜集truss 信息

1.客户端连接数据库
sqlplus scott/tiger@test
2.listner 进程收到了对应的链接,并产生了对应的server process.
524732: psargs: /u01/app/11.2.0/grid/bin/tnslsnr LISTENER -inherit
......
524732: kfork() = 496094
496094: kfork() (returning as child ...) = 0
......
496094: kfork() = 483742
483742: kfork() (returning as child ...) = 0
3. 为server process指定环境变量。
483742: execve(0x0FFFFFFFFFFF2660, 0x0000000110773730, 0x000000011077B670) argc: 2
483742: argv: oracle<sid name> (LOCAL=NO) <<<<<<<< 服务器进程环境变量被指定
483742: envp: _=/u01/app/11.2.0/grid/bin/oraagent.bin LANG=en_US LOGIN=root
483742: __CLSAGENT_INCARNATION=2 _ORA_AGENT_ACTION=TRUE PATH=
483742: NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 __CLSAGENT_USER_NAME=oracle
......
483742: ENV_FILE=/u01/app/11.2.0/grid/crs/install/s_crsconfig_<node name>_env.txt
......
483742: __CLSAGENT_LOGDIR_NAME=crsd PWD=/ TZ=Asia/Shanghai <<<< 时区被指定。

我们能看到环境变量TZ的值在创建服务器进程时会被绑定到server process 中。当然,如果您没有对lisetner 搜集truss 输出。您也可以通过操作系统命令获得对应进程的环境变量,例如:ps eauwww <pid from above>,您可以通过MOS note 373303.1 中的内容获得不同平台的命令。另外,以上的数据库是通过GI agent 启动的,如果数据库是手动启动的(例如:startup 命令),那么,输出会不同。当然, pmon在注册数据库服务到listener时也会将自己的环境变量注册到对应的service上。

所以,在诊断RAC 环境下sysdate 返回错误时间的问题时,我们需要检查以下信息。
1. 操作系统级别的时区设置,并确保操作系统命令date 能返回正确的时间。对于如何查看不同平台的时区设置,请参考note 1209444.1
2. 确认GI 配置文件<gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件中的变量TZ和操作系统的TZ 设置一致。
3. 确认是否在database或listener资源层面设置了TZ变量。如果设置了,是否和OS,GI的设置是一致的。
4. 另外,server process的环境变量LIBPATH 或 LD_LIBRARY_PATH 也会对oracle访问操作系统函数产生影响。而且GI 的agent进程(适用于版本11.2.0.3 及以上的版本)在启动资源时(例如:database资源)会自动的将进程的以下环境变量清空
LD_LIBRARY_PATH, SHLIB_PATH (HP-UX), LD_LIBPATH_PATH_64 (Solaris), LIBPATH(AIX)
所以,如果您的database是使用srvctl 命令启动的,就需要确认上面的环境变量被设置正确。
例如:srvctl setenv database -d <db_name> -t 'LIBPATH=<gi_home/lib>'
注意:不同的Unix平台,以上命令可能会不同。
所以,我们也去要确认database 资源的LIBPATH 或 LD_LIBRARY_PATH 变量是否被设定。
例如:srvctl getenv database -d <db_name>
另外,在诊断这种问题时,需要搜集以下信息。
1. <gi_home>/crs/install/s_crsconfig_<节点名>_env.txt文件
2. 操作系统时区设置(cat /etc/sysconfig/clock) 和环境变量TZ的设置。以及pmon进程的环境变量。
3. database和 listener资源的环境变量
例如:srvctl getenv database -d <db_name>
srvctl getenv listener -l <listener name>
4. 如果以上的信息没有问题,那么就需要搜集listener 进程的truss(或strace) 输出找到有问题的环境变量设置。
5. 如果1—4 中的信息仍然无法找到问题的原因,请搜集客户端和服务器端的sqlnet trace,以便确认是否有任何的’alter session set ...’命令修改了会话的时区或者相关的变量。
客户端sqlnet trace:设置以下参数到客户端的sqlnet.ora 文件中。
trace_level_client=16
trace_directory_client=c:\tmp ==> 确保该路径存在
trace_file_client=client
trace_unique_client=on
trace_timestamp_client=on
服务器端sqlnet trace:设置以下参数到服务器端的sqlnet.ora文件中
trace_level_server=16
trace_file_server=server
trace_directory_server=/tmp ==> 确保该路径存在
trace_timestamp_server=ON


希望以上的解释对大家诊断类似问题会有所帮助。

星期一 二月 24, 2014

如何获得Oracle数据库技术支持信息和工具?

是否期望系统运行更加稳定,提前发现潜在的数据库问题?
是否期望得到指导如何分析问题,提供解决方案?
是否需要一种工具帮助您来分析特定的错误并且提供解决方案?
是否能够非常容易的找到您所需要的信息?

对于以上问题,如果您的答案是: YES,那么请查看Note
Oracle Database Resource Portfolio (Doc ID  1573428.2)
这篇Note可以帮助我们快速简单的了解最新的新闻,最佳实践,健康检查,工具,故障处理方案等。

Note 1573428.2具体包含的内容有:


  • 首页 技术支持政策,Webcast 等等

  • 技术支持工具 数据收集工具,监控工具,健康检查工具,故障处理分析工具等等

  • 安装/升级/打补丁 最佳实践,建议等等

  • 性能 数据库性能分析,SQL语句优化,SQLT等等

  • 高可用,备份恢复 – Active Data Guard最佳实践,备份恢复案例等等

  • RAC - RAC 常见问题,各个平台的最佳实践等等

  • 安全 权限,角色,CPU等等


您还在犹豫什么,请马上查看并收藏Note 1573428.2,参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"共享:如何获得更多Oracle数据库技术支持信息和工具"

星期一 二月 10, 2014

RAC中误将数据文件创建在本地盘时的修正


用户创建表空间时误将数据文件放到了本地盘,重启数据库时一个实例启动不了,只能offline该表空间后启动数据库。现用户想知道怎样能把这个表空间数据文件中的数据恢复出来。

测试目的:验证RAC中误将数据文件创建在本地盘时的修复办法
环境说明:
两节点RAC,数据库名为db10g 版本10.2.0.5
使用了ASM作为共享存储解决方案。



1
,场景准备

1
)节点2:创建表空间test1,数据文件不放到ASM,而是放到本地盘:

SQL> create tablespace test1 datafile '/home/oracle/test1.dbf' size 10m;


Tablespace created.


SQL> select name,status from v$datafile;


NAME

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

STATUS

-------

+DG/db10g/datafile/system.256.821723567

SYSTEM


+DG/db10g/datafile/undotbs1.258.821723569

ONLINE


+DG/db10g/datafile/sysaux.257.821723569

ONLINE



NAME

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

STATUS

-------

+DG/db10g/datafile/users.259.821723569

ONLINE


+DG/db10g/datafile/undotbs2.264.821723755

ONLINE


/home/oracle/test1.dbf

ONLINE



6 rows selected.


2
)节点2:在表空间test1中创建表没问题


SQL> create table test1 (id int) tablespace test1;


Table created.

SQL> create table test2 tablespace test1 as select * from dba_tables;


Table created.


3
)节点1:能查到表空间test1,但创建表报错

SQL> select name ,status from v$datafile;


NAME

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

STATUS

-------

+DG/db10g/datafile/system.256.821723567

SYSTEM


+DG/db10g/datafile/undotbs1.258.821723569

ONLINE


+DG/db10g/datafile/sysaux.257.821723569

ONLINE



NAME

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

STATUS

-------

+DG/db10g/datafile/users.259.821723569

ONLINE


+DG/db10g/datafile/undotbs2.264.821723755

ONLINE


/home/oracle/test1.dbf

ONLINE



6 rows selected.


SQL> create table test1 (id int) tablespace test1;

create table test1 (id int) tablespace test1

*

ERROR at line 1:

ORA-01157: cannot identify/lock data file 6 - see DBWR trace file

ORA-01110: data file 6: '/home/oracle/test1.dbf'


4
)重启数据库,会发现节点1实例起不来,因为节点1无法读取节点2本地盘上的/home/oracle/test1.dbf

[oracle@rac10g2 ~]$ srvctl stop database -d db10g

[oracle@rac10g2 ~]$ srvctl start database -d db10g

PRKP-1001 : Error starting instance db10g1 on node rac10g1

CRS-0215: Could not start resource 'ora.db10g.db10g1.inst'.

[oracle@rac10g2 ~]$ crs_stat -t

Name          
Type          
Target    State    
Host        

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

ora.db10g.db   application    ONLINE   
ONLINE    rac10g1     

ora....g1.inst application    ONLINE   
OFFLINE             
 

ora....g2.inst application    ONLINE   
ONLINE    rac10g2     

ora....SM1.asm application    ONLINE   
ONLINE    rac10g1     

ora....G1.lsnr application    ONLINE   
ONLINE    rac10g1     

ora....0g1.gsd application    ONLINE   
ONLINE    rac10g1     

ora....0g1.ons application    ONLINE   
ONLINE    rac10g1     

ora....0g1.vip application    ONLINE   
ONLINE    rac10g1     

ora....SM2.asm application    ONLINE   
ONLINE    rac10g2     

ora....G2.lsnr application    ONLINE   
ONLINE    rac10g2     

ora....0g2.gsd application    ONLINE   
ONLINE    rac10g2     

ora....0g2.ons application    ONLINE   
ONLINE    rac10g2     

ora....0g2.vip application    ONLINE   
ONLINE    rac10g2   


2
,处理过程


由于该过程中需要从本地盘把数据文件迁移到ASM共享存储,ASM文件的访问无法通过操作系统级别直接进行。


10gR2中,我们可以使用RMAN命令备份和恢复ASM文件,使用ASMCMD命令可以浏览和操纵目录结构。不过,Oracle 10g包中的DBMS_FILE_TRANSFER是处理ASM的另一种方式。 DBMS_FILE_TRANSFER可以在同一台Oracle服务器上或两台Oracle 服务器之间复制文件。它使用目录对象来指定源目录和目的目录,因为目录对象支持ASM路径名称,所以DBMS_FILE_TRANSFER也支持ASM路径名。这使得从常规文件系统的ASM存储区移入和移出文件变得十分简单,使用它可以完成如下的迁移:


ASM->ASMASM->OS
Flie
OS File->ASMOS
File->OS File



建错的表空间test1数据文件在节点2,所以只能从节点2上打开。可在节点2上将表空间offline之后使用dbms_file_transfer将数据文件移到ASM共享存储(如使用的是集群文件系统,直接拷贝数据文件即可)


1)为两个数据文件路径创建目录


节点2:创建两个directory,一个指向本地盘该数据文件目录;一个指向ASM数据文件目录。

SQL> create directory test1 as '/home/oracle';


Directory created.


SQL> create directory test2 as '+DG/db10g/datafile';


Directory created.


2
offline表空间


节点2offline表空间test1

SQL> alter tablespace test1 offline;


Tablespace altered.


3
)拷贝数据文件到ASM


节点2:使用dbms_file_transfer拷贝该数据文件到ASM

SQL> exec
dbms_file_transfer.copy_file('TEST1','test1.dbf','TEST2','test1.dbf');


PL/SQL procedure successfully completed.


4
)修改控制文件中的数据文件路径


节点2

SQL> alter database rename file '/home/oracle/test1.dbf' to
'+DG/db10g/datafile/test1.dbf'

SQL> /


Database altered.


5
online表空间test1


节点2online表空间test1

SQL> alter tablespace test1 online;


Tablespace altered.


6
)启动实例1

[oracle@rac10g2 ~]$ srvctl start instance -d db10g -i db10g1

[oracle@rac10g2 ~]$ crs_stat -t

Name          
Type          
Target    State    
Host        

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

ora.db10g.db   application    ONLINE   
ONLINE    rac10g1     

ora....g1.inst application    ONLINE   
ONLINE    rac10g1     

ora....g2.inst application    ONLINE   
ONLINE    rac10g2     

ora....SM1.asm application    ONLINE   
ONLINE    rac10g1     

ora....G1.lsnr application    ONLINE   
ONLINE    rac10g1     

ora....0g1.gsd application    ONLINE   
ONLINE    rac10g1     

ora....0g1.ons application    ONLINE   
ONLINE    rac10g1     

ora....0g1.vip application    ONLINE   
ONLINE    rac10g1     

ora....SM2.asm application    ONLINE   
ONLINE    rac10g2     

ora....G2.lsnr application    ONLINE   
ONLINE    rac10g2     

ora....0g2.gsd application    ONLINE   
ONLINE    rac10g2     

ora....0g2.ons application    ONLINE   
ONLINE    rac10g2     

ora....0g2.vip application    ONLINE   
ONLINE    rac10g2     


7
)节点1:检查数据文件状态和表空间内数据

SQL> select name ,status from v$datafile;


NAME

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

STATUS

-------

+DG/db10g/datafile/system.256.821723567

SYSTEM


+DG/db10g/datafile/undotbs1.258.821723569

ONLINE


+DG/db10g/datafile/sysaux.257.821723569

ONLINE



NAME

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

STATUS

-------

+DG/db10g/datafile/users.259.821723569

ONLINE


+DG/db10g/datafile/undotbs2.264.821723755

ONLINE


+DG/db10g/datafile/test1.dbf

ONLINE



6 rows selected.


SQL> select count(*) from test2;


  COUNT(*)

----------

      1522 




3、备注


以上迁移数据文件时是采用 dbms_file_transfer.copy_file迁移数据文件的方法,也可以使用RMAN来做:




SQL>select tablespace_name,file_name,status,online_status from
dba_data_files;

需要对表空间进行OFFLINE
登录RMAN

 RMAN> sql "alter tablespace test1 offline";


  RMAN> copy datafile '/home/oracle/test1.dbf' to
'+DG/rac10g/datafile/test1.dbf';




SQL> alter database rename file '/home/oracle/test1.dbf' to
'+DG/rac10g/datafile/test1.dbf';


SQL> alter tablespace test1 online;



参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"测试:RAC中误将数据文件创建在本地盘时的修正"

星期六 二月 08, 2014

Oracle诊断工具 - ORA-2730x Troubleshooting Tool


通常情况下,ORA-27300 ORA-27301 ORA-27302错误的原因是操作系统的系统调用错误或者操作系统配置问题,错误格式:
ORA-27300: OS system dependent operation:%s  failed with status: %s
ORA-27301: OS failure message: %s
ORA-27302: failure occurred at: %s

Oracle support网站提供ORA-2730x错误诊断工具:ORA-2730x  Troubleshooting Tool


ORA-2730x Troubleshooting Tool根据分析上传的日志文件,提供ORA-2730x的分析解决方案。
如果符合已知的解决方案,那么ORA-2730x Troubleshooting Tool提供错误原因和解决方案。
如果没有符合的已知解决方案,那么ORA-2730x Troubleshooting Tool会导向ORA-2730x有关的Notes,详细解释ORA-2730x错误,并提供已知的bug信息。

使用ORA-2730x Troubleshooting Tool好处:


- 分析上传的文件,对于一个已知的问题,提供错误的原因和解决方案。
- 提供诊断分析报告。
- 可选择创建SR,会自动填入许多SR的项目。

访问ORA-2730x Troubleshooting Tool2种方法:


方法1:创建SR时使用ORA-2730x Troubleshooting Tool访问Support网站
    步骤1:上传文件
    步骤2:浏览推荐

方法2 直接访问ORA-2730x Troubleshooting Tool (访问URL)
    步骤1:分析新的问题
    步骤2:上传文件
    步骤3:浏览推荐
    步骤4:浏览诊断报告(可选)

了解更多ORA-2730x错误的note,请参考:


ORA-2730x Troubleshooting Tool (Doc ID  1541106.1)
Troubleshooting ORA-27300 ORA-27301  ORA-27302 errors (Doc ID 579365.1)



了解最新数据库技术资讯请关注:Oracle数据库技术支持通讯(Doc ID 1529795.1)
















星期一 一月 20, 2014

RAC等待事件:gc buffer busy acquire









概述
---------------------
gc buffer busyRAC数据库中常见的等待事件,11g开始gc buffer  busy分为gc buffer busy acquiregc buffer  busy release

gc buffer busy acquire是当session#1尝试请求访问远程实例(remote  instance) buffer,但是在session#1之前已经有相同实例上另外一个session#2请求访问了相同的buffer,并且没有完成,那么session#1等待gc buffer busy acquire

gc buffer busy release是在session#1之前已经有远程实例的session#2请求访问了相同的buffer,并且没有完成,那么session#1等待gc buffer busy release

原因/解决方法
---------------------
- 热点块(hot block)
AWRSegments by Global Cache Buffer Busy 记录了访问频繁的gc buffer.
解决方法可以根据热点块的类型采取不同的解决方法,比如采取分区表,分区索引,反向index等等。这点与单机数据库中的buffer busy waits类似。

- 低效SQL语句
低效SQL语句会导致不必要的buffer被请求访问,增加了buffer busy的机会。在AWR中可以找到TOP SQL。解决方法可以优化SQL语句减少buffer访问。这点与单机数据库中的buffer busy waits类似。

- 数据交叉访问。
RAC数据库,同一数据在不同数据库实例上被请求访问。
如果应用程序可以实现,那么我们建议不同的应用功能/模块数据分布在不同的数据库实例上被访问,避免同一数据被多个实例交叉访问,可以减少buffer的争用,避免gc等待。

- Oracle bug
建议安装Oracle推荐的最新Patch SetPSU
Patch setPSU信息请参考:Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)

案例分享
---------------------
一个gc buffer busy acquire的案例,和大家分享一下。

- 应用端反映业务处理异常,数据库hang,在第一时间现场DBA收集了hanganalyze (hanganalyze对于分析数据库hang非常重要)

RAC数据库收集hanganalyze的命令:
SQL> conn / as sysdba
SQL> oradebug setmypid
SQL> oradebug unlimit
SQL> oradebug -g all hanganalyze 3

通过hanganalyze我们可以比较容易看到有1000个以上的Chain都有类似的等待关系,比如:

Chain 1 Signature: 'gc current request'<='gc buffer busy acquire'<='enq: TX -  contention'
Chain 2 Signature: 'gc current request'<='gc buffer busy  acquire'<='buffer busy waits'

Chain 1243 Signature: 'gc current request'<='gc buffer busy  acquire'<='enq: TA - contention'
Chain 1244 Signature: 'gc current request'<='gc buffer busy  acquire'<='enq: TA - contention'



Hanganalyze说明数据库中大部分session直接或者间接等待'gc  current request'<='gc buffer busy acquire'。



- 有些情况下dia0 trace文件也会记录hang信息

  inst# SessId  Ser#     OSPID PrcNm Event

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

      1   1152     3  21364904    FG gc buffer busy acquire

      1   2481     3  26607642    FG gc current request

Chain 1 Signature: 'gc current request'<='gc buffer busy acquire'

Chain 1 Signature Hash: 0x8823aa2a 



- 有些情况下dba_hist_active_sess_history也会记录hang信息。


1. 在数据库hang的时间段内,有691个session在等待'enq: TA - contention','enq: TA - contention'的持有者是session#931,serial#39657




2. session#931serial#39657  也是处于等待状态,等待事件是'gc buffer busy acquire',而'gc buffer busy
acquire'
的持有者是session#1324serial#22503



3. session#1324serial#22503  也是处于等待状态,等待事件是'gc current request'




通过分析dba_hist_active_sess_history,也可以得到session等待关系:
'gc current request'<='gc buffer busy  acquire'<='enq: TA - contention'
这个等待关系与hanganalyze是一致的。

- 根据以上分析得到session等待关系,可以确定数据库hang的原因是oracle已知问题Bug
13787307 - Hang in RAC with 'gc current request'<='gc buffer busy acquire'  signature.



- 解决方法:
安装Patch 13787307 或者 设置_gc_bypass_readers=false临时规避这个问题。
另外,在11.2低版本中也有些类似的已知问题,建议安装最新patch set (11.2.0.3/4) + 最新PSU
Patch setPSU信息请参考:Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)


参与此主题的后续讨论,请回复blog,或者访问我们的中文社区,跟帖"共享:RAC等待事件:gc buffer busy acquire"。 













星期五 一月 10, 2014

Oracle 11.2.0.4数据库版本发布

DB 11.2.0.4(Patch 13390677)已经发布的平台包括:



  • Linux x86-64

  • Linux x86

  • Solaris on SPARC (64-bit)

  • Solaris x86-64

  • HP-UX Itanium

  • IBM AIX on Power Systems

  • Microsoft Windows x64 (64-bit)

  • Microsoft Windows (32-bit)

  • HP-UX PA-RISC (64-bit)

  • IBM: Linux on System z



11.2.0.4 patch set 是DB 11.2最后一个patch set.

了解DB 11.2.0.4中修复的bug和已知问题:




了解DB 11.2.0.4新特性:



Oracle 12.1.0.1数据库版本发布

2014年01月09日 Oracle 12.1.0.1数据库发布以下平台版本:



  • HP-UX Itanium

  • IBM AIX

  • IBM Linux on System z



截至到目前Oracle 12.1.0.1数据库已经发布的平台包括:



  • Linux x86-64

  • Oracle Solaris SPARC (64-bit)

  • Oracle Solaris x86-64 (64-bit)

  • Microsoft Windows x64 (64-bit)

  • HP-UX Itanium

  • IBM AIX on POWER Systems

  • IBM Linux on System z



星期三 一月 08, 2014

Oracle诊断工具 - ORA-1578 Troubleshooting Tool


Oracle support网站提供ORA-1578错误诊断工具:ORA-1578 Troubleshooting Tool。

ORA-1578 Troubleshooting Tool根据分析上传的日志文件,提供ORA-1578的分析解决方案。

如果符合一个已知的问题,那么ORA-1578 Troubleshooting Tool提供错误原因和解决方案。

如果没有符合的已知问题,那么ORA-1578 Troubleshooting Tool会导向ORA-1578 master note,详细介绍ORA-1578错误。



ORA-1578是一个常见的坏块错误信息,说明数据库检测到数据坏块(block corruption),并且打印出坏块信息:相对文件号和块号。

例如:

ORA-01578: ORACLE 数据块损坏 (文件号 17, 块号 1862743)



使用ORA-1578 Troubleshooting Tool好处:

- 分析上传的文件后,对于一个已知的问题,提供错误的原因和解决方案。

- 如果没有已知问题,会导向ORA-1578 master note。

- 提供诊断分析报告。

- 可选择创建SR,会自动填入许多SR的项目。



访问ORA-1578 Troubleshooting Tool有2种方法:


方法1:创建SR时使用ORA-1578 Troubleshooting Tool(访问Support网站

    步骤1:上传文件

    步骤2:浏览推荐

方法2: 直接访问ORA-1578 Troubleshooting Tool (访问URL)

    步骤1:分析新的问题

    步骤2:上传文件

    步骤3:浏览推荐

    步骤4:浏览诊断向导

更多ORA-1578 Troubleshooting Tool介绍,请参考:

ORA-1578 Troubleshooting Tool (Doc ID 1567169.1)

OERR: ORA-1578 "ORACLE data block corrupted (file # %s, block # %s)" Master Note (Doc ID 1578.1)

星期四 十二月 26, 2013

如何分析发生在过去的数据库性能问题

在数据库运行的过程中,我们有时会碰到数据库hung住的问题,在这个时候很多人会选择尽快让它恢复正常而不是找出问题的root cause. 只有在问题被解决后,才意识到需要找到root cause来避免再次碰到相同的问题; 下面就讲讲如何分析发生在过去的数据库性能问题 (这是一篇讲方法论的blog,并没有涉及到具体的案例, 稍后会有更多具体案例的Blog)




1.       首先要申明的是, 对于这样的问题,我们需要有一个正确的期望: 不一定能够找到root cause, 这取决于发生问题时是否收集到了足够的信息.




2.       梳理我们可以收集到的信息, 一般的可以先检查下面的日志


a)       操作系统日志, 参照文档 note 1349613.1 - How To Gather The OS Logs For Each Specific OS Platform


b)       数据库alert log


c)       操作系统resource(CPU, memory, IO, swapping)使用的状况, 推荐使用OSWbb (也可以是nmon等第三方工具)




有的时候可以通过上面的日志找到一些蛛丝马迹, 比如有时alert log中会提示当时有过多的swap活动, 或提示生成了 enqueue/ row cache enqueue 等等的trace, 或提示diag后台进程生成了systemstate dump trace, 那么进一步就是要分析这些trace了;又比如OSWbb的ps输出显示当时有很多和数据库无关的进程在消耗过多的CPU等等, 那么这就证明问题和数据库无关了.




3.       接下来要收集发生问题时间段的AWR report和ASH report


但是往往发生问题后数据库被重起了,那么很不幸AWR report很可能没有发生问题时间段的信息, 那么这样的AWR对我们分析这个问题就没有意义了.


ASH在大部分的情况下都是可以收集到发生问题时间段的信息, 从中可以查到数据库top的等待事件/session; 然后根据具体的问题,进行进一步的分析




4.       如果之前收集到的信息不足以找出问题的原因, 我们还有一个地方可以查,那就是 dba_hist_active_sess_history.


这个视图是用来生成ASH report的, 但是ASH report并没有充分的利用这个视图的强大之处,我们通过分析这个视图的详细数据,往往可以找到问题发生的原因.


可以从宏观和微观两个维度来分析这个视图(用11gR2的dba_hist_active_sess_history做例子):




比如


宏观:


a)       可以按照一段时间内(发生问题的时间段)这些session等待的非空闲等待事件的类型做分类和求和,就可以知道哪种等待事件最严重


b)       可以按照一段时间内(发生问题的时间段)等待最严重事件的这些session所执行的SQL_ID来汇总求和,可以知道哪个SQL跟这个问题相关





微观:


a). 对于某一条dba_hist_active_sess_history的记录,我们可以知道这个session的SESSION_STATE是ON CPU还是WAITING, 如果是ON CPU,那么这个session的event就无意义了; 如果是WAITING, 可以进一步看它的等待事件和BLOCKING_SESSION_STATUS, 如果它是被另一个session阻塞, 那么BLOCKING_SESSION_STATUS这一列就会显示为VALID或 GLOBAL. 然后再检查BLOCKING_INST_ID和BLOCKING_SESSION找到阻塞这个session的是哪里实例上的哪个session


b). 按照SAMPLE_TIME排序,我们可以找到问题发生的具体的时间点 (还是比较精确的)


c). 对某个session, dba_hist_active_sess_history还能揭示更多有用的信息, 比如这个session当前执行的SQL语句的类型(SQL_OPCODE, SQL_OPNAME), 这个session是否在PARSE(IN_PARSE, IN_HARD_PARSE等), 它是什么客户端(PROGRAM, MODULE, ACTION, CLIENT_ID, MACHINE), 它使用的PGA(PGA_ALLOCATED), 它使用的temp空间大小(TEMP_SPACE_ALLOCATED)等等




善于使用 dba_hist_active_sess_history能极大地帮助我们分析问题.但是也要注意dba_hist_active_sess_history不是万能的: 如果最终阻塞别人的session当时并不是active的或者它并没有被ASH记录到dba_hist_active_sess_history中, 我们还是不能知道它当时处于一种什么状况.




结语: 总之, 分析类似的问题就是充分挖掘已有的trace/日志的过程, 但是因为缺少足够的诊断日志/信息,很多时候还是无法找到问题发生的原因. 如果我们确实有需要找到root cause, 那么在发生问题时就需要收集到足够多的信息. 比如hanganalyze, systemstate dump等






参与此主题的后续讨论,可以访问我们的中文社区,跟帖 "如何分析发生在过去的数据库性能问题"。 

星期三 十二月 18, 2013

DB 12c Release 1 (12.1) 相关信息列表

登录到 My Oracle Support,查看 Oracle 数据库技术支持通讯文件1529795.1),了解12C数据库相关的完整信息列表,例如:


Oracle Database 12c -    


About

本博客由Oracle全球技术支持中国区的工程师维护。为中文用户提供数据库相关的技术支持信息,包括常用的诊断工具、诊断方法、产品新特性、案例分析等。此外,MOS也陆续推出各类中文内容:技术通讯统一发布在Note 1529795.1 中,中文文档列表更新在Note 1533057.1 中,网上讲座请查看MOS文档 1456176.1,在"Archived"中可以下载历史的录音和文档。

Search

Archives
« 四月 2014
星期日星期一星期二星期三星期四星期五星期六
  
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
今天