爱在Cookies
- 浏览: 76416 次
- 性别:
- 来自: 广州
-
最新评论
开始truncate该表
SQL> truncate table test;
Table truncated
查询当前时间为20090314 12:21:29
引用
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YYYYMMDDHH24:
------------------------------------------------------
2010-12-22 15:33:09
TO_CHAR(SYSDATE,'YYYYMMDDHH24:
------------------------------------------------------
2010-12-22 15:33:09
怎么办，表被truncate了，当然是想法子恢复回来了，首先将数据库置于MOUNT模式
引用
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss');
flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss')
*
第 1 行出现错误:
ORA-01034: ORACLE not available
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variable Size 145488364 bytes
Database Buffers 25165824 bytes
Redo Buffers 524288 bytes
数据库装载完毕。
SQL> flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss');
闪回完成。
quote]
提示成功了，将数据库打开，请注意这个restlogs！
现在让登陆进去看看结果
该表记录终于找回来了，非常激动人心吧！
除了上面说的格式问题外，还要另外注意一点，就是这个闪回的时间是有限的，要有足够的闪回空间，否则将无法将数据库闪回到时间太前的时间，比如该例子说明到早上10点就无法闪回了。
SQL> flashback database to timestamp to_timestamp('2009-03-14 10:00:00','yyyy-mm-dd hh24:mi:ss');
ERROR at line 1:
ORA-38729: Not enough flashback database log data to do FLASHBACK.
总结：本小节通过闪回了整个数据库找回了被truncate的数据，不过现实中这样闪回整个数据库的操作可能只适合在开发库和测试库，生产中做这样操作的可能性非常小，首先是闪回整个庞大的数据库要足够的空间，其次是你如果闪回了你当前失误点时刻的数据库，好象时光倒流了，但是你是并发用户数据库，别人的正常操作过程也被你给回退了。所以生产中即便要做这样的操作，也要有非常严谨的考虑和规划才开始操作。
联想与引申：本例是讲述了如何找回被truncate的表，大家想想，虽然我把delete+commit，drop表，truncate table三个最容易发生的误操作分别用闪回查询，回收站和闪回数据库三种不同的方法找回，实际上闪回数据库的方法是包含了恢复delete+commit 和drop两类，整个数据库都可以回到某个时刻，被delete+commit和drop的表能不恢复回来吗！此外被drop的表如果回收站被人清空了，估计也就不得不依赖闪回数据库了。不过闪回数据库和回收站必须依赖oracle 10g版本数据库才可以，这点要牢记！
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss');
flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss')
*
第 1 行出现错误:
ORA-01034: ORACLE not available
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area 171966464 bytes
Fixed Size 787988 bytes
Variable Size 145488364 bytes
Database Buffers 25165824 bytes
Redo Buffers 524288 bytes
数据库装载完毕。
SQL> flashback database to timestamp to_timestamp('2010-12-22 15:32:20' ,'yyyy-mm-dd hh24:mi:ss');
闪回完成。
quote]
提示成功了，将数据库打开，请注意这个restlogs！
引用
SQL> alter database open resetlogs;
数据库已更改。
数据库已更改。
现在让登陆进去看看结果
引用
SQL> connect scott/liweiwei@liweiwei
已连接。
已连接。
该表记录终于找回来了，非常激动人心吧！
引用
SQL> select count(*) from test;
COUNT(*)
----------
14
COUNT(*)
----------
14
除了上面说的格式问题外，还要另外注意一点，就是这个闪回的时间是有限的，要有足够的闪回空间，否则将无法将数据库闪回到时间太前的时间，比如该例子说明到早上10点就无法闪回了。
SQL> flashback database to timestamp to_timestamp('2009-03-14 10:00:00','yyyy-mm-dd hh24:mi:ss');
ERROR at line 1:
ORA-38729: Not enough flashback database log data to do FLASHBACK.
总结：本小节通过闪回了整个数据库找回了被truncate的数据，不过现实中这样闪回整个数据库的操作可能只适合在开发库和测试库，生产中做这样操作的可能性非常小，首先是闪回整个庞大的数据库要足够的空间，其次是你如果闪回了你当前失误点时刻的数据库，好象时光倒流了，但是你是并发用户数据库，别人的正常操作过程也被你给回退了。所以生产中即便要做这样的操作，也要有非常严谨的考虑和规划才开始操作。
联想与引申：本例是讲述了如何找回被truncate的表，大家想想，虽然我把delete+commit，drop表，truncate table三个最容易发生的误操作分别用闪回查询，回收站和闪回数据库三种不同的方法找回，实际上闪回数据库的方法是包含了恢复delete+commit 和drop两类，整个数据库都可以回到某个时刻，被delete+commit和drop的表能不恢复回来吗！此外被drop的表如果回收站被人清空了，估计也就不得不依赖闪回数据库了。不过闪回数据库和回收站必须依赖oracle 10g版本数据库才可以，这点要牢记！
分享到：
发表评论
相关推荐
然而，这也意味着`TRUNCATE`操作一旦执行，数据就无法通过正常的数据库事务回滚来恢复，这对于初学者来说可能是一个陷阱。 当误用`TRUNCATE TABLE`导致数据丢失时，如果没有备份，恢复过程通常比较复杂。以下是一些...
### Truncate 表恢复(无备份情况下) #### 概述 在数据库管理中，`TRUNCATE`命令是一种快速清空表数据的方法。与`DELETE`不同的是，`TRUNCATE`不会逐一删除数据行，而是重置数据字典中的元数据信息，使表返回到初始...
然而，一旦执行`TRUNCATE TABLE`，数据通常无法通过常规的数据库备份或恢复机制还原，因为它不触发任何撤销（ROLLBACK）操作。这就引出了我们的主要知识点：如何在Oracle中尝试恢复`TRUNCATE TABLE`后丢失的数据。 ...
1、 表是否能成功恢复，取决于被truncate了的表所占用的数据块是不是被新的段(表、索引等)所重用，如果被重用就无法完成这样的恢复了，看个人运气了 。 2、需用到牛人写的恢复包，FY_Recover_Data。
### Truncate 表恢复 #### 测试环境与背景 在探讨如何进行`TRUNCATE`操作后的表数据恢复前，我们需要了解本次实验的环境配置。本案例中的测试环境包括： - **操作系统**: Linux (IP: 172.28.145.21) - **数据库**...
实际线上的场景比较复杂，当时涉及了truncate, delete 两个操作，经确认丢数据差不多7万多行，等停下来时，差不多又有共计1万多行数据写入。 这里为了简单说明，只拿弄一个简单的业务场景举例。 测试环境： Percona-...
首先，理解TRUNCATE表恢复的基本原理：由于TRUNCATE不涉及行级别的删除，所以没有日志信息可供直接回滚。通常，我们依赖于数据库的备份来恢复数据。如果没有备份，那么可能需要借助一些特殊的工具或者技术，如闪回、...
### Oracle Truncate 操作及其恢复方法 在Oracle数据库管理中，`TRUNCATE`命令是一种高效的数据清除方式，常用于快速清空表中的所有数据。然而，与`DELETE`语句不同的是，`TRUNCATE`操作是非事务性的且无法通过普通...
注意这边文章针对的是PRM在 数据字典模式下的Truncate恢复选项不可用时使用，数据字典模式下的Truncate恢复选项是最简单、易用的一种模式，具体使用见《使用PRM恢复Oracle数据库中误truncate截断的表数据》...
- **不产生回滚信息**：`truncate` 不会产生回滚信息，这意味着一旦执行了 `truncate` 操作，删除的数据将无法恢复。 - **隐式提交**：`truncate` 属于 DDL（数据定义语言）命令，因此它是隐式提交的，不能通过回滚...
根据日志，它能找到在TRUNCATE操作之前的数据快照。 5. **恢复过程**： 运行gdul进程，让它从日志中提取并重建被删除的数据。这个过程可能需要一段时间，具体取决于日志的大小和数据库的活动级别。 6. **数据验证...
Oracle 中 Truncate 表的恢复方法 Oracle 数据库中，Truncate 表是一种高效的删除表操作，但是它不会产生日志记录和回滚段空间的使用，无法使用闪回恢复。因此，需要使用 LogMiner 快速定位 Truncate 表的 SCN，并...
truncate语句更快、更高效，但也更危险，因为它不能回滚。 -delete和truncate的区别 1. 条件语句：delete语句可以带有条件语句，以指定要删除的记录，而truncate语句不可以带有条件语句。 2. 删除方式：delete语句...
在Oracle数据库中，`TRUNCATE TABLE`是一个用于删除表中所有数据的命令，与`DELETE`语句不同，`TRUNCATE`不记录任何删除操作，因此它不能通过闪回查询（Flashback Query）来恢复。当你执行`TRUNCATE TABLE`后，数据...
使用bbed强制online数据文件，修复system头损坏，找回truncate数据
### Truncate, Delete, Drop 的异同点 在数据库管理中，`TRUNCATE`, `DELETE`, 和 `DROP` 是三种常见的数据操作语言（DML）与数据定义语言（DDL）。这三种命令都有助于管理和调整数据库表结构及其中的数据，但它们...
【Oracle 恢复 Truncate 删除表的数据】 在Oracle数据库中，`TRUNCATE TABLE`命令用于删除表中的所有数据，但保留表结构。与`DELETE`语句不同，`TRUNCATE`不记录任何删除操作，因此无法通过常规的事务回滚来恢复...