Author: mac

之前有用户在AWR中定位到问题SQL语句后想要了解该SQL statement的具体执行计划，于是就用AWR报告中得到的SQL ID去V$SQL等几个动态性能视图中查询，但发现V$SQL或V$SQL_PLAN视图都已经找不到对应SQL ID的记录，一般来说这些语句已经从shared pool共享池中被替换出去了。 这个时候我们可以尝试使用DBMS_XPLAN.DISPLAY_AWR存储过程来将Oracle Automatic Workload Repository自动负载仓库中记录的SQL语句相关信息抽取出来，如: SQL> set linesize 200 pagesize 2000; SQL> select * from global_name; GLOBAL_NAME ——————————————————————————– askmac.cn SQL> select /* extract_me */ count(*) from maclean; COUNT(*) ———- 9564 SQL> select sql_id from v$sql where sql_text like ‘%extract_me%’ and sql_text not like ‘%like%’; SQL_ID ————- 8vff23q8qp9fj SQL> exec dbms_workload_repository.create_snapshot; PL/SQL…

DBA在性能调优或诊断过程中多少会使用一些成品工具，以下列出一些我工作中使用较为频繁的工具: Program platform download URL nmon AIX POWER http://www.ibm.com/developerworks/wikis/download/attachments/53871937/nmon4aix12e.zip?version=1 nmon Linux http://nmon.sourceforge.net/docs/MPG_nmon_for_Linux_14a_binaries.zip sarmon Solaris http://sourceforge.net/projects/sarmon/files/ putty Interl x86 http://the.earth.li/~sgtatham/putty/latest/x86/putty.exe OS watcher Non Windows https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=REFERENCE&id=301137.1 Procwatcher Non Windows https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=BULLETIN&id=459694.1 SQLTXPLAIN ALL https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=TROUBLESHOOTING&id=215187.1 TRCANLZR ALL https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=TROUBLESHOOTING&id=224270.1 STRMMON Non Windows https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=BULLETIN&id=290605.1 Oracle Cluster Verification Utility ALL http://www.oracle.com/technetwork/database/clustering/downloads/cvu-download-homepage-099973.html Oracle Cluster Health Monitor (CHM) Linux and Windows http://www.oracle.com/technetwork/database/clustering/downloads/ipd-download-homepage-087212.html RDA 4…

