如何设置SQLServer数据库内存

如何设置SQLServer数据库内存,第1张

如果能在实例级别为同一SQL服务器上的不同实例限制其能够使用的最大和最小内存,就能降低这种情况对其他应用系统的影响。具体的 *** 作如下:

(一)实例的最大和最小内存设置

右击数据,选择属性,如图。

为实例设置合适的最大和最小内存,如图。

(二)为 *** 作系统预留足够的内存

假如一台8GB的服务器,我们可以限制数据库使用的内存上限不超过6GB,剩下的2GB留给 *** 作系统使用。

(三)配置lockpagesinmemory

查看SQL进程的启动账户,如图。

在组策略里设置启动SQL Server的账户拥有锁定内存页的权限。如图。

在下图的添加用户或组界面,添加SQL server的服务启动账户,如图。

假定在程序效率和关键过程相当且不计入缓存等措施的条件下,读写任何类型的数据都没有直接 *** 作文件来的快,不论MSYQL过程如何,最后都要到磁盘上去读这个“文件”(记录存储区等效),所以当然这一切的前提是只读 内容,无关任何排序或查找 *** 作。

动态网站一般都是用数据库来存储信息,如果信息的及时性要求不高 可以加入缓存来减少频繁读写数据库。

两种方式一般都支持,但是绕过 *** 作系统直接 *** 作磁盘的性能较高,而且安全性也较高,数据库系中的磁盘性能一直都是瓶颈,大型数据库一般基于unix

系统,当然win下也有,不常用应为win的不可靠性,unix下,用的是裸设备raw设备,就是没有加工过的设备(unix下的磁盘分区属于特殊设备,

以文件形式统一管理),由dbms直接管理,不通过 *** 作系统,效率很高,可靠性也高,因为磁盘,cache和内存都是自己管理的,大型数据库系统

db2,oracal,informix(不太流行了),mssql算不上大型数据库系统。

1、直接读文件相比数据库查询效率更胜一筹,而且文中还没算上连接和断开的时间。

2、一次读取的内容越大,直接读文件的优势会越明

显(读文件时间都是小幅增长,这跟文件存储的连续性和簇大小等有关系),这个结果恰恰跟书生预料的相反,说明MYSQL对更大文件读取可能又附加了某些 ***

作(两次时间增长了近30%),如果只是单纯的赋值转换应该是差异偏小才对。

3、写文件和INSERT几乎不用测试就可以推测出,数据库效率只会更差。

4、很小的配置文件如果不需要使用到数据库特性,更加适合放到独立文件里存取,无需单独创建数据表或记录,很大的文件比如、音乐等采用文件存储更为方便,只把路径或缩略图等索引信息放到数据库里更合理一些。

5、PHP上如果只是读文件,file_get_contents比fopen、fclose更有效率,不包括判断存在这个函数时间会少3秒左右。

6、fetch_row和fetch_object应该是从fetch_array转换而来的,书生没看过PHP的源码,单从执行上就可以说明fetch_array效率更高,这跟网上的说法似乎相反。

磁盘读写与数据库的关系:

一 磁盘物理结构

(1) 盘片:硬盘的盘体由多个盘片叠在一起构成。

在硬盘出厂时,由硬盘生产商完成了低级格式化(物理格式化),作用是将空白的盘片(Platter)划分为一个个同圆心、不同半径的磁道

(Track),还将磁道划分为若干个扇区(Sector),每个扇区可存储128×2的N次方(N=0123)字节信息,默认每个扇区的大小为

512字节。通常使用者无需再进行低级格式化 *** 作。

(2) 磁头:每张盘片的正反两面各有一个磁头。

(3) 主轴:所有磁片都由主轴电机带动旋转。

(4) 控制集成电路板:复杂!上面还有ROM(内有软件系统)、Cache等。

二 磁盘如何完成单次IO *** 作

(1) 寻道

当控制器对磁盘发出一个IO *** 作命令的时候,磁盘的驱动臂(Actuator

Arm)带动磁头(Head)离开着陆区(Landing

Zone,位于内圈没有数据的区域),移动到要 *** 作的初始数据块所在的磁道(Track)的正上方,这个过程被称为寻道(Seeking),对应消耗的时

