昨晚协助客户完成了一个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--
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/23135684/viewspace-765876/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/23135684/viewspace-765876/