Partilhar via

Usar o OLTP in-memory no Banco de Dados SQL do Azure para melhorar o desempenho do aplicativo

  • Artigo

Aplica-se a: Banco de Dados SQL do Azure

O OLTP in-memory pode ser usado para melhorar o desempenho do processamento de transações, a ingestão de dados e os cenários de dados transitórios sem aumentar o objetivo de serviço do banco de dados ou do pool elástico.

  • Os bancos de dados e os pools elásticos nas camadas de serviço Premium (DTU) e Comercialmente Crítico (vCore) são compatíveis com o OLTP in-memory.
  • A camada de serviço de hiperescala é compatível com um subconjunto de objetos OLTP in-memory, mas não inclui tabelas com otimização de memória. Para obter mais informações, consulte Limitações da hiperescala.

Siga estas etapas para começar a usar o OLTP in-memory em seus bancos de dados existentes.

Etapa 1: Verifique se que você estivá usando um banco de dados de camada Premium ou Comercialmente Crítico

O OLTP in-memory terá suporte se o resultado da seguinte consulta for 1 (não 0):

SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');

XTP significa Extreme Transaction Processing, que é um nome informal do recurso OLTP in-memory.

Etapa 2: Identificar os objetos para migrar para o OLTP Na Memória

O SSMS (SQL Server Management Studio) inclui um relatório Visão Geral da Análise do Desempenho da Transação que pode ser executado em um banco de dados com uma carga de trabalho ativa. O relatório identifica as tabelas e os procedimentos armazenados candidatos à migração para OLTP Na Memória.

No SSMS, para gerar o relatório:

  • No Pesquisador de Objetos, clique com o botão direito do mouse no nó do banco de dados.
  • Selecione Relatórios>Relatórios Padrão>Visão Geral da Análise de Desempenho da Transação.

Para saber mais sobre como acessar os benefícios do OLTP in-memory, confira Determinando se uma tabela ou um procedimento armazenado deve ser transportado para o OLTP Na Memória.

Etapa 3: Criar um banco de dados de teste comparável

Suponha que o relatório indique que o banco de dados tem uma tabela que pode se beneficiar do que está sendo convertido em uma tabela com otimização de memória. É recomendável que você primeiro teste para confirmar a indicação.

Você precisa de uma cópia de teste do seu banco de dados de produção. O banco de dados de teste deve estar no mesmo nível da camada de serviço que o banco de dados de produção.

Para facilitar o teste, ajuste seu banco de dados de teste da seguinte maneira:

  1. Conecte-se ao banco de dados de teste usando o SQL Server Management Studio (SSMS).

  2. Para evitar a necessidade da opção WITH (SNAPSHOT) em consultas, defina a opção MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT do banco de dados atual, como mostrado na seguinte instrução T-SQL:

    ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

Etapa 4: migrar tabelas

Você deve criar e preencher uma cópia com otimização de memória da tabela que você deseja testar. Você pode criá-la usando:

Assistente de Otimização de Memória no SSMS

Para usar essa opção de migração:

  1. Conecte-se ao banco de dados de teste com o SSMS.

  2. No Pesquisador de Objetos, clique com o botão direito do mouse na tabela e selecione Supervisor de Otimização de Memória.

    O assistente Supervisor Otimizador de Memória da Tabela é exibido.

  3. No assistente, selecione Validação de migração (ou no botão Avançar) para ver se a tabela tem algum recurso sem suporte nas tabelas com otimização de memória. Para saber mais, veja:

  4. Se a tabela não tiver recursos sem suporte, o supervisor poderá executar o esquema e a migração de dados reais para você.

T-SQL Manual

Para usar essa opção de migração:

  1. Conecte-se ao seu banco de dados de teste usando o SSMS.
  2. Obtenha o script T-SQL completo para a tabela e as respectivas restrições e índices.
    • No SSMS, clique com o botão direito do mouse no nó da sua tabela.
    • Selecione Script de Tabela como>CRIAR Para>Nova Janela de Consulta.
  3. Na janela de script, adicione WITH (MEMORY_OPTIMIZED = ON) à instrução CREATE TABLE. Para obter mais informações, consulte Sintaxe para tabelas com otimização de memória.
  4. Se houver um índice CLUSTERED, altere-o para NONCLUSTERED.
  5. Renomeie a tabela existente usando sp_rename.
  6. Crie a nova cópia da tabela com otimização de memória executando o script CREATE TABLE editado.
  7. Copie os dados para sua tabela com otimização de memória usando INSERT...SELECT * INTO:
    INSERT INTO [<new_memory_optimized_table>]
