关于sqlserver2016内存功能介绍

关于sqlserver2016内存功能的介绍，我相信每个人都不是内存概念的新手. 以前，许多Daniels都介绍了SQL内存的创建方法. 详细信息尚不清楚，例如: 内存是否将整个都放在内存中？数据在内存中. 是关机还是关机？数据不消失了吗？根据它在内存中的存储方式还是基于页面，行的大小是否受到限制？内存称为无锁设计. SQL如何处理并发冲突？我相信这些问题也是人们在考虑内存时经常遇到的问题. 下面将逐一揭露这些问题的面纱. 如果有什么问题sql server内存，请请官员帮我指出. 1.如何仅在内存中存储内存？整个都在内存中吗？答: 不能. SQLServer 2016提供了许多令人兴奋的新功能，但是我认为最值得期待的功能之一是内存. 当我参加去年在西雅图举行的2016 SQL PASS峰会开幕式时，微软宣布它将在下一代SQL Server中包含一个代号为Hekaton的内存引擎. 现在，随着2016CTP1的到来，我们终于可以看到它的外观了. 内存位于传统表中. 由于磁盘物理结构的限制，表和索引的结构是B-Tree，这使得在大型并发OLTP环境中，这种类型的索引显得很弱，尽管有许多方法可以解决此问题. 乐观并发控制，应用程序缓存，分布式等.

但是成本仍然会更高. 随着多年来硬件的发展，服务器拥有数百G内存的情况并不少见. 此外，由于NUMA体系结构的成熟，还消除了多CPU访问内存的瓶颈问题，因此出现了内存. 内存的科学名称称为随机访问内存，因此，由于其特性是可以随机访问的，因此对于内存，相应的数据结构也将为Hash-Index，并发隔离方法也将相应地变为MVCC，因此内存在相同的硬件资源下，Handle具有更多的并发性和请求，并且不会被锁阻止. SQL Server 2016集成了此强大功能. 与需要额外付费的Oracle TimesTen不同，它结合了SSD AS缓冲池的功能，其效果将非常值得期待. SQL Server的Hekaton引擎中SQL Server内存的体现包括两部分: 内存优化表和本地编译存储过程. 尽管Hekaton已集成到关系引擎中，但是访问它们的方法对客户端是透明的，这也意味着从客户端应用程序的角度来看，将不知道Hekaton引擎的存在. 如图1所示. 图1.客户端APP将不会感知到Hekaton引擎的存在. 首先，内存优化表根本没有锁的概念. 此外sql server内存，内存优化表的哈希索引结构极大地提高了随机读写的速度. 此外，可以将内存优化表设置为非持久内存优化表，因此没有日志. 在本文中，我要强调以下两个信息: 内存实际上是将指定的表放入内存中，而不是整个中；内存使用文件流组织磁盘上的数据文件；我添加了另一个信息存储器的数据文件，分为数据文件和增量文件，并成对出现； 1，内存实际上是将指定的表放在内存中，而不是整个中；创建内存的过程实际上是将表存储在内存中，而不是整个中.

下图显示了创建内存优化表的语法. 创建语法时，红色框标记内存与传统表之间的差异. 内存优化表不仅将数据存储在内存中，还与传统的数据缓存没有什么不同. 在内存中，内存优化表也称为“本地编译内存优化表”. 已翻译是本地编译的内存优化表. 创建内存优化表后，该表将由同时编译的本地机器代码加载到内存中. 本地机器代码包含可由CPU直接执行的机器指令，因此内存优化表的访问和操作将非常快. 有两种类型的内存优化表，持久性表和非持久性表. 对持久性表的更改将被记录. 即使重新启动，数据也不会丢失；非持久表上的操作将不会被记录. 这些操作结果仅保留在内存中，并且重新启动后数据将丢失. 上面仅介绍了创建新表的情况. 在正常的业务环境中，我们不能在业务系统中创建每个表. 现有表格是否有配置方法？答案可能不是很令人满意. 当前，SQL不支持将现有表迁移到内存. 因此，要使用内存，必须重新创建现有的业务数据表. 2.内存将文件流中磁盘中的数据文件组织起来. 在内存中，磁盘上存储的数据文件不存储在区域或页面中，而是根据文件流存储.

