标签: memory-optimized-tables

重现问题的步骤

创建具有内存优化文件组和容器的数据库 使用非集群 pk 创建仅模式内存表 模拟插入和删除活动。我的结果是我有高索引未使用的内存，不会下降。

 USE master
 go
 DROP DATABASE IF EXISTS MemoryOptimizedTest
 CREATE DATABASE MemoryOptimizedTest
 GO
 USE MemoryOptimizedTest
 GO
 ALTER DATABASE MemoryOptimizedTest 
 ADD FILEGROUP imoltp_mod CONTAINS MEMORY_OPTIMIZED_DATA
 GO 
 
 ALTER DATABASE MemoryOptimizedTest ADD FILE (name='imoltp_mod1', filename='c:\imoltp_mod1') TO FILEGROUP imoltp_mod
 GO
 
 
 DROP TABLE IF EXISTS dbo.MyCache
 CREATE TABLE dbo.MyCache
 (
    PK int NOT NULL, 
    SecondInt int NOT NULL,
    ThirdInt int NOT NULL,
     CONSTRAINT PK_MyCache PRIMARY KEY NONCLUSTERED (PK)
 ) WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)
 
 go

/* Generate activity …

我正在使用 sqlalchemy 将对象存储在数据库中。我正在创建的对象类型在运行时之前是未知的。我可以存储像字符串一样简单的东西。我可以存储一个jpg。我可能会创建自己的文件格式并存储它。重点是它很灵活。

我设想的表格至少包含两列。一个描述文件类型（.jpg、.txt、.py 等），另一个是包含文件数据的 blob。我想知道的是我在创建表时是否需要定义 blob 大小。是否可以让mysql动态设置blob的大小？这将很好地简化我的设计。

我知道还有其他方法可以做到这一点，但我有充分的理由这样做。如果它变成死胡同，我不介意沿着这条路走下去，然后再翻倍。

我们最近在我们的 mysql-cluster 上从 mysql5.5.x/mysql5.1.x 升级到 mysql5.6.25。下面是我们架构的简要快照。

自从我们升级并启用 gtid-mode 以来，我们一直在间歇性地收到类似于以下内容的从属错误：

Last_SQL_Error: 错误 '当@@SESSION.GTID_NEXT 设置为 GTID 时，您必须在 COMMIT 或 ROLLBACK 后将其显式设置为不同的值。请查看 GTID_NEXT 变量手册页以获取详细说明。当前@@SESSION.GTID_NEXT 是“d7e8990d-3a9e-11e5-8bc7-22000aa63d47:1466”。在查询。默认数据库：'adplatform'。查询：'像 X 一样创建表 X_new'

我们的观察如下..

• 这些从站错误只需重新启动从站即可解决。
• 此类错误始终与具有内存存储引擎的表的创建/删除有关。
• Complete-Slave(B) 上的错误在每小时的固定分钟（第 39 分钟）不断出现，并且自我们升级以来一直重复，将近一周。
• 每当其主机重新启动时，都会观察到 Complete-Slave 和 Partial slave 上的错误。
• Cluster-1 和 Cluster-2 有 centos 机器，Cluster-3 有 ubuntu-machines。centos 机器上的 slave 也会在其 master(C/D) 重新启动时失败并显示相同的错误，但 ubuntu 机器上的 slave 不会失败！！

我们暂时能够通过在我们的监控系统上设置一个动作脚本来解决这个问题，该脚本在任何机器上触发从属错误警报。

查看mysql的replication-options doc中的gtid_next部分告诉以下内容

在 MySQL 5.6.20 之前，当 GTID 已启用但 gtid_next 不是 AUTOMATIC 时，DROP TABLE 在非临时表与临时表的组合或使用事务存储引擎的临时表与使用非事务存储引擎的临时表的组合上使用时无法正常工作. 在 MySQL 5.6.20 及更高版本中，DROP TABLE 或 DROP TEMPORARY TABLE 在与这些表组合中的任何一个一起使用时失败并显示显式错误。（错误＃17620053） …

我刚刚在sp_who使用MEMORY_OPTIMIZED表的SQL Server 2016 实例上XTP_THREAD_POOL运行，我看到几个进程正在运行：

有关输出的其他一些详细信息：

• XTP_THREAD_POOL结果集中正好有 6行
• 我的系统有两个逻辑核心
  • 具体来说，它是一个带有 2 个插槽的 VM - 每个插槽都装有一个 1 核处理器
• 所有这些任务都作为后台运行（sa）

这些进程在做什么？我在 Google 上没有找到太多关于此任务名称的信息。

TIA

拥有一个 SQL Server 2017 Standard edition box，版本为 14.0.3045.24，带有一个内存优化表。当我们的第 3 方备份完成时，SQL Server 2017 错误日志显示了多条 [INFO] 消息，其中包含HKHostFreezeCkptTrimming()、HKHostBackupDeleteContext()、getMaxUnrecoverableCheckpointID()并具有相同的用户数据库 ID。你们中有人熟悉这些消息吗？这是一个错误还是有这些消息的修复程序？

其他测试表明这些 [INFO] 消息出现在完整、差异、事务日志和手动仅复制备份期间。性能很好，用户也没有抱怨，但考虑到所需的备份量，这些消息正在填满错误日志。

我能做些什么来限制这些消息在错误日志中的输入？或者这是处理额外消息的情况？

在我们的一台生产服务器上，我发现索引大小是数据大小的 10 倍。

这些服务器和模式与类似的工作负载相同。

CREATE TABLE [dbo].[process_aggregation_close]
(
    [organization_id] [bigint] NOT NULL,
    [computer_id] [uniqueidentifier] NOT NULL,
    [process_id] [int] NOT NULL,
    .
    .
INDEX [ix_process_aggregation_memory_computer_id_process_id] NONCLUSTERED 
(
    [organization_id] ASC,
    [computer_id] ASC,
    [process_id] ASC
)
)WITH ( MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_ONLY )
GO

表是临时表，它们涉及非常频繁的插入/删除操作。

Microsoft SQL Server 2017 CU9 标准版。

所有数据库都处于完全恢复模式。我认为它与checkpoint无关，因为这些表仅是模式持久的。（无论如何，我尝试了一个没有效果的手动检查点）。

这些内存表是暂存的，并且总是存在插入和删除活动。我监控了五个负载相似的 SQL Server。此行为仅发生在一个上。

检查 SQL Server 2019 CTP 2.5 (15.0.1500.28) 我发现了这个新的配置选项，并在它背后徘徊。到目前为止找不到任何信息，想知道您是否知道在哪里可以找到更多信息？

我正在尝试放置一个内存中 OLTP 表，

这是您需要的内存估计：

但当迁移开始时，会显示以下错误消息：

我的表大小约为22GB

我有一台 64GB 内存的服务器，我为 SQL 分配了 56GB，为了将表放入内存，我只需要 23GB

有谁能够帮助我？谢谢。

我有一个内存优化表（在我的测试中）有 1000 万行。UPDATE针对它并行运行一些，我得到 CPU 的间歇性峰值和查询的执行时间的巨大峰值（从 1 毫秒开始> 1 秒）。CPU 峰值是由 SQLServer 引起的。在这些高峰期间，所有查询都很慢，即使是不使用相同表或GETUTCDATE.

它在 SQL Server 2019 CU10、8 核和 100GB RAM 上运行。我还让它在裸机服务器（24 核）、新的 VM 和我的笔记本电脑上运行，结果或多或少相同。该表在我的测试系统中有 1000 万行，在 prod 中有 40 mio。有四个NONCLUSTEREDindizes 和两个NONCLUSTERED HASH，它们没有长链并且有很多未装满的桶。

Prod 使用许多 InMemory 表、外键和本机编译的过程，所以我在减少问题的同时保持完全相同的特征时遇到了一些问题。在我重现该问题时，我在 C# 中并行运行 10 个线程，每次更新之间等待 1-5 毫秒：

UPDATE ContainerAutoTest SET LastComment = 'TestEntry' WHERE Name = @TestContainer

每个线程都有自己的要更新的行，因此行级别不应该有任何冲突。我是从同一台机器还是通过网络运行查询都没有关系。

在 prod 中，我们在写入数据时大约每 30 秒就会出现一次尖峰，在我的测试中，我可以在大约 20 秒甚至每 2 秒处重现尖峰，具体取决于机器、我正在运行的线程数量以及更新之间的等待时间。

我已经重建了一个全新的表，我可以在其中重现问题：

CREATE TABLE [dbo].[ContainerAutoTest]
(
    [Id] [int] IDENTITY(1,1) NOT NULL, …

考虑以下：

CREATE DATABASE [Foo]
ALTER DATABASE [Foo] ADD FILEGROUP XTP CONTAINS MEMORY_OPTIMIZED_DATA
ALTER DATABASE [Foo] ADD FILE (NAME=XTP,FILENAME='C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\Bar_XTP') TO FILEGROUP XTP 
GO
USE [Foo]
CREATE TABLE dbo.A(
    ID INT NOT NULL CONSTRAINT PK_A_ID PRIMARY KEY NONCLUSTERED, 
    [Start] DATETIME2 GENERATED ALWAYS AS ROW START,
    [End] DATETIME2 GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME([Start], [End]),
    INDEX IX_A_CCS CLUSTERED COLUMNSTORE
) WITH (
    MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA,  
    SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.A_History)
)

这个奇妙的装置结合了 SQL Server …