Compartilhar via

Usar o OLTP in-memory na Instância Gerenciada de SQL para melhorar o desempenho de aplicativos

  • Artigo

Aplica-se a: Instância Gerenciada de 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. A camada de serviço Comercialmente Crítico inclui uma certa quantidade de Memória OLTP In-Memory máxima, um limite determinado pelo número de vCores.

Siga estas etapas para adotar o in-memory OLTP no banco de dados existente na Instância Gerenciada de SQL do Azure.

Etapa 1 identificar os objetos para migrar para o OLTP in-memory

O SQL Server Management Studio (SSMS) 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 In-Memory.

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 2: 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 na mesma camada de serviço (Comercialmente Crítico) e a contagem de vCore 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 3: 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 banco de dados de teste usando o SSMS (ou um utilitário semelhante).
  2. Obtenha o script T-SQL completo para a tabela e seus í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.
  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 4 (opcional): migrar procedimentos armazenados

O recurso In-Memory também pode modificar um procedimento armazenado para melhorar o desempenho.

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 tabelas cujas definições de coluna o procedimento armazenado não pode alterar de alguma forma que afete o próprio procedimento armazenado, a menos que você descarte o procedimento armazenado.

Um módulo nativo deve usar grandes blocos ATOMIC para o gerenciamento de transações. Não há função para BEGIN TRANSACTION ou ROLLBACK TRANSACTION. explícitos Se seu código detectar uma violação de uma regra de negócio, poderá finalizar o bloco atômico com uma instrução THROW.

CREATE PROCEDURE típico para compilados nativamente

Normalmente, 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 o procedimento armazenado nativamente compilado. 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

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 simplesmente descarte-o usando DROP.
  5. Execute o script T-SQL CREATE PROCEDURE editado.

Etapa 5: 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 com o uso do recurso Na Memória 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 ajustar e executar a carga de trabalho de teste, considere usar a ferramenta útil ostress.exe.

Para minimizar a latência de rede, execute o teste na mesma região geográfica do Azure onde está o banco de dados.

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

Considere monitorar os efeitos de desempenho de suas implementações de Na Memória em produção:

Conteúdo relacionado