① 数据库运行过程中常见的故障有哪几类试述对各类故障的恢复策略。
数据库运行过程中常见的故障有3类：事物故障、系统故障、介质故障。
恢复策略：
1、事物故障：
发生事务故障时，被迫中断的事务可能已对数据库进行丁修改，为了消除该事务对数据库的影响，要利用日志文件中所记载的信息，强行回滚该事务，将数据库恢复到修改前的初始状态。
为此，要检查日志文件中由这些事务所引起的发生变化的记录，取消这些没有完成的事务所做的一切改变，这类恢复操作称为事务撤销。
2、系统故障：
系统故障的恢复要完成两方面的工作，既要撤销所有末完成的事务，还要重做所有已提交的事务，这样才能将数据库真正恢复到一致的状态。
3、介质故障：
介质故障比事务故障和系统故障发生的可能性要小，但这是最严重的一种故障，破坏性很大，磁盘上的物理数据和日志文件可能被破坏，这需要装入发生介质故障前最新的后备数据库副本，然后利用日志文件重做该副本后所运行的所有事务。
(1)数据库事务提交时宕机了怎么解决扩展阅读：
“数据故障恢复”和“完整性约束”、“并发控制”一样，都是数据库数据保护机制中的一种完整性控制。所有的系统都免不了会发生故障，有可能是硬件失灵，有可能是软件系统崩溃，也有可能是其他外界的原因，比如断电等等。
数据库运行的突然中断会使数据库处在一个错误的状态，而且故障排除后没有办法让系统精确地从断点继续执行下去。这就要求DBMS要有一套故障后的数据恢复机构，保证数据库能够回复到一致的、正确地状态去。
参考资料来源：网络-事务故障
参考资料来源：网络-系统故障
参考资料来源：网络-介质故障
② 服务器宕机了，应该怎么办
造成服务器宕机（死机）的原因是什么呢？那么他解决方法有哪些呢？壹基比来告诉你
引发服务器宕机原因大概有：运行环境问题、服务器性能问题、服务器硬件问题、数据丢失或损坏问题。下面我们对以上几个问题详情描述并提供解决办法：
一、运行环境问题导致服务器宕机
服务器运行环境包括操作系统，数据库，应用程序，应用程序bug，网络数据等，以上软件系统故障会引起服务器宕机现象。解决办法：需要我们查找分析系统、应用程序相关日志来找出真正的原因。一般都能发现问题，根据日志提供的错误信息修改相关设置来解决此类宕机故障，由于系统原因可以重装系统，或重启一下服务器就可以了。
二、服务器性能问题导致服务器宕机
服务器性能好坏也是引发宕机的一个因素，因为IDC提供商的服务器有些不是品牌服务器，是组装型的服务器，采购的硬件也不是品牌的，多用于杂牌硬件，难免会因硬件兼容性，CPU，内存等性能不好，导致宕机。解决办法：查看服务器硬件信息，在租用或选购时尽量用品牌服务器，品牌服务器在稳定性方面是没得说的。
三、服务器硬件问题导致服务器宕机
如服务器主板，电源，CPU，内存，磁盘有问题也会导致服务器宕机故障，解决办法：使用工具测试相关硬件配件，或更换配件测试服务器硬件问题。
四、数据丢失或损坏问题导致服务器宕机
数据丢失包括人为错删除数据，磁盘坏道导致数据丢失，磁盘写满等原因可导致服务器系统崩溃宕机，解决办法：做好数据备份，监控磁盘空间大小。
③ 服务器宕机怎么办
解决方法：
对于服务器频繁出现宕机情况就要注意了检查服务器是否存在负载量过大，服务器散热存在问题等等情况。再针对这样的情况一项一项来解决，这样才能保证服务器尽可能长时间正常运行。
对于一般服务器宕机，我们可以采用重启服务器的方式来解决。正常重启服务器可以清除内存碎片，重新优化应用软件，中断无用的端口，缓解CPU压力，加快服务器运行速度等等。
对于服务器租用用户来说，服务器宕机是非常值得重视的问题，如果租用的服务器经常出现宕机情况的话，一定要及时通知服务商，让服务器查明具体情况，问题过于严重甚至可以要求跟换服务器或者更换服务器供应商。
④ 网站宕机 服务器宕机 数据库宕机 宕机怎么办
最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对DBA来说也是一项挑战，可能你的手一抖就会导致多少人无法正常使用业务，如果你没有把握，请先把现场环境备份后再进行操作，避免数据的二次损坏，下面壹基比小喻说一下大概的思路吧。
1.检查是否有备份，如果备份存在，binlog存在，那么万事大吉，一切都有挽回的余地，慢慢来搞，只要你基础扎实，数据还原只是时间的问题。
2.对于没有备份的，那处理这个问题就有些棘手了，还得一步一步的来。
在my.cnf中[mysqld]下加上以下配置，采用强制恢复机制，看是否能够启动
[mysqld]
innodb_force_recovery=1
如果设置成1不能启动，可以逐渐的将数据增大到6，下文会详细说下1-6是什么意思，如果在1-6之间启动成功了，那么你运气还不错，这时候不要恢复业务，赶紧把数据用逻辑方式导出来，再启个新的实例把数据还原，有人会问，为什么mysql已经启动了，还要导出数据呢，原因在这：
当innodb_force_recovery被设置为大于0的时候 ，会阻止用户insert,update,delete也就是你启动的mysql不是一个正常的mysql服务，类似于windows系统下的安全模式。以下这段引于其它地方，具体地址不太清楚了，也可以从官方文档中找到。
innodb_force_recovery被允许的非零值如下。一个更大的数字包含所有更小数字的预防措施。如果你能够用一个多数是4的选项值来转储你的表，那么你是比较安全的，只有一些在损坏的单独页面上的数据会丢失。一个为6的值更夸张，因为数据库页被留在一个陈旧的状态，这个状态反过来可以引发对B树和其它数据库结构的更多破坏。
innodb_force_recovery=1 (SRV_FORCE_IGNORE_CORRUPT)
即使服务器检测到一个损坏的页，也让服务器运行着；试着让SELECT * FROM tbl_name 跳过损坏的索引记录和页，这样有助于转储表。
innodb_force_recovery=2 (SRV_FORCE_NO_BACKGROUND)
阻止主线程运行，如果崩溃可能在净化操作过程中发生，这将阻止它。
innodb_force_recovery=3 (SRV_FORCE_NO_TRX_UNDO)
恢复后不运行事务回滚。
innodb_force_recovery=4 (SRV_FORCE_NO_IBUF_MERGE)
也阻止插入缓冲合并操作。如果你可能会导致一个崩溃。最好不要做这些操作，不要计算表统计表。
innodb_force_recovery=5 (SRV_FORCE_NO_UNDO_LOG_SCAN)
启动数据库之时不查看未完成日志：InnoDB把未完成的事务视为已提交的。
innodb_force_recovery=6 (SRV_FORCE_NO_LOG_REDO)
不要在恢复连接中做日志前滚。
数据库不能另外地带着这些选项中被允许的选项来使用。作为一个安全措施，当innodb_force_recovery被设置为大于0的值时，InnoDB阻止用户执行INSERT, UPDATE或DELETE操作.
即使强制恢复被使用，你也可以DROP或CREATE表。如果你知道一个给定的表正在导致回滚崩溃，你可以移除它。你也可以用这个来停止由失败的大宗导入或失败的ALTER TABLE导致的失控回滚。你可以杀掉mysqld进程，然后设置innodb_force_recovery为3，使得数据库被挂起而不需要回滚，然后舍弃导致失控回滚的表。
关于上面进行逻辑备份也可能会遇到问题，可能会备份失败，如果出错，建议先按库一个一个的备份，到哪个库出错后，再按照当前库的表一个一个备份，表出错根据表中主键一点一点备份，最终将大部分数据导出。如果你的数据不重要，可以容忍丢失，那么可以当我说的都是废话了。
3.如果还是不可以启动，那么恭喜你，你遇到挑战了。
查看错误日志，看没有提示因为某个表的原因而导致启动不了，可以先把损坏的表的ibd文件先从数据目录mv走，再试着启动，在数据已经恢复后，我把当时错误的文件拿到本地，做了测试，把几个报错的ibd文件mv走后，数据库就可以正常启动了，但是mv走的这几个表数据会丢失。怎么把这个表的数据弄回来呢，曾想过用在线表空间传输，但是.cfg文件却没有，这种方法没有行通。后来用Percona Data Recovery Tool for InnoDB工具进行数据恢复，关于这个工具的介绍与操作，网上一大堆，我就不详细说明了。
⑤ MySQL一主多从的环境下，如果主宕机了怎么办如何把损失降到最小
1、需要对MYSQL定时备份
2、应用中交换数据时，要判断是否联网，如果不联网就把信息先保存在本地，等联网后再
与MYSQL数据同步。
3、应用中注意使用事务
⑥ 数据库宕机怎么解决
a、是否是应用程序导致内存溢出或者泄露，out of memory导致
b、是否是进程过多或者不断创建，耗尽资源导致
c、是否是数据库程序死锁，连接数过多导致
d、是否是应用程序异常导致
e、是否是流量负载过大导致
f、 是否是遭受黑客入侵攻击导致
g、是否是误操作导致
⑦ 如何有效防止数据中心系统宕机
当启动Binlog后，事务会产生Binlog Event，这些Event被看做事务数据的一部分。因此要保证事务的Binlog Event和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：
- 所有已经提交的事务的数据仍然存在。
- 所有没有提交的事务的数据自动回滚。
- 所有已经提交了的事务的Binlog Event也仍然存在。
- 所有没有提交事务没有记录Binlog Event。
这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。
为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。
⑧ mysql数据库宕机怎么分析原因
可以手动将应用的数据库配置修改为从机的配置（ip、port、数据库名），然后重启服务。
⑨ 我的oracle宕机了怎么处理
1、案例现象
在root用户下，su切换到一个普通用户oracle下，却发生了如下错误：
oracle数据库意外宕机的分析处理案例
于是，尝试直接通过oracle用户登录系统，发现此时的oracle用户也无法登录了，出现与上面同样的错误。
2、解决思路
从上面错误提示可知是权限出现了问题，那么可以从权限入手进行排查，基本思路如下：
用户目录/home/oracle权限问题；
su程序执行权限问题；
程序依赖的共享权限问题；
selinux问题导致；
系统根空间问题。
3、排查问题
根据上面的思路，我们进行逐一检查，考虑到su在切换到oracle用户时会读取oracle目录下的环境变量配置文件，因此，首先检查/home/oralce目录的权限是否存在问题，
[root@loaclhost home]# ls -al/home|grep oracle
drwx---- 4 oralce oinstall 4096 01-31 10:45 oracle
从输出可知，/home/oracle目录的属主是oracle用户，oracle用户对这个目录有“rwx”权限，因此，oracle用户目录的权限设置是正确的，可以排除掉这个问题了。
接着检查su执行权限问题：
[root@loaclhost home]# 11 /bin/su
-rwsr-xr-x 1 root root 24120 2007-11-30 /bin/su
可见su命令执行权限也没有问题，这个也排除了。
继续检查su依赖的共享库权限，使用ldd命令检查su命令依赖的共享库文件，如下图
oracle数据库意外宕机的分析处理案例
根据上面的操作，依次检查su命令依赖的每个库文件的权限，发现也都是正常的，因此，共享库的问题也排除了。
根据上面的思路，绩效检查SELinux的设置。
oracle数据库意外宕机的分析处理案例
由输出可知，SELinux处于关闭状态，这个原因也排除了。
到这来为止，问题变得朴素迷离，到底是哪里出现问题了呢？作为Linux运维，例行检查系统根分区状态是非常必要的，那么首先检查一个根分区的磁盘空间大小，发现剩余空间还有很多，空间问题也排除了。既然报的错误是权限有问题，那么只要以权限为线索，不偏离这个核心就没错，于是继续尝试检查/home目录下各个用户的权限，如下图。
oracle数据库意外宕机的分析处理案例
从输出看每个用户的目录权限，都是“rwx----”,即“700”，完全没有问题，可是我发现我错了，我的目光一直在用户对应的目录上，而忽略了其他输出信息，而问题就藏在我没有关注的信息中。在这个命令输出的前两行中，第一行权限对应的目录是“.”，代表当前目录，也就是/home目录，权限为“rwxr-xr-x”，第二行权限对应的目录是“..”，也就是根目录，权限却为“rw-rw-rw-”，即“666”，此时，问题终于查找到了，原来是根目录权限问题。
4、解决问题
知道了问题产生的原因，解决问题就非常简单，执行如下命令：
[root@localhost~]#chmod 755 /
然后就可顺利执行su切换命令。
经验分享
这个问题主要是由于根目录没有执行权限，而Linux下所有的操作都是在根目录下进行的，进而导致/home/oralce目录没有执行权限。其实根目录权限的丢失对于系统中运行的每个用户存在同样的影响。因此，在权限出现问题时，一定要注意根目录的权限。