SELECT * FROM [<old_disk_based_table>];

Etapa 5 (opcional): migrar procedimentos armazenados

O OLTP in-memory também permite procedimentos armazenados compilados nativamente, o que pode melhorar o desempenho do T-SQL.

Considerações sobre procedimentos armazenados compilados nativamente

Um procedimento armazenado compilado nativamente deve ter as seguintes opções na sua cláusula WITH do T-SQL:

  • NATIVE_COMPILATION: significa que as instruções Transact-SQL no procedimento são todas compiladas em código nativo para uma execução eficiente.
  • SCHEMABINDING: significa que as tabelas referenciadas no procedimento armazenado não pode ter suas definições alteradas de alguma forma que afete o próprio procedimento armazenado, a menos que você o descarte.

Um módulo compilado de forma nativa deve usar um bloco ATOMIC para o gerenciamento de transações. Não há uso de declarações BEGIN TRANSACTION ou ROLLBACK TRANSACTION explícitas. Seu código pode encerrar o bloco atômico com uma instrução THROW, por exemplo, se detectar uma violação de regra de negócios.

Um exemplo de um procedimento armazenado nativamente compilado

O T-SQL para criar um procedimento armazenado nativamente compilado é semelhante ao seguinte modelo:

CREATE PROCEDURE schemaname.procedurename
    @param1 type1, ...
    WITH NATIVE_COMPILATION, SCHEMABINDING
    AS
        BEGIN ATOMIC WITH
            (
            TRANSACTION ISOLATION LEVEL = SNAPSHOT,
            LANGUAGE = N'<desired sys.syslanuages.sysname value>'
            )
        ...
        END;
  • Para TRANSACTION_ISOLATION_LEVEL, o SNAPSHOT é o valor mais comum para os procedimentos armazenados nativamente compilados. No entanto, também há suporte para um subconjunto dos outros valores:
    • REPEATABLE READ
    • SERIALIZABLE
  • O valor LANGUAGE deve estar presente na exibição sys.syslanguages, na coluna name. Por exemplo, N'us_english'.

Como migrar um procedimento armazenado para usar a compilação nativa

As etapas de migração são:

  1. Obtenha o script CREATE PROCEDURE para o procedimento armazenado (interpretado) regular.
  2. Reescreva o cabeçalho para que ele corresponda ao modelo anterior.
  3. Determinar se o código T-SQL de procedimento armazenado usa os recursos sem suporte para procedimentos armazenados compilados nativamente. Implemente soluções alternativas, se necessário. Para saber mais, veja Problemas de migração para procedimentos armazenados compilados nativamente.
  4. Renomeie o antigo procedimento armazenado usando sp_rename ou descarte-o.
  5. Execute o script T-SQL CREATE PROCEDURE editado.

Etapa 6: executar sua carga de trabalho no teste

Execute uma carga de trabalho em seu banco de dados de teste que seja semelhante à carga de trabalho executada em seu banco de dados de produção. Isso deve revelar o ganho de desempenho obtido pelo uso do OLTP in-memory para tabelas e procedimentos armazenados.

Os principais atributos da carga de trabalho são:

  • Número de conexões simultâneas.
  • Taxa de leitura/gravação.

Para personalizar e executar a carga de trabalho de teste, considere usar a ferramenta ostress.exe do grupo de ferramentas Utilitários RML. Para obter mais informações, consulte Exemplo de In-Memory no Banco de Dados SQL do Azure.

Para minimizar a latência da rede, execute ostress.exe na mesma região do Azure em que está o banco de dados.

Etapa 7: Monitoramento pós-implementação

Considere monitorar os efeitos de desempenho de sua implementação do OLTP in-memory em produção:

Conteúdo relacionado