很久没有更新BLOG了,无论出于什么样的原因,我都十分汗颜。向各位关注老熊一亩三分地的朋友们说声对不起了。

本文讲述端午节期间一位朋友在AIX 6.1上安装Oracle 10g RAC时死活不出现节点选择界面的问题的处理过程,希望对一些朋友有所帮助。在正文开始之前,向在端午期间仍然奋战在DBA工作一线的朋友们致敬^_^

对这个问题,是通过朋友的QQ远程协助处理的,因此在下面的过程描述中缺乏一些界面或者说是代码。不过我尽量将处理的思路描述清楚。

众所周知,在安装10g RAC时,需要先安装CRS,即Oracle Cluster,再安装Oracle RDBMS Software。安装这2部分都应该会出现选择安装节点的界面,本文描述的问题是出现在RDBMS部分出现的。下面是当时具体的处理过程:

  • 安装界面不出现节点选择界面,很多时候是由于/etc/hosts配置不当,以及rsh或ssh配置不当所导致。而之前CRS已经安装妥当,同时crs_stat命令检查CRS的各个资源也运行正常,使用crsctl check命令检查cluster也显示正常。那么hosts和rsh等问题应该是不会存在的,否则CRS也不能正确安装和运行。虽然如此,我还是检查了一下这2方面,没有发现任何问题。
  • 在OUI安装界面,在选择Oracle HOME时,发现主机上已经有2个HOME,分别是/oracle/product/10.2.0/crs和/oracle/product/10.2.0/cluster,此系统安装的朋友解释是在安装CRS时,出现了异常,然后重新安装到另一个目录成功。crs那个目录是废弃的HOME,cluster那个是正在运行的CRS的HOME。
  • 对于这样的问题,我习惯的做法是,先检查能够容易想到的,如果根据经验和能够想到的可能出现的问题进行排查后,仍然不能解决问题,那么我就会参考文档,按文档一步一步去检查。在此期间,我参考了Metalink上的文档《Minimum Software Versions and Patches Required to Support Oracle Products on IBM Power Systems [ID 282036.1]》、《RAC Assurance Support Team RAC Starter Kit and Best Practices (AIX) [ID 811293.1]》、《Oracle Database on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) [ID 169706.1]》三篇文章。同时也参考了《Oracle Database 10gR2 RAC on AIX Install Guide》(本文可以自MOS 811293.1文章中的连接下载)。根据文档重点考虑到了AIX 6.1这个新版本,同时应用了文档中提到的rootpre.sh补丁。问题仍然没有解决。

其实根据安装的经验,安装RAC时问题通常会出现在CRS安装部分,而RDBMS这部分很少有遇到问题。接下来:

  • 在安装的时候还发现有java的报错,在网上搜索一番这个错误,未果。这个错误与安装问题可能有很大的关联,但是不知道问题出现在哪里,是JAVA的问题?是安装程序的问题?还是缺少什么组件?或者是操作系统的问题,不得而知。
  • 根据MOS文档《How to trace OUI Note:269837.1》,开启安装程序的跟踪:
    ./runInstaller -J-DTRACING.ENABLED=true -J-DTRACING.LEVEL=2
    从结果来看,安装程序获取了ocr的路径,同时获取了其他一些属性。在此之后,就报出了JAVA的错误。

在问题的整个处理过程中,我一直在思考一个问题,那就是安装程序OUI是怎么来判断应该安装RAC还是安装非RAC的软件。我想到的几个方面:

  • 从/etc/hosts来判断,我很快否决了这个想法,这个不太可靠。
  • RAC的运行离不开Cluster软件,因此检查是否有cluster,cluster中有些什么样的节点,这是一个可行的办法。以前在AIX上安装Oracle9i时,如果有HA软件在运行,在安装时则会自动出现节点的选择并安装RAC软件。这是我认为的比较可靠的,并且应该是Oracle应当会采用的方法。但这里一个关键的问题是,现在CRS运行正常,安装程序为什么不能检测到cluster,不能检测到cluster中的节点。
  • 通过Oracle Inventory来检测,这是从以前解决DBCA建库不出现节点选择界面所得到的经验。当时为了解决问题,甚至反编译了DBCA部分JAVA代码。

打开/oracle/oraInventory/ContentsXML/inventory.xml,文件内容如下:

<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 2005 Oracle Corporation. All rights Reserved -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
   <SAVED_WITH>10.2.0.1.0</SAVED_WITH>
   <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OUIHome1" LOC="/oracle/product/10.2.0/crs" TYPE="O" IDX="1" CRS="true">
   <NODE_LIST>
      <NODE NAME="node1"/>
      <NODE NAME="node2"/>
   </NODE_LIST>
</HOME>
<HOME NAME="OUIHome2" LOC="/oracle/product/10.2.0/cluster" TYPE="O" IDX="2" CRS="true">
   <NODE_LIST>
      <NODE NAME="node1"/>
      <NODE NAME="node2"/>
   </NODE_LIST>
