Expert Oracle Exadata译者序

从去年8月份到现在,我跟KayaJacky合译的《Expert Oracle Exadata》,如果不出意外,应该可以在5月底出版。在出版以后,计划以ACOUG的名义和博文视点联合举办一些现场的发布活动,目前还在筹划中。

我个人从这本书的翻译中获益良多,甚至在最近的这次大数据量、短停机时间的数据库迁移项目中就开始使用书中介绍的Exadata迁移方法,虽然我的这个项目并没有Exadata,但是仍然可以从书中描述的通用的迁移解决方案和优化手段中得到启发。所以,我想无论是不是在使用Exadata,这本书都值得期待。下面是为我的译者序。

译者序-Kamus

这本书的翻译计划是从2011年8月份开始的,据我所知,最早是博文视点的编辑“侠少”找到阿里巴巴的张瑞(Jacky)和甲骨文的黄凯耀(Kaya),然后Jacky再找到我。

实际上,我个人开始想要翻译这本Exadata技术书籍倒是从更早的时候就开始了,这本书在Amazon上的发行日期是2011年8月9日,其实早在2011年2月份已经有另外一本关于Exadata性能的书籍(Achieving Extreme Performance with Oracle Exadata,作者全部是Oracle公司员工),但是论作者的知名度,仍然是本书更受人关注。最早知道这本书是从本书联合作者Tanel Poder的个人技术Blog中,那是2011年3月份,Tanel发文说已经可以Apress网站上购买新书的Alpha版本,Tanel是全球最受人尊重的Oracle技术专家之一,而一本技术书籍可以预先购买Alpha版本也是很稀奇的事情,再加上Exadata正是当今IT界的当红炸子鸡,理所当然这本书非常值得期待。在2011年4月份,我个人跟某出版社联系过,表达了如果该书可以引进中国,那么我很愿意组织人手进行翻译的工作,对方的回复是正在谈版权,之后没有消息。然后,Tanel在6月份发文说,本书已经即将定稿,再之后,就是8月份,该书正式发售。而在正式发售的当月,博文视点就开始寻找中文版本的译者,可以说是非常迅速。而版权的猜测,那一定是博文视点拿到了版权,而某出版社失利了。:-D

以上的情况,让我收到Jacky的邀请以后,毫不犹豫地接受了工作,无论工作如何繁忙,我都愿意这本书的中文翻译者里有我的名字,这对于我而言可以说是一种荣幸。2011年8月17日收到这本书的PDF电子版(当然后来又收到纸质版),从8月份开始,Kaya,Jacky和我都迅速地投入了翻译的工作,在整个过程中,通过不断地沟通,我们按照每个人的经验和对各个章节的熟悉程度以及感兴趣程度,大致是均分了各个章节。我负责翻译的章节是一、二、四、六、十三、十六章,原本我给自己定下的计划是每两周翻译一章,那么最快可以在2个月内完成翻译,再加上校稿,本来计划在3个月内可以完成所有的翻译,也就是如果一切顺利,这本书的中文译本应该在2011年年底的时候就跟大家见面了。但是,计划永远是赶不上变化的,除了工作的繁忙和个人的懒惰,我们几个译者还都在其它方面出现了这样那样的意外情况,导致整个翻译工作整体滞后。所幸,还不算太迟,我想在你们看到本书的时候,这个世界上应该还没有更新的Exadata书籍可以参考。所以,这本书仍然是迄今为止想要了解Exadata,想要使用Exadata,想要监控调整Exadata的最佳参考书籍。

Oracle Exadata的举世独步,对整个数据库硬件/软件市场的震撼,在全球或者仅仅是中国国内的引人瞩目,乃至热销,这已经无需赘言。作为数据库从业者,也许你没有听过Netezza,也许你没有听过Twinfin,也许你没有听过Hana,但是你一定听过Exadata,这绝不仅仅是由于Oracle公司一贯的好战、勇于进攻、大力宣传的风格,而是Exadata确实具有独步天下的功能。也许我们不能说在经过最精细地调整以后,Exadata在数据仓库领域与其它竞争对手相比一定具有绝对的优势,但是,不要忘记,在现在这个世界里,又有多少是纯粹的数据仓库系统呢?又有多少用户愿意OLTP用一套系统而数据仓库又用另外一套系统呢?这其中的数据传输开销和系统设计复杂性的开销,如果能够消减甚至是避免,那么又何乐而不为呢?Exadata正是这样的一套软硬件一体的平台,同时支持OLTP类型负载和数据仓库类型负载,通过Oracle Database 11gR2中的资源管理器来更加精细地调控硬件资源,让两种类型的负载都能获得各自需要的资源,并顺畅执行。

