oracle控制文件報(bào)錯(cuò)corrupt block detected in control file

changsiheng

大家好我現(xiàn)在遇到了這樣一個(gè)問題，我這里有個(gè)oracle11g的數(shù)據(jù)庫，是一個(gè)通過shareplex同步的目標(biāo)庫


前段時(shí)間疏于管理，忘了查看目標(biāo)庫的狀態(tài)，發(fā)現(xiàn)archivelog 占用100%，之后又報(bào)出控制文件問題，直接關(guān)閉了數(shù)據(jù)庫，當(dāng)我startup的時(shí)候，就會(huì)提示數(shù)據(jù)庫的控制文件問題

控制文件有兩個(gè)，替換之后還是有問題，initorcl.ora 直接指向第二個(gè)控制文件也還是不行


alter database mount
*
ERROR at line 1:
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/app/oradata/zdfdb/control01.ctl'

一下為alert中的部分日志
Fri Jul 31 14:12:20 2015
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 4
Number of processor cores in the system is 4
Number of processor sockets in the system is 1
CELL communication is configured to use 0 interface(s):
CELL IP affinity details:
    NUMA status: non-NUMA system
    cellaffinity.ora status: N/A
CELL communication will use 1 IP group(s):
    Grp 0:
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =249
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /oracle/app/product/11.2.0/dbhome_1
System name:    Linux
Node name:      sp_server2
Release:        2.6.32-358.el6.x86_64
Version:        #1 SMP Fri Feb 22 00:31:26 UTC 2013
Machine:        x86_64
Using parameter settings in server-side pfile /oracle/app/product/11.2.0/dbhome_1/dbs/initorcl.ora
System parameters with non-default values:
  processes                = 1500
  sessions                 = 2272
  memory_target            = 16G
  control_files            = "/oracle/app/oradata/control01.ctl"
  control_files            = "/oracle/app/oradata/control02.ctl"
  db_block_size            = 8192
  compatible               = "11.2.0.0.0"
  db_recovery_file_dest    = "/oracle/app/flash_recovery_area"
  db_recovery_file_dest_size= 200G
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=zdfdbXDB)"
  audit_file_dest          = "/oracle/app/admin/adump"
  audit_trail              = "DB"
  db_name                  = "orcl"
  open_cursors             = 1000
  diagnostic_dest          = "/oracle/app"
Fri Jul 31 14:12:21 2015
PMON started with pid=2, OS id=46209
Fri Jul 31 14:12:21 2015
PSP0 started with pid=3, OS id=46211
Fri Jul 31 14:12:22 2015
VKTM started with pid=4, OS id=46213 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Fri Jul 31 14:12:22 2015
GEN0 started with pid=5, OS id=46217
Fri Jul 31 14:12:22 2015
DIAG started with pid=6, OS id=46219
Fri Jul 31 14:12:22 2015
DBRM started with pid=7, OS id=46221
Fri Jul 31 14:12:22 2015
DIA0 started with pid=8, OS id=46223
Fri Jul 31 14:12:22 2015
MMAN started with pid=9, OS id=46225
Fri Jul 31 14:12:22 2015
DBW0 started with pid=10, OS id=46227
Fri Jul 31 14:12:22 2015
LGWR started with pid=11, OS id=46229
Fri Jul 31 14:12:22 2015
CKPT started with pid=12, OS id=46231
Fri Jul 31 14:12:22 2015
SMON started with pid=13, OS id=46233
Fri Jul 31 14:12:22 2015
RECO started with pid=14, OS id=46235
Fri Jul 31 14:12:22 2015
MMON started with pid=15, OS id=46237
Fri Jul 31 14:12:22 2015
MMNL started with pid=16, OS id=46239
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /oracle/app
Fri Jul 31 14:12:22 2015
ALTER DATABASE   MOUNT
Errors in file /oracle/app/diag/rdbms/trace/zdfdb_ora_46244.trc:
ORA-00202: control file: '/oracle/app/oradata/zdfdb/control01.ctl'
Errors in file /oracle/app/diag/rdbms/trace/zdfdb_ora_46244.trc  (incident=288169):
ORA-00227: corrupt block detected in control file: (block 1, # blocks 1)
ORA-00202: control file: '/oracle/app/oradata/control01.ctl'
Incident details in: /oracle/app/incident/incdir_288169/zdfdb_ora_46244_i288169.trc
ORA-227 signalled during: ALTER DATABASE   MOUNT...
Dumping diagnostic data in directory=[cdmp_20150731141224], requested by (instance=1, osid=46244), summary=[incident=288169].


有什么辦法可以恢復(fù)嗎？還煩勞各位給一個(gè)思路，自己沒什么思路，DB方面的小學(xué)生

jackson198574

控制文件有備份嗎？是否有嘗試復(fù)制控制文件？

changsiheng

回復(fù) 2# jackson198574


    這個(gè)也已經(jīng)嘗試了，兩個(gè)控制文件全部損壞了，嘗試了一些方法，最后還是選擇了重新創(chuàng)建控制文件。感覺是一個(gè)很巧合的事情，rman滿了之后，在某個(gè)寫入點(diǎn)上把控制文件寫壞了

jackson198574

回復(fù) 3# changsiheng


    恩，平時(shí)需要多監(jiān)控一下空間資源使用情況。