ORA-16014: log 4 sequence# 1 not archived解决

今天在dataguard 备库起recover 的时候报错：
ORA-16014: log 4 sequence# 1 not archived, no available destinations解决下面第一种方法：
先看
SQL> show parameter db_recoveryNAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      D:Oracleproduct10.2.0/flash
                                                 _recovery_area
db_recovery_file_dest_size           big integer 2GSQL> alter system set db_recovery_file_dest_size=3G scope=both;系统已更改。--------------下面继续这种思路：
1）.检查flash recovery area的使用情况： SQL> select * from v$flash_recovery_area_usage;FILE_TYPE    PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE                 .33                         0               1
ONLINELOG                  7.32                         0               3
ARCHIVELOG                25.06                         0              35
BACKUPPIECE               67.69                         0               4
IMAGECOPY                     0                         0               0
FLASHBACKLOG                  0                         0               0已选择6行。
.计算flash recovery area已经占用的空间： SQL> select sum（percent_space_used）*3/100 from v$flash_recovery_area_usage;SUM（PERCENT_SPACE_USED）*3/100
-----------------------------
3.012
可以看到，这里已经有3.012G使用了，这说明我们刚开始设置的db_recovery_file_dest_size=2G不足，导致online redo log无法归档，在这里，我们通过设置db_recovery_file_dest_size参数，增大了flash recovery area来解决这个问题。（3）.也可以在ｒｍａｎ中通过删除flash recovery area中不必要的备份来释放flash recovery area空间来解决这个问题：（1）. delete obsolete;（2）. crosscheck backupset;delete expired backupset;
我这里事先手工把归档的文件删除一部分，然后用ｒｍａｎ用上面的命令把flash recovery area 实际空间变小。问题就解决了。
------------------后来，我发现这种方法是不能解决我的问题的，原因我的这个原因是归档路径被改变。先启动到mount:
SQL> startup mount;
ORACLE 例程已经启动。Total System Global Area 603979776 bytes
Fixed Size                  1250404 bytes
Variable Size             163580828 bytes
Database Buffers          436207616 bytes
Redo Buffers                2940928 bytes
数据库装载完毕。
SQL> select database_role, open_mode from v$database;DATABASE_ROLE    OPEN_MODE
---------------- ----------
PHYSICAL STANDBY MOUNTED看一下alert 日志：Successful mount of redo thread 1, with mount id 1778855572
Sat Dec 31 15:16:40 2011
Physical Standby Database mounted.
Completed: ALTER DATABASE   MOUNT
Sat Dec 31 15:16:40 2011
ARC1: Archiving not possible: No primary destinations
ARC1: Failed to archive thread 1 sequence 1 （4）
ARCH: Archival stopped, error occurred. Will continue retrying
Sat Dec 31 15:16:41 2011
Errors in file c:oracleproduct10.2.0adminshengdumpsheng_arc1_1836.trc:
ORA-16014: log 4 sequence# 1 not archived, no available destinations
ORA-00312: online log 4 thread 1: "C:ORACLEPRODUCT10.2.0ORADATASHENGREDO04.LOG"再后来：recover database 又报错;SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
*
第 1 行出现错误:
ORA-16136: 受管备用恢复未激活看一下alert 日志：Sat Dec 31 15:20:15 2011
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL
Sat Dec 31 15:20:15 2011
ORA-16136 signalled during: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL...----------------------------下面问题还得一个一个解决：-------------下面看一下归档路径：
好像没有问题，下面解决一下：
SQL> alter database clear unarchived logfile group 4;数据库已更改。SQL> alter database clear unarchived logfile group 5;数据库已更改。SQL> alter database clear unarchived logfile group 6;数据库已更改。SQL> alter database clear unarchived logfile group 7;数据库已更改。------------
shutdown immediate;
startup mount;看一下alert 日志：
Successful mount of redo thread 1, with mount id 1778822431
Sat Dec 31 16:35:50 2011
Physical Standby Database mounted.
Completed: ALTER DATABASE   MOUNT没有问题。SQL> alter database recover managed standby database disconnect from session;数据库已更改。SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;数据库已更改。SQL> alter database open read only;
alter database open read only
*
第 1 行出现错误:
ORA-16004: 备份数据库需要恢复
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: "C:ORACLEPRODUCT10.2.0ORADATASHENGSYSTEM01.DBF"原因是，control file 是primary 以前copy 的，datafile 是dataguard 配好以后再copy 过来的。Data guard 出现gap sequence修复Oracle 使用RMAN自动备份相关资讯 Oracle基础教程

Oracle块编程返回结果集详解（11/10/2013 10:45:58）
Oracle基础教程之设置系统全局区（08/22/2013 14:24:00）
Oracle基础教程知识点总结（06/18/2013 07:43:32）

Oracle基础教程之tkprof程序详解（10/22/2013 11:49:50）
Oracle基础教程之sqlplus汉字乱码（07/18/2013 16:30:00）
Oracle 管理之 Linux 网络基础（02/16/2013 18:37:35）

本文评论查看全部评论（0）