昨晚协助客户完成了一个Oracle数据库的恢复操作。恢复并没有太高深的东西，但其中一些细节还是在这里记录一下。
客户的环境是一台安装Linux 64位的HP DL380G7，没有接存储，直接将数据放在了本地磁盘上，数据库的版本是Oracle Database 10.2.0.1 for Linux x86_64bit。在Linux系统的日志中出现了大量ERROR I/O的错误，之后操作系统无法正常启动。
整个恢复过程经历了如下几步：
1).将Linux安装光盘插入服务器光驱，从光驱引导进入安装Linux的第一个界面，键入linux rescue<回车>，之后根据提示配置好网络，最终将进入Linux的救援模式。
2).执行fdisk -l查看磁盘，手动执行mount操作挂载原有的文件系统。
3).通过网络将所有的数据文件、控制文件、日志文件传送到另外的服务器。
4).在相同平台、相同版本的数据库环境手动创建参数文件，尝试启动传递过来的数据库文件。
起初数据库打开之后业务系统使用过程中，告警日志收到如下的信息：
Mon Jul 8 22:02:14 2013
Errors in file /u01/app/oracle/admin/oradb/bdump/oradb_j001_5259.trc:
ORA-01552: cannot use system rollback segment for non-system tablespace 'TEMP'
Mon Jul 8 22:02:51 2013
Errors in file /u01/app/oracle/admin/oradb/bdump/oradb_j001_5259.trc:
ORA-01552: cannot use system rollback segment for non-system tablespace 'TEMP'
Mon Jul 8 22:02:51 2013
Errors in file /u01/app/oracle/admin/oradb/bdump/oradb_j001_5259.trc:
ORA-01552: cannot use system rollback segment for non-system tablespace 'TEMP'
这是因为参数文件中未明确设定UNDO_MANAGEMENT='AUTO'，默认值是MANUAL，另外，process未明确设定时候的默认值是40，通常这也是不够用的。
这是因为参数文件中未明确设定UNDO_MANAGEMENT='AUTO'，默认值是MANUAL，另外，process未明确设定时候的默认值是40，通常这也是不够用的。
手动配置参数文件的参数值推荐包含以下内容：
audit_file_dest='/u01/app/oracle/admin/oradb/adump'
background_dump_dest='/u01/app/oracle/admin/oradb/bdump'
compatible='10.2.0.1.0'
control_files='/u01/mocha/control01.ctl','/u01/mocha/control02.ctl','/u01/mocha/control03.ctl'
core_dump_dest='/u01/app/oracle/admin/oradb/cdump'
db_name='oradb'
db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'
db_recovery_file_dest_size=2147483648
job_queue_processes=10
processes=200
sga_max_size=2g
sga_target=2g
UNDO_MANAGEMENT='AUTO'
user_dump_dest='/u01/app/oracle/admin/oradb/udump'
数据库丢失了一个数据文件，在MOUNT模式将其OFFLINE DROP（非归档模式），之后数据库顺利打开，确定数据没问题后执行exp将其导出，恢复到其他活动的数据库。
--end--