大约是一周前，一位资深的Oracle工程师向我和客户介绍RAC中脑裂的处理过程，据他介绍脑裂发生时通过各节点对voting disk(投票磁盘)的抢夺，那些争抢到(n/2+1)数量voting disk的节点就可以survive(幸存)下来，而没有争抢到voting disk的节点则被evicted踢出节点。 不得不说以上这番观点，来得太过随意了，一位从Oracle 6就开始从事维护工作的老工程师也会犯这样的概念性错误，只能说Oracle技术的更新过于日新月异了。 在理解脑裂(Brain Split)处理过程前，有必要介绍一下Oracle RAC Css(Cluster Synchronization Services)的工作框架: Oracle RAC CSS提供2种后台服务包括群组管理(Group Managment简称GM)和节点监控(Node Monitor简称NM)，其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(master node)。集群中的其他节点串行地将GM请求发送到主控节点(master node)，而master node将集群成员变更信息广播给集群中的其他节点。组成员关系(group membership)在每次发生集群重置(cluster reconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。 而节点监控NM服务则负责通过skgxn(skgxn-libskgxn.a，提供节点监控的库)与其他厂商的集群软件保持节点信息的一致性。此外NM还提供对我们熟知的网络心跳(Network heartbeat)和磁盘心跳(Disk heartbeat)的维护以保证节点始终存活着。当集群成员没有正常Network heartbeat或Disk heartbeat时NM负责将成员踢出集群，被踢出集群的节点将发生节点重启(reboot)。 NM服务通过OCR中的记录(OCR中记录了Interconnect的信息)来了解其所需要监听和交互的端点，将心跳信息通过网络发送到其他集群成员。同时它也监控来自所有其他集群成员的网络心跳Network heartbeat，每一秒钟都会发生这样的网络心跳，若某个节点的网络心跳在misscount(by the way:10.2.0.1中Linux上默认misscount为60s，其他平台为30s，若使用了第三方vendor clusterware则为600s，但10.2.0.1中未引入disktimeout；10.2.0.4以后misscount为60s,disktimeout为200s；11.2以后misscount为30s:CRS-4678: Successful get misscount 30 for Cluster Synchronization Services,CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services)指定的秒数中都没有被收到的话，该节点被认为已经”死亡”了。NM还负责当其他节点加入或离开集群时初始化集群的重置(Initiates cluster reconfiguration)。 在解决脑裂的场景中，NM还会监控voting disk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下，试想我们的环境中存在大量的节点，以Oracle官方构建过的128个节点的环境为我们的想象空间，当网络故障发生时存在多种的可能性，一种可能性是全局的网络失败，即128个节点中每个节点都不能互相发生网络心跳，此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败，128个节点中被分成多个部分，每个部分中包含多于一个的节点，这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(vote mesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了，这个时候NM Reconfiguration就需要用到voting disk投票磁盘。…

一套11.1.0.7上的Oracle Application Object Library应用程序，在收集schema统计信息时出现了ORA-20001错误，具体错误日志如下: SQL> exec fnd_stats.gather_schema_statistics(‘AP’); PL/SQL procedure successfully completed. SQL> show error No errors. ============================================ Concurrent request error Log ———————————— **Starts**14-APR-2011 02:20:53 **Ends**14-APR-2011 04:40:43 ORA-0000: normal, successful completion +—————————————————————————+ Start of log messages from FND_FILE +—————————————————————————+ In GATHER_SCHEMA_STATS , schema_name= ALL percent= 10 degree = 8 internal_flag= NOBACKUP stats on table AQ$_WF_CONTROL_P is…

前2天有客户报一套10.2.0.3的数据库个别服务进程PGA使用量暴涨，疑似内存泄露(memory leak)；遂提供on-site service，赶到用户现场时问题进程已经消失，系统内存使用量恢复正常，客户之前除了保留了v$process动态性能视图的信息外未抓取其他有用的诊断信息。 查看保存的v$process视图信息可以看到进程991714的PGA内存使用量达到13个G： select spid,program,PGA_USED_MEM,PGA_ALLOC_MEM from v$process; SPID PROGRAM PGA_USED_MEM PGA_ALLOC_MEM ———————— ———————————————— ———— ————- 991714 oracleBTS@oam_app_a 14427510986 14432001786 oracle@oam_app_a@/oracle/product/10.2.0/dbs $ ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 4194304 memory(kbytes) unlimited coredump(blocks) unlimited nofiles(descriptors) unlimited SQL> select x.ksppinm name,y.ksppstvl value 2 from sys.x$ksppi x, sys.x$ksppcv y 3 where x.inst_id=USERENV(‘Instance’) 4 and y.inst_id…

2011 April的Oracle Patch set Update与Critical Patch Update发布了，本次发布包括了对Oracle Database Server, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite and Supply Chain Products Suite, Oracle PeopleSoft Enterprise, and Oracle JDEdwards EntepriseOne, Oracle Siebel CRM, Oracle Industry Applications, Oracle Sun products suite, and Oracle OpenOffice Suite等多个产品的补丁更新。 其中与数据库相关的主要有补丁集更新和紧急补丁更新如下： Database 11.2.0.2上的CPU Patch 11724984, or PSU Patch 11724916…

一套SUNOS 5.10上的单节点10.2.0.3系统出现了ORA-07445: exception encountered: core dump [SIGFPE] [Integer divide by zero] [42788866] [] [] []内部错误，具体trace日志如下: mon_ora_17633.trc Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – Production With the Partitioning, OLAP and Data Mining options ORACLE_HOME = /oracle/oracle/product/10.2.0 System name: SunOS Node name: monitor-a Release: 5.10 Version: Generic_139556-08 Machine: i86pc ksedmp: internal or fatal error ORA-07445: exception…

出于种种原因我们可能需要为已安装的Oracle集群软件修改其使用的公用或私有网络所使用的网络接口(How to Change Interconnect/Public Interface IP or Subnet in Oracle Clusterware)，这些共有或私有网络(public/private network)被保存在ocr中，我们需要以root用户的身份执行oifcfg命令来对这些网络接口信息进行修改: /* 使用ocrdump命令转储ocr信息 */ [oracle@vrh1 ~]$ ocrdump ocr [oracle@vrh1 ~]$ cat ocr [SYSTEM.css.interfaces]UNDEF [SYSTEM.css.interfaces.global]UNDEF [SYSTEM.css.interfaces.global.eth0]UNDEF [SYSTEM.css.interfaces.global.eth0.131|d32|d1|d0]UNDEF [SYSTEM.css.interfaces.global.eth0.131|d32|d1|d0]ORATEXT : public [SYSTEM.css.interfaces.global.eth1]UNDEF [SYSTEM.css.interfaces.global.eth1.131|d33|d1|d0]UNDEF : [SYSTEM.css.interfaces.global.eth1.131|d33|d1|d0]ORATEXT : cluster_interconnect …………. /* 实际上css的misscount参数和voting disk所在的位置也存在ocr文件中 */ [SYSTEM.css.misscount]UB4 (10) : 60 [SYSTEM.css.diskfile]ORATEXT : /dev/raw/raw2 1.首先我们可以通过oifcfg getif了解当前的public/interconnect网络配置情况: [root@vrh1 ~]# who am i…

下午在客户office遭遇了ORA-07274错误，那是一套AIX 5.3上10.2.0.4的2节点RAC系统，乍看到7274还以为是ORA-7445的孪生兄弟，心中暗想10.2.0.4的RAC问题还真是不少: Errors in file /s01/oracle/product/10.2.0/db_1/rdbms/log/prod21_psp0_4272.trc: ORA-07274: spdcr: access error, access to oracle denied. No such file or directory Mon Apr 18 17:05:44 2011 PSP0: terminating instance due to error 7274 Mon Apr 18 17:05:44 2011 Errors in file /s01/oracle/product/10.2.0/db_1/rdbms/log/prod21_lms1_4285.trc: ORA-07274: spdcr: access error, access to oracle denied. Mon Apr 18 17:05:44 2011 Errors in…

Oracle的扛鼎产品Database Software数据库软件12c版本何时会发布？ 就这一问题，我们来回顾一下Oracle数据库产品发布的历史年表: Release Release Date Elapsed Years Oracle 6 1988 Oracle 7 1992 4 Oracle 8 1997 5 Oracle 8i 1998 1 Oracle 9i 2001 3 Oracle 10g 2004 3 Oracle 11g 2007 3 Oracle 12c Unknown till now 4   到11g为止(Oracle 11g的Beta版本最早在2006年招募内部测试者)，Oracle平均每3.6年发布新的一代数据库产品。 根据以往的经验以及一些小道消息(部分来自于Oracle Staff)，我们有理由相信在今年(2011)的第三或第四季度Oracle可能会展开对Database 12c的Beta测试，并且会在2012年的第一季度为其下一代的重量级数据库产品Oracle Database 12c揭开序幕！ 在2012同期可能发布的重量级产品还有Microsoft微软公司的旗舰产品Windows 8。 如果不出意料的话我们有幸在2012-Dec-21之前体验到以上这2款软件，俗套地说:”神马都是浮云啊！“