内存优化表支持的collation

在SQL Server中,Collation 决定varchar 或 char字段的Byte representation和Code Page。在内存优化表中,字符类型(varchar,char,nvarchar,nchar)的column,必须使用Code Page=1252的Collation;如果 memory-optimized index 创建在字符类型的Column上,那么该column只能使用以 BIN2 结尾的collation。

限制1,在字符列(unicode和 non-nicode)上创建Memory-optimized index,那么该字符列必须使用BIN2 collation。

Collation :Bosnian_Latin_100_BIN2 的Code Page 是1520,用于 LastName varchar(20) 时报错:The data types char(n) and varchar(n) using a collation that has a code page other than 1252 are not supported with memory optimized tables.

-- create a table with collation
CREATE TABLE dbo.Employees
(
  EmployeeID int NOT NULL ,
  LastName varchar(20) COLLATE Bosnian_Latin_100_BIN2 NOT NULL INDEX IX_LastName NONCLUSTERED,
  FirstName nvarchar(10) NOT NULL ,
  CONSTRAINT PK__Employees PRIMARY KEY NONCLUSTERED HASH(EmployeeID)  WITH (BUCKET_COUNT=1024)
)
WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_AND_DATA)
GO

在内存优化表中,要在non-unicode字符列上创建index,必须满足两个条件:Collation Name 以 BIN2 结尾,Code Page是1252;要在unicode 字符列上创建Index,只需要满足一个条件:Collation Name 以BIN2 结尾。

Indexes on (n)(var)char columns can only be specified with BIN2 collations

-- all supported collations for indexes on memory-optimized tables and
-- comparison/sorting in natively compiled stored procedures
select *
from sys.fn_helpcollations()
where name like ‘%BIN2‘
    and collationproperty(name, ‘codepage‘) = 1252;

限制2 ,在内存优化表中,non-unicode 字符列的Code Page必须是1252。如果需要存储Code Page不是1252的字符,必须使用 unicode 数据类型。

(var)char columns in memory-optimized tables must use code page 1252 collation. This restriction does not apply to n(var)char columns. If you need to store non-Latin characters, use n(var)char columns.

-- all supported collations for (var)char columns in memory-optimized tables
select * from sys.fn_helpcollations()
where collationproperty(name, ‘codepage‘) = 1252;

引用《Collations and Code Pages》:

In-Memory OLTP has restrictions on supported code pages for (var)char columns in memory-optimized tables and supported collations used in indexes and natively compiled stored procedures.

The code page for a (var)char value determines the mapping between characters and the byte representation that is stored in the table. For example, with the Windows Latin 1 code page (1252; the SQL Server default), the character ‘a‘ corresponds to the byte 0x61.

The code page of a (var)char value is determined by the collation associated with the value. For example, the collation SQL_Latin1_General_CP1_CI_AS has the associated code page 1252.

The collation of a value is either inherited from the database collation, or can be specified explicitly using the COLLATE keyword. Database collation cannot be changed if the database contains memory-optimized tables or natively compiled stored procedures. The following example sets the database collation and creates a table, which has a column with a different collation. The database uses Latin case-insensitive collation.

Indexes can only be created on string columns if they use a BIN2 collation. The LastName variable uses BIN2 collation. FirstName uses the database default, which is CI_AS (case-insensitive, accent-sensitive).

示例:创建一个内存优化表,使用collate 子句显式指定字符列的Collation,然后在字符列上创建memory-optimized index。

use master
go 

--create database
create database TestMemoryDB;

--add filegroup
alter database TestMemoryDB
add FileGroup FG_TestMemoryDB
contains MEMORY_OPTIMIZED_DATA;

--add file
alter database TestMemoryDB
add file
(
    name=‘TestMemoryDBDirectory‘,
    filename=‘D:\MSSQLServerData\MSSQL12.MSSQLSERVER\MSSQL\DATA\TestMemoryDBDirectory‘
)
to FileGroup FG_TestMemoryDB;

--  set the database collations
ALTER DATABASE TestMemoryDB COLLATE Latin1_General_100_CI_AS
GO

USE TestMemoryDB
GO

-- create a table with collation
CREATE TABLE dbo.Employees
(
  EmployeeID int NOT NULL ,
  LastName varchar(20) COLLATE Latin1_General_100_BIN2 NOT NULL INDEX IX_LastName NONCLUSTERED,
  FirstName nvarchar(10) NOT NULL ,
  CONSTRAINT PK__Employees PRIMARY KEY NONCLUSTERED HASH(EmployeeID)  WITH (BUCKET_COUNT=1024)
)
WITH (MEMORY_OPTIMIZED=ON, DURABILITY=SCHEMA_AND_DATA)
GO

参考doc:

Collations and Code Pages

时间: 2024-08-24 14:18:54

内存优化表支持的collation的相关文章

试试SQLSERVER2014的内存优化表