间被称为寻道时间(Seek Time);

(2) 旋转延迟

找到对应磁道还不能马上读取数据,这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正下方之后才能开始读取数据,在这个等待盘片旋转到可 *** 作扇区的过程中消耗的时间称为旋转延时(Rotational Delay);

(3) 数据传送

接下来就随着盘片的旋转,磁头不断的读/写相应的数据块,直到完成这次IO所需要 *** 作的全部数据,这个过程称为数据传送(Data Transfer),对应的时间称为传送时间(Transfer Time)。完成这三个步骤之后单次IO *** 作也就完成了。

根据磁盘单次IO *** 作的过程,可以发现:

单次IO时间 = 寻道时间 + 旋转延迟 + 传送时间

进而推算IOPS(IO per second)的公式为:

IOPS = 1000ms/单次IO时间

三 磁盘IOPS计算

不同磁盘,它的寻道时间,旋转延迟,数据传送所需的时间各是多少?

1 寻道时间

考虑到被读写的数据可能在磁盘的任意一个磁道,既有可能在磁盘的最内圈(寻道时间最短),也可能在磁盘的最外圈(寻道时间最长),所以在计算中我们只考虑平均寻道时间。

在购买磁盘时,该参数都有标明,目前的SATA/SAS磁盘,按转速不同,寻道时间不同,不过通常都在10ms以下:

3 传送时间2 旋转延时

和寻道一样,当磁头定位到磁道之后有可能正好在要读写扇区之上,这时候是不需要额外的延时就可以立刻读写到数据,但是最坏的情况确实要磁盘旋转整整

一圈之后磁头才能读取到数据,所以这里也考虑的是平均旋转延时,对于15000rpm的磁盘就是(60s/15000)(1/2) = 2ms。

(1) 磁盘传输速率

磁盘传输速率分两种:内部传输速率(Internal Transfer Rate),外部传输速率(External Transfer Rate)。

内部传输速率(Internal Transfer Rate),是指磁头与硬盘缓存之间的数据传输速率,简单的说就是硬盘磁头将数据从盘片上读取出来,然后存储在缓存内的速度。

理想的内部传输速率不存在寻道,旋转延时,就一直在同一个磁道上读数据并传到缓存,显然这是不可能的,因为单个磁道的存储空间是有限的;

实际的内部传输速率包含了寻道和旋转延时,目前家用磁盘,稳定的内部传输速率一般在30MB/s到45MB/s之间(服务器磁盘,应该会更高)。

外部传输速率(External Transfer Rate),是指硬盘缓存和系统总线之间的数据传输速率,也就是计算机通过硬盘接口从缓存中将数据读出交给相应的硬盘控制器的速率。

硬盘厂商在硬盘参数中,通常也会给出一个最大传输速率,比如现在SATA30的6Gbit/s,换算一下就是61024/8,768MB/s,通常指的是硬盘接口对外的最大传输速率,当然实际使用中是达不到这个值的。

这里计算IOPS,保守选择实际内部传输速率,以40M/s为例。

(2) 单次IO *** 作的大小

有了传送速率,还要知道单次IO *** 作的大小(IO Chunk Size),才可以算出单次IO的传送时间。那么磁盘单次IO的大小是多少?答案是:不确定。

*** 作系统为了提高 IO的性能而引入了文件系统缓存(File System Cache),系统会根据请求数据的情况将多个来自IO的请求先放在缓存里面,然后再一次性的提交给磁盘,也就是说对于数据库发出的多个8K数据块的读 *** 作有可能放在一个磁盘读IO里就处理了。

还有,有些存储系统也是提供了缓存(Cache),接收到 *** 作系统的IO请求之后也是会将多个 *** 作系统的 IO请求合并成一个来处理。

不管是 *** 作系统层面的缓存还是磁盘控制器层面的缓存,目的都只有一个,提高数据读写的效率。因此每次单独的IO *** 作大小都是不一样的,它主要取决于系统对于数据读写效率的判断。这里以SQL Server数据库的数据页大小为例:8K。

