ORA-00257: archiver error.Connect internalonly, until freed 后续之 delete force

前言--现象描述

远程plsq登录报错“

ORA-00257: archiver error.Connect internalonly, until freed

alert后台日志报错:

Errors in file/oracle/app/oracle/diag/rdbms/pdunq/ptext/trace/ptext_arcc_19603.trc:

ORA-19809: limit exceeded for recoveryfiles

ORA-19804: cannot reclaim 42910720 bytesdisk space from 23622320128 limit

ARCc: Error 19809 Creating archive log fileto'/oracle/app/oracle/flash_recovery_area/PDUNQ/archivelog/2015_05_14/o1_mf_1_190_%u_.arc'

Thu May 14 10:08:18 2015

Errors in file /oracle/app/oracle/diag/rdbms/pdunq/ptext/trace/ptext_arcd_19605.trc:

ORA-19815: WARNING:db_recovery_file_dest_size of 23622320128 bytes is 100.00% used, and has 0remaining bytes available.

************************************************************************

You have following choices to free up spacefrom recovery area:

1. Consider changing RMAN RETENTION POLICY.If you are using Data Guard,

  then consider changing RMAN ARCHIVELOG DELETION POLICY.

2. Back up files to tertiary device such astape using RMAN

  BACKUP RECOVERY AREA command.

3. Add disk space and increasedb_recovery_file_dest_size parameter to

  reflect the new space.

4. Delete unnecessary files using RMANDELETE command. If an operating

  system command was used to delete files, then use RMAN CROSSCHECK and

  DELETE EXPIRED commands.

************************************************************************

1,先进去查看是否磁盘已经满了,df -h检查OK,磁盘空间足够了

[oracle@powerlong4 ptext]$ pwd

/home/oradata/ptext

[oracle@powerlong4 ptext]$ df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/sda3              57G   20G  35G  37% /

tmpfs                  12G  2.1G  10G  18% /dev/shm

/dev/sda1             194M   32M 153M  18% /boot

/dev/mapper/vg001-lv001

                       63G   49G  12G  81% /home/oradata

df: `/root/.gvfs': Permission denied

[oracle@powerlong4 ptext]$

2,查看归档日志的路径

SQL> show parameter log_archive_dest;

NAME                                        TYPE       VALUE

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

log_archive_dest                   string

log_archive_dest_1                        string

log_archive_dest_10                      string

log_archive_dest_11                      string

log_archive_dest_12                      string

log_archive_dest_13                      string

log_archive_dest_14                      string

log_archive_dest_15                      string

log_archive_dest_16                      string

log_archive_dest_17                      string

log_archive_dest_18                      string

NAME                                        TYPE       VALUE

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

log_archive_dest_19                      string

log_archive_dest_2                        string     SERVICE=pdunq_dg  lgwr sync af

                                                         firm VALID_FOR=(ONLINE_LOGFILE

                                                         S,PRIMARY_ROLE) DB_UNIQUE_NAME

                                                         =ptext

.......

3,VALUE值有为空的情况,再查看archivelog list;检查一下归档目录和logsequence

SQL> archive log list;

Database log mode        Archive Mode

Automatic archival         Enabled

Archive destination       USE_DB_RECOVERY_FILE_DEST

Oldest online log sequence     192

Next log sequence to archive   194

Current log sequence             194

SQL>

 ----------------------------------------------------------------------------------------------------------------
<版权所有,文章允许转载,但必须以链接方式注明源地址,否则追究法律责任!>
原博客地址:  http://blog.csdn.net/mchdba/article/details/45725659
原作者:黄杉 (mchdba)
----------------------------------------------------------------------------------------------------------------

4. 检查flash recovery area的使用情况,可以看见archivelog的使用率很大,达到93.62%

SQL> select * fromV$FLASH_RECOVERY_AREA_USAGE;

FILE_TYPE   PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES

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

CONTROLFILE                 .13                        0               1

ONLINELOG                  2.93                        0               3

ARCHIVELOG                93.62                       0              141

BACKUPPIECE                   0                         0               0

IMAGECOPY                      0                         0               0

FLASHBACKLOG                0                         0               0

5. 计算flash recovery area已经占用的空间

SQL> selectsum(percent_space_used)*3/100 from v$flash_recovery_area_usage;

SUM(PERCENT_SPACE_USED)*3/100

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

                          2.9988

SQL>

6. 找到recovery目录, show parameterrecover

SQL> show parameter recover;

NAME                                        TYPE       VALUE

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

db_recovery_file_dest                   string     /oracle/app/oracle/flash_recovery_area

db_recovery_file_dest_size        big integer 22G

recovery_parallelism                      integer   0

SQL>

7 上述结果告诉我们,归档位置用的是默认值,放在flash_recovery_area下(db_recovery_file_dest目录=/oracle/app/oracle/flash_recovery_area)

进归档目录,删除一些归档日志,转移或清除对应的归档日志, 删除一些不用的日期目录的文件,注意保留最后几个文件(比如360以后的)

[oracle@powerlong4 ~]$ cd/oracle/app/oracle/flash_recovery_area

[oracle@powerlong4 flash_recovery_area]$

8,手动去/oracle/app/oracle/flash_recovery_area目录下删除归档日志文件

cd /oracle/app/oracle/flash_recovery_area/PDUNQ/archivelog

rm -rf 2015_01* 2015_02* 2015_03* 2015_04*2015_05_0*

---------------------------------------------------------------------------------------
注意: 
在删除归档日志后,必须用RMAN维护控制文件,否则空间显示仍然不释放。
---------------------------------------------------------------------------------------

9. 检查一些无用的archivelog

RMAN> crosscheck archivelog all;

返回:对归档日志的验证失败

10. 删除过期的归档

RMAN> delete expired archivelog all;

返回:RMAN-08137: 警告: 因为仍需要归档日志, 所以未删除

delete archivelog until time 'sysdate-1' ; 删除截止到前一天的所有archivelog

也报错

google打不开,只好baidu了下,说如果测试环境或者开发环境可以强行删除所有归档:

delete noprompt force archivelog all;

11,然后查看归档日志使用率,已经到了0.57%了,如下所示:

SQL> select * fromV$FLASH_RECOVERY_AREA_USAGE;

FILE_TYPE              PERCENT_SPACE_USEDPERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

CONTROL FILE                         0                             0

               0

REDO LOG                                 0                             0

               0

ARCHIVED LOG                              .57                     0

               3

FILE_TYPE              PERCENT_SPACE_USEDPERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

BACKUP PIECE                             20.86               20.82

               7

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.

SQL>

12,plsq可以正常登录了,alert后台日志也正常了。

plsq也可以登录了,一切OK了。归档满了,需要定时清理,一味的增大db_recovery_file_dest_size的值也不是长久得事情,磁盘总归是有限制的,oracle的归档日志和mysql的binlog一样,都可以强行清理掉,注意的时候如果是生产环境要注意备库的数据是否已经同步过去了,如果同步过去了,就可以强行删除归档日志释放空间,否则还是小心为上。

猜你喜欢

转载自blog.csdn.net/csdnhsh/article/details/94229557
今日推荐