oracle数据库回滚

Ⅰ oracle数据库中数据回滚的概念

commit-提交
rollback-回滚，即撤销对数据的改动，不保存到数据库

Ⅱ oracle 提交数据，怎么回滚

execute执行后 可以回滚

commit提交后 不可以回滚

其实Oracle提交数据是分两步操作的，第一步execute执行，第二步commit提交。对应的PL\sql也是要先点execute执行，执行后再点commit提交。
但是 commit提交后 可以用闪回查询恢复原来的数据 因为oracle会将近期的数据保存到快照中 如:

SELECT * FROM TABLE_1 AS OF TIMESTAMP TO_TIMESTAMP('20080606 20:00:00','YYYYMMDD HH24:MI:SS');
这里'20080606 20:00:00'就是你想恢复数据到哪个时间状态 TABLE_1是数据库的表名 这样查询到的数据就是执行更新操作之前的数据

Ⅲ oracle数据库引起自动回滚的原因

比如说你的事务未提交进程意外终止（
掉线
啊，点击
叉叉
退出连接啊）未提交的数据全部
回滚
。或者在你的事务提交过程中，数据违反约束条件，事务内部出现错误被终止，则该事务中所有操作也被自动回滚。还有其他一些情况，这两个是主要的。

Ⅳ oracle 删除数据提交怎么回滚

