Category: Oracle Database

DBA, If don’t know what you are doing, please don’t do

14 Comments

今天收到一个发过来请求帮助的case，Oracle数据库无法启动，请求帮助恢复。仔细阅读了发过来的告警日志，这是一个典型的“事情越弄越糟”的案例。

以下就来根据告警日志，一条一条地回顾这位DBA是如何将数据库弄到完全启动不了的。

故障最开始是从1月11日的凌晨3:30开始出现，数据库在归档的时候，意外发现某个控制文件的头块全部被清零了，这可能是存储本身的问题，并非人为。

Fri Jan 11 03:30:24 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
Master background archival failure: 227
Fri Jan 11 03:31:24 2013
Hex dump of (file 0, block 1) in trace file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc
Corrupt block relative dba: 0x00000001 (file 0, block 1)
Completely zero block found during control file header read
Fri Jan 11 03:31:24 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc:
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
Fri Jan 11 03:31:24 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
Fri Jan 11 03:30:24 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
Fri Jan 11 03:30:24 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
Fri Jan 11 03:30:24 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'

接下来，数据库痛苦地挣扎了半小时，期间不停地报相同的ORA-00227错误。一直到凌晨4:01，终于CKPT进程也发现无法更新控制文件头部，于是强势地将数据库直接关闭了。

