您的位置:首页 > 产品设计 > UI/UE

ORA-16014: log 4 sequence# 1 not archived , 今天解决了

2011-12-31 17:46 316 查看
今天在dataguard 备库起recover 的时候报错:

ORA-16014: log 4 sequence# 1 not archived, no available destinations

解决下面第一种方法:

先看

SQL> show parameter db_recovery

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

db_recovery_file_dest string D:\oracle\product\10.2.0/flash

_recovery_area

db_recovery_file_dest_size big integer 2G

SQL> 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).也可以在rman中通过删除flash recovery area中不必要的备份来释放flash recovery area空间来解决这个问题:

(1). delete obsolete;

(2). crosscheck backupset;

delete expired backupset;

我这里事先手工把归档的文件删除一部分,然后用rman 用上面的 命令把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:\oracle\product\10.2.0\admin\sheng\bdump\sheng_arc1_1836.trc:

ORA-16014: log 4 sequence# 1 not archived, no available destinations

ORA-00312: online log 4 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\SHENG\REDO04.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:\ORACLE\PRODUCT\10.2.0\ORADATA\SHENG\SYSTEM01.DBF'

原因是,control file 是primary 以前copy 的,datafile 是dataguard 配好以后再copy 过来的。

这个问题以后解决
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