ORACLE 12C 控制文件异常恢复

在oracle 12c引进了pdb的概念,但重建控制文件的过程还是完全和no-cdb(以前版本ORACLE)相同
数据库启动异常

idle> startup
ORACLE instance started.

Total System Global Area  521936896 bytes
Fixed Size                  2404552 bytes
Variable Size             205524792 bytes
Database Buffers          306184192 bytes
Redo Buffers                7823360 bytes
ORA-00205: error in identifying control file, check alert log for more info


idle> select * from v$version;

BANNER                                                                               CON_ID
-------------------------------------------------------------------------------- ----------
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production              0
PL/SQL Release 12.1.0.1.0 - Production                                                    0
CORE    12.1.0.1.0      Production                                                        0
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production                                   0
NLSRTL Version 12.1.0.1.0 - Production                                                    0

alert日志信息

Wed Mar 19 20:30:20 2014
ALTER DATABASE   MOUNT
Wed Mar 19 20:30:20 2014
ORA-00210: ???????????
ORA-00202: ????: ''E:\APP\XIFENFEI\ORADATA\CDB\CONTROL01.CTL''
ORA-27048: skgfifi: ????????
OSD-04001: 逻辑块大小无效
ORA-205 signalled during: ALTER DATABASE   MOUNT...

利用strings命令找出来数据文件和联机日志路径

E:\APP\XIFENFEI\ORADATA\CDB\REDO04.LOG
E:\APP\XIFENFEI\ORADATA\CDB\REDO06.LOG
E:\APP\XIFENFEI\ORADATA\CDB\REDO05.LOG
E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\USERS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\UNDOTBS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\TEMP01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\TEMP01.DBF

如果有完整的alert日志也可以通过alert日志来分析数据文件路径和redo路径;
通过alert日志分析数据库编码,如果没有alert日志通过分析prop$分析编码;
redo group 可以在alert日志中查看,写入错误,在创建时候会提示正确值;
redo size 可以查看redo file,也可以先写入错误值,创建时候会提示正确block数量

重建控制文件

idle> CREATE CONTROLFILE REUSE DATABASE "CDB" NORESETLOGS FORCE LOGGING ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 2921
  7  LOGFILE
  8  GROUP 4 'E:\APP\XIFENFEI\ORADATA\CDB\REDO04.LOG' size 50M,
  9  GROUP 6 'E:\APP\XIFENFEI\ORADATA\CDB\REDO06.LOG'  size 50M,
 10  GROUP 5 'E:\APP\XIFENFEI\ORADATA\CDB\REDO05.LOG'  size 50M
 11  DATAFILE
 12  'E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF',
 13  'E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSAUX01.DBF',
 14  'E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF',
 15  'E:\APP\XIFENFEI\ORADATA\CDB\UNDOTBS01.DBF',
 16  'E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSAUX01.DBF',
 17  'E:\APP\XIFENFEI\ORADATA\CDB\SYSAUX01.DBF',
 18  'E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSTEM01.DBF',
 19  'E:\APP\XIFENFEI\ORADATA\CDB\SYSTEM01.DBF',
 20  'E:\APP\XIFENFEI\ORADATA\CDB\USERS01.DBF'
 21  CHARACTER SET ZHS16GBK
 22  ;

控制文件已创建。

idle> recover database;
完成介质恢复。
idle> alter database open;

数据库已更改。

idle> show pdbs;

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB                            MOUNTED
idle> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
E:\APP\XIFENFEI\ORADATA\CDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDBSEED\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\USERS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSTEM01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\SYSAUX01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\PDB\PDB_USERS01.DBF
E:\APP\XIFENFEI\ORADATA\CDB\UNDOTBS01.DBF

已选择 9 行。

CDB_CDB$ROOT@SYS> alter session set container=pdb;

Session altered.

CDB_CDB$ROOT@SYS> alter database open;

Database altered.

数据库在mount状态重建控制文件请参考:重建控制文件

发表在 ORACLE 12C, Oracle备份恢复 | 标签为 , , | 评论关闭

推荐Exadata相关Blog网站

