[Memory Optimization Advisor] – Migrando os Dados para In-Memory (Hekaton)

Posted on fevereiro 3, 2014

1


Introdução

De acordo com que as releases do SQL Server 2014 são lançadas, diversas features são implementadas.O recuso de In-Memory para o SQL Server 2014 é sem dúvidas uma das maiores e mais importantes features implementada pelo time de produto do SQL Server, veja aqui mais sobre – https://luanmorenodba.wordpress.com/category/hekaton/.

Estamos no SQL Server CTP II e com isso para ajudar o DBA que deseja migrar os dados para o Hekaton (In-Memory OLTP) o time lançou uma feature chamada Memory Optimization Advisor. O objetivo é guiar a migração das tabelas que estão em disco (On Disk) para a memória (In-Memory).

 

Recomendações

Antes de começarmos é interessante conhecermos alguns pré-requisitos para que sua migração seja eficiente e com sucesso, segue lista de recursos não suportados

  • Tipos de Dados não suportados
    • Datetimeoffset
    • Varbinary(max)
    • Varchar(max)
    • Nvarchar(max)
    • XML
    • Text
    • Image
    • Sql_Variant
  • Colunas Computadas
  • Sparse Column
  • Identity – (Somente na Release Final)
  • Particionamento ou Replicação da Tabela
  • Foreign Key
  • Constraints
  • Trigger

 

Verificando Informações da Tabela

Após a instalação do SQL Server 2014 CTP II, existe um banco de dados AdventureWorks que possui toda a estrutura para se trabalhar com os recusos do Hekaton – http://msftdbprodsamples.codeplex.com/releases/view/114491 iremos utilizar ele nessa demonstração.

 

Iremos migrar a tabela – Sales.SpecialOffer_OnDisk para In-Memory (Hekaton).

 

Verificando os campos das tabelas antes da migração.

SELECT ST.name AS NomeTabela,

          SC.name AS NomeColuna,

          STY.name AS TipoColuna,

          STY.max_length AS TamanhoColuna

FROM sys.tables AS ST

INNER JOIN sys.columns AS SC

ON ST.object_id = SC.object_id

INNER JOIN sys.types AS STY

ON STY.user_type_id = SC.user_type_id

       AND STY.is_user_defined = 0

WHERE ST.object_id = OBJECT_ID(‘[Sales].[SpecialOffer_OnDisk]’)

ORDER BY SC.column_id

 

image

(Figura 1 – Informações da Tabela – Aparentemente não temos nenhum tipo de dado não suportado para a migração da estrutura e dos dados.)

 

SELECT object_id ,name, is_memory_optimized, type_desc

FROM sys.tables

WHERE object_id = OBJECT_ID(‘[Sales].[SpecialOffer_OnDisk]’)

 

image

(Figura 2 – Verificando a FLAG – is_memory_optimized ou seja a tabela ainda não está em memória.)

 

Memory Optimization Advisor

Para iniciamos o Memory Optimization Advisor iremos no banco de dados aonde se encontra a tabela e após isso botão direito na tabela Sales.SpecialOffer_OnDisk

 

MOA

(Figura 3 – Iniciando o Memory Optimization Advisor.)

 

Após isso o mesmo irá validar todos os pré-requisitos listados acima.

DiskVsInMemoryMigration

(Figura 4 – Constraints não são suportadas no Hekaton.)

 

Para retirar a inconsistência segue script, o mesmo irá deletar as DEFAULT Constraints da Tabela.

ALTER TABLE [Sales].[SpecialOffer_ondisk]

DROP CONSTRAINT ODDF_SpecialOffer_DiscountPct

 

ALTER TABLE [Sales].[SpecialOffer_ondisk]

DROP CONSTRAINT ODDF_SpecialOffer_MinQty

 

ALTER TABLE [Sales].[SpecialOffer_ondisk]

DROP CONSTRAINT ODDF_SpecialOffer_ModifiedDate

 

Outro validação muito importante é verificar todos os objetos que refereciam a tabela, isso é muito importante imagina a tabela possuir views a após a migração as mesmas não funcionarem mais, por isso temos os Warnings que são gerados para termos idéia do que temos ou devemos alterar após migrar a tabela para In-Memory.

 

WarningsMigrationInMemory

(Figura 5 – Warnings gerados pela Memory Optimization Advisor – A view Sales.usp_InsertSalesOrder_ondisk faz referência com a tabela, após migração a mesma deve ser alterada.)

 

Agora que verficamos e corrigimos todas as inconsistências geradas, iremos selecionar o filegroup In-Memory ou criar caso o Banco de Dados não possua – https://luanmorenodba.wordpress.com/2013/07/01/in-memory-a-k-a-oltp-hekaton-deep-dives-1/

 

MigrationFinalPhase

(Figura 6 – Filegroup In-Memory selecionado.)

 

Podemos agora escolher um nome para a renomear a tabela original, e outro ponto muito forte é marcar a FLAG – Also Copy Table Data to the New Memory Optimized Table, assim além da migração da estrutura da tabela os dados serão migrados automaticamente. Possuimos dois modos no Hekaton – DURABILITY – SCHEMA e SCHEMA_AND_DATA

  • SCHEMA – Quando uma tabela é marcada com essa opção após o SQL Server ser reiniciado os dados da tabela são apagados mantendo assim somente a estrutura da tabela.
  • SCHEMA_AND_DATA – Dessa forma independente do SQL Server ser reiniciado ou não, os dados sempre estarão armazenados em memória e nos arquivos de Delta, Data e Log do SQL Sever – https://luanmorenodba.wordpress.com/category/hekaton/

 

ChoosingPrimaryKeyInMemoryTable

(Figura 7 – Selecionando o campo no qual será criado o índice na tabela.)

 

IndexPhaseMigration

(Figura 8 – Tipo do Índice que será criado na tabela.)

 

As tabelas In-Memory possuem dois tipos de Índices

  • Hash-Index – Esse índice é excelente para equalidades para buscar por campos númericos. Recomendado para ser a chave primária de um sistema OLTP.
  • Range-Index – Eficiente para pesquisas de range de valores

FinalReport

(Figura 9 – Relatório de Status do que foi selecionado para migração.)

ResultsMigration

(Figura 10 – Passos da migração da tabela em disco para tabela In-Memory.)

SELECT object_id ,name, is_memory_optimized, type_desc

FROM sys.tables

WHERE object_id = OBJECT_ID(‘[Sales].[SpecialOffer_OnDisk]’)

 

image

(Figura 11 – FLAG – is_memory_optimized marcada como 1.)

 

Após isso a tabela Sales.SpecialOffer_OnDisk  está em memória, aproveite e após isso faça comparativos de velocidade entre a tabela em disco para tabela em memória e se surpreenda.