Author: mac

适用于： MySQL服务器版本4.0及以上 本文信息适用于所有平台。   症状 当尝试访问表test.t1时，出现以下错误：   150512 16:30:01 [ERROR] MySQL is trying to open a table handle but the .ibd file for table test/t1 does not exist. Have you deleted the .ibd fil e from the database directory under the MySQL datadir, or have you used DISCARD TABLESPACE? See http://dev.mysql.com/doc/refman/5.1/en/innodb‐troubl eshooting.html how you can…

适用于： MySQL企业版备份版本3.5及以上 MySQL服务器版本4.0及以上 本文信息适用于所有平台。   症状 InnoDB引擎依赖于数据和日志文件的逻辑一致性。   InnoDB可能会遇到不可预知的行为，包括与来自不同环境的混合的文件损坏有关的崩溃和错误。   一个错误的例子： 2015‐03‐18 11:24:44 11904 [Note] InnoDB: Database was not shutdown normally! 2015‐03‐18 11:24:44 11904 [Note] InnoDB: Starting crash recovery. 2015‐03‐18 11:24:44 11904 [Note] InnoDB: Reading tablespace infor mation from the .ibd files… 2015‐03‐18 11:24:44 11904 [ERROR] InnoDB: Attempted to open a previously opened tablespace. Previous…

适用于： MySQL服务器版本4.1及以上 本文信息适用于所有平台。   症状 当尝试访问一个CSV表时，发生以下错误。 ERROR 1194 (HY000): Table ‘t1’ is marked as crashed and should be repaired   表的损坏不会总显示为以上错误。根据数据的损坏，SELECT可能有用，但会返回损坏的数据。   更改 这通常会发生在以下情况之后： MySQL的崩溃 – 这包括操作系统崩溃，如由于断电等情况 。 数据目录的磁盘不够。   原因 CSV表被损坏。像之前说到的，这通常由于非正常情况发生。   注：当 SELECT 语句由于损坏失败，INSERT 语句仍会运行，因为对于CSV表，插入行是一行或多行数据文件的简单追加。   你可以看到由于其表打开.CSV副本的损坏。例如，假设是表csvtest.t1，那么该文件是${datadir}/csvtest/t1.CSV，其中${datadir}是用于MySQL实例的数据目录。损坏通常会看起来像一行已被清空，且下一行在在同一列开始： 1,”2014-01-11 12:32:22″,”abc” 2,”2014-01-15 13:11:12″,”def” 3,”20144,”2014-01-28 18:00:19″,”jkl” 5,”2014-02-04 12:49:30″,”mno” 6,”2014-02-04 13:22:25″,”pqr”   在上面的示例中第三行被损坏且包含两部分： 3,”2014 这是被清空的行 4,”2014-01-28 18:00:19″,”jkl”…

适用于： MySQL服务器版本5.5及以上 本文信息适用于所有平台。   症状 尝试从GUI客户端创建函数语法如下：   CREATE FUNCTION `mydb`.`f_seq_gen` (`applicationid` text) RETURNS INT BEGIN DECLA RE nextval bigint(20); select seqno into nextval from mydb.seqgen where application_id = applicationid; update mydb.se qgen SET seqno = seqno + 1 where application_id = applicationid; RETURN nextval; END   但是失败了：     ERROR 1548 (HY000): Cannot load from…

适用于： MySQL服务器版本5.1到5.1 [发行版5.1] MySQL服务器版本4.0及以上 本文信息适用于所有平台。   症状 当尝试在例如断电的崩溃后启动MySQL时，发生类似以下的错误：   InnoDB: Assertion failure in thread 4096 in file fil0fil.c line 3959 InnoDB: We intentionally generate a memory trap. InnoDB: Submit a detailed bug report to http://bugs.mysql.com. InnoDB: If you get repeated assertion failures or crashes, even InnoDB: immediately after the mysqld startup, there may be InnoDB:…

适用于： MySQL服务器版本5.5到5.5 [发行版5.5] 本文信息适用于所有平台。   症状 当重新启动MySQL5.5.20或5.5.21时，MySQL无法启动，并且在错误日志中出现以下错误：   121215 11:25:25 InnoDB: Error: data file /mysql_data/mysql_databases/ibdata2 uses page size 1024, 12121 5 11:25:25 InnoDB: but the only supported page size in this release is=16384 121215 11:25:25 InnoDB: Could not open or create data files.   报告的ibdata2页大小可以有除了1024的其他尺寸。   更改 这个问题通常在使用ALTER TABLE语句改变一个InnoDB表的KEY_BLOCK_SIZE属性时发生，例如从一个未压缩表切换到压缩表时。   原因 这是由于防止从MySQL5.6降级的更改而造成的复原，其支持除16k以外的页大小。   参见 Bug…

