SQLCTP2内存驻留OLTP详细功能概述.docx
《SQLCTP2内存驻留OLTP详细功能概述.docx》由会员分享，可在线阅读，更多相关《SQLCTP2内存驻留OLTP详细功能概述.docx（45页珍藏版）》请在冰豆网上搜索。
SQLCTP2内存驻留OLTP详细功能概述
SQLServerCTP2内存驻留OLTP详细功能概述
SQLServer技术文档
作者：
KalenDelaney
技术审稿人：
KevinLiu、SunilAgarwal、JosdeBruijn、KevinFarlee、MikeZwilling、CraigFreedman、MikeWeiner、CristianDiaconu、PoojaHarjani、PaulLarson、DavidSchwartz
发布时间：
2013年10月
适用产品：
SQLServer2014CTP2
概述：
内存驻留OLTP（项目“Hekaton”）是一个全新的、完全集成到SQLServer的数据库引擎组件。
对OLTP工作负载访问驻留在内存中的数据进行了优化。
内存驻留OLTP能够帮助OLTP工作负载实现显著的性能改善，并减少处理时间。
表能被视为“内存优化”，提升内存中的OLTP功能。
内存优化表是完全可事务的、并可以使用Transact-SQL进行访问。
Transact-SQL存储过程可以编译成为机器码，从而进一步地提高内存优化表的性能。
该引擎是专为高并发而设计的，并且阻塞是最小的。
版权声明
本文档中包含的信息只做信息展示用途。
本文档中包含的信息和视图，包括URL以及其他的网站参考可能会在未经提示的情况下被修改，您需要自己承担适用这些信息的风险。
本文档并未给您提供适用任何微软产品当中知识产权的法律权限。
您只能以内部参考用途的目的来复制和适用本文档当中的内容。
©2013微软公司，保留所有权利。
目录
概述6
设计考虑和目的6
术语6
功能概述7
内存驻留的OLTP有哪些技术亮点？
7
内存优化的表8
内存优化的表索引8
增强的并发性功能9
本地编译的存储过程9
内存优化的OLTP是不是就是DBCCPINTABLE？
9
竞争对手的解决方案9
使用内存驻留的OLTP10
创建数据库10
创建表11
行和索引存储12
行12
行头13
有效载荷区域14
内存优化的表上的索引14
哈希索引14
范围索引16
数据操作19
内存优化的表允许的隔离级别19
删除20
更新和插入20
读取21
验证22
T-SQL支持22
内存驻留的行垃圾回收机制23
事务隔离和并发性管理24
检查点和恢复26
事务日志27
检查点29
检查点文件30
检查点流程30
合并检查点文件30
自动的合并30
手动合并sys.sp_xtp_merge_checkpoint_files31
检查点文件垃圾回收32
恢复32
本地编译表和存储过程33
什么是本地编译？
33
维护DLL文件33
本地编译的表33
存储过程的本地编译34
编译和查询流程35
SQLServer功能支持36
管理体验36
Metadata元数据36
归类视图36
动态管理对象37
XEvents37
性能计数器38
内存使用报告38
内存需求39
通过资源监管器管理内存39
使用AMR40
总结40
了解更多信息：
41
概述
SQLServer在最初设计的时候，假定主内存是非常昂贵的，所以当数据实际需要处理时数据需要驻留在磁盘上。
随着在过去的30年中内存的价格大幅度降低，这个假设已不再有效。
与此同时，多核服务器已经成为人人可用得起的东西，所以今天的人们可以以5万美元以下的价格购买一台具有32个内核和1TB的内存的服务器。
由于在实际使用中的多数OLTP数据库完全可以容纳1TB，所以我们在将数据读入内存处理的时候，需要重新评估存储在磁盘上的数据和产生的I/O成本的收益。
此外，当这个数据被更新并需要写回磁盘的时候，OLTP数据库也会产生成本。
内存优化表存储的方式完全不同于基于磁盘表存储的方式，并且这些新的数据结构使得数据访问和处理更加有效。
由于这一趋势使得产生更多可用的内存和更多的内核，所以微软SQLServer团队已经开始构建一个具有优化的大型主存储器和多核心的CPU的数据库引擎。
本文展现了这个新的数据库引擎功能的技术概述：
内存驻留OLTP。
欲了解更多关于内存驻留OLTP的信息，请参阅内存驻留OLTP（内存驻留优化）。
设计考虑和目的
创建真正的主内存中的数据库这一行动被三个基本需求驱动：
1）、整合大部分或全部数据所需的工作量到主内存，2）、数据操作需要更少的延迟时间，以及3）、专门的数据库引擎，这些引擎针对一些需要调整的特定类型的工作负载。
摩尔定律已经影响了内存的成本，并允许主存储器必须足够大，从而完全满足第一个需求和部分满足第二个需求。
（更大的内存降低读取的延迟，但并不影响在传统数据库系统需要的写入到磁盘的延迟）。
内存驻留OLTP的其他功能大幅度改善数据修改操作的延迟。
需要专门的数据库引擎来驱动一类特殊的工作，这些工作由识别系统设计，能够经常执行更通用的10个或10个以上的因素决定的系统。
诸如那些为CEP（复杂事务处理）、DW/BI和OLTP而创建的专业的系统，通过专注于内存驻留结构而优化数据结构和算法。
微软创建内存驻留OLTP的原因主要来源于一个事实–主内存大小正在以极快的速度增长，并变得更加便宜。
另外，由于近普遍性的64位架构和多核处理器，所以即使不是全部至少大多数OLTP数据库或整个性能敏感的工作数据集可以完全驻留在内存中，这样的认识是很合理的。
许多最大的金融、网上零售和航空订票系统介于500GB到5TB，这些系统的工作组都明显较小。
截至2012年，即使是两个插座的服务器都可容纳能使用32GB的DIMM的DRAM中的2TB（如IBMx3680X5）。
展望未来，完全可能在未来几年，您就能构建基于DRAM的分布式系统，可以通过小于5/GB美元的成本购买1-10PB的容量。
非易失性RAM的可行性也仅仅是一个时间问题。
如果大多数或所有应用程序的数据是能够完全在内存中留驻，那么自从第一个版本以来，SQLServer优化器已经开始使用这一成本规则就几乎完全过时了。
其原因是规则假定所有访问页面潜在地需要从磁盘上进行物理读取。
如果没有从磁盘读取的需求，优化器可以使用不同的成本算法。
此外，如果没有磁盘读取的等待时间的需求，其他等待的统计数据都可以不成比例的大，这些数据诸如等待锁被释放、等待锁可用、或等待日志写入完成。
内存驻留OLTP能解决这些所有的问题。
内存驻留OLTP通过使用一种新型的多版本的并发控制来解决等待锁被释放的问题。
它通过生成很少的日志数据以及较少的日志，从而降低了等待写入日志的延迟。
术语
SQLServer2014的内存中的内存驻留OLTP的功能是指一套与内存优化表协同工作的技术。
内存优化表的替代将被称为基于磁盘的表，这种表通常由SQL服务器所提供。
将使用的条款包括：
∙内存优化表是指使用新的数据结构，添加到内存驻留OLTP中，这部分介绍将在下文中详细阐述。
∙基于磁盘的表是指内存优化表的替代，其使用的数据结构是SQLServer常用的、8K的页面需要读取和写入到磁盘，从而成为一个单元。
∙本地编译的存储过程是指一种对象类型，这种类型被内存驻留OLTP所支持；内存驻留OLTP被编译为机器代码，并有可能进一步提高性能，甚至比只使用内存优化表更加优化。
另一种替代方案是采用基于解释型的Transact-SQL存储过程，这是SQLServer中常用的、采用基础的编译的存储过程只能引用内存优化表。
∙跨容器的事务是指同时参考内存优化表和基于磁盘的表的事务。
∙互操作性是指引用内存优化表的解释型的Transact-SQL。
功能概述
在内存驻留OLTP大部分的数据处理操作中，您可能并没有意识到正在使用的是内存优化表，而不是基于磁盘的表。
但是如果数据存储在内存优化表中，SQLServer处理您的数据的方式是截然不同的。
在本节中，我们将着眼于概述内存驻留OLTP的操作和数据的处理方式如何不同于SQLServer的基于磁盘的操作和数据。
我们也将简要地提及一些来自竞争对手的内存优化的数据库解决方案，并指出SQLServer中的内存驻留OLTP是如何与对手的方案不同。
内存驻留的OLTP有哪些技术亮点？
虽然内存驻留OLTP与SQLServer关系型引擎集成，并能通过相同的接口访问，但是其内部的行为和性能却大相径庭。
图1展现了一个关于包含内存驻留OLTP组件的SQLServer引擎。
图1：
包含内存驻留OLTP组件的SQLServer引擎
无论调用本地编译的存储过程或者Transact-SQL，客户端应用程序采用与内存优化表或基于磁盘的表同样的方式连接到TDS处理器。
您可以看到解释型的Transact-SQL能通过互操作能力访问内存优化表，但本地编译的存储过程只能访问内存优化表。
内存优化的表
优化内存的表和基于磁盘的表之间最重要的区别是优化内存的表被访问时，页面并不需要从磁盘被读入高速缓存。
所有数据在任意时间中都能被存储在内存中。
一组只用于恢复目的的检查点文件（数据和增量文件组）是建立于驻留在内存优化文件组的文件中，这些优化文件组能追踪数据的变化，并且这些检查点文件是仅限追加的。
内存优化表的操作使用与基于磁盘的表的操作相同的事务日志，和往常一样，事务日志被存储在磁盘上。
在系统崩溃或服务器故障时，内存优化表中的数据行可以从检查点文件和事务日志重新创建。
内存驻留OLTP提供选项来创建一个表，这个表并不是持久的，并且不会用一个称为SCHEMA_ONLY的选项记录。
这个选项显示表的架构将是持久的，尽管数据并不是持久的。
这些表在事务处理过程中并不要求任何IO操作，但该数据在SQLServer运行时，才在内存中可用。
在SQLServer死机或AlwaysOn的群组故障转移的情况下，在这些表中的数据会被丢失。
当所属的数据库被恢复时，这些表将被重新创建，但将不会重建表中的数据。
比如说，对于在ETL场景中临时表或对于存储Web服务器会话状态，这些表的用途可能是有用的。
虽然数据并不是持久的，这些表上的操作满足所有其他事务的要求；它们是原子的、孤立的、一致的。
我们将在创建表章节看到创建非持久表的语法。
内存优化的表索引
内存优化表上的索引并不是以传统的B-树的方式存储的。
内存优化表支持哈希索引和范围索引，哈希索引存储为带有链表连接的哈希表，每个链表连接包括映射为相同值的所有行，而范围索引使用特殊BW-树存储。
在CTP2之前，内存优化表上的非聚集索引并不可用。
因为是索引合并所有行进入到一个单一表中，所以每一个内存优化表必须至少有一个索引。
内存优化表并不像基于磁盘的表那样存储以无序行的方式存储。
索引从不会存储在磁盘上，这些索引不会反映在磁盘上的检查点文件中，而且索引上的操作从不被记录。
在内存优化表的所有修改操作中，索引会像基于磁盘的表B-树索引那样自动维护，但在SQLServer重启的情况下，当数据传输到内存中时，内存优化表的索引会被重建。
增强的并发性功能
当访问内存优化表时，SQLServer实现了主动的多版本并发控制。
虽然通过SQLServer2005中引入的基于快照的隔离级别，SQLServer之前就被介绍成为支持主动的并发控制，但是这些所谓的主动的方法在数据修改操作时确实需要获取锁。
对于内存优化表，并不需要获取锁，因此并没有由于阻塞而产生的等待时间。
请注意，这并不意味着当使用内存优化表时，不需要任何等待。
还是会有其他等待的类型，比如等待日志写入从而完成年底的事务。
但是当写入日志时，在内存优化表进行更改的记录比基于磁盘的表的记录是更加有效，所以等待的时间将大大缩短。
而且也从不会有任何从磁盘读取数据的等待，也没有对数据行上的锁的等待。
本地编译的存储过程
当通过内存优化表使用本地编译的存储过程时能得到最好的执行性能。
不过相对于可用于解释代码的丰富的功能集，也有一些关于在本地编译存储过程中允许的Transact-SQL语言结构的限制。
此外，本地编译的存储过程只能访问内存优化表而不能引用基于磁盘的表。
内存优化的OLTP是不是就是DBCCPINTABLE？
DBCCPINTABLE是早前版本的SQLServer当中的一个功能。
一旦页面从磁盘读取，该功能确保不会从内存中的“固定”表中删除任何数据页。
这些页面确实需要最初被读取，所以在访问一个表时总会有读取表的成本。
这些固定的表与其他基于磁盘的表没有什么不同。
他们需要相同数量的锁定、闭锁和日志记录，同时他们使用相同的索引结构，这些索引结构也需要锁定和记录。
内存驻留OLTP内存优化表与SQLServer的基于磁盘的表是完全不同，他们使用不同的数据和索引结构，锁定并不会被使用，并且对这些内存优化表的记录更改比对基于磁盘的表的记录更改更加有效。
竞争对手的解决方案
对于处理OLTP数据，有两种类型的引擎。
首先是主内存数据库。
Oracle有TimesTen产品、IBM有solidDB产品。
还有很多其他的主要针对嵌入式的数据库空间。
第二类是应用程序缓存或键值存储（例如，Velocity–应用程序光纤缓存和GigaSpaces），它们利用应用程序和中间层内存数据库系统来卸载数据库系统。
这些缓存继续变得更加复杂，并获得数据库的功能，如事务，范围索引和查询功能（GigaSpaces已经有这些）。
与此同时，数据库系统获取缓存功能，如在整个集群中的机器高性能Hash索引和规模（VoltDB就是一个例子）。
内存中的OLTP引擎是提供最好的这些类型的引擎。
一种考虑内存中的OLTP的方法是它有缓存和数据库的能力。
它支持存储在内存中的表和索引，所以您可以把整个数据库创建为内存中的一个完整系统。
它还提供了高性能的索引和记录以及其他功能，显着提高查询执行性能。
SQLServer内存驻留OLTP能够提供以下少数其他的（或任意其他的）产品都无法提供的功能：
∙集成内存优化表和基于磁盘的表可以逐渐过渡到内存驻留数据库，创建只有您最重要的表和存储过程作为内存优化对象。
∙本机编译存储过程来改善基本的数据操作的执行时间量级。
∙哈希和BW-树索引专门优化主记忆体存取。
∙页面不存储数据，删除页面需要锁存器。
∙真正的多版本积极并发控制的任何操作无锁定或闭锁。
SQLServer的内存驻留OLTP与竞争对手产品中设计最明显的差异是“互操作”一体化。
在一个典型的高端OLTP工作负载，性能瓶颈都集中在特定的领域，如一小部分表和存储过程。
这将是昂贵和低效的，以迫使整个数据库驻留在内存中。
但到今天为止，其他主要竞争力的产品需要这样的做法。
在SQLServer中，高性能和高竞争区域可以迁移到内存驻留OLTP，那么这些内存优化表的操作（存储过程）可以通过使用本地编译，以实现最大的业务处理性能。
另外一个关键的内存驻留OLTP优化是删除内存优化表的页面构造。
这从根本上改变了从磁盘优化内存和缓存优化数据操作算法。
正如前面提到的，关于内存驻留OLTP是否被简单认为是“DBCCPINTABLE”表被锁定在缓冲仍然有很多困惑。
然而，即使页面时都被迫留在内存中，很多的竞争对手还进行页面构造。
例如SAPHANA仍然使用16KB大小的页面当中进行内存中的行存储，这本质上会受到高性能环境的影响。
使用内存驻留的OLTP
内存驻留OLTP引擎从2013年6月CTP版本开始，已经成为SQLServer2014的一部分。
内存驻留OLTPSQLServer的安装是SQLServer安装程序的一部分。
内存驻留OLTP组件只能被安装在一个SQLServer201464位版本中，而不与32位版本兼容。
创建数据库
包含内存优化表的任何数据库至少需要有一个MEMORY_OPTIMIZED_DATA文件组。
这些文件组用于存储数据和增量文件，这些文件被SQLServer用来恢复内存优化表。
虽然创建MEMORY_OPTIMIZED_DATA文件组与创建常规FILESTREAM文件组的语法几乎是相同的，但是还是必须要指定CONTAINSMEMORY_OPTIMIZED_DATA这一选项。
以下是一个关于用CREATEDATABASE语句来创建可以支持内存优化表的数据库的示例：
CREATEDATABASEHKDB
ON
PRIMARY（NAME=[HKDB_data],
FILENAME='Q:
\data\HKDB_data.mdf',size=500MB）,
FILEGROUP[SampleDB_mod_fg]CONTAINSMEMORY_OPTIMIZED_DATA
（NAME=[HKDB_mod_dir],
FILENAME='R:
\data\HKDB_mod_dir'）,
（NAME=[HKDB_mod_dir],
FILENAME='S:
\data\HKDB_mod_dir'）
LOGON（name=[SampleDB_log],Filename='L:
\log\HKDB_log.ldf',size=500MB）
COLLATELatin1_General_100_BIN2;
请注意以上代码的示例在三个不同的驱动器上创建文件（Q：
、R：
和S：
）。
所以如果您想运行此代码，您可能需要编辑路径名称来与您的系统匹配。
在驱动器R：
和S：
上的文件名称是相同的，所以如果您在相同的驱动器上创建所有这些文件，您需要区分这两个文件名称。
同时请注意二进制排序规则已经被指定。
此时内存优化表的所有索引只能是使用Windows（非SQL）BIN2整理，并且本机编译存储过程只支持比较、排序、以及用相同的排序规则分组。
对整个数据库的默认二进制排序规则可以被指定（就像以上的CREATEDATABASE语句所做的那样），或者您可以指定在CREATETABLE语句中的任何字符数据的排序规则。
（您也可以指定在查询核对，任何比较、有排序或分组操作）。
也可以添加一个MEMORY_OPTIMIZED_DATA文件组到一个现有的数据库，然后文件可以添加到MEMORY_OPTIMIZED_DATA文件组中，例如：
ALTERDATABASEAdventureWorks2012
ADDFILEGROUPhk_modCONTAINSMEMORY_OPTIMIZED_DATA;
GO
ALTERDATABASEAdventureWorks2012
ADDFILE（NAME='hk_mod',FILENAME='c:
\data\hk_mod'）
TOFILEGROUPhk_mod;
GO
创建表
创建优化内存表的语法与创建基于磁盘的表的语法几乎相同，只有一些限制以及需要的扩展。
指定表是内存优化表是用MEMORY_OPTIMIZED=ON语句实现的。
内存优化表只可以有以下这些可支持的数据类型的列：
∙字节；
∙所有整数类型：
tinyint、smallint、int、bigint；
∙所有money类型：
money、smallmoney；
∙所有浮点类型：
float、real；
∙所有日期/时间类型：
datetime、smalldatetime、datetime2、date、time；
∙数字和浮点数类型；
∙所有非LOB字符类型：
char（n）、varchar（n）、nchar（n）、nvarchar（n）、sysname；
∙非LOB二进制类型：
binary（n）、varbinary（n）；
∙独特的识别符。
请注意的是LOB数据类型是
可用的；不能有XML类型、CLR、或者max数据类型的列，并且所有行的长度都限制在8060个字节之内，而且没有行外数据。
事实上，8060字节的限制是在表创建的时候执行的，所以不像基于磁盘的表，内存优化表不能创建两个varchar（5000）的列。
内存优化表可以通过两种DURABILITY值定义：
SCHEMA_AND_DATA或SCHEMA_ONLY，前者是默认值。
内存优化表由DURABILITY=SCHEMA_ONLY定义，这意味着表中数据的变化没有被记录下来，并且表中的数据并没有保存在磁盘上。
但是，架构会被作为数据库元数据的一部分保存下来，所以在一个SQLServer重启的过程中恢复数据库之后，这样的空表是可用的。
如前所述，内存优化表必须至少有一个索引，但这一要求能通过索引自动创建来满足，从而支持主键约束。
除了那些用schema_only选项所创建的表以外的其他表都必须有一个声明的主键。
至少有一个索引必须声明支持一个主键约束。
下面的示例显示了一个主键索引创建成为一个分区索引，其中的统计指标也必须被指定。
一些关于选择统计指标值的指导将在讨论关于分区索引存储的细节中提及。
如下图所示，单列索引可以在CREATETABLE语句中列定义时候一起创建。
BUCKET_COUNT属性将在哈希索引章节中讨论。
CREATETABLET1
（
[Name]varchar（32）notnullPRIMARYKEYNONCLUSTEREDHASHWITH（BUCKET_COUNT=100000）,
[City]varchar（32）null,
[State_Province]varchar（32）null,
[LastModified]datetimenotnull,
）WITH（MEMORY_OPTIMIZED=ON,DURABILITY=SCHEMA_AND_DATA）;
相反地，如下面的例子所示，复合索引可以在所有的列定义后再创建。
以下示例对上面的定义添加了一个范围的索引。
请注意这两种索引的不同之处是，一个使用关键字HASH，而另一个并没有。
这两种类型的索引被指定为NONCLUSTERED，但如果没有使用关键字HASH，这个索引就是一个范围索引。
CREATETABLET2
（
[Name]varchar（32）notnullPRIMARYKEYNONCLUSTEREDHASHWITH（BUCKET_COUNT=100000）,
[City]varchar（32）null,
[State_Province]varchar（32）null,
[LastModified]datetimenotnull,
INDEXT1_ndx_c2c3NONCLUSTERED（[City],[State_Province]）
）WITH（MEMORY_OPTIMIZED=ON,DURABILITY=SCHEMA_AND_DATA）;
当一个内存优化表被创建，在内存驻留OLTP引擎将只为访问表生成并编译DML例程，并加载程序成为DLL。
SQLServer本身并不在内存优化表上执行实际的数据操作（记录裂纹），而是当访问内存优化表时，对所需的操作调用相应的DLL。
当创建内存优化表时，除已列的对数据类型的限制之外，只有少数的其他限制：
∙没有DML触发器；
∙没有FOREIGNKEY或CHECK约束；
∙没有IDENTITY列；
∙除了主键没有唯一索引；
∙最多8个索引，包括支持主键的索引。
此外，一旦一个表被创建后，架构是不可改变的。
您将需要删除并重新创建表，而不是使用ALTERTABLE。
此外，并没有具体的索引DDL命令（比如创建索引、修
升级会员 