</HOME>
</HOME_LIST>
</INVENTORY>

会不会是安装程序在根据第一个CRS HOME检测cluster出现了问题呢。删除掉IDX=“1”的那个HOME,将IDX=“2”改成IDX="1",然后重装安装。啊,上帝保佑,成功了。当时差点就内牛满面啊。

对于这个问题,其实还有一个不算太完美的解决办法,就是分别在2个节点上安装好Oracle RDBMS软件,然后打开rac_on选项,然后relink oracle。只不过这样的情况下,DBCA这样的工具又不能正常使用了。

也许有朋友问,为什么不一开始就关注inventory的问题。这可能跟我的处理问题习惯有关系,通常情况下我会按常规方式处理,或者看看有没有类似的案例。接下来才会考虑那些比较另类的方法。
--EOF

曾几何时,网络上流传着给Oracle数据库分配内存的一条法则:把80%的内存分配给Oracle使用,而又将这80%的内存分配80%给Oracle的SGA,剩下的20%分给Oracle的PGA。记得Tom曾说过类似这样的话:如果一个参数的设置对Oracle是最佳的,那么Oracle就会自动地将其设为了默认值。而显然,在内存分配这事上,Oracle的初始设置并不是按这个法则的,那么就是说从某一方面证明这个法则存在问题。

当然大部分DBA不会这样设置内存参数,但是也有不少的人在Oracle的内存分配上存在欠考虑的地方。

首先,我们来看看保留可用内存20%给操作系统是否合适。对于2G内存的服务器(现实中这样的机器不少),20%意味着400M,而通常400M对操作系统来说是不够用的。而对于内存特别多的主机,20%又显得太多。比如下面是一份来自于一台P595的内存情况:

====================================================|==========|===========
Memory Overview                                     |    Pages |  Megabytes 
----------------------------------------------------|----------|-----------
Total memory in system                              | 45875200 |  179200.00 
    Total memory in use                             | 34789026 |  135894.63 
    Free memory                                     | 11086174 |   43305.36 
====================================================|==========|===========
Segment Overview                                    |    Pages |  Megabytes 
----------------------------------------------------|---------|-----------
Total segment id mempgs                             | 32618956 |  127417.79 
    Total fork tree segment pages                   |     2074 |       8.10 
    Total kernel segment id mempgs                  |  3594452 |   14040.82 

这台主机共计179GB物理内存,已使用135G,其中内核占用14G。内核占用的内存不到总内存的10%。

以上的数据以及说明,只是表达这样一个观点,对于操作系统的保留内存,需要根据实际情况预以考虑,这包括了操作系统的内核参数的设置。比如在AIX下的默认设置,client和perm内存可以占用远远超过20%的内存,而HP-UX下的默认设置,File Cache和Buf Cache也可能占用远远超过20%的内存。所以对于这些环境的数据库,一定要注意调整OS的内核参数。对于OS的内存使用,至少保留20%也不失为一种稳妥的做法。

除了操作系统这一块,给Oracle分配内存的时候,还需要注意以下非常重要的几点,这几点经常被人忽略:

  • 注意业务高峰期的内存使用:我所维护的一套系统,平时的连接数通常在5000-5500左右,而在最高时连接数达到了8000,也就是到达了连接的上限才作罢。因此,我们需要为业务高峰期时保留足够的内存。
  • 对于RAC数据库,需要考虑到其他节点故障或停机维护时,连接和压力转移到继续工作的节点时的内存消耗。
  • 一些人只考虑到了连接时进程使用的PGA内存,这里存在一个很大的误解,就是认为一个连接,只会使用PGA的内存。但还有一个很重要的内存使用,那就是进程本身占用的操作系统内存,除了PGA之外的内存。进程本身有代码(在OS中这通常是共享的),有stack,有heap,还要有kernel的内存占用。PGA只是进程使用的内存中一部分,甚至大部分情况下只是一小部分。在Oracle 10.2.0.4 for AIX下测试过,一个空闲连接,也就是啥事儿都不干的一个连接,PGA占用500K左右,而server process进程占用的内存在4-5M之间。测试时这套库刚启动,没有任何负载。实际上据观察在一套运行比较长时间的库上,server process占用的内存在9-10M之间。当然不同的系统,不同的配置,oracle进程占用的内存有所不同,有兴趣的朋友可以测量一下Oracle进程在HP-UX和LINUX下的内存占用。

对于SGA内各组件的细分以及PGA大小设置,网上很多相关的文章可供参考,本文不再涉及。不过我的个人观点是:参数的调整也不是一步到位的事情,需要根据系统运行时对性能数据的分析来进行调整,直至达到最优化。

应该怎么样安装数据库,从安装软件到创建数据库?对于这个问题,或许有的人不屑一顾,因为他们觉得这没有丝毫问题;同时有另一部分人,觉得这是个大问题。

