老熊的三分地-Oracle及数据恢复

很久没有更新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，重启一下数据库，重新执行删除用户的操作，操作很快完成。

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

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