某运营商网管故障报告(2013年写的)

最新推荐文章于 2023-05-05 11:28:23 发布

cuixiaohui5019

最新推荐文章于 2023-05-05 11:28:23 发布

阅读量545

点赞数

文章标签：数据库 5g 操作系统

1. 故障现象：

[BEGIN] 2013/2/2 6:16:26

-ef |grep ora_

root 28668 28621 0 06:11:47 pts/7 0:00 grep ora_

2013/2/2号(星期六早上6点左右) 远程登录进去发现已经没有oracle进程了

oracle 日志报错信息：

Creating archive destination LOG_ARCHIVE_DEST_1: '/archlog/archlog/cqdb_T0001S0000740433.ORA'

ARC2: Completed archiving log 4 thread 1 sequence 740433

Sat Feb 2 01:07:06 2013

KCF: write/open error block=0x1e56a online=1

file=266 /usr5/linkdata/newdata/data58.dbf

error=27063 txt: 'SVR4 Error: 5: I/O error

Sat Feb 2 01:07:06 2013

KCF: write/open error block=0x28c7 online=1

Sat Feb 2 01:07:06 2013

KCF: write/open error block=0x1895 online=1

Sat Feb 2 01:07:06 2013

KCF: write/open error block=0x7ede online=1

Additional information: -1

file=399 /usr5/linkdata/newdata/data192.dbf

file=289 /usr5/linkdata/newdata/data81.dbf

Sat Feb 2 01:07:06 2013

KCF: write/open error block=0x1c042 online=1

file=233 /usr5/linkdata/newdata/data25.dbf

Additional information: 8192'

error=27063 txt: 'SVR4 Error: 5: I/O error

file=289 /usr5/linkdata/newdata/data81.dbf

error=27063 txt: 'SVR4 Error: 5: I/O error

Additional information: -1

Sat Feb 2 01:07:06 2013

KCF: write/open error block=0x1c03f online=1

error=27063 txt: 'SVR4 Error: 5: I/O error

Additional information: -1

Additional information: 8192'

file=289 /usr5/linkdata/newdata/data81.dbf

Additional information: -1

Additional information: 8192'

error=27063 txt: 'SVR4 Error: 5: I/O error

Additional information: 8192'

Additional information: -1

Additional information: 8192'

Sat Feb 2 01:07:06 2013

Additional information: -1

Additional information: 8192

Sat Feb 2 01:07:06 2013

………………………..

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_ckpt_17756.trc:

ORA-01171: datafile 246 going offline due to error advancing checkpoint

ORA-01110: data file 246: '/usr5/linkdata/newdata/data38.dbf'