在安装Oracle上,通常会有几种类型的人:

  • 完全抓不着头脑,不知道怎么安装,这通常是初学者,连Linux/Unix都不太熟悉。
  • 很少安装Oracle的人,但是知道对照文档一步一步操作,出了错也知道上google、baidu和metalink查找解决方案。
  • Oracle老手,安装数据库不需要任何文档,对每个步骤也很熟悉。
  • 对Oracle的安装非常熟悉,但是在安装时仍然按文档一步一步操作。

对我个人来说,我是最后一种类型的人。我也自认为安装了不少的数据库,覆盖了大部分的平台和操作系统。但我安装的时候,仍然会不嫌麻烦的一步一步操作按文档操作。在安装数据库软件包括建库,基本上没有遇到过什么问题。因为我也见过
很多朋友,被安装这一问题折腾得焦头烂额,特别是在安装RAC的时候,这里只是写一写我自己的一些做法,仅供参考,毕竟每个人都有自己的习惯和做法。

本文主要描述Linux/Unix下的Oracle安装,不涉及Windows系统下的安装。

我的习惯做法:

  • 平时注意收集安装文档,包括oracle online document(所谓的官方文档),metalink上的,还有IBM、HP这些公司与Oracle合作部门提供的文档。oracle online document中安装部分没事看一遍就可以了,但是metalink上很多文档详细地记录了版本的兼容性,安装时可能出现的问题以及解决办法等等,比如很实用的文档:《Oracle Database on Unix AIX,HP-UX,Linux,Mac OS X,Solaris,Tru64 Unix Operating Systems Installation and Configuration Requirements Quick Reference (8.0.5 to 11.2) [ID 169706.1]》、《Linux OS Requirements Reference List for Database Server [ID 851598.1]》、《Status of Certification of Oracle Clusterware with HACMP [ID 404474.1]》。而其他厂商的文档包括:《CookBook_V3.2_Oracle_9i_RAC_AIX5L》、《COOKBOOK_Oracle CTC RAC10g R2 on HP-UX》、《COOKBOOK-V2.0-10gRAC R2 - ASM - AIX5L - SAN Storage》如此等等,还包括网上一些朋友自己撰写的安装文档。在参考这些文档时,需要注意的是,一定要明白每一个步骤其目的,有什么作用。
  • 根据以上提到的文档,进行整理,形成自己的文档。我在前面说到,我安装时一步一步按文档操作,是指的按我自己的文档,而不是去参考前面提到的若干文档。在自己的文档中,甚至提供了详细的命令,这样在安装的时候对某些不熟悉的命令不至于现查资料。
  • 深入理解文档中提到的各个参数、各个命令的作用。这不光是对安装,而对于Oracle数据库的更深入理解也是大有好处的。

安装Oracle数据库时,在安装软件之前,通常有下面的操作:

  • 检查操作系统版本、相应组件是否安装,是否有安装好文档中指定的补丁,也包括c编译器或c语行环境,这些对Linux下的安装来说犹为重要。
  • 检查文件系统空间,特别是/tmp临时文件系统
  • 检查memory大小,特别是swap的大小。特别是在HP-UX下,swap的管理方式与其他系统有些不一样(此处不再细述),最
  • 好能够达到物理内存大小,对于特别大的物理内存,至少也要达到一半。
  • 检查主机时区,时间设置。这一步通常被很多人忽略。
  • 检查主机名设置,有的安装系统相当不负责任,直接将主机取名localhost。
  • 检查异步IO设置。
  • 检查网络设置,包括/etc/hosts文件的设置,特别是对RAC数据库犹为重要。
  • 检查内核参数,特别是共享内存、信号量、用户最多可运行进程数这些参数。
  • oracle用户创建后,注意编辑profile文件,设置相应的环境变量,注意不同的平台,相同意义的环境变量却有不同的名字,比如linux下的LD_LIBRARY_PATH和AIX下的LIBPATH。经常见到有的系统,oracle的PATH都没有设置,这样登录后操作相当不方便。
  • 对Oracle用户设置limit,通常是直接编辑/etc/security/limits.conf文件。
  • 给Oracle用户一些特定的权限,比如HP-UX下修改/etc/privgroup文件,10.2.0.4 for AIX下给用户CAP_NUMA_ATTACH, CAP_BYPASS_RAC_VMM, CAP_PROPAGATE 这样的权限等等。
  • 对于RAC,还需要设置rsh或ssh

至于安装的其他步骤,不是本文所要讲的主要内容,在此略过。

还要提及一点,安装的时候对于目录的选择,可以按照OFA的标准做法,也可以按照使用部门的习惯,建议使用OFA。经常有见到一些乱七八糟的目录,让人好找,这种做法不太好。

说到安装,不能不提到打补丁。在安装完成后,最好是打上较新的补丁包以及metlink上提到的一些建议打的补丁。而等到系统正式使用,发现问题再打补丁,其代价就昂贵得多。

