标签: in-memory-database

我已经从这里下载了基于 AdventureWorks 的内存示例，并遵循了随附文档中描述的所有步骤。但是，当我尝试在 SQL Server Management Studio 中运行脚本时，我收到错误消息：

多语句事务中不允许使用 ALTER DATABASE 语句

错误指向第 9 行，即：

IF NOT EXISTS (SELECT * FROM sys.data_spaces WHERE type='FX')
    ALTER DATABASE CURRENT ADD FILEGROUP [AdventureWorks2012_mod] 
    CONTAINS MEMORY_OPTIMIZED_DATA
GO

由于这是（或多或少）微软官方文档，我假设这是我做错的事情，但我无法弄清楚它是什么。

描述：

RocksDB 是一个键值存储，因此我们可以简单地序列化对象列表并存储与键对应的值。如果列表中的数据足够小，这将是可以的。

但是如果列表很大并且大小不断增加，那么我们需要对数据进行分页。因此，在这种情况下，存储与单个键对应的整个序列化列表数据不是一个好主意；因为会存在性能问题，因为每次将新数据插入列表时，这个非常大的值也需要在读取期间读取和更新，当向用户显示列表时，将检索整个值，而只有一部分是用户需要。

例如：假设我们想将用户下的订单存储在 RocksDB 中。然后我们可以在 RockDB “u:1:li:o” 中以下列方式存储这个订单数据：Serialised([O1{}, O2{},....On{}])。但是如果用户下的订单数以千计，我们想以页面的形式检索订单（一次 10 或 20 条记录）。因此，在同一个键中存储数千个订单并从该键中检索整个数据然后提供所需的 10-20 条记录并不是一个好主意。此外，用户向同一键添加新订单将影响上述性能。

所以我正在努力设计模式以在 RocksDB 中有效地存储和检索如此大的列表。

如果您能就架构设计提出您的建议，那将会很棒且非常有帮助。

内存中的 OLAP 引擎是否比传统的 OLAP 引擎有优势，并有足够的 RAM 支持以包含整个多维数据集？

例如，如果我使用 MOLAP 引擎 (SSAS) 和 GB/TB 的 RAM，其中整个多维数据集（甚至星型模式）都驻留在 RAM 中，那么与 TM1/SAP HANA 之类的东西相比有什么区别？

在 SQL Server 2014 中，内存中 OLTP，如果事务回滚并且不再需要新创建的行版本，会发生什么。垃圾收集器是否有责任删除此类行，或者在事务回滚时会在运行时收集此类垃圾？

Oracle 最近在 12c 中宣布了其最新的Oracle 数据库内存功能。

Oracle 已经有一个内存数据库 TimesTen，现在我想知道这两个野兽之间有什么区别？

我有一个 SQL Server 2016 数据库，并且配置了内存表。我想删除此配置，然后删除该表。当我想删除该文件和文件组时，出现以下错误。

USE [InMem_Test]
GO
ALTER DATABASE [InMem_Test]  REMOVE FILE [InMemFile]
GO
ALTER DATABASE [InMem_Test] REMOVE FILEGROUP [InMemFileGroup]
GO

消息 41802，级别 16，状态 1，第 3 行无法删除最后一个内存优化容器“InMemFile”。消息 5042，级别 16，状态 11，第 5 行无法删除文件组“InMemFileGroup”，因为它不为空。

我使用 Java 中的以下代码创建并使用内存中的 H2 数据库（不写入存储）进行演示和快速测试：

 Connection conn = DriverManager.getConnection( "jdbc:h2:mem:example_db" ) ;

这第一次有效，但随后数据库似乎消失了，无法进行进一步的工作。如何随着时间的推移使用相同的内存数据库？

我知道 PostgreSQL 仅自动为足够小的表使用 RAM。但我不仅仅谈论表内的数据，而是谈论整个表本身。

基本上，我（很差地）在 PHP 数组中重新实现了各种数据库功能，例如，当我从 API 获取数据并希望在将其显示在控制面板中之前对其进行排序或“按摩”时。在这种情况下，拥有一个仅用于此目的且带有临时数据的实际数据库表是没有意义的（至少对我来说）。如果我可以即时创建一个表，将其填充到 RAM 中，进行排序，然后使用普通的 PG SQL 查询从中获取记录，那就更好了。

这是一件事吗？我有数组结构和各种试图模仿 SQL 的“SORT BY”的函数，这感觉很愚蠢。

当然，我不是在谈论执行CREATE TABLE，向其中添加数据，然后再次返回给 PHP，然后DROP TABLE. 这对于性能来说是非常糟糕的。

如果没有办法做到这一点，我就会接受它，但我常常认为这是非常有意义的。

我们在 Windows 上使用 SQL Server 2019，并在某些数据库上激活了内存中 oltp。服务器重新启动/服务重新启动后，内存数据库需要很长时间才能可用（超过一个小时），即使大多数表不持久。内存优化对象的大小非常小：10 MB

我们看到主数据库上有一个等待类型为（110514580ms）WAIT_XTP_RECOVERY的后台会话，并且几乎没有读取。CPU 核心利用率为 100%。磁盘闲置。

我们对此数据库使用透明数据加密（TDE）。该数据库使用同义词来访问同一实例上的另一个数据库。它使用服务代理。实例在数据库上设置了事务复制，但未激活内存。

添加 CPU 使其速度更快。这是一台低端机器，但并不垃圾。XTP 引擎 2.11。

知道发生了什么事吗？

我创建了服务器范围 ddl 触发器来审核服务器上的用户活动。
现在，如果有人尝试创建内存表，该语句将失败并显示以下错误：

Error SQL72014: .Net SqlClient Data Provider: Msg 12332, Level 16, State 107,
Line 1 Database and server triggers on DDL statements DROP and CREATE are not
supported with memory optimized tables.

我可以创建 ddl 触发器来忽略对内存表的操作吗？

在内存 OLTP 表中访问实体框架是否有任何限制？或者这是不可能的？