AIX platform ORA-01115 ORA-01110 ORA-27067 failure recovery

Received a friend recovery request, Aix 5.3,oracle 10.2.0.1 Platform, database startup ORA-01115 ORA-01110 ORA-27067 error, database failed to open, through analysis, is due to 10201 of the bugs on Aix caused, Through the skills to circumvent, the perfect solution to the problem, data 0 lost
Database Error Alert Log
Mon Aug 10 13:25:22 2015
ALTER DATABASE MOUNT
Mon Aug 10 13:25:29 2015
Setting recovery target incarnation to 1
Mon Aug 10 13:25:29 2015
Successful mount of Redo thread 1 with Mount ID 432339141
Mon Aug 10 13:25:29 2015
Database mounted in Exclusive Mode
Completed:alter DATABASE MOUNT
Mon Aug 10 13:25:36 2015
ALTER DATABASE Open
Mon Aug 10 13:25:36 2015
Beginning crash recovery of 1 threads
Parallel recovery started with processes
Mon Aug 10 13:25:37 2015
Started Redo scan
Mon Aug 10 13:25:52 2015
Completed Redo Scan
7889582 redo blocks read, 75305 data blocks need
Mon Aug 10 13:25:53 2015
Errors in FILE/DC/ADMIN/DATACENT/BDUMP/DATACENT_P002_144124.TRC:
Ora-01115:io Error reading block from File 2 (Block # 40704)
Ora-01110:data file 2: '/DC/ORADATA/DATACENT/UNDOTBS01.DBF '
Ora-27067:size of I/o buffer is invalid
Additional Information:2
Additional information:1572864
Mon Aug 10 13:25:53 2015
Aborting crash recovery due to slave death, attempting serial crash
Mon Aug 10 13:25:53 2015
Beginning crash recovery of 1 threads
Mon Aug 10 13:25:53 2015
Started Redo scan
Mon Aug 10 13:26:09 2015
Completed Redo Scan
7889582 redo blocks read, 75305 data blocks need
Mon Aug 10 13:26:12 2015
Aborting crash recovery due to error 1115
Mon Aug 10 13:26:12 2015
Errors in FILE/DC/ADMIN/DATACENT/UDUMP/DATACENT_ORA_123384.TRC:
Ora-01115:io Error reading block from File 2 (Block # 39077)
Ora-01110:data file 2: '/DC/ORADATA/DATACENT/UNDOTBS01.DBF '
Ora-27067:size of I/o buffer is invalid
Additional Information:2
Additional information:1310720
ORA-1115 signalled during:alter database open ...
The previous two errors ORA-01115 ORA-01110 are familiar to us, and may be reported as such when a database startup encounters a bad block or IO error. But ORA-27067 is really rare, and from MoS, a lot of it is because the bugs at the time of the Rman backup may be causing the error.

dBV detect undo Bad block file
Dbverify:release 10.2.0.1.0-production on Mon Aug 10 23:18:15 2015

Copyright (c) 1982, 2003, Oracle and/or its affiliates. All rights reserved.

Dbverify-verification Starting:file =/dc/oradata/datacent/undotbs01.dbf

Dbverify-verification Complete

Total Pages examined:329600
Total Pages processed (Data): 0
Total Pages Failing (Data): 0
Total Pages processed (Index): 0
Total Pages Failing (Index): 0
Total Pages processed (other): 327504
Total Pages processed (SEG): 17
Total Pages Failing (Seg): 0
Total Pages empty:2096
Total Pages Marked corrupt:0
Total Pages influx:0
Total Pages encrypted:0
Highest block scn:1887888 (0.1887888)
As can be seen here, the undo file itself does not have logical and physical bad blocks, proving that the reason for the database exception may be due to the ora-27067:size of I/o buffer is invalid. According to the official documents ORA-01115 ORA-27067 DURING PARALLEL INSTANCE RECOVERY after INSTANCE, We can basically determine that it is most likely because 10.2.0.1 in the AIX platform's JFS2 system, because of a large number of transaction operations, suddenly abort out of the database (also may be power off), so that the database at the start of the instance recovery, and due to internal bugs, resulting in instance recovery can not succeed. Through our processing, the database is perfect to start, data 0 lost

Database Startup log
Mon Aug 10 16:34:14 2015
ALTER DATABASE Open
Mon Aug 10 16:34:14 2015
Beginning crash recovery of 1 threads
Parallel recovery started with processes
Mon Aug 10 16:34:14 2015
Started Redo scan
Mon Aug 10 16:34:27 2015
Completed Redo Scan
7889582 redo blocks read, 0 data blocks need recovery
Mon Aug 10 16:34:27 2015
Started Redo application at
Thread 1:logseq 664704, Block 1286922
Mon Aug 10 16:34:27 2015
Recovery of Online Redo log:thread 1 Group 4 Seq 664704 Reading Mem 0
mem# 0 errs 0:/dev/rredo04
Mon Aug 10 16:34:32 2015
Recovery of Online Redo log:thread 1 Group 5 Seq 664705 Reading Mem 0
mem# 0 errs 0:/dev/rredo05
Mon Aug 10 16:34:38 2015
Recovery of Online Redo log:thread 1 Group 6 Seq 664706 Reading Mem 0
mem# 0 errs 0:/dev/rredo06
Mon Aug 10 16:34:40 2015
Completed Redo Application
Mon Aug 10 16:34:40 2015
Completed Crash Recovery at
Thread 1:logseq 664706, Block 1017805, SCN 8554793334
0 data blocks read, 0 data blocks written, 7889582 redo blocks Read
Mon Aug 10 16:34:40 2015
Thread 1 advanced to log sequence 664707
Thread 1 opened at log sequence 664707
Current log# 1 seq# 664707 mem# 0:/dev/rredo01
Successful open of Redo thread 1
Mon Aug 10 16:34:40 2015
MTTR advisory is disabled because fast_start_mttr_target are not set
Mon Aug 10 16:34:40 2015
Smon:enabling Cache Recovery
Mon Aug 10 16:34:40 2015
Successfully onlined Undo tablespace 1.
Mon Aug 10 16:34:40 2015
smon:enabling TX Recovery
Mon Aug 10 16:34:41 2015
Database Characterset is zhs32gb18030
Replication_dependency_tracking turned off (no async multimaster replication found)
Warning:aq_tm_processes is set to 0. System operation might be adversely affected.
Mon Aug 10 16:34:41 2015
Smon:parallel Transaction Recovery tried
Mon Aug 10 16:34:42 2015
Db_recovery_file_dest_size of 2048 MB is 0.00% used. This is a
User-specified limit on the amount of spaces that'll be used by this
Database for recovery-related files, and does not reflect the amount of
Spaces available in the underlying filesystem or ASM DiskGroup.
Mon Aug 10 16:34:42 2015
Completed:alter Database Open