(3) 传送时间

传送时间 = IO Chunk Size/Internal Transfer Rate = 8k/40M/s = 02ms

可以发现:

(31) 如果IO Chunk Size大的话,传送时间会变大,从而导致IOPS变小;

(32) 机械磁盘的主要读写成本,都花在了寻址时间上,即:寻道时间 + 旋转延迟,也就是磁盘臂的摆动,和磁盘的旋转延迟。

(33) 如果粗略的计算IOPS,可以忽略传送时间,1000ms/(寻道时间 + 旋转延迟)即可。

4 IOPS计算示例

以15000rpm为例:

(1) 单次IO时间

单次IO时间 = 寻道时间 + 旋转延迟 + 传送时间 = 3ms + 2ms + 02 ms = 52 ms

(2) IOPS

IOPS = 1000ms/单次IO时间 = 1000ms/52ms = 192 (次)

这里计算的是单块磁盘的随机访问IOPS。

考虑一种极端的情况,如果磁盘全部为顺序访问,那么就可以忽略:寻道时间 + 旋转延迟 的时长,IOPS的计算公式就变为:IOPS = 1000ms/传送时间

IOPS = 1000ms/传送时间= 1000ms/02ms = 5000 (次)

显然这种极端的情况太过理想,毕竟每个磁道的空间是有限的,寻道时间 + 旋转延迟 时长确实可以减少,不过是无法完全避免的。

四 数据库中的磁盘读写

1 随机访问和连续访问

(1) 随机访问(Random Access)

指的是本次IO所给出的扇区地址和上次IO给出扇区地址相差比较大,这样的话磁头在两次IO *** 作之间需要作比较大的移动动作才能重新开始读/写数据。

(2) 连续访问(Sequential Access)

相反的,如果当次IO给出的扇区地址与上次IO结束的扇区地址一致或者是接近的话,那磁头就能很快的开始这次IO *** 作,这样的多个IO *** 作称为连续访问。

(3) 以SQL Server数据库为例

数据文件,SQL Server统一区上的对象,是以extent(88k)为单位进行空间分配的,数据存放是很随机的,哪个数据页有空间,就写在哪里,除非通过文件组给每个表预分配足够大的、单独使用的文件,否则不能保证数据的连续性,通常为随机访问。

另外哪怕聚集索引表,也只是逻辑上的连续,并不是物理上。

日志文件,由于有VLF的存在,日志的读写理论上为连续访问,但如果日志文件设置为自动增长,且增量不大,VLF就会很多很小,那么就也并不是严格的连续访问了。

2 顺序IO和并发IO

(1) 顺序IO模式(Queue Mode)

磁盘控制器可能会一次对磁盘组发出一连串的IO命令,如果磁盘组一次只能执行一个IO命令,称为顺序IO;

(2) 并发IO模式(Burst Mode)

当磁盘组能同时执行多个IO命令时,称为并发IO。并发IO只能发生在由多个磁盘组成的磁盘组上,单块磁盘只能一次处理一个IO命令。

(3) 以SQL Server数据库为例

有的时候,尽管磁盘的IOPS(Disk Transfers/sec)还没有太大,但是发现数据库出现IO等待,为什么?通常是因为有了磁盘请求队列,有过多的IO请求堆积。

磁盘的请求队列和繁忙程度,通过以下性能计数器查看:

LogicalDisk/AvgDisk Queue Length

LogicalDisk/Current Disk Queue Length

LogicalDisk/%Disk Time

这种情况下,可以做的是:

(1) 简化业务逻辑,减少IO请求数;

(2) 同一个实例下,多个数据库迁移的不同实例下;

(3) 同一个数据库的日志,数据文件分离到不同的存储单元;

(4) 借助HA策略,做读写 *** 作的分离。

3 IOPS和吞吐量(throughput)

(1) IOPS

IOPS即每秒进行读写(I/O) *** 作的次数。在计算传送时间时,有提到,如果IO Chunk Size大的话,那么IOPS会变小,假设以100M为单位读写数据,那么IOPS就会很小。