Fri Jan 11 04:01:25 2013
Hex dump of (file 0, block 1) in trace file /oracle/admin/dpdata/bdump/dpdata_ckpt_3007.trc
Corrupt block relative dba: 0x00000001 (file 0, block 1)
Completely zero block found during control file header read
Fri Jan 11 04:01:25 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_ckpt_3007.trc:
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
Fri Jan 11 04:01:25 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_ckpt_3007.trc:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
CKPT: terminating instance due to error 227
Fri Jan 11 04:01:25 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_pmon_2997.trc:
ORA-00227: corrupt block detected in control file: (block , # blocks )
Fri Jan 11 04:01:26 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_psp0_2999.trc:
ORA-00227: corrupt block detected in control file: (block , # blocks )
Instance terminated by CKPT, pid = 3007

接下来的5个小时，数据库静静地躺在机房里，没有人知道这个数据库已经挂掉了，一直到上午DBA来上班。他发现数据库无法访问，于是尝试重新启动数据库。

Fri Jan 11 09:15:51 2013
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on.

自然数据库无法正常启动，连mount状态都无法进入，因为某个控制文件头部已经损坏了。告警日志的信息明确地说明了无法读取control03.ctl文件的头块，因此在尝试mount数据库的时候报了ORA-00205错误。

Fri Jan 11 09:15:56 2013
ALTER DATABASE   MOUNT
Fri Jan 11 09:15:56 2013
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
ORA-27047: unable to read the header block of file
Additional information: 2
Fri Jan 11 09:15:59 2013
ORA-205 signalled during: ALTER DATABASE   MOUNT...
Fri Jan 11 09:19:31 2013
Starting ORACLE instance (normal)
Fri Jan 11 09:19:43 2013
alter database mount
Fri Jan 11 09:19:43 2013
ORA-00202: control file: '/oracle/oradata/dpdata/control03.ctl'
ORA-27047: unable to read the header block of file
Additional information: 2
Fri Jan 11 09:19:43 2013
ORA-205 signalled during: alter database mount

接下来，这位DBA开始反复地关闭实例，又启动实例。这样的操作一直持续了1个小时，一直到上午的10:28，可以想象这是多么纠结的一个小时。忠告: 除非十分特殊的恢复案例，否则反复起停数据库实例是于事无补的。

Shutting down instance: further logons disabled
Fri Jan 11 09:23:47 2013
Stopping background process CJQ0
……
Fri Jan 11 09:38:02 2013
Starting ORACLE instance (normal)
……
Fri Jan 11 09:43:00 2013
Shutting down instance: further logons disabled
……
Fri Jan 11 09:43:58 2013
Starting ORACLE instance (normal)
……
Fri Jan 11 09:55:34 2013
ALTER DATABASE CLOSE NORMAL
……
Fri Jan 11 09:56:55 2013
Starting ORACLE instance (normal)
……
Fri Jan 11 10:28:10 2013
ALTER DATABASE CLOSE NORMAL

接下来10:29的再次重新启动数据库实例之前，DBA终于意识到可能是控制文件出现了问题，因此修改了初始化参数，将报错的control03.ctl文件从初始化参数control_files中去掉了。这次数据库得以正常启动。

Fri Jan 11 10:29:20 2013
Starting ORACLE instance (normal)
……
control_files            = /data1/oradata/dpdata/control01.ctl, /data1/oradata/dpdata/control02.ctl
……
Fri Jan 11 10:29:37 2013
Completed: ALTER DATABASE OPEN

而DBA也迅速地作了一次备份控制文件的操作，但是正是这个操作引导到了后面噩梦一般的结果。

Fri Jan 11 10:36:14 2013
alter database backup controlfile to trace
Fri Jan 11 10:36:14 2013
Completed: alter database backup controlfile to trace

数据库又平稳地运行了一个上午，这种宁静到下午14:16的时候被打破，数据库开始报ORA-600错误，并且在CKPT进程作检查点的时候，报数据文件10和31的文件头部无法被正确读取。如果不是更深层次的原因，那么这可能仍然是跟凌晨时候控制文件意外损坏时候的故障一样，也许是存储子系统本身的问题。

Fri Jan 11 14:16:07 2013
Errors in file /oracle/admin/dpdata/udump/dpdata_ora_22240.trc:
ORA-00600: internal error code, arguments: [6002], [0], [0], [3], [0], [], [], []
Fri Jan 11 14:19:44 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_ckpt_9579.trc:
ORA-01171: datafile 10 going offline due to error advancing checkpoint
ORA-01122: database file 10 failed verification check
ORA-01110: data file 10: '/data2/DECTR_HIS2.dbf'
ORA-01251: Unknown File Header Version read for file number 10
Fri Jan 11 14:19:59 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_ckpt_9579.trc:
ORA-01171: datafile 31 going offline due to error advancing checkpoint
ORA-01122: database file 31 failed verification check
ORA-01110: data file 31: '/data3/ts2_dpcis.dbf'
ORA-01251: Unknown File Header Version read for file number 31

紧接着，应用系统的某个JOB也由于数据文件无法访问，而开始报错。

Fri Jan 11 14:30:19 2013
Errors in file /oracle/admin/dpdata/bdump/dpdata_j001_12993.trc:
ORA-12012: error on auto execute of job 88
ORA-00376: file 10 cannot be read at this time
ORA-01110: data file 10: '/data2/DECTR_HIS2.dbf'
ORA-06512: at "DECTR.P_MOVE_CONTS_SHIP", line 77
ORA-06512: at line 1

相同的报错一直持续了四十多分钟，之后DBA又再次介入了。但是DBA很奇怪地断然执行了offline这两个数据文件的操作，并在2分多钟之后，又尝试将两个数据文件再次online。而由于文件损坏，自然在online的时候遇到了ORA-1122错误，而无法成功online。

Fri Jan 11 15:16:23 2013
alter database datafile '/data3/ts2_dpcis.dbf' offline
Fri Jan 11 15:16:23 2013
Completed: alter database datafile '/data3/ts2_dpcis.dbf' offline
Fri Jan 11 15:17:05 2013
alter database datafile  '/data2/DECTR_HIS2.dbf'
offline
Fri Jan 11 15:17:05 2013
Completed: alter database datafile  '/data2/DECTR_HIS2.dbf'
offline
Fri Jan 11 15:19:41 2013
alter database datafile '/data3/ts2_dpcis.dbf' online
Fri Jan 11 15:19:41 2013
ORA-1122 signalled during: alter database datafile '/data3/ts2_dpcis.dbf' online...
Fri Jan 11 15:21:10 2013
alter database datafile  '/data2/DECTR_HIS2.dbf' online
Fri Jan 11 15:21:10 2013
ORA-1122 signalled during: alter database datafile  '/data2/DECTR_HIS2.dbf' online...

这才仅仅是噩梦的开始，接下来的一切属于危险动作，请勿轻易模仿。

遇到ORA-1122错误以后，DBA考虑了9秒钟，再次断然地关闭了数据库，并随之又重新启动。由于仅仅是用户表空间数据文件损坏，并且之前也已经被offline了，因此数据库实例毫无障碍地OPEN成功。

Fri Jan 11 15:21:19 2013
Shutting down instance: further logons disabled
Fri Jan 11 15:21:19 2013
Stopping background process QMNC
Fri Jan 11 15:21:19 2013
Stopping background process CJQ0
Fri Jan 11 15:21:21 2013
Stopping background process MMNL
Fri Jan 11 15:21:22 2013
Stopping background process MMON
Fri Jan 11 15:21:23 2013
Shutting down instance (immediate)
……
Fri Jan 11 15:22:59 2013
Starting ORACLE instance (normal)
……
Fri Jan 11 15:23:13 2013
Completed: ALTER DATABASE OPEN

DBA再次尝试online数据文件的操作，同样的ORA-1122错误。

Fri Jan 11 15:23:31 2013
alter database datafile '/data3/ts2_dpcis.dbf' online
Fri Jan 11 15:23:31 2013
ORA-1122 signalled during: alter database datafile '/data3/ts2_dpcis.dbf' online...

考虑了2分半钟之后，DBA也许是想起上午的时候做过控制文件的备份，因此决定进行数据库恢复。重启数据库到nomount状态，并开始进行RECOVER DATABASE USING BACKUP CONTROLFILE，ORA-1507错误的意思是告知如果要使用备份的控制文件进行数据库恢复，那么应该要先使用备份的控制文件将数据库启动到mount状态。

Fri Jan 11 15:25:05 2013
Shutting down instance: further logons disabled
Fri Jan 11 15:25:05 2013
Stopping background process QMNC
Fri Jan 11 15:25:05 2013
Stopping background process CJQ0
Fri Jan 11 15:25:07 2013
Stopping background process MMNL
Fri Jan 11 15:25:08 2013
Stopping background process MMON
Fri Jan 11 15:25:09 2013
Shutting down instance (immediate)
……
Fri Jan 11 15:26:32 2013
Starting ORACLE instance (normal)
……
Fri Jan 11 15:26:46 2013
ALTER DATABASE RECOVER  database using backup controlfile until cancel  
Fri Jan 11 15:26:46 2013
ORA-1507 signalled during: ALTER DATABASE RECOVER  database using backup controlfile    until cancel  ...

DBA于是将数据库启动到mount状态，继续进行数据库恢复。这其中的几个ORA错误都是正常的，ORA-279提示需要一个归档文件来完成恢复，ORA-308提示打不开1_87749_604491553.dbf归档文件，根据前面的告警日志，可以知道实际上87749这个重做日志是当前日志，还没有归档，自然找不到。ORA-1547错误表示恢复已经完成，但是OPEN RESETLOGS的时候仍然要遇到错误。

Fri Jan 11 15:26:56 2013
alter database mount
Fri Jan 11 15:27:00 2013
Setting recovery target incarnation to 2
Fri Jan 11 15:27:00 2013
Successful mount of redo thread 1, with mount id 560899584
Fri Jan 11 15:27:00 2013
Database mounted in Exclusive Mode
Completed: alter database mount
Fri Jan 11 15:27:10 2013
ALTER DATABASE RECOVER  database using backup controlfile until cancel  
Media Recovery Start
 parallel recovery started with 3 processes
ORA-279 signalled during: ALTER DATABASE RECOVER  database using backup controlfile until cancel  ...
Fri Jan 11 15:27:28 2013
ALTER DATABASE RECOVER    CONTINUE DEFAULT  
Fri Jan 11 15:27:28 2013
Media Recovery Log /soft/db_arch/1_87749_604491553.dbf
Errors with log /soft/db_arch/1_87749_604491553.dbf
ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Fri Jan 11 15:27:28 2013
ALTER DATABASE RECOVER    CONTINUE DEFAULT  
Fri Jan 11 15:27:28 2013
Media Recovery Log /soft/db_arch/1_87749_604491553.dbf
Errors with log /soft/db_arch/1_87749_604491553.dbf
ORA-308 signalled during: ALTER DATABASE RECOVER    CONTINUE DEFAULT  ...
Fri Jan 11 15:27:28 2013
ALTER DATABASE RECOVER CANCEL 
ORA-1547 signalled during: ALTER DATABASE RECOVER CANCEL ...

DBA忽略了这个错误，尝试将数据库打开，很显然会遇到ORA-1589错误，之后又尝试用NORESTLOGS方式OPEN数据库，这也很显然会遇到ORA-1588错误。不完全恢复的数据库必须要以RESETLOGS方式打开。

Fri Jan 11 15:29:52 2013
alter database open
Fri Jan 11 15:29:52 2013
ORA-1589 signalled during: alter database open...
Fri Jan 11 15:30:11 2013
alter database open NORESETLOGS
Fri Jan 11 15:30:11 2013
ORA-1588 signalled during: alter database open NORESETLOGS

之后，DBA作了一个艰难的决定，再次关闭并重启了数据库。又再次尝试相同的OPEN步骤。当然，Oracle也给与了相同的报错。数据库仍然无法打开。至此，数据库无法提供服务已经1个多小时。

Fri Jan 11 15:30:42 2013
Shutting down instance: further logons disabled
Fri Jan 11 15:30:42 2013
Stopping background process CJQ0
Fri Jan 11 15:30:42 2013
Stopping background process MMNL
Fri Jan 11 15:30:43 2013
Stopping background process MMON
Fri Jan 11 15:30:44 2013
Shutting down instance (immediate)
……
Fri Jan 11 15:30:59 2013
Starting ORACLE instance (normal)
……
Fri Jan 11 15:31:08 2013
ALTER DATABASE OPEN
ORA-1589 signalled during: ALTER DATABASE OPEN...
Fri Jan 11 15:31:28 2013
alter database open NORESETLOGS
Fri Jan 11 15:31:28 2013
ORA-1588 signalled during: alter database open NORESETLOGS...
Fri Jan 11 15:31:41 2013
alter database open RESETLOGS
Fri Jan 11 15:31:41 2013
ORA-1122 signalled during: alter database open RESETLOGS...

再接下来，是一团混乱，DBA多次重启数据库，尝试了多种恢复手段。offline数据文件，recover数据文件，recover数据库，online数据文件，再recover，再offline，再open，但是一切尝试都是徒劳的。一直到晚上18:35，在数据库宕机4个多小时以后，开始求助我们帮助其恢复数据库。

Fri Jan 11 15:41:28 2013
alter database datafile '/data2/DECTR_HIS2.dbf' offline
Completed: alter database datafile '/data2/DECTR_HIS2.dbf' offline
Fri Jan 11 15:41:35 2013
alter database open
Fri Jan 11 15:41:35 2013
ORA-1589 signalled during: alter database open...
Fri Jan 11 15:42:20 2013
alter database  open resetlogs
Fri Jan 11 15:42:20 2013
ORA-1245 signalled during: alter database  open resetlogs...
Fri Jan 11 15:43:40 2013
ALTER DATABASE RECOVER  datafile '/data3/ts2_dpcis.dbf'  
Fri Jan 11 15:43:40 2013
Media Recovery Start
Fri Jan 11 15:43:40 2013
Media Recovery failed with error 1610
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile '/data3/ts2_dpcis.dbf'  ...
Fri Jan 11 15:46:09 2013
ALTER DATABASE RECOVER  datafile 10  
Fri Jan 11 15:46:09 2013
Media Recovery Start
Fri Jan 11 15:46:09 2013
Media Recovery failed with error 1610
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile 10  ...
……
Fri Jan 11 16:37:51 2013
ALTER DATABASE RECOVER  database  
Fri Jan 11 16:37:51 2013
Media Recovery Start
Fri Jan 11 16:37:51 2013
Media Recovery failed with error 1610
ORA-283 signalled during: ALTER DATABASE RECOVER  database  ...
Fri Jan 11 16:39:29 2013
ALTER DATABASE RECOVER  database using backup controlfile until cancel  
Fri Jan 11 16:39:29 2013
Media Recovery Start
 parallel recovery started with 3 processes
ORA-279 signalled during: ALTER DATABASE RECOVER  database using backup controlfile until cancel  ...
Fri Jan 11 16:39:43 2013
ALTER DATABASE RECOVER    CANCEL  
Fri Jan 11 16:39:44 2013
ORA-1547 signalled during: ALTER DATABASE RECOVER    CANCEL  ...
Fri Jan 11 16:39:44 2013
ALTER DATABASE RECOVER CANCEL 
ORA-1112 signalled during: ALTER DATABASE RECOVER CANCEL ...
Fri Jan 11 16:40:15 2013
alter database datafile 10 online
Fri Jan 11 16:40:15 2013
Completed: alter database datafile 10 online
Fri Jan 11 16:40:25 2013
alter database datafile 31 online
Completed: alter database datafile 31 online
Fri Jan 11 16:40:47 2013
ALTER DATABASE RECOVER  database using backup controlfile until cancel  
Fri Jan 11 16:40:47 2013
Media Recovery Start
Fri Jan 11 16:40:47 2013
Media Recovery failed with error 1110
ORA-283 signalled during: ALTER DATABASE RECOVER  database using backup controlfile until cancel  ...
Fri Jan 11 16:47:12 2013
WARNING: inbound connection timed out (ORA-3136)
Fri Jan 11 17:44:47 2013
ALTER DATABASE RECOVER  datafile 10  
Fri Jan 11 17:44:47 2013
Media Recovery Start
Fri Jan 11 17:44:47 2013
Media Recovery failed with error 1610
ORA-283 signalled during: ALTER DATABASE RECOVER  datafile 10  ...
Fri Jan 11 17:45:19 2013
ALTER DATABASE RECOVER  database until cancel using backup controlfile  
Fri Jan 11 17:45:19 2013
Media Recovery Start
Fri Jan 11 17:45:19 2013
Media Recovery failed with error 1110
ORA-283 signalled during: ALTER DATABASE RECOVER  database until cancel using backup controlfile  ...
Fri Jan 11 17:46:39 2013
alter database datafile 10 offline
Fri Jan 11 17:46:40 2013
Completed: alter database datafile 10 offline
Fri Jan 11 17:47:18 2013
ALTER DATABASE RECOVER  database until cancel  
Fri Jan 11 17:47:18 2013
Media Recovery Start
Fri Jan 11 17:47:18 2013
Media Recovery failed with error 1610
ORA-283 signalled during: ALTER DATABASE RECOVER  database until cancel  ...
Fri Jan 11 18:11:31 2013
alter database open
Fri Jan 11 18:11:31 2013
ORA-1589 signalled during: alter database open...
Fri Jan 11 18:35:29 2013
Starting ORACLE instance (normal)
Fri Jan 11 18:35:43 2013
alter database open
Fri Jan 11 18:35:43 2013
ORA-1589 signalled during: alter database open...

这是一个没有备份的数据库，实际上如果是存储字系统的问题导致了数据文件损坏，那么可能与DBA的关系并不大，但是在经过一下午的折腾，将一个其实仅仅是坏了2个数据文件而可以轻松OPEN的数据库恢复到无论如何也无法轻易打开的状态，这就与DBA有很大的关系了。

Compare SAP HANA with Oracle Exadata

6 Comments

【前言】
本文的最终观点：如果不是拿全公司的产品线来混合搭配，如果仅就一款产品而言，无论其它厂商如何宣传，目前整个IT业界还没有任何一款一体机产品能跟Oracle Exadata同场较量，TeraData不能，IBM PureSystem不能，SAP HANA也同样不能。而SAP HANA可能更应该拿自己去跟Exalytics作比较，而不是Exadata。

本文对于SAP HANA的认知来自于“SAP HANA Essentials eBook”以及Experience SAP HANA站点，完全属于纸上谈兵，如果有更熟悉SAP HANA技术的技术人员认为本文有失偏颇，欢迎指正。

【正文】
需要承认SAP HANA的出现，在理念上与Oracle Exadata几乎是完全一致的，SAP也意识到大量的数据要从缓慢的磁盘子系统中读取到计算资源中，这部分读取操作成为了最大的性能瓶颈，解决方法就是在计算时减少不必要的IO。对此，SAP HANA的解决方案是跳过磁盘层，通过压缩，将大量数据完全放到内存中，当然于此相配套的还有一些对于数据持久化的技术解决方案，但是无论如何，HANA作到的只是内存间计算而已，能够做到这一点，几乎完全得益于硬件的发展，如果不是当前内存容量剧增而成本却持续下降的话，几乎无法想象HANA能够成为普遍的企业级解决方案。

而与HANA相比，很明显Oracle Exadata在磁盘层读取技术上进行了大量创新，Smart Scan以及Storage Index等技术，都是更有意思的创造，从这一点而言，Oracle的创新更大，作为内存数据库＋内存分析解决方案的Exalytics提供了跟Exadata的完美连接，如果需要分析的数据过于庞大而无法完全放置在Exalytics的内存中，那么仍然可以通过Exadata中的压缩，并行，智能扫描等创新技术来加速存储在磁盘中的数据的计算。这是一套更完善的解决方案，也更适合企业IT架构更平滑的过渡。

我们可以简单地认为SAP HANA是一个内存数据库解决方案（这可以与Oracle TimesTen相比较），或者称为内存计算解决方案（这可以与整合了Oracle BI，Oracle TimesTen以及Essbase的Exalytics相比较），这与Exadata的定位以及地位完全不一样。

说的更直白一些，凭着内存足够大，将数据都放到内存中，来获得计算速度的提升，这算什么创新的本事？内存大了，哪家数据库厂家花点儿心思在持久化保存上，都能这么干，这样并无核心竞争力。

以下列出一些分散的并不成体系的关于SAP HANA和Oracle Exadata的观点，同样，欢迎点评及讨论。

1. SAP HANA中列式表和行式表的转换也许是一个亮点。我想Oracle在Exadata中应该借鉴。

2. HANA迄今为止只支持报表应用，因此维护大并发需要的事务锁机制这个最大的技术难点目前看SAP还没有任何解决方案，那么这样的产品并不能与Exadata相提并论。事实是这样的：一直到2012年之前，SAP HANA的解决方案都称为SAP BW Accelerator，这需要一个独立的HANA数据库来完成BI报表，直到SAP BW 7.3 SP5 on SAP HANA的出现，HANA可以当作主数据库使用，不但是查询，而且企业数据改变也直接访问HANA，但这也仍然只是面对数据仓库以及BI领域的应用，这时候被称为SAP NetWeaver BW Powered by SAP HANA（说实话，这名字真够长的）。迄今为止HANA还未能宣布支持真正OLTP应用的案例。

3. HANA的数据持久化机制从文档上看，并无任何特殊之处，几乎与Oracle完全一样，通过将提交的事务写入log，来保证断电重启以后，可以重演log，这就是Oracle的redolog写机制。

4. 成本比较，HANA的硬件成本更贵，因为需要的内存更大；而同时只要企业真正业务产生的最原始数据是需要通过数据传输/同步手段（无论这个传输过程标称如何快速、如何实时）转移到HANA中的，HANA就还需要表复制，表同步的时间和人力成本；还需要额外的手段将SAP应用的相关报表数据迁移到HANA中，即使SAP宣称有快速的最佳实践部署方式，但是只要一种方式可以被称为solution，那就不会太简单。

5. SAP把HANA视为革命性地创新，试图打造一个围绕在HANA周边的原厂，合作伙伴，客户共同创造新应用的生态圈，虽然我们需要承认内存计算导致的应用延迟降低，确实具有其革命性的潜质，但是我仍然认为SAP期望过高。
HANA的多合作伙伴硬件一体机架构，可能会导致混乱。虽然SAP限定了CPU型号（Intel E7），内存型号（Samsung），以及操作系统版本（SUSE Linux SLES 11），但是每家合作伙伴的硬件设计工艺都不尽相同，服务能力也有差距，而SAP自身是否有足够能力同时保证七个硬件厂家（目前7家合作伙伴是Cisco, Dell, Fujitsu, IBM, HP, Hitachi, NEC）产品上运行HANA的性能，质量，可用性的测试认证，这也存在疑问。这并非一体机的好模式。

6. SAP的优势在于从ERP应用往下层延升，试图进入新一代数据库市场，而Oracle本来就占据数据库市场霸主地位，Exa系列的推出拓展了一片新的一体机天地，看看能否借助这样的优势，往上层延升，获得更大的ERP应用市场份额。

7. 在文档中多处看到了以Apple为例，看来Apple才是现今各种创新的源头，大家都从Apple那里学习和借鉴。各大厂商实际上都在尽量整合自己的解决方案，历来都如是，所以如果从这个意义上而言，其实从来就不缺乏一体机的概念。不过你有办法想象苹果的成功会来自于苹果提供iOS，指定芯片类型，而由三星或者诺基亚来制造手机吗？所以看上去Oracle在学Apple，而SAP在学Google的Android策略。

最后，有两个疑问能否有人帮我解答？
1. HANA的后台持久化磁盘存储也是共享磁盘，这是需要一个SAN磁盘阵列吗？那么一个HANA集群中的多个数据库实例是通过Share Everything的方式来共享访问这个存储？
2. 如果一个HANA节点挂掉了，这部分数据全部重新加载到备用节点的内存中，这个过程大约要花多长时间？我现在获得的数据是每秒钟扫描100TB数据集中的1000亿条记录（这个说法实在模糊，是扫描100TB数据还是扫描1000亿条记录，1000亿条记录又是多大数据？），每分钟可以加载1600万记录到内存中，这样的话，一秒钟扫描的数据也需要加载10小时才行？

Python for the Oracle DBA on Mac OS X Lion (1)

2 Comments

作为一个技术人员，不学习一门编程语言，人生是不完整的。
是Shell是Perl还是Python，哪个简单哪个好用，哪个更适合Oracle DBA，这不是本文的范围，俗话说，萝卜青菜，各有所爱。

Mac OS X中自带Python（实际上也自带Shell和Perl），在Lion之后，由于64bit Oracle客户端无法在Mac中正常运行，导致一系列的麻烦。在Python中连接Oracle数据库，通常是使用cx_Oracle扩展模块。如果是Windows或者CentOS/Redhat/OEL Linux可以直接在cx-oracle.sourceforge.net下载相应的安装文件，但是对于Mac而言，却必须下载源码，自行编译。需要解决64bit问题和Oracle Instant Client配置问题。

文本大部分内容参考Andy Chan的Tutorial: How to Install Python Oracle Module “cx_Oracle” on Mac OS X Lion。

在作一切操作之前，请先确认已经安装了XCode，并且安装了Command Line Tools，否则会在最后编译安装cx_Oracle的时候报错：unable to execute llvm-gcc-4.2: No such file or directory

1. 安装Oracle Instant Client，由于众所周知的64bit客户端在Mac OS X Lion中回发生“Segmentation fault: 11”的错误，因此必须下载32bit版本。
编译cx_Oracle需要下载如下图的两个安装文件，不过实际上我是除了Basic Lite之外都下载安装了。具体安装步骤及其它设置可以参看之前我的文章：How to use Oracle Instant Client in Mac OS X Lion。

2. Oracle Instant Client的安装实际上就是解压，然后将生成的目录放在$PATH环境变量中，我将解压后的目录放在：/Applications/Utilities/instantclient，目录中的内容如下：

bogon:instantclient Kamus$ ls -l
total 204152
-rw-r--r--@  1 Kamus  staff       278 Apr  1  2009 BASIC_README
-rw-r--r--@  1 Kamus  staff       276 Apr  1  2009 JDBC_README
-rw-r--r--@  1 Kamus  staff       282 Apr  1  2009 SQLPLUS_README
drwxr-xr-x   3 Kamus  admin       102 Aug  9  2011 bin
-rw-r--r--@  1 Kamus  staff   1609607 Feb  2  2008 classes12.jar
-rwxr-xr-x@  1 Kamus  staff     30556 Apr  1  2009 genezi
-rwxr-xr-x@  1 Kamus  staff      1555 Aug  9  2011 glogin.sql
drwxr-xr-x  13 Kamus  admin       442 Jul 22 01:38 lib
lrwxr-xr-x   1 Kamus  admin        20 Jul 22 01:38 libclntsh.dylib -> libclntsh.dylib.10.1
-rwxr-xr-x@  1 Kamus  staff  21537536 Mar 31  2009 libclntsh.dylib.10.1
-rwxr-xr-x@  1 Kamus  staff     31788 Mar 25  2009 libheteroxa10.dylib
-rwxr-xr-x@  1 Kamus  staff     31788 Mar 25  2009 libheteroxa10.jnilib
-rwxr-xr-x@  1 Kamus  staff   1683924 Feb 11  2009 libnnz10.dylib
-rwxr-xr-x@  1 Kamus  staff   1142284 Feb 11  2009 libocci.dylib.10.1
-rwxr-xr-x@  1 Kamus  staff  72626824 Apr  1  2009 libociei.dylib
-rwxr-xr-x@  1 Kamus  staff    106184 Mar 25  2009 libocijdbc10.dylib
-rwxr-xr-x@  1 Kamus  staff    106184 Mar 25  2009 libocijdbc10.jnilib
-rwxr-xr-x@  1 Kamus  staff    933744 Mar 25  2009 libsqlplus.dylib
-rwxr-xr-x@  1 Kamus  staff   1442316 Feb 11  2009 libsqlplusic.dylib
drwxr-xr-x   3 Kamus  admin       102 Jul 30  2011 network
-rw-r--r--@  1 Kamus  staff   1555682 Feb  2  2008 ojdbc14.jar
-rw-r--r--@  1 Kamus  staff   1646178 Jan 23  2008 orai18n.jar
drwxr-xr-x@  7 Kamus  admin       238 Apr  1  2009 sdk
drwxr-xr-x   3 Kamus  admin       102 Aug  9  2011 sqlplus

其中需要注意的是：
1) libclntsh.dylib是需要手工创建的链接。

ln -s libclntsh.dylib.10.1 libclntsh.dylib

2) lib目录，在默认解压以后，没有该目录，需要手工创建，然后将所有lib*复制到该目录中。否则在安装cx_Oracle的时候会报错：无法找到正确的ORACLE_HOME。我的lib目录中文件列表如下：

