11g Database Installation flow
Does GATHER_STATS_JOB gather all objects’ stats every time?
周五在一家客户的调优会议中讨论了一个由于统计信息陈旧导致SQL执行计划偏差的问题,这是一个10g的库并且禁用了自动收集统计信息的定时作业GATHER_STATS_JOB;当问及应用程序开发商为何要禁用自动统计信息收集时,开发商的一位工程师说因为该库的数据量较大,考虑到该JOB每天都会将所有大表统计一遍可能要花费大量时间所以予以停用。
这里就存在一个问题,GATHER_STATS_JOB自动统计作业是每次打开都会将数据库中所有的对象的统计信息都收集一遍吗?细心的朋友一定会发觉实际上该JOB的运行时间是时长时短的,同时绝对不是如这位开发工程师所说的会每天都重复统计所有表。
10g的官方文档中对该GATHER_STATS_JOB描述为”The Scheduler runs this job when the maintenance window is opened. By default, the maintenance window opens every night from 10 P.M. to 6 A.M. and all day on weekends.The stop_on_window_close
attribute controls whether the GATHER_STATS_JOB
continues when the maintenance window closes. The default setting for the stop_on_window_close
attribute is TRUE
, causing Scheduler to terminate GATHER_STATS_JOB
when the maintenance window closes. The remaining objects are then processed in the next maintenance window.The GATHER_DATABASE_STATS_JOB_PROC
procedure collects statistics on database objects when the object has no previously gathered statistics or the existing statistics are stale because the underlying object has been modified significantly (more than 10% of the rows).”
以上这段描述还是比较清晰的,MAINTENANCE_WINDOW_GROUP维护窗口组中的工作日窗口(WEEKNIGHT_WINDOW,周一到周五)会在每个工作日的22:00启动并于第二天的6:00结束,在周末该维护窗口组中的周末窗口(WEEKEND_WINDOW)从周六Sat的0点开始并持续48小时(你不难发现这2个窗口在周六0点到6点之间存在overlay,实际的情况是WEEKEND_WINDOW窗口是从周六的0点整到周一的0点,具体可以观察dba_scheduler_windows视图的NEXT_START_DATE列,这里不再赘述)。在数据库一直打开的情况下,GATHER_STATS_JOB会伴随维护窗口一起被启动,默认情况下如果到维护窗口关闭该JOB仍未结束则将被终止(这取决于该JOB的属性
stop_on_window_close),剩下的有待收集信息的对象将在下一个维护窗口中得到处理;如果数据库一直处于关闭的状态,并在某维护窗口的时间范围内该DB被打开,那么相应的维护窗口会被立即激活(ACTIVE),同时
GATHER_STATS_JOB自动作业也会被启动,但该自动作业仅会在一个窗口中自动运行一次(因REASON="ORA-01014: ORACLE shutdown in progress"等原因失败的不算做一次)。
以上介绍了GATHER_STATS_JOB的运行周期,和我们要介绍的问题没有直接的联系。我们这里要谈的是,
GATHER_STATS_JOB自动统计信息收集作业每次启动时是由针对性地收集统计信息的而非对数据库中所有schema下的对象都分析一遍;以上引用的文字中介绍了该JOB挑选分析对象的条件,即:
- 对象之前从未收集过统计信息,或由于某些原因没有统计信息
- 对象的统计信息相对陈旧(stale),是否陈旧的评判标准是由上次收集信息到此次收集期间被修改过的行数超过10%
条件1显得理所当然,剔除一些复杂的情况,一个对象没有统计信息的原因往往是这个对象刚刚被创建或者加载到数据库中,并且用户没有手动地去收集过统计信息,那么Oracle有充分的理由去分析这些对象。而后者则体现了查询优化器对统计信息陈旧度的容忍在超过10%的情况下导致执行计划偏差的可能性将大幅上升,为了遏制这种势头有必要再次统计这些对象。
让我们来看看GATHER_STATS_JOB
针对”陈旧”(stale)统计信息的实际表现:
SQL> select * from global_name; GLOBAL_NAME ------------------------------------ www.askmac.cn SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod PL/SQL Release 10.2.0.1.0 - Production CORE 10.2.0.1.0 Production TNS for Linux: Version 10.2.0.1.0 - Production NLSRTL Version 10.2.0.1.0 - Production SQL> conn maclean/maclean Connected. SQL> create table need_analyze tablespace users as select rownum t1 from dba_objects where rownum<10001; Table created. SQL> select count(*) from need_analyze; COUNT(*) ---------- 10000 SQL> select num_rows,blocks from dba_tables where table_name='NEED_ANALYZE'; NUM_ROWS BLOCKS ---------- ---------- /* 以上创建了一张具有10000行记录的测试用表,因为是新建的所以没有num_rows和blocks等等统计信息 */ /* 手动调用GATHER_STATS_JOB自动作业 */ SQL> begin dbms_scheduler.run_job(job_name=>'SYS.GATHER_STATS_JOB',use_current_session=>true); end; / SQL> select num_rows,blocks from dba_tables where table_name='NEED_ANALYZE'; NUM_ROWS BLOCKS ---------- ---------- 10000 20 /* 删除999条记录,即不到10%的数据 */ SQL> delete need_analyze where rownum<1000; 999 rows deleted. SQL> commit; Commit complete. /* 再次调用GATHER_STATS_JOB */ begin dbms_scheduler.run_job(job_name=>'SYS.GATHER_STATS_JOB',use_current_session=>true); end; / /* 可以看到统计信息并未被更新 */ SQL> select num_rows,blocks from dba_tables where table_name='NEED_ANALYZE'; NUM_ROWS BLOCKS ---------- ---------- 10000 20 SQL> delete need_analyze where rownum<2; 1 row deleted. SQL> commit; Commit complete. SQL> begin dbms_scheduler.run_job(job_name=>'SYS.GATHER_STATS_JOB',use_current_session=>true); end; / 2 3 4 PL/SQL procedure successfully completed. SQL> select num_rows,blocks from dba_tables where table_name='NEED_ANALYZE'; NUM_ROWS BLOCKS ---------- ---------- 10000 20 SQL> delete need_analyze where rownum<2; 1 row deleted. SQL> commit; Commit complete. SQL> begin dbms_scheduler.run_job(job_name=>'SYS.GATHER_STATS_JOB',use_current_session=>true); end; / 2 3 4 PL/SQL procedure successfully completed. SQL> select num_rows,blocks from dba_tables where table_name='NEED_ANALYZE'; NUM_ROWS BLOCKS ---------- ---------- 8999 20 /* 可以看到修改的行数必须超过10%后才会被收集 */
有的朋友肯定要问Oracle是怎么知道某张表是否有过DML操作,而DML操作又涉及到了多少行数据呢?这都是通过表监控特性(a table monitoring facility)来实现的,当初始化参数STATISTICS_LEVEL设置为TYPICAL或ALL时默认启用这种特性。Oracle会默认监控表上的INSERT,UPDATE,DELETE以及表是否被TRUNCATE截断,并记录这些操作数量的近似值到数据字典。我们可以通过访问user_tab_modifications视图来了解这些信息:
SQL> delete need_analyze; 8999 rows deleted. SQL> commit; Commit complete. SQL> select * from user_tab_modifications where table_name='NEED_ANALYZE'; no rows selected /* 从实际的DML操作完成到*_tab_modifications视图到更新可能存在几分钟的延迟 */ /* 通过dbms_stats包中的FLUSH_DATABASE_MONITORING_INFO存储过程可以 将这些监控数据刷新到字典中 */ SQL> exec DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO; PL/SQL procedure successfully completed SQL> col table_name for a20 SQL> select table_name,inserts,updates,deletes,timestamp from user_tab_modifications where table_name='NEED_ANALYZE'; TABLE_NAME INSERTS UPDATES DELETES TIMESTAMP -------------------- ---------- ---------- ---------- --------- NEED_ANALYZE 0 0 8999 26-MAR-11 /* 可以看到*_tab_modifications视图中记录了上次收集统计信息以来 NEED_ANALYZE表上删除过8999条记录,因为测试时仅用少量的串行DML,所以这里十分精确 */ SQL> set autotrace on;
/* 通过以上执行计划可以猜测,monitoring监控数据来源于MON_MODS_ALL$基表上 */ SQL> desc sys.MON_MODS_ALL$; Name Null? Type ----------------------------------------- -------- ---------------------------- OBJ# NUMBER INSERTS NUMBER UPDATES NUMBER DELETES NUMBER TIMESTAMP DATE FLAGS NUMBER DROP_SEGMENTS NUMBER SQL> select * from mon_mods_all$ where obj#=(select object_id from dba_objects where object_name='NEED_ANALYZE'); OBJ# INSERTS UPDATES DELETES TIMESTAMP FLAGS DROP_SEGMENTS ---------- ---------- ---------- ---------- --------- ---------- ------------- 52565 0 0 8999 26-MAR-11 0 0 /* 需要注意的该mon_mods_all$修改监控基表仅记录上次该对象统计信息以来的修改(modify)情况, 并不能做为某张表的实际修改历史记录来利用 */
虽然我们现在对GATHER_STATS_JOB在如何选择分析对象的条件上更清晰了,但是不少朋友可能还是会疑惑难道Oracle不对那些长久以来没有显著修改的表一直不予以收集信息吗?这似乎有悖于我们的常识,试看下例子:
/ * NEED_ANALYZE现在扮演一张静态表,它上次被分析是在2011年3月26日 */ SQL> select last_analyzed from dba_tables where table_name='NEED_ANALYZE'; LAST_ANAL --------- 26-MAR-11 SQL> select sysdate from dual; SYSDATE --------- 26-MAR-11 SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> host [maclean@rh8 ~]$ su - root Password: /* 我们把时钟调快到2012年的12月30日,希望我们能安全度过2012! */ [root@rh8 ~]# date -s "2012-12-30 00:00:00" Sun Dec 30 00:00:00 CST 2012 [root@rh8 ~]# date Sun Dec 30 00:00:01 CST 2012 [maclean@rh8 ~]$ exit exit SQL> startup; ORACLE instance started. Total System Global Area 167772160 bytes Fixed Size 1218292 bytes Variable Size 75499788 bytes Database Buffers 83886080 bytes Redo Buffers 7168000 bytes Database mounted. Database opened. SQL> select sysdate from dual; SYSDATE --------- 30-DEC-12 /* 再次手动调用GATHER_STATS_JOB自动作业 */ SQL> set timing on; SQL> begin dbms_scheduler.run_job(job_name=>'SYS.GATHER_STATS_JOB',use_current_session=>true); end; / 2 3 4 PL/SQL procedure successfully completed. Elapsed: 00:00:00.33 /* :-),运行结束不到1s */ SQL> select last_analyzed from dba_tables where table_name='NEED_ANALYZE'; LAST_ANAL --------- 26-MAR-11
是的,默认情况下GATHER_STATS_JOB不会反复去分析那些静态表,无论过去”多久”。
好了,我们需要对GATHER_STATS_JOB和DBMS_STATS包下属的统计信息收集存储过程(gather_*_stats)有一个饱满的认识,他们远没有我们想象的那么2,实际上这个GATHER_STATS_JOB调用的PROGRAM存储过程是DBMS_STATS.GATHER_DATABASE_STATS_JOB_PROC,虽然这是一个内部存储过程(interal procedure);但实际上它和我们经常手动调用的DBMS_STATS.GATHER_DATABASE_STATS收集整库统计信息的存储过程在以GATHER AUTO选项运行时的行为方式上几乎一致,主要的区别是GATHER_DATABASE_STATS_JOB_PROC总是优先收集那些急需收集统计信息的对象,这保证了在维护窗口关闭之前那些最需要收集的统计信息总是能得到满足。而在手动调用GATHER_DATABASE_STATS等存储过程时因为不需要考虑窗口时间线的限制,而不论优先级。
to be continued ………….
Large Memory Footprints on AIX
Connor Mcdonald-一位Oracle极客为我们分享了一个AIX平台上11g独享服务进程内存占用过量的问题,该问题最后被确认为Bug”11G SERVER PROCESSES CONSUMING MUCH MORE MEMORY THAT 10G OR 9I”,相关文档如下:
Bug 9796810: 11G SERVER PROCESSES CONSUMING MUCH MORE MEMORY THAT 10G OR 9I
Bug 10190759: PROCESSES CONSUMING ADDITIONAL MEMORY DUE TO ‘USLA HEAP’
可以看到上述问题仅发生在从9i/10g升级到11g后,作为一个已确认的升级Bug值得我们大家去关注;最近几年这样的升级会越来越多,同时希望该Bug能在11.2.0.3中修复。
实际上我在10.2.0.3上就遇到过类似的Process Large Footprints问题:用户在打上一个one-off patch[6110331]后单个server process的rss量明显上升,主机的内存使用量大幅提高,虽然这个问题同样提交了SR,但最后没有确认为Bug;用户试图询问Oracle GCS关于rss上升的原因,但语焉而不详。
Search Criteria:AIX 11.2
Memory Footprint For Dedicated Server Processes More Than Doubled After 11g Upgrade On AIX Platform (Doc ID 1246995.1)
1. Have you installed the patch 10190759 ?
Review the note:
Memory Footprint For Dedicated Server Processes More Than Doubled After 11g Upgrade On AIX Platform (Doc ID 1246995.1)
If you have not installed the patch ?
–>>there is one available for 11.2.0.2.0, 11.2.0.2.2, 11.2.0.2.3
If you need me to review the patches you have installed you can upload the opatch listing?
opatch lsinventory -patch -detail
2. If you have already installed the patch 10190759 then
The additional memory seen allocated to oracle processes in the 11.2 release is a consequence of the additional link options added to the oracle link
line, -bexpfull and -brtllib. The two link options were specifically added in 11.2.0.1 to support the online patching feature.
Patch Name or Number: 10190759
Changes in the make file have been implemented such that you can relink without these options (-bexpfull and -brtllib) to avoid
additional memory overhead incurred by adding these options.These changes are available via a one-off patch.
This is a known bug: BUG:10190759 – PROCESSES CONSUMING ADDITIONAL MEMORY DUE TO ‘USLA HEAP’
Install Patch: 10190759
Oracle公司对日本9.0级大地震的哀悼
以下文字引自MOS:
東北地方太平洋沖地震について
この度の東北地方太平洋沖地震に より被災された皆様には心よりお見舞いを申し上げます。
皆様の安全と一日も早い復旧・復興を当社一同、心よりお祈り申し上げます。
当社としましても、できる限りのご支援をさせていただく所存でございます。
お客様、パートナー様への重要なお知らせ
私たちは、お客様とパートナー様を支援することが最優先であると考えております。
今回の輪番停電(計画停電)の状況下におきましても、引き続き24時間・週7日のご支援を提供いたします。
皆様は、従来と変わらないサポート窓口をご利用ください。
Unix平台上OUI启动常见问题
Oracle Universal Installer是一种基于Java的图形界面应用程序,OUI为Oracle软件的安装、管理提供了统一的接口。在Unix平台上安装Oracle database software时,因为实际操作系统的差异,往往会出现OUI无法正常启动的问题,在这里我列出几种常见的启动问题和解决方案。
1.Itanium Montecito processors引起的JRE问题:在安腾平台上执行runInstaller启动OUI时会出现Java HotSpot错误如下:
An unexpected error has been detected by HotSpot Virtual Machine:
SIGILL (0x4) at pc=0x2000000000039a4070 pid=11459 tid=2305843009213968960
原因是9iR2,10gR1/R2自带的JRE在Montecito处理器相关的操作系统如Windows/Linux Itanium上存在Bug,该Bug在SUN JDK版本1.4.2_11(b02)中得到修复;如果遇到以上问题,那么可以follow 以下Metalink文档:
How To Install Oracle RDBMS Software On Itanium Servers With Montecito Processors [ID 400227.1]
How To Identify A Server Which Has Itanium2 (Montecito, Montvale, Tukwila….) Processors Installed [ID 401332.1]
2.DISPLAY显示环境变量设置不当导致图形界面无法显示,可以通过安装例如Xmanager的软件解决;也可以follow以下Metalink文档:
FAQ: X Server Testing and Troubleshooting [ID 153960.1]
3.临时目录/tmp空间应至少有400MB空间,且Oracle software安装用户对该目录有读写权限;在无奈之下可以通过修改用户的临时目录环境必变量$TMP来workaround:
Unable To Start OUI: not enough room in /tmp [ID 339657.1]
How To Set Temporary Space Directory [ID 177902.1]
4.必要时以”-debug”调试选项来调用OUI,通过阅读详细的OUI bootstrap引导流程日志以确认和保证以下2点:
- 在JRE解压阶段没有出现错误
- 在调用java命令启动OUI java图形界面阶段没有出现错误
如以下DEBUG示例:
[maclean@rh8 database]$ cd database [maclean@rh8 database]$ ./runInstaller -debug > debug.log Preparing to launch Oracle Universal Installer from /tmp/OraInstall2011-03-17_03-12-17PM. Please wait ...Archive: ../stage/Components/oracle.jdk/1.5.0.1.1/1/DataFiles/lib.jar inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/dt.jar inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/htmlconverter.jar inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/ir.idl inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/jconsole.jar inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/orb.idl inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/sa-jdi.jar inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/lib/tools.jar Archive: ../stage/Components/oracle.jdk/1.5.0.1.1/1/DataFiles/jre.jar EMPTY_DIR inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/jre/CHANGES inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/jre/COPYRIGHT inflating: /tmp/OraInstall2011-03-17_03-12-17PM/jdk/jre/LICENSE .................. LD_LIBRARY_PATH environment variable : ------------------------------------------------------- Total args: 22 Command line argument array elements ... Arg:0:/tmp/OraInstall2011-03-17_03-12-17PM/jdk/jre/bin/java: Arg:1:-Doracle.installer.library_loc=/tmp/OraInstall2011-03-17_03-12-17PM/oui/lib/linux: Arg:2:-Doracle.installer.oui_loc=/tmp/OraInstall2011-03-17_03-12-17PM/oui: Arg:3:-Doracle.installer.bootstrap=TRUE: Arg:4:-Doracle.installer.startup_location=/home/maclean/Downloads/database/install: Arg:5:-Doracle.installer.jre_loc=/tmp/OraInstall2011-03-17_03-12-17PM/jdk/jre: Arg:6:-Doracle.installer.nlsEnabled="TRUE": Arg:7:-Doracle.installer.prereqConfigLoc= : Arg:8:-Doracle.installer.unixVersion=2.6.35.11-83.fc14.i686: Arg:9:-mx150m: Arg:10:-cp: Arg:11:/tmp/OraInstall2011-03-17_03-12-17PM::/tmp/OraInstall2011-03-17_03-12-17PM/ext/jlib/orai18n-mapping.jar:/tmp/OraInstall2011-03-17_03-12-17PM/ext/jlib/orai18n-utility.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/OraInstaller.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/oneclick.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/xmlparserv2.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/share.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/OraInstallerNet.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/emCfg.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/OraPrereq.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/jsch.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/ssh.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/remoteinterfaces.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/http_client.jar:../stage/Components/oracle.swd.opatch/11.1.0.6.0/1/DataFiles/jlib/opatch.jar:../stage/Components/oracle.swd.opatch/11.1.0.6.0/1/DataFiles/jlib/opatchactions.jar:../stage/Components/oracle.swd.opatch/11.1.0.6.0/1/DataFiles/jlib/opatchprereq.jar:../stage/Components/oracle.swd.opatch/11.1.0.6.0/1/DataFiles/jlib/opatchutil.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstImages.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_de.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_es.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_fr.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_it.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_ja.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_ko.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_pt_BR.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_zh_CN.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/InstHelp_zh_TW.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/oracle_ice.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/help4.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/help4-nls.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/ewt3.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/ewt3-swingaccess.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/ewt3-nls.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/swingaccess.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/classes12.jar::/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/jewt4.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/jewt4-nls.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/orai18n-collation.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/orai18n-mapping.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/ojmisc.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/xml.jar:/tmp/OraInstall2011-03-17_03-12-17PM/oui/jlib/srvm.jar: Arg:12:oracle.sysman.oii.oiic.OiicInstaller: Arg:13:-scratchPath: Arg:14:/tmp/OraInstall2011-03-17_03-12-17PM: Arg:15:-sourceLoc: Arg:16:/home/maclean/Downloads/database/install/../stage/products.xml: Arg:17:-sourceType: Arg:18:network: Arg:19:-timestamp: Arg:20:2011-03-17_03-12-07PM: Arg:21:-debug: ------------------------------------------------------- Initializing Java Virtual Machine from /tmp/OraInstall2011-03-17_03-12-07PM/jdk/jre/bin/java. Please wait... [maclean@rh8 database]$ Oracle Universal Installer, Version 11.1.0.6.0 Production Copyright (C) 1999, 2007, Oracle. All rights reserved.
若以上JRE解压顺利完成但OUI仍无法启动图形欢迎界面(一般来说由java命令失败引起),那么很有可能是安装工具自带的JRE在目标系统上无法正常工作。建议客户自行安装目标系统上最新可用的JDK软件,并使用runInstaller的”-jreloc”选项以workaround。
5.为了进一步确认JRE的问题,我们可能需要将安装介质中自带的JRE手动解压出来并测试其java命令的可用性;可以通过如下流程测试:
/* 首先通过oraparam.ini配置文件了解介质自带JRE jar包所在路径 */ [maclean@rh8 tmp]$ cat database/install/oraparam.ini |grep JRE_LOCATION JRE_LOCATION=../stage/Components/oracle.swd.jre/1.4.2.8.0/1/DataFiles [maclean@rh8 tmp]$ ls database/stage/Components/oracle.swd.jre/1.4.2.8.0/1/DataFiles/ filegroup1.jar filegroup2.jar filegroup3.jar filegroup4.jar filegroup5.jar [maclean@rh8 tmp]$ mkdir /tmp/jre_test [maclean@rh8 tmp]$ cp database/stage/Components/oracle.swd.jre/1.4.2.8.0/1/DataFiles/*.jar /tmp/jre_test [maclean@rh8 tmp]$ cd /tmp/jre_test [maclean@rh8 jre_test]$ unzip filegroup1.jar Archive: filegroup1.jar inflating: jre/1.4.2/bin/ControlPanel inflating: jre/1.4.2/bin/java inflating: jre/1.4.2/bin/java_vm inflating: jre/1.4.2/bin/keytool inflating: jre/1.4.2/bin/kinit inflating: jre/1.4.2/bin/klist inflating: jre/1.4.2/bin/ktab inflating: jre/1.4.2/bin/orbd inflating: jre/1.4.2/bin/policytool inflating: jre/1.4.2/bin/rmid inflating: jre/1.4.2/bin/rmiregistry inflating: jre/1.4.2/bin/servertool inflating: jre/1.4.2/bin/tnameserv /* 使用unzip命令依次解压copy过来的jar文件,会出现jre目录 */ [maclean@rh8 jre_test]$ ls filegroup1.jar filegroup2.jar filegroup3.jar filegroup4.jar filegroup5.jar jre [maclean@rh8 jre_test]$ cd jre/1.4.2/bin [maclean@rh8 bin]$ chmod u+x java [maclean@rh8 bin]$ ./java -version java version "1.4.2_08" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03) Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode) /* 可以看到在我们的场景中java命令运行正常 */
若以上测试的最后结果中java命令出错则说明Oracle安装介质自带的JRE存在问题,这可能是个例,在安装介质传输过程中出现网络错误所导致的文件损坏可能引起以上问题;可以通过checksum等方式验证安装介质包/ISO文件无误。若经过验证发现安装介质没有损坏,那么很有可能是自带JRE在目标操作系统上无法正常运行,用户可以到java.sun.com网站去下载指定平台最新可用的JDK软件,在成功安装后JDK后再次尝试以”-jreloc”选项启动runInstaller程序,命令示例如下:
./runInstaller -debug -jreLoc <JRE Install Home>
Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)
This script is intended to provide a user friendly output to diagnose the status of the database either before (or) after upgrade. The script will create a file called db_upg_diag__.log.
-- - - - - - - - - - - - - - Script begins here - - - - - - - - - - - - - - col TODAY NEW_VALUE _DATE col VERSION NEW_VALUE _VERSION set termout off select to_char(SYSDATE,'fmMonth DD, YYYY') TODAY from DUAL; select version from v$instance; set termout on set echo off set feedback off set head off set verify off Prompt PROMPT Enter location for Spooled output: Prompt DEFINE log_path = &1 column timecol new_value timestamp column spool_extension new_value suffix SELECT to_char(sysdate,'dd-Mon-yyyy_hhmi') timecol,'.log' spool_extension FROM sys.dual; column output new_value dbname SELECT value || '_' output FROM v$parameter WHERE name = 'db_name'; spool &log_path/db_upg_diag_&&dbname&×tamp&&suffix set linesize 150 set pages 100 set trim on set trims on col Compatible for a35 col comp_id for a12 col comp_name for a40 col org_version for a11 col prv_version for a11 col owner for a12 col object_name for a40 col object_type for a40 col Wordsize for a25 col Metadata for a8 col 'Initial DB Creation Info' for a35 col 'Total Invalid JAVA objects' for a45 col 'Role' for a30 col 'User Existence' for a27 col "JAVAVM TESTING" for a15 Prompt Prompt set feedback off head off select LPAD('*** Start of LogFile ***',50) from dual; select LPAD('Oracle Database Upgrade Diagnostic Utility',44)|| LPAD(TO_CHAR(SYSDATE, 'MM-DD-YYYY HH24:MI:SS'),26) from dual; Prompt Prompt =============== Prompt Database Uptime Prompt =============== SELECT to_char(startup_time, 'HH24:MI DD-MON-YY') "Startup Time" FROM v$instance; Prompt Prompt ================= Prompt Database Wordsize Prompt ================= SELECT distinct('This is a ' || (length(addr)*4) || '-bit database') "WordSize" FROM v$process; Prompt Prompt ================ Prompt Software Version Prompt ================ SELECT * FROM v$version; Prompt Prompt ============= Prompt Compatibility Prompt ============= SELECT 'Compatibility is set as '||value Compatible FROM v$parameter WHERE name ='compatible'; Prompt Prompt ================ Prompt Component Status Prompt ================ Prompt SET SERVEROUTPUT ON; DECLARE ORG_VERSION varchar2(12); PRV_VERSION varchar2(12); P_VERSION VARCHAR2(10); BEGIN SELECT version INTO p_version FROM registry$ WHERE cid='CATPROC' ; IF SUBSTR(p_version,1,5) = '9.2.0' THEN DBMS_OUTPUT.PUT_LINE(RPAD('Comp ID', 8) ||RPAD('Component',35)|| RPAD('Status',10) ||RPAD('Version', 15)); DBMS_OUTPUT.PUT_LINE(RPAD(' ',8,'-') ||RPAD(' ',35,'-')|| RPAD(' ',10,'-') ||RPAD(' ',15,'-')); FOR x in (SELECT SUBSTR(dr.comp_id,1,8) comp_id, SUBSTR(dr.comp_name,1,35) comp_name, dr.status Status,SUBSTR(dr.version,1,15) version FROM dba_registry dr,registry$ r WHERE dr.comp_id=r.cid and dr.comp_name=r.cname ORDER BY 1) LOOP DBMS_OUTPUT.PUT_LINE(RPAD(SUBSTR(x.comp_id,1,8),8) || RPAD(SUBSTR(x.comp_name,1,35),35)|| RPAD(x.status,10) || RPAD(x.version, 15)); END LOOP; ELSIF SUBSTR(p_version,1,5) != '9.2.0' THEN DBMS_OUTPUT.PUT_LINE(RPAD('Comp ID', 8) ||RPAD('Component',35)|| RPAD('Status',10) ||RPAD('Version', 15)|| RPAD('Org_Version',15)||RPAD('Prv_Version',15)); DBMS_OUTPUT.PUT_LINE(RPAD(' ',8,'-') ||RPAD(' ',35,'-')|| RPAD(' ',10,'-')||RPAD(' ',15,'-')||RPAD(' ',15,'-')|| RPAD(' ',15,'-')); FOR y in (SELECT SUBSTR(dr.comp_id,1,8) comp_id, SUBSTR(dr.comp_name,1,35) comp_name, dr.status Status, SUBSTR(dr.version,1,11) version,org_version,prv_version FROM dba_registry dr,registry$ r WHERE dr.comp_id=r.cid and dr.comp_name=r.cname ORDER BY 1) LOOP DBMS_OUTPUT.PUT_LINE(RPAD(substr(y.comp_id,1,8), 8) || RPAD(substr(y.comp_name,1,35),35)||RPAD(y.status,10) || RPAD(y.version, 15)||RPAD(y.org_version,15)||RPAD(y.prv_version,15)); END LOOP; END IF; END; / SET SERVEROUTPUT OFF Prompt Prompt Prompt ====================================================== Prompt List of Invalid Database Objects Owned by SYS / SYSTEM Prompt ====================================================== Prompt set head on SELECT case count(object_name) WHEN 0 THEN 'There are no Invalid Objects' ELSE 'There are '||count(object_name)||' Invalid objects' END "Number of Invalid Objects" FROM dba_objects WHERE status='INVALID' AND owner in ('SYS','SYSTEM'); Prompt DOC ################################################################ If there are no Invalid objects below will result in zero rows. ################################################################ # Prompt set feedback on SELECT owner,object_name,object_type FROM dba_objects WHERE status='INVALID' AND owner in ('SYS','SYSTEM') ORDER BY owner,object_type; set feedback off Prompt Prompt ================================ Prompt List of Invalid Database Objects Prompt ================================ Prompt set head on SELECT case count(object_name) WHEN 0 THEN 'There are no Invalid Objects' ELSE 'There are '||count(object_name)||' Invalid objects' END "Number of Invalid Objects" FROM dba_objects WHERE status='INVALID' AND owner not in ('SYS','SYSTEM'); Prompt DOC ################################################################ If there are no Invalid objects below will result in zero rows. ################################################################ # Prompt set feedback on SELECT owner,object_name,object_type FROM dba_objects WHERE status='INVALID' AND owner not in ('SYS','SYSTEM') ORDER BY owner,object_type; set feedback off Prompt Prompt ============================================================== Prompt Identifying whether a database was created as 32-bit or 64-bit Prompt ============================================================== Prompt DOC ########################################################################### Result referencing the string 'B023' ==> Database was created as 32-bit Result referencing the string 'B047' ==> Database was created as 64-bit When String results in 'B023' and when upgrading database to 10.2.0.3.0 (64-bit) , For known issue refer below articles Note 412271.1 ORA-600 [22635] and ORA-600 [KOKEIIX1] Reported While Upgrading Or Patching Databases To 10.2.0.3 Note 579523.1 ORA-600 [22635], ORA-600 [KOKEIIX1], ORA-7445 [KOPESIZ] and OCI-21500 [KOXSIHREAD1] Reported While Upgrading To 11.1.0.6 ########################################################################### # Prompt SELECT SUBSTR(metadata,109,4) "Metadata", CASE SUBSTR(metadata,109,4) WHEN 'B023' THEN 'Database was created as 32-bit' WHEN 'B047' THEN 'Database was created as 64-bit' ELSE 'Metadata not Matching' END "Initial DB Creation Info" FROM sys.kopm$; Prompt Prompt =================================================== Prompt Number of Duplicate Objects Owned by SYS and SYSTEM Prompt =================================================== Prompt Prompt Counting duplicate objects .... Prompt SELECT count(1) FROM dba_objects WHERE object_name||object_type in (SELECT object_name||object_type from dba_objects where owner = 'SYS') and owner = 'SYSTEM'; Prompt Prompt ========================================= Prompt Duplicate Objects Owned by SYS and SYSTEM Prompt ========================================= Prompt Prompt Querying duplicate objects .... Prompt SELECT object_name, object_type FROM dba_objects WHERE object_name||object_type in (SELECT object_name||object_type FROM dba_objects WHERE owner = 'SYS') AND owner = 'SYSTEM'; Prompt DOC ################################################################################ If any objects found please follow below article. Note 1030426.6 How to Clean Up Duplicate Objects Owned by SYS and SYSTEM schema Read the Exceptions carefully before taking actions. ################################################################################ # Prompt Prompt ================ Prompt JVM Verification Prompt ================ Prompt SET SERVEROUTPUT ON DECLARE V_CT NUMBER; P_VERSION VARCHAR2(10); BEGIN -- If so, get the version of the JAVAM component EXECUTE IMMEDIATE 'SELECT version FROM registry$ WHERE cid=''JAVAVM'' AND status <> 99' INTO p_version; SELECT count(*) INTO v_ct FROM dba_objects WHERE object_type LIKE '%JAVA%' AND owner='SYS'; IF SUBSTR(p_version,1,5) = '8.1.7' THEN IF v_ct>=6787 THEN DBMS_OUTPUT.PUT_LINE('JAVAVM - Installed properly'); ELSE DBMS_OUTPUT.PUT_LINE('JAVAVM - Not Installed properly'); END IF; ELSIF SUBSTR(p_version,1,5) = '9.0.1' THEN IF v_ct>=8585 THEN DBMS_OUTPUT.PUT_LINE('JAVAVM - Installed properly'); ELSE DBMS_OUTPUT.PUT_LINE('JAVAVM - Not Installed properly'); END IF; ELSIF SUBSTR(p_version,1,5) = '9.2.0' THEN IF v_ct>=8585 THEN DBMS_OUTPUT.PUT_LINE('JAVAVM - Installed properly'); ELSE DBMS_OUTPUT.PUT_LINE('JAVAVM - Not Installed properly'); END IF; ELSIF SUBSTR(p_version,1,6) = '10.1.0' THEN IF v_ct>=13866 THEN DBMS_OUTPUT.PUT_LINE('JAVAVM - Installed properly'); ELSE DBMS_OUTPUT.PUT_LINE('JAVAVM - Not Installed properly'); END IF; ELSIF SUBSTR(p_version,1,6) = '10.2.0' THEN IF v_ct>=14113 THEN DBMS_OUTPUT.PUT_LINE('JAVAVM - Installed properly'); ELSE DBMS_OUTPUT.PUT_LINE('JAVAVM - Not Installed properly'); END IF; END IF; EXCEPTION WHEN NO_DATA_FOUND THEN DBMS_OUTPUT.PUT_LINE('JAVAVM - NOT Installed. Below results can be ignored'); END; / SET SERVEROUTPUT OFF Prompt Prompt ================================================ Prompt Checking Existence of Java-Based Users and Roles Prompt ================================================ Prompt DOC ################################################################################ There should not be any Java Based users for database version 9.0.1 and above. If any users found, it is faulty JVM. ################################################################################ # Prompt SELECT CASE count(username) WHEN 0 THEN 'No Java Based Users' ELSE 'There are '||count(*)||' JAVA based users' END "User Existence" FROM dba_users WHERE username LIKE '%AURORA%' AND username LIKE '%OSE%'; Prompt DOC ############################################################### Healthy JVM Should contain Six Roles. If there are more or less than six role, JVM is inconsistent. ############################################################### # Prompt SELECT CASE count(role) WHEN 0 THEN 'No JAVA related Roles' ELSE 'There are '||count(role)||' JAVA related roles' END "Role" FROM dba_roles WHERE role LIKE '%JAVA%'; Prompt Prompt Roles Prompt SELECT role FROM dba_roles WHERE role LIKE '%JAVA%'; set head off Prompt Prompt ========================================= Prompt List of Invalid Java Objects owned by SYS Prompt ========================================= SELECT CASE count(*) WHEN 0 THEN 'There are no SYS owned invalid JAVA objects' ELSE 'There are '||count(*)||' SYS owned invalid JAVA objects' END "Total Invalid JAVA objects" FROM dba_objects WHERE object_type LIKE '%JAVA%' AND status='INVALID' AND owner='SYS'; Prompt DOC ################################################################# Check the status of the main JVM interface packages DBMS_JAVA and INITJVMAUX and make sure it is VALID. If there are no Invalid objects below will result in zero rows. ################################################################# # Prompt set feedback on SELECT owner,object_name,object_type FROM dba_objects WHERE object_type LIKE '%JAVA%' AND status='INVALID' AND owner='SYS'; set feedback off Prompt Prompt INFO: Below query should succeed with 'foo' as result. set heading on select dbms_java.longname('foo') "JAVAVM TESTING" from dual; set heading off Prompt set feedback off head off select LPAD('*** End of LogFile ***',50) from dual; set feedback on head on Prompt spool off Prompt set heading off set heading off set feedback off select 'Upload db_upg_diag_&&dbname&×tamp&&suffix from "&log_path" directory' from dual; set heading on set feedback on Prompt -- - - - - - - - - - - - - - - - Script ends here - - - - - - - - - - - - - -
介绍dbms_registry PL/SQL程序包
[gview file=”https://www.askmac.cn/wp-content/uploads/2011/03/介绍dbms_registry-PLSQL程序包1.ppt”]
11gr1 installation failed on Fedora 14 with libnnz11.so could not read symbols
尝试把桌面迁移到Fedora 14上,在安装11g r1数据库软件时遭遇了libnnz11.so: could not read symbols: Invalid operation错误,OUI部分日志如下:
INFO: gcc -o /u01/app/maclean/product/11.1.0/db_1/sysman/lib/emdctl -L/u01/app/maclean/product/11.1.0/db_1/lib/ -L/u01/app/maclean/product/11.1.0/db_1/sysman/lib/ -L/u01/app/maclean/product/11.1.0/db_1/lib/stubs/ `cat /u01/app/maclean/product/11.1.0/db_1/lib/sysliblist` -Wl,-rpath,/u01/app/maclean/product/11.1.0/db_1/lib -lm `cat /u01/app/maclean/product/11.1.0/db_1/lib/sysliblist` -ldl -lm -L/u01/app/maclean/product/11.1.0/db_1/lib /u01/app/maclean/product/11.1.0/db_1/sysman/lib//s0nmectl.o -lnmectl - INFO: lclntsh -L/u01/app/maclean/product/11.1.0/db_1/lib -L/u01/app/maclean/product/11.1.0/db_1/sysman/lib/ -lnmemso -lcore11 -Wl,-rpath,/u01/app/maclean/product/11.1.0/db_1/lib/:/u01/app/maclean/product/11.1.0/db_1/sysman/lib/:/u01/app/maclean/product/11.1.0/db_1/jdk/jre/lib/i386/client:/u01/app/maclean/product/11.1.0/db_1/jdk/jre/lib/i386 -L/u01/app/maclean/product/11.1.0/db_1/jdk/jre/lib/i386/client -L/u01/app/maclean/product/11.1.0/db_1/jdk/jre/lib/i386 -z lazyload -ljava -ljvm -lverify -z nolazyload -Wl,-rp INFO: ath,/u01/app/maclean/product/11.1.0/db_1/lib/:/u01/app/maclean/product/11.1.0/db_1/sysman/lib/:/u01/app/maclean/product/11.1.0/db_1/jdk/jre/lib/i386/client:/u01/app/maclean/product/11.1.0/db_1/jdk/jre/lib/i386 -Wl,--allow-shlib-undefined `cat /u01/app/maclean/product/11.1.0/db_1/lib/sysliblist` -ldl -lm INFO: /usr/bin/ld: /u01/app/maclean/product/11.1.0/db_1/sysman/lib//libnmectl.a(nmectlt.o): undefined reference to symbol 'B_DestroyKeyObject' /usr/bin/ld: note: 'B_DestroyKeyObject' is defined in DSO /u01/app/maclean/product/11.1.0/db_1/lib/libnnz11.so so try adding it to the linker command line /u01/app/maclean/product/11.1.0/db_1/lib/libnnz11.so: could not read symbols: Invalid operation INFO: collect2: ld returned 1 exit status INFO: make[1]: *** [/u01/app/maclean/product/11.1.0/db_1/sysman/lib/emdctl] Error 1 INFO: make[1]: Leaving directory `/u01/app/maclean/product/11.1.0/db_1/sysman/lib' INFO: make: *** [emdctl] Error 2 INFO: End output from spawned process. INFO: ---------------------------------- INFO: Exception thrown from action: make Exception Name: MakefileException Exception String: Error in invoking target 'agent tclexec' of makefile '/u01/app/maclean/product/11.1.0/db_1/sysman/lib/ins_emagent.mk'. See '/u01/oraInventory/logs/installActions2011-03-15_09-59-46PM.log' for details. Exception Severity: 1
google了一下网上的解决方法,需要手动修改make文件ins_emagent.mk,该文件位于$ORACLE_HOME/sysman/lib/ins_emagent.mk,找出该文件中的以下部分并修改:
$(SYSMANBIN)emdctl: $(MK_EMAGENT_NMECTL) 修改为 $(SYSMANBIN)emdctl: $(MK_EMAGENT_NMECTL) -lnnz11 之后重新编译该agent部分模块: make -f ins_emagent.mk "agent"
Oracle中可以nologging执行的操作
redo重做日志是Oracle数据库恢复(recovery)的基础;但在很多情况下可以通过禁用重做日志的产生来加速SQL语句的完成,也就是我们所说的可nologging化的操作,这些操作大多是或串行的或并行的数据载入。
那么哪些操作是允许被nologging化的呢?首先需要注意的是普通的DML操作,即:常规insert,update,和delete(以及merge)总是不能被nologging执行的。但以下SQL语句则可以以nologging选项执行:
- direct load (SQL*Loader)
- direct load INSERT (using APPEND hint)
- CREATE TABLE … AS SELECT
- CREATE INDEX
- ALTER TABLE … MOVE PARTITION
- ALTER TABLE … SPLIT PARTITION
- ALTER INDEX … SPLIT PARTITION
- ALTER INDEX … REBUILD
- ALTER INDEX … REBUILD PARTITION
- INSERT, UPDATE, and DELETE on LOBs in NOCACHE NOLOGGING mode stored out of line
以上列出的语句,其产生undo和redo重做日志几乎可以完全禁绝。因为都是数据载入语句(或者装载索引)其所产生的新的区间(new extent)在执行过程中被标记为无效的(invalid),同时仅有少量的由数据字典变更引起的重做日志会产生。
【Oracle ASM数据恢复】ORA-15032、ORA-15075 ASM DISK PATH Problem
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
SQL> alter diskgroup datadg add disk ‘/dev/asm-diskh’ rebalance power 2;
alter diskgroup datadg add disk ‘/dev/asm-diskh’ rebalance power 2
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15075: disk(s) are not visible cluster-wide
SQL> alter diskgroup datadg add disk ‘/dev/asm-diskh’ ;
alter diskgroup datadg add disk ‘/dev/asm-diskh’
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15075: disk(s) are not visible cluster-wide
15032, 00000, “not all alterations performed”
// *Cause: At least one ALTER DISKGROUP action failed.
// *Action: Check the other messages issued along with this summary error.
//
15075, 00000, “disk(s) are not visible cluster-wide”
// *Cause: An ALTER DISKGROUP ADD DISK command specified a disk that could
// not be discovered by one or more nodes in a RAC cluster
// configuration.
// *Action: Determine which disks are causing the problem from the
// GV$ASM_DISK fixed view. Check operating system permissions
// for the device and the storage sub-system configuration on
// each node in a RAC cluster that cannot identify the disk.
//
SQL> alter diskgroup datadg add disk ‘/dev/asm-diskh’ ;
Diskgroup altered.
1节点
1* select GROUP_NUMBER,DISK_NUMBER,path,HEADER_STATUS from v$ASM_DISK order by 1,2
SQL> /
GROUP_NUMBER DISK_NUMBER PATH HEADER_STATUS
———— ———– ——————– ————————————
1 0 /dev/asm-diske MEMBER
1 1 /dev/asm-diskf MEMBER
1 2 /dev/asm-diskg MEMBER
1 5 /dev/asm-diskh MEMBER
2 0 /dev/asm-diskb MEMBER
2 1 /dev/asm-diskc MEMBER
2 2 /dev/asm-diskd MEMBER
7 rows selected.
2节点
SQL> select GROUP_NUMBER,DISK_NUMBER,path,HEADER_STATUS from v$ASM_DISK order by 1,2;
GROUP_NUMBER DISK_NUMBER PATH HEADER_STATUS
———— ———– ——————– ————————————
1 0 /dev/asm-diske MEMBER
1 1 /dev/asm-diskf MEMBER
1 2 /dev/asm-diskg MEMBER
1 5 /dev/asm-diskz MEMBER
2 0 /dev/asm-diskb MEMBER
2 1 /dev/asm-diskc MEMBER
2 2 /dev/asm-diskd MEMBER
7 rows selected.
NOTE: disk validation pending for group 1/0x5448421c (DATADG)
SUCCESS: validated disks for 1/0x5448421c (DATADG)
NOTE: disk validation pending for group 1/0x5448421c (DATADG)
NOTE: Assigning number (1,5) to disk (/dev/asm-diskz)
SUCCESS: validated disks for 1/0x5448421c (DATADG)
NOTE: membership refresh pending for group 1/0x5448421c (DATADG)
Tue Mar 12 20:36:59 2013
GMON querying group 1 at 7 for pid 18, osid 2763
NOTE: cache opening disk 5 of grp 1: DATADG_0005 path:/dev/asm-diskz
GMON querying group 1 at 8 for pid 18, osid 2763
SUCCESS: refreshed membership for 1/0x5448421c (DATADG)
Tue Mar 12 20:37:02 2013
NOTE: Attempting voting file refresh on diskgroup DATADG
Tue Mar 12 20:37:06 2013
ALTER SYSTEM SET local_listener=’ (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.184)(PORT=1521))))’ SCOPE=MEMORY SID=’+ASM2′;
Tue Mar 12 20:37:54 2013
NOTE: membership refresh pending for group 1/0x5448421c (DATADG)
Tue Mar 12 20:37:56 2013
GMON querying group 1 at 9 for pid 18, osid 2763
SUCCESS: refreshed membership for 1/0x5448421c (DATADG)
NOTE: Attempting voting file refresh on diskgroup DATADG
[grid@vmac2 ~]$ kfed read /dev/asm-diskz
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 2147483653 ; 0x008: disk=5
kfbh.check: 1582693660 ; 0x00c: 0x5e55fd1c
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum: 5 ; 0x024: 0x0005
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATADG_0005 ; 0x028: length=11
kfdhdb.grpname: DATADG ; 0x048: length=6
kfdhdb.fgname: DATADG_0005 ; 0x068: length=11
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32984459 ; 0x0a8: HOUR=0xb DAYS=0xc MNTH=0x3 YEAR=0x7dd
kfdhdb.crestmp.lo: 2470649856 ; 0x0ac: USEC=0x0 MSEC=0xc8 SECS=0x34 MINS=0x24
kfdhdb.mntstmp.hi: 32984459 ; 0x0b0: HOUR=0xb DAYS=0xc MNTH=0x3 YEAR=0x7dd
kfdhdb.mntstmp.lo: 2470650880 ; 0x0b4: USEC=0x0 MSEC=0xc9 SECS=0x34 MINS=0x24
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 5120 ; 0x0c4: 0x00001400
kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 0 ; 0x0d4: 0x00000000
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32983191 ; 0x0e4: HOUR=0x17 DAYS=0x4 MNTH=0x2 YEAR=0x7dd
kfdhdb.grpstmp.lo: 2328331264 ; 0x0e8: USEC=0x0 MSEC=0x1e1 SECS=0x2c MINS=0x22
kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000
kfdhdb.vfend: 0 ; 0x0f0: 0x00000000
kfdhdb.spfile: 0 ; 0x0f4: 0x00000000
kfdhdb.spfflg: 0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[0]: 0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x100: 0x00000000
kfdhdb.ub4spare[2]: 0 ; 0x104: 0x00000000
kfdhdb.ub4spare[3]: 0 ; 0x108: 0x00000000
kfdhdb.ub4spare[4]: 0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[5]: 0 ; 0x110: 0x00000000
kfdhdb.ub4spare[6]: 0 ; 0x114: 0x00000000
kfdhdb.ub4spare[7]: 0 ; 0x118: 0x00000000
kfdhdb.ub4spare[8]: 0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[9]: 0 ; 0x120: 0x00000000
kfdhdb.ub4spare[10]: 0 ; 0x124: 0x00000000
kfdhdb.ub4spare[11]: 0 ; 0x128: 0x00000000
kfdhdb.ub4spare[12]: 0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[13]: 0 ; 0x130: 0x00000000
kfdhdb.ub4spare[14]: 0 ; 0x134: 0x00000000
kfdhdb.ub4spare[15]: 0 ; 0x138: 0x00000000
kfdhdb.ub4spare[16]: 0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[17]: 0 ; 0x140: 0x00000000
kfdhdb.ub4spare[18]: 0 ; 0x144: 0x00000000
kfdhdb.ub4spare[19]: 0 ; 0x148: 0x00000000
kfdhdb.ub4spare[20]: 0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[21]: 0 ; 0x150: 0x00000000
kfdhdb.ub4spare[22]: 0 ; 0x154: 0x00000000
kfdhdb.ub4spare[23]: 0 ; 0x158: 0x00000000
kfdhdb.ub4spare[24]: 0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[25]: 0 ; 0x160: 0x00000000
kfdhdb.ub4spare[26]: 0 ; 0x164: 0x00000000
kfdhdb.ub4spare[27]: 0 ; 0x168: 0x00000000
kfdhdb.ub4spare[28]: 0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[29]: 0 ; 0x170: 0x00000000
kfdhdb.ub4spare[30]: 0 ; 0x174: 0x00000000
kfdhdb.ub4spare[31]: 0 ; 0x178: 0x00000000
kfdhdb.ub4spare[32]: 0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[33]: 0 ; 0x180: 0x00000000
kfdhdb.ub4spare[34]: 0 ; 0x184: 0x00000000
kfdhdb.ub4spare[35]: 0 ; 0x188: 0x00000000
kfdhdb.ub4spare[36]: 0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[37]: 0 ; 0x190: 0x00000000
kfdhdb.ub4spare[38]: 0 ; 0x194: 0x00000000
kfdhdb.ub4spare[39]: 0 ; 0x198: 0x00000000
kfdhdb.ub4spare[40]: 0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[41]: 0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[42]: 0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[43]: 0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[44]: 0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[45]: 0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[46]: 0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[47]: 0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[48]: 0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[49]: 0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[50]: 0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[51]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[52]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[53]: 0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000
以上 ORA-15032、ORA-15075 ASM DISK PATH Problem就是由于LUN配置不当,导致LUN并非在RAC的多个节点上可见所导致的。
对于此类问题 首先确认已经合理设置了设备文件权限。
接着做如下操作来进一步确认:
echo "======================" > fakedata.txt
date >> fakedata.txt
echo "======================" >> fakedata.txt
dd if=/home/oracle/test/fakedata.txt of=你要检验的设备名 bs=4096 count=1 conv=notrunc
之后使用od命令在多个节点上查看该设备上的内容即可确认在集群环境中该设备是否指向同一个LUN
od -c 你要检验的设备名 | more