由于安装Oracle软件以及升级版本和打补丁,比较耗时,有的朋友就喜欢下面的做法:安装好软件,打上补丁,然后tar成一个包,保存在自己的存储介质上,下次在其他主机上安装时,直接用这个tar包解开。这种做法可以省一些安装软件的时间,但是需要tar包的环境是否一致。我曾遇到过下面的问题:

某套新装9208的库,报ORA-600[504]错误,通过在metalink上搜索发现其最符合的一个BUG对应的补丁已经打上。其他类似环境下,包括有同样的补丁,却没有这样的错误。我找了一台操作系统完全一样的测试主机,安装与有问题库的版本完全一样的版本和补丁,却也没有这样的错误;接下来我将出问题的Oracle home 复制到测试主机上,结果问题重现了,看起来问题在Oracle软件上。我尝试执行relink操作,居然失败。发现这份Oracle在relink包括有HA代码,实际上这是一个单机的环境,也没有安装HACMP。最后,使用rac_off选项,再重新relink,新生成的oracle,不再出现这样的问题。在有问题的生产主机上重新relink后,问题解决。

出现问题的Oracle,就是通过解tar文件来安装的,在主机上我们也发现了以前安装时保留的tar文件。因此通过这种方式安装的,建议进行relink。

下面再谈谈创建数据库的一些个人经验:

  • 尽量使用new database(9i)或者custom database(10g)这样的选项来创建库,建库时只安装必须的组件,这种做法有3个主要好处:更安全、更稳定、以后升级时所花的时间更少。
  • 创建数据库时注意选择正确的字符集。
  • 如果是选用模板创建数据库,注意模板有可能不与Oracle软件软件版本相匹配。同时在建库完成后需要运行相应的脚本,比如在安装了PSU的情况下,那么使用模板建库,得需要运行PSU带的脚本(具体参考PSU的README)。
  • 在打完补丁之后,在创建数据库,避免在升级软件之后还要升级数据库。
  • 建完库后,建议设置一下大体上合理的数据库参数。

希望本文能够对Oracle数据库的安装不太熟悉的朋友一些帮助。

去年年底做了不少系统的数据迁移,大部分系统由于平台和版本的原因,做的是逻辑迁移,少部分做的是物理迁移,有一些心得体会,与大家分享。

首先说说迁移流程,在迁移之前,写好方案,特别是实施的方案步骤一定要写清楚,然后进行完整的测试。我们在迁移时,有的系统测试了四五次,通过测试来完善方案和流程。

针对物理迁移,也即通过RMAN备份来进行还原并应用归档的方式(这里不讨论通过dd方式进行的冷迁移),虽然注意的是要将数据库设为force logging的方式,在用RMAN做全备之前,一定要执行:

alter database force logging;

否则可能会产生坏块。

对于逻辑迁移,在job_processes设置为>0的数值之前,注意job的下次执行时间和job所属用户。比如job的定义在之前已经导入,但是在迁移之时,job已经运行过,那么迁移完成之后,job的下次时间还是原来的时间,这样可能会重复运行。另外,job通过IMP导入后,job所属用户会变成导入用户的名称,显然job原来的用户就不能对JOB进行管理了,可以通过下面的sql进行修改:

update sys.job$ set lowner=cowner , powner=cowner;

在迁移之前,应该禁止对系统进行结构上的修改和发布,比如表结构,索引,存储过程包等。

如果是用exp/imp导入的对象,包括存储过程等,应该检查对象是否与原生产库一致,比如由于dblink的原因,imp之后,存储过程不能创建,导致有部分存储过程丢失,尽管这些存储过程可能没有被使用。