bogon:instantclient Kamus$ ls -l lib
total 194656
lrwxr-xr-x  1 Kamus  admin        20 Jul 22 01:38 libclntsh.dylib -> libclntsh.dylib.10.1
-rwxr-xr-x@ 1 Kamus  admin  21537536 Jul 22 01:36 libclntsh.dylib.10.1
-rwxr-xr-x@ 1 Kamus  admin     31788 Jul 22 01:36 libheteroxa10.dylib
-rwxr-xr-x@ 1 Kamus  admin     31788 Jul 22 01:36 libheteroxa10.jnilib
-rwxr-xr-x@ 1 Kamus  admin   1683924 Jul 22 01:36 libnnz10.dylib
-rwxr-xr-x@ 1 Kamus  admin   1142284 Jul 22 01:36 libocci.dylib.10.1
-rwxr-xr-x@ 1 Kamus  admin  72626824 Jul 22 01:36 libociei.dylib
-rwxr-xr-x@ 1 Kamus  admin    106184 Jul 22 01:36 libocijdbc10.dylib
-rwxr-xr-x@ 1 Kamus  admin    106184 Jul 22 01:36 libocijdbc10.jnilib
-rwxr-xr-x@ 1 Kamus  admin    933744 Jul 22 01:36 libsqlplus.dylib
-rwxr-xr-x@ 1 Kamus  admin   1442316 Jul 22 01:36 libsqlplusic.dylib

