STANDBY DATABSE UNDO ERROR(ORA-10564、ORA-10567、ORA-01110）

最新推荐文章于 2024-07-30 09:35:41 发布
最新推荐文章于 2024-07-30 09:35:41 发布
阅读量987 收藏 1
点赞数
文章标签： 数据库 网络 操作系统
standby database trace log
Tue Dec 15 10:19:43 2015
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (oracle11)
Tue Dec 15 10:19:43 2015
MRP0 started with pid=28, OS id=25313 
MRP0: Background Managed Standby Recovery process started (oracle11)
 started logmerger process
Tue Dec 15 10:19:48 2015
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 12 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /orafile/oraarch/1_1031_882528643.rac
Completed: alter database recover managed standby database using current logfile disconnect
Tue Dec 15 10:19:49 2015
Errors in file /app/oracle/diag/rdbms/oracle11dg/oracle11/trace/oracle11_pr06_25328.trc  (incident=576287):
ORA-00600: 内部错误代码, 参数: [3020], [3], [24862], [12607774], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 24862, file offset is 407339008 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 数据文件 3: '/orafile/oradata/undotbs01.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Incident details in: /app/oracle/diag/rdbms/oracle11dg/oracle11/incident/incdir_576287/oracle11_pr06_25328_i576287.trc
Tue Dec 15 10:19:49 2015
Errors in file /app/oracle/diag/rdbms/oracle11dg/oracle11/trace/oracle11_pr09_25334.trc  (incident=576311):
ORA-00600: 内部错误代码, 参数: [3020], [3], [11606], [12594518], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 11606, file offset is 190152704 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 数据文件 3: '/orafile/oradata/undotbs01.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Incident details in: /app/oracle/diag/rdbms/oracle11dg/oracle11/incident/incdir_576311/oracle11_pr09_25334_i576311.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Slave exiting with ORA-600 exception
Errors in file /app/oracle/diag/rdbms/oracle11dg/oracle11/trace/oracle11_pr09_25334.trc:
ORA-00600: 内部错误代码, 参数: [3020], [3], [11606], [12594518], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 11606, file offset is 190152704 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 数据文件 3: '/orafile/oradata/undotbs01.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Slave exiting with ORA-600 exception
Errors in file /app/oracle/diag/rdbms/oracle11dg/oracle11/trace/oracle11_pr06_25328.trc:
ORA-00600: 内部错误代码, 参数: [3020], [3], [24862], [12607774], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 24862, file offset is 407339008 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 数据文件 3: '/orafile/oradata/undotbs01.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Errors in file /app/oracle/diag/rdbms/oracle11dg/oracle11/trace/oracle11_mrp0_25313.trc  (incident=576231):
ORA-00600: 内部错误代码, 参数: [3020], [3], [11606], [12594518], [], [], [], [], [], [], [], []
ORA-10567: Redo is inconsistent with data block (file# 3, block# 11606, file offset is 190152704 bytes)
ORA-10564: tablespace UNDOTBS1
ORA-01110: 数据文件 3: '/orafile/oradata/undotbs01.dbf'
ORA-10560: block type 'KTU UNDO BLOCK'
Incident details in: /app/oracle/diag/rdbms/oracle11dg/oracle11/incident/incdir_576231/oracle11_mrp0_25313_i576231.trc
Tue Dec 15 10:19:50 2015
Dumping diagnostic data in directory=[cdmp_20151215101950], requested by (instance=1, osid=25334 (PR09)), summary=[incident=576311].
Tue Dec 15 10:19:50 2015
Sweep [inc][576311]: completed
Sweep [inc][576287]: completed
Sweep [inc][576231]: completed
Sweep [inc2][576311]: completed
Sweep [inc2][576287]: completed
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Recovery Slave PR09 previously exited with exception 600
MRP0: Background Media Recovery terminated with error 448
Errors in file /app/oracle/diag/rdbms/oracle11dg/oracle11/trace/oracle11_pr00_25316.trc:
ORA-00448: 后台进程正常结束
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 3539009743
MRP0: Background Media Recovery process shutdown (oracle11)
Dumping diagnostic data in directory=[cdmp_20151215101951], requested by (instance=1, osid=25313 (MRP0)), summary=[incident=576231].
ORA-01110: 数据文件 3: '/orafile/oradata/undotbs01.dbf'Tue Dec 15 10:20:50 2015
Sweep [inc2][576231]: completed
ORA-10567: Redo is inconsistent with data block (file# 3, block# 24862, file offset is 407339008 bytes)Tue Dec 15 10:32:41 2015
db_recovery_file_dest_size of 819200 MB is 0.44% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Tue Dec 15 10:48:39 2015
alter tablespace UNDOTBS1 begin backup
ORA-1109 signalled during: alter tablespace UNDOTBS1 begin backup...
Tue Dec 15 10:49:52 2015
alter tablespace UNDOTBS1 end backup
Completed: alter tablespace UNDOTBS1 end backup
Tue Dec 15 10:55:14 2015
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process MMNL
Stopping background process MMON
License high water mark = 17
All dispatchers and shared servers shutdown
ALTER DATABASE CLOSE NORMAL
ORA-1109 signalled during: ALTER DATABASE CLOSE NORMAL...
ALTER DATABASE DISMOUNT
Shutting down archive processes
Archiving is disabled
Tue Dec 15 10:55:19 2015
ARCH shutting down
Tue Dec 15 10:55:19 2015
ARCH shutting down
Tue Dec 15 10:55:19 2015
ARC3: Archival stoppedARCH shutting down


Tue Dec 15 10:55:19 2015
ARCH shutting down
ARC1: Archival stopped
ARC2: Relinquishing active heartbeat ARCH role
ARC0: Archival stopped
ARC2: Archival stopped
Completed: ALTER DATABASE DISMOUNT
ARCH: Archival disabled due to shutdown: 1089
Shutting down archive processes
Archiving is disabled
ARCH: Archival disabled due to shutdown: 1089
Tue Dec 15 10:55:21 2015
Stopping background process VKTM
Shutting down archive processes
Archiving is disabled
Tue Dec 15 10:55:24 2015
Instance shutdown complete
Tue Dec 15 10:55:30 2015
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =250
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /app/oracle/product/11.2.0/db_1
System name:    Linux
Node name:      smsplatform02
Release:        3.8.13-44.1.1.el6uek.x86_64
Version:        #2 SMP Wed Sep 10 06:10:25 PDT 2014
Machine:        x86_64
Using parameter settings in server-side spfile /app/oracle/product/11.2.0/db_1/dbs/spfileoracle11.ora
System parameters with non-default values:
  processes                = 1500
  sessions                 = 2280
  nls_language             = "SIMPLIFIED CHINESE"
  nls_territory            = "CHINA"
  memory_target            = 12864M
  control_files            = "/orafile/oradata/control01.ctl"
  control_files            = "/orafile/oradata/control02.ctl"
  control_files            = "/backup/orafile/control03.ctl"
  db_block_size            = 16384
  compatible               = "11.2.0.0.0"
  log_archive_dest_1       = "LOCATION=/orafile/oraarch  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=oracle11dg"
  log_archive_dest_2       = "SERVICE=primary LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=oracle11"
  log_archive_dest_state_1 = "ENABLE"
  log_archive_dest_state_2 = "ENABLE"
  fal_client               = "standby"
  fal_server               = "primary"
  log_archive_config       = "dg_config=(oracle11,oracle11dg)"
  log_archive_format       = "%t_%s_%r.rac"
  db_recovery_file_dest    = "/backup/orafile"
  db_recovery_file_dest_size= 800G
  standby_file_management  = "AUTO"
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=oracle11XDB)"
  utl_file_dir             = "/home/oracle/"
  audit_file_dest          = "/app/oracle/admin/oracle11/adump"
  commit_wait              = "NOWAIT"
  commit_logging           = "BATCH"
  audit_trail              = "DB"
  db_name                  = "oracle11"
  db_unique_name           = "oracle11dg"
  open_cursors             = 3000
  deferred_segment_creation= TRUE
  diagnostic_dest          = "/app/oracle"
Tue Dec 15 10:55:32 2015
PMON started with pid=2, OS id=26934 
Tue Dec 15 10:55:32 2015
PSP0 started with pid=3, OS id=26936 
Tue Dec 15 10:55:33 2015
VKTM started with pid=4, OS id=26938 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Tue Dec 15 10:55:33 2015
GEN0 started with pid=5, OS id=26942 
Tue Dec 15 10:55:33 2015
DIAG started with pid=6, OS id=26944 
Tue Dec 15 10:55:33 2015
DBRM started with pid=7, OS id=26946 
Tue Dec 15 10:55:33 2015
DIA0 started with pid=8, OS id=26948 
Tue Dec 15 10:55:33 2015
MMAN started with pid=9, OS id=26950 
Tue Dec 15 10:55:33 2015
DBW0 started with pid=10, OS id=26952 
Tue Dec 15 10:55:33 2015
DBW1 started with pid=11, OS id=26954 
Tue Dec 15 10:55:33 2015
LGWR started with pid=12, OS id=26956 
Tue Dec 15 10:55:33 2015
CKPT started with pid=13, OS id=26958 
Tue Dec 15 10:55:33 2015
SMON started with pid=14, OS id=26960 
Tue Dec 15 10:55:33 2015
RECO started with pid=15, OS id=26962 
Tue Dec 15 10:55:33 2015
MMON started with pid=16, OS id=26964 
Tue Dec 15 10:55:33 2015
MMNL started with pid=17, OS id=26966 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /app/oracle
Tue Dec 15 10:55:33 2015
ALTER DATABASE   MOUNT
ARCH: STARTING ARCH PROCESSES
Tue Dec 15 10:55:37 2015
ARC0 started with pid=21, OS id=27155 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Successful mount of redo thread 1, with mount id 2591747685
Physical Standby Database mounted.
Lost write protection disabled
Tue Dec 15 10:55:38 2015
ARC1 started with pid=22, OS id=27171 
Tue Dec 15 10:55:39 2015
ARC2 started with pid=23, OS id=27173 
Tue Dec 15 10:55:39 2015
ARC3 started with pid=24, OS id=27175 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
Completed: ALTER DATABASE   MOUNT
Tue Dec 15 10:55:39 2015
ALTER DATABASE OPEN
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Log /orafile/oraarch/1_1031_882528643.rac
Tue Dec 15 10:55:39 2015
Using STANDBY_ARCHIVE_DEST parameter default value as /orafile/oraarch
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Tue Dec 15 10:55:44 2015
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1]: Assigned to RFS process 27185
RFS[1]: Selected log 12 for thread 1 sequence 1192 dbid -1722023950 branch 882528643
Tue Dec 15 10:55:44 2015
RFS[2]: Assigned to RFS process 27187
RFS[2]: Selected log 11 for thread 1 sequence 1191 dbid -1722023950 branch 882528643
Tue Dec 15 10:55:54 2015
Archived Log entry 1259 added for thread 1 sequence 1191 ID 0x998786f6 dest 1:
Tue Dec 15 10:55:59 2015
Media Recovery Log /orafile/oraarch/1_1032_882528643.rac
Tue Dec 15 10:56:18 2015
Media Recovery Log /orafile/oraarch/1_1033_882528643.rac
Tue Dec 15 10:56:51 2015
Media Recovery Log /orafile/oraarch/1_1034_882528643.rac
Tue Dec 15 10:57:18 2015
Media Recovery Log /orafile/oraarch/1_1035_882528643.rac
Tue Dec 15 10:58:06 2015
Media Recovery Log /orafile/oraarch/1_1036_882528643.rac
Tue Dec 15 10:58:38 2015
Media Recovery Log /orafile/oraarch/1_1037_882528643.rac
Media Recovery Log /orafile/oraarch/1_1038_882528643.rac
Tue Dec 15 10:58:58 2015
Media Recovery Log /orafile/oraarch/1_1039_882528643.rac
Tue Dec 15 10:59:17 2015
Media Recovery Log /orafile/oraarch/1_1040_882528643.rac
Tue Dec 15 10:59:30 2015
Media Recovery Log /orafile/oraarch/1_1041_882528643.rac
Tue Dec 15 10:59:48 2015
Media Recovery Log /orafile/oraarch/1_1042_882528643.rac
Tue Dec 15 11:00:04 2015
Media Recovery Log /orafile/oraarch/1_1043_882528643.rac
Tue Dec 15 11:00:47 2015
Media Recovery Log /orafile/oraarch/1_1044_882528643.rac
Media Recovery Log /orafile/oraarch/1_1045_882528643.rac
Media Recovery Log /orafile/oraarch/1_1046_882528643.rac
Tue Dec 15 11:01:04 2015
Media Recovery Log /orafile/oraarch/1_1047_882528643.rac
Tue Dec 15 11:01:17 2015
Media Recovery Log /orafile/oraarch/1_1048_882528643.rac
Tue Dec 15 11:01:36 2015
Media Recovery Log /orafile/oraarch/1_1049_882528643.rac
Tue Dec 15 11:01:53 2015
Media Recovery Log /orafile/oraarch/1_1050_882528643.rac




priamry database
alter tablespace UNDOTBS1 begin backup;                                        
host cp /orafile/oradata/undotbs01.dbf /home/oracle/undotbs01.dbf


alter tablespace UNDOTBS1 end backup; 






standby database






SQL> alter database datafile 3 offline drop;


Database altered.


SQL> host cp /orafile/oradata/undotbs01.dbf /orafile/oradata/bakundotbs01.dbf


SQL> host scp /home/oracle/undotbs01.dbf oracle@172.20.1.100:/orafile/oradata/undotbs01.dbf


SQL> alter database datafile 3 online;


Database altered.


SQL>  alter database recover managed standby database disconnect from session;


Database altered.


SQL> alter database recover managed standby database cancel;


Database altered.


SQL> alter database open read only; 


Database altered.


SQL> alter database recover managed standby database using current logfile disconnect;


Database altered.




see standby tarce日志已经恢复正常


Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 3
Autotune of undo retention is turned on. 
IMODE=BR
ILAT =250
LICENSE_MAX_USERS = 0
SYS auditing is disabled
Starting up:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options.
ORACLE_HOME = /app/oracle/product/11.2.0/db_1
System name:    Linux
Node name:      smsplatform02
Release:        3.8.13-44.1.1.el6uek.x86_64
Version:        #2 SMP Wed Sep 10 06:10:25 PDT 2014
Machine:        x86_64
Using parameter settings in server-side spfile /app/oracle/product/11.2.0/db_1/dbs/spfileoracle11.ora
System parameters with non-default values:
  processes                = 1500
  sessions                 = 2280
  nls_language             = "SIMPLIFIED CHINESE"
  nls_territory            = "CHINA"
  memory_target            = 12864M
  control_files            = "/orafile/oradata/control01.ctl"
  control_files            = "/orafile/oradata/control02.ctl"
  control_files            = "/backup/orafile/control03.ctl"
  db_block_size            = 16384
  compatible               = "11.2.0.0.0"
  log_archive_dest_1       = "LOCATION=/orafile/oraarch  VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=oracle11dg"
  log_archive_dest_2       = "SERVICE=primary LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=oracle11"
  log_archive_dest_state_1 = "ENABLE"
  log_archive_dest_state_2 = "ENABLE"
  fal_client               = "standby"
  fal_server               = "primary"
  log_archive_config       = "dg_config=(oracle11,oracle11dg)"
  log_archive_format       = "%t_%s_%r.rac"
  db_recovery_file_dest    = "/backup/orafile"
  db_recovery_file_dest_size= 800G
  standby_file_management  = "AUTO"
  undo_tablespace          = "UNDOTBS1"
  remote_login_passwordfile= "EXCLUSIVE"
  db_domain                = ""
  dispatchers              = "(PROTOCOL=TCP) (SERVICE=oracle11XDB)"
  utl_file_dir             = "/home/oracle/"
  audit_file_dest          = "/app/oracle/admin/oracle11/adump"
  commit_wait              = "NOWAIT"
  commit_logging           = "BATCH"
  audit_trail              = "DB"
  db_name                  = "oracle11"
  db_unique_name           = "oracle11dg"
  open_cursors             = 3000
  deferred_segment_creation= TRUE
  diagnostic_dest          = "/app/oracle"
Tue Dec 15 10:55:32 2015
PMON started with pid=2, OS id=26934 
Tue Dec 15 10:55:32 2015
PSP0 started with pid=3, OS id=26936 
Tue Dec 15 10:55:33 2015
VKTM started with pid=4, OS id=26938 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Tue Dec 15 10:55:33 2015
GEN0 started with pid=5, OS id=26942 
Tue Dec 15 10:55:33 2015
DIAG started with pid=6, OS id=26944 
Tue Dec 15 10:55:33 2015
DBRM started with pid=7, OS id=26946 
Tue Dec 15 10:55:33 2015
DIA0 started with pid=8, OS id=26948 
Tue Dec 15 10:55:33 2015
MMAN started with pid=9, OS id=26950 
Tue Dec 15 10:55:33 2015
DBW0 started with pid=10, OS id=26952 
Tue Dec 15 10:55:33 2015
DBW1 started with pid=11, OS id=26954 
Tue Dec 15 10:55:33 2015
LGWR started with pid=12, OS id=26956 
Tue Dec 15 10:55:33 2015
CKPT started with pid=13, OS id=26958 
Tue Dec 15 10:55:33 2015
SMON started with pid=14, OS id=26960 
Tue Dec 15 10:55:33 2015
RECO started with pid=15, OS id=26962 
Tue Dec 15 10:55:33 2015
MMON started with pid=16, OS id=26964 
Tue Dec 15 10:55:33 2015
MMNL started with pid=17, OS id=26966 
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = /app/oracle
Tue Dec 15 10:55:33 2015
ALTER DATABASE   MOUNT
ARCH: STARTING ARCH PROCESSES
Tue Dec 15 10:55:37 2015
ARC0 started with pid=21, OS id=27155 
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Successful mount of redo thread 1, with mount id 2591747685
Physical Standby Database mounted.
Lost write protection disabled
Tue Dec 15 10:55:38 2015
ARC1 started with pid=22, OS id=27171 
Tue Dec 15 10:55:39 2015
ARC2 started with pid=23, OS id=27173 
Tue Dec 15 10:55:39 2015
ARC3 started with pid=24, OS id=27175 
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC2: Becoming the heartbeat ARCH
ARC2: Becoming the active heartbeat ARCH
Completed: ALTER DATABASE   MOUNT
Tue Dec 15 10:55:39 2015
ALTER DATABASE OPEN
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
Beginning standby crash recovery.
Serial Media Recovery started
Managed Standby Recovery starting Real Time Apply
Media Recovery Log /orafile/oraarch/1_1031_882528643.rac
Tue Dec 15 10:55:39 2015
Using STANDBY_ARCHIVE_DEST parameter default value as /orafile/oraarch
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Tue Dec 15 10:55:44 2015
Primary database is in MAXIMUM PERFORMANCE mode
RFS[1]: Assigned to RFS process 27185
RFS[1]: Selected log 12 for thread 1 sequence 1192 dbid -1722023950 branch 882528643
Tue Dec 15 10:55:44 2015
RFS[2]: Assigned to RFS process 27187
RFS[2]: Selected log 11 for thread 1 sequence 1191 dbid -1722023950 branch 882528643
Tue Dec 15 10:55:54 2015
Archived Log entry 1259 added for thread 1 sequence 1191 ID 0x998786f6 dest 1:
Tue Dec 15 10:55:59 2015
Media Recovery Log /orafile/oraarch/1_1032_882528643.rac
Tue Dec 15 10:56:18 2015
Media Recovery Log /orafile/oraarch/1_1033_882528643.rac
Tue Dec 15 10:56:51 2015
Media Recovery Log /orafile/oraarch/1_1034_882528643.rac
Tue Dec 15 10:57:18 2015
Media Recovery Log /orafile/oraarch/1_1035_882528643.rac
Tue Dec 15 10:58:06 2015
Media Recovery Log /orafile/oraarch/1_1036_882528643.rac
Tue Dec 15 10:58:38 2015
Media Recovery Log /orafile/oraarch/1_1037_882528643.rac
Media Recovery Log /orafile/oraarch/1_1038_882528643.rac
Tue Dec 15 10:58:58 2015
Media Recovery Log /orafile/oraarch/1_1039_882528643.rac
Tue Dec 15 10:59:17 2015
Media Recovery Log /orafile/oraarch/1_1040_882528643.rac
Tue Dec 15 10:59:30 2015
Media Recovery Log /orafile/oraarch/1_1041_882528643.rac
Tue Dec 15 10:59:48 2015
Media Recovery Log /orafile/oraarch/1_1042_882528643.rac
Tue Dec 15 11:00:04 2015
Media Recovery Log /orafile/oraarch/1_1043_882528643.rac
Tue Dec 15 11:00:47 2015
Media Recovery Log /orafile/oraarch/1_1044_882528643.rac
Media Recovery Log /orafile/oraarch/1_1045_882528643.rac
Media Recovery Log /orafile/oraarch/1_1046_882528643.rac
Tue Dec 15 11:01:04 2015
Media Recovery Log /orafile/oraarch/1_1047_882528643.rac
Tue Dec 15 11:01:17 2015
Media Recovery Log /orafile/oraarch/1_1048_882528643.rac
Tue Dec 15 11:01:36 2015
Media Recovery Log /orafile/oraarch/1_1049_882528643.rac
Tue Dec 15 11:01:53 2015
Media Recovery Log /orafile/oraarch/1_1050_882528643.rac

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

转载于:http://blog.itpub.net/29065182/viewspace-1872555/

csdn426523
关注
Oracle ADG备库SYSAUX数据文件坏块恢复处理（ORA-00600,ORA-10567,ORA-10564......
Enmotech的博客
10-14 1281
点击上方"蓝字"关注我们，享更多干货！本文阐述了Oracle ADG备库SYSAUX数据文件坏块恢复处理（ORA-00600,ORA-10567,ORA-10564,ORA-01110,O...
oracle ora 01152,standby database ope时，提示ORA-10458: ORA-01152: ORA-01110:
weixin_32656511的博客
04-10 1399
在配置完standby database，完成数据库同步时，将standby database切换到open状态时，提示下面的的错误SQL> select open_mode from v$database;OPEN_MODE--------------------MOUNTEDSQL> alter database open;alter database open*ERROR at ...
Oracle备库ORA-00600、ORA-10567、ORA-10564、ORA-01110、ORA-10560
m0_37625564的博客
05-06 1273
现象描述： alert日志： Thu Apr 29 13:21:00 2021 Hex dump of (file 35, block 2111309) in trace file /u01/app/oracle/diag/rdbms/orclstd/orcl/trace/orcl_pr04_16930.trc Reading datafile '/u01/app/oracle/oradata/orcl/user20200821.dbf' for corruption at rdba: 0x08e0374d
Oracle DG GAP---ORA-10567 Redo is inconsistent with data block
最新发布
u014332621的博客
07-30 392
pwdls -lhls -lhpwdls -lh。
dataguard 备库ora-10567 ora-10564 ora-01110 ora-10560报错处理
weixin_47064402的博客
11-28 171
注：还有一种方式可以尝试，即找到备库卡在哪个归档上没有应用，将主库对应的归档传输一份到备库，并将备库原归档 mv 成其他名字，然后数据库启动到mount状态进行recover。8.当alert日志出现如下内容且mpr进程与rfs进程对应的sequence#一致时 取消mrp应用日志进程。9.取消应用日志后开启数据库并开启日志实时应用，至此dataguard主备已完全同步。1.查看alter日志，发现报错信息如下，具体内容为数据文件号为3的文件发生块损坏。6.将备份片注册进数据库并进行restore。
DataGuard - ORA-10567错误
Kamus' Oracle World
08-30 4057
数据库已经升级到9205，操作系统是Sun Solaris 8在Data Guard环境中作Primary端的数据导入，大概有2G的dmp文件导入过程中在Primary端添加一个数据文件由于设置了standby_file_nanagement=auto，该数据文件自动在Standby端也创建了但是立刻接下来的recover就报ORA-10567错误整个报错信息如下：Erro
ORA-10567故障处理
weixin_34364071的博客
05-24 1113
一：场景描述数据库版本：11.2.0.1 64bit active dataguard操作系统版本：centos 5.8 64bit早上数据库例行检查，发现undo表空间数据文件太大，查询了最大的block后，发现实际只使用到几百兆。于是想当然alter database datafile 'xxxx' resize 3G;万事ok！在这之前，遇到这种情况，也都是这样处理，均未出现过问题！个人不太...
oracle ora1019,ORACLE 11G 配置DG 报ORA-10458、ORA-01152、ORA-01110
weixin_36282765的博客
04-05 947
操作系统:Oracle Linux Server release 5.7数据库版本：Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 -64bit ProductionPL/SQL Release 11.2.0.3.0 - ProductionCORE11.2.0.3.0ProductionTNS for Linux: Vers...
oracle ora 00283,ORA-00283 ORA-19909 ORA-01110
weixin_39583521的博客
04-04 696
MRP Recovery Failed With ORA-19909 [ID 554358.1]修改时间 24-MAR-2011类型 PROBLEM状态 PUBLISHEDIn this DocumentApplies to:Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 10.2.0.3 - Release:...
oracle select ora-16000,standby上增加tempfile报错ORA-00604,ORA-16000解决方法
weixin_29194817的博客
04-04 1410
众所周知在DG中对primary增加tempfile不会同步到standby上，所以增加tempfile需要在standby上操作，但这次在standby上增加tempfile却报错ORA-00604 ORA-16000 (mount状态，MRP cancel报错依旧)。分析：这里ORA-00604通常是trigger在影响，因为时间紧迫没有做10046 trace，直接查询官方得到权威解释。原...
Oracle standby ORA-00600:[3020] ORA-10567
cuilingqiao0657的博客
10-26 504
現象 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production Red Hat Ent...
oracle数据库ORA-01196错误解决办法分享
09-09
主要介绍了oracle数据库ORA-01196错误解决办法分享，小编觉得还是挺不错的，这里分享给大家，供需要的朋友参考。
ORA-10567,ORA-00313
岁月有声。。。
09-17 4477
 今天碰到一个奇怪的问题，有一个测试的数据库down了，我们一个同事去重新启动一下DB，但是过了几分钟后又down了，察看alert_*.log发现有下列错误：Errors in file /home/sfcs/admin/world/udump/water_ora_15814.trc:ORA-00600: internal error code, arguments: [3020], [
ORA-00600 3020 ORA-10567案例
weixin_33816821的博客
11-25 873
  PlateSpin克隆复制出的Oracle数据库服务器，往往启动数据库实例都会遇到一些杂七杂八的问题。今天测试DR环境时又遇到了一个特殊场景，在此之前，我已经遇到了下面两起案例： ORA-00600: internal error code, arguments: [kcratr1_lastbwr], [], [], [], [], [], [], [] ORA-00600: internal...
ORA-10567: Redo is inconsistent with data block
huangliang0703的专栏
02-09 2811
这两天 在做DG升级，备库应用日志的时候遭遇了以下问题： Media Recovery Log /export/11g/flash_recovery_area/ORCL2/archivelog/2015_02_08/o1_mf_1_34_bfgq6snb_.arc Hex dump of (file 3, block 160) in trace file /export/11g/di
oracle 10561,oracle standby ORA-10567:故障
weixin_36272416的博客
04-05 275
版本 oracle 10g R2 10.2.0.1 x64平台:redhat as4u6-x64oraclestandby ORA-10567:故障Errors in file/opt/oracle10g/admin/ORCL/bdump/orcl_mrp0_30516.trc:ORA-00600: internal error code, arguments: [3020], [4], [53...
Oracle数据文件删除之后ORA-00600[3020] ORA-10567报错处理
Kay的博客
05-31 857
由于数据文件被误删除，从Linux文件句柄恢复之后，recover redo出现数据不一致错误，无法利用redo日志做恢复。在未开启归档模式下，可以使用跳过数据块的形式，将数据库强制打开。 使用命令recover datafile file# allow N corruption;允许数据库跳过N个数据库进行redo的recover，如上是跳过100个数据块之后，数据库成功open ...
ORA-00600 3020 和ORA-10567 问题定位
cucanqi9387的博客
09-03 255
SQL> recover standby database;ORA-00279: change 7718749264083 generated at 08/11/2012 16:02:01 needed forthread...
Error: ORA-16795: the standby database needs to be re-create 怎么解决
06-13
ORA-16795错误通常是由于物理备库的配置出现问题引起的。解决此问题的步骤如下： 1. 检查主库和备库之间的网络连接是否正常，确保可以相互访问。 2. 确认主库和备库之间的日志传输是否正常运行。可以使用以下命令检查： a. 在主库上运行：SELECT THREAD#, SEQUENCE#, STATUS FROM V$LOG; b. 在备库上运行：SELECT THREAD#, SEQUENCE#, STATUS FROM V$LOG_HISTORY; 如果备库中缺少主库中的某些日志，则需要将这些日志手动复制到备库中。 3. 确认备库的配置是否正确。可以使用以下命令检查： a. 在备库上运行：SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME LIKE '%db_unique_name%'; b. 确认备库的db_unique_name与主库的db_unique_name是否一致。 4. 如果上述步骤都没有解决问题，则需要重新创建备库。可以使用以下步骤重新创建备库： a. 在备库上运行：ALTER DATABASE DISMOUNT; b. 在备库上运行：DROP DATABASE; c. 重新创建备库。 最后，建议您在解决ORA-16795错误之前备份数据库。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值