1、oracle失败：
1.1语句失败：
比如超出空间的配额，用户在特定的表空间上所需要的空间超过了该用户在该表空间实际可用的最大表空间，比如执行如下语句：
create table temp(cola int,colb int) storage(minextents 4);
报错 ora-01536：超出表空间user01的空间限额。
为了解决这种错误，应该以dba的身份登录数据库，用alter user语句为用户分配更多的空间配额。然后 重新执行相应的语句：
alter user scott quota 100m on user01；
再比如表空间没有足够的空间，这个与上面的没有足够的空间配额不同，上面的是针对某个用户的，但这个是针对表空间的，出现这种错误的时候dba应该进行扩展表空间：
alter tablespace user01 add datafile ‘d：\demo\user01_2.dbf’ size 100m autoextend on next 10m;
1.2用户错误：
误删除表(drop table)：
使用import工具导入表结构及其数据，但这种方法可能会丢失部分数据。
使用基于时间点的数据库不完全恢复（DBPITR）这种方法可以确保不丢失任何表数据，但是可能会丢失其他表空间事务操作的数据，注意， DBPITR只适用于ARCHIVELOG模式。
使用基于时间点的表空间不完全恢复（TSPITR）这种方法不仅可以确保不丢失任何表数据，还能确保不丢失其他表空间事务操作的数据，注意，TSPITR只适用于ARCHIVELOG模式。
10g以后出现了FLASHBACK TABLE语句，其原理是在10g中删除表，其表的结构和数据不会被立即清除，而是被放在数据库回收站，如果表空间足够大，有可能表的内容永远都不会被清除。命令：flashback table emp to before drop;
误截断表（truncate table）：
当执行了truncate table后，会删除表的所有数据，但是会保留表的结构。恢复方法与drop table基本一样。但是注意，使用import导入的时候，表结构还是存在的所以加上参数：ignore=y；
dml误操作：
10g之后，使用flashback table语句可以讲表数据恢复到过去的时间点或者过去的scn，注意，如果要使用该特征，那么必须激活表的行移动特征，另外，flashback table 所能恢复的最早的时间受限于初始化参数db_flashback_retention_target..
示例：
首先执行：alter table emp enable row movement；
然后：update emp set sal=sal*1.1 where deptno=10;
然后：commit；
查询一下结果：select ename，sal from emp where deptno=10；显示已经将sal更改。
现在我们要闪回到某个时间点：flashback table emp to timestamp to_timestamp('2012-05-02 11:20:30','yyyy-mm-dd hh24:mi:ss');
再次查询结果：结果返回那一时间点对应的数据。
1.3用户进程失败：
出现用户进程失败不需要dba做任何操作，有专门的后台进程PMON检测被意外终止的用户进程，当检测到后，pmon会自动回退用户进程未完成的事务，并且释放用户进程在服务器端占用的资源和锁。
常见的用户进程失败如下：
1、用户执行了断开连接的操作，例如在sqlplus中按下了ctrl+break组合键，如果按下ctrl+c，那么在会话中会执行exit语句。
2、dba终止了用户进程，有可能是因为你的会话长时间不提交，影响别人的事务，所以dba给你终止了。
备份恢复方法：
*用户管理的备份与恢复——操作系统备份（cp，copy等）
*rman（recovery manager）备份。
*逻辑备份与恢复——使用expdp，impdp数据泵导入导出工具或者exp，imp工具。exp，imp是客户端的工具程序，他们既可以在客户端使用，也可以在服务器端使用，expdp，impdp是服务器端的工具程序，他们只能在oracle服务器端使用，不能在oracle客户端使用。
2、truncate 操作与drop 操作的异同
以下内容为转载
有人认为：truncate = drop + create。。。
但是有跟帖：
truncate 和drop 有本质的区别，并不是 truncate=drop+create
我之前也是认为说 drop 只要删除数据字典表就好了，并不会修改数据本身所处的 段头 数据，这一点通过将 数据所在的 tablespace 设成 read only ，还能 drop掉表也能得到验证，但是请看下面一句话
the drop will first convert the segment to a temporary segment, and only then start cleaning up the now temporary segment's extents. Thus, if the drop is interrupted, the temporary segment will now be cleaned up by SMON.（drop操作首先把要删除的数据对象所在的段转换成临时段，只有这样才能开始清除这个临时段的数据扩展。所以如果drop被打断，临时段会被SMON进程清除）
这里的转换过程网友说是一个标志位的更改，可以在dba_segments视图中看到。
今天在Itpub看到一个讨论大表的truncate与drop操作的帖子, 下面是我对其的回复.
1. drop 与 Truncate操作类似的地方.
drop 是直接处理数据字典,去掉object与其对应的data_object_id的对应关系..
truncate 操作是创建一个新的空的segment(对应于data object id), 并将此segment与现有对象关联起来.
2. drop 与 truncate 操作都会触发object checkpoint操作, 如果buffer Cache很大的话, 这两个操作都可能会出现较长时间的等待, 在Oracle 10gR2以后, Oracle对Buffer header做了些许变更, 以提高Fast Object Checkpoint的速度.
1 |
Re: |
3. 对于drop 与 Truncate 操作还涉及另外一块事情: 空间的回收：
对于使用Local Management的tablespace（本地管理的表空间） ,需要修改这个segment 涉及到的所有数据文件的bitmap 内容的修改.. 一般情况下, 速度都还可以..
如果是基于字典管理的表空间.. 由于所有的回收操作都是基于uet$,fet$表操作的,,所有如果使用的空间量非常大, 回收的操作将非常慢,,我曾听说,,有人删除一个表要等待好几个小时甚至1-2天的情况..
解决办法是:
1 |
truncate table xxx |
2 |
alter table xxx deallocate unused |
3 |
alter table xxx deallocate unused |