3. 修改环境变量，将以下行添加到~/.bash_profile文件中。

export ORACLE_HOME=/Applications/Utilities/instantclient
export LD_LIBRARY_PATH=ORACLE_HOME
export DYLD_LIBRARY_PATH=ORACLE_HOME
export SQLPATH=ORACLE_HOME
export PATH=PATH:$ORACLE_HOME/bin
#for cx_Oracle，这是必须的，强制Python使用32位版本
export VERSIONER_PYTHON_PREFER_32_BIT=yes

4. 启动新的Terminal窗口，先安装pip，pip是Python的包管理软件，使用pip可以方便地从网络上直接安装需要的Python模块。

sudo easy_install pip

5. 安装cx_Oracle

sudo pip install cx_Oracle

安装过程中产生的类似如下这些警告，可以忽略：

/Applications/Utilities/instantclient/sdk/include/nzt.h:2746: warning: function declaration isn’t a prototype
......
Connection.c:283: warning: implicit conversion shortens 64-bit value into a 32-bit value
......

最终显示如下信息表示安装成功：

Successfully installed cx-Oracle

6. 最后测试一下cx_Oracle是否工作正常。具体语法参看：cx_Oracle 5.1.2 documentation。

bogon:~ Kamuspython
Python 2.7.1 (r271:86832, Aug  5 2011, 03:30:24) 
[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from cx_Oracle import connect
>>> conn=connect('kamus/oracle@www.enmotech.com:1521/orcl')
>>> curs = conn.cursor()
>>> curs.execute("select * from vversion")
<__builtin__.OracleCursor on >
>>> rows = curs.fetchall()
＃＃以下报错是Python语法对于强制代码缩进的体现，如果for循环中的语句开头没有缩进，则会报错。
>>> for i in range(len(rows)):
... print rows[i][0]
  File "", line 2
    print rows[i][0]
        ^
IndentationError: expected an indented block 
＃＃在print前增加两个空格即可
>>> for i in range(len(rows)):
...   print rows[i][0]
... 
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
PL/SQL Release 11.2.0.3.0 - Production
CORE	11.2.0.3.0	Production
TNS for Solaris: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production