MyISAM表的.frm文件丢失后的恢复方法

MyISAM表的.frm文件丢失后的恢复方法:

1、创建实验用的MyISAM表t1,并插入数据:

mysql> create table t1(id int) engine=myisam;

Query OK, 0 rows affected (0.01 sec)

mysql> insert into t1 values(1),(2),(3),(4),(5),(6),(7),(8);

Query OK, 8 rows affected (0.00 sec)

Records: 8  Duplicates: 0  Warnings: 0

2、删除t1表的.frm文件

[[email protected] gusha]# cd /var/lib/mysql/gusha

[[email protected] gusha]# ls

db.opt     t1.MYI    t1.frm  t1.MYD

[[email protected] gusha]# rm -rf t1.frm

此时在gusha库里已经查询不到t1表了:

mysql> show tables;

Empty set (0.00 sec)

还能查询t1表里的内容是因为有缓存,清下缓存:

mysql> select * from t1;

+------+

| id   |

+------+

|    1 |

|    2 |

|    3 |

|    4 |

|    5 |

|    6 |

|    7 |

|    8 |

+------+

8 rows in set (0.00 sec)

mysql> flush tables;

Query OK, 0 rows affected (0.00 sec)

mysql> select * from t1;

ERROR 1146 (42S02): Table ‘gusha.t1‘ doesn‘t exist

3、进行恢复,把gusha库对应的文件夹里的t1.MYD和t1.MYI文件移动到其它文件夹:

[[email protected] gusha]# mv t1.MY* /var/lib/backup/

[[email protected] gusha]# ls

db.opt

在gusha库里重新创建一个t1表,表结构和原来的t1表一样:

mysql> create table t1(id int) engine=myisam;

Query OK, 0 rows affected (0.00 sec)

把t1.MYD和t1.MYI文件移动会gusha库对应的文件夹:

[[email protected] gusha]# mv /var/lib/backup/t1.MY* .

mv: overwrite `./t1.MYD‘? y

mv: overwrite `./t1.MYI‘? y

此时MySQL会自动修复t1表

mysql> select * from t1;

+------+

| id   |

+------+

|    1 |

|    2 |

|    3 |

|    4 |

|    5 |

|    6 |

|    7 |

|    8 |

+------+

8 rows in set (0.00 sec)

如果没有自动修复,则执行下面命令进行修复:

mysql> repair table t1;

+----------+--------+----------+----------+

| Table    | Op     | Msg_type | Msg_text |

+----------+--------+----------+----------+

| gusha.t1 | repair | status   | OK       |

+----------+--------+----------+----------+

1 row in set (0.00 sec)

到此MyISAM表t1.frm丢失后又恢复回来了

更多精彩MySQL内容 请关注我:

时间: 2024-10-11 07:14:44

MyISAM表的.frm文件丢失后的恢复方法的相关文章

ORACLE数据库文件丢失后的恢复测试

一.测试环境 数据库版本是11GR2,在做完一份完全备份之后,关机,做一份快照,每一次开机之后都执行数次alter system switch logfile以产生归档日志. 之后的测试都是基于这么一个完全备份来恢复. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/backup/%F'; backup incremental level 0 format '/backup/%T_%f' database; 二.

Oracle在线 redo log文件丢失后的恢复

今天一个开发库启动不了了,发过来报错一看是日志文件损坏了(见下图),接着说了一下前因后果.说是年前服务器掉电了,然后就再没有启动起来过.今天有人用才想到要处理. 先说一下大体的思路,如果损坏的redo log是INACTIVE状态的,也就是实例崩溃恢复用不到的redo log,那处理起来比较容易,直接alter database clear logfile group #;或alter database clear unarchived logfile group #;重建日志组就行了.建议重建

[课]9.2模拟数据库,表空间和数据文件损坏后的恢复操作