如果我们抛却Exadata在存储节点中的软件特性,它使用的各个硬件组件并不是划时代的,无论是Infiniband还是Flashcache/SSD,都已经出现了很久,在企业级市场中也被很多用户在使用了,但是将这些组件放在一起,并且预先调整为一个平衡的系统(没有任何一处明显的性能瓶颈),这是划时代的。Oracle将软硬一体机的概念推广到了开放性平台上,极大地挑战了Teradata的市场,用开放性的硬件+开放性的操作系统+开放性的数据库软件,构造出了一个平衡的,性能超强的平台,这同样是划时代的。

好吧,前面我们提到了“抛却Exadata在存储节点中的软件特性”是吗?这就好比我们说,把皇冠上最闪亮的那颗宝石先摘下来,别闪花了我们的眼睛。现在,我们要把这颗宝石放回去了,智能扫描(Smart Scan),存储索引(Storage Index),混合列压缩(Hybrid Columnar Compression),无论哪一项软件特性都足以震撼数据处理市场,而当他们结合在一起,配合上Oracle Database原本就具有的高性能,再配合前面说的这个平衡的硬件架构,我们就得到了足以颠覆一切固有理念的惊人性能。在Exadata的POC现场,有客户因为实在无法接受Exadata展示出来的飞一般的速度而怀疑Oracle的技术人员在造假。这在无奈的同时无疑也是一种自豪吧。

Exadata的出现,颠覆了一些我们既有的数据库管理理念,但是无论如何,Exadata中运行的是Oracle Enterprise Linux(当然也有Solaris,不过是x86-64版本,至少到目前为止,Oracle还没有计划显示会出现SPARC平台上的Exadata),Linux上运行的是Oracle Database 11gR2,对于所有数据库技术从业者来说,之前积累的操作系统管理知识,Oracle数据库/RAC管理知识都仍然适用。我们需要的只是与时俱进,将Exadata的特有知识点加入我们以前的知识体系中。本书是最佳的入手点,因为本书中不但有Exadata的特性阐述,也同样有使用经验和最佳实践。要知道本书的作者都是真正的Exadata使用者,而本书的Review者(Kevin)更是Exadata的性能架构师(不过,Kevin现在已经离开Oracle公司,加盟EMC,去玩Greenplum了)。

我唯一希望的是,大家在读这本中文译本的时候,不至于产生去重新阅读原著的冲动(虽然,我仍然建议大家去阅读原著),因为如果那样,那只能表示我们的翻译实在是很不适合中文读者的理解。如果你觉得本书优秀,那么基本上可以说这是原作者的功劳,当然,我也希望你们看到我们三位译者的努力。我们在翻译完各自的章节以后,又互相审阅了其他人的章节,我们尽量斟酌每一句话的翻译,希望读起来是符合中文阅读习惯的,对于一些比较难于理解的片段(比如Kevin说的某些话),我们通过邮件跟作者进行了沟通以确保译文是正确体现了作者意图的,对于一些原文较为晦涩的地方,我们也根据自己的理解增加了“译者注”,我相信这也是目前大多数技术书籍的译文中并不常见的,我们甚至在想,如果译者注足够多,那么就可以出一本批注版的书籍了(:-D)。这其中由于Kaya在Exadata中的实战经验尤为丰富,更是付出了格外的精力。你们现在看到的这本Expert Oracle Exadata中文版,应该是全球的最新版本,因为在我们的翻译过程中,不但将本书英文版出版以后提交给作者的错误修订全部都更正到本书中,而且我们还在翻译过程中发现了更多的错误,Kaya通过邮件直接跟三位作者沟通并一一确认,最终对于确实是错误的描述也都全部作了更正。实际上,这也是本书推迟到现在才出版的原因之一。

