为您推荐:
精华内容
最热下载
问答
  • 2.52MB qq_43368368 2019-01-16 12:12:37
  • 实际线上的场景比较复杂,当时涉及了truncate, delete 两个操作,经确认丢数据差不多7万多行,等停下来时,差不多又有共计1万多行数据写入。 这里为了简单说明,只拿弄一个简单的业务场景举例。测试环境: Percona-...

    实际线上的场景比较复杂,当时涉及了truncate, delete 两个操作,经确认丢数据差不多7万多行,等停下来时,差不多又有共计1万多行数据写入。 这里为了简单说明,只拿弄一个简单的业务场景举例。

    测试环境: Percona-Server-5.6.16

    日志格式: mixed 没起用gtid

    表结构如下:

    CREATETABLE`tb_wubx`(`id`INT(11)NOTNULLAUTO_INCREMENT,`name`VARCHAR(32)DEFAULTNULL,PRIMARYKEY(`id`)) ENGINE=InnoDB AUTO_INCREMENT=2DEFAULT CHARSET=utf8

    基于某个时间点有一个备份或是有全量的binlog是能恢复数据的一个唯一保证。 例如我们的备份就是一个表结构创建语句,binlog pos相关信息: mysql-bin.000004 , 4,然后进行了如下:

    -t1时间 程序写入:

    insert into tb_wubx(name) values(‘张三’),(‘李四’);

    insert into tb_wubx(name) values(‘隔壁老王’);

    -t2时间 某个人员失误

    truncate table tb_wubx;

    -t3时间 程序写入

    insert into tb_wubx(name) values(‘老赵’);

    update tb_wubx set name=’老赵赵’ where id=1;

    现在表里的数据情况:

    mysql>SELECT*FROM tb_wubx;

    +----+-----------+| id | name |+----+-----------+|1| 老赵赵 |+----+-----------+1ROWINSET(0.00 sec)

    可以见truncate table操作后,表的自增id又变更为从1开始,原来写入的数据应该是:

    +—-+———-+

    | id | name |

    +—-+———-+

    | 1 | 张三 |

    +—-+———-+

    | 2 | 李四 |

    +—-+———-+

    | 3 | 隔壁老王 |

    +—-+———-+

    如果没生truncate table操作,实际的数据应该为:

    +—-+———-+

    | id | name |

    +—-+———-+

    | 1 | 张三 |

    +—-+———-+

    | 2 | 李四 |

    +—-+———-+

    | 3 | 隔壁老王 |

    +—-+———-+

    | 4 | 老赵赵 |

    +—-+———-+

    而且线上的恢复那个表时和序序开发人员了解才知道,原来那个id和缓存及其它地方有依赖,因为id乱了,也会造成程序错乱。这个时间修复id在程序层错乱的事,留给开发人员了关建是给他们讲明白恢复的结果是什么样,我们的关建任务是把数据恢复出来。好,接下来的工作是开始从binlog中恢复数据。

    利用: show binary logs; 查看当的log文件分布, 然后利用show binlog events in ‘binary log文件’; 查看log文件的内容,目的是找到truncate发生的日志位置。

    另外因为基于备份(由log的启始位置)或是从量log, 如果基于备份有log的起始位置,我们需要处理的log文件是启始位置到发生truncate的日值(后面的数据处理不了,会发生主建冲突的错误造成truncate后的数据不能恢复),

    如果是全量日志,需要从创建完mysql后库后的日志去处理到当前的发生truncate的位置(后面数据会因为主建冲突写不进去)

    恢复准备工作,创建一个库用于恢复数据,这里创建了一个re_wubx, 及原结构的表: tb_wubx (相当于恢复了备份,过程省略)

    作者:吴炳锡 来源:http://www.mysqlsupport.cn/ 联系方式: wubingxi#gmail.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

    mysql>SHOWBINARY logs;

    +------------------+-----------+| Log_name | File_size |+------------------+-----------+| mysql-bin.000001 |143|| mysql-bin.000002 |261|| mysql-bin.000003 |562|| mysql-bin.000004 |1144|+------------------+-----------+4ROWSINSET(0.00 sec)

    我这里有一个备份文件就是那个创建表的sql语句,位置是mysql-bin.000004 , 4

    在这个案例里我只用cover住mysql-bin.000004这个文件。

    mysql>SHOW binlog events IN'mysql-bin.000004';

    +------------------+------+-------------+-----------+-------------+----------------------------------------------------+| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |+------------------+------+-------------+-----------+-------------+----------------------------------------------------+| mysql-bin.000004 |4| Format_desc |753306|120| Server ver: 5.6.16-64.2-rel64.2-log, Binlog ver: 4|| mysql-bin.000004 |120| Query |753306|209|USE`wubx`; TRUNCATETABLE tb_wubx || mysql-bin.000004 |209| Query |753306|281|BEGIN|| mysql-bin.000004 |281| Table_map |753306|334| table_id: 91(wubx.tb_wubx)|| mysql-bin.000004 |334| Write_rows |753306|393| table_id: 91 flags: STMT_END_F || mysql-bin.000004 |393| Xid |753306|424| COMMIT /* xid=1073 */|| mysql-bin.000004 |424| Query |753306|496|BEGIN|| mysql-bin.000004 |496| Table_map |753306|549| table_id: 91(wubx.tb_wubx)|| mysql-bin.000004 |549| Write_rows |753306|602| table_id: 91 flags: STMT_END_F || mysql-bin.000004 |602| Xid |753306|633| COMMIT /* xid=1074 */|| mysql-bin.000004 |633| Query |753306|722|USE`wubx`; TRUNCATETABLE tb_wubx || mysql-bin.000004 |722| Query |753306|794|BEGIN|| mysql-bin.000004 |794| Table_map |753306|847| table_id: 92(wubx.tb_wubx)|| mysql-bin.000004 |847| Write_rows |753306|894| table_id: 92 flags: STMT_END_F || mysql-bin.000004 |894| Xid |753306|925| COMMIT /* xid=1081 */|| mysql-bin.000004 |925| Query |753306|997|BEGIN|| mysql-bin.000004 |997| Table_map |753306|1050| table_id: 92(wubx.tb_wubx)|| mysql-bin.000004 |1050| Update_rows |753306|1113| table_id: 92 flags: STMT_END_F || mysql-bin.000004 |1113| Xid |753306|1144| COMMIT /* xid=1084 */|+------------------+------+-------------+-----------+-------------+----------------------------------------------------+19ROWSINSET(0.00 sec)

    看到这个表刚开始就发生一次truncate, 那其实也可以说明我就恢复刚开始那个truncate到后来那个误操作的truncate table的语句之间的数据就是丢失的数据。

    这个恢复可以从mysql-bin.000004 pos: 4到mysql-bin.000004 pos: 633 即:

    mysqlbinlog --rewrite-db='wubx->re_wubx' --start-position=4 --stop-position=633 mysql-bin.000004 |mysql -S /tmp/mysql.sock re_wubx

    恢复结果如下:

    mysql -S /tmp/mysql.sock re_wubx;

    mysql>SELECTCOUNT(*)FROM tb_wubx;

    +----------+|COUNT(*)|+----------+|3|+----------+1ROWINSET(0.02 sec)

    mysql>SELECT*FROM tb_wubx;

    +----+--------------+| id | name |+----+--------------+|1| 张三 ||2| 李四 ||3| 隔壁老王 |+----+--------------+3ROWSINSET(0.00 sec)

    mysql>INSERTINTO tb_wubx(name)SELECT name FROM wubx.tb_wubx;

    Query OK,1ROW affected (0.00 sec)

    Records: 1 Duplicates: 0 Warnings: 0

    mysql>RENAMETABLE wubx.tb_wubx TO wubx.bak_tb_wubx;

    Query OK,0ROWS affected (0.04 sec)

    mysql>RENAMETABLE re_wubx.tb_wubx TO wubx.tb_wubx;

    Query OK,0ROWS affected (0.03 sec)

    mysql>SELECT*FROM wubx.tb_wubx;

    +----+--------------+| id | name |+----+--------------+|1| 张三 ||2| 李四 ||3| 隔壁老王 ||4| 老赵赵 |+----+--------------+4ROWSINSET(0.00 sec)

    恢复完成。

    想一想,如果我跳过那个truncate继续执行那些binlog会怎么样 ?

    觉得文章有用?立即:

    和朋友一起 共学习 共进步!

    猜您喜欢

    展开全文
    weixin_32659227 2021-02-01 19:09:21
  • 61KB weixin_38535132 2020-09-10 09:39:30
  • 可能有一些数据库知识的应该会知道,在正常逻辑中,如果我们将表truncate掉了,是找不回来了,TRUNCATE TABLE 是一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存,删除行是不能恢复的。...

    在我的另外几篇文章中,介绍了关于数据库闪回的一些内容,对于drop和delete的数据闪回。对于truncate,可能有一些数据库知识的应该会知道,在正常逻辑中,如果我们将表truncate掉了,是找不回来了,TRUNCATE TABLE 是一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存,删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。
    那么问题来了,如果我们生产过程中,一不小心,将业务表truncate掉了该怎么办呢?其实也是有办法解决的,具体操作过程如下:

    1,新建测试表t_test,插入几条测试数据
    在这里插入图片描述
    2,执行我们truncate命令,清除t_test中的所有数据
    在这里插入图片描述
    3,truncate恢复需要一个存储过程fy_recover_data(我个人觉得,能写出这种存储过程的,怕真的是科学家级别的了)
    下载地址:https://download.csdn.net/download/xxbb0101/10275209

    4,下载完成后,使用sys用户登录db(注意一定要sys用户登录,否则会出现执行报错的情况),然后执行存储过程

    5,在command界面,登录sys用户,执行命令:exec fy_recover_data.recover_truncated_table('userName','tableName');
    注意该程序有两个参数,前一个为被truncate表所在用户的用户名,后者为表名
    在这里插入图片描述
    4,用被普通用户登录,查询临时表:select * from tablename$$;(临时表名为表名+“$$”)
    可见,被truncate掉的数据已经全部在我们的临时表中了
    在这里插入图片描述
    5,最后将临时表的数据全部插入的业务表即可,你看业务表数据,已经被全部恢复了
    在这里插入图片描述
    6,到此虽然我们数据恢复工作已经做完了,但是由于其恢复需要生成临时表文件,所以我们要找到其对应的表空间文件,做相关删除操作,可以看到生成的临时表空间为;FY_RST_DATA
    在这里插入图片描述
    7,根据数据字典DBA_DATA_FILES,查出该表空间对应的磁盘文件
    在这里插入图片描述
    8,在磁盘上找到对应的文件,rm即可
    在这里插入图片描述

    到此为止,整个truncate数据恢复操作就算全部完成了!希望对大家有所帮助

    展开全文
    baomw 2018-11-22 13:31:33
  • 这次的数据恢复操作我我使用第一种方式,以下是操作步骤: 1、拷贝数据文件和2节点的归档日志文件。由于故障库的备份是nfs挂载到备份机上的,省去了拷贝数据文件的时间,只需要把2节点下的archive日志文件拷贝到测试...
    这次的数据恢复操作我我使用第一种方式,以下是操作步骤:
    1、拷贝数据文件和2节点的归档日志文件。由于故障库的备份是nfs挂载到备份机上的,省去了拷贝数据文件的时间,只需要把2节点下的archive日志文件拷贝到测试库上就行。
    2、创建新库的pfile参数文件,拷贝故障库的spfile文件,修改参数并删除有关rac的不需要参数信息。
    3、创建新库的密码文件.
         orapwd file=/u02/app/oracle/product/11.2.0/db1/dbs/orapwklir passord=oracle entries=10 force=y
    4、创建新库的dump目录。
    5、启动新库到nomount下。
    [oracle@kms2 dbs]$ export ORACLE_SID=klir
    [oracle@kms2 dbs]$ sqlplus / as sysdba
    SQL*Plus: Release 11.2.0.1.0 Production on Thu Nov 18 09:56:35 2010
    Copyright (c) 1982, 2009, Oracle.  All rights reserved.
    Connected to an idle instance.
    SQL> startup nomount pfile='/u02/pfile_klir.ora'
    6、从备份集中恢复控制文件,并启动到mount状态下。
    RMAN>   restore controlfile from /orabk/ctl_c-949039848-20101116-00.ctl;
    RMAN>  alter database mount;
     
    7、恢复表空间。因为只是一个表空间下的一些表被删除了,朋友建议我只恢复有问题的表空间就可以了,当然system,sysaux,undo这些基本的表空间是要恢复的。

    RMAN> restore tablespace system;
    Starting restore at 16-NOV-10
    Starting implicit crosscheck backup at 16-NOV-10
    allocated channel: ORA_DISK_1
    Crosschecked 198 objects
    Finished implicit crosscheck backup at 16-NOV-10
    Starting implicit crosscheck copy at 16-NOV-10
    using channel ORA_DISK_1
    Finished implicit crosscheck copy at 16-NOV-10
    searching for all files in the recovery area
    cataloging files...
    no files cataloged
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00001 to +DG1/system01.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13771_1_1_735012733.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13771_1_1_735012733.dbf tag=TAG20101114T021212
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:09:15
    Finished restore at 16-NOV-10
    RMAN> restore tablespace sysaux;
    Starting restore at 16-NOV-10
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00002 to +DG1/sysaux01.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13770_1_1_735012528.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13770_1_1_735012528.dbf tag=TAG20101114T021212                               
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:08:50
    Finished restore at 16-NOV-10
    RMAN> restore tablespace HZDATATBS;
    Starting restore at 16-NOV-10
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00011 to +DG1/hzdata01.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13770_1_1_735012528.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13770_1_1_735012528.dbf tag=TAG20101114T021212
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:16:35
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00154 to +DG1/hzdata02.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13938_1_1_735186686.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13938_1_1_735186686.dbf tag=TAG20101116T023123
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:02:05
    Finished restore at 16-NOV-10
    RMAN> restore tablespace hzindtbs;
    Starting restore at 16-NOV-10
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00017 to +DG1/hzind02.dbf
    channel ORA_DISK_1: restoring datafile 00021 to +DG1/hzind03.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13773_1_1_735012734.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13773_1_1_735012734.dbf tag=TAG20101114T021212
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:13:45
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00012 to +DG1/hzind01.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13771_1_1_735012733.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13771_1_1_735012733.dbf tag=TAG20101114T021212
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:14:46
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00153 to +DG1/hzind04.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13937_1_1_735186478.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13937_1_1_735186478.dbf tag=TAG20101116T023123
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:03:15
    Finished restore at 17-NOV-10

    RMAN> restore tablespace undotbs2;
    Starting restore at 17-NOV-10
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00006 to +DG1/undotbs201.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13770_1_1_735012528.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13770_1_1_735012528.dbf tag=TAG20101114T021212
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:04:46
    Finished restore at 17-NOV-10
    RMAN> restore tablespace undotbs1;
    Starting restore at 17-NOV-10
    using channel ORA_DISK_1
    channel ORA_DISK_1: starting datafile backup set restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    channel ORA_DISK_1: restoring datafile 00003 to +DG1/undotbs101.dbf
    channel ORA_DISK_1: reading from backup piece /orabk/db_KLIR_13773_1_1_735012734.dbf
    channel ORA_DISK_1: piece handle=/orabk/db_KLIR_13773_1_1_735012734.dbf tag=TAG20101114T021212
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:11:05
    Finished restore at 17-NOV-10
     
    8.Offline 其它不用的表空间。
    SQL> alter database datafile 5,7 offline drop;
    Database altered.
    SQL> alter database datafile 13,14,15,16 offline drop;
    Database altered.
     
    9、不完全恢复数据库。

    SQL> recover database until time '2010-11-16 16:25:00'   using backup  controlfile;
    ORA-00279: change 2602636589 generated at 11/14/2010 13:16:46 needed for thread
    1
    ORA-00289: suggestion : +ARCHIVE
    ORA-00280: change 2602636589 for thread 1 is in sequence #5709

    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    thread_1_seq_5709.528.735293603
    ORA-00308: cannot open archived log 'thread_1_seq_5709.528.735293603'
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3

    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    /orabk/aaa/thread_1_seq_5709.528.735293603
    ORA-00279: change 2602636589 generated at 11/14/2010 06:43:25 needed for thread
    2
    ORA-00289: suggestion : +ARCHIVE
    ORA-00280: change 2602636589 for thread 2 is in sequence #6914
     
    ORA-00289: suggestion : +ARCHIVE
    ORA-00280: change 2609694870 for thread 1 is in sequence #5824
    ORA-00278: log file '/orabk/aaa/arch11/1_5823_719402218.dbf' no longer needed
    for this recovery

    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    /orabk/aaa/arch11/1_5824_719402218.dbf
    ORA-00279: change 2609942602 generated at 11/16/2010 16:07:30 needed for thread
    2
    ORA-00289: suggestion : +ARCHIVE
    ORA-00280: change 2609942602 for thread 2 is in sequence #6990
    ORA-00278: log file '/orabk/aaa/arch22/2_6989_719402218.dbf' no longer needed
    for this recovery
    ........................省略中间部分
    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    /orabk/aaa/arch22/2_6990_719402218.dbf
    ORA-00279: change 2609955345 generated at 11/16/2010 16:08:25 needed for thread
    1
    ORA-00289: suggestion : +ARCHIVE
    ORA-00280: change 2609955345 for thread 1 is in sequence #5825
    ORA-00278: log file '/orabk/aaa/arch11/1_5824_719402218.dbf' no longer needed
    for this recovery

    Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
    / orabk/aaa/arch11/1_5825_719402218.dbf
    Log applied.
    Media recovery complete.
     
    10、打开数据库。
    SQL> alter database open resetlogs;
    经过几分钟的等待后,数据成功打开,登录数据库查询需要的文件都已经恢复出来了。谢天谢地!
     
     
    这次数据恢复操作,用了近1天的时间,当时发生问题时我都快搞懵了,幸好在朋友的帮助下顺利完数据恢复,在这里要非常感谢他们!顺便记录下恢复期间遇到的几个问题。
    <1>、有些日志文件在故障库的日志目录里是没有的,需要从备份中还原,不同节点的日志文件恢复时要写上thread=*命令,例如:
     
    RMAN>  restore archivelog from logseq 6914 until logseq 6915  thread=2;
    Starting restore at 17-NOV-10
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=182 instance=klir2 device type=DISK
    channel ORA_DISK_1: starting archived log restore to default destination
    channel ORA_DISK_1: restoring archived log
    archived log thread=2 sequence=6914
    channel ORA_DISK_1: reading from backup piece /orabk/arc_KLIR_13864_1_1_735184831.dbf
    channel ORA_DISK_1: piece handle=/orabk/arc_KLIR_13864_1_1_735184831.dbf tag=TAG20101116T020016
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
    channel ORA_DISK_1: starting archived log restore to default destination
    channel ORA_DISK_1: restoring archived log
    archived log thread=2 sequence=6915
    channel ORA_DISK_1: reading from backup piece /orabk/arc_KLIR_13866_1_1_735184956.dbf
    channel ORA_DISK_1: piece handle=/orabk/arc_KLIR_13866_1_1_735184956.dbf tag=TAG20101116T020016
    channel ORA_DISK_1: restored backup piece 1
    channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
    Finished restore at 17-NOV-10
     
    否则会提示以下错误,
    RMAN>  restore archivelog from logseq 6914 until logseq 6915;
    Starting restore at 17-NOV-10
    using target database control file instead of recovery catalog
    allocated channel: ORA_DISK_1
    channel ORA_DISK_1: SID=182 instance=klir2 device type=DISK
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of restore command at 11/17/2010 08:15:07
    RMAN-20242: specification does not match any archived log in the repository
    <2>、故障库恢复出日志文件后,因为在asm磁盘组里,要进入asmcmd里拷贝出日志文件。
    ASMCMD> cp +ARCHIVE/klir/archivelog/2010_11_17/thread_1_seq_5705.369.735274973 /orabk/aaa/
     
    <3>、恢复命令要写对,刚开始写的几种命令都不正确。
    SQL> recover database until time '2010-11-16 16:25:00'
    ORA-00283: recovery session canceled due to errors
    ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
     
    SQL>  recover database until time to_date('2010-11-16 16:25:00','yyyy-mm-dd HH24:MI:SS');
    ORA-00285: TIME not given as a string constant
    <4>、对于这种只是丢失部分表的情况,就可以只还原需要的表空间来打开数据库,可以节省大量的恢复时间。
     


    本文转自 gjm008 51CTO博客,原文链接:http://blog.51cto.com/gaoshan/426326,如需转载请自行联系原作者
    展开全文
    weixin_33834628 2017-11-27 16:22:00
  • 8.93MB qq_34556892 2016-04-18 13:30:09
  • truncate表后恢复方法总结 1.1...

    truncate表后恢复方法总结

     

    1.1  BLOG文档结构图

    image

     

    1.2  前言部分

     

    1.2.1  导读和注意事项

    各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~:

    truncate操作后的恢复方法(重点)

     

      Tips:

           ① 若文章代码格式有错乱,推荐使用QQ、搜狗或360浏览器,也可以下载pdf格式的文档来查看,pdf文档下载地址:http://yunpan.cn/cdEQedhCs2kFz (提取码:ed9b 

           ② 本篇BLOG中命令的输出部分需要特别关注的地方我都用灰色背景和粉红色字体来表示,比如下边的例子中,thread 1的最大归档日志号为33thread 2的最大归档日志号为43是需要特别关注的地方;而命令一般使用黄色背景和红色字体注;对代码或代码输出部分的注释一般采用蓝色字体表示

     

      List of Archived Logs in backup set 11

      Thrd Seq     Low SCN    Low Time            Next SCN   Next Time

      ---- ------- ---------- ------------------- ---------- ---------

      1    32      1621589    2015-05-29 11:09:52 1625242    2015-05-29 11:15:48

      1    33      1625242    2015-05-29 11:15:48 1625293    2015-05-29 11:15:58

      2    42      1613951    2015-05-29 10:41:18 1625245    2015-05-29 11:15:49

      2    43      1625245    2015-05-29 11:15:49 1625253    2015-05-29 11:15:53

     

     

     

     

    [ZFXXDB1:root]:/>lsvg -o

    T_XDESK_APP1_vg

    rootvg

    [ZFXXDB1:root]:/>

    00:27:22 SQL> alter tablespace idxtbs read write;

     

     

    ====》2097152*512/1024/1024/1024=1G 

     

     

     

    本文如有错误或不完善的地方请大家多多指正,ITPUB留言或QQ皆可,您的批评指正是我写作的最大动力。

     

     

    1.2.2  相关参考文章链接

     

     

    1.2.3  本文简介

    truncate操作是比较危险的操作,不记录redo,不能通过闪回查询来找回数据,但是只要段所占用的块没有全部被重新占用的情况下,我们还是可以通过一些特殊的办法来找回truncate掉的数据,因为当Truncate命令发起之后,Oracle实际上并没有在删除底层数据块上的数据,而是要等到重用的时候才会把这一部分数据回收,于是这给了我们一个能够恢复数据库的机会。

    总体而言,恢复的办法是通过一些大牛写的工具来恢复,分为收费和免费的,我们下边分别说明。实验部分我们只实验fy_recover_data包和gdul工具。

    有的实验是很久之前做的,这篇文章发布太晚,因为中间学习了DUL和BBED的相关知识。

    1.3  收费软件

     

    这里简单列举一下,具体内容请到相关网站了解:

    工具名称

    下载地址

    作者

    软件

    ODU

    http://www.oracleodu.com/cn/

    老熊

    命令行操作

    PRM-DUL

    http://www.parnassusdata.com/ 

    Maclean Liu

    图形界面操作

    AUL/mydul

    http://www.dbatools.net/mydul/

    d.c.b.a/楼方鑫

    命令行

     

     

     

    1.4  免费软件

    1.4.1  fy_recover_data

    作者个人信息:

    WWW.HelloDBA.COM                                                   

    Created By: Fuyuncat                                               

    Created Date: 08/08/2012                                           

    Email: Fuyuncat@gmail.com                                          

    Copyright (c), 2014, WWW.HelloDBA.COM All rights reserved.         

    Latest Version: http://www.HelloDBA.com/download/FY_Recover_Data.zip

    该包采用纯plsql语句恢复被truncate掉的表,操作比较简单,下载可以去官网下载,或者小麦苗的云盘共享目录。

     

    Fy_Recover_Data是利用Oracle表扫描机制、数据嫁接机制恢复TRUNCATE或者损坏数据的工具包。由纯PLSQL编写,原理图如下:

    wps33F2.tmp 

     

     

    包内容:

    wps3403.tmp

     

    1.4.2  gdul工具

    GDUL老耿开发的一款类dul工具,当数据库于某种原因无法打开,可以利用GDUL把表数据直接读取出来工具下载地址参考小麦苗的blog老耿的信息如下:

    *********************************************************************

      GDUL for ORACLE DB.

      Version 4.0.0.1, build date: 2016.04.12.

      Copyright (c) 2007, 2016. Andy Geng.  ALL RIGHTS RESERVED.

      Email: dbtool@aliyun.com

      WeChat official account: dbtool

      QQ group: 235019291

    *********************************************************************

     

    1.4.2.1  gDUL功能特点

    完整支持多种格式导出,包括expdp,exp,text格式。目前市面上的类dul工具只有gDUL支持expdp格式。

    支持ASM文件系统,并内置asmcmd命令。

    支持绝大多数列类型,支持常见的NUMBER,CHAR, VARCHAR2, DATE,LOB, LONG等类型。。其中 SecureFile LOB 支持压缩,尚不支持去重和加密。

    支持导出常规表、IOT、Cluster 表、分区表、压缩表。

    支持 truncated 表、删除行恢复。

    支持常规表空间和 bigfile 表空间。

    支持主流硬件平台(HP-UX,AIX, Solaris, Linux, Windows),各个平台仅需单一的可执行文件,方便分发。

    重点是——永久免费使用,无需额外费用,不开源。

     

     

     

    1.4.3  dul

    DUL Data Unloader 的缩写,是一个荷兰的 Oracle 工程师开发的,他的名字为 Bernard Van DuijnenDUL 是一个 C 开发的小程序,编译后整个程序只有一个文件,大小也不过几百 KB,它工作时不需 Oracle RDBMS 以及任何的 Oracle 的程序、组件,它可以直接从一个坏了数据库的数据文件中读取数据,生成 IMP SQL*Loader 可以识别的文件。

    DUL 不是一个商用化的产品,Oracle 不卖、不提供也不支持它的使用。DUL 只有在 Oracle 的内部网站才可以下载到,因此也只有 Oracle Supporter 才能下载到有这个工具,如果与 Oracle Supporter 熟悉,没准他私底下会给你一个,这个工具也因此有一些流落到民间,被一些人收入囊中,奉为珍宝。 

    不同的平台、不同版本的数据库都有相应的 DUL 软件,9.x 及之前 DUL 是没有 License 限制的,也就是有这个工具可以无限制的使用,不过最新的 DUL 在这方面已经改进了,kamus 说最新 DUL 拿到手只能用一个月。 

    关于这一小点稍总结一下,获得 DUL 有以下几种途径: 

    wps3404.tmp 如果你是 Oracle Supporter ,可以在内部网站下载,地址为: http://www.nl.oracle.com/support/dul/ 

    wps3405.tmp 如果你有 Oracle Supporter 的朋友可以向他们要一个,itpub 也几位斑竹都到 Oracle 了,如 coolylkamus,lunar 

    wps3406.tmp 一些 dul 流落到民间,可以向有这软件的朋友要一个,不过他们不一定有你需要的那个。 

     

    所以关于DUL我们不做过多的解释。

     

    1.4.4  bbed来恢复

    这个比较复杂,若对oracle不熟悉或者bbed不熟悉都不推荐使用这个,具体案例参考:http://blog.itpub.net/26736162/viewspace-2080727/

     

     

    第二章 实验部分

    2.1  实验环境介绍

    项目

    db

    db 类型

    单实例

    db version

    11.2.0.4.0

    db 存储

    FS

    主机IP地址/hosts配置

    192.168.59.129

    OS版本及kernel版本

    AIX 7.1 64位

    归档模式

    Archive Mode

    ORACLE_SID

    oralhr

     

     

    2.2  实验目标

    将truncate掉的表数据成功找回。

     

    2.3  实验过程

     

    2.3.1  fy_recover_data包恢复truncate的表

    [ZFXDESKDB1:oracle]:/oracle>ORACLE_SID=oraESKDB1

    [ZFXDESKDB1:oracle]:/oracle>sqlplus / as sysdba

     

    SQL*Plus: Release 11.2.0.4.0 Production on Mon Mar 21 15:51:55 2016

     

    Copyright (c) 1982, 2013, Oracle.  All rights reserved.

     

     

    Connected to:

    Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

    Data Mining and Real Application Testing options

     

    SYS@oraESKDB1> set time on;

    15:52:10 SYS@oraESKDB1> set timing on;

    15:52:10 SYS@oraESKDB1> set serveroutput on;

    15:52:10 SYS@oraESKDB1> create table scott.TB_0321    as SELECT * FROM dba_objects;

     

    Table created.

     

    Elapsed: 00:00:00.59

    15:52:18 SYS@oraESKDB1> SELECT COUNT(1) FROM   scott.TB_0321;

     

      COUNT(1)

    ----------

         86651

     

    Elapsed: 00:00:00.19

    15:52:24 SYS@oraESKDB1> INSERT INTO scott.TB_0321 SELECT * FROM scott.TB_0321;

     

     

    86651 rows created.

     

    Elapsed: 00:00:00.26

    15:52:30 SYS@oraESKDB1> COMMIT;

    Commit complete.

     

    Elapsed: 00:00:00.01

    15:52:30 SYS@oraESKDB1> INSERT INTO scott.TB_0321 SELECT * FROM scott.TB_0321;

    COMMIT;

     

    173302 rows created.

     

    Elapsed: 00:00:00.43

    15:53:02 SYS@oraESKDB1> SELECT COUNT(1) FROM   scott.TB_0321;

     

      COUNT(1)

    ----------

      346604

     

    Elapsed: 00:00:00.27

    16:15:18 SYS@oraESKDB1> SELECT d.BYTES/1024/1024 FROM dba_segments d WHERE d.segment_name ='TB_0321';

     

    D.BYTES/1024/1024

    -----------------

                   40

     

    Elapsed: 00:00:00.44

    16:15:25 SYS@oraESKDB1> truncate table scott.TB_0321;

     

    Table truncated.

     

    Elapsed: 00:00:00.20

    16:15:46 SYS@oraESKDB1> SELECT COUNT(1) FROM   scott.TB_0321;

     

      COUNT(1)

    ----------

             0

     

    Elapsed: 00:00:00.01

     

    ====》数据已经被truncate掉了,下边我们来恢复

     

     

    16:15:52 SYS@oraESKDB1> @/oracle/FY_Recover_Data.pck

     

    Package created.

     

    Elapsed: 00:00:00.06

     

    Package body created.

     

    Elapsed: 00:00:00.03

    16:15:59 SYS@oraESKDB1> exec fy_recover_data.recover_truncated_table('scott','TB_0321');

    16:16:06: Use existing Directory Name: FY_DATA_DIR

    16:16:07: Recover Table: SCOTT.TB_0321$

    16:16:09: Restore Table: SCOTT.TB_0321$$

    16:16:24: Copy file of Recover Tablespace: FY_REC_DATA_COPY.DAT1

    16:16:24: begin to recover table SCOTT.TB_0321

    16:16:24: Use existing Directory Name: TMP_HF_DIR

    16:17:09: Recovering data in datafile +DATA/oraeskdb/datafile/users.351.902678817

    16:17:09: Use existing Directory Name: TMP_HF_DIR

    16:39:16: 4984 truncated data blocks found.

    16:39:16: 346604 records recovered in backup table SCOTT.TB_0321$$

    16:39:17: Total: 4984 truncated data blocks found.

    16:39:17: Total: 346604 records recovered in backup table SCOTT.TB_0321$$

    16:39:17: Recovery completed.

    16:39:17: Data has been recovered to SCOTT.TB_0321$$

     

    PL/SQL procedure successfully completed.

     

    Elapsed: 00:23:11.59

     

    16:39:17 SYS@oraESKDB1> SELECT COUNT(1) FROM   scott.TB_0321$$;

     

      COUNT(1)

    ----------

       346604

     

    Elapsed: 00:00:01.55

    16:40:51 SYS@oraESKDB1>

    16:40:51 SYS@oraESKDB1> alter table scott.TB_0321 nologging;

     

    Table altered.

     

    Elapsed: 00:00:00.03

    16:41:43 SYS@oraESKDB1> insert /*+append*/ into scott.TB_0321 select * from scott.TB_0321$$;

     

    346604 rows created.

     

    Elapsed: 00:00:00.86

    16:41:52 SYS@oraESKDB1> commit;

     

    Commit complete.

     

    Elapsed: 00:00:00.01

    16:41:55 SYS@oraESKDB1> alter table scott.TB_0321 logging;

     

    Table altered.

     

    Elapsed: 00:00:00.02

    16:42:06 SYS@oraESKDB1>

    16:42:06 SYS@oraESKDB1> drop tablespace   FY_REC_DATA  including contents and datafiles;

     

    Tablespace dropped.

     

    Elapsed: 00:00:08.00

    16:42:35 SYS@oraESKDB1> drop tablespace   FY_RST_DATA  including contents and datafiles;

     

    Tablespace dropped.

     

    Elapsed: 00:00:07.59

    16:42:44 SYS@oraESKDB1>

     

     

    数据成功恢复。

     

     

    2.3.2  gdul恢复truncate的表

    set time on;

    set timing on;

    set serveroutput on;

    drop table scott.TB_0322_05;

    create table scott.TB_0322_05    as SELECT * FROM dba_objects;

     

    SELECT COUNT(1) FROM   scott.TB_0322_05;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    SELECT COUNT(1) FROM   scott.TB_0322_05;

     

    SELECT d.BYTES/1024/1024 FROM dba_segments d WHERE d.segment_name ='TB_0322_05';

     

     

    truncate table scott.TB_0322_05;

     

    alter system checkpoint;

     

    col ownere format a10

    col DIRECTORY_NAME format a30

    col DIRECTORY_PATH format a50

    select OWNER,DIRECTORY_NAME,DIRECTORY_PATH from  dba_directories;

     

     

    bootstrap

    desc scott.TB_0322_05

    unload table  scott.TB_0322_05

    scan tablespace 4

    untrunc table  scott.TB_0322_05

     

    cp SCOTT_TB_0322_05.dmp /oracle/app/oracle/admin/oralhr/dpdump/

    impdp  scott/tiger directory=DATA_PUMP_DIR dumpfile=SCOTT_TB_0322_05.dmp LOGFILE=SCOTT_TB_0322_05.log TABLES=TB_0322_05

     

    15:41:04 SQL> set time on;

    15:59:49 SQL> set timing on;

    15:59:49 SQL> set serveroutput on;

    15:59:49 SQL> drop table scott.TB_0322_05;

    create table scott.TB_0322_05    as SELECT * FROM dba_objects;

     

    SELECT COUNT(1) FROM   scott.TB_0322_05;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

     

    Table dropped.

     

    Elapsed: 00:00:00.07

    15:59:49 SQL> COMMIT;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    INSERT INTO scott.TB_0322_05 SELECT * FROM scott.TB_0322_05;

    COMMIT;

    SELECT COUNT(1) FROM   scott.TB_0322_05;

     

    SELECT d.BYTES/1024/1024 FROM dba_segments d WHERE d.segment_name ='TB_0322_05';

     

     

    truncate table scott.TB_0322_05;

     

    alter system checkpoint;

     

    Table created.

     

    Elapsed: 00:00:00.97

    15:59:50 SQL> 15:59:50 SQL>

      COUNT(1)

    ----------

         75707

     

    Elapsed: 00:00:00.86

    15:59:51 SQL>

    75707 rows created.

     

    Elapsed: 00:00:00.23

    15:59:52 SQL>

    Commit complete.

     

    Elapsed: 00:00:00.17

    15:59:52 SQL>

    151414 rows created.

     

    Elapsed: 00:00:00.50

    15:59:52 SQL>

    Commit complete.

     

    Elapsed: 00:00:00.23

    15:59:52 SQL>

    302828 rows created.

     

    Elapsed: 00:00:01.63

    15:59:54 SQL>

    Commit complete.

     

    Elapsed: 00:00:00.22

    15:59:54 SQL>

    605656 rows created.

     

    Elapsed: 00:00:06.19

    16:00:00 SQL>

    Commit complete.

     

    Elapsed: 00:00:00.02

    16:00:01 SQL>

      COUNT(1)

    ----------

       1211312

     

    Elapsed: 00:00:00.07

    16:00:01 SQL> 16:00:01 SQL>

    D.BYTES/1024/1024

    -----------------

                  136

     

    Elapsed: 00:00:00.17

    16:00:01 SQL> 16:00:01 SQL> 16:00:01 SQL>

    Table truncated.

     

    Elapsed: 00:00:01.26

    16:00:02 SQL> 16:00:02 SQL>

    System altered.

     

    Elapsed: 00:00:00.15

    16:00:02 SQL>

    16:00:02 SQL> SELECT COUNT(1) FROM   scott.TB_0322_05;

     

      COUNT(1)

    ----------

             0

     

    Elapsed: 00:00:00.00

    16:02:35 SQL>

     

    [oracle@ZFFR4CB1101:/home/oracle/gdul]$ ./gdul

     

    *********************************************************************

      GDUL for ORACLE DB.

      Version 3.5.0.1, build date: 2016.03.07.

      Copyright (c) 2007, 2016. Andy Geng.  ALL RIGHTS RESERVED.

      Email: gengyonghui@aliyun.com

      QQ group: 235019291, WeChat Official Account: dbtool

    *********************************************************************

     

    GDUL> bootstrap

    Bootstrap finish.

    GDUL> desc scott.TB_0322_05

     

    object_id: 78302, dataobj#: 78303, cluster tab#: 0

    segment header: (ts#: 4, rfile#: 4, block#: 682))

     

    Seg Column#  Column#    Name                 Null?           Type     

    ------------ ---------- -------------------- --------------- --------------

    1            1          OWNER                                VARCHAR2(30)

    2            2          OBJECT_NAME                          VARCHAR2(128)

    3            3          SUBOBJECT_NAME                       VARCHAR2(30)

    4            4          OBJECT_ID                            NUMBER   

    5            5          DATA_OBJECT_ID                       NUMBER   

    6            6          OBJECT_TYPE                          VARCHAR2(19)

    7            7          CREATED                              DATE     

    8            8          LAST_DDL_TIME                        DATE     

    9            9          TIMESTAMP                            VARCHAR2(19)

    10           10         STATUS                               VARCHAR2(7)

    11           11         TEMPORARY                            VARCHAR2(1)

    12           12         GENERATED                            VARCHAR2(1)

    13           13         SECONDARY                            VARCHAR2(1)

    14           14         NAMESPACE                            NUMBER   

    15           15         EDITION_NAME                         VARCHAR2(30)

     

    GDUL> unload table  scott.TB_0322_05

    2016-03-22 16:01:54...unloaded "SCOTT"."TB_0322_05"   0 rows

    GDUL> scan tablespace 4

    start scan tablespace 4...

    scan tablespace completed.

    GDUL> untrunc table  scott.TB_0322_05

    2016-03-22 16:04:29...untruncating table TB_0322_05 1211312 rows unloaded.

    GDUL>

     

    16:02:35 SQL> select * from dba_directories;

     

    OWNER                          DIRECTORY_NAME                 DIRECTORY_PATH

    ------------------------------ ------------------------------ -----------------------------------------------------------------------

    SYS                            SUBDIR                         /u01/app/oracle/product/11.2.0/dbhome_1/demo/schema/order_entry//2002/Sep

    SYS                            SS_OE_XMLDIR                   /u01/app/oracle/product/11.2.0/dbhome_1/demo/schema/order_entry/

    SYS                            LOG_FILE_DIR                   /u01/app/oracle/product/11.2.0/dbhome_1/demo/schema/log/

    SYS                            MEDIA_DIR                      /u01/app/oracle/product/11.2.0/dbhome_1/demo/schema/product_media/

    SYS                            XMLDIR                         /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/xml

    SYS                            DATA_FILE_DIR                  /u01/app/oracle/product/11.2.0/dbhome_1/demo/schema/sales_history/

    SYS                            DATA_PUMP_DIR                  /u01/app/oracle/product/11.2.0/dbhome_1/rdbms/log/

    SYS                            ORACLE_OCM_CONFIG_DIR          /u01/app/oracle/product/11.2.0/dbhome_1/ccr/state

     

    8 rows selected.

     

    Elapsed: 00:00:00.00

    16:05:29 SQL>

     

    [oracle@ZFFR4CB1101:/home/oracle/gdul/dump]$ impdp  scott/tiger directory=DATA_PUMP_DIR dumpfile=SCOTT_TB_0322_05.dmp LOGFILE=SCOTT_TB_0322_05.log TABLES=TB_0322_05

     

    Import: Release 11.2.0.3.0 - Production on Tue Mar 22 16:16:48 2016

     

    Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

     

    Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

    Data Mining and Real Application Testing options

    Master table "SCOTT"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded

    Starting "SCOTT"."SYS_IMPORT_TABLE_01":  scott/******** directory=DATA_PUMP_DIR dumpfile=SCOTT_TB_0322_05.dmp LOGFILE=SCOTT_TB_0322_05.log TABLES=TB_0322_05

    Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

    . . imported "SCOTT"."TB_0322_05"                        117.1 MB 1211312 rows

    Job "SCOTT"."SYS_IMPORT_TABLE_01" successfully completed at 16:16:59

     

    [oracle@ZFFR4CB1101:/home/oracle/gdul/dump]$

    [oracle@ZFFR4CB2101:/home/oracle]$ sqlplus / as sysdba

     

    SQL*Plus: Release 11.2.0.3.0 Production on Tue Mar 22 16:17:39 2016

     

    Copyright (c) 1982, 2011, Oracle.  All rights reserved.

     

     

    Connected to:

    Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

    With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,

    Data Mining and Real Application Testing options

     

    SQL> SELECT COUNT(1) FROM   scott.TB_0322_05;

     

      COUNT(1)

    ----------

       1211312

     

    SQL>

     

    数据成功恢复。

     

     

     

    2.4  实验总结

     

    总体而言用fy_recover_data包或GDUL工具都是非常好的,fy_recover_data可以恢复truncate的数据,但不能恢复drop的数据,而GDUL工具就比较全面了,具体可以参考前边的简介或下载文档来看,小麦苗的共享云盘里也有比较全的文档。

     

     

     

    ---------------------------------------------------------------------------------------------------------------------

     

     

     






    About Me

    ...............................................................................................................................

    ● 本文作者:小麦苗,只专注于数据库的技术,更注重技术的运用

    ● 本文在itpub(http://blog.itpub.net/26736162)、博客园(http://www.cnblogs.com/lhrbest)和个人微信公众号(xiaomaimiaolhr)上有同步更新

    ● 本文itpub地址:http://blog.itpub.net/26736162/viewspace-2082965/

    ● 本文博客园地址:http://www.cnblogs.com/lhrbest

    ● 本文pdf版及小麦苗云盘地址:http://blog.itpub.net/26736162/viewspace-1624453/

    ● 数据库笔试面试题库及解答:http://blog.itpub.net/26736162/viewspace-2134706/

    ● QQ群:230161599     微信群:私聊

    ● 联系我请加QQ好友(646634621),注明添加缘由

    ● 于 2016-03-10 10:00~ 2016-04-15 19:00 在魔都完成

    ● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

    ● 版权所有,欢迎分享本文,转载请保留出处

    ...............................................................................................................................

    拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号:xiaomaimiaolhr,扫描右边的二维码加入小麦苗的QQ群,学习最实用的数据库技术。

    ico_mailme_02.png
    DBA笔试面试讲解
    欢迎与我联系

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26736162/viewspace-2082965/,如需转载,请注明出处,否则将追究法律责任。

    展开全文
    cpongo3 2016-04-17 20:43:01
  • weixin_34547883 2021-01-19 00:42:00
  • tchic 2016-09-12 12:40:20
  • Aritem 2017-11-15 10:39:56
  • okhymok 2019-12-23 21:49:46
  • beiya123 2017-01-06 14:42:31
  • a261017250 2020-02-20 10:57:41
  • weixin_34886431 2021-04-30 11:21:43
  • weixin_30784141 2013-09-30 03:36:00
  • Plynest 2019-07-17 16:17:27
  • weixin_29630465 2021-01-19 00:41:57
  • changxuan1568 2019-09-18 07:09:41
  • culuo4781 2020-07-27 13:26:29
  • tianmingt 2015-12-03 15:11:00
  • weixin_31452537 2021-04-30 09:44:30
  • 10KB longqiyuan 2019-03-29 20:47:57
  • ruyi574812039 2015-12-20 13:31:07
  • beiya123 2019-07-26 15:44:50
  • gumengkai 2017-01-07 18:03:02
  • weixin_29137489 2021-04-30 07:40:56

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 25,725
精华内容 10,290
关键字:

truncate之后数据恢复