Chinaunix首页 | 论坛 | 博客
  • 博客访问: 103119511
  • 博文数量: 19283
  • 博客积分: 9968
  • 博客等级: 上将
  • 技术积分: 196062
  • 用 户 组: 普通用户
  • 注册时间: 2007-02-07 14:28
文章分类

全部博文(19283)

文章存档

2011年(1)

2009年(125)

2008年(19094)

2007年(63)

分类: Oracle

2008-04-20 21:04:01

作者:       文章来源:   

 

  4、解决过程

  根据数据库目前可用存储空间为200GB、FLASH_RECOVERY_AREA空间为2GB的实际情况,把FLASH_RECOVERY_AREA的空间修改为20GB。

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20g;

系统已更改。

SQL> select * from v$recovery_file_dest;

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

NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

/oracle/flash_recovery_area 2.1475E+10 2264587776 0 38

  这时再查看日志的状态,发现REDO LOG处于正常的归档状态。

SQL> select * from v$log;

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

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

1 1 101 52428800 1 YES ACTIVE 3621973 24-7月 -06

2 1 102 52428800 1 NO CURRENT 3650399 25-7月 -06

3 1 100 52428800 1 YES INACTIVE 3611932 24-7月 -06

SQL> select * from v$flash_recovery_area_usage;

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES

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

CONTROLFILE 0 0 0

ONLINELOG 0 0 0

ARCHIVELOG 7.6 0 43

BACKUPPIECE 4.21 0 2

IMAGECOPY 0 0 0

FLASHBACKLOG 0 0 0

已选择6行。

SQL>

  5、小结

  造成本次故障的原因由两方面同时发生所造成的:

  ·其一是Flash_Recovery_Area空间缺省安装时比较小,只有2GB,容易用完;

  ·其二是由于采用归档方式通过Veritas备份,由于备份软件没有运行,造成归档日志没有及时删除。

  从本次故障解决处理中,我们可以得出经验教训:

  ·Oracle 10g数据库物理空间管理方式与以前Oracle发生了变化,对归档日志所在的Flash_Recovery_Area空间进行了另外限制;
 
  ·对数据库系统管理员要对Oracle数据库归档日志、备份软件运行状况定期检查,提前发现、处理可能发生的故障。
阅读(289) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~