oracle 误操作 数据丢失找回

1、查询可以恢复的时间点

select * from V$SQL where SQL_TEXT like ‘%update MAP_OPTCBL_POINT_70 set shape%‘

2、数据恢复到新建的表,根据时间戳

create table newTable as select * from oldTable as of timestamp to_timestamp(‘2015-10-11‘,‘yyyy-mm-dd‘);

3、结果集导出到Excel,使用Excel函数生成你需要的sql

 =CONCATENATE("update oldTable t set t.dicname=‘"&F2&"‘ where t.id="&B2&";")

4、执行得到的sql

5、删除新建的表

时间: 2024-08-10 23:18:40

oracle 误操作 数据丢失找回的相关文章

oracle误操作commit之后,可以闪回数据

1. 授予行迁移权限 alter table table_name enable row movement; 2. 到15分钟前: flashback table order   to timestamp systimestamp - interval '15' minute; 到某个时间点: FLASHBACK TABLE order TO TIMESTAMP    TO_TIMESTAMP('2017-06-12 01:15:25 PM','YYYY-MM-DD HH:MI:SS AM')

Oracle数据库常见的误操作恢复方法(上)

实验环境:Linux6.4 + Oracle 11g 面向读者:Oracle开发维护人员 本文以Oracle自带的scott用户进行演示: 首先逻辑备份导出scott的对象数据 $ exp scott/tiger file='/u01/app/backup/scott.dmp' log='/u01/app/backup/scott.log' owner=scott; 1.误操作drop了emp表 利用表级闪回恢复,只要回收站中有就可以恢复. SQL> drop table emp; Table

通过案例学Oracle之--一次AIX rac误操作引起的血案

系统环境: 操作系统: AIX 5300-09 集群软件: CRS 10.2.0.1 数据库:   Oracle 10.2.0.1 本案例是用于基于VG Concurrent 的共享存储,通过HACMP 实现卷组的并发 案例分析: 一.错误现象: 1.Oracle 用户无法访问设备文件 2.CRS  server启动失败 [[email protected] ~]$ls -l /dev /dev/__vg10: No permission /dev/audit: No permission /d

当数据被误删除/误操作后造成数据丢失。你尝试过用什么手段来挽救数据/损失?

一.前提 当数据被误删除/误操作后,第一时间要关闭数据库.业务方需要紧急挂停机公告,避免数据二次污染,用于保护数据的一致性 BINLOG格式为ROW格式,不讨论其他格式的BINLOG 二.数据被误操作(update/delete/drop)造成数据丢失,可以用哪些手段来恢复? BINLOG恢复:可以使用逆向解析BINLOG工具来恢复.例如:binlog2SQL等 延迟从库: 可以通过解除延迟从库,并指定BINLOG结束位置点,可以实现数据恢复 三.数据被误删除(rm/物理文件损坏)造成数据丢失,

oracle 如何查询过去某个时间点的记录(应用于某个时间点的误操作,回滚到之前的操作)

这个功能是在自己误操作,将某些数据更改错了,你想恢复更改错之前的数据,这个时候你可以使用这种方式 不过建议要小心更改数据,如果实在有必要去更新,请先备份数据表,不到万不得以才可以这么做. SELECT * FROM Aselect * from a as of timestamp to_timestamp('2016-6-22 16:35:00','yyyy-mm-dd hh24:mi:ss'); <该语句是查询2016-6-22 16:35:00' 这个时间点之前的数据,如果你需要这个时间点的

请列出你在从事IT生涯中,最难以忘怀的一次误操作

IT系统最怕什么,我觉得就两点: 1.不可靠的软硬件. 2.误操作. 第一点就不用解释了,第二点是该文的内容,主要摘选自ITPUB的精华贴——[精华] 请列出你在从事DBA生涯中,最难以忘怀的一次误操作 中摘录各位网友的经验和教训,常看看以警惕自己. #2 一次一个session占用内存很大,这个session id比较大,所以以为是用户进程,kill, 则库立刻down了,查日志后,才知道是一个后台进程,但详细是哪个进程,现在忘记了. 好的是库起来了,这个故障,我一直牢记于心. 现在做任何操作

SQLServer 2008以上误操作数据库恢复方法——日志尾部备份

问题: 经常看到有人误删数据,或者误操作,特别是update和delete的时候没有加where,然后就喊爹喊娘了.人非圣贤孰能无过,做错可以理解,但不能纵容,这个以后再说,现在先来解决问题. 遇到这种情况,一般都是没有做备份,不然也不会来发问了.首先要冷静,否则会有更大的灾难.直到你放弃. 解决方法: 对于这类问题,主要是找回误操作之前的数据,在2008之前,有个很出名的工具Log Exploer,听说还挺好用的,这个网上大把教程,这里就不多说了.但是唯一遗憾的是,不支持2008及更高版本,这

ORACLE日常操作手册

转发自:http://blog.csdn.net/lichangzai/article/details/7955766 以前为开发人员编写的oracle基础操作手册,都基本的oracle操作和SQL语句写法,适合初学者. 因是很久之前写的,文章中可能会存在不准确的地方,希望指正. ORACLE日常操作手册 目录 一.......数据库的启动和关闭...4 1.   数据库的正常启动步骤...4 2.   数据库的正常关闭步骤...4 3.   几种关闭数据库方法对比...4 4.   数据库的启

一次误操作导致的gi psu升级失败

oracle使用opatch auto的方式安装gi psu时需要一个节点一个节点来,昨晚的升级中,因为误操作而是两节点同时安装gi psu,最终在补丁安装完成后,无法拉起crs. 选择进行补丁的rollback,结果悲剧的发现rollback的前提是需要crs启动的状态,无奈之下只能进行备份文件的恢复了. 不过因为意识的疏忽,压缩$oracle_home目录和$grid_home目录时没有使用root用户,导致部分文件没有备份出来. 以后打类似的psu,有两个注意点: 第一,一定要一个节点一个