1环境准备 对数据库做一次全备份: 验证当前的备份文件: 2数据库损坏的恢复 2.1模拟数据库损坏 尝试重启数据库查看报错: 这里需要重点说明的是因为我们用的是CATLOG数据库作为目录数据库,所以即使控制文件丢失也不影响我们进行恢复. 现在我们查看一下告警文件的报错: 2.2进行数据库恢复 3表空间损坏的恢复 3.1模拟表空间损坏 查看当前库的表空间,现在我们就模拟TEST_MSSM和TEST_ASSM表空间损坏. 删除表空间文件: 重启数据库查看报错信息: 我们查询一下告警文件里的错误信息:

丢失了所有控制文件副本后进行恢复 以trace文件恢复

实验:基于trace的控制文件重建及数据库回复(所有控制文件丢失等) 1.测试数据的构造,创建只读表空间 create tablespace tbs_users datafile '/u01/app/oracle/oradata/PROD/datafile/tbs_users1.dbf' size 5m, '/u01/app/oracle/oradata/PROD/datafile/tbs_users2.dbf' size 5m; alter tablesapce tbs_users read

[网络课摘抄]8.1模拟控制文件丢失后的数据库恢复(完全恢复)

1.环境准备 1.1确认数据库版本 1.2确认数据库归档 1.3备份数据库文件 2模拟控制文件丢失后的数据库恢复(完全恢复). 2.1查看控制文件位置 2.2执行操作后删除控制文件 2.3启动数据库 启动数据库的时候发现数据库发生了报错,提示无法确认控制文件,检查告警文件,我们现在检查一下告警文件里的信息: 2.4重建控制文件 对于日志和数据文件都完整的情况下,如果只是控制文件丢失,那么重建控制文件是最好的一种解决方式,一般重建控制文件能够解决99%的问题,现在我们就重建控制文件. 2.5尝试打

照片或特殊文件丢失后 采用winhex脚本进行数据恢复方法

照片或特殊文件丢失后 采用winhex脚本进行数据恢复方法 1:打开winhex,打开一个正常的图片文件如:JPG CR2 BMP;  视频类文件  MP4 WAV RMVB MTS MOV ; 办法文档文件如DOC XLS PPT MDB等.查看文件前8-16位字节,然后保存下来.这就是我们要找的文件头. 最好,使用同一个相机生成的照片,或同一电脑保存的文档进行取样. 2:确定文件头后,我们就可以用winhex打开要恢复的硬盘或分区,进行全盘扇区扫描式查找.查找到的文件一定要保存到另外一块硬盘

[Oracle]System 表空间的文件丢失

如果system 表空间的文件丢失,假设有备份的情况,可以恢复.数据库需要设置为mount 状态,然后restore/recover datafile 模拟实验: SQL> select name from v $ datafile; NAME-------------------------------------------------------------------- ------------------------------/u01/app/oracle/oradata/ORA11

【1.1】mysql frm文件丢失(ibd文件丢失)

[1]故障模拟准备环境 这里以innodb为例 [1.1]配置参数 开启独立表空间 innodb_file_per_table; [1.2]构建测试数据 create database test; create table a(id int,num int); insert into  a values(1,11),(2,12); [2]故障模拟 [2.1]在业务正在运行的情况下,手动删除 test库 下的 a.frm [2.2]删除完之后,会发生什么? 如上图所示可知(在业务还在跑的情况下):

ORACLE模拟临时文件、日志成员、口令文件丢失情况与恢复【weber出品】

一.临时表空间文件.日志文件和口令文件都属于非关键性文件,因为这些文件丢失后并不会影响到整个数据库的完整性. 但是,当这些文件丢失后我们需要快速的找回这些文件.接下来我将模拟临时表空间文件.日志文件和口令文件丢失的情况. 二.如果属于 TEMP 表空间的临时文件丢失或损坏,则 TEMP 表空间将不可用.例如:在执行需要 TEMP 空间进行排序的 SQL 语句过程中,此问题将声明其为错误. 一般会用到临时表空间的场景有: 索引create或rebuild Order by 或 group by D