由于硬件故障造成宕机的原因有哪些?该如何处理?

—、服务器出现宕机的原因

1.运行环境出现问题，机房断电导致的服务器断电(欠压，过载，波动)、机房温度过高，散热不良、资源冲突、DirectX文件的损坏、系统不完善等等原因而造成服务器宕机。

⒉.服务器不堪负重，最常见的如磁盘空间耗尽、访问值过大、程序中毒、遭受攻击等大规模高消耗服务器资源情况。

3.由于主备数据不—致导致的复制问题。

4.性能问题，运维运行糟糕的SQL或Schema和索引设计等。

二、服务器宕机应该从哪些方面检查呢?

①硬件

(1)检查硬件是否有冲突

(2)对比服务器电源所负载的功率判断电源是否出现故障

(3)扫描硬盘表面检查是否有坏道

(4)通过错误报告和 *** 作系统的报错信息来判断

(5)使用替换法判断主板、CPU、SCSI/RAID卡或其他PCI设备是否出现故障。

②软件

(1)检查 *** 作系统的系统日志，可以通过系统日志来判断部分造成死机的原因

(2)在判断硬件没有故障后，考虑系统软件的BUG和漏洞原因

(3)如果是因为软件使用不当或系统工作压力过大，可以适当降低服务器的工作压力

(4)电脑病毒。

以上就是有关服务器宕机的原因有哪些，应该从哪些方面检查的知识介绍。

在想解决处理办法之前要知道服务器宕机的两种形态：假死机和死机

假死机(非蓝屏死机)是由于硬件资源暂时性地被消耗殆尽，因而无法对外部指令进行响应的现象， 通常是网站处于访问高峰期，带宽等资源跑满，这时只需要等待一定的时间，待服务器腾出更多的硬件资源即可恢复正常。

而死机，如果通过ping测试服务器，键盘切换数字锁定键(NumLock)或大写锁定键(Caps Lock)功能， 显示器无画面输出，或者鼠标光标没有任何反应则表明服务器硬件故障。

再了解服务器出现宕机的常见原因 ：

1.在运行环境的问题中，最普遍的问题时磁盘空间耗尽。

2.在性能问题中，最普通的服务器宕机原因确实是运行很糟糕的SQL， 但也不一定都是这个原因，比如也有很多问题是由于服务器Bug或错误的行为导致的。

3.糟糕的Schema和索引设计是第二大影响性能的问题。

4.复制问题通常由于主备数据不一致导致。

5.数据丢失问题通常由于drop table的错误 *** 作导致，并总是便随着缺少可用备份的问题。

如何查看服务器宕机的原因：

a、是否是应用程序导致内存溢出或者泄露，out of memory导致

b、是否是进程过多或者不断创建，耗尽资源导致

c、是否是数据库程序死锁，连接数过多导致

d、是否是应用程序异常导致

e、是否是流量负载过大导致

f、 是否是遭受黑客入侵攻击导致

g、是否是误 *** 作导致

服务器宕机自行解决办法：

1.要即时发现服务器宕机的问题。时间就是金钱，这是不变的真理。我们要第一时间， 发现宕机的问题，服务器宕机时，为了避免造成不必要的损失，要尽早通知IDC服务商解决相关问题。

2.最好准备2个服务器空间，他们存放的内容相同，而ip不同，并且机房的地理位置不同。这样2个区域的服务器， 能够做到有效异地容灾备份。发现宕机问题后，可以迅速的通过修改http://dnspod.com中的域名记录，指向目前正常的服务器。Dnspod解析生效的时间是实时的， 而一般的dns服务器，刷新时间较长，对外声称24小时内生效，按照实际经验看来，差不多30分钟内生效，否则就要检查域名绑定是否正确了。

1.什么是服务器宕机

可以简单的理解为死机.服务器是硬件设备.而且是全年二十四小时不间断运行的.通常负载量也较大.所以时间一长就容易出现宕机的情况.只要不是太频繁.就是完全正常的.一般常用服务器的人都知道.每隔一段时间定期手动重启下机器.对机器的性能有很大帮助.而且可以避免宕机的情况.毕竟服务器也是硬件.长期运行中间也应该有个喘气的过程.