文件流存储的特征之一是支持快速读取操作，当重新启动时将文件流中的数据加载到内存中可以提高效率. 3.内存的数据文件分为数据文件和增量文件，并成对出现；内存中插入，更新和删除的数据分别物理存储，并分别与数据文件和增量文件一起保存. 数据文件数据文件用于保存“插入”或“更新”的数据行. 严格按照执行事务的顺序来组织数据文件中数据行的存储顺序. 例如，数据文件中的第一行数据来自事务1，第二行数据来自事务2. 这两个行可以是同一表中的数据，也可以是不同表中的数据，具体取决于该表的内存优化表. 两个连续的事务操作是相同的. 此方法的优点是确保磁盘IO的连续性并避免随机IO. 数据文件的大小固定为128MB. 当数据文件已满时，SQL将自动创建一个新的数据文件. 因为数据保存在数据文件中的顺序是执行事务的顺序，所以表的数据行可能跨越多个数据文件. 在多行上更新操作时，写操作可以分布到多个文件上，并且可以同时进行，因此可以提高更新效率.

如下所示，总共有4个数据文件. 第一个数据文件的事务范围是100-200，第二个数据文件的事务范围是200-300 ...在数据文件中，如果删除或更新了一行，则不会从行中删除该行. 数据文件，但删除的行将通过增量文件进行标记，这可以消除不必要的磁盘IO. 如果数据文件中的数据从未删除过，是否不是文件大小无限制地增加，并且将来不必使用大磁盘进行备份吗？当然不是，SQL处理这个问题的方法实际上很简单-“合并”，根据合并策略，合并多个数据文件和增量文件，并根据内容删除数据文件中的冗余记录. 单击增量文件，然后将多个数据文件合并为一个文件，从而减少数据文件占用的磁盘空间量. 增量文件每个数据文件都有一个匹配的增量文件. 此匹配是指交易范围内的匹配. 两者记录同一事务上的数据. 增量文件将删除的行记录在数据文件中. 标记，此标记实际上是一个关联的信息{ing_tx_id，row_id，deleteing_tx_id}.

与数据文件相同，并且还严格按照事务操作的顺序保存已删除行的信息. 如上图所示，内存有5个数据文件，分别存储事务范围为100-200、200-300、300-400、400-500和500的数据. 如果带有时间戳的事务501需要删除由带有时间戳的事务150、250、450生成的数据并添加一些新数据，则将相应的IO请求分配给增量文件1、2、4和第五数据文件. 删除操作可以同时分发到多个文件，从而可以提高删除效率. 其次，数据全部在内存中. 当计算机关闭或关闭电源时数据是否消失了？答: 不能. 内存通过两种方式保证数据的持久性: 事务日志和chcekpoint. 事务日志存储中的“写日志”和“写数据”在一个事务中，在事务执行过程中，SQL将先“写数据”然后“写日志”，这与传统不同，在传统中无论是内存还是在磁盘上，“写数据”总是在“写日志”之后，通常称为WAL.

但是，提交事务时，内存和传统之间的“写日志”没有区别: 日志将在数据之前写入磁盘. 因此，即使服务器关闭或关闭电源，下次重新启动时，也会根据磁盘中已保存的事务日志重做该服务，因此不必担心数据丢失. 另外，需要添加的是内存仅将已提交的事务日志保存到持久表的磁盘上. 这样的好处可以减少磁盘写入的次数. 内存支持频繁和快速的操作，例如添加，删除和修改. 这种强度远高于传统. 需要为每个操作写入日志，这将生成大量磁盘IO，并且日志写入操作可能会成为性能瓶颈. 在不记录未提交的事务日志的情况下，减少写入日志的数量，从而可以提高性能. 一些学生可能想知道，如果不记录未提交的事务，是否会导致数据不一致？当然不是，因为在将日志写入磁盘之前不可能将“脏数据”写入磁盘. CheckPoint在内存中. CheckPoint的主要目的是将内存中的“数据”写入磁盘，从而减少了崩溃或重新启动时恢复数据的时间. 无需一一读取所有日志以恢复数据. 默认情况下，检查点是定期执行的. 当最后一个检查点之后日志增加512M时，将触发新一轮的CheckPoint.