就在今天,我重新审阅完了自己翻译的第6章,回顾了一下从2011年8月份开始,我们三位译者和博文视点的侠少关于翻译本书的邮件沟通,来来回回将近300封邮件,我相信在本书中文版最终定稿的时候,沟通邮件量一定会超过300封(实际上最终的沟通邮件将近500封)。我们扪心自问,已经尽了自己最大的努力,但是一定还会有这样那样的不足,还望读者海涵。

最后,我要感谢我的妻子和可爱的儿子,在我工作之余的很多个深夜,我仍然在翻译此书,是我的妻子极大地包容了我,没有她的支持,没有她承担的几乎全部家务,和对于我们年仅1岁多的儿子的照料,也许我的翻译进度还会拖后。谢谢你,我爱你们。感谢Kaya,Jacky,还有博文视点的侠少,与你们关于本书翻译讨论的500封邮件是宝贵的财富。感谢我的大学师妹-董楠,她是《老美国志异》、《此地无人生还》、《满是镜子的房间》三本畅销书籍的译者,喜欢摇滚的朋友应该热爱这几本书籍,本书某些段落的措辞有得到她的指教。另外,我同样要感谢我所在的公司-云和恩墨的多位同事,是你们帮我承担了由于翻译工作而拉下的本应属于我的工作,感谢杨廷琨(老杨同时帮助审阅了本书的第一章),感谢盖国强。还有帮助我审阅中文译稿的同事们,仇实、刘洋、余广宏、董禹、宋春风,译稿里面也有你们的功劳,谢谢你们。

2012年2月29日
张乐奕(Kamus)于上岛咖啡,北京。

Install GI and DB PSU 11.2.0.2.5 Failed in VirtualBox

Oracle的Apply Patchset的方法一直是为人诟病的,其实步骤复杂倒也罢了,怕的是Oracle总在不停地修改Apply Patch的方法,Oracle的原意是让Apply Patch的语法越来越简单,但是各种各样的Patch,各种不同的命令,特别是很大的Bundle Patch,如果不仔细阅读Readme,千万不要轻易出手。

这次尝试在自己的VirtualBox虚拟机OEL6中给之前安装的GI(Oracle Restart)+ ASM + Oracle Database安装最新的11.2.0.2.5 PSU,遇到各种问题。

1. Patch解压的目录必须是grid用户和oracle用户拥有写权限的,如果没有写权限,会报错:

Opatch version check failed for oracle home  /u01/app/oracle/product/11.2.0/dbhome_1
Opatch version  check failed
update the opatch version for the failed homes and retry

安装需求是使用root用户来安装(这是我第一次看到在安装PSU的时候要求使用root用户),而我的虚拟机中由于没有足够的磁盘空间,所以将Mac中的下载目录作为Shared Folder映射到虚拟机中,因此改目录的属主是root,用户组是vboxsf,而且并不允许使用chmod直接修改。因此出现了权限问题。我的解决方法是将grid用户和oracle用户都加入vboxsf组中。

建议:在真实环境中,Patch解压目录应该属于dba用户组。

2. 我的Patch是解压在/media/sf_PSU目录下,解压以后生成了p13343447_112020_Linux-x86-64目录,其下有两个目录分别是13343424(这是DB PSU)和13343447(这是GI PSU),整个目录结构如下所示:

 |-media
 |--sf_PSU
 |---p13343447_112020_Linux-x86-64
 |-----13343424
 |-----13343447

按照Readme文档中描述的,opatch的命令应该写为:

opatch auto 

此处的UNZIPPED_PATCH_LOCATION按照文档描述应该就是/media/sf_PSU目录,因为这是解压目录,但是实际上这份文档是有问题的(注:这是我个人造成的问题,我在操作系统中双击解压zip包,自动生成了p13343447_112020_Linux-x86-64目录,而如果命令行下用unzip解压,则不会出现此目录,因此Oracle文档中的描述并没有问题,但是这里主要吐槽下面的报错信息),如果opatch命令写为:

