Maclean’s Oracle Database Tech Blog Archives

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复! 诗檀软件专业数据库修复团队 服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]     [oracle@vrh8 ~]$ oerr imp 8 00008, 00000, “unrecognized statement in the export file: \n %s” // *Cause: Import did not recognize a statement in the export file. Either // the export file was corrupted, or an Import internal error has // occurred. // *Action: If the…

表结构存储在.frm文件和InnoDB数据字典中。有时，通常在数据恢复问题中，我们需要恢复这些结构，以便能够找到丢失的数据或只是重建表。   有不同的操作方式，我们已经在博客中已经写过。例如，我们可以使用数据恢复工具从InnoDB字典恢复表结构，或使用MySQL服务器从.frm文件恢复。本文将是后者的更新。我会告诉你如何轻松从.frm文件恢复结构，在某些情况下，甚至不需要使用MySQL服务器。这将使过程更快，编写脚本更轻松。   MySQL 工具和mysqlfrm     MySQL工具是由Oracle发布的一组脚本，帮助我们更简单地执行常见的DBA任务。它是用Python编写的，它唯一的依赖是Python连接器。在各种工具的名单中，我们将使用mysqlfrm工具来帮助我们恢复结构。 像往常一样，图像胜过千言万语。我们恢复一些表结构： 这是我们的表：   CREATE TABLE `new_table` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(45) DEFAULT NULL, `age` tinyint(4) NOT NULL, PRIMARY KEY (`id`), KEY `name_idx` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1   现在我们尝试从.frm文件恢复该信息，看看结果：   $ mysqlfrm –diagnostic /usr/local/mysql/data/test/new_table.frm # WARNING: Cannot generate character set or collation names…