(2) 吞吐量(throughput)

吞吐量指每秒可以读写的字节数。同样假设以100M为单位读写数据,尽管IOPS很小,但是每秒读写了N100M的数据,吞吐量并不小。

(3) 以SQL Server数据库为例

对于OLTP的系统,经常读写小块数据,多为随机访问,用IOPS来衡量读写性能;

对于数据仓库,日志文件,经常读写大块数据,多为顺序访问,用吞吐量来衡量读写性能。

磁盘当前的IOPS,通过以下性能计数器查看:

LogicalDisk/Disk Transfers/sec

LogicalDisk/Disk Reads/sec

LogicalDisk/Disk Writes/sec

磁盘当前的吞吐量,通过以下性能计数器查看:

LogicalDisk/Disk Bytes/sec

LogicalDisk/Disk Read Bytes/sec

LogicalDisk/Disk Write Bytes/sec

内存结构 oracle内存结构大致具有四个区:软件代码区、系统全局区、程序全局区和排序区。 1、系统全局区。(SGA) 系统全局区为一组由oracle分配的共享数据结构,它是实例的主要部分,它含有数据维护、SQL语句分析与重做缓存所必须的所有内存结构,系统全局区的数据是共享的,也就是说,多个进程可以在同一时间对SGA中的数据进行访问和修改。它包含以下内容: <1>、数据块缓冲区 该区存放最近使用过的数据块,使用LRU(最近最少使用算法)进行管理。 <2>、字典缓冲区 该区用于保存数据字典中的行,数据字典中存放oracle系统管理自身所需的所有信息。该区也使用LRU算法管理。 <3>、重做日志缓冲区 任何事务在记录到重做日志之前都先放到该区,数据库系统定期将该区内容写入到联机重做日志中。 <4>、SQL共享池 存放所有通过SQL语法分析、准备执行的SQL语句。 <5>、JAVA池 为JAVA命令提供语法分析。 <6>、多缓冲池 可以在SGA中创建多个缓冲池,能够用多个缓冲池把的数据集与其他的应用程序分开,以减少它们争夺数据块缓冲区相同资源的可 能性。 2、程序全局区(PGA) 包含单个服务器进程或单个后台进程的数据和控制信息,与几个进程共享的SGA 正相反PGA 是只被一个进程使用的区域,PGA 在创建进程时分配在终止进程时回收。 3、排序区 排序需要内存,这部分空间成为排序区,排序区存在于请求排序的用户进程的内存中,该空间的大小为适应排序数据量的大小,可增长,但受初始化参数SORT_AREA_SIZER所限制。 4、软件代码区 用于存储正在执行或可以执行的程序代码。 </FONT></SPAN>

在云计算、大数据等新技术的带动下,越来越多的企业需要对数据进行存储管理、分析挖掘和创新应用。2019软博会上聚集了国内知名的从事数据库、大数据解决方案、数据挖掘分析和产品研发的专业公司。

柏睿数据的全内存流数据库是一个分布式、可扩展、能够在毫秒级内连续、稳定地传输并实时分析处理数据的流数据库。其具备对各行业产生的海量流动数据进行实时数据采集、实时流式数据处理、实时多源并行分析的能力,在数据清洗、数据集成、多传感器网络等领域有着广泛的应用。

以其在制造业领域为例,柏睿数据开发的MPP内存数据仓库引擎能够帮助企业整合内外部数据,强化企业数据资产的管理,实现各领域数据的横纵结合。MPP内存数据仓库Rapids DB/分布式内存流数据库 Rapids StreamDB能够实现企业现有数据、应用系统、软件装备和资源的连接,快速构建数据应用。

优炫软件研发的优炫云数据库(UXDB)是一款为云平台打造的NewSQL数据库系统。全面兼容传统的关系型数据库的数据建模模式,并保证事物处理的一致性,用户可继续使用其熟悉的SQL语言使用优炫云数据库。同时,UXDB还吸纳了NoSQL的横向扩展性和高速的吞吐性能的特性,突破传统关系型数据库无法支持海量数据的局限,以及NoSQL数据存储不能使用SQL语言进行查询的不足。

