仅记录:
Incomplete Recovery applied until change 9744654282788
Flashback Media Recovery Complete
Completed: flashback database to scn 9744654282785
Thu Jun 18 19:13:16 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[7]: Assigned to RFS process 16416
RFS[7]: Identified database type as 'physical standby'
RFS[7]: New Archival REDO Branch: 689886752 Current: 679664461
RFS[7]: No standby redo logfiles created
RFS[7]: Archived Log: '/Tbackup/archivelog/mctest/1_1_689886752.dbf'
RFS[7]: New Archival REDO Branch(resetlogs_id): 689886752 Prior: 679664461
RFS[7]: Archival Activation ID: 0x2c88fd7d Current: 0x2c85130d
RFS[7]: Effect of primary database OPEN RESETLOGS
New incarnation branch detected in ArchiveLog, filename /Tbackup/archivelog/mctest/1_1_689886752.dbf
Inspection of file changed rdi from 1 to 2
Setting recovery target incarnation to 2
Thu Jun 18 19:13:16 2009
RFS[7]: Incarnation entry added for Branch(resetlogs_id): 689886752 (mctest)
Thu Jun 18 19:13:16 2009
Setting recovery target incarnation to 2
Thu Jun 18 19:13:18 2009
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[8]: Assigned to RFS process 16582
RFS[8]: Identified database type as 'physical standby'
alter database open RESETLOGS
ARCH: Logfile 1 is wrong incarnation (0:1049208:06/19/2009 12:40:02 vs 0:446075:06/16/2009 17:12:13)
ARCH: Logfile 2 is wrong incarnation (0:1049208:06/19/2009 12:40:02 vs 0:446075:06/16/2009 17:12:13)
ARCH: Logfile 3 is wrong incarnation (0:1049208:06/19/2009 12:40:02 vs 0:446075:06/16/2009 17:12:13)
RESETLOGS after complete recovery through change 1055358
Resetting resetlogs activation ID 1987903337 (0x767cff69)
Fri Jun 19 15:56:51 2009
Setting recovery target incarnation to 2
Dictionary check beginning
Tablespace 'TEMP' #3 found in data dictionary,
but not in the controlfile. Adding to controlfile.
Tablespace 'USERS' #4 found in data dictionary,
but not in the controlfile. Adding to controlfile.
File #4 found in data dictionary but not in controlfile.
Creating OFFLINE file 'MISSING00004' in the controlfile.
This file can no longer be recovered so it must be dropped.
Dictionary check complete
分享到:
相关推荐
日志传输是指从主库传输日志到备库,以确保备库的数据是一致的。在 Switchover 或 Failover 过程中,日志传输是必不可少的一步。 7. alert.log alert.log 是 Oracle 数据库的日志文件,记录着数据库的所有操作。在...
使用 RMAN+DUPLICATE 命令可以快速地将主库数据库文件、日志文件、控制文件共同复制到备库中,不需要主库关机,也不需要主库做备份,再到备库恢复。 DataGuard 配置 配置 DataGuard 需要设置保护模式为 MAXIMUM ...
同时,还涉及了闪回技术,如闪回数据库、闪回表和闪回事务,这些能够在不影响其他用户的情况下,快速撤销错误操作。 除了常规的恢复技术,书中还探讨了复杂的恢复场景,例如多数据文件损坏、控制文件丢失以及时间点...
在此模式下,redo 传输可以选择 arch 或 lgwr 进程,并且主库的日志可以异步传输到备库,从而最小化对主库性能的影响,但也存在主库崩溃时可能出现数据丢失的风险。 #### 四、重要进程 - **RFS (Remote File Server...
- **方法**:使用`cat /u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log`命令查看alert日志文件。 **2.3 检查Oracle核心转储目录** - **目的**:检查是否存在Oracle核心转储文件,这可能是Oracle进程...
- `alert.log`和`trace files`记录了错误信息,有助于诊断问题。 - `RMAN`(Recovery Manager)工具用于备份、恢复和维护数据库。 11. **Network Configuration**: - 使用适当的网络协议(如TCP/IP)配置主库和...
1. Alert日志:记录数据库运行中的警告和错误信息,是排查问题的重要资源。 2. Trace文件:当发生异常时,Oracle会生成Trace文件,提供详细的错误信息。 3. V$视图:提供实时的数据库状态信息,用于监控和诊断。 ...
- **检查RMAN日志**:通过查看RMAN的输出日志,可以找到归档日志是否已经被成功备份的信息。 #### 3. 如何查看指定文件系统的剩余空间及其子目录占用的空间? **知识点解析:** - **Unix/Linux环境下**: - 使用`...
- 需要先检查alert日志获取更多关于故障的信息。 - 如果日志中出现ORA-01151错误提示,则需要进行介质恢复。 - 关闭数据库,使用`shutdown immediate`命令。 - 使用`startup nomount`命令以nomount模式启动...