下面是一些加快迁移速度的技巧:

  • 通过dblink,使用append insert的方式,同时利用并行,这种方式比exp/imp更快
  • 对于有LONG类型的列,insert..select的方式显然是不行的,可以通过exp/imp的方式,但是这种方式速度非常慢,其原因在于imp时一行一行地插入表。有另外一种方式,即sqlplus的copy命令,下面是一个示例:
    spool copy_long_table_1.log
    conn / as sysdba
    set copycommit=2000
    set arraysize 30
    set long 10485760
    
    copy from system/xxxx@source_db append username.table_name using select * from username.table_name;
    
    spool off
    exit
    

    不过,sqlpus的copy命令不支持有timestamp和lob列类型的表。如果有timestamp类型的表,可以通过在exp时,加上rowid的条件,将一个表分成多个部分同时操作,对于有lob类型的表,也可以同样处理(因为insert ...select方式下,有lob类型列时,也同样是一行一行地插入)。注意在这种方式下,就不能使用direct的方式exp/imp。下面是exp导出时parfile示例:

    query="where rowid>=dbms_rowid.rowid_create(1,71224,52,9,0) and rowid<=dbms_rowid.rowid_create(1,71224,55,1038344,10000)" 
    file=/dumpdata/n1.dmp
    tables=username.table1
    constraints=n
    grants=no
    indexes=no
    buffer=104857600
    ...
    ...
    query="where rowid>=dbms_rowid.rowid_create(1,71224,423,137,0) and rowid<=dbms_rowid.rowid_create(1,71224,432,59272,10000)" 
    file=/dumpdata/n6.dmp
    tables=username.table1
    constraints=n
    grants=no
    indexes=no
    buffer=104857600
    

    将表分成几部分同时操作,不仅仅可以利用rowid,也可以利用表上的列,比如说,表上有一个created_date的列,并且保证是递增插入数据,那么这种情况下,也可以使用这个字段将表分成不同的范围同时进行导出和导入。不过使用ROWID通常具有更高的效率。
    当然对于有lob列的表,可以按上述方式,拆成多个insert方式同时插入,不需要exp/imp。

  • 对于特别大的分区表,虽然使用并行可以提高速度,但是受限于单个进程(不能跨DB LINK进行并行事务,只能并行查询,也即insert..select只能是SELECT部分才能进行并行)的处理能力,这种方式下速度仍然有限。可以并行将数据插入多个中间表,然后通过exchange partition without validation 的方式,交换分区,这种方式将会大大提高了速度。
    有朋友可能会问,为什么不并行直接插入分区表,当然如果是非direct path(append)方式,则是没问题的,但是这种方式插入的性能较低。而direct path的方式,会在表上持有mode=6(互斥)的TM锁,不能多个会话同时插入。(update: 在insert 时使用这样的语句:insert into tablename partition (partname) select * from tablename where ....,更简单更有效率。)
  • 迁移时,将数据分成两部分,一部分是历史表,第二部分是动态变化的表,在迁移之前,先导入历史表,并在历史表上建好索引,这无疑会大大减少迁移时业务系统中断时间。
  • 迁移之前,考虑清理掉垃圾数据。
  • 迁移时,应保证表上没有任何索引,约束(NOT NULL除外)和触发器,数据导入完成后,再建索引。建索引时同样,同时使用多个进程跑脚本。索引创建无成后,应去掉索引的PARALLEL属性
  • 在创建约束时,应按先创建CHECK约束,主键,唯一键,再创建外键约束的顺序。约束状态为 ENABLE NOVALIDATE,这将大大减少约束创建时间。而在迁移完成后,再考虑设回为ENABLE VALIDATE。
  • 通过使用dbms_stats.export_schame_stats和dbms_stats.import_schame_stats导入原库上的统计信息,而不用重新收集统计使用。

朋友们可以看到,以上均是针对9i的,实际上在10g甚至11g环境下,也仍然很多借鉴意义。当然这些技巧不仅仅用于完整的数据库迁移,也可以应用到将个别表复制到其他数据库上。

这里没有提到的是利用物化视图或高级复制、触发器之类的技术,因为这些技术,毕竟要修改生产库,对生产库的运行有比较大的影响,因此,只有在停机时间要求特别严格,而在这个时间内又不能完成迁移时才应该考虑。

从迁移的经验来说,只有完善的流程,完整的测试才可以保证成功。这里只是列举了一些小技巧,如果对整个迁移过程有兴趣,可以针对这个话题再进行讨论。

在一个表上建索引时,报ORA-01410错误,我们查询这个表来重现这个错误:

Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production
With the Partitioning option
JServer Release 9.2.0.6.0 - Production

SQL> set timing on
SQL> set time on
14:20:03 SQL> select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a; 
select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a
                                                    *
ERROR at line 1:
ORA-01410: invalid ROWID

ORA-01410错误通常见于通过索引访问表,而索引或表由逻辑上的损坏。而这里显示没有通过索引访问表?那问题出在哪里呢?在这种情况下,这个错误与ORA-08103极其类似,参照《记一次ORA-8103错误的处理》

14:27:00 SQL> alter session set max_dump_file_size=unlimited;

Session altered.

Elapsed: 00:00:00.01
14:27:18 SQL> alter session set db_file_multiblock_read_count=1;

Session altered.

Elapsed: 00:00:00.00
14:27:18 SQL> alter session set events 'immediate trace name trace_buffer_on level 1048576';

Session altered.

Elapsed: 00:00:00.00
14:27:18 SQL> alter session set events '10200 trace name context forever, level 1';

Session altered.

Elapsed: 00:00:00.00
14:27:18 SQL> select /*+ full(a) no_index(a) */ count(*) from crm.cust_order a; 
ERROR at line 1:
ORA-01410: invalid ROWID


Elapsed: 00:05:50.82
14:33:09 SQL> 14:33:09 SQL> alter session set events 'immediate trace name trace_buffer_off';

Session altered.

在trace文件的最后,我们可以看到:

Consistent read started for block 10 : 2489c394
  env: (scn: 0x0a0d.690ff414  xid: 0x0000.000.00000000  uba: 0x00000000.0000.00  statement num=0  parent xid: xid: 0x0000.000.000000
00  scn: 0x0000.00000000 0sch: scn: 0x0000.00000000)

这里只有"start“,而没有finish,表明在读2489c394这个块出了问题。
用ODU工具的rdba查看文件号和坏号:

ODU> rdba 2489c394

  rdba   : 0x2489c394=613008276
  rfile# : 146
  block# : 639892

通过"alter sytem dump datafile 146 block 639892”命令发现块中的object_id与CUST_ORDER表的data object id不同,看起来这就是问题所在(此处不再列出数据)。
看起来有坏块了。不过这个库是个查询库,把表TRUNCATE之后重新从生产库同步过来,发现问题仍然存在,甚至把表DROP之后重建也是如此,均是发生在146/639892这个块上。

而TRUNCATE/DROP表都不能解决问题,显然这个块还在内存中,看起来需要刷新buffer cache了:

14:37:07 SQL> alter session set events 'immediate trace name flush_cache level 1';
Session altered.

刷新buffer cache后,问题解决。

总结:这个问题,与ORA-8103类似,都是出现了逻辑坏块,只不过这次的坏块是发生在内存中的块。至于坏块是怎么进入到内存中,为什么在重建表后还在内存中,这就是个谜了,或者是ORACLE的BUG,或者跟用的同步软件DSG有关。在这个案例中,块的object_id与段的实际的data object id不一致。而object_id不一致有时也会报ORA-600错误。

成都东方龙马公司(就是老熊所在的公司),招聘1-2名Oracle技术支持工程师

成都东方龙马有优秀的技术团队,主要服务于各省级运营商,因业务发展需要,需招聘1-2名Oracle技术支持工程师。

基本要求:
1、有4年或以上数据库维护经验,对Oracle架构、机理及概念非常清晰。
2、有丰富的Oracle故障处理以及优化经验。
3、熟悉1种以上UNIX操作系统(AIX, HP-UX, Linux, Solaris),对存储及网络有一定了解。
4、良好的沟通能力。
5、很好的文档编写习惯。
6、对Oracle数据库有浓厚的兴趣。
7、有很好的职业道德及团队精神。
8、能够适应长期出差。

待遇,视能力而定,面议!

有兴趣的朋友,请将简历发送到我的邮箱 xj@olm.com.cn
简历请用doc或pdf附件形式,文件名内包含姓名。

与eygle,yangtingkun等几位合作的《Oracle DBA手记--数据库诊断案例与性能优化实践》即将出版,预计在1月份上架。在此感谢各位的去持。下面是本文的章节目录(来自eygle的网站):

├─第一篇 DBA工作手记
│      01.Eygle的DBA工作手记-Eygle
│      02.Yangtingkun的DBA工作手记-Yangtingkun
│      03.老熊的DBA手记
│      04.BanPing的DBA工作手记-Banping

├─第二篇 诊断案例篇
│      01.ASM案例分析与诊断
│      02.监听故障的诊断与分析
│      03.ORA系列错误与诊断
│      04.ORA-01200错误裸设备恢复
│      05.Oracle数据库无响应故障的处理
│      06.RAC环境诊断案例一则
├─第三篇 SQL调优篇
│      01.合理利用索引解决性能问题
│      02.SQL优化与调整实践
│      03.索引访问与数据读取
│      04.SQL优化之Everything is possible

└─第四篇 性能优化篇
        01.CBO、执行计划与统计信息案例
        02.Oracle数据库性能与统计信息
        03.聚簇因子、柱状图与执行计划
        04.表碎片及分页查询优化
        05.一次排序的调整与优化

本书在豆瓣上的条目:http://www.douban.com/subject/4209919/

再次感谢朋友们的关注。

在以前的一篇文章《DBMS_STATS、ANALYZE以及Global Statistics》中,提到使用10g数据库dbms_stats收集统计信息时,granularity缺省值为“AUTO”,其含义是“Auto -- Table + Partition + Subpartition (10g,表+分区,当子分区是list分区时还包括子分区)”。本文就这个问题再深入地探讨一下。

大家都知道,子分区有两种,一种是分区为RANGE,子分区为HASH,另一种是分区为RANGE,子分区为LIST。在10g数据库中,如果在使用dbms_stats收集统计信息时,如果没有显式指定granularity(粒度),那么granularity就会取自dbms_stats配置:
而其缺省值是“AUTO",而不再是9i下的”DEFAULT":

SQL> select dbms_stats.get_param('granularity') param from dual;

PARAM
------------------------------
AUTO

而10g自带的自动收集统计信息的任务“GATHER_STATS_JOB",其granularity同样是取自granularity param。当然可以通过下面的SQL来更改其值:

SQL> exec dbms_stats.set_param('granularity','global and partition');

