2008-07-04 Fri

09:15 Log Buffer #104: a Carnival of the Vanities for DBAs (7311 Bytes) » Pythian Group Blog » Log Buffer

Andrew Clarke has published to 104^th edition of Log Buffer, the weekly review of database blogs, on Radio Free Tooting, marking LB’s second year. Happy Birthday, LB!

Log Buffer always needs editors, so if you you’d like to present your view of the week that was in DB blogs, contact me, the Log Buffer coordinator. You’ll be joining some of the best bloggers around, and making yourself and your blog a little better known to readers around the world.

And now, here’s Andrew Clarke’s Log Buffer #104.

P.S.: To our readers in the U.S. — Happy 4^th of July!

These icons link to social bookmarking sites where readers can share and discover new web pages.

08:16 浪潮之巅第九章硅谷的另一面（四） (6706 Bytes) » Fenng's shared items in Google Reader

发表者：Google（谷歌）研究员吴军

1. 成王败寇

2. 嗜血的地方

3. 机会均等

4. 硅含量不断降低

旧金山湾区之所以得名硅谷是因为早期这里的公司大多数是半导体公司或者计算机硬件公司。我们前面介绍的惠普公司虽然不能算是一家半导体公司，但它是以计算机和仪器等硬件为主的公司，可以算是硅谷早期主流公司的代表。但是，最早诞生于硅谷的真正的半导体公司是仙童半导体（Fairchild Semiconductor）。

今天知道仙童公司的人已经不多了，但它在半导体历史上占据着独一无二的地位。仙童半导体公司是从夏克利半导体（Shockley Semiconductor）“叛逃”的科技史上著名的“八叛徒”（Traitorous Eight）创办的。其中最有名的是后来英特尔公司的创始人、摩尔定理的提出者戈登·摩尔和集成电路的发明人罗伯特·诺伊斯（Robert Noyce）。仙童半导体公司在五十年代末制造出世界第一个商用半导体集成电路。（注释：对于是谁第一个发明集成电路，现在仍有争议，德州仪器公司的专利比仙童的早，但是，仙童是世界上第一个做出了实用产品的）尽管现在仙童公司早已江河日下了，但是每一个计算机用户一定知道它的两个孩子—英特尔公司和 AMD 公司。

自仙童以后，在旧金山湾区诞生了许许多多的半导体公司，包括今天世界上最大的半导体公司英特尔，旧金山湾区从此赢得了硅谷之名。直到八十年代，半导体和计算机硬件一直是硅谷的支柱产业，其中著名的半导体公司还有国家半导体和 Maxim 等公司，而中小公司就更是不计其数了。在九十年代前，硅谷著名的大公司有：惠普，英特尔，Sun，SGI，IBM （Almaden），甲骨文（Oracle），苹果，3Com， Seagate，AMD，国家半导体（National Semiconductor）。其中只有 Oracle 是以计算机软件和服务为主的公司， IBM 的 Almaden 实验室基本上是一半软件（DB2）一半硬件（存储设备），其余都是半导体公司或者计算机硬件公司。这段时间可以称得上是硅谷半导体公司的黄金时代。

但是九十年代后，虽然硅谷的半导体业还在发展，新的半导体公司还在诞生，但是，半导体在硅谷经济中的比重已经大大不如以前了。2000 年后，硅谷最大的公司是思科，谷歌，英特尔，IBM，甲骨文，苹果，惠普，雅虎，基因科技（Genentech）和 Ebay。其中谷歌，雅虎和 Ebay 是互联网公司，IBM 将存储设备部门卖给了日立公司后在 Almaden 是一个纯软件和服务的公司，而基因科技干脆就不是 IT 科技公司，而是世界上最大的生物制药公司。它们都和半导体毫无关系。即使是英特尔，也已经将其工厂迁到美国其它州以及海外，它甚至逐步将研发部门迁到费用低廉的亚利桑那和俄罗冈州。进入二十一世纪后，硅谷在世界经济和科研上的地位有增无减，半导体在全世界经济中所占的分量仍然在增加，只是硅谷的核心产业越来越远离半导体了。

造成硅谷半导体衰退的直接原因有两个，首先是反摩尔定理的效应。由于半导体的价格每十八个月降一半，当一个公司研制出来一个新的芯片以后，它不能指望像制药公司那样随着销量的上升而不断增加利润，因为用不了多少时间，这个芯片的利润就薄得必须淘汰了。整个半导体工业天天都在为利润率发愁。从这个角度讲，半导体工业很难在费用高的硅谷长期发展。我们前面提到，硅谷是一个拒绝平庸的地方，当一个行业的利润率无法维持硅谷高昂的费用时，它就必须搬出硅谷。

其次是“亚洲制造”效应，由于硅谷靠半导体和计算机硬件起飞，在七十年代它便聚集了很多半导体和计算机硬件的专家和工程师。同时，也促进了斯坦福大学和伯克利加大电机工程系的发展。这些人或者从仙童等第一代半导体公司跑出来，或者离开斯坦福和伯克利，开始了第二轮的半导体公司和计算机硬件公司的创业。其中的代表者包括开发和制造 RISC 处理器的 MIPS 公司，Sun 公司和 SGI 公司，以及 LSI 等中大等规模的公司。这些公司大部分还是由美国人为主创办。在第二代公司中有大量亚裔的工程师和主管。他们通过第二轮半导体的创业，积累了财富和经验，其中一些人后来成为世界第三轮半导体公司创业的中流砥柱。等到有大量亚裔专家出来再创办半导体和计算机公司时，他们很容易将制造甚至设计部门移到成本比美国低很多的东亚尤其是中国台湾，而只在硅谷保留科研部门。这时期最有代表性的包括当今世界上最大的显卡公司 Nvidia。其创始人黄仁勋，生于台湾，毕业于斯坦福，任职于 LSI 和 AMD，然后创办 Nvidia。这时在硅谷半导体时代创业最经典的例子。当硬件制造业移到台湾后，半导体业的整体利润就被大大地压缩了，从此改变了半导体和计算机硬件行业的游戏规则。于是以前的半导体公司为了竞争的需要都纷纷将工厂外移。到后来，大家发现一些低端的设计亦可以拿到台湾去做，硅谷的硅含量就越来越低了。

硅谷兴起于半导体工业，三十年前，硅谷就是半导体的同义词。但是现在半导体工业在硅谷的比重在不断下降。世界上很多城市因为一个产业而兴起，比如德国的鲁尔兴起于采煤和炼钢、美国的匹兹堡和底特律分别靠钢铁业和汽车业发达，但是，随着这些工业的饱和和衰落，相应的城市也渐渐衰落了。二十年前，当半导体公司开始离开硅谷时，不少人也怀疑过是否早晚有一天硅谷会步匹兹堡和底特律的后尘，二十年过去了，这种因产业变革带来的地域性衰退并没有在硅谷发生。事实上，没有了半导体，硅谷反而更加繁荣了。

硅谷没有了硅，那么留下了什么呢？

07:30 Jiffy -- 端到端的 Web 性能评测框架 (4719 Bytes) » DBA notes

作者：Fenng 发布在 dbanotes.net. | 转载文章是对互联网的伤害

前面几天介绍的 Web 前端优化最佳实践 系列离不开一个关键词：YSlow。简单的说，YSlow 是以最佳实践得到的规则为基础，进行 Web 页面的性能评估，并给出指导建议。

而 Velocity 2008 上发布的 Jiffy ，我断言是一个比 YSlow 更有前途的工具，只是当前还没引起足够的关注度。之所以说 Jiffy 更有前途，是因为 Jiffy 设计初衷是面向端到端的，不只是个工具（Jiffy 有基于 FireBug 的插件 Jiffy Firebug Extension for Firefox ），而变成了框架，对于 Web 上的每个组件，都能进行性能度量。如果说 YSlow 是类似"望闻问切"的诊断方式，那么 Jiffy 就是 CT 检查了。

下图揭示了 Jiffy 的工作机制：

通过页面中植入 Jiffy.js ，针对 Apache 做特定的设置，当用户调用页面的时候，拦截并记录 Jiffy 的相关请求，接着把所有的性能信息注入数据库中，然后从数据库中抽取数据进行展现。这正是当前绝大多数 Web 公司都缺少的性能衡量策略(尤其是 JavaScript 的精细度量)。唯一美中不足的是使用 Oracle XE 做性能信息存储的数据库，相信不就会完美支持 MySQL 。

关心 UE 的朋友可以在自己的环境里面搭一套 Jiffy 啦，有好处没坏处。

--EOF--

相关文章|Related Articles

评论数量(2)|Add Comments

本文网址：http://www.dbanotes.net/web/jiffy.html
最近作者还说了什么? Follow Twitter / Fenng

DBA notes 理念: 用最简约的技术取得最大的收益!

07:07 财务是否为ERP的核心？ (4118 Bytes) » Fenng's shared items in Google Reader

我在google的reader里头订阅了Oracle ERP 字眼，今天给我发了个 ERP雾里看花，名字够吸引人吧？我也来吸引人一把，财务是否是ERP的核心？来个倒叙，根据唯物辩证主义，此命题答案是：说法欲盖弥彰，偷梁换柱。为啥如此回答，请看下面分析：

1，为什么要上ERP？
不同的企业有不同的观点，小部分观点是赶时髦，装门脸。大部门企业呢？是企业的老总不知道现在企业的现状，越来越不好管理，是需要整合的时候。企业的老总最关心不外乎2件事，我们的企业的产品在外面市场咋样？我们企业的钱管得咋样？这2件事管好之后，老板才会去考虑，我们的市场还行，现在企业每天的（钱进－钱出）是一个比较理想的数值，那么我们的企业是否能做得更好呢？所以，这就来了，投入跟产出是否达到了最佳配置呢？因此，前端的MRP，后端的采购就成为需要被重点关注的内容，如上所述都已经达到最佳配置了，那么，老板才可能去思考企业的未来，10 年， 20年，或者更远，我们的企业需要成长为什么样的企业，这下子，商业决策就应运而生了。因此，如果作为一个优秀的business analyst ，不是时时把成本，把钱，就象李连杰一样，虽然读的书不多，英语也不好，但是总把数字，2个字挂在嘴边。 ERP 的结果干嘛，出数字呗？什么样的数字老板喜欢，真真假假的数字老板都喜欢，但是要真真实实的告诉他，是什么样的数字导致了企业的现状，老板也不是白当的，自个儿会去想方法解决。说到底，为什么上ERP，就是要出数字。那么，逻辑就很清楚了，什么样的数字是企业的核心。（因为今天多吃了个馒头，决定多谈点），关于上ERP 这个上字，为什么要上字，而不用推，造，玩，等等呢？因为企业也有风险意识，同时老板也是聪明人，想借鉴别人，别人能拿那么多钱，是为啥？人家肯定有某些方面比我们好，所以上字的原因，就是为了节约成本，让数字更好看一些，然后借鉴别人的经验。

2，什么样的数字是企业的核心？
ERP 是管人流，物流，钱流，信息流，这4流其实都很重要，但是对于刚要蓬勃发展的企业而言，市场，产品卖得咋样的数字，钱的数字，是老板最关心的。因此，这样就导致了很多企业都期望上 ERP ，能让这部分数据更清晰。从上ERP的初期目的而言，就是销售，财务是企业的核心，老板期望把这部分数据清晰，明朗化。也就是对应Oracle ERP 里头的 OM －> AR -> GL 这条线。接着，第2核心的东西，往上扩展，就是 PDM，往下扩展就是CRM。因此，就形成了 CRM －> PDM -> MRP －> ERP -> SCM 这样一条整个的企业的信息链。这样其实刚好Mapping了人流，信息流，钱流，物流这样里头的核心。数字的企业核心，其实在企业的不同阶段进行表现的。从企业的发展角度而言，在所有的核心中，财务只是一个核心，并不能说财务是 ERP 的核心。正确的说法是： ERP的核心中，财务是一个。在上面的信息链中， ERP 环节，销售，财务，是2个核心。

所以，读完上述文字，我们也知道，如果你刚好在做关联企业的命运数据，你是幸运的，你是在在帮老板管数字的，但是同时也请遵守职业道德，这是个企业，这个企业是要生存的。这些数字对企业很重要。

Note: 本文的的观点仅代表本人看法,请勿有效模仿。
转载请标注：来自 www.xiaobaicai.com

05:53 搞笑：采访朱坚强 (791 Bytes) » Fenng's shared items in Google Reader

Shared by Fenng
这肯定是央视的记者！

问：你被困了36天，现在被救出来，你觉得你是幸运的吗？
答：幸运个屁，猪油都涨价了，我却瘦成这样了！

问：你为什么吃木炭呢？（好有水平的记者）
答：你以为我不想吃地瓜啊！

问：你被救出来的时候，你知道你在下面被埋了多少天了吗？
答：你这猪头，明明知道我是猪了还问，我哪里会算啊！

问：你还有亲人吗？
答：几个兄弟姐妹在地震前被卖到屠宰场了，不知道隔壁家的母猪还在不？
...

04:38 [技术报告]C10K问题---epoll简介 (530 Bytes) » Fenng's shared items in Google Reader

Shared by Fenng
终于又有人关注 C10K 了

简介：编写连接数巨大的高负载服务器程序时，经典的多线程模式和select模式都不再适用。应当抛弃它们，采用epoll/kqueue/dev_poll来捕获I/O事件。

全文链接：http://www.sogou.com/labs/report/1-1.pdf

03:36 申音:马化腾与李东生 (7697 Bytes) » Fenng's shared items in Google Reader

这两天想起来看了看TCL的股价，这家公司我跟踪已有六七年，基本算见证了它由盛而衰的全过程，最近似乎看到了拐点。TCL集团（000100）的股价是4元，市值105亿，TCL多媒体（HK:1070）已经是不折不扣的“仙股”，股价才0.29元，市值17亿,TCL通讯（HK:2618）的股价是0.20元，市值14亿多港币。

恰好看到链接的新闻说，6月中旬，TCL多媒体为了筹集约1.55亿美元资金用以赎回债券，向TCL实业、TCL多媒体管理层和独立第三方投资者在内的投资者定向发行股份。除了李东生、吕忠丽这些高管熟面孔，比较特别的是另外一位署名MaHuateng的男士，以独立第三方身份，通过其全资控股子公司AdvanceDataServiceLimitied认购TCL多媒体近3900万港元。

MaHuateng就是马化腾。于是又看了看腾讯。Tencent(HK:0700)的股价是60块，市值1070多亿港币，换句话说，今天的TCL三个上市公司合并的市值也仅为腾讯的12％。而如果论销售收入，TCL去年营收390亿元，腾讯去年营收38亿元，恰好TCL是腾讯的十倍多。

商业世界很残酷。老话说三十年河东，三十年河西。但今天财富的转移，企业的兴衰恐怕4年就已足够。

2004年腾讯登陆香港主板的时候，招股价只有3.75港币。QQ虽然坐拥几千万用户，却直到2003年才开始赚钱。而彼时，李东生正如日中天。当时，除了闭门不出的任正非，李东生就是广东企业家的带头大哥了。TCL通过两起海外并购，成了全球彩电大王，世界手机业七强，海外营收超过国内市场的营收，风头盖过联想。