原文:试试SQLSERVER2014的内存优化表 试试SQLSERVER2014的内存优化表 SQL Server 2014中的内存引擎(代号为Hekaton)将OLTP提升到了新的高度. 现在,存储引擎已整合进当前的数据库管理系统,而使用先进内存技术来支持大规模OLTP工作负载. 就算如此,要利用此新功能,数据库必须包含"内存优化"文件组和表 即所配置的文件组和表使用Hekaton技术. 幸运的是,SQL Server 2014使这一过程变得非常简单直接. 要说明其工作原理,我们来创

SQLSERVER2014的内存优化表

SQL Server 2014中的内存引擎(代号为Hekaton)将OLTP提升到了新的高度. 现在,存储引擎已整合进当前的数据库管理系统,而使用先进内存技术来支持大规模OLTP工作负载. 就算如此,要利用此新功能,数据库必须包含“内存优化”文件组和表 即所配置的文件组和表使用Hekaton技术. 幸运的是,SQL Server 2014使这一过程变得非常简单直接. 要说明其工作原理,我们来创建一个名为TestHekaton的数据库,然后添加一个内存优化文件组到此数据库 测试环境:Microso

SQL Server 2014 内存优化表

不同于disk-based table,内存优化表驻留在内存中,使用 Hekaton 内存数据库引擎实现.在查询时,从内存中读取数据行:在更新时,将数据的更新直接写入到内存中.内存优化表能够在disk上维护一个副本,用于持久化数据集. Memory-optimized tables reside in memory. Rows in the table are read from and written to memory. The entire table resides in memory.

SQLServer 2014 内存优化表

内存优化表是 SQLServer 2014 的新功能,它是可以将表放在内存中,这会明显提升DML性能.关于内存优化表,更多可参考两位大侠的文章:SQL Server 2014新特性探秘(1)-内存数据库 试试SQLSERVER2014的内存优化表 创建内存优化表也很简单,以下测试: 添加内存优化数据库文件组:[sql] view plain copy 在CODE上查看代码片派生到我的代码片USE [master] GO -- 在当前数据库中添加内存优化数据库文件组(每个数据库仅1个文件组) AL

初识内存优化表

创建数据库 创建内存优化数据文件组 注意:每个数据库只能创建一个内存优化数据文件组. 创建内存优化数据文件 在文件组MemoryOptimizedData中添加一个文件夹MemoryOptimizedDataFile用来保存内存优化表数据 创建内存优化表 内存优化表分为两种类型: 持久表(默认):把数据保存在内存和内存优化数据文件组中. 非持久表:数据仅保存在内存中,一旦系统因为故障导致重启数据将会丢失. 因为SSMS目前不支持可视化创建,So只能手动创建内存优化表: 1 USE MyDB; 2

In-Memory:内存优化表的事务处理

内存优化表(Memory-Optimized Table,简称MOT)使用乐观策略(optimistic approach)实现事务的并发控制,在读取MOT时,使用多行版本化(Multi-Row versioning)创建数据快照,读操作不会对数据加锁,因此,读写操作不会相互阻塞.写操作会申请行级锁,如果两个事务尝试更新同一数据行,SQL Server检测到写-写冲突,产生错误(Error 41302),将后后创建的事务作为失败者,回滚事务的操作.虽然MOT事务使用无锁结构(Lock-Free)

Sql server2014 内存优化表 本地编译存储过程

参考文献:http://www.infoq.com/cn/news/2013/09/Compiled-Queries http://www.bianceng.cn/database/SQLServer/201502/48247.htm SQL Server 2014内存数据库针对传统的表和存储过程引入了新的结构: memory optimized table(内存优化表)和native stored procedure(本地编译存储过程). 内存优化表:  默认情况下Memory optimiz

SQL Server 内存优化表的索引设计

测试的版本:SQL Server 2017 内存优化表上可以创建三种类型的索引,分别是:Hash Index.内存优化非聚集(NONCLUSTERED)索引和聚集(CLUSTERED)列存储索引. 本文着重分享非聚集索引和哈希索引,这两个索引适用的场景是: 非聚集索引   如果查询中包含order by子句.或者包含 where index_column > value等范围扫描操作 ,推荐使用非聚集索引. 哈希索引       如果查询中包含点查找(point lookup),例如 where

In-Memory:内存优化数据的持久化和还原

数据持久化是还原的前提,没有数据的持久化,就无法还原内存优化表的数据,SQL Server In-Memory OLTP的内存数据能够持久化存储,这意味着内存数据能够在SQL Server实例重启之后自动还原.在创建持久化的内存优化表时,必须设置选项:memory_optimized=on,durability=schema_and_data.内存优化表的持久化由两个进程实现:Checkpoint和事务日志记录,在服务器重启之后,SQL Server通过存储在磁盘上的事务日志和Checkpoin