优炫云数据库(UXDB)适用于各种大数据应用场景,如大数据处理、大型联机交易系统、大型Web应用、数据业务分析等。

为数据库配置比较大的内存 可以有效提高数据库性能 因为数据库在运行过程中 会在内存中划出一块区域来作为数据缓存 通常情况下 用户访问数据库时 数据先会被读取到这个数据缓存中 当下次用户还需要访问这个数据时 就会从这个数据缓存中读取 因为在数据缓存中读取数据要比在硬盘上读取数据快几百倍 所以扩大数据库服务器内存 可以有效提高数据库性能 特别是 *** 作大型数据库时效果更加明显

但是 现在企业中普遍采用的数据库服务器都是 位的 *** 作系统 而这个 位的 *** 作系统却有最大内存的使用限制 通常情况下 标准的 位地址最多可以采用 GB的内存 若数据库管理员想让数据库系统采用更多的内存来提高数据库的性能 则就需要进行额外的配置 下面笔者就介绍两种常用的配置方式 让SQLServer数据库服务器支持大内存 让其成为数据库的加速剂

一 让数据库应用程序支持 GB的内存空间

虽然 *** 作系统支持 GB内存 可是 这并不会全部给数据库等应用程序使用 默认情况下 在 位 *** 作系统中 将有 GB的内存空间是为 *** 作系统所保留的 即使没有用完 其他应用程序也是不能够染指的 而包含SQL Server数据库在内的所有应用程序 只能过采用剩余的 GB内存空间

但是 在实际应用中 *** 作系统往往用不着多大 G的内存 根据笔者的经验 一般只要为 *** 作系统保留 G的内存已经足够其使用 只要没有病毒等不良因素作怪 这个内存不会被完全适用 如此的话 应用程序可以采用的内存空间就会多达 G 比原先整整多出一个G来

要实现这个转变 其实很简单 在Windows *** 作系统中 有一个BOOT启动配置文件 为了让数据库服务器支持 GB的用户模式进程空间 必须在这个配置文件中 加入一个/ gb的参数 然后重新启动 *** 作系统即可 这么设置之后 应用程序就可以寻址 GB的进程地址空间 而为 *** 作系统保留 GB的内存空间

有时候 这个小小的配置可以在很大程度上提高数据库的性能 记得有一次 笔者为一家企业优化数据库性能 笔者查看了用户的数据库环境之后 就建议用户增大数据库服务器的内存 从 G增加到 G 可是 效果并没有很大的改善 正当笔者束手无措的时候 就想到了改变 *** 作系统与应用程序的内存分配方式 为此 笔者就更改了BOOT启动配置文件 只给 *** 作系统保留 G的内存空间 重新启动后 数据库性能得到了很大的改善

二 为SQLServer启用更高的内存支持

如果数据库应用程序内存寻址空间达到 GB后 数据库管理员还不满足的话 则就需要通过增加物理内存的方式 来提高应用程序的性能 若需要服务器 *** 作系统突破其默认 GB内存空间的限制 支持 GB以上的内存空间 也不是不可能的 只是需要进行额外的配置 并且 其维护的工作量也比较大

若想要SQLServer数据库支持 GB以上的内存寻址空间 则往往需要进行如下配置

第一步 锁定内存页

默认情况下 内存大小与 *** 作系统的虚拟内存之间有一个正比例关系 在这里 数据库管理员只想增大服务器的物理内存 而不想对虚拟内存有什么影响 故需要锁定内存页 锁定内存页的主要作用就是确定哪些帐户可以使用进程将数据保留在物理内存中 从而阻止系统将数据分页到磁盘的虚拟内存中 默认情况下 这个选项的只为OFF 也就是说 在必要的时候 系统会将数据分页到硬盘的虚拟空间中 为了最大程度发挥内存的效用 就需要把这个选项开启 不过这数据库管理员往往需要寻求系统管理员的帮助 因为只有具有系统管理员权限的用户 才能够给更改这个选项

