首先是关闭数据库:以SYS身份链接到oracle,执行>shutdown immediate
启动数据库到mount状态:>startup mount
查看回闪恢复区的大小和存放目标:>show parameter db_recovery_file_dest
修改回闪恢复区的大小>alter system set db_recovery_file_dest_size = 4G(缺省是2G,可以根据实际情况调整大小)
最后打开数据库:>alter database openOK , 问题解决。数据库恢复使用。方法二 :进入oracle清空日志信息,把空间释放出来启动数据库到mount状态: >sqlplus “/as sysdba”>startup mount新起一个终端,用rman进入把归档日志删除命令>rman target/ (只安装了一个oracle10g数据库)命令>crosscheck archivelog all(列出归档日志信息)命令>delete expired archivelog all(将上述列出的归档日志删除)命令>exit此时最好将数据库重新备份一下把数据库的mount状态更改为open状态>alter database openOK.问题解决,数据库可以使用。 误区: 在系统清空归档目录的日志信息(即物理删除归档日志,或将归档日志转移至别处)不可取,OS虽然删除了,但oracle系统识别不出来已经清空日志,只能进入oracle清空日志信息,把空间释放出来,(方法二);或者是把归档空间设置更大(方法一)。 建议将两种方法结合使用,减少工作量,也避免数据库频繁挂起。同时定时进行数据库完全备份或其他重要数据备份
先查出当前数据库使用的归档目录是在哪,这个我昨天回答过一个问题。http://zhidao.baidu.com/question/416031451
你可以参考一下。
然后,便可以到 *** 作系统上,看归档目录所在的文件系统使用情况,如
一般的
unix
上,df
-g
以
GB
为单位看,linux
上,
df
-h,
为以
GB
为单位看。
如果文件系统空间使用率达
90%
了,那就是快满了。
可以通过备份至磁带,再删除的方式进行。
如果是设置了
db_recovery_file_dest
及
db_recovery_file_dest_size
参数启用了
flash
recovery
area
后,
可能会由于该区域满而导致无法归档.
由于对
flash
recovery
area
的信息是记录于
rman
repository
及控制文件中的,
因而,
仅是从磁盘删除旧的备份或是归档日志并不足够,
因为rman
repository
及控制文件中仍持有该空间被使用的信息.
因而,
可增大
db_recovery_file_dest_size
的值,
或是从rman
中执行crosscheck
archivelog
all
来标记相关归档日志已被删除,
再执行rman
delete
expired
archivelog
all
来删除其记录.
最好的方式为rman
backup
archivelog
until
logseq
delete
all
input
这样一则进行了备份,
二则也删除了flash
recovery
area
中的空间,
并更新了控制文件.
同时,可使用
select
*
from
v$RECOVERY_FILE_DEST
来了解
recovery
area
中允许的最大空间,已用的空间,可以被数据库自动回收的空间。
并进而使用
select
file_type,
PERCENT_SPACE_USED
,
PERCENT_SPACE_RECLAIMABLE,
NUMBER_OF_FILES
from
v$RECOVERY_AREA_USAGE
来了解
recovery
area
中各类文件所占用的空间百分比。
如果
recovery
area
是放在
asm
的
diskgroup
中的,还需要注意
相应的
diskgroup
中是否仍有空间。
可
11g
的
asm,
可在 *** 作系统命令行,执行
asmcmd
进入命令行后
lsdg
命令,来查看
diskgroup
的总空间及剩余空间量。
如果不想加硬盘的话,那么只能删除日志,可以根据时间删除老日志(如果有带库的话,也可以将老日志转移到带库上,然后再删除存储上的老日志)。删除归档日志有一套程序的。可不是直接删除了就行,那套程序网上很多,我就不多写了。归档日志占满硬盘,还不敢或者不能删除(万一宕机了,没有备分怎么恢复),多数是备分策略有一点问题,可以重新讨论备分策略(主要是备分方式和备分级别),让备分占用的空间相对稳定下来的。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)