温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

ORACLE 11G DB RAC ORA-00257archiver error解决办法

发布时间:2020-07-30 17:49:01 来源:网络 阅读:8951 作者:翘楚秦歌 栏目:数据库

ORA-00257archiver error解决办法

1.之前有处理单机过oracle 11.2.0.4归档日志磁盘空间不足的问题 ,但是没有处理过ORACLE RAC的归档日志磁盘空间不足的问题 

所以没有预想到会是出现asm磁盘空间不足的议题


Oracle数据库是目前业界最常用的大型数据库系统,我在单机ORACLE的实际项目中有遇到出现ORA-00257错误(空间不足错误),

通过查找资料,发现绝大部分说这是由于归档日志太多,占用了全部的硬盘剩余空间导致的,可通过简单删除日志或加大存储空间就能够解决。但是我在Oracle11g RAC上两个RAC节点发现,它们的存储空间都还有很大,却也报这个错误,经过大半天的折腾,发现原来是Oracle11g RAC中的ASM磁盘空间不足导致的。


操作系统CentOS 6.5 x86-64Linux

数据库Oracle 11.2.0.4.0


2.问题现象

数据库系统已经运行了一年多,在5月8号开发同事用应用账号连接数据库后,发现无法连接登入,并且出现ORA-00257:archive error.connect internal only,until freed 错误。

提示归档错误,通过查找ORACLE错误代码,解释为硬盘空间不足,需要删除归档日志增加空间,但是服务器两个节点可用空间都还有1.4T,目前只用了10GB左右,这是为什么呢?

且在5月8号用rman形式删除清理系统100天以前的归档日志以后好了,没想到第二天5月9号又出现了。没有理由啊,一天的归档日志大过一百天的归档日志,所以我就质疑数据库报错的准确性,认为这只是表面的归档日志空间已满,实质性的问题却还不知道。


3.诊断过程: 