execute执行后
可以回滚
commit提交后
不可以回滚
其实oracle提交数据是分两步操作的，第一步execute执行，第二步commit提交。对应的pl\sql也是要先点execute执行，执行后再点commit提交。
但是
commit提交后
可以用闪回查询恢复原来的数据
因为oracle会将近期的数据保存到快照中
如:
select
*
from
table_1
as
of
timestamp
to_timestamp('20080606
20:00:00','yyyymmdd
hh24:mi:ss');
这里'20080606
20:00:00'就是你想恢复数据到哪个时间状态
table_1是数据库的表名
这样查询到的数据就是执行更新操作之前的数据

Ⅳ oracle 提交之后怎么回滚

execute执行后
可以回滚
commit提交后
不可以回滚
其实Oracle提交数据是分两步操作的，第一步execute执行，第二步commit提交。对应的PL\SQL也是要先点execute执行，执行后再点commit提交。
但是
commit提交后
可以用闪回查询恢复原来的数据
因为oracle会将近期的数据保存到快照中
如:
SELECT
*
FROM
TABLE_1
AS
OF
TIMESTAMP
TO_TIMESTAMP('20080606
20:00:00','YYYYMMDD
HH24:MI:SS');
这里'20080606
20:00:00'就是你想恢复数据到哪个时间状态
TABLE_1是数据库的表名
这样查询到的数据就是执行更新操作之前的数据

Ⅵ oracle中数据是怎样前滚和回滚的

保持数据一致性和完整性，是每一款成功商业数据库软件都必须要做到的基本要求。从故障中恢复，保证ACID原则，保证事务完整性，一直是Oracle数据库核心功能组成部分。本篇主要介绍Oracle实例意外终止（断电或者强制关闭）之后，重新启动时发生的恢复过程，也可以称作“前滚和回滚”。
基础知识说明
为了更明确的说明问题，笔者首先介绍一下本文涉及到的一些重要知识。
数据库实例失败
我们经常说的数据库服务器failure是有多层含义的。Oracle数据库是一个由多进程组件共同构成的结构体系。最重要的部分包括监听器、Oracle数据库实例两个部分，当然还包括各类文件，更广义的还有硬件和操作系统OS。不同部分的Failure现象和处理方法都有所不同。本文所阐述的过程是Oracle实例失败后的自动恢复过程。
在实例失败的时候，往往是突然性的终止。此时Oracle数据库可能在进行一系列完成或者未完成的事务。实例失败恢复，就是要将这些状态进行还原，恢复到数据完整性的状态。
写日志（RedoLog）在先机制
Oracle数据库是采用“日志在先”机制的。当我们对数据库数据进行修改时，并不是立即将修改写入到文件中，而是写入到共享内存SGA空间中的BufferCache里。同时，将修改的日志不断的写入到SGA中另一块Log Buffer缓存中。有一个后台进程LGWR不断的将LogBuffer缓存中的日志内容写入到online redo log文件中。
写入LogBuffer缓存和LGWR写入文件的过程是异步进行的。那么LGWR会在哪些情况下将日志缓冲区(全部内容)转储到日志文件呢？如下：--参考OCA认证考试指南(1Z0-052,P40)ü 用户进行直接的commit操作；
ü RedoBuffer数据超过1/3；
ü DBWn启动，将BufferCache中的脏数据写入到文件中；ü 距离上次LGWR写入操作超过三秒(三秒超时，DBWn每三秒钟会对一些缓冲区清理一次，这个时候，刚好符合触发LGWR的第三点)；而数据文件写入进程DBWn工作的触发点(此处注意：DBWn会将高速缓冲区的脏缓冲区,即脏数据块写入数据文件，而不是缓冲区里头的全部内容---参考OCA认证考试指南(1Z0-052,P38))。
因为考虑到磁盘I/O会降低性能，DBWn采用的是极懒算法执行写入。如果对于经常变脏的缓冲区，即这边缓冲区处于十分忙碌的状态，那么DBWn不会将缓冲区写入磁盘的。反而一段时间来，任何会话都未曾关注的一些缓冲区，DBWn会将其写入到磁盘。因此DBWn写脏缓冲区比较平缓和低频率。但如果出现检查点的情况例外：DBWn会将所有脏缓冲区全部写入磁盘。---参考OCA认证考试指南(1Z0-052,P38中，P39)。
ü 当BufferCache中没有任何可用缓冲区；ü 脏缓冲区过多；
ü 遇到三秒超时(DBWn每三秒钟会对一些缓冲区清理一次)ü 遇到检查点
综合DBWn和LGWR工作的特点，我们可以得到日志文件的几个特点：
首先，日志文件的写入是很频繁的。LGWR会不断将日志信息从LogBuffer中写入Online Redo Log；其次，在日志文件上，可以有三个类型的事务事件。
1、事务结束，已经被commit，之后打过checkpoint检查点。这种事务记录在LogFile上，但是变化信息已经被DBWn写入进数据文件；2、事务结束，已经被commit，之后没有打入checkpint检查点。这种情况下，LogFile已经写入了日志项目，数据文件可能包括脏数据，也可能没有写入脏数据；3、事务未结束，没有commit。这种时候，数据块DirtyBlock上面是有事务槽信息，表示未结束事务，是不会将数据写入到数据文件中。但是，日志LogBuffer可能将部分未提交的DML操作项目写入到Log File中；检查点Checkpoint
检查点Checkpoint是数据库一致性检查的一个标记。简单的说，就是在这个点上，Oracle保证各个文件（数据、控制、日志等）是一致的。检查点的作用就是在进行实例恢复的时候，告诉SMON进程，这个点之前的内容不需要进行恢复。
前滚和回滚介绍
“前滚和回滚”是Oracle数据库实例发生意外崩溃，重新启动的时候，由SMON进行的自动恢复过程。下面通过模拟实例和讲解介绍这个过程。
失败前场景说明
日志中记录过程如下：
1、事务A进行之后，结束commit。之后系统进行了一次checkpointA；2、Checkpoint之后，进行事务B，结束commit；3、进行事务C，C事务量较大，其中进行了一定量的RedoLog文件写入。之后系统断电；--按照LGWR的工作机制，C事务量比较大，所以应用程序将在几分之一秒内的时间里生成足以填充1/3秒的重做内容，因此这会触发LGWR将日志缓冲区的内容转储到日志文件，但始终得不到针对C事务的提交记录，这是需要回滚的。
4、还有种可能，事务B和D，事务D所用的缓冲区处于高速缓冲区不活跃的位置，而且事务B已提交，但其所用的缓冲区处于高速缓冲区活跃的位置。因此DBWn会将D事务缓冲区数据写入数据文件，而没将B事务的数据写入。此种情况需要回滚D事务，保留B事务。---参考OCP认证考试指南全册（P358下半部分内容).
1、系统启动过程，进入实例恢复阶段
当实例意外中断的时候，各类型文件，包括控制文件、数据文件和日志文件上，会存在不一致的问题。这种不一致主要体现在SCN值的差异上。
实例在启动的时候，经过三阶段（nomount、mount和open）。在open之前，会进行这种不一致现象的检查，如果出现不一致，要启动SMON进程的恢复流程。
SMON是Oracle实例的一个后台进程，主要负责进行系统监控恢复。进行恢复的依据主要是RedoLog记录。
2、前滚进程
SMON首先找到最后SCN记录的Redo LogFile。寻找最后一个打入的Checkpoint。
顺序找到CheckPointA之后，表示A之前的所有事务都是完全写入到数据文件中，不存在不一致性问题。恢复过程从CheckpointA开始，Oracle开始依据重做日志Redo Log的系列条目，进行推进。
首先遇到了事务B信息，由于事务B已经commit，所以事务B所有相关的Redo Log条目已经全都写入到Redo LogFile中。所以，按照日志继续条目推进，完全可以重演replay，并且应用apply事务B的全部过程。
这样，事务B全部实现，最终将通过DBWn完全写入到数据文件中。所以，实例失败之前提交commit的事务B，完全恢复。
进入事务C的范畴，由于一部分事务C的RedoLog条目已经进入Redo LogFile中(根据LGWR和DBWn的工作机制，事务C有可能将部分数据块写入日志文件和数据文件，但这时候C事务始终没提交，这是比较严重的讹误，所以需要回滚)，所以在进行前滚的时候，一定会replay到这部分的内容。不过，这部分内容中不可能出现commit的标记。所以，前滚的结果一定是遇到实例突然中断的那个时点。此时replay的结果是，事务C没有提交。这样结束了前滚过程，进入回滚阶段。
3、回滚过程(与普通的回滚一样（当事务执行失败后自动回滚或者命令:ROLLBACK.）---参考OCP认证考试指南全册)对事务C(针对DML的update，当然其他同理)，要进行回滚过程，释放所有相关资源。在前滚中，利用日志填充了的撤销块和表数据块的值，然后在回滚的时候，会将撤销块的值复制回表数据块中(因为此事务没提交记录)，以此来进行SGA中BufferCache数据块恢复。
4、说说恢复过程的损耗
很多时候，由于我们事务规模较大，当出现实例崩溃的时候，重启所需要的时间很多。有一种经验说法是，事务有多长，前滚和回滚所消耗的时间有多长×2。而且，如果不能完成SMON恢复过程，数据库是不能算作正常的Open的。
SMON的恢复过程是Oracle强制进行的一个过程，即使恢复中发生断电或者其他中断失败事件。Oracle在下一次启动的时候，还是会继续这个过程，只有耐心等待。
通过检查一些内部视图（X$视图），可以观察到恢复进程和速度，但是丝毫不能影响到最终恢复的过程。
这个过程虽然可以保证数据一致性，但是也带来了系统不能启动，影响生产环境的问题。我们可以通过两个方式进行缓解：
首先，我们在设计开发系统时，要保证事务规模的可控性，不要让事务规模在技术层面上过大。避免一旦发生崩溃，大规模强制回滚的发生；其次，一旦出现了这个强制回滚，要注意对生产环境的影响。可以采用备库standby进行顶替，让主库安静的慢慢恢复；

Ⅶ Oracle数据库中为什么会产生回滚与前退

在一个transaction发生的过程中，online redo log首先记录transaction中修改的数据块相关信息，修改的数据块会被缓存在database buffer cache中。由于database buffer cache写满或者checkpoint等等条件触发dbwn进程，会导致这些缓存的数据块写入数据文件，但此时可能该transaction仍然还没有提交。所以在数据文件中，可能会有commited 和 uncommited 的数据块。而原有的数据块镜像会存放在undo segment。 IXDBA.NET社区论坛 然而，dbwn写脏数据时不管这个要写的transaction是否提交， 也没有必要去管。 这样就发生了所谓的已经提交的数据，但是还没有写入数据文件的现象。 还有一种情况，数据没有提交，但是已经被写入数据文件，此时发生回退，撤销没有提交的数据。 根本原因是commit后写redo buffer和触发lgwr写 redo buffer的区别。 事务在执行完毕后，随即会被写入redo buffer和undo中，同时在redo buffer和undo中对该事务都有一个是否提交的标记。两者的默认状态都是active的，即没有提交时刻处于激活状态。 commit操作执行时刻把此前的所有事务操作全部写入redo log file，commit成功后，redo buffer信息全部写入redo file，同时修改两者中的事务提交标识为inactive，表示此前事务已经递交。 oracle的前滚和回退根据就是依据事务是否提交而进行的。 在触发lgwr进程后，oracle同样把此前的redo buffer信息写入redo file，但是与commit触发写日志不同的是，redo file本身对lgwr写日志操作不记录任何信息标识，lgwr写到那里就是那里，就算此时掉电也无妨，redo file就记录到掉电时刻的信息。 lgwr是一个Oracle后台执行的进程，具体的日志写操作都有oracle去控制，这对于oracle来说是透明的，因此不用在redo file中写入任何标记信息，这也是正常的。 于是，Oracle崩溃恢复步骤如下： 首先rolling forward 前滚：由于oracle failure，sga中的内存信息丢失了，但是online redo log中还是存储了transaction信息，包括commited or uncommited data。可能这些修改信息并没有被oracle正确的来处理，包含两种情况：已经提交的还没有写入数据文件，或者没有提交的却被写入了数据文件。针对已经提交的还没有写入数据文件就要发生前滚，在前滚过程中，smon会根据online redo log中的记录来完成对datafile的修改。保证已经提交的数据已经写入数据文件。 接下来，前滚结束后，数据库正常open，此时用户可以正常连接，可以访问已经recover的commited data，但是对于那些属于unrecoverable transaction的uncommited data，会被oracle 加锁，是不可以访问的。

Ⅷ oracle数据库回滚

开没开归档，如果没开市回滚不了的

Ⅸ oracle数据库库删除怎么回滚

删除表后，可以采用如下操作：
在 user_recyclebin中找到最近操作过的表名称，然后用闪回（只能用于10G及以上版本）。
FLASH BACK TABLE TABLE_NAME TO BEFORE DROP;
如果是删了或修改里面的数据，可以先建立一个快表将删除修改之前状态的数据找回到这个表中：
CREATE TABLE QUICK_TABLE AS
SELECT * FROM TABLE_NAME AS OF TIMESTAMP SYSTEM-1/24 (一小时前的)，减去的时间可以自己定。如楼上F_253那位老兄的写法就不错，能自由定制时间