ORA-01115: IO error reading block from file 246 (block # 1)

ORA-27063: skgfospo: number of bytes read/written is incorrect

SVR4 Error: 5: I/O error

Additional information: -1

Additional information: 8192

Sat Feb 2 01:07:06 2013

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_ckpt_17756.trc:

ORA-01171: datafile 247 going offline due to error advancing checkpoint

ORA-01110: data file 247: '/usr5/linkdata/newdata/data40.dbf'

ORA-01115: IO error reading block from file 247 (block # 1)

ORA-27063: skgfospo: number of bytes read/written is incorrect

SVR4 Error: 5: I/O error

Additional information: -1

Additional information: 8192

Sat Feb 2 01:07:06 2013

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_ckpt_17756.trc:

ORA-01171: datafile 248 going offline due to error advancing checkpoint

ORA-01110: data file 248: '/usr5/linkdata/newdata/data41.dbf'

ORA-01115: IO error reading block from file 248 (block # 1)

ORA-27063: skgfospo: number of bytes read/written is incorrect

SVR4 Error: 5: I/O error

Additional information: -1

Additional information: 8192

Sat Feb 2 01:07:06 2013

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_ckpt_17756.trc:

ORA-01171: datafile 249 going offline due to error advancing checkpoint

ORA-01110: data file 249: '/usr5/linkdata/newdata/data42.dbf'

ORA-01115: IO error reading block from file 249 (block # 1)

ORA-27063: skgfospo: number of bytes read/written is incorre

alert日志里报告大量IO错误,查看操作系统发现user5下面已经没有linkdata目录了

cqdb% cd /usr5/linkdata/newdata

/usr5/linkdata/newdata: No such file or directory

cqdb% cd /usr5

cqdb% ls

linkdata_20050914.old

cqdb% pwd

/usr5

cqdb% ls

linkdata_20050914.old

1. 故障处理步骤：

1:在2013/2/2 早上7左右赶到8楼,主机工程师确认是文件系统出了问题,经过了重启等一系列文件修复动作,在上午10点左右确认/user5下面的文件系统恢复了(经过后面的确认,这个时候/archlog归档目录也出现了损坏,但没有检查出)

2:这时启动数据库报告如下错误

SQL> startup
ORACLE 例程已经启动。
Total System Global Area 4550795736 bytes
Fixed Size                   737752 bytes
Variable Size            1291845632 bytes
Database Buffers         3254779904 bytes
Redo Buffers                3432448 bytes
数据库装载完毕。
ORA-01122: 数据库文件 1 验证失败
ORA-01110: 数据文件 1: '/usr5/linkdata/sys/system_ln10_1.dbf'
ORA-01207: 文件比控制文件更新 - 旧的控制文件

备注:

1:我刚开始是产生的trace文件,而后去重新创建控制文件,因为里面有空行,搞了半天没有创建成功,正在找原因,应用提示丢了数据文件,应该有400多个的,而这里产生的才247个,不解!!!

alter database backup controlfile to trace as '/opt/app/oracle/admin/cqdb/control.ctl';

2:什么情况下会导致上面的情况发生？如果真是创建的控制文件里少了数据文件，还能重新加入进去吗?

3:如果重建的控制文件文本里有空行会如下错误

SQL> SP2-0734: 未知的命令开头 "'/usr5/lin..." - 忽略了剩余的行。

3:文件系统异常,主机强制关机等操作导致了控制文件跟数据文件不一致,需要重新创建控制文件

cqdb% rman target /

恢复管理器: 版本9.2.0.6.0 - 64bit Production

连接到目标数据库: cqdb（未安装）

RMAN> connect catalog rman/rman@legato;

连接到恢复目录数据库

RMAN> restore controlfile from '/opt/app/oracle/product/9.2.0.1/dbs/auto_bak_controlfile/c-1685697677-20130201-00';

启动 restore 于 2013-02-02 09:37:52

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=21 devtype=DISK

通道 ORA_DISK_1: 正在恢复控制文件

通道 ORA_DISK_1: 恢复完成

正在复制控制文件

输出文件名=/usr5/linkdata/sys/control_ln.1_1.ctl

输出文件名=/usr5/linkdata/sys/control_ln.1_2.ctl

输出文件名=/usr5/linkdata/sys/control_ln.1_3.ctl

完成 restore 于 2013-02-02 09:38:03

RMAN> exit

4: 利用从集中备份恢复的控制文件开始恢复启动数据库

cqdb% set LANG=en

SQL> alter database mount;

cqdb% sqlplus "/as sysdba"

SQL*Plus: Release 9.2.0.6.0 - Production on 星期六 2月 2 09:52:41 2013

连接到:

Oracle9i Enterprise Edition Release 9.2.0.6.0 - 64bit Production

With the Partitioning, OLAP and Oracle Data Mining options

JServer Release 9.2.0.6.0 - Production

SQL> recover database using backup controlfile until cancel;

ORA-00279: 更改 20497614742 (在 08/04/2010 00:16:28 生成) 对于线程 1 是必需的

ORA-00289: 建议: /archlog/archlog/cqdb_T0001S0000331740.ORA

ORA-00280: 更改 20497614742 对于线程 1 是按序列 # 331740 进行的

?---归档目录根本都找不到cqdb_T0001S0000331740.ORA

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

/usr5/linkdata/sys/redob2_ln.1_1.log ?指定当前联机日志文件来恢复

ORA-00310: 存档日志包含序列 331739；要求序列 331740

ORA-00334: 归档日志: '/usr5/linkdata/sys/redob2_ln.1_1.log'

ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误

ORA-01194: 文件1需要更多的恢复来保持一致性 <---这里提示system需要更多的日志文件来恢复

ORA-01110: 数据文件 1: '/usr5/linkdata/sys/system_ln10_1.dbf'

ORA-01112: 未启动介质恢复

查看当前联机日志

SQL> select * from v$logfile;

GROUP# STATUS TYPE

---------- -------------- --------------

MEMBER

--------------------------------------------------------------------------------

1 ONLINE

/usr5/linkdata/sys/redoa1_ln.1_1.log

1 ONLINE

/usr5/linkdata/sys/redob1_ln.1_1.log

2 ONLINE

/usr5/linkdata/sys/redoa2_ln.1_1.log

GROUP# STATUS TYPE

---------- -------------- --------------

MEMBER

--------------------------------------------------------------------------------

2 ONLINE

/usr5/linkdata/sys/redob2_ln.1_1.log

3 ONLINE

/usr5/linkdata/sys/redoa3_ln.1_1.log

3 ONLINE

/usr5/linkdata/sys/redob3_ln.1_1.log

GROUP# STATUS TYPE

---------- -------------- --------------

MEMBER

--------------------------------------------------------------------------------

4 ONLINE

/usr5/linkdata/sys/redoa4_ln.1_1.log

4 ONLINE

/usr5/linkdata/sys/redob4_ln.1_1.log

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIV

---------- ---------- ---------- ---------- ---------- ------

STATUS FIRST_CHANGE# FIRST_TIME

-------------------------------- ------------- -------------------

1 1 740202 104857600 2 YES

INACTIVE 2.6179E+10 2013-02-01 17:48:40

2 1 740203 104857600 2 YES

ACTIVE 2.6179E+10 2013-02-01 18:04:08

3 1 740204 104857600 2 NO

CURRENT 2.6179E+10 2013-02-01 18:07:31

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIV

---------- ---------- ---------- ---------- ---------- ------

STATUS FIRST_CHANGE# FIRST_TIME

-------------------------------- ------------- -------------------

4 1 740201 104857600 2 YES

INACTIVE

这时查看归档目录是否有恢复需要的归档日志文件

cqdb% cd /archlog/archlog

cqdb% ls -l

./cqdb_T0001S0000740399.ORA: I/O error ?-----归档目录有报告IO错误,归档日志根本无法读取

./cqdb_T0001S0000740400.ORA: I/O error

./cqdb_T0001S0000740398.ORA: I/O error

total 30534272

-rw-r----- 1 oracle dba 104857088 Feb 1 21:10 cqdb_T0001S0000331734.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 21:11 cqdb_T0001S0000331735.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 21:12 cqdb_T0001S0000331736.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 21:14 cqdb_T0001S0000331737.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 21:21 cqdb_T0001S0000331738.ORA

-rw-r----- 1 oracle dba 104857088 Aug 4 2010 cqdb_T0001S0000331739.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 18:58 cqdb_T0001S0000740255.ORA

-rw-r----- 1 oracle dba 104857088 Aug 3 2010 cqdb_T0001S0000740257.ORA

-rw-r----- 1 oracle dba 104857088 Aug 3 2010 cqdb_T0001S0000740258.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 19:02 cqdb_T0001S0000740259.ORA

-rw-r----- 1 oracle dba 104857088 Feb 1 19:03 cqdb_T0001S0000740260.ORA

……………………..

当系统工程师对/archlog/archlog做了目录修复后, /archlog/archlog目录下的很多归档日志都丢失了,要想通过这些不连续的归档日志来恢复启动数据库已经不可能了

5:查看当前各个文件的checkpoint值

SQL> col checkpoint_change# format 9999999999999999999999999

SQL> select file#,checkpoint_change# from v$datafile_header;

1 26181013653

2 26181013653

3 20497614742

4 20497614742

……………………….

99 20497614742

100 20497614742

101 26181053757

102 26181053757

………………………………………

227 26181053757

228 26181053757

229 26181053757

230 20497614742

231 20497614742

232 20497614742

233 20497614742

……………………………………………

241 20497614742

242 26181053757

243 26181013653

……………………………………….

300 26181013653

301 20497614742

302 20497614742

………………………………………

319 20497614742

320 20497614742

321 26181013653

………………………………

449 26181013653

450 26181013653

451 26181013653

452 26181013653

453 26181013653

454 26181013653

已选择454行。

?----共454条数据文件记录,但其checkpoint_change#出现了很多不一致现象,此时的数据库是根本无法正常打开的

而恢复所需要的日志文件已经被文件系统修复丢失了部分,不连续的日志文件无法保证数据库能到open状态.

6:把当前情况汇报给华胜二线专家组，同时联系了原厂Oracle工程师,一致确认当前数据库已经无法正常打开了。

建议在先保留现场的情况下,而后利用备份恢复

7:考虑到而系统占用空间大(800G)左右,根本没有足够的空间来保留现场,避免更严重的损坏,同时rman集中备份的文件也重来没有恢复过,不能保证一定能够成功从备份系统恢复回来.

没有任何回退方案,此时也不能贸然决定用集中备份恢复,而且这种恢复会耗费很长时间.

8:连接到catalog查看集中备份的备份时间,以确定是否可以恢复数据库,以及能推进的最近归档时间

cqdb% rman target /

恢复管理器: 版本9.2.0.6.0 - 64bit Production

连接到目标数据库: CQDB (DBID=1685697677)

RMAN> connect catalog rman/rman@legato;

连接到恢复目录数据库

RMAN> list backup of database;

………………………

BS 关键字类型 LV 大小设备类型经过时间完成时间

------- ---- -- ---------- ----------- ------------ -------------------

2192881 Full 5G SBT_TAPE 00:04:08 2013-01-27 06:47:44 ?--显示最近一次全库备份时间是1月27

BP 关键字: 2193006 状态: AVAILABLE 标记:TAG20130127T040147

段名:/full_CQDB_nvo0eoso/

备份集 2192881 中的数据文件列表

文件 LV 类型 Ckp SCN Ckp 时间名称

---- -- ---- ---------- ------------------- ----

191 Full 26136929293 2013-01-27 06:43:37 /usr5/linkdata/user/c_perf_partition1.5_32.dbf

192 Full 26136929293 2013-01-27 06:43:37 /usr5/linkdata/user/c_perf_partition1.5_33.dbf

193 Full 26136929293 2013-01-27 06:43:37 /usr5/linkdata/user/c_perf_partition1.5_34.dbf

194 Full 26136929293 2013-01-27 06:43:37 /usr5/linkdata/user/c_perf_partition1.5_35.dbf

RMAN> list backup of archivelog all;

?-显示最近一次归档备份是1月31号

也就是说如果采用集中备份恢复，在一切正常的情况下可以推到2013年1月31号的数据

9:决定先采用非常规方法强制打开数据库,让应用厂商把相关重要数据及表结构做逻辑备份,防止万一集中备份恢复失败还有方案可走

10: 采用了如下一系列的隐含参数文件来强制启动数据库,加了event,跳过不一致检查来试图打开数据库

*._allow_resetlogs_corruption =true

*._minimum_giga_scn=11649

*.undo_managment=manual

*._CORRUPTED_ROLLBACK_SEGMENTS=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$,_SYSSMU11$,_SYSSMU12$,_SYSSMU13$,_SYSSMU14$,_SYSSMU15$,_SYSSMU16$,_SYSSMU17$,_SYSSMU18$,_SYSSMU19$,_SYSSMU20$)

11:强制打开的数据库报告了很多内部错误,这个在预料之中,赶紧让开发人员把重要表和数据做Exp逻辑备份

?-下午3点左右数据库可以打开

errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_smon_11419.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

Sat Feb 2 15:17:44 2013

Errors in file /opt/app/oracle/admin/cqdb/udump/cqdb_ora_11439.trc:

ORA-00600: 内部错误代码，参数: [4193], [4274], [4300], [], [], [], [], []

Sat Feb 2 15:17:45 2013

ORACLE Instance cqdb (pid = 11) - Error 600 encountered while recovering transaction (11, 27).

Sat Feb 2 15:17:45 2013

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_smon_11419.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

Sat Feb 2 15:17:46 2013

Doing block recovery for fno: 2 blk: 1137288

Sat Feb 2 15:17:46 2013

Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0

Mem# 0 errs 0: /usr5/linkdata/sys/redoa1_ln.1_1.log

Mem# 1 errs 0: /usr5/linkdata/sys/redob1_ln.1_1.log

Doing block recovery for fno: 2 blk: 9

Sat Feb 2 15:17:46 2013

Recovery of Online Redo Log: Thread 1 Group 1 Seq 2 Reading mem 0

Mem# 0 errs 0: /usr5/linkdata/sys/redoa1_ln.1_1.log

Mem# 1 errs 0: /usr5/linkdata/sys/redob1_ln.1_1.log

Sat Feb 2 15:17:46 2013

Errors in file /opt/app/oracle/admin/cqdb/udump/cqdb_ora_11439.trc:

ORA-00607: 当更改数据块时出现内部错误

ORA-00600: 内部错误代码，参数: [4193], [4274], [4300], [], [], [], [], []

Error 607 happened during db open, shutting down database

USER: terminating instance due to error 607

Instance terminated by USER, pid = 11439

12:大概在晚上7点左右(2月2号), 开发人员把他们认为重要的表及数据都导了出来,保存到本地,作为最后的回退恢复方案

这时去掉先前启用的隐含参数文件,再次启动数据库,此时的数据库是可以正常启动了的,有如下错误,ha双机软件观察业务都是可以正常运行的,考虑到该库强制打开过,已经处于不稳定状态,随时都可能报告不可预知的内部错误,而且已经逻辑备份了重要的业务数据,决定采用集中备份来进行全库恢复工作

ORA-00339: archived log does not contain any redo

ORA-00334: archived log: '/usr5/linkdata/sys/redoa4_ln.1_1.log'

Sat Feb 2 17:50:57 2013

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_smon_18702.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

Sat Feb 2 17:50:58 2013

ORACLE Instance cqdb (pid = 11) - Error 600 encountered while recovering transaction (11, 28).

Sat Feb 2 17:50:58 2013

Errors in file /opt/app/oracle/admin/cqdb/bdump/cqdb_smon_18702.trc:

ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []

13:经过商量决定,联系集中备份,大概在晚上8点作业开始了全库恢复工作,一直持续到2月3号下午5点左右才停止恢复，数据恢复推演到2013年1月28号早上2点左右.

14:在推演日志的时候,有如下两个数据文件一直提示需要恢复

SQL> select t.name,f.name from v$tablespace t,v$datafile f

where f.file# in (453,454)

and f.ts#=t.ts#;

C_PERF_PARTITION11 /usr5/linkdata/newdata/data247.dbf

PERF_DOCARRIERFREQ02 /usr5/linkdata/newdata/data246.dbf

跟业务人员确认说这两个文件是2月1号新添加的,不在全库备份恢复范围内,而恢复所采用的控制文件是20130201最新的控制文件,

执行了如下操作

alter database create datafile '/usr5/linkdata/newdata/data246.dbf';

alter database create datafile '/usr5/linkdata/newdata/data247.dbf';

alter database datafile '/usr5/linkdata/newdata/data246.dbf' offline drop;

alter database datafile '/usr5/linkdata/newdata/data247.dbf' offline drop;

SQL> col checkpoint_change# format 9999999999999999999999999

SQL> select file#,checkpoint_change# from v$datafile_header;

此时的所有数据文件checkpoint都处于了一直状态,但246和247对应的要小很多

alter database backup controlfile to trace as '/opt/app/oracle/admin/cqdb/control.ctl';

在导出的控制文件里去掉了最后的246和247数据文件重新建立进去

再次查询v$datafile的checkpoint_change#,没有发现了246和247

可以alter database open resetlogs;打开数据库了

打开以后发现246文件需要recover,后来证实这个文件是1月28号所建的,而最开始推日志的时候已经offline过,日志都没了,无法online的

SQL> select file_name,status from dba_data_files where file_name='/usr5/linkdata/newdata/data246.dbf';

/usr5/linkdata/newdata/data246.dbf

AVAILABLE

SQL> select file#,status from v$datafile where name ='/usr5/linkdata/newdata/data246.dbf';

FILE# STATUS

---------- -------

453 RECOVER

SQL> alter database create datafile '/opt/app/oracle/product/9.2.0.1/dbs/MISSING00453' as '/usr5/linkdata/newdata/data246.dbf';

alter database create datafile '/opt/app/oracle/product/9.2.0.1/dbs/MISSING00453' as '/usr5/linkdata/newdata/data246.dbf'

ERROR 位于第 1 行:

ORA-01178: 文件 453 在最后一个 CREATE CONTROLFILE 之前创建，无法重新创建

ORA-01111: 数据文件 453 名称未知 - 请重命名以更正文件

ORA-01110: 数据文件 453: '/opt/app/oracle/product/9.2.0.1/dbs/MISSING00453'

Mos: ID[333620.1]

The control file should have datafile created information.If the controlfile was re-created
after the datafile was created then the below solution will not work and step 2 will
error with ORA-01178

如果在创建文件之后重建了控制文件,再次创建就会报ORA-01178错误

SQL> alter database datafile '/opt/app/oracle/product/9.2.0.1/dbs/MISSING00453' offline;

数据库已更改。

SQL> alter database rename file '/opt/app/oracle/product/9.2.0.1/dbs/MISSING00453' to '/usr5/linkdata/newdata/data246.dbf';

数据库已更改。

SQL> alter database datafile '/usr5/linkdata/newdata/data246.dbf' online;

ERROR 位于第 1 行:

ORA-01190: 控制文件或数据文件453来自于最后一个 RESETLOGS 之前

ORA-01110: 数据文件 453: '/usr5/linkdata/newdata/data246.dbf'

无法online,就让他offline吧，但后面发现还是有问题,只要到这个文件的读写都无法进行

Mos:[ ID 1475632.1] once the controlfile is recreated with resetlogs all offlined datafiles cannot be added back to the database. You may encounter the following errors.

RMAN> sql 'alter database datafile 6 online';
sql statement: alter database datafile 6 online
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 07/29/2012 11:07:07
RMAN-11003: failure during parse/execution of SQL statement: alter database datafile 6 online
ORA-01190: control file or data file 6 is from before the last RESETLOGS
ORA-01110: data file 6: '/opt/app/oracle/oradata/ORA112/leng_ts.dbf'

15:数据库正常打开后(2月3号6点左右)又遭遇了一次主机的异常宕机,这次没有影响到数据库的正常启动.

业务开始补录数据

16:2月4号业务补录1月28到1月31号数据过程中遇到如下错误

select * from C_PERF.C_PERF_DOCARRIERFREQ partition (PERF_DO_FREQ130201) where start_time='2013-01-28 12:00:00'

直接报错:

ORA-00376:此时无法读取文件453

ORA-01110:数据文件453: '/usr5/linkdata/newdata/data246.dbf'

不解：该文件都已经offline了,为什么还要去读里面内容,写也写不进去(现在控制文件显示是offline,数据文件显示是recover)

经过再次跟业务确认，发现data246.dbf根本就不是2月1号所建,应该是1月28号早上9点左右建立的

此时该数据文件已经是offline状态,想recover已经是不可能了.因该文件对应一个分区的分区表空间,决定先导出数据，重建该表空间，再倒入进去

17: 导出数据

exp c_perf/cdmaperf0808@cqdb file=C_PERF_DOCARRIERFREQpartition201301.dmp tables=C_PERF_DOCARRIERFREQ:PERF_DO_FREQ130201 log=./log/exp_partition_201301.log query=\"where start_time\<\'2013-01-28\'\"

18: 删除分区 alter table C_PERF_DOCARRIERFREQ drop partition PERF_DO_FREQ130201;

19: 删除表空间 PERF_DOCARRIERFREQ02

drop tablespace PERF_DOCARRIERFREQ02 INCLUDING CONTENTS and DATAFILES;

20: 添加表空间

create tablespace PERF_DOCARRIERFREQ02 datafile '/usr5/linkdata/newdata/data145.dbf';

alter tablespace PERF_DOCARRIERFREQ02 add datafile '/usr5/linkdata/newdata/data157.dbf';

alter tablespace PERF_DOCARRIERFREQ02 add datafile '/usr5/linkdata/newdata/data246.dbf';

21: 分裂分区

ALTER TABLE C_PERF.C_PERF_DOCARRIERFREQ

SPLIT PARTITION PERF_DO_FREQ130301

AT (TO_DATE ('2013-02-01 00:00:00','YYYY-MM-DD HH24:MI:SS'))

INTO (partition PERF_DO_FREQ130201 tablespace PERF_DOCARRIERFREQ02, partition PERF_DO_FREQ130301);

22: imp导入数据

imp c_perf/cdmaperf0808@cqdb file='C_PERF_DOCARRIERFREQpartition201301.dmp' tables=C_PERF_DOCARRIERFREQ:PERF_DO_FREQ130201 ignore=y buffer=104857600 commit=yes feedback=100000 log=imp_DO_FREQ130201.log

23:到此为止,全部结束!

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/61604/viewspace-1757675/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/61604/viewspace-1757675/