在传统中，Checkpoint可以将未提交的数据刷新到磁盘上的mdf文件. 在内存中不会发生这种现象，因为内存仅记录已提交的事务，但是在写入日志之前不可能先将数据写入磁盘，因此可以保证将数据写入磁盘磁盘必须是已提交事务的数据. 3.数据如何存储在内存中或基于页面，行的大小是否受到限制？答: 不按照页面的方式，一行的限制大小是8060Bytes. 内存优化表根据行版本进行存储. 内存中同一行有多个版本. 内存优化表的存储结构可以视为表中所有行的多个行版本的集合. 内存优化表的行结构与传统的行结构不同. 下图描述了内存优化表中一行的数据结构: 在内存优化表中，一行由两大部分组成: 行标题和行主体，行标题记录了该行的有效期以及索引指针行主体记录一行的实际数据. 在内存优化表中，行版本的数量由该行的操作数量决定，例如: 每次更新将生成一个新行，添加一个行版本，该新行具有一个新的开始时间戳，以及一个新的生成行之后，原始数据行将自动填充结束时间戳，这意味着该行已过期. 备注: 上面的图片实际上只有3行，第1行有3行版本，第2行有2行版本，第3行有4行版本.

由于内存中同一行的行版本太多，因此如何在访问时控制？在传统中，表中的每一行都是唯一的. 如果要查找事务行，可以使用文件号，页码和插槽. 在内存中，每一行都有多个行版本. 事务不可能在每个行版本上进行操作. 实际上，一个事务只能在同一行的一个行版本上进行操作. 至于可以在哪个行版本上执行，该操作取决于事务执行时间是否在该行的两个时间戳之间. 其他行版本对事务不可见. 由于一行中可能存在多个行版本，因此您可能会问这样一个问题: 每行具有如此多的行版本，一个具有数百万行的表以及足够的内存. 不用担心，如前所述，每行实际上都带有时间戳. 对于已加时间戳记且未被活动事务访问的行，SQL Server将通过垃圾回收机制回收其使用的内存，从而节省内存. 因此，不必担心内存不足. 4.内存称为无锁设计. 如果发生并发冲突怎么办？SQL如何处理冲突？答: 内存使用行版本来处理冲突. 锁的重要作用是防止多个进程同时修改数据，从而导致数据不一致. 常见的冲突包括读写互锁和读写互锁. 内存如何通过行版本解决这两种锁定现象？读写互锁位于内存中，内存优化表的所有事务隔离均基于快照，准确地说是基于行的快照.

从上一行的结构中，我们可以知道每行的标题都包含开始时间戳和结束时间戳. 事务是否可以访问此行的关键是事务的开始时间是否在该行的两个时间戳中. 内. 如果事务正在修改一行，但尚未提交给内存优化表，也就是说，“新行”尚未结束时间戳，那么对于“读取事务”，它将读取原始行，因此它不会存在脏读现象. 写－写互锁当两个事务同时更新一行时，发生写－写互锁. 与传统相比，内存冲突的可能性要小得多，但是如果实际遇到冲突，则只能调整应用程序并向应用程序添加“重试逻辑”以解决该冲突. 也许有些学生认为以这种方式并没有重大的成绩变化. 实际上，否则，例如，在传统中，锁可以保存整个表. 在表锁定期间，您只能等待该事务完成，然后再执行其他事务. 实际上，此事务只能修改少量的行. 由于存在表锁，因此此事务不需要对其他行进行操作. 但是，内存中的写冲突始终发生在行级别. 这种粒度要小得多，影响也不是很大.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/jisuanjixue/article-241341-1.html