周末无意中发现朋友的网站上多了很多关于Exadata的资料,转载一些Exadata各个版本的硬件配置,以便不时之需.
Exadata X4-2 满配的硬件配置(Full Rack,高容量)
Exadata X4-2 满配的硬件配置(Full Rack,高性能)
Exadata X4-2 二分之一配的硬件配置(1/2 Rack,高性能)
Exadata X4-2 二分之一配的硬件配置(1/2 Rack,高容量)
Exadata X4-2 四分之一配的硬件配置(1/4 Rack,高性能)
Exadata X4-2 四分之一配的硬件配置(1/4 Rack,高容量)
Exadata X4-2 八分之一配的硬件配置(1/8 Rack,高性能)
Exadata X4-2 八分之一配的硬件配置(1/8 Rack,高容量)
Exadata X3-2 满配的硬件配置(Full Rack,高容量)
Exadata X3-2 满配的硬件配置(Full Rack,高性能)
Exadata X3-2 二分之一配的硬件配置(1/2 Rack,高容量)
Exadata X3-2 二分之一配的硬件配置(1/2 Rack,高性能)
Exadata X3-2 四分之一配的硬件配置(1/4 Rack,高容量)
Exadata X3-2 四分之一配的硬件配置(1/4 Rack,高性能)
Exadata X3-2 八分之一配的硬件配置(1/8 Rack,高容量)
Exadata X3-2 八分之一配的硬件配置(1/8 Rack,高性能)
Exadata X2-2 满配的硬件配置(Full Rack,高容量)
Exadata X2-2 满配的硬件配置(Full Rack,高性能)
Exadata X2-2 二分之一配的硬件配置(1/2 Rack,高容量)
Exadata X2-2 二分之一配的硬件配置(1/2 Rack,高性能)
Exadata X2-2 四分之一配的硬件配置(1/4 Rack,高容量)
Exadata X2-2 四分之一配的硬件配置(1/4 Rack,高性能)
Exadata V2 满配的硬件配置(Full Rack,高容量)
Exadata V2 满配的硬件配置(Full Rack,高性能)
Exadata V2 二分之一配的硬件配置(1/2 Rack,高容量)
Exadata V2 二分之一配的硬件配置(1/2 Rack,高性能)
Exadata V2 四分之一配的硬件配置(1/4 Rack,高容量)
Exadata V2 四分之一配的硬件配置(1/4 Rack,高性能)
Exadata V1 满配的硬件配置(Full Rack,高容量)
Exadata V1 满配的硬件配置(Full Rack,高性能)
Exadata V1 二分之一配的硬件配置(1/2 Rack,高容量)
Exadata V1 二分之一配的硬件配置(1/2 Rack,高性能)
Exadata V1 四分之一配的硬件配置(1/4 Rack,高容量)
Exadata V1 四分之一配的硬件配置(1/4 Rack,高性能)
推荐Lunar的oracle实验室—国内少有的xd相关Blog

发表在 EXADATA | 评论关闭

解决imp导入数据报IMP-00098错误

晚上十点多,准备睡觉了,一个朋友在qq上找到我,说他们数据库imp异常,希望我帮忙看看
大概情况
使用exp/imp升级并迁移数据库从win 10.2.0.1 升级到linux 11.2.0.3 由于硬盘空间不够,使用exp把win上面数据导出来,格式化掉win的数据文件所在硬盘格式化并加入到linux系统中(也就是说,故障之时,只有dmp文件,没有了数据文件),因为原库没有了,dmp又报错,所以担心了起来.
imp报错信息

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Tes

Export file created by EXPORT:V10.02.01 via conventional path
import done in ZHS16GBK character set and AL16UTF16 NCHAR character set
export client uses US7ASCII character set (possible charset conversion)
. . importing table                "ART_T_ARCTYPE"          0 rows imported
. . importing table                "ART_T_ARTICLE"          0 rows imported
……
. . importing table            "EVT_T_ACCEPT_CODE"          1 rows imported
. . importing table            "EVT_T_ACCEPT_FLOW"
 illegal lob length marker 51166
 bytesread = 00000000000
 TABLE =EVT_T_ACCEPT_FLOW   EVT_T_ACCEPT_FLOW
IMP-00098: INTERNAL ERROR: impgst2
IMP-00028: partial import of previous table rolled back: 680071 rows rolled back
IMP-00008: unrecognized statement in the export file:
  ??????????????????
IMP-00008: unrecognized statement in the export file:
  .:
IMP-00008: unrecognized statement in the export file:
  $;
IMP-00008: unrecognized statement in the export file:
  ||$
…………

这里可以知道数据库exp的客户端是版本是10.2.0.1,使用编码是US7ASCII,但是导入的库编码是ZHS16GBK

exp日志信息

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses ZHS16GBK character set (possible charset conversion)

EXP-00091: Exporting questionable statistics.
. . exporting table              EVT_T_ACCEPT_FLOW    3470071 rows exported
. . exporting table             EVT_T_ACCEPT_FLOW1    2707606 rows exported
……
. exporting post-schema procedural objects and actions
. exporting statistics
Export terminated successfully with warnings.

这里我们可以知道数据库编码是ZHS16GBK,exp客户端编码为US7ASCII,因此到导出过程中发生了一次由ZHS16GBK到US7ASCII的编码转换

检查新库发现,其db编码为ZHS16GBK,新库的NLS设置为:nls_lang=AMERICAN_AMERICA.ZHS16GBK
整个导出流程是:db编码为ZHS16GBK的数据库被客户端编码为US7ASCII的exp导出,然后被编码为ZHS16GBK的imp导入到db编码为ZHS16GBK的数据库中

故障可能性定位
1.可能在从ZHS16GBK到US7ASCII的编码转换中发生数据异常,也就是说dmp文件本身异常(我们最不希望出现的结果)
2.由于数据库导出过场会发生编码转换(ZHS16GBK->US7ASCII),而导入过程未发生编码转换(ZHS16GBK->ZHS16GBK),从而出现异常

分析并解决
1. 使用dul扫描dmp文件发现汉字都能够识别,而且exp成功的记录条数在dul扫描中都完全正常恢复出来,证明dmp文件是正常的
2. 基于dmp文件正常,编码转换的过程,得出结论在该库的imp过程中设置nls_lang=AMERICAN_AMERICA.US7ASCII问题应该就可以正常解决.果不其然,设置了NLS_LANG之后imp导入数据OK

得出结论
1. 做升级,迁移尽快保留多一份数据,这次吓得不轻
2. exp/imp最好前后客户端编码一致,否则可能被转换晕
如果遭遇真的dmp损坏情况,类似:IMP-00098: INTERNAL ERROR: impgst2,可以联系我们,提供专业处理

发表在 逻辑备份/恢复 | 标签为 , | 2 条评论