Author: mac

TOOL TO UNDELETE DELETED Oracle RDBMS/DB USERS it seems to be impossible to undelete deleted users without restoring the DB is there however a undocumented (unsupported) workaround ? As it is very likely, this will happen … Can you pls Try Oracle PRM-DUL recovery TOOLS? It can be download here : http://www.parnassusdata.com/en

适用于： MySQL服务器版本4.1到5.6 [发行版4.1到5.6] 本文信息适用于所有平台。   目标 如何使用undrop for innodb从损坏的表中提取数据     解决方案 使用工具有时可能从无法用innodb_force_recovery读取的表中恢复数据。 undrop可以直接读取数据库的ibdata1文件，来获取数据字典信息和必要的恢复信息。 通常，该工具从整个（多个）ibdata文件且/或独立的InnoDB tablespace文件 (innodb_file_per_table在使用中的.ibd文件)提取索引页。Blob页被提取到可应用的另外的子目录 一旦数据被提取到索引页，下一步就是从数据目录恢复主键或一般聚类索引ID，然后将数据提取到适于使用LOAD DATA INFILE的文件。 如果可以的话，以要恢复的（多个）数据库的至少一个schema dump启动，需要时使用innodb_force_recovery。即使一个过时的备份也好过什么都没有。虽然UnDROP有时能从ibdata文件中提取一个有效表定义，它不擅于处理所有列类型。如果你完全没有备份，.frm文件能被用于重建表定义。如果你没有任何备份或.frm文件，那么最后一招就是UnDROP 能从idbata提取的表定义能尝试至少恢复一些数据。   首先stream_parser是用于从ibdata提取页的工具。它的使用很简单：   ./stream_parser -f <path_to_ibdata>   页会被默认提取到”pages-<ibdata_file_name>”。索引页被储存在子目录FIL_PAGE_INDEX，且blob页被储存在子目录FIL_PAGE_TYPE_BLOB。     要提取表的所有数据，有必要识别表的主键的数据目录索引ID (在没有主键时的一般索引)。这能通过使用UnDROP工具的”recover_dictionary.sh”脚本，将从被提取的索引页提取的字典数据放到在运行服务器的’test’ schema，像这样：   $ ./recover_dictionary.sh Generating dictionary tables dumps… OK Creating test database … OK Creating dictionary tables in database test:…

适用于： MySQL服务器版本5.0及以上 本文信息适用于所有平台。   症状 在MyISAM表使用DML (如inserts, deletes, selects,等)，以下错误可能发生：   101001 14:57:57 [ERROR] ./bin/mysqld: Table ‘./test/t2′ is marked as crashed and last (automatic?) repair failed     原因   Bug 11764345 –SHOW TABLE STATUS + SMALL MYISAM_SORT_BUFFER_SIZE IN REPAIR, TABLE CRASHE 当小的myisam_sort_buffer_size与repair by sort发生，且有人运行 ‘show table status’ 或引用表selects from information_schema tables，错误在日志中出现。 当check table在运行时，表不显示损坏。   解决方案…

适用于： MySQL服务器版本5.6及以上 本文信息适用于所有平台。 目标   在Windows系统，OPTIMIZE TABLE损坏了大于4GB的表。   解决方案 在Windows创建的bug引起损坏的发生： http://bugs.mysql.com/bug.php?id=69683 BUG 17235179 OPTIMIZE AFTER A DELETE RETURNS ERROR 0 CAN’T GET STAT OF MYD FILE 解决方案是升级到5.6.19或更新版本。 参考 BUG:17235179 –OPTIMIZE AFTER A DELETE RETURNS ERROR 0 CAN’T GET STAT OF MYD FILE http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news5619.html

适用于： MySQL 服务器版本4.0到5.7 [发行版4.0到5.7] 本文信息适用于所有平台。   目标 问题： InnoDB将像这样的错误打印到错误日志后，mysqld.exe崩溃：   130820 13:37:44 InnoDB: Operating system error number 1117 in a file operation. InnoDB: Some operating system error numbers are described at InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operatingsystemerrorcodes.html InnoDB: File operation call: ‘flush’. InnoDB: Cannot continue operation.   解决方案 建议：   这不是InnoDB或MySQL问题。 该问题是由于硬盘，控制器，驱动或操作系统。   ERROR_IO_DEVICE 1117 (0x45D) The request could…

