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

今天收到一个发过来请求帮助的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有很大的关系了。

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

作为一个技术人员,不学习一门编程语言,人生是不完整的。
是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:~ Kamus$ python
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 v$version")
<__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

Oracle Datafiles & Block Device & Parted & Udev

需求:
1. 使用裸设备作为Oracle数据文件,而且要跳过操作系统或者其它软件提供的卷管理(比如Linux下的LVM)。
2. 由于small datafile限制,有大量磁盘分区需要创建。

以下测试环境操作系统为CentOS 6.0,如果你的操作是RHEL6或者OEL6,也同样适用,如果是RHEL5或者OEL5,那么udev部分的命令是不相同的。但是只需要在操作系统中man udev,查看一下相应的语法即可,思路是相同的。

解决方案:
1. 使用parted命令,脚本式创建多个分区,使用gpt类型分区表,这样可以创建大量primary分区,而如果使用msdos分区,则必须要要创建extend分区,然后再创建logical分区,这样在后面的udev规则文件中,还需要将extend分区排除出去,比较麻烦。

在我的测试环境中,对于/dev/sdc磁盘进行操作,分了11个分区,每个50M。

parted -s /dev/sdc mklabel gpt 
parted -s /dev/sdc unit MB mkpart primary 1 50 
parted -s /dev/sdc unit MB mkpart primary 50 100 
parted -s /dev/sdc unit MB mkpart primary 100 150 
parted -s /dev/sdc unit MB mkpart primary 150 200 
parted -s /dev/sdc unit MB mkpart primary 250 300 
parted -s /dev/sdc unit MB mkpart primary 300 350 
parted -s /dev/sdc unit MB mkpart primary 350 400 
parted -s /dev/sdc unit MB mkpart primary 400 450 
parted -s /dev/sdc unit MB mkpart primary 450 500 
parted -s /dev/sdc unit MB mkpart primary 500 550 
parted -s /dev/sdc unit MB mkpart primary 550 600

如果在生产环境的Oracle数据库中,block_size=2K的表空间,单个数据文件最大8G,可以使用:

parted -s /dev/sdc unit GB mkpart primary 1 8 

2. 设置udev规则。如何在CentOS 6中设置udev,可以参看我之前的文章 - How to use udev for Oracle ASM in Oracle Linux 6

vi /etc/udev/rules.d/99-oracle.rules

添加如下行:

KERNEL=="sd?[1-9]", SUBSYSTEM=="block", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="36000c293bd690056ce6834434765d3f4", NAME="oradisk0$number", SYMLINK="mapper/$name", OWNER="oracle",  GROUP="dba", MODE="0660"
KERNEL=="sd?1[0-9]", SUBSYSTEM=="block", PROGRAM=="/sbin/scsi_id --whitelisted --replace-whitespace --device=/dev/$name", RESULT=="36000c293bd690056ce6834434765d3f4", NAME="oradisk$number", SYMLINK="mapper/$name", OWNER="oracle",  GROUP="dba", MODE="0660"

重启udev服务:

start_udev

然后可以发现/dev/mapper下的链接都成功创建,并且指向规则中定义的块设备名称。

# ls -l /dev/mapper/
total 0
crw-rw----. 1 root root 10, 58 Dec 29 03:29 control
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk01 -> ../oradisk01
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk02 -> ../oradisk02
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk03 -> ../oradisk03
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk04 -> ../oradisk04
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk05 -> ../oradisk05
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk06 -> ../oradisk06
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk07 -> ../oradisk07
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk08 -> ../oradisk08
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk09 -> ../oradisk09
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk10 -> ../oradisk10
lrwxrwxrwx. 1 root root     12 Dec 29 03:29 oradisk11 -> ../oradisk11

注意,此时/dev目录下,sdc1至sdc11设备都不再存在了,但是我们可以通过比较设备的major号和minor号来确认绑定是正确的。