第二步 启用Awe Enable选项

默认情况下 即使服务器 *** 作系统支持 GB以上的内存空间 可是数据库应用程序并不一定支持 为了让SQLServer应用程序也支持这个 就必须更改数据库的配置参数 也就是说 需要将这个选项的值设置为 然后重新启动数据库系统 这个配置比较简单 只需要利用命令sp_configure awe enabled 即可 不过在进行这个配置之前 需要注意两个细节方面的内容 一是数据库用户需要这个 *** 作的权限 二是这里有一个BUG 即在SQL Server数据库中会有一个错误信息 数据库管理员可以忽略这个信息

第三步 限制文件系统缓存

若增加的内存给 *** 作系统或者其他应用程序用了 那么数据库管理员不是白忙一场吗为此 数据库管理员还需要优化数据库系统内存的使用情况 如需要限制系统用于文件缓存的内存量 如要这么处理的话 只需要简单的三个步骤即可

首先 数据库管理员在 *** 作系统中 找到控制面板 并双击网络连接 然后选中本地连接 其次 双击本地连接 在d出的对话框中 找到常规选项卡 单击属性 选中网络文件与打印机共享 并单击属性 最后 在d出的对话框中 去掉 最大化网络应用程序数据吞吐量 复选框 一路按确认即可 这个简单的步骤 就可以优化数据库内存的使用率

三 大内存维护管理几个关键点

在通常情况下 往往不需要启用 GB以上的内存 但是 若在服务器上 同时启用了其他的应用程序服务 如在一台服务器上同时有数据库应用程序 邮件应用程序 文件服务器等多个应用服务的话 则可能原有的 GB内存无法满足 系统管理员不得不对内存进行升级 但是 对内存升级之后 数据库管理员需要手工对内存的分配进行干预 以免SQLServer应用程序占用比较多的内存空间 而影响其他应用程序的性能

配置max server memory选项 虽然说这个选项并不是必须要修改的 但是笔者仍强烈建议数据库管理员要修改这个选项 特别是数据库应用程序与其他应用程序共享同一台服务器时 因为启动SQLServer对大内存的支持后(将Awe Enabled设置为 ) 而且可用物理内存大于用户模式进程空间 则当启动数据库服务器时 运行的SQLServer实例将会占用几乎所有的可用内存(不管需不需要使用 数据库服务器程序会先锁定这些内存 这就叫占著茅坑不拉屎) 而这个max server memory选项就是用来配置其最大可以占用的内存数量 数据库管理员需要预先估算出一个合理的数值 然后进行配置 让数据库应用程序与其他应用服务能够共同改善 至少不能够对其他应用程序的性呢产生不良影响 在比较极端的情况下 可以在升级内存之前 先关闭数据库应用程序;然后启用其他应用程序服务 观测一段时间 看看他们所需要用到多少的内存 然后升级内存 并为其他应用程序至少保留以前所需要的内存空间 否则的话 就会对其他应用程序产生不良影响 牺牲其他应用程序的性能来提高数据库的性能 这是拆西墙补东墙的做法 不值得取

lishixinzhi/Article/program/SQL/201311/16351

(1)采用复杂的数据模型表示数据结构,数据冗余小,易扩充,实现了数据共享。(2)具有较高的数据和程序独立性,数据库的独立性有物理独立性和逻辑独立性。(3)内存数据库为用户提供了方便的用户接口。(4)内存数据库提供4个方面的数据控制功能,分别是并发控制、恢复、完整性和安全性。数据库中各个应用程序所使用的数据由数据库统一规定,按照一定的数据模型组织和建立,由系统统一管理和集中控制。(5)增加了系统的灵活性。

以上就是关于如何设置SQLServer数据库内存全部的内容,包括:如何设置SQLServer数据库内存、一个例子说明内存数据库为什么比磁盘数据库要快、简要说明oracle数据库体系的内存结构等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9495307.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-28
下一篇 2023-04-28

发表评论

登录后才能评论

评论列表(0条)

保存