2.服务器宕机的几种原因及解决办法

(1)客户端发出域名请求，形如xxx.com

这里可能出现的错误是，手工输入的域名网址错误。自然不能访问正确的网站了。这是最初级的错误，但还是容易发生的。要注意网址中，一些相近，或形似的字符，比如网址中 “1”与”l”，”0”与”o”，这些都是很容易混淆的字符。解决办法：认真审核一下网址，再次输入。或者百度一下，网址的核心关键字，或者品牌字，试一试。百度的结果，一般说来，还是比较准确的。

(2)通过dns服务器，将域名解析成对应的ip

这个步骤很关键，也是问题的高发期，40%的宕机，都是因为dns服务器不稳定造成的。Dns服务器，就像联系着姓名与电话号码的查询簿。这里如果出现问题，其后果是不堪设想的。因为一般的企业，和个人，多是选用网站空间建设网站，条件好一点的，也不过是租用或托管服务器。但是很少有人，拥有独立的dns服务器。80%的站长，都没有自已的dns服务器。大家的域名解析请求，一般通过域名商，提供的dns服务器完成。多对一，而这个服务的基数又是相当巨大的。当信息的洪流，集中到1-6台dns服务器上的时候，那么这几台dns服务器，就变的极不稳定了。

快速判定dns服务器故障的办法：

目前有一些网站，提供”IP反查”的功能。你需要找到一些，和你同ip的网站。可能因为更新有延时，有些域名的ip已经改变了。你需要再次ping一下选定的网址，确定该网站，和你的网站同属一个ip。把他们的网址记录下来。当你的网站不能打开的第一时间，你要登录同ip的网站看一看。如果，同ip下的其它网站，能打开，而唯独你的网站打不开。那就可以确定，是你网站的dns服务器，出现问题了。否则的话，那就要再进行下一步的故障排除。你也可以把，你的网站，和你同ip的网站，是否dns服务器故障，或是网站空间宕机故障了。

解决dns服务器不稳定的方法：

你可以选择一些专业的dns解析服务商，来解析你的域名。这些解析商，不但专业，而且也提供稳定而且免费的dns解析服务。在国内比较出名的dns解析商有：dnspod.com，dns.la，iidns.com等等…国外也有一些，不过推荐国内的服务。如果你的网站业务在国内，那么无论你的主机，还是dns服务器，都应该首选国内的机器。海外跨洋的线路，因为路途遥远，还有国家防火墙，等不可预知的因素较多，推荐国内的服务相对较稳定。在填写dns服务器列表的时候，也尽量将6个dns服务器，全部写上，比较稳妥。

(3)与ip对应的网站空间，或服务器做出响应

这个步骤，引起服务器宕机的概率在40%左右。这里故障的原因，就是服务器宕机了。一般站长，所指的宕机，也主要在这里。服务器当机的原因很多，流量过大，DDOS攻击，内部不稳定的程序，等等…

服务器宕机的判断方法：

同上一个步骤，如果同ip下的网站，都不能打开，那么基本上可以确定，是服务器宕机所致。

解决服务器宕机的方法：

a.要即时发现服务器宕机的问题。时间就是金钱，这是不变的真理。我们要第一时间，发现宕机的问题。如果他第一时间发现你的网站无法访问，他将立即发送Email通知站长。

b.最好准备2个网站空间，他们存放的内容相同，而ip不同，并且机房的地理位置不同。这样2个主机，同时宕机的可能性就大大降低了。第一时间发现宕机问题后，可以迅速的通过修改dnspod.com中的域名记录，指向目前正常的网站空间。Dnspod解析生效的时间是实时的，而一般的dns服务器，刷新时间较长，对外声称24小时内生效，按照实际经验看来，差不多30分钟内生效，否则就要检查域名绑定是否正确了。

c.可能仍有一些站长朋友，觉得域名解析有点复杂。想通了，其实很简单。别看他们的教程可能有一大段文字，其实就2个步骤：aa.在dns服务器上，将域名指向ip.bb.在网站空间上，将主机绑定域名(也是在这里，申请网站备案的!)。一个是，发送给谁?另一个是，接受谁的请求?是不是很简单呢?

(4)数据下载至本地网络，完成一次请求

