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语句中存在类似于死循环的东西,导致归档日志如此庞大,后续有什么发现,我将再次记录下来。
致此,归档日志空间已满议题是暂时解决了。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。