alter database open resetlogs时 alert的输出

SQL> alter database open resetlogs;

Database altered.
时的提示:


ORA-279 signalled during: ALTER DATABASE RECOVER  datafile 5  ...
ALTER DATABASE RECOVER    CANCEL 
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER    CANCEL 
Sat Apr 18 18:41:33 2015
alter database open resetlogs
ORA-1139 signalled during: alter database open resetlogs...
Sat Apr 18 18:42:06 2015
ALTER DATABASE RECOVER  database until cancel 
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 4 slaves
Sat Apr 18 18:42:06 2015
Warning: Datafile 5 (/u01/app/oracle/oradata/test/ten01.dbf) is offline during full database recovery and will not be recovered
Media Recovery Not Required
Completed: ALTER DATABASE RECOVER  database until cancel 
Sat Apr 18 18:42:23 2015
alter database open resetlogs
RESETLOGS after complete recovery through change 3580552
Archived Log entry 28 added for thread 1 sequence 155 ID 0x7d875fb4 dest 1:
Resetting resetlogs activation ID 2106023860 (0x7d875fb4)
Sat Apr 18 18:42:28 2015
Setting recovery target incarnation to 3
Sat Apr 18 18:42:28 2015
Assigning activation ID 2175494118 (0x81ab67e6)
LGWR: STARTING ARCH PROCESSES
Sat Apr 18 18:42:28 2015
ARC0 started with pid=20, OS id=3826
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Sat Apr 18 18:42:29 2015
ARC1 started with pid=21, OS id=3828
Sat Apr 18 18:42:29 2015
ARC2 started with pid=22, OS id=3830
Sat Apr 18 18:42:29 2015
ARC3 started with pid=23, OS id=3832
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Thread 1 opened at log sequence 1
  Current log# 1 seq# 1 mem# 0: /u01/app/oracle/oradata/test/redo01.log
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Apr 18 18:42:29 2015
SMON: enabling cache recovery
[3781] Successfully onlined Undo Tablespace 2.
Undo initialization finished serial:0 start:11031024 end:11032224 diff:1200 (12 seconds)
Dictionary check beginning
File #5 is offline, but is part of an online tablespace.
data file 5: '/u01/app/oracle/oradata/test/ten01.dbf'
File #12 is offline, but is part of an online tablespace.
data file 12: '/u01/app/oracle/oradata/test/test.dbf'
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
No Resource Manager plan active
Sat Apr 18 18:42:33 2015
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Sat Apr 18 18:42:37 2015
QMNC started with pid=24, OS id=3834
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Sat Apr 18 18:42:50 2015
Completed: alter database open resetlogs
Sat Apr 18 18:42:50 2015
Starting background process CJQ0
Sat Apr 18 18:42:50 2015
CJQ0 started with pid=27, OS id=3854
Sat Apr 18 18:42:51 2015
Checker run found 2 new persistent data failures

<think>我们面对的问题:在Oracle 19c Non-CDB环境下,使用RMAN进行单表恢复,遇到ORA-16000错误,提示数据库以只读方式打开。用户希望解决这个问题并完成单表恢复。 分析: 1. ORA-16000错误表示数据库或可插拔数据库以只读方式打开。在Non-CDB环境中,整个数据库实例是只读的。 2. 单表恢复通常需要使用RMAN的辅助实例(auxiliary instance)来恢复特定表到某个间点,然后将该表导出再导入到原库。 3. 在恢复过程中,辅助实例需要被启动到某个状态(如MOUNT或OPEN),但ORA-16000错误表明辅助实例被以只读方式打开,而恢复操作需要读写模式。 解决思路: 1. 确保辅助实例的控制文件、参数文件等配置正确,特别是要确保辅助实例可以以读写模式打开。 2. 检查辅助实例的初始化参数,确保没有设置`open_readonly=on`之类的参数。 3. 在RMAN恢复脚本中,明确指定辅助实例以读写方式打开。 具体步骤(针对Non-CDB单表恢复): 由于Non-CDB没有PDB的概念,整个恢复过程相对简单。以下是使用RMAN进行单表恢复的一般步骤,并解决ORA-16000错误: 步骤1:准备辅助实例的环境 - 创建辅助实例所需的目录结构(如admin目录、数据文件目录、日志目录等)。 - 创建辅助实例的初始化参数文件(init<SID>.ora),并设置必要的参数,例如: ``` db_name=aux memory_target=1G control_files='/path/to/control01.ctl' db_create_file_dest='/path/to/datafiles' db_create_online_log_dest_1='/path/to/onlinelogs' compatible=19.0.0 # 确保没有设置只读相关的参数,如read_only等 ``` 步骤2:启动辅助实例到NOMOUNT状态 - 使用SQL*Plus连接到辅助实例,启动到NOMOUNT状态: ```sql STARTUP NOMOUNT; ``` 步骤3:在RMAN中连接到目标数据库(要恢复的源库)和辅助实例 ```bash rman target sys/password@source_db auxiliary sys/password@auxiliary_db ``` 步骤4:执行恢复表操作 使用`RECOVER TABLE`命令,并指定间点(如SCN或间戳)和导出文件的存放位置。注意:在恢复过程中,RMAN会自动将辅助实例启动到MOUNT状态,然后恢复数据文件,最后将辅助实例以读写方式打开(这一步是关键,如果出现只读,就会报错)。 但是,如果遇到ORA-16000,可能是由于辅助实例在打开被强制为只读。因此,我们需要在恢复命令中明确指定辅助实例的打开模式。然而,标准的`RECOVER TABLE`命令并没有直接提供指定打开模式的选项。所以,我们需要检查辅助实例的配置,确保它能够以读写方式打开。 检查点: - 辅助实例的初始化参数文件中不能有`read_only=TRUE`这样的参数。 - 辅助实例的密码文件必须存在,并且sys用户的密码正确。 - 辅助实例的日志文件目录必须可写。 步骤5:如果仍然遇到ORA-16000,可以尝试手动控制恢复过程 如果自动恢复表命令(`RECOVER TABLE`)始终无法以读写方式打开辅助实例,我们可以采用传统的间点恢复方法(不完全恢复)来恢复整个数据库到辅助实例,然后手动导出表。步骤如下: 1. 在辅助实例上,使用RMAN恢复目标数据库的备份(控制文件、数据文件)到指定的间点(SCN或间)。 2. 恢复完成后,使用`ALTER DATABASE OPEN RESETLOGS;`打开辅助实例(此必须是读写模式)。 3. 使用数据泵导出需要恢复的表。 4. 将导出的表导入到原库。 这种方式虽然步骤多,但可以完全控制辅助实例的打开模式。 步骤6:导出并导入表 - 在辅助实例上使用数据泵导出表: ```bash expdp system/password@auxiliary_db tables=SCHEMA.TABLE directory=DATA_PUMP_DIR dumpfile=table.dmp logfile=exp_table.log ``` - 然后将导出的dump文件复制到目标库服务器,并导入: ```bash impdp system/password@target_db tables=SCHEMA.TABLE directory=DATA_PUMP_DIR dumpfile=table.dmp logfile=imp_table.log ``` 注意:在导入前,可能需要先备份原表(重命名或导出)以防止数据丢失。 总结: ORA-16000错误通常是由于辅助实例被以只读方式打开导致的。在Non-CDB环境中,我们应确保辅助实例的初始化参数没有设置为只读,并且在恢复过程中RMAN能够以读写方式打开辅助实例。如果使用自动的`RECOVER TABLE`命令失败,可以尝试手动恢复整个辅助实例到指定间点,然后手动导出/导入表。 §§相关问题§§ 1. 如何创建Oracle辅助实例进行RMAN恢复? 2. Oracle RMAN单表恢复的步骤和注意事项有哪些? 3. 如何解决Oracle数据库只读打开(ORA-16000)的问题? 4. 在Oracle 19c Non-CDB环境中,如何执行不完全恢复? 5. 使用数据泵导出导入单表有哪些常见问题?</think>### Oracle 19c Non-CDB RMAN 单表恢复 ORA-16000 解决方案 #### 问题分析 ORA-16000 错误表明数据库或辅助实例以**只读模式**打开,而单表恢复需要**读写模式**才能完成数据恢复操作[^1]。在Non-CDB环境中,常见原因包括: 1. 辅助实例初始化参数错误设置了`read_only=TRUE` 2. RMAN恢复脚本未正确指定打开模式 3. 表空间状态限制(如UNDO表空间不可用) 4. 恢复目标间点处于只读事务中 --- ### 完整解决步骤(Non-CDB环境) #### 步骤1:验证数据库状态 ```sql SELECT open_mode FROM v$database; -- 确认状态为READ WRITE ``` #### 步骤2:创建辅助实例参数文件(关键配置) ```bash # initaux.ora 关键参数 db_name=aux db_unique_name=aux control_files='/u01/oradata/aux/control01.ctl' compatible=19.0.0 db_create_file_dest='/u01/oradata/aux' db_recovery_file_dest='/u01/fra' db_recovery_file_dest_size=10G # 必须禁用只读模式 ↓ read_only=FALSE undo_management=AUTO ``` #### 步骤3:启动辅助实例(注意模式控制) ```bash export ORACLE_SID=aux sqlplus / as sysdba > STARTUP NOMOUNT; > CREATE SPFILE FROM PFILE='/path/initaux.ora'; > SHUTDOWN IMMEDIATE > STARTUP NOMOUNT; # 确保非只读模式启动 ``` #### 步骤4:执行RMAN单表恢复(关键命令) ```rman rman target sys/pwd@primary auxiliary / RUN { SET AUXILIARY INSTANCE PARAMETER FILE TO '/path/initaux.ora'; RECOVER TABLE schema.tabname UNTIL TIME "TO_DATE('2023-12-01 14:00:00','YYYY-MM-DD HH24:MI:SS')" AUXILIARY DESTINATION '/u01/auxiliary' REMAP TABLE 'schema.tabname:new_tabname'; # 避免覆盖原表 } ``` #### 步骤5:处理ORA-16000的专用方案 若仍报错,强制指定读写模式: ```rman RUN { ... SQL "ALTER DATABASE OPEN READ WRITE"; # 显式指定读写模式 RECOVER TABLE ... ; } ``` #### 步骤6:数据导出/导入 ```bash # 从辅助实例导出 expdp system/pwd@aux tables=schema.new_tabname directory=DPUMP_DIR dumpfile=recover.dmp # 导入目标库 impdp system/pwd@primary tables=schema.new_tabname directory=DPUMP_DIR \ remap_table=schema.new_tabname:tabname # 恢复原名 ``` --- ### 关键注意事项 1. **空间要求**:辅助目录需有1.2倍原表空间大小 2. **权限检查**: ```sql GRANT SYSBACKUP TO auxiliary_user; GRANT READ, WRITE ON DIRECTORY data_pump_dir TO system; ``` 3. **日志监控**:恢复过程中检查`alert_aux.log`的打开模式记录 4. **12c/19c差异**:19c需显式设置`db_recovery_file_dest_size`[^3] > **重要**:完成恢复后立即删除辅助实例,避免资源冲突: > ```bash > rman target / > DROP DATABASE INCLUDING BACKUPS NOPROMPT; > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值