opatch auto /media/sf_PSU -ocmrf /home/grid/ocm.rsp

其中的-ocmrf是另外一个问题,这个OCM的配置文件,根据Readme文档中描述的方法创建即可。

运行以上命令会报错:

Opatch version check failed for oracle home  /u01/app/oracle/product/11.2.0/dbhome_1
Opatch version  check failed
update the opatch version for the failed homes and retry

是的,你没有看错,我也没有贴错,确实报了一模一样的错误(虽然这两个错误都完全不是opatch版本的问题),所以,opatch的报错信息是不可信的,我们必须要去提示的log文件中仔细查看最后的错误信息。

 ZOP-49: Not able to execute the prereq. OPatch cannot inform if the patch satisfies minimum version requirement.
 PatchObject constructor: Input file "/media/sf_PSU/p13343447_112020_Linux-x86-64/etc/config/actions" or "/media/sf_PSU/p13343447_112020_Linux-x86-64/etc/config/inventory" does not exist.

因此,正确的opatch命令应该是:

opatch auto /media/sf_PSU/p13343447_112020_Linux-x86-64 -ocmrf /home/grid/ocm.rsp

3. Oracle软件所在的文件系统剩余空间必须要大于3G,如果不足,会报错:

patch /media/sf_PSU/p13343447_112020_Linux-x86-64/13343447  apply  failed  for home  /u01/app/grid/product/11.2.0/grid
ACFS-9459: ADVM/ACFS is not supported on this OS version: 'error: file /etc/SuSE-release: No such file or directory

可以看到,又是一次很无稽的报错信息,/etc/SuSE-release?拜托,这里只有/etc/redhat-release。

那么,仔细检查log文件,会发现如下的报错:

 Prerequisite check "CheckSystemSpace" failed.
 The details are:
 Required amount of space(3154696080) is not available.
 UtilSession failed: Prerequisite check "CheckSystemSpace" failed.
 Log file location: /u01/app/grid/product/11.2.0/grid/cfgtoollogs/opatch/opatch2012-01-27_18-23-48PM.log

 OPatch failed with error code 73

到此为止,我放弃了在虚拟机中安装PSU 11.2.0.2.5(如果要增加虚拟机中的文件系统剩余空间是非常麻烦的事情),但是我认为解决了磁盘空间问题之后,后面应该不会再有太多问题了。另外,如果在真实环境中这些问题可能都不存在,因为真实环境中文件系统的剩余空间应该远远不止3G,也应该不会有Shared Folder权限的问题,不过目录位置的问题应该还是会遇到,希望这里遇到的问题对将要在产品环境中Apply 11.2.0.2.5 PSU的朋友有帮助。

如果你成功Apply了该版本的Patch,那么也可以留言告诉我你遇到了什么障碍。

Update@2012-02-09
在另外一台测试的Solaris机器中成功apply了最新的11.2.0.3.1 PSU,包括GI和DB的,由于命令跟本文描述的11.2.0.2.5 PSU的更新方法一样,所以记录在此。如果没有本文描述的上述错误,opatch auto还是很简便的。

# export PATH=$PATH:/u02/app/oracle/product/11.2.0/grid/OPatch
# opatch auto /home/oracle/gi_psu_11.2.0.3.1 -ocmrf /home/grid/ocm.rsp
Executing /usr/bin/perl /u02/app/oracle/product/11.2.0/grid/OPatch/crs/patch112.pl -patchdir /home/oracle -patchn gi_psu_11.2.0.3.1 -ocmrf /home/grid/ocm.rsp -paramfile /u02/app/oracle/product/11.2.0/grid/crs/install/crsconfig_params
defined(@array) is deprecated at /u02/app/oracle/product/11.2.0/grid/OPatch/crs/crsconfig_lib.pm line 2149.
        (Maybe you should just omit the defined()?)
defined(@array) is deprecated at /u02/app/oracle/product/11.2.0/grid/OPatch/crs/crsconfig_lib.pm line 2149.
        (Maybe you should just omit the defined()?)