适用于： MySQL服务器版本5.0及以上 本文信息适用于所有平台。   目标 学习引起InnoDB损坏最常见的原因以及你如何对其进行防护。   解决方案 InnoDB损坏的原因 InnoDB损坏四个主要的原因有： 硬件错误(通常是磁盘或内存) 崩溃 (例如由于断电或操作系统bug引起的) Bugs 不一致的备份   除了例如使用错误更正代码（ECC）内存外，防止硬件错误的措施很少。   对于由于断电引起的崩溃，UPS是最好的防护。对于有操作系统bug引起的崩溃 (幸好这些是很少发生的)，电池备份的磁盘能帮助避免部分写。通常使用innodb_flush_log_at_trx_commit = 1来确保你在同步写入磁盘。 但注意操作系统或磁盘可能并没有实际刷掉写入。因为这个电池备份磁盘是防护。   除非按照更改日志并检查是否需要更新，否则bug很难防护。你能在以下找到更改日志： MySQL 5.0 MySQL 5.1 MySQL 5.5 MySQL 5.6 MySQL 5.7   备份通常比预期的更常引起损坏 (包括不一致性，即在两个表中的数据不一致 )。这个情况的原因是即使有一个FLUSH TABLES WITH READ LOCK，InnoDB 将继续在底部写入数据文件。这表示即使备份方法对于比如MyISAM有作用，它可能对InnoDB不适用。   在所有情况中，建议经常备份并验证备份。   参考 https://dev.mysql.com/doc/relnotes/mysql/5.5/en/ https://dev.mysql.com/doc/relnotes/mysql/5.6/en/ NOTE:1023132.1 How to Create a…

如何理解Oracle中的incarnation概念？   小明 活到了90岁 这是incarnation A ， 这个matrix 矩阵世界里的 root (or oracle)管理员 将 小明世界的时间节点回退到了小明20岁时(同时resetlogs)，由于神的能力还不足以让这个宇宙里的一切量子变化都保证和之前的那一次完全一样，所以这次回退节点里的小明 是incarnation B，最后incarnation B的小明也会活到90岁。 虽然最后2个小明都90岁了，但这2个小明并不是一样的 ，他们都叫小明，但需要区别他们 所以一个叫incarnation A 另一个叫incarnation B。 在其他平行世界里可能还有其他 incarnation的小明，这取决于 root (or oracle)管理员的需求。

适用于： MySQL 服务器版本4.0及以上 本文信息适用于所有平台。   症状 在修复一个MyISAM表时，”Table ‘x’ is read only”错误是什么意思，如何修复它？   mysql> repair table t; +‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐ ‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ | Table | Op | Msg_type | Msg_text | +‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+ | test.t | repair | Error | Table ‘t’ is read only | | test.t | repair | status | Operation failed | +‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+   原因 这个错误有两个可能的起因：…

How to Recover a Corrupted InnoDB Table Definition File   适用于： MySQL服务器版本5.0及以上 本文信息适用于所有平台。 你会想要完整的show create table的表输出来重建定义文件。 目标 如何在没有可用备份的情况下重建损坏的Innodb表定义文件。   修复 以下文档显示如何恢复InnoDB 中的损坏的表定义文件而无需通过创建一个相同的虚拟表并将它的定义复制到损坏的表中来从备份恢复。     mysql [localhost] {msandbox} ((none)) > drop database test; Query OK, 5 rows affected (0.44 sec) mysql [localhost] {msandbox} ((none)) > create database test; Query OK, 1 row affected (1.38 sec) mysql…

适用于: MySQL 服务器4.0及以上 本文信息适用于所有平台   症状 当尝试在恢复后使用InnoDB，会发生以下错误。     ERROR ‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 120207 13:30:29 InnoDB: Error: page 573441 log sequence number 22 697197707 InnoDB: is in the future! Current system log sequence number 5 2916730276. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log…