# ls -l /dev/mapper/oradisk01
lrwxrwxrwx. 1 root root 12 Dec 29 03:29 /dev/mapper/oradisk01 -> ../oradisk01
# ls -l /dev/oradisk01
brw-rw----. 1 oracle dba 8, 33 Dec 29 03:29 /dev/oradisk01
# cat /proc/partitions | grep 33
   8       33      48128 sdc1

3. 直接使用/dev/mapper/oradisk*作为数据文件
由于在Oracle 10.2.0.2以后,Oracle已经可以用O_DIRECT标志直接打开块设备,而不是像以前版本那样,如果要跳过操作系统缓存直接读写磁盘设备,必须要用使用字符设备。在以前的版本中,因为要使用字符设备,所以才需要用raw命令去将某一个块设备映射为一个裸设备(字符设备)。而在Oracle 10.2.0.2以后则可以直接使用块设备(比如/dev/sdc1,比如udev映射以后的/dev/oradisk01,这些都是块设备),不过,虽然Oracle 10.2.0.2以后,Oracle可以直接读取块设备,但是在Oracle 11g以前,这个特性还不被OUI支持,如果要在OUI中使用,则需要使用符号链接(symbolic links),如我们用udev创建的/dev/mapper/oradisk*。
也就是在Oracle 10.2.0.2以后,Oracle 11g以前,需要使用/dev/mapper/oradisk*这样的符号链接作为数据文件。
在Oracle 11g以后,可以使用符号链接,也可以直接使用/dev/oradisk*作为数据文件。

如果你们认为有更优的最佳实践,欢迎讨论。当然我们也可以使用lvm或者Oracle ASM来处理数据文件的存储,这不在本文讨论范围内。

BTW: 一个有趣的bug?在测试中发现,如果在udev创建完符号链接之后,再使用parted来查看链接的分区情况,则会导致链接消失,而映射前的sdc1设备名重新出现。重启udev服务也无法将链接重新创建,但是用parted重新查看sdc1设备,则链接又重新出现,sdc1又重新消失。求解释。

--正常情况下有符号链接
[root@localhost ~]# ls -l /dev/mapper/oradisk01
lrwxrwxrwx. 1 root root 12 Dec 29 03:29 /dev/mapper/oradisk01 -> ../oradisk01
--映射前的sdc1设备是不存在的
[root@localhost ~]# ls -l /dev/sdc1
ls: cannot access /dev/sdc1: No such file or directory
--用parted检查链接,或者检查/dev/oradisk01块设备,效果是一样的
[root@localhost ~]# parted /dev/mapper/oradisk01
GNU Parted 2.1
Using /dev/mapper/oradisk01
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) q                                                                
--链接消失
[root@localhost ~]# ls -l /dev/mapper/oradisk01
ls: cannot access /dev/mapper/oradisk01: No such file or directory
--映射的块设备还在
[root@localhost ~]# ls -l /dev/oradisk01
brw-rw----. 1 oracle dba 8, 33 Dec 29 03:29 /dev/oradisk01
--原先的sdc1设备出现
[root@localhost ~]# ls -l /dev/sdc1
brw-rw----. 1 root disk 8, 33 Dec 29 04:29 /dev/sdc1
--重新用parted检查sdc1
[root@localhost ~]# parted /dev/sdc1
GNU Parted 2.1
Using /dev/sdc1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) q                                                                
--符号链接重新出现
[root@localhost ~]# ls -l /dev/mapper/oradisk01
lrwxrwxrwx. 1 root root 12 Dec 29 04:38 /dev/mapper/oradisk01 -> ../oradisk01
--sdc1重新消失
[root@localhost ~]# ls -l /dev/sdc1
ls: cannot access /dev/sdc1: No such file or directory

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,因此还有其它更复杂的操作,不在这里描述。

SoftCon 2011 – My Presentation

今天上午为2011中国软件技术大会作的演讲,题目是《VLDB Statistics Gathering Strategy – Something You Need to Know But Maybe You Don’t》