为什么InnoDB 需要字典     InnoDB字典是InnoDB用于维护用户表的各种信息的一组内部表。它作为人类和数据库之间的API。人类根据他们的名字参考表，而InnoDB通过整数标识符。字典存储表名和index_id之间的对应关系。 字典表是普通的InnoDB表，但对用户不可见。然而一些版本的MySQL在information_schema数据库中提供的字典只读访问。 字典被存储在ibdata1中。例如，SYS_TABLES的root页有id 8，所以它是ibdata1开头的第八页。 即使是MySQL 5.6，字典页也是冗余格式。我可能会在以后写更多关于记录格式的文章。现在只要知道冗余度是最早的记录格式就行了。它自4.0版本起可用，是当时唯一的格式。     SYS_TABLES     CREATE TABLE `SYS_TABLES` ( `NAME` varchar(255) NOT NULL DEFAULT ”, `ID` bigint(20) unsigned NOT NULL DEFAULT ‘0’, `N_COLS` int(10) DEFAULT NULL, `TYPE` int(10) unsigned DEFAULT NULL, `MIX_ID` bigint(20) unsigned DEFAULT NULL, `MIX_LEN` int(10) unsigned DEFAULT NULL, `CLUSTER_NAME` varchar(255) DEFAULT NULL,…

  unDROP for InnoDB 工具能用于恢复损坏的MySQL数据库。在这篇文章中，我们会展示当MySQL数据库的文件损坏，甚至innodb_force_recovery=6也无法帮助时，如何恢复数据库。   InnoDB表空间的损坏可能是多种原因造成的。一个即将报废的硬盘可能写入垃圾数据，导致页校验错误。然后InnoDB报告给错误日志：   InnoDB: Database page corruption on disk or a failed InnoDB: file read of page 4.   MySQL差劲的启动脚本是众所周知的。一个简单的升级过程可能出现两个mysqld的进程写入同一表空间的情况。这也会导致损坏。有时，电源复位不仅损坏InnoDB文件，而且使文件系统对操作系统不可用。 InnoDB 对于页的操作非常严格。如果校验不匹配或头中一些字段包含非预期值，InnoDB明智地倾向于崩溃，以避免进一步的损坏。 首先会尝试以innodb_force_recovery选项启动MySQL。此选项的目的是让用户转储其数据。由于无法修复表空间，用户必须删除表空间，创建新的，并加载回数据。 innodb_force_recovery 接受从1到6的值。值越高，InnoDB就会禁用越多功能。   在本文章，我们假设MySQL 即使在innodb_force_recovery=6的情况下也不能启动。   恢复工具包直接对InnoDB文件进行操作，它可以从InnoDB页面读取记录。如果页的某一部分被破坏，它将跳过那块，并继续进一步读取页的记录。 所以，我们来损坏一些InnoDB文件并对表进行恢复。   损坏InnoDB   简单起见，我们将重写.ibd 文件用户数据的一部分。   事情情况中，损坏可能发生在索引PRIMARY的任何地方。   在表sakila.actor的PRIMARY索引的中间，我们将数据用128个字符“A”重写：   0000C058  00 00 00 02 00 32 01 00 02…

适用于： MySQL集群版本6.3及以上 本文信息适用于所有平台。   症状 在特定情况下，系统表ndb_binlog_index可能被损坏。   当尝试执行以下查询时，这个损坏最常见的症状是ERROR 1194：     query: mysql> SELECT * from ndb_binlog_index; ERROR 1194 (HY000): Table ‘ndb_binlog_ index’ is marked as crashed and should be repaired   表损坏也能从MySQL错误日志中被证实：   Faile d to flush master info file Slave I/O thread exiting, read u p to log ‘log‐bin.NNNNNN’, position MMMMMMMMM Error reading…

适用于： MySQL服务器版本5.1及以上 本文档的信息适用于所有平台   症状 MySQL无法以运行中InnoDB存储引擎重启，你会在MySQL错误日志中看到像这样的错误：     InnoDB: Serious error! InnoDB is trying to free page 11200 InnoDB: though it is already marked as free in the tablespa ce! InnoDB: Assertion failure in thread 16363778 in file fsp0fsp.c line 2981 mysqld got signal 11 ;   页号和线程号会不同。在fsp0fsp.c源代码文件中的行可能也不同但文件相同。   原因 有三种可能的原因，从最可能到最不可能排序； 断电和写入缓冲开启或写入缓冲控制器没有运作的备用电池的磁盘驱动。 两个MySQL的备份尝试与同一InnoDB数据文件工作。 显示尝试与InnoDB同时运作的两个MySQL备份的错误日志中复制启动信息和时间戳检查。锁通常恩能够避免这个情况的发生。 在InnoDB插件版本中的关于blob存储的罕见错误在MySQL…

讨论 该错误可能在MySQL读取表文件，VIEW，.frm文件，logs文件，全文索引文件，或有时间区信息的文件时发生。   意外的EOF错误表示MySQL得到一个小于预期的文件。一般情况下，你不会得到这个错误。但它说明你有损坏的文件系统，或损坏的表文件或日志或其他文件。或者是由于在MySQL本身的错误发生。  

该错误表示MySQL在尝试锁一个文件时，接收到来自文件系统的错误信息。 该错误信息最常见的原因是外部应用访问MySQL数据文件。 这些情况通常包括： Mysql运行时运行文件备份过程 反病毒软件锁住文件(在Windows上) Mysql运行时myisamchk被错误使用 多个mysqld服务器访问同一数据文件 你对mysqld指定了 –external-locking选项且系统锁不可靠   考虑到–external-locking选项，它应该从my.cnf被移除，除非你运行多个mysqld daemon访问相同数据文件(不建议使用)。更多信息参见系统文档边缘的外部资源链接。

  MySQL Error: 1194 Table ‘%s’ is marked as crashed and should be repaired. 以上信息表示指定表由于意外硬件或一个MySQL服务器的崩溃而处于不一致的状态。要完整检查表的一致性，使用以下语句：   CHECK TABLE table_name EXTENDED;   以上语句会扫描在给定表的所有行和键，并报告发现的错误。 CHECK TABLE选项和输出的完整描述参见MySQL手册 (查看在边框的外部资源)。   如果你得到任何’OK’或’Table is already up to date’以外的状态信息，你应该正常运行表的修复。运行以下语句进行恢复：   REPAIR TABLE table_name EXTENDED;   以上语句会指示MySQL尝试恢复指定表并报告状态。 REPAIR TABLE选项和输出的完整描述参见MySQL手册 (查看在边框的外部资源)。

强制InnoDB恢复   为了研究数据库页损坏，你能用SELECT … INTO OUTFILE从数据库中转储表。通常，以这种方式获得的大部分数据是完整的。严重的损坏可能导致SELECT* FROM tbl_name语句或InnoDB的后台操作崩溃或断言，甚至造成InnoDB前滚恢复崩溃。 在这样的情况下，可以使用innodb_force_recovery选项强制InnoDB存储引擎启动同时阻止后台操作运行，这样你就能转储表了。例如，你可以在重新启动服务器之前添加以下行到选项文件的[mysqld]部分：   [mysqld] innodb_force_recovery = 1     警告   只有在紧急情况下将innodb_force_recovery设为大于0的值，你才能启动InnoDB并转储表。在进行此操作之前，确保你有数据库的备份副本，以备需要重建它。4及以上的值可以永久破坏数据文件。只有在数据库的独立物理副本的成功地测试了设置，才能在生产服务器实例使用4及以上的innodb_force_recovery设置。当强制InnoDB恢复，你应该总是以innodb_force_recovery=1启动，且仅在需要时增加值。   innodb_force_recovery默认为0（没有强制恢复的正常启动）。对于innodb_force_recovery允许的非零值是1至6。较大值包括较小值的功能。例如，为3的值包括所有的值1和2的功能。   如果你能以innodb_force_recovery为3或更低值转储你的表，那么你是比较安全的，只有在损坏的个人页的一些数据会丢失。4或更大的值被认为是危险的，因为数据文件可以被永久地损坏。值6被认为是严重的，数据库页被留在一个陈旧的状态，这反过来又可能带给B-trees和其它数据库结构更多的损坏。   作为一个安全措施，InnoDB 在innodb_force_recovery大于0时阻止INSERT，UPDATE或DELETE操作。对于MySQL5.6.15，将innodb_force_recovery设为4或更高会让InnoDB处于只读模式。   1 (SRV_FORCE_IGNORE_CORRUPT) 即使服务器检测到损坏的页仍让它运行。试图使SELECT* FROM tbl_name跳过损坏的索引记录和页，这样有助于转储表。   2 (SRV_FORCE_NO_BACKGROUND) 阻止主线程和任何清除线程的运行。如果崩溃会在清除操作中发生，该恢复值会阻止它。   3 (SRV_FORCE_NO_TRX_UNDO) 不要在崩溃恢复后运行事务回滚。   4 (SRV_FORCE_NO_IBUF_MERGE) 阻止插入缓冲合并操作。如果它们会导致崩溃，不要做这些。不计算表统计。这个值可以永久损坏数据文件。使用这个值后，准备好删除并重建所有辅助索引。在MySQL5.6.15中，设置InnoDB为只读。   5 (SRV_FORCE_NO_UNDO_LOG_SCAN) 在启动数据库时不检查撤消日志：InnoDB将即使未完成的事务也作为已提交。这个值可能永久损坏数据文件。在MySQL5.6.15中，设置InnoDB为只读。   6 (SRV_FORCE_NO_LOG_REDO) 在启动数据库过程中不检查重做日志文件：跳过恢复对重做日志进行前滚。这个值可能永久损坏数据文件。数据库页被留在一个陈旧的状态，这反过来又可能带给B-trees和其它数据库结构更多的损坏。在MySQL5.6.15中，设置InnoDB为只读。   你可以从表中SELECT来转储它们。innodb_force_recovery的值为3或更低，你可以DROP或CREATE表。在MySQL 5.6.27中，DROP…