Chinaunix首页 | 论坛 | 博客
  • 博客访问: 2833323
  • 博文数量: 599
  • 博客积分: 16398
  • 博客等级: 上将
  • 技术积分: 6875
  • 用 户 组: 普通用户
  • 注册时间: 2009-11-30 12:04
个人简介

WINDOWS下的程序员出身,偶尔也写一些linux平台下小程序, 后转行数据库行业,专注于ORACLE和DB2的运维和优化。 同时也是ios移动开发者。欢迎志同道合的朋友一起研究技术。 数据库技术交流群:58308065,23618606

文章分类

全部博文(599)

文章存档

2014年(12)

2013年(56)

2012年(199)

2011年(105)

2010年(128)

2009年(99)

分类: Oracle

2009-12-31 16:34:37

前一段时间解决了一个ORA-1122错误,正好本机的数据库环境由于Windows的自动重起,导致数据库无法打开,出现错误信息也是ORA-1122

这次出现错误的表空间是UNDO表空间。


首先看一下问题,尝试打开数据库,则会报错:

SQL> CONN /@TEST AS SYSDBA已连接到空闲例程。
SQL> STARTUP MOUNT
ORACLE
例程已经启动。

Total System Global Area 76619308 bytes
Fixed Size 454188 bytes
Variable Size 50331648 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes

数据库装载完毕。
SQL> ALTER DATABASE OPEN;
ALTER DATABASE OPEN
*
ERROR
位于第 1 :
ORA-01122:
数据库文件 2 验证失败

ORA-01110:
数据文件 2: 'F:ORACLE\ORADATA\TEST\UNDOTBS01.DBF'
ORA-01200: 25600
的实际文件大小小于26880块的正确大小

数据库是处于归档模式:

SQL> SELECT LOG_MODE FROM V$DATABASE;

LOG_MODE
------------
ARCHIVELOG

解决问题最简单的方法莫过于使用备份和归档日志进行数据库的恢复。由于是本机的测试数据库,因此没有设置备份策略,不过还是在本机找到一个一年前的数据库冷备份,而且发现数据库的所有归档都存在,那么使用归档恢复则是最方便、最稳妥的方法。

首先仍然是备份当前的环境,一方面是为了一会的恢复如果出现意外,至少可以恢复到没有操作前的状态,不会导致数据库的问题进一步复杂。另一方面是为了保留错误现场,这样在尝试正常方法恢复后还可以有环境来尝试一下其他的恢复方式。

备份完现场环境后,可以进行数据库的恢复:

SQL> HOST COPY F:\ORACLE\BACKUP\TEST\20061110\UNDOTBS01.DBF F:\ORACLE\ORADATA\TEST\UNDOTBS01.DBF

SQL> RECOVER TABLESPACE UNDOTBS1
ORA-00279:
更改 55747341 ( 11/11/2006 22:11:26 生成) 对于线程 1 是必需的
ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00306.001
ORA-00280:
更改 55747341 对于线程 1 是按序列 # 306 进行的

指定日志: {=suggested | filename | AUTO | CANCEL}

ORA-00279: 更改 55773423 ( 11/12/2006 08:34:23 生成) 对于线程 1 是必需的
ORA-00289:
建议: F\:ORACLE\ORADATA\TEST\ARCHIVE\ARC00307.001
ORA-00280:
更改 55773423 对于线程 1 是按序列 # 307 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00306.001'

指定日志: {=suggested | filename | AUTO | CANCEL}

ORA-00279: 更改 55793564 ( 11/12/2006 23:24:46 生成) 对于线程 1 是必需的
ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00308.001
ORA-00280:
更改 55793564 对于线程 1 是按序列 # 308 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACL\EORADATA\TEST\ARCHIVE\ARC00307.001'

指定日志: {=suggested | filename | AUTO | CANCEL}

ORA-00279: 更改 55793630 ( 11/12/2006 23:28:00 生成) 对于线程 1 是必需的
ORA-00289:
建议: F\:ORACLE\ORADATA\TEST\ARCHIVE\ARC00309.001
ORA-00280:
更改 55793630 对于线程 1 是按序列 # 309 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00308.001'

指定日志: {=suggested | filename | AUTO | CANCEL}
AUTO
ORA-00279:
更改 55793693 ( 11/12/2006 23:30:10 生成) 对于线程 1 是必需的

ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00310.001
ORA-00280:
更改 55793693 对于线程 1 是按序列 # 310 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00309.001'


ORA-00279:
更改 55815674 ( 11/13/2006 08:29:33 生成) 对于线程 1 是必需的
ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00311.001
ORA-00280:
更改 55815674 对于线程 1 是按序列 # 311 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00310.001'

.
.
.
ORA-00279:
更改 58975589 ( 05/13/2007 21:36:37 生成) 对于线程 1 是必需的
ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00444.001
ORA-00280:
更改 58975589 对于线程 1 是按序列 # 444 进行的

ORA-00278:
此恢复不再需要日志文件 'F\:ORACLE\ORADATA\TEST\ARCHIVE\ARC00443.001'


ORA-00279:
更改 58988027 ( 05/13/2007 21:38:39 生成) 对于线程 1 是必需的
ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00445.001
ORA-00280:
更改 58988027 对于线程 1 是按序列 # 445 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00444.001'


ORA-00279:
更改 59004640 ( 05/13/2007 21:40:16 生成) 对于线程 1 是必需的
ORA-00289:
建议: F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00446.001
ORA-00280:
更改 59004640 对于线程 1 是按序列 # 446 进行的

ORA-00278:
此恢复不再需要日志文件 'F:\ORACLE\ORADATA\TEST\ARCHIVE\ARC00445.001'

已应用的日志。完成介质恢复。
SQL> ALTER DATABASE OPEN;

数据库已更改。

SQL> SELECT COUNT(*) FROM YANGTK.T;

COUNT(*)
----------
636807

可以看到,虽然表空间的备份已经是1年多以前的,虽然需要恢复归档的日志有100多个,只要备份和归档都没有被损坏,数据库就可以轻松的恢复。

这种方法显然是最简单可靠的。

阅读(2043) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~