记一次导库归档撑爆不负责任的做法

测试导数据验证一个其它问题，但是突然导入的时候一直卡主了。然后一看日志发现原来impdp导入过程中产生大量归档日志，存储归档的空间满了所以才卡住了

10年的肇东网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。营销型网站建设的优势是能够根据用户设备显示端的尺寸不同，自动调整肇东建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联公司从事“肇东网站设计”,“肇东网站推广”以来，每个客户项目都认真落实执行。

tail /u01/app/oracle/diag/rdbms/zhanky/zhanky/trace/alert_zhanky.log（主要报错如下）

[root@source ~]# tail /u01/app/oracle/diag/rdbms/zhanky/zhanky/trace/alert_zhanky.log 
....
************************************************************************
ARC3: Error 19809 Creating archive log file to '/u01/app/oracle/fast_recovery_area/ZHANKY/archivelog/2019_05_07/o1_mf_1_100_%u_.arc'
Errors in file /u01/app/oracle/diag/rdbms/zhanky/zhanky/trace/zhanky_arc0_2423.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 4385144832 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from 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 as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
...

因为是测试环境所以只是开启了归档其它啥都没设置，于是就默认存放位置载db_recovery_file_dest_size 下，默认也是4G大小。

其实解决方法也简单，只不过想起来好久没写博客所以记录一下。主要归档满了，我们可以通过设置限制的大小或者删除归档日志来解决。但是因为我这边测试空间不多所以采用第二种方法删除归档日志。

先新开一个终端，rman target /  运行以下命令。

[oracle@source ~]$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Tue May 7 20:48:26 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ZHANKY (DBID=2622149390)

RMAN> 
RMAN> delete archivelog all; 

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1163 device type=DISK
List of Archived Log Copies for database with db_unique_name ZHANKY
=====================================================================

Key     Thrd Seq     S Low Time 
------- ---- ------- - ---------
97      1    100     A 07-MAY-19
.
.
.
.
        Name: /u01/app/oracle/fast_recovery_area/ZHANKY/archivelog/2019_05_07/o1_mf_1_100_gf3079ns_.arc
140     1    144     A 07-MAY-19
        Name: /u01/app/oracle/fast_recovery_area/ZHANKY/archivelog/2019_05_07/o1_mf_1_144_gf30osyo_.arc
Do you really want to delete the above objects (enter YES or NO)? yes
deleted archived log
archived log file name=/u01/app/oracle/fast_recovery_area/ZHANKY/archivelog/2019_05_07/o1_mf_1_100_gf3079ns_.arc RECID=97 STAMP=1007672299
deleted archived log
.
.
.
.
archived log file name=/u01/app/oracle/fast_recovery_area/ZHANKY/archivelog/2019_05_07/o1_mf_1_144_gf30osyo_.arc RECID=140 STAMP=1007672763
Deleted 45 objects


RMAN> exit

后面在开就恢复正常了

[root@source ~]# tail /u01/app/oracle/diag/rdbms/zhanky/zhanky/trace/alert_zhanky.log 
Archived Log entry 139 added for thread 1 sequence 143 ID 0x9c4b270e dest 1:
Thread 1 advanced to log sequence 145 (LGWR switch)
  Current log# 1 seq# 145 mem# 0: /u01/app/oracle/oradata/zhanky/redo01.log
Tue May 07 21:06:03 2019
Archived Log entry 140 added for thread 1 sequence 144 ID 0x9c4b270e dest 1:
Tue May 07 21:06:12 2019
Thread 1 advanced to log sequence 146 (LGWR switch)
  Current log# 2 seq# 146 mem# 0: /u01/app/oracle/oradata/zhanky/redo02.log
Tue May 07 21:06:13 2019
Archived Log entry 141 added for thread 1 sequence 145 ID 0x9c4b270e dest 1:

本文题目：记一次导库归档撑爆不负责任的做法
标题路径：https://www.cdcxhl.com/article22/gooejc.html

成都网站建设公司_创新互联，为您提供Google、标签优化、企业网站制作、网站制作、关键词优化、网站收录

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联