defined(@array) is deprecated at /u02/app/oracle/product/11.2.0/grid/OPatch/crs/crsconfig_lib.pm line 2227.
        (Maybe you should just omit the defined()?)
opatch auto log file location is /u02/app/oracle/product/11.2.0/grid/OPatch/crs/../../cfgtoollogs/opatchauto2012-02-09_01-37-59.log
Detected Oracle Restart install
Using configuration parameter file: /u02/app/oracle/product/11.2.0/grid/crs/install/crsconfig_params
patch /home/oracle/gi_psu_11.2.0.3.1/13348650/custom/server/13348650  apply successful for home  /u01/app/oracle/product/11.2.0/db_1
patch /home/oracle/gi_psu_11.2.0.3.1/13343438  apply successful for home  /u01/app/oracle/product/11.2.0/db_1
Successfully unlock /u02/app/oracle/product/11.2.0/grid
patch /home/oracle/gi_psu_11.2.0.3.1/13348650  apply successful for home  /u02/app/oracle/product/11.2.0/grid
patch /home/oracle/gi_psu_11.2.0.3.1/13343438  apply successful for home  /u02/app/oracle/product/11.2.0/grid
ACFS-9459: ADVM/ACFS is not supported on this OS version: 'Solaris 11 11/11 X86'
CRS-4123: Oracle High Availability Services has been started.

PSU补丁应用完毕以后,数据库会自动启动,接下来需要继续为数据库运行catbundle.sql。

cd $ORACLE_HOME/rdbms/admin
sqlplus / as sysdba
SQL> @catbundle.sql psu apply

检查PSU补丁情况。

$ opatch lsinventory | grep "Patch Set Update"
Patch Description:  "Database Patch Set Update : 11.2.0.3.1 (13343438)"
Patch Description:  "Grid Infrastructure Patch Set Update : 11.2.0.3.1 (13348650)"

$ sqlplus / as sysdba
SQL> select action,comments from registry$history;

ACTION                         COMMENTS
------------------------------ ------------------------------
APPLY                          PSU 11.2.0.3.1

How to Recover Datafile Which Deleted Accidentally in Linux

今天有客户的数据库意外被删除了整个目录中的数据文件,操作系统级别的删除,然而幸运的是这个数据库没有崩溃,仍然处于open状态的时候,客户就发现了问题,求助到我们,最终完整地恢复了所有数据文件。

在Linux下大致重新演示一下恢复的过程,恢复的步骤与数据库版本没有太大关系,与操作系统的不同会有所不同。

1. 在数据库open的时候,直接删除users表空间中的数据文件。

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/app/oracle/oradata/ORCL/datafile/o1_mf_system_555wqbnk_.dbf
/app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_555wqxgl_.dbf
/app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_555wr5p6_.dbf
/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf
 
SQL> host rm /app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf

2. 尝试在users表空间中创建表,开始报错。

SQL> create table t tablespace users as select * from dual;
create table t tablespace users as select * from dual
                                                 *
ERROR at line 1:
ORA-01116: error in opening database file 4
ORA-01110: data file 4:
'/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

在告警日志中,同样也可以看到类似信息。

Mon Dec 19 21:48:17 CST 2011
Errors in file /app/oracle/admin/orcl/bdump/orcl_m000_3897.trc:
ORA-01116: error in opening database file 4
ORA-01110: data file 4: '/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf'
ORA-27041: unable to open file
Linux Error: 2: No such file or directory
Additional information: 3

3. 检查dbwr的进程PID

$ ps -ef|grep dbw0|grep -v grep
oracle    2879     1  0 21:38 ?        00:00:00 ora_dbw0_orcl

4. dbwr会打开所有数据文件的句柄。在proc目录中可以查到,目录名是进程PID,fd表示文件描述符。

$ cd /proc/2879/fd
$ ls -l
total 0
lr-x------ 1 oracle dba 64 Dec 19 21:50 0 -> /dev/null
lr-x------ 1 oracle dba 64 Dec 19 21:50 1 -> /dev/null
lr-x------ 1 oracle dba 64 Dec 19 21:50 10 -> /dev/zero
lr-x------ 1 oracle dba 64 Dec 19 21:50 11 -> /dev/zero
lr-x------ 1 oracle dba 64 Dec 19 21:50 12 -> /app/oracle/product/10.2.0/db_1/rdbms/mesg/oraus.msb
lrwx------ 1 oracle dba 64 Dec 19 21:50 13 -> /app/oracle/product/10.2.0/db_1/dbs/hc_orcl.dat
lrwx------ 1 oracle dba 64 Dec 19 21:50 14 -> /app/oracle/product/10.2.0/db_1/dbs/lkORCL
lrwx------ 1 oracle dba 64 Dec 19 21:50 15 -> /app/oracle/oradata/ORCL/controlfile/o1_mf_555wq3ng_.ctl
lrwx------ 1 oracle dba 64 Dec 19 21:50 16 -> /app/oracle/oradata/ORCL/datafile/o1_mf_system_555wqbnk_.dbf
lrwx------ 1 oracle dba 64 Dec 19 21:50 17 -> /app/oracle/oradata/ORCL/datafile/o1_mf_undotbs1_555wqxgl_.dbf
lrwx------ 1 oracle dba 64 Dec 19 21:50 18 -> /app/oracle/oradata/ORCL/datafile/o1_mf_sysaux_555wr5p6_.dbf
lrwx------ 1 oracle dba 64 Dec 19 21:50 19 -> /app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf (deleted)
lr-x------ 1 oracle dba 64 Dec 19 21:50 2 -> /dev/null
lrwx------ 1 oracle dba 64 Dec 19 21:50 20 -> /app/oracle/oradata/ORCL/datafile/o1_mf_temp_555wrbnz_.tmp
lr-x------ 1 oracle dba 64 Dec 19 21:50 21 -> /app/oracle/product/10.2.0/db_1/rdbms/mesg/oraus.msb
lr-x------ 1 oracle dba 64 Dec 19 21:50 3 -> /dev/null
lr-x------ 1 oracle dba 64 Dec 19 21:50 4 -> /dev/null
l-wx------ 1 oracle dba 64 Dec 19 21:50 5 -> /app/oracle/admin/orcl/udump/orcl_ora_2871.trc
l-wx------ 1 oracle dba 64 Dec 19 21:50 6 -> /app/oracle/admin/orcl/bdump/alert_orcl.log
lrwx------ 1 oracle dba 64 Dec 19 21:50 7 -> /app/oracle/product/10.2.0/db_1/dbs/lkinstorcl (deleted)
l-wx------ 1 oracle dba 64 Dec 19 21:50 8 -> /app/oracle/admin/orcl/bdump/alert_orcl.log
lrwx------ 1 oracle dba 64 Dec 19 21:50 9 -> /app/oracle/product/10.2.0/db_1/dbs/hc_orcl.dat

注意其中“/app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf (deleted)”字样,表示该文件已经被删除,如果是Solaris操作系统,ls命令不会有如此清晰的显示,为了在Solaris系统中确认哪个句柄对应哪个文件,则需要使用lsof程序。

5. 直接cp该句柄文件名回原位置。

cp 19 /app/oracle/oradata/ORCL/datafile/o1_mf_users_555wrj4o_.dbf

6. 进行数据文件recover

SQL> alter database datafile 4 offline;

Database altered.

SQL> recover datafile 4;
Media recovery complete.
SQL> alter database datafile 4 online;

Database altered.

完成数据文件恢复。

恢复的原理是,在Linux操作系统中,如果文件从操作系统级别被rm掉,之前打开该文件的进程仍然持有相应的文件句柄,所指向的文件仍然可以读写,并且该文件的文件描述符可以从/proc目录中获得。但是要注意的是,此时如果关闭数据库,则此句柄会消失,那么除了扫描磁盘进行文件恢复之外就没有其它方法了,因此在数据库出现问题的时候,如果不确认情况的复杂程度,千万不要随便关闭数据库。重启数据库往往是没有意义的,甚至是致命的。

当然,客户的操作系统是Solaris,并且客户删除的文件还包括current online redo log,因此还有其它更复杂的操作,不在这里描述。