适用于： MySQL服务器版本5.0到5.6 [发行版5.0到5.6] 本文信息适用于所有平台   目标 如果在访问表时你看到以下错误信息，这表示表结构文件.frm已被损坏。   ERROR 1033 (HY000): Incorrect information in file: ‘./world/Country.frm'”   解决方案 如果.frm文件已被严重损坏，那就没有简单的方法来恢复它。你能从备份中恢复表，或按照以下的解决方法：   假设你有表结构，在同一服务器的另外数据库中创建一个类似的表。 现在从其他数据库将.frm文件复制到world数据库: cp Country.frm <datadir>/world/ 检查文件的权限，并确保新复制的文件与现有的文件是相同的所有者和组， 现在，你应该能够用现有数据访问表 你现在可以正常执行所有表操作。   注：你能在线操作，不需要重启。但是要确保表在活动时无法被任何线程访问，这可能会再次导致崩溃。   Keywords ERROR MESSAGE; FRM; RECOVER; TABLE STRUCTURE

  适用于： MySQL服务器版本4.0及以上 本文信息适用于所有平台。   症状 MySQL服务器由以下信息崩溃：   InnoDB: Database page corruption on disk or a failed InnoDB: file read of page   原因 为了保护数据，InnoDB使用校验和（与页储存在一起）。当InnoDB从磁盘读取时，它计算每个页的校验和，并与磁盘加载的校验和进行比较。如果值是不同的，可能真的发生了一些错误。InnoDB将关闭MySQL服务器，以防止进一步的逻辑或物理损坏。   解决方案 如何找出损坏发生的原因 没有通用的解决方案。最典型的是有一些硬件问题，例如：物理磁盘或内存故障，坏的驱动器/控制器，甚至操作系统内核的bug。下面是一些建议：   在Linux平台上，有时会重置页缓存能解决这个问题： echo 2 > /proc/sys/vm/drop_caches 检查系统日志有没有可能的硬件故障。 如果InnoDB每次在特定页崩溃，最典型的是物理磁盘发生故障：运行对于你的OS /硬件的详细磁盘诊断。 如果崩溃是随机的且不在相同查询重复，可能是RAM故障：运行详细的RAM诊断。 在MySQL关闭时，用innochecksum工具检查InnoDB文件是有帮助的。   如何从损坏中恢复 最重要的是执行详细的硬件诊断，以消除问题扩散的机会。如果操作系统I / O缓存是磁盘读损坏的原因，重置缓存或重新启动操作系统应有助于消除当前的问题，数据库可能会重新运作。   有时唯一的解决办法是在有效恢复模式下备份数据。Sometimes the only   参考 http://dev.mysql.com/doc/en/forcinginnodbrecovery.html http://dev.mysql.com/doc/en/innochecksum.html

この文はOracleに壊れたブロックに対して、どうやって対応できるかを検討する文である。このあと、主な対応法が紹介するので、完全に読みきった前に、勝手に手を打たないでください。   ファイル履歴レコード この文に掲載したすべてのSQL文もSQL*Plusに適用する。あるいはSYSDBAとして。リンクする時に、server manager（ Orale7/8.0）にも適用する。（例えば“connect / as sysdba”或“connect internal”） サマリー この文はOracleに壊れたブロックに対して、どうやって対応できるかを検討する文である。このあと、主な対応法が紹介するので、完全に読みきった前に、勝手に手を打たないでください。 この文は壊れたメモリーブロック問題について、検討していない。 注意：もし起動するときに、ORA-600[17XXX]タイプエラが出たら、地方のサポートセンタに連絡してください。 Doc 106638.1-このファイルはお客様に見せられないが、経験豊かな技術員がその中の一部なステップを提供してもいい。 この文で、いろんなタイプなミスを紹介した、ほかのいろんなところにもこの文を使える。大事なのは以下壊れたブロックについての情報を知るべきだと思う： 壊れたブロックを含むファイルの番号（file number） この文で&.AFNと言う。 壊れたブロックを含む名 この文で&.FILENAMEと言う。 （ファイル番号を知ったが、ファイルなを知らない場合に、V$DATAFILEでファイル名を獲得する： SELECT name FROM v$tempfile   WHERE file#=(&AFN – &DB_FILES_value);   )   ファイル番号がOracle8iのV$DATAFILEに映していない、&AFNがDB_FILESバラメタ値に超えた場合に、そのファイルが一時的なファイルかもしれない。この場合に以下の問合せでファイル名を見つけ出せる： SELECT name FROM v$tempfile   WHERE file#=(&AFN – &DB_FILES_value);   )   ファイルの中のブロック番号 この文で&.BLと言う。 影響を受けたブロックのテーブルスペース番号と名を含んで、この文で“&TSN”と“&TABLESPACE_NAMEと言う。 これについての情報を知らない場合に、以下の問合せで見つけ出してください： SELECT ts# “TSN”…

Data Record/rows is deleted in Oracle , it just means the row piece has been flagged as deleted, but we can still extract the record/rows from underlying disk . This can be done by bbed or PRM-DUL (http://www.parnassusdata.com/en). the flag info can be : struct kdrh   /* row header structure for passing as an…