因为数据库不是我架设的,对oracle也不太熟,所以不知道归档日志放置的路径,通过语句查找也得到的是个+ARC/back/archivelog/**之类的,但是我就是想破脑袋,用find的方式也找不到具体存放路径。


a.查看数据库REDOLOG情况

[root@~]$ sqlplus / as sysdba

SQL> connect / as sysdba

SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE#FIRST_TIME


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


1 1 101 52428800 1 NO CURRENT 3621973 9-5月 -17


2 1 99 52428800 1 NO INACTIVE 3600145 9-5月 -17


3 1 100 52428800 1 NO INACTIVE 3611932 9-5月 -17


发现ARC状态为NO,表示系统没法自动做归档。



b.查看Oracle数据库后台归档服务进程 

[oracle@~ ]ps -ef | grep oracle

发现grid       3081      1  0 10:14 ?        00:00:00 oracle+ASM1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

一个节点如上述服务正常,但另外一个节点却LOCAL=NO的类似情况,反正服务不正常


c.查看FLASH_RECOVERY_AREA空间中各部分使用情况


SQL> select * from v$recovery_file_dest;


NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

+BACKUP

 1.2885E+11  484442112       0       5

##注:空间大把的有

 

SQL> select * from v$flash_recovery_area_usage;


FILE_TYPE     PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

CONTROL FILE    .04 0 1


REDO LOG    .33 0 4


ARCHIVED LOG      0 0 0



FILE_TYPE     PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

BACKUP PIECE      0 0 0


IMAGE COPY      0 0 0


FLASHBACK LOG      0 0 0



FILE_TYPE     PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

FOREIGN ARCHIVED LOG      0 0 0

7 rows selected.

发现ARCHIVELOG、BACKUPPIRCR都不大,就是0,没什么占用率,这样FLASH_RECOVERY_AREA空间的空间还大把的有。


因为之前报错时,不知道如何处理问题,就像直接shutdown immediate一个节点看看,没想到半天没任何反应,就直接使用shutdown abort强行关闭,该节点出现下列节点挂载实例报问题

d.故障节点挂载实例报错:

SQL> startup  

ORACLE instance started.  

  

Total System Global Area  413372416 bytes  

Fixed Size                  2253784 bytes  

Variable Size             327158824 bytes  

Database Buffers           79691776 bytes  

Redo Buffers                4268032 bytes  

Database mounted.  

ORA-03113: end-of-file on communication channel  

Process ID: 2420  

Session ID: 1 Serial number: 5 


e.查找资料发现,下面做法可行:

SQL> conn / as sysdba  

Connected to an idle instance.  

SQL> startup nomount  

ORACLE instance started.  

  

Total System Global Area  413372416 bytes  

Fixed Size                  2253784 bytes  

Variable Size             327158824 bytes  

Database Buffers           79691776 bytes  

Redo Buffers                4268032 bytes  

SQL> alter database mount;  

  

Database altered.  


SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01034: ORACLE not available

Process ID: 0

Session ID: 0 Serial number: 0 


发现在打开数据文件报错


SQL> recover database until time '2017-05-09'

ORA-00283: recovery session canceled due to errors

ORA-01124: cannot recover data file 1 - file is in use or recovery

ORA-01110: data file 1: '+DATADG/fmall/datafile/system.259.907327891'

用覆盖形式恢复也报错


f.后面有资料提出可使用RMAN操作系统删掉归档来解决问题

rman下crosscheck然后delete。

[oracle@~ ]rman target  sys/pass

RMAN > crosscheck archivelog all;

validation succeeded for archived log

archived log file name=+ARCH/fmall/archivelog/2017_03_08/thread_2_seq_6362.21528.938070989 RECID=43022 STAMP=938070990

validation succeeded for archived log

RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row

RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows

ORACLE error from target database: 

ORA-01089: immediate shutdown in progress - no operations are permitted

Process ID: 14578

Session ID: 235 Serial number: 2647

校验日志的可用性,报错或者等待很久没有结果出来


RMAN > delete archivelog all completed before 'sysdate-30'; 

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

如果你删除三十天前的归档日志,等待很久却没有结果,甚至像上面一样报错可以参考我下面的做法


RMAN > delete force noprompt archivelog until time 'sysdate-30'; 

强制性删除三十天前的归档日志


网站异常告警解除,说明归档日志腾出空间,致使数据库可正常提供应用连接。


g.实例证明,归档日志空间已满导致应用无法连接数据库

有经验的DBA告诉我说,RAC会有一个ASM的磁盘空间议题,我经过查询ASM磁盘空间发现,我的妈呀,ARCH的空间就才腾出282M。


SQL> select name,total_mb,free_mb from v$asm_disk;

NAME TOTAL_MB    FREE_MB

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

GRIDDG_0001           4768      4585

ARCH_0000           944137      282

DATADG_0000         1238390      1202771

GRIDDG_0000           4768      4553

BACKUP_0000          953675      949001


再次进入RMAN,使用delete archivelog的方式再删除15天后,查看ASM磁盘空间大小:

SQL> select name,total_mb,free_mb from v$asm_disk;

NAME TOTAL_MB    FREE_MB

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

GRIDDG_0001            4768        4585

ARCH_0000             944137       716045

DATADG_0000            1238390      1202771

GRIDDG_0000            4768        4553

BACKUP_0000            953675       949001


空出了将近700多G的空间,太可怕了,短短十五天就能够用掉将近七百多G的归档日志空间,我的数据库大小才1.1G,归档日志就一天以十几二十G的速度疯长。一定是哪里出了问题,必须彻查。

当然首先要做的估计就是把清理归档日志命令写成脚本纳入crontab里,按一定时间进行处理。初步怀疑是应用程式sql语句中存在类似于死循环的东西,导致归档日志如此庞大,后续有什么发现,我将再次记录下来。


致此,归档日志空间已满议题是暂时解决了。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI