您所在的位置:首页 > 企业救援 > SQL数据库修复专题

SQL数据库修复案例

故障解决方案

一、故障类型1
◆故障描述:ibdata1、MYI、MYD损坏
◆典型特征:
(1)数据库无法进行查询等操作    
(2)使用mysqlcheck和myisamchk无法修复数据库
(3)损坏程度星级评价:★★★
二、解决方案
◆检测流程:    
(1)对损坏的数据库进行备份,防止进一步破坏;
(2)手工对MYD和MYI文件进行内部结构检测;
(3)使用自主开发的程序对ibdata1文件进行检测;
◆实施流程:
(1)将损坏的数据库文件进行手工备份拷贝,以防止二次破坏;
(2)通过自主开发的程序对数据库进行完整检测;
(3)修复损坏的索引或数据文件;
(4)使用自主开发的程序对数据进行提取;
(5)生成数据库。
◆验收流程:
(1)挂载数据库,启动服务;
(2)对数据库做mysqlcheck检测;
(3)对重要表进行数据查询,检验数据的更新日期。
三、    数据恢复的可能
    数据库恢复的成功率视其损坏的程序而定。
四、    数据恢复所需时间
也因数据库大小而定,一般时间在1-2个工作日。
五、    服务费用
视数据表的个数及大小不同,价格也不同,恢复费用:3000元起/次

【小贴士】
◆发现数据库损坏后,请及时对数据库备份,不要在没有备份的情况下对数据进行任何修复操作。
◆故障出现的可能原因:
1.    数据库正在操作过程中,机器突然断电
2.    人为误操作或其它原因
◆隐患故障及损坏程度星级评价
隐患1.数据库损坏后未进行过任何修复操作
损坏程度星级评价:★★★
            隐患2.数据库损坏后,在未备份的情况下对数据库进行修复操作
            损坏程度星级评价:★★★★
◆文件保护措施
做好数据库备份工作

一、故障类型2
◆故障类型:数据库表记录删除
◆典型特征:
(1)数据表中无任何数据或只有部分数据
(2)客户端无法查询到完整的信息
◆损坏程度星级评价:★★★★
二、解决方案
◆检测流程:
(1)使用磁盘编辑器对数据文件MYD进行分析;
(2)判断表记录丢失的可能原因。
◆实施流程:
(1)将损坏的数据库文件进行备份;
(2)对数据库文件进行分析,判断丢失的可能原因;
(3)针对不同的丢失原因,使用自主开发的软件进行数据恢复;
(4)将数据插入原数据库,对数据库做完整性检测。
◆验收流程:
(1)对数据库做mysqlcheck检测;
(2)查询数据库最新记录;
(3)对用户指定的关键数据表进行针对性校验。
三、数据恢复的可能性
数据库的表记录删除后,如未做其它任何操作,因MYD内容结构的原因,数据恢复成功率不可达到100%。
四、数据恢复所需
时间视数据库大小而定,约为1-2天不等
五、服务费用
数据库表记录丢失:3000元起/次

【小贴士】
◆发现数据库表记录删除后,请及时对数据库备份,不要再进行数据插入等操作。
◆故障出现的可能原因:
1.对数据库进行升级,SQL语句条件不严格
2.人为操作错误
◆隐患故障及损坏程度星级评价
隐患1:数据库表记录丢失后未做任何操作
损坏程度星级评价:★★★★
隐患2:数据库表丢失后插入新的记录
损坏程度星级评价:★★★★★
◆数据库操作提示:
1.在对数据库进行操作时,尽量先对数据库进行备份;
2.对数据表进行操作时请慎重。

SQL数据库相关文档

在平时被问及最多的问题就是关于MySQL数据库性能优化方面的问题,所以最近打算写一个MySQL数据库性能优化方面的系列文章,希望对初中级MySQL DBA以及其他对MySQL性能优化感兴趣的朋友们有所帮助。
数据库属于IO密集型的应用程序,其主职责就是数据的管理及存储工作。而我们知道,从内存中读取一个数据库的时间是微秒级别,而从一块普通硬盘上读取一个IO是在毫秒级别,二者相差3个数量级。所以,要优化数据库,首先第一步需要优化的就是IO,尽可能将磁盘IO转化为内存IO。本文先从MySQL数据库IO相关参数(缓存参数)的角度来看看可以通过哪些参数进行IO优化:
•query_cache_size/query_cache_type (global)
Query cache作用于整个MySQL Instance,主要用来缓存MySQL中的ResultSet,也就是一条SQL语句执行的结果集,所以仅仅只能针对select语句。当我们打开了 Query Cache功能,MySQL在接受到一条select语句的请求后,如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cachehttp://www.aibeili.net,或者已经显式申明需要使用Query Cache),MySQL会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash,然后到Query Cache中直接查找是否已经缓存。也就是说,如果已经在缓存中,该select请求就会直接将数据返回,从而省略了后面所有的步骤(如SQL语句的解析,优化器优化以及向存储引擎请求数据等),极大的提高性能。
当然,Query Cache也有一个致命的缺陷,那就是当某个表的数据有任何任何变化,都会导致所有引用了该表的select语句在Query Cache中的缓存数据失效。所以,当我们的数据变化非常频繁的情况下,使用Query Cache可能会得不偿失。
Query Cache的使用需要多个参数配合,其中最为关键的是query_cache_size和query_cache_type,前者设置用于缓存ResultSet的内存大小,后者设置在何场景下使用Query Cache。在以往的经验来看,如果不是用来缓存基本不变的数据的MySQL数据库,query_cache_size一般256MBhttp://www.aibeili.net是一个比较合适的大小。当然,这可以通过计算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))来进行调整。query_cache_type可以设置为0(OFF),1(ON)或者2(DEMOND),分别表示完全不使用query cache,除显式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache,只有显示要求才使用query cache(使用sql_cache)。
•binlog_cache_size (global)
Binlog Cache用于在打开了二进制日志(binlog)记录功能的环境,是MySQL用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。
一般来说,如果我们的数据库中没有什么大事务,写入也不是特别频繁,2MB~4MB是一个合适的选择。但是如果我们的数据库大事务较多,写入量比较大,可与适当调高binlog_cache_size。同时,我们可以通过binlog_cache_use以及binlog_cache_disk_use来分析设置的binlog_cache_size是否足够,是否有大量的binlog_cache由于内存大小不够而使用临时文件(binlog_cache_disk_use)来缓存了。

本文转载于51cto博客