这样更改后,dbms_stats默认就会收集表以及分区级统计信息,不收集子分区级统计信息。

那么,granularity=auto时,到底是怎么样的呢?前面说到了子分区是以list方式分区时,那么就会收集子分区级统计信息,其言外之意就是如果子分区是以hash方式分区时就不会收集子分区统计信息了。到底是不是这样呢?下面做个测试,测试环境是Oracle 10.2.0.4 for Linux AS4:

QL> create table t1
  2  partition by range(object_id)
  3  subpartition by hash(data_object_id)
  4  subpartitions 4
  5  ( partition p1 values less than(10000),
  6    partition p2 values less than(20000),
  7    partition p3 values less than (maxvalue)
  8  )
  9  as select * from dba_objects;  

Table created.

SQL> create table t2
  2  partition by range(object_id)
  3  subpartition by list(object_type)
  4  subpartition template(
  5    subpartition sp1 values ('TABLE'),
  6    subpartition sp2 values ('INDEX'),
  7    subpartition sp3 values ('VIEW'),  
  8    subpartition sp4 values (DEFAULT)
  9  )  
 10  ( partition p1 values less than(10000),
 11    partition p2 values less than(20000),
 12    partition p3 values less than (maxvalue)
 13  )
 14  as select * from dba_objects; 

Table created.

我们先建再从个测试表,表T1是RANGE+HASH方式的复合(组合)分区表,表T2是RANGE+LIST方式的复合分区表。
下面将"granularity" param重新设回为”auto“,然后收集T1和T2的统计信息:

Read the rest of this entry

说起来汗颜,我这个BLOG主要写Oracle相关的文章,也附带写点UNIX,可惜从来没正经写过UNIX方面的东西。毕竟不是专业的SA,水平不够恐怕误导读者朋友。这次的故障,主要是从OS层进行处理的,稍微算是沾上一点UNIX的边。闲话少扯了,说正事吧。

事情的起因,是系统的最终用户反映某些查询功能比较慢。简单地看了一下主机的负载以及数据库的性能状况,没发现什么异常,甚至可以说系统相当地轻闲。

那问题出在哪?我首先观察到内存的使用率相当地高,达到99%。但是从操作上看,速度还没受到影响。不过很快想到,这个系统某些模块,用了短连接,难道是监听太慢引起的?这个库启了6个监听(详见《一切皆有可能》),分别TNSPING这几个监听,有个别监听非常慢,重启监听后,查询功能比较慢的问题得到解决。

不过之前观察到的内存的异常使用引起了我极大的注意。这套系统,平时一般都会有几十G的空闲内存,不会达到这么高的。第一反应是用ipcs命令检查一下共享内存,发现有一个异常的共享内存段,占了60多G。

[oracle@hostname%/oracle]ipcs -ma
IPC status from /dev/kmem as of Mon Dec  7 10:58:53 2009
T         ID     KEY        MODE        OWNER     GROUP   CREATOR    CGROUP NATTCH      SEGSZ  CPID  LPID   ATIME    DTIME    CTIME 
Shared Memory:
m          0 0x41180809 --rw-rw-rw-      root      root      root      root      0        348  2725  2725  2:38:57  2:38:57  2:38:50
m          1 0x4e0c0002 --rw-rw-rw-      root      root      root      root      2      61760  2725  2727 12:27:19 18:19:39  2:38:50
m          2 0x411c0de1 --rw-rw-rw-      root      root      root      root      2       8192  2725  2727 12:27:19  2:38:50  2:38:50
m          3 0x00a5c581 --rw-------     sfmdb     users     sfmdb     users     11   10469376  3362  3398  2:39:38  2:39:39  2:39:38
m          4 0x4118043d --rw-------      root      root      root      root      1       4096  3410  4745  2:40:12 no-entry  2:40:12
m          5 0x06347849 --rw-rw-rw-      root      root      root      root      1      65544  3535  6722 17:53:03 17:53:03  2:39:47
m    1015814 0x0c6629c9 --rw-r-----      root       dba      root       dba      0   35921048  6722  6722 17:53:03 no-entry 17:53:03
m     819207 0x491002d0 --rw-r--r--      root      root      root      root      0      22908  3674  3674  2:39:54  2:39:54  2:39:54
m    5472264 0x00000000 D-rw-r-----    oracle       dba    oracle       dba      6 66640334848  5508 23604 17:58:00 17:58:00 17:58:00
m   95387657 0x0000cace --rw-rw-rw-      root       sys      root       sys      0          2 21306 21306 20:24:33 20:24:33 20:24:29
m   35520522 0xa57bccf8 --rw-r-----    oracle       dba    oracle       dba  12231 66640334848  3231 26942 10:58:53 10:58:53 18:10:36

