当前位置:Gxlcms > mysql > SQLServer内存相关博文

SQLServer内存相关博文

时间:2021-07-01 10:21:17 帮助过:37人阅读

Dont confuse error 823 and error 832 本文大意: 错误832: A page that should have been constant has changed (expected checksum: 1dcb28a7, actual checksum: 68c626bb, database 13, file 'E:\Program Files\microsoft sql server\MSSQL\data\BlahBl

Don’t confuse error 823 and error 832

本文大意:

错误832:

A page that should have been constant has changed (expected checksum: 1dcb28a7, actual checksum: 68c626bb, database 13, file 'E:\Program Files\microsoft sql server\MSSQL\data\BlahBlah.mdf', page (1:112644)). This usually indicates a memory failure or other hardware or OS corruption.

当一个页从磁盘读入,被标记为干净,如果被修改,变成脏页,检查checksum,发现checksum不再可用,832错误发生,发生这个错误一般出现在:1.内存问题,2.操作系统内存管理器问题,或者流氓程序写入到sql server。

1.通过微软产品支持,跟踪内存

2.通过替换法,替换内存

SQL Server and Large Pages Explained….

本文大意:

windows是支持大数据页的,关于windows大数据页的支持可以看Microsoft windows internal,X64支持2MB的大数据页。

有3个条件决定了是否使用大数据页:

1.sql server企业版

2.内存在8G以上

3.Lock Page in Memory权限

这个检查Lock Page in Memory和buffer pool使用AWE API没有关系,因为Large Page 也是不在work set中,也是不能被page out的。

如果Large Page启用会在error log中有一下信息:

2009-06-04 12:21:08.16 Server Large Page Extensions enabled.

2009-06-04 12:21:08.16 Server Large Page Granularity: 2097152

2009-06-04 12:21:08.21 Server Large Page Allocated: 32MB

但是有人会怀疑,明明没有开启TF 834为什么会用large page,因为TF834只限制buffer pool用不用large page。

开启834之后,buffer pool使用large page,因为large page通过virtualalloc()分配内存,比较慢所以会在开机时一次性分配。

启动时,分配算法:

1.会根据max server memory 和物理内存的最小值,若没有设置max server memory那么会分配所有内存。所以max server memeory的设置很总要

2.当使用large page的时候最让是sql server专用服务器。

3.如果不能分配,那么会分配的少一点,还是不能分配就会报错,服务无法启动。

注意:

内存size必须是连续的,并且在使用过程中buffer pool 不会自动增长。

使用large page导致开机时间变成,因为virtualalloc分配内存比较慢,并且时间不单单是分配内存的时间

总结

1.large page在内存>8gb,并有lock page权限

2.需要开启TF834,擦能让buffer pool使用large page

3.large page 并不适用所有场景应该测试后再决定

Come on 64bit so we can leave the mem….

本文大意:

作者在64BIT环境下看到一个错误,并且被问是否和MemToLeave有关。

作者解释了在64bit下并没有MemToLeave。

当32bit的年代,虚拟地址空间只有4个g,内核2g,用户2g,也可以通过4g选项调整为内核1g,用户3g,反正就是很少,设计者会为buffer pool保留地址,buffer pool有地址了,才不会影响内存的使用。buffer pool尽量大的保留地址空间了,但还是没有用完地址空间,因为有记下几个也需要用内存的:

1.线程stack,2.heap,3.SQL Server多页分配,4.其他DDL分配。

MemToLeave的意思就是留下来用来做别的事情,比如上面的,当服务启动的时候sql server 会先保留一部分地址空间,然后buffer pool保留地址空间,保留完之后,memtoleave释放地址空间。保留的地址的大小如下:线程堆栈大小*线程数+g参数的大小(默认256M)。

当64位来临,带来了大量的地址空间,所以没有必要在再服务启动时去保留地址空间,直接在需要用的时候分配就好了。

TechNet Magazine: October 2009 SQL Q&A column

本文大意:

1.sql server 2005启动的时候发现一致性检查信息,但是不管数据库大小,检查都很快,为什么?

其实这些并不是实际上的检查,只是把上次最后一次检查的信息输出出来。当dbcc checkdb运行完之后会写入到boot page 上。启动服务的检查只是把boot page的信息print出来。

2.如何确定内存被使用在那个数据库?

sql server会占用大量内存,并且在没必要的时候是不会释放啊内存,除非os有内存压力。sql server主要的内存都使用在buffer pool中,还有一部分是使用在plan cache中,内存多可以减少io,可以减少编译所占用的时间。可以通过sys.dm_os_buffer_descriptors是buffer pool的信息,来确定是那个数据库占用了内存。当然也可以使用 dbcc memorystatus 来确定实例内存的使用。

3.数据库偶尔会出现SUSPECT和RECOVERY_PENDING的情况,就会需要通过被备份恢复,会有数据丢失的问题,如何解决?

这2个状态都是由故障恢复的时候出现的,当crash 恢复,读不到日志的时候会出现RECOVERY_PENDING。当日志可读,但是日志可以访问,但是无法完成恢复,一致性不对的时候会出现SUSPECT。有2个原因会导致恢复无法完成,1.日志数据问题,2.数据文件有问题。

还有一个会进入SUSPECT状态就是,当事务回滚,在回滚时出现错误。

可以使用备份来恢复数据,如果没有备份可以转入应急模式,来恢复。

4.高安全的数据库镜像使用witness是如何识别错误的?

错误识别有一下几种:

1.sql server实例级crash,每秒ping,能ping通但是发现sql server没有监听端口,立即报告

2.服务器级别crash,每秒ping 不能ping通马上报告

3.事务磁盘问题,当日志写入的队列太高,香港虚拟主机,20秒后会写入到error log,服务器空间,40秒后认为log 磁盘offline,触发切换

4.数据库页出错,数据库会变成suspect状态,马上触发切换

5.如果文件或者文件组offline,primary正常,当碰到错误是切换。

Performance issues from wasted buffer pool memory

本文大意:

内存浪费是可耻,特别是对于数据库来说,内存不足有一下几个特点:

1.物理io变多,不管读还是写

2.Lazy write变多

3.RESOURCE_SEMAPHORE等待变多,因为查询需要内存

4.大量的plan重编译,因为没有地方放plan cache

低数据密度:

使用sys.dm_os_buffer_descriptors可以看,到底buffer pool 里面有多少是空的,也就是浪费的。

低数据密度引起的原因一般就怎么几个:

1.宽行,那么就使用小的数据类型

2.分页,合理设置填充因子

3.行删除,导致内部碎片

低数据密度也会有一下几个代价:

1.io变多,因为空间被浪费了

2.磁盘空间被浪费

3.内存被浪费

低数据密度解决办法:

1.小数据类型

2.使用顺序的key,不要用随机降低分页

3.调整填充因子,填充因子本身就是一种浪费,所以要合理不能太大

4.重建索引

5.数据压缩

作者各处了一些脚本,自己去原文看,个人觉得还是蛮有用的。

Database mirroring: avoiding ‘cannot obtain a LOCK resource’ problems

本文大意:

在镜像服务器出现不能获取LOCK资源,很有趣,镜像是不会动的,为什么会出现这个错误?

原因很简单,比如一个事务主体回顾的时候,镜像也回滚,会滚就会产生事务,不信自己试试看。

人气教程排行