Classificações e Tabelas de Códigos

In-Memory OLTP tem restrições nas páginas de código suportadas para colunas (var)char em tabelas otimizadas para memória e nas ordenações suportadas usadas em índices e procedimentos armazenados compilados de forma nativa.

A página de código para um valor (var)char determina o mapeamento entre os caracteres e a representação em bytes que é armazenada na tabela. Por exemplo, com a página de código do Windows Latin 1 (1252; o padrão do SQL Server), o caractere 'a' corresponde ao byte 0x61.

A página de código de um valor de caractere (var)é determinada pela ordenação associada ao valor. Por exemplo, a collation SQL_Latin1_General_CP1_CI_AS tem associado o código de página 1252.

A ordenação de um valor é herdada da ordenação de banco de dados ou pode ser especificada explicitamente usando a palavra-chave COLLATE. A ordenação de banco de dados não poderá ser alterada se o banco de dados contiver tabelas com otimização de memória ou procedimentos armazenados compilados nativamente. O exemplo a seguir define a ordenação do banco de dados e cria uma tabela, que tem uma coluna com uma ordenação diferente. O banco de dados usa ordenação latina insensível a maiúsculas e minúsculas.

Os índices só podem ser criados em colunas de texto se utilizarem uma ordenação BIN2. A variável LastName usa ordenação BIN2. FirstName usa o padrão do banco de dados, que é CI_AS (sem diferenciação entre maiúsculas e minúsculas, sensível a acentos).

CREATE DATABASE IMOLTP  
  
ALTER DATABASE IMOLTP ADD FILEGROUP IMOLTP_mod CONTAINS MEMORY_OPTIMIZED_DATA  
ALTER DATABASE IMOLTP ADD FILE( NAME = 'IMOLTP_mod' , FILENAME = 'c:\data\IMOLTP_mod') TO FILEGROUP IMOLTP_mod;  
--GO  
  
--  set the database collations  
ALTER DATABASE IMOLTP COLLATE Latin1_General_100_CI_AS  
GO  
  
--  
USE IMOLTP   
GO  
  
-- create a table with collation  
CREATE TABLE Employees (  
  EmployeeID int NOT NULL ,   
  LastName nvarchar(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  

As seguintes restrições se aplicam a tabelas com otimização de memória e procedimentos armazenados compilados nativamente:

• As colunas char (var) em tabelas com otimização de memória devem usar a ordenação da página de código 1252. Essa restrição não se aplica a colunas n(var)char. O código a seguir recupera todas as 1252 ordenações:

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

  Se você precisar armazenar caracteres não latinos, use colunas char n(var).

• Índices em colunas (n)(var)char só podem ser especificados com colações BIN2 (consulte o primeiro exemplo). A consulta a seguir recupera todas as ordenações BIN2 com suporte:

  -- 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'  
  

  Se você acessar a tabela por meio do Transact-SQL interpretado, poderá usar a COLLATE palavra-chave para alterar a ordenação com expressões ou operações de classificação. Veja o último exemplo para obter um exemplo disso.

• Procedimentos armazenados compilados nativamente não podem usar parâmetros, variáveis locais ou constantes de cadeia de caracteres do tipo (var)char se a ordenação do banco de dados não for uma ordenação da página de código 1252.

• Todas as expressões e operações de classificação em procedimentos armazenados compilados nativamente devem usar colações BIN2. A implicação é que todas as comparações e operações de classificação são baseadas nos pontos de código Unicode dos caracteres (representações binárias). Por exemplo, toda classificação diferencia maiúsculas de minúsculas ('Z' vem antes de 'a'). Se necessário, use Transact-SQL interpretado para classificação e comparação sem diferenciação entre maiúsculas e minúsculas.

• Não há suporte para truncamento de dados UTF-16 dentro de procedimentos armazenados compilados nativamente. Isso significa que os valores n(var)char(n) não poderão ser convertidos no tipo n(var)char(i), se i<n, se a ordenação tiver _SC propriedade. Por exemplo, não há suporte para o seguinte:

  -- column definition using an _SC collation  
   c2 nvarchar(200) collate Latin1_General_100_CS_AS_SC not null   
  -- assignment to a smaller variable, requiring truncation  
   declare @c2 nvarchar(100) = '';  
   select @c2 = c2  
  

  Não há suporte para funções de manipulação de cadeia de caracteres, como LEN, SUBSTRING, LTRIM e RTRIM com dados UTF-16 dentro de procedimentos armazenados compilados nativamente. Você não pode usar essas funções de manipulação de cadeia de caracteres para valores de caractere n(var)que tenham uma ordenação _SC.

  Declare variáveis usando tipos grandes o suficiente para evitar truncamento.

O exemplo a seguir mostra algumas das implicações e soluções alternativas para as limitações de classificação em In-Memory OLTP. O exemplo usa a tabela Funcionários especificada acima. Este exemplo lista todos os funcionários. Observe que, para LastName, devido à ordenação binária, os nomes em maiúsculas são classificados antes dos em minúsculas. Portanto, 'Thomas' vem antes de 'nolan' porque os caracteres maiúsculos têm pontos de código mais baixos. FirstName tem uma ordenação que não diferencia maiúsculas de minúsculas. Portanto, a classificação é por letra do alfabeto, não pelo ponto de código dos caracteres.

-- insert a number of values  
INSERT Employees VALUES (1,'thomas', 'john')  
INSERT Employees VALUES (2,'Thomas', 'rupert')  
INSERT Employees VALUES (3,'Thomas', 'Jack')  
INSERT Employees VALUES (4,'Thomas', 'annie')  
INSERT Employees VALUES (5,'nolan', 'John')  
GO  
  
-- ===========  
SELECT EmployeeID, LastName, FirstName FROM Employees  
ORDER BY LastName, FirstName  
GO  
  
-- ===========  
-- specify collation: sorting uses case-insensitive collation, thus 'nolan' comes before 'Thomas'  
SELECT * FROM Employees  
ORDER BY LastName COLLATE Latin1_General_100_CI_AS, FirstName  
GO  
  
-- ===========  
-- retrieve employee by Name  
-- must use BIN2 collation for comparison in natively compiled stored procedures  
CREATE PROCEDURE usp_EmployeeByName @LastName nvarchar(20), @FirstName nvarchar(10)  
WITH NATIVE_COMPILATION, SCHEMABINDING, EXECUTE AS OWNER  
AS BEGIN ATOMIC WITH   
(  TRANSACTION ISOLATION LEVEL = SNAPSHOT,  
  LANGUAGE = N'us_english'  
)  
  SELECT EmployeeID, LastName, FirstName FROM dbo.Employees  
  WHERE   
    LastName = @LastName AND  
    FirstName COLLATE Latin1_General_100_BIN2 = @FirstName  
  
END  
GO  
  
-- this does not return any rows, as EmployeeID 1 has first name 'john', which is not equal to 'John' in a binary collation  
EXEC usp_EmployeeByName 'thomas', 'John'  
  
-- this retrieves EmployeeID 1  
EXEC usp_EmployeeByName 'thomas', 'john'  

Consulte Também

OLTP na memória (otimização na memória)