查询回滚事务的用户 oracle
看能不能查到你所需要的信息：包括sql语句,用户名,机器名等
execute执行后
可以回滚
commit提交后
不可以回滚
其实Oracle提交数据是分两步操作的,第一步execute执行,第二步commit提交.对应的PL\SQL也是要先点execute执行,执行后再点commit提交.
但是
可以用闪回查询恢复原来的数据
因为oracle会将近期的数据保存到快照中
如:
SELECT
*
FROM
TABLE_1
AS
OF
TIMESTAMP
TABLE_1是数据库的表名
这样查询到的数据就是执行更新操作之前的数据
保持数据一致性和完整性,是每一款成功商业数据库软件都必须要做到的基本要求.从故障中恢复,保证ACID原则,保证事务完整性,一直是Oracle数据库核心功能组成部分.本篇主要介绍Oracle实例意外终止（断电或者强制关闭）之后,重新启动时发生的恢复过程,也可以称作"前滚和回滚".
基础知识说明
为了更明确的说明问题,笔者首先介绍一下本文涉及到的一些重要知识.
数据库实例失败
我们经常说的数据库服务器failure是有多层含义的.Oracle数据库是一个由多进程组件共同构成的结构体系.最重要的部分包括监听器、Oracle数据库实例两个部分,当然还包括各类文件,更广义的还有硬件和操作系统OS.不同部分的Failure现象和处理方法都有所不同.本文所阐述的过程是Oracle实例失败后的自动恢复过程.
在实例失败的时候,往往是突然性的终止.此时Oracle数据库可能在进行一系列完成或者未完成的事务.实例失败恢复,就是要将这些状态进行还原,恢复到数据完整性的状态.
写日志（RedoLog）在先机制
Oracle数据库是采用"日志在先"机制的.当我们对数据库数据进行修改时,并不是立即将修改写入到文件中,而是写入到共享内存SGA空间中的BufferCache里.同时,将修改的日志不断的写入到SGA中另一块Log Buffer缓存中.有一个后台进程LGWR不断的将LogBuffer缓存中的日志内容写入到online redo log文件中.
ù 当BufferCache中没有任何可用缓冲区；ù 脏缓冲区过多；
ù 遇到三秒超时(DBWn每三秒钟会对一些缓冲区清理一次)ù 遇到检查点
综合DBWn和LGWR工作的特点,我们可以得到日志文件的几个特点：
首先,日志文件的写入是很频繁的.LGWR会不断将日志信息从LogBuffer中写入Online Redo Log；其次,在日志文件上,可以有三个类型的事务事件.
检查点Checkpoint是数据库一致性检查的一个标记.简单的说,就是在这个点上,Oracle保证各个文件（数据、控制、日志等）是一致的.检查点的作用就是在进行实例恢复的时候,告诉SMON进程,这个点之前的内容不需要进行恢复.
前滚和回滚介绍
"前滚和回滚"是Oracle数据库实例发生意外崩溃,重新启动的时候,由SMON进行的自动恢复过程.下面通过模拟实例和讲解介绍这个过程.
失败前场景说明
日志中记录过程如下：
①.、系统启动过程,进入实例恢复阶段
当实例意外中断的时候,各类型文件,包括控制文件、数据文件和日志文件上,会存在不一致的问题.这种不一致主要体现在SCN值的差异上.
实例在启动的时候,经过三阶段（nomount、mount和open）.在open之前,会进行这种不一致现象的检查,如果出现不一致,要启动SMON进程的恢复流程.
SMON是Oracle实例的一个后台进程,主要负责进行系统监控恢复.进行恢复的依据主要是RedoLog记录.
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没有提交.这样结束了前滚过程,进入回滚阶段.
SMON的恢复过程是Oracle强制进行的一个过程,即使恢复中发生断电或者其他中断失败事件.Oracle在下一次启动的时候,还是会继续这个过程,只有耐心等待.
通过检查一些内部视图（X$视图）,可以观察到恢复进程和速度,但是丝毫不能影响到最终恢复的过程.
这个过程虽然可以保证数据一致性,但是也带来了系统不能启动,影响生产环境的问题.我们可以通过两个方式进行缓解：
首先,我们在设计开发系统时,要保证事务规模的可控性,不要让事务规模在技术层面上过大.避免一旦发生崩溃,大规模强制回滚的发生；其次,一旦出现了这个强制回滚,要注意对生产环境的影响.可以采用备库standby进行顶替,让主库安静的慢慢恢复；
如果执行了数据库恢复操作,日志序列号会归零.你可以这样查
select * from v$log;
看sequence#这一列.
至于回滚不容易看吧,那是事务级别的.
其实oracle提交数据是分两步操作的,第一步execute执行,第二步commit提交.对应的pl\sql也是要先点execute执行,执行后再点commit提交.
select
from
table_1
as
of
timestamp
table_1是数据库的表名
以上就是土嘎嘎小编为大家整理的oracle怎么看回滚相关主题介绍,如果您觉得小编更新的文章只要能对粉丝们有用,就是我们最大的鼓励和动力,不要忘记讲本站分享给您身边的朋友哦！！