内容实际上是分为两个部分:
1. 我认为理想的数据库表直方图信息收集的策略,这在我之前的文章-Oracle Histogram Investigation也有所描述。
2. 在使用granularity参数进行分区表统计信息收集的时候,有一些需要注意的问题,产生聚合统计信息是高效的方法,但是聚合统计信息在某些场景下却并不会如你所愿的生成。

OTN China Tour 2011

OTN China Tour

OTN Tour是每年一度的全球巡回演讲主题活动,而今年是第一次走进中国,ACOUG是这次活动在国内的组织者,也得到了ITPUB,IT168以及OTN中国的大力支持,这次活动在国内我们称之为Oracle技术嘉年华,将会集结数十位国内外Oracle技术专家,在两天时间内分享交流Oracle、MySQL、Java等方面的技术知识。

从7月份开始筹划,短短三个月时间,到10月份能够如期举办,我只能说这是一个奇迹。这绝对是一次高水准的技术分享盛会,相信参会人员都会从中有所收获。不管你信不信的,反正我信了。 😀

作为一个对于数据库很关心的从业者,下面这些演讲是我个人非常期待的。

Clonedb: The quick and easy cloning solution you never knew you had – Tim Hall
应该很多人都知道www.oracle-base.com网站,这个网站上有大量详尽的Oracle新功能评测,更新及时,信息量非常大,曾经一度是我探索Oracle数据库新功能必去浏览的网站之一,而Tim Hall正是该网站的主人,他同时也是Oracle ACE Director,还是OrkTable Network的成员。他的演讲绝对值得期待。

Virtualized Oracle 11g/R2 RAC Database on Oracle VM: Methods/Tips – Kai Yu
Oracle VM 3.0 – Patanjali Venkatacharya

虚拟化是现在的潮流,云技术也同样离不开虚拟化,而Oracle VM则是基于Xen技术的企业级虚拟化产品,特别是其对于Oracle数据库,中间件的完美支持更是成为其值得一试的理由。这两个主题一个偏重实战经验,一个是对最新版本的Oracle VM 3.0的介绍,偏重理论,正好相辅相成。

Exploiting Oracle tools & Utilities for Monitoring and Testing Oracle 11g RAC – Muralli Vallath
Muralli是印度Oracle用户组创办者,也是毋庸置疑的RAC专家,他对于Oracle 11g RAC的监控和测试的心得一定是值得我们学习的,中国现在的企业数据库似乎很少不上RAC,那么就更值得一听。

Oracle Security Tips : Some easy ways to make your DB more secure! – Francisco Munoz Alvarez
安全一直是企业级用户所关心的问题,但是说实话,在中国现在真正对于数据库安全做了实施的用户恐怕是少之又少,繁琐恐怕是其中的原因之一,那么如果有一些简单的方法就可以让数据库更加安全,听上去就很吸引人。

后oracle时代互联网企业数据产品技术—淘宝数据魔方技术架构 – 李金波(介然)
在当今这个言则电子商务的时代,商业数据分析恐怕是能够运筹帷幄、制胜千里的唯一方法。淘宝平台亿万数据是如何整合,如何分析,如何指导商业运作的,淘宝数据魔方的后台技术架构到底会有怎样的独特之处?

Some Oracle Database Questions

本文起源自dbsnake的《昨天我被问到的问题》

如果这几个问题是问到我,那么我怎么回答呢?

1. dedicated模式、非RAC、无连接池、要求支持2000个连接,在这样的条件下如何设置PGA?
根据应用程序特性的不同,SQL语句优化的程度,PGA的设置会相差很远。即使是知道专属连接方式,有2000个连接,恐怕我也无法再没有测试前就知道该设置多大的PGA。有一点默认的考虑,一个应用程序如果要支持2000个连接,那么通常不会是数据仓库系统,那么是OLTP系统的话,单个会话使用的PGA理应不需要很大。按照一般的经验值,给每个连接3M-5M,那么PGA的初始设置应该在6G-10G,然后跑测试,根据statspack或者awr report,再去判断是需要增加还是减少PGA。

2. 如何解决ORA-04031问题?
ORA-04031:unable to allocate string bytes of shared memory (“string”,”string”,”string”,”string”)
通常表示Shared Pool不足,一种情况是确实设置过小,另外一种情况是共享池碎片太多,没有足够的连续空间来放置一个稍大的空间请求,前一种情况就是增大共享池,大概到2G如果还报4031错误,那么应该是后一种情况了,而后一种情况则很可能是由于绑定变量不足导致过多的SQL Cursor存在,优化应用程序吧。再有那就可能是Oracle Database的bug了,那就五花八门不一而足了。

3. Current online redo log被删掉或者损坏后如何恢复?
当前联机日志损坏或者被删除,那么通常意味着必然会有数据损失,如果有备份,那么做full database restore,然后做不完全恢复,open resetlogs启动数据库。如果没有备份,那么利用_allow_resetlogs_corruption的隐含参数强制open数据库,做全库export,然后重建新库,做import。

4. oracle里的补丁具体分为哪几种类型?
我所知道的包括:大的Patchset,比如10.2.0.4的Patchset;Oneoff patch,修补某个bug或者某些bug的小Patch;Bundle Patch,一个时间段之后,发布的对于某一产品的集合Patch,修补一堆问题;CPU,也就是安全性Patch。dbsnake列出的其它那些,都不知道了。
其实,我的意思是这个问题有意义吗?

dbsnake – cuihua是这几年里我见到的对于Oracle数据库Internal研究最富有热情的朋友,在他的blog中有大量对于Oracle数据库内部机制的研究,比如类似于上面的第三个问题,哪怕是最棘手的数据库恢复,我相信dbsnake也是可以完成的。

Abnormal result by “show sga” command in 11g

一个有趣的现象。在11.1.0.6版本的数据库中show sga的显示结果并不正确。

KAMUS@orcl11g> select * from v$version;

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production

Elapsed: 00:00:00.06
KAMUS@orcl11g> show sga

Total System Global Area  380817408 bytes
Fixed Size                  1333340 bytes
Variable Size             289408932 bytes
Database Buffers           83886080 bytes
Redo Buffers                6189056 bytes
KAMUS@orcl11g> show parameter memory_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_target                        big integer 364M
KAMUS@orcl11g> select sum(bytes) from v$sgastat;

SUM(BYTES)
----------
 271768244

Elapsed: 00:00:00.03
KAMUS@orcl11g> select value from v$pgastat where name='total PGA allocated';

     VALUE
----------
  80623616

Elapsed: 00:00:00.01
KAMUS@orcl11g> select 380817408/1024/1024 from dual;

380817408/1024/1024
-------------------
         363.175781

Elapsed: 00:00:00.01

在show sga命令中显示Total System Global Area大小实际上是所有Memory的大小,包括了SGA+PGA,也就是memory_target参数的值。

将11g的新参数memory_target禁用,单独设置SGA和PGA,再看一下。

SYS@orcl11g> alter system set memory_target=0 scope=spfile;

System altered.
SYS@orcl11g> alter system set sga_target=271768244 scope=spfile;

System altered.
SYS@orcl11g> alter system set pga_aggregate_target=113246208 scope=spfile;

System altered.

修改完毕以后,重新启动数据库实例。再次用show sga命令显示SGA大小。

KAMUS@orcl11g> show sga

Total System Global Area  272011264 bytes
Fixed Size                  1332612 bytes
Variable Size             180357756 bytes
Database Buffers           88080384 bytes
Redo Buffers                2240512 bytes
KAMUS@orcl11g> select sum(bytes) from v$sgastat;

SUM(BYTES)
----------
 272013276

Elapsed: 00:00:00.10

这次show sga的显示结果正确了(有一些细微的误差,可以忽略不计)。