四年后，QQ已经拥有了7亿注册用户，放眼全球互联网业，小马哥也算得上一号人物。而当年认为国内市场已经基本饱和的TCL，却在欧美市场碰得头破血流，而其大后方也被索尼、三星、夏普、海信等趁虚而入。

这4年，是中国经济飞速变化的四年。是价值、资金从制造业流向服务业，从实体经济流向虚拟经济，从世界工厂流向中国市场，从消费者经济流向用户经济的四年。马化腾的QQ恰逢其时，所以滚雪球般迅速发展。如果投资腾讯的股票，坚持4年就已经涨了近20倍。如果买TCL集团（000100）的股票，直到今天还是04年高位时的1/2。

但另一方面，商业世界又不乏温情。

听TCL的人说过，李东生很早就看好马化腾。两人是潮汕老乡，好像还有点亲戚关系。小马哥创业早期，因为互联网泡沫的破灭，一度撑不下去，李东生在马化腾最困难的时候，还出钱支持了一把。后来腾讯上市，李东生又应邀出任非独立执行董事，为其背书（查了一下腾讯07年的年报，李东生持有10万股腾讯的股票，占已发行股本的0.01％）。两家公司迄今仍比邻而居。

TCL遇到困难后，腾讯的拍拍网租了TCL大厦的整整一层。这次，马化腾又出钱支持，也算是知恩图报。

我相信TCL还会东山再起，正如中国这个大国离不开制造业一样。只是这个升级过程会很痛苦。而QQ代表的互联网服务业肯定会遭遇冬天，这是自然规律，迟早而已。

一个运作良好的商业世界应该有此两面。有优胜劣汰的竞争机制，顺时者昌，逆时者败，长江后浪推前浪，商业才能进步，社会才能发展。

同时，前辈提携后进，创业者能遇到“天使”，能得到管理的指点和帮助，总会大大提高成功率。成功人物知道“花无百日红”，可以预先播种，给自己另留条路。

李东生那么多投资里面，对人的投资也许是最值得的。直到今天，TCL内部仍有能撑起局面的人，可见其眼光不错。

总而言之，在你有能力的时候，多帮助别人。这不是施舍，这是投资。

comment

01:27 Recovering Innodb table Corruption (35439 Bytes) » MySQL Performance Blog

Assume you're running MySQL with Innodb tables and you've got crappy hardware, driver bug, kernel bug, unlucky power failure or some rare MySQL bug and some pages in Innodb tablespace got corrupted. In such cases Innodb will typically print something like this:

InnoDB: Database page corruption on disk or a failed
InnoDB: file read of page 7.
InnoDB: You may have to recover from a backup.
080703 23:46:16 InnoDB: Page dump in ascii and hex (16384 bytes):
... A LOT OF HEX AND BINARY DATA...
080703 23:46:16 InnoDB: Page checksum 587461377, prior-to-4.0.14-form checksum 772331632
InnoDB: stored checksum 2287785129, prior-to-4.0.14-form stored checksum 772331632
InnoDB: Page lsn 24 1487506025, low 4 bytes of lsn at page end 1487506025
InnoDB: Page number (if stored to page already) 7,
InnoDB: space id (if created with >= MySQL-4.1.1 and stored already) 6353
InnoDB: Page may be an index page where index id is 0 25556
InnoDB: (index "PRIMARY" of table "test"."test")
InnoDB: Database page corruption on disk or a failed

and crash with assertion failure.
So what can you do to recover such a table ?

There are multiple things which can get corrupted and I will be looking in details on the simple one in this article - when page in clustered key index is corrupted. It is worse compared to having data corrupted in secondary indexes, in which case simple OPTIMIZE TABLE could be enough to rebuild it, but it is much better compared to table dictionary corruption when it may be much harder to recover the table.

In this example I actually went ahead and manually edited test.ibd file replacing few bytes so corruption is mild.

First I should note CHECK TABLE in INNODB is pretty useless. For my manually corrupted table I am getting:

PLAIN TEXT

SQL:

mysql> CHECK TABLE test;
ERROR 2013 (HY000): Lost connection TO MySQL server during query
mysql> CHECK TABLE test;
+-----------+-------+----------+----------+
| TABLE | Op | Msg_type | Msg_text |
+-----------+-------+----------+----------+
| test.test | CHECK | STATUS | OK |
+-----------+-------+----------+----------+
1 row IN SET (0.69 sec)

First run is check table in normal operation mode - in which case Innodb simply crashes if there is checksum error (even if we're running CHECK operation). In second case I'm running with innodb_force_recovery=1 and as you can see even though I get the message in the log file about checksum failing CHECK TABLE says table is OK. This means You Can't Trust CHECK TABLE in Innodb to be sure your tables are good.

In this simple corruption was only in the data portion of pages so once you started Innodb with innodb_force_recovery=1 you can do the following:

PLAIN TEXT

SQL:

mysql> CREATE TABLE `test2` (
-> `c` char(255) DEFAULT NULL,
-> `id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT,
-> PRIMARY KEY (`id`)
-> ) ENGINE=MYISAM;
Query OK, 0 rows affected (0.03 sec)
mysql> INSERT INTO test2 SELECT * FROM test;
Query OK, 229376 rows affected (0.91 sec)
Records: 229376 Duplicates: 0 Warnings: 0

Now you got all your data in MyISAM table so all you have to do is to drop old table and convert new table back to Innodb after restarting without innodb_force_recovery option. You can also rename the old table in case you will need to look into it more later. Another alternative is to dump table with MySQLDump and load it back. It is all pretty much the same stuff. I'm using MyISAM table for the reason you'll see later.

You may think why do not you simply rebuild table by using OPTIMIZE TABLE ? This is because Running in innodb_force_recovery mode Innodb becomes read only for data operations and so you can't insert or delete any data (though you can create or drop Innodb tables):

PLAIN TEXT

SQL:

mysql> OPTIMIZE TABLE test;
+-----------+----------+----------+----------------------------------+
| TABLE | Op | Msg_type | Msg_text |
+-----------+----------+----------+----------------------------------+
| test.test | OPTIMIZE | error | Got error -1 FROM storage engine |
| test.test | OPTIMIZE | STATUS | Operation failed |
+-----------+----------+----------+----------------------------------+
2 rows IN SET, 2 warnings (0.09 sec)

That was easy, right ?

I also thought so, so I went ahead and edited test.ibd a little more wiping one of the page headers completely. Now CHECK TABLE would crash even with innodb_force_recovery=1

080704 0:22:53 InnoDB: Assertion failure in thread 1158060352 in file btr/btr0btr.c line 3235
InnoDB: Failing assertion: page_get_n_recs(page) > 0 || (level == 0 && page_get_page_no(page) == dict_index_get_page(index))
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

If you get such assertion failures most likely higher innodb_force_recovery values would not help you - they are helpful in case there is corruption in various system areas but they can't really change anything in a way Innodb processes page data.

The next comes trial and error approach:

PLAIN TEXT

SQL:

mysql> INSERT INTO test2 SELECT * FROM test;
ERROR 2013 (HY000): Lost connection TO MySQL server during query

You may think will will scan the table until first corrupted row and get result in MyISAM table ? Unfortunately test2 ended up to be empty after the run. At the same time I saw some data could be selected. The problem is there is some buffering taking place and as MySQL crashes it does not store all data it could recover to MyISAM table.

Using series of queries with LIMIT can be handly if you recover manually:

PLAIN TEXT

SQL:

mysql> INSERT IGNORE INTO test2 SELECT * FROM test LIMIT 10;
Query OK, 10 rows affected (0.00 sec)
Records: 10 Duplicates: 0 Warnings: 0
mysql> INSERT IGNORE INTO test2 SELECT * FROM test LIMIT 20;
Query OK, 10 rows affected (0.00 sec)
Records: 20 Duplicates: 10 Warnings: 0
mysql> INSERT IGNORE INTO test2 SELECT * FROM test LIMIT 100;
Query OK, 80 rows affected (0.00 sec)
Records: 100 Duplicates: 20 Warnings: 0
mysql> INSERT IGNORE INTO test2 SELECT * FROM test LIMIT 200;
Query OK, 100 rows affected (1.47 sec)
Records: 200 Duplicates: 100 Warnings: 0
mysql> INSERT IGNORE INTO test2 SELECT * FROM test LIMIT 300;
ERROR 2013 (HY000): Lost connection TO MySQL server during query

As you can see I can get rows from the table in the new one until we finally touch the row which crashes MySQL. In this case we can expect this is the row between 200 and 300 and we can do bunch of similar statements to find exact number doing "binary search"

Note even if you do not use MyISAM table but fetch data to the script instead make sure to use LIMIT or PK Rangers when MySQL crashes you will not get all data in the network packet you potentially could get due to buffering.

So now we found there is corrupted data in the table and we need to somehow skip over it. To do it we would need to find max PK which could be recovered and try some higher values

PLAIN TEXT

SQL:

mysql> SELECT max(id) FROM test2;
+---------+
| max(id) |
+---------+
| 220 |
+---------+
1 row IN SET (0.00 sec)
mysql> INSERT IGNORE INTO test2 SELECT * FROM test WHERE id>250;
ERROR 2013 (HY000): Lost connection TO MySQL server during query
mysql> INSERT IGNORE INTO test2 SELECT * FROM test WHERE id>300;
Query OK, 573140 rows affected (7.79 sec)
Records: 573140 Duplicates: 0 Warnings: 0

So we tried to skip 30 rows and it was too little while skipping 80 rows was OK. Again using binary search you can find out how many rows do you need to skip exactly to recover as much data as possible. Row size can be good help to you. In this case we have about 280 bytes per row so we get about 50 rows per page so not a big surprise 30 rows was not enough - typically if page directory is corrupted you would need to skip at least whole page. If page is corrupted at higher level in BTREE you may need to skip a lot of pages (whole subtree) to use this recovery method.

It is also well possible you will need to skip over few bad pages rather than one as in this example.

Another hint - you may want to CHECK your MyISAM table you use for recovery after MySQL crashes to make sure indexes are not corrupted.

So we looked at how to get your data back from simple Innodb Table Corruption. In more complex cases you may need to use higher innodb_force_recovery modes to block purging activity, insert buffer merge or recovery from transactional logs all together. Though the lower recovery mode you can run your recovery process with better data you're likely to get.

In some cases such as if data dictionary or "root page" for clustered index is corrupted this method will not work well - in this case you may wish to use Innodb Recovery Toolkit which is also helpful in cases you've want to recover deleted rows or dropped table.

I should also mention at Percona we offer assistance in MySQL Recovery, including recovery from Innodb corruptions and deleted data.

Entry posted by peter | One comment

Add to: | | | |

00:11 国家兴衰，匹夫有责 (942 Bytes) » 玉面飞龙的BLOG

最近真是不消停，看似波澜不惊，实际上是洪水猛兽。继今冬南方雪灾，先后发生多起天灾，5.12四川地震，入夏南方多个省市的洪涝灾害,重创了很多灾民和家庭。人定胜天，这是屁话。同时，发展的中国社会也激发了潜在的很多内部外部的矛盾。人祸也伴随其中，6.28事件，上海警局事件，网络上的各种流言蜚语，让人深刻思考,毕竟每个人都是社会主动或者被动发展的一分子。国际上，石油价格屡创新高，挑战实际非官方CPI。可悲可叹的是发展30年的中国仍然不是游戏规则的制定者。去年还有同事谈论”货币战争”是阴谋论。不知道是否将会体验经济衰退周期了。新闻每天都有，可是最近坏新闻额外的多。好新闻就是，我准备过几天的黄道吉日和女朋友领结婚证，希望大家都有好的运气。