ID为"5472264"的共享内存段就是异常的共享内存段。
为什么会出现这种情况?数据库可以确定是被重启过,询问客户这套系统的DBA,的确是在头一天出现了异常然后进行了重启。至于出现了什么样的异常,为什么要重启,这里不再深入。本文只讨论怎么样来清除这个异常的共享内存段。

由于这个内存段的NTATTCH(number of attach)为6,在HP-UX下是清理不掉的:

[oracle@hostname%/oracle]ipcrm -m 5472264
ipcrm: shmid(5472264): not found

这是由于还有进程attach(理解为连接吧)到这个共享内存段上。只要找到这个进程被KILL之,就会解决问题。一种简单的方法是使用lsof来找到这些进程:

[oracle@hostname%/oracle]lsof | egrep "COMMAND|5472264"

不过简单的方法,不一定效率就高。这个系统光oracle server process就有5000个以上,lsof实在很慢。所以运行几分钟就直接放弃(因为以前在这套系统上运行过lsof命令,知道要输出完结果时间比较“漫长”)。

OK, 手工找一下吧。从上面的ipcs输出的CTIME字段看到,正常的共享内存段是18:10左右创建的,而异常的是17:58左右创建的,那么attach到这个异常共享内存段的进程应该是在18点之前创建,而在17:58左右。首先使用"ps -ef | grep defunct“,没有发现僵死进程。然后根据这样的条件,并且经过一系列筛选,得到下面的结果:

[oracle@hostname%/oracle]ps -ef | grep oraclesidname | grep "17:" | grep -v "18:17" | grep -v "11:17"
  oracle 22586     1  1 07:17:43 ?         0:31 oraclesidname (LOCAL=NO)
  oracle 28403     1  0 09:17:38 ?         0:02 oraclesidname (LOCAL=NO)
  oracle 22618     1  0 07:17:59 ?         0:00 oraclesidname (LOCAL=NO)
  oracle  7539     1  0 08:17:42 ?         0:10 oraclesidname (LOCAL=NO)
  oracle  7419     1  0 08:17:05 ?         0:00 oraclesidname (LOCAL=NO)
  oracle 22580     1  0 07:17:42 ?         0:36 oraclesidname (LOCAL=NO)
  oracle  7421     1  0 08:17:06 ?         0:06 oraclesidname (LOCAL=NO)
  oracle  7537     1  0 08:17:42 ?         0:02 oraclesidname (LOCAL=NO)
  oracle  7535     1  0 08:17:41 ?         0:00 oraclesidname (LOCAL=NO)
  oracle 21395     1  0 17:56:49 ?         0:01 oraclesidname (LOCAL=NO)
  oracle 22616     1  0 07:17:59 ?         0:00 oraclesidname (LOCAL=NO)
  oracle 20786     1  0 17:54:24 ?         0:10 oraclesidname (LOCAL=NO)
  oracle 22614     1  0 07:17:58 ?         0:00 oraclesidname (LOCAL=NO)
  oracle  7423     1  0 08:17:06 ?         0:18 oraclesidname (LOCAL=NO)

看上去进程号为21395和20786的进程,正好满足前面提到的条件。KILL这两个进程,检查共享内存段,发现这个异常的共享内存段自动被清除。再检查内存的使用,内存的使用率也大幅下降,回到正常状态。

今天也算是幸运的,在没有监控系统的情况下,人为的较早发现了这个问题,避免了全系统范围内的系统问题。如果没有及时发现这个问题,内存的使用一上去,开始大量使用交换页,那就头疼多了。

我们都知道drop table, truncate table时都会先做一次checkpoint,将被删除对象的脏块写入磁盘。

客户有一套系统,Oracle 9.2.0.8,需要做数据迁移,由于种种原因,采用的是逻辑迁移的方式。由于库比较大,超过了1.5T,而停机时间又有限,因此在正式迁移之前需要做大量的测试,测试的目的,一方面是看迁移流程上是否存在问题,另一方面是看迁移的时候,哪个地方会存在性能瓶颈,并进行优化,同时估算实施迁移时间。

第一次测试后,需要把测试产生的大量用户及其对象全部删除,删除用的是drop user username cascade。不幸的是这种方式删除得相当地慢。一个9000多个表的用户,删除了1个半小时才删除了4000多个表。为什么这么慢?有没有办法提高速度?

drop table既然要做checkpoint,那么在db cache非常大的情况下,这需要消耗的时间是比较长的。如果能够减少这个时间无疑将大幅提高速度。首先尝试做一次checkpoint,将buffer cache全部刷新出去:

alter system checkpoint;
alter session set events 'immediate trace name flush_cache level 1';

发现没什么效果。

由于db_cache_size有50GB左右,db_keep_cache_size有6G左右。重新设置参数,将db_keep_cache_size设为0,将db_cache_size设为200M,重启一下数据库,重新执行删除用户的操作,操作很快完成。

在另一次同样的过程中,采用同样的修改参数的方式,效果同样非常明显。

这是个简单的案例,与君共享。