还有你的数据库是不是有完整的备份以及归档模式!
如果没有备份以及归档,就看看能不能从 *** 作系统层面恢复文件!
如果不能的话,肯定要丢失了这个DBF文件的数据了!
可以强拉数据库启动使用~
首先,undo表空间满是正常的,oracle自然会重用或者扩展它,一般不用管它。然后,现在要解决的话,需要先把undo
tablespace设置成手动,启动数据库,创建新的undo
tablespace。把新的设置成默认的。
假设你的库现在是mounted状态
1
创建PFILE(如果已有就是更新)
SQL>create
pfile
from
spfile
2
关闭数据库
SQL>shutdown
immediate
3
在你的$ORACLE_HOME/dbs目录下面找个叫做
init<数据库>.ora的文件,把其中有undo_management=AUTO的一行改成
undo_management=MANUAL
如果没有就在文件末尾填一行
4
以sysdba身份连接数据库
SQL>connect
"/
as
sysdba"
用刚才改过的文件启动数据库
SQL>
startup
pfile=<刚才的文件全路径和名字>
这步是最关键的,如果成功,后面就没问题了
5
drop掉原来的表空间
SQL>
drop
tablespace
<原来的undo表空间名字>
including
contents
6
创建新的undo表空间
SQL>
create
UNDO
tablespace
undotbs2
datafile
'/u01/app/oracle/oradata/orcl/undotbs02.dbf'
size
100M
autoextend
on
7
关闭数据库,
SQL>shutdown
immediate
在开始那个init文件里设置UNDO_MANAGEMENT=AUTO
和
UNDO_TABLESPACE=UNDOTBS2
8
再做一次第四步
9
更新spfile
SQL>create
spfile
from
pfile
10
关闭数据库,正常重新启动
SQL>shutdown
immediate
SQL>startup
11
去网上教你删undo那个地方骂它。非常想当然的做法。没有任何理由这么做
12
让你的工程师去学oracle
培训
以上步骤的中的第5步可能会出问题。我不确认。。。
但是即使第5步不成功,问题应该也不大
1. NOARCHIVELOG模式如果在NOARCHIVELOG模式下丢失数据库中的任何数据文件,则需要完全恢复数据库,包括控制文件和所有数据文件。
如果数据库处于NOARCHIVELOG模式,则只能在最后一次备份之前恢复。因此,用户必须重新输入自备份以来所做的所有更改。
使用Enterprise Manager Cloud Control来执行这种类型的恢复:
如果还没有关闭实例,则关闭它。
选择可用性>备份和恢复>执行恢复。
选择整个数据库作为恢复类型。
如果有一个处于NOARCHIVELOG模式、具有增量备份策略的数据库,则RMAN首先还原最近的0级,然后RMAN恢复应用增量备份
2. ARCHIVELOG模式
如果数据库处于ARCHIVELOG模式,那么丢失不属于系统或UNDO表空间的任何数据文件只会影响丢失文件中的对象。数据库的其余部分仍然可供用户继续工作。
3. 关键文件损坏
属于系统表空间或包含撤消数据的数据文件被认为是系统关键文件。丢失其中一个文件需要从挂载状态恢复数据库(不像其他数据文件可以在数据库打开时恢复)。
使用Enterprise Manager Cloud Control执行此恢复:
如果实例还没有关闭,请关闭它。
挂载数据库。
选择可用性>备份和恢复>执行恢复。
在用户定向恢复部分,在恢复范围菜单中选择Datafiles,然后选择“恢复到当前时间”。
单击“添加”以选择需要恢复的所有数据文件。
指定是否要将文件恢复到默认位置,或者(如果缺少磁盘或控制器)恢复到新位置。
提交RMAN作业以恢复和恢复丢失的文件。
打开数据库。恢复到最后一次提交时为止。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)