这里出现问题的机率较小，不过也有可能。其表现的症状就是，在你的机器上不能访问你的网站。而在别人的电脑上，却是可以打开的。如果发生了这样的情况，那就可能是因为你所在地的网络不稳定，而造成的访问中断。这个故障，通常影响的区域较小。如果要确定，本地网络是否畅通，在打不开你的网站的时候，通过”在线代理”打开你的网站试一试。百度一下”在线代理”，有一些网站能提供，用其它的ip，或国外ip代理访问某个网站的服务。如果在线代理，能够打开你的网站，基本上可以确定，你所在的本地网络，出现了暂时的不稳定情况。

看了以上的介绍，大家也有了一定的了解了。电脑本身就是个负荷量大的东西，尤其是在使用较长一段时间之后，很容易出现各种各样的问题。但有些问题我们是可以从中找到原因的，并自己解决。相信服务器宕机的情况的很多人都经历过，稍微了解电脑的人看看以上的原因，就可以自己动手解决了，也不用再拿出去维修。

使用MSSQL的站长朋友都会被MSSQL数据库吃内存的能力佩服得五体投地 一个小小的网站 运行若干天之后 MSSQL就会把服务器上所有的内存都吃光 此时你不得不重新启动一下服务器或MSSQL来释放内存 有人认为是MSSQL有内存泄露问题 其实不然 微软给我们了明确说明:

在您启动 SQL Server 之后 SQL Server 内存使用量将会持续稳定上升 即使当服务器上活动很少时也不会下降 另外 任务管理器和性能监视器将显示计算机上可用的物理内存稳定下降 直到可用内存降到 至 MB 为止

仅仅出现这种状态不表示内存泄漏 此行为是正常的 并且是 SQL Server 缓冲池的预期行为

默认情况下 SQL Server 根据 *** 作系统报告的物理内存加载动态增大和收缩其缓冲池(缓存)的大小 只要有足够的内存可用于防止内存页面交换(在 至 MB 之间) SQL Server 缓冲池就会继续增大 像在与 SQL Server 分配内存位于相同计算机上的其他进程一样 SQL Server 缓冲区管理器将在需要的时候释放内存 SQL Server 每秒可以释放和获取几兆字节的内存 从而使它可以快速适应内存分配变化

更多信息

您可以通过服务器内存最小值和服务器内存最大值配置选项设置 SQL Server 数据库引擎使用的内存(缓冲池)量的上下限 在设置服务器内存最小值和服务器内存最大值选项之前 请查阅以下 Microsoft 知识库文章中标题为"内存"一节中的参考信息

HOW TO Determine Proper SQL Server Configuration Settings(确定正确的 SQL Server 配置设置)

请注意 服务器内存最大值选项只限制 SQL Server 缓冲池的大小 服务器内存最大值选项不限制剩余的未保留内存区域 SQL Server 准备将该区域分配给其他组件 例如扩展存储过程 对象 以及非共享 DLL EXE 和 MAPI 组件 由于前面的分配 SQL Server 专用字节超过服务器内存最大值配置是很正常的 有关此未保留内存区域中分配的其他信息 请单击下面的文章编号 以查看 Microsoft 知识库中相应的文章

PRB 在使用大量数据库时可能没有足够的虚拟内存

参考

SQL Server 联机图书主题 "服务器内存最小值和最大值的影响""内存体系结构""服务器内存选项""SQL Server 内存池"

下面我们就来实战如何限制MSSQL内存使用:

第一步:打开企业管理双击进入要修改的MSSQL

第二步:在左侧MSSQL上点击右键 选择属性 d出SQL Server属性(配置)对话框

第三步:点击内存选项卡

在这里 你会看到MSSQL默认设置为使用最大内存 也就是你所有的内存 根据你的需要 设置它的最大值吧

lishixinzhi/Article/program/MySQL/201311/29533

最近遇到个比较有意思的问题，服务器宕掉后无法启动，想了好多办法，虽然解决了问题，数据没有丢失，但是没有按照自已的思路来，未免还是有些不甘。遇到问题不能慌，尤其是线上的环境，更不能紧张，心理素质对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工具进行数据恢复，关于这个工具的介绍与 *** 作，网上一大堆，我就不详细说明了。

---