问题标签 [memory-optimized-tables]

在几天前的一次会议上，有人说“使用 Hekaton 会增加事务日志的大小，从而增加故障转移的时间”，同时描述了使用 Hekaton 内存表的 AlwaysOn SQL 集群的挑战。我不是 SQL 专家，所以想知道这是否是一个真实的陈述，如果是这样，是什么让 Hekaton 事务日志比没有 Hekaton 时更大？

我有一个实习，他们给了我一个关于内存数据库中 ms sql 的项目。实习结束，我们加载了数据库大量数据。

我的任务是在最短的时间内获取任何文件。我在互联网上研究了这个主题，尤其是在微软网站上。但是互联网上没有实现部分。我该怎么做这个任务。谁能帮助我？我不明白到底是什么我需要去做？

其实我理解内存数据库的概念。微软在系统中添加了一个名为Hekaton的新功能。它提高了速度。

公司问我，我们怎样才能在我们的系统中使用这个可以与 erp 程序集成的功能。

他们会将很多东西加载到数据库中。我需要在使用内存数据库时从数据库中获取任何东西。如何？我需要从哪里开始实施这个？

我使用的平台具有使用 SQL 服务器表作为队列的消息传递系统。

该系统基于此： 使用表作为队列

ATM 我们面临一些可扩展性问题，因为这种分布式模式主要基于 SQL 锁和磁盘操作，以保证数据的持久性/一致性。

为了解决基于磁盘的 I/O 瓶颈并改善糟糕的分配逻辑，我们正在考虑将基于磁盘的 SQL 表更改为 SQL 2014 和 2016 中可用的内存 SQL (Hekaton)。

我已经阅读了一些关于 Hekaton 的内容，但我仍然不确定这是否是最好的方法，或者是否可以将这些队列实现到内存中以及这是否是最好的方法。

这些队列中的大多数都在实现悲观并发，而 Hekaton 使用无锁系统仅乐观并发（基于多版本）。“总是”（我知道这是一个坏词）有可能将悲观的并发变为乐观的并发吗？例如在上述队列中。

Hekaton 是否适用于许多插入/删除（入队/出队）、订单行（FIFO 队列）和大量表大小变化（服务器上的工作负载变化会增加/减少队列大小）？是否可以正确更新本机存储过程查询性能的统计信息？

我觉得本机编译的 SQL 存储过程会大大提高性能，但我不确定这种实现（相关的 FIFO 队列）是否适合在 Hekaton 上使用，因为我没有找到任何“在内存队列”使用 Hekaton 实现。

我正在将磁盘中的队列迁移到内存 SQL Server 2016 以实现队列。

这是我的队列格式：

这是我的Enqueue原生 SQL Server 存储过程：

我正在尝试写下本Dequeue机 SQL Server 存储过程，但在如何实现UPDATESELECT 或变量表的使用结果方面遇到了一些困难。

到目前为止，我尝试过：

但我得到这个错误：

子查询（嵌套在另一个查询中的查询）仅在具有本机编译模块的 SELECT 语句中受支持。

所以我尝试了一种不同的方法，使用变量来存储结果。

首先我创建了一个表格类型：

到目前为止一切顺利，然后我尝试使用它：

我收到此错误：

必须声明标量变量“@result”。

（仅当使用@resulton时WHERE @result.MsgId = dbo.SimpleQueue.MsgId）

这是在磁盘 SQL Server 表中使用的旧出队过程：

如何使 UPDATE 和 OUTPUT 更新值（具有高性能，因为这很关键）？

我在让单列“varchar(5)”字段可靠地使用表搜索而不是表扫描时遇到了一些麻烦。本例中的生产表包含 2500 万行。尽管在 35 秒内扫描 2500 万行令人印象深刻，但查询应该运行得更快。

这是部分表格说明

通常，使用包括以下内容的查询访问此表：

此查询坚持使用表扫描。例如，我尝试过 WITH (FORCESEEK)，但这只会使查询失败。

当我调查了这个问题时，我也尝试过：

当我使用 64 个或更少（实际、有效）邮政编码运行此查询时，该查询使用表搜索。

但是当我给它 65 个或更多的邮政编码时，它会使用表扫描。

总而言之，生产查询总是使用表扫描，当我指定 65 个或更多邮政编码时，查询也使用表扫描。

坦率地说，我想知道索引列的数据类型（Latin1_General_100_BIN2 NOT NULL）是否存在某种问题。我可能会尝试将邮政编码转换为整数，看看会发生什么。

但我宁愿知道发生了什么，也不愿简单地随机尝试。

在 SQL Server 2014 的传统（基于磁盘）表中，我们有一个基于触发器的更改跟踪设置，其中对主表的以下更改在单独的审计表中进行跟踪：

oldvalue, newvalue, changedbyuser, 时间戳

我们正在评估迁移到内存优化表。内存优化表不支持触发器。因此，我们对传统表格的基于触发器的方法将不再有效。

服务代理提供了异步机制来解决这个问题，但是，我被困在如何通知服务代理表更改。我正在探索使用查询通知来实现事物。通知程序将侦听表上的更改，并在发生更改时通知服务代理。

我想知道社区对此的看法。

我正在尝试为 SQL Server 2016 RC 2 中的内存优化表编写删除触发器

当我运行此查询时，我收到以下错误。子查询（嵌套在另一个查询中的查询）仅在具有本机编译模块的 SELECT 语句中受支持。

我有一个本机编译的存储过程，我想异步执行另一个存储过程。背景是，我需要尽可能快地存储一些暂存数据（在我本机编译的存储过程中），并且我想异步调用另一个存储过程来进一步处理我的数据（但不“阻塞”当前本机编译的存储程序）。

有人知道这是否可能吗？

这是我想要的一个例子：

我正在使用循环游标的存储过程。在游标内，我正在调用本机编译的存储过程。本机编译的存储过程向内存优化表执行插入操作。

我的问题是我在一段时间（3分钟左右）后遇到错误“资源池'默认'中的系统内存不足，无法运行此查询”。

我追查了问题，似乎插入语句（或它的底层查询）产生了问题并抽出似乎在插入之后没有释放的内存，也没有在存储过程之后。

我从大约 3 GB 的已用内存（在我的数据库上）开始，当查询运行时，它逐步达到 12 GB（这是限制）并导致错误。错误发生后，内存立即下降到 3 GB，这表明它不可能是插入表大小本身的问题。在我的主存储过程中，它大约有 29 个循环（在游标中），因此游标本身可以正常工作。如果我删除插入语句（见下面的代码），一切都很好。所以问题一定是插入语句（分别是底层查询）。我不明白，为什么 SQL Server 在插入后（或者至少在执行本机存储过程之后）似乎没有释放内存。

任何想法如何解决这个问题（我正在使用 SQL Server 2014）？

这里是本机编译的存储过程的代码：

我们当前的系统架构如下：

我们在数据库表中有大约 500 万条记录。根据需要，我们得到一个包含 100 万条记录的结果集，并将它们保存在整个应用程序的缓存中，当我们完成时，将它们删除。

现在，不使用 .NET 应用程序的内存，“是否可以使用内存表将这 100 万条记录保存在内存表中，而基于磁盘的表仍保留 500 万条记录？”