MSSQL数据库占用内存过大造成服务器死机问题的解决方法

使用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

服务器mysql数据库老自动停止是因为在设置时出现了问题，解决方法为：

1、首先登陆服务器。

2、登陆MySQL数据库；命令如下：mysql -u root -p pwd。

3、查询MySQL数据库是否允许远程ip访问。

4、开启远程访问 *** 作。命令如下：GRANT ALL PRIVILEGES ON *.* TO 'root'@'%'IDENTIFIED BY '111qqqpwd' WITH GRANT OPTIONFLUSH PRIVILEGES。

5、打开navicate客户端，新建mysql链接。

6、输入远程MySQL数据库链接信息，点击测试链接。数据库链接成功。

注意事项：

MySQL 软件采用了双授权政策，分为社区版和商业版，由于其体积小、速度快、总体拥有成本低，尤其是开放源码这一特点，一般中小型网站的开发都选择 MySQL 作为网站数据库。

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

---