Todos os produtos
Search
Central de documentação

Data Management:Otimização de revisão SQL em tickets de alteração de dados

Última atualização: Sep 22, 2026

A otimização de revisão SQL nas regras de segurança do DMS verifica instruções SQL no SQL console e em tickets de alteração de dados em busca de problemas de conformidade — como comentários de tabela ausentes ou colunas obrigatórias — e sugere melhorias, como alterações sem bloqueio. Este tópico demonstra como configure uma regra de revisão SQL e aplicá-la a um ticket de alteração de dados.

Contexto

O DMS inclui regras padrão de revisão SQL, como A table must have comments, An INSERT statement cannot insert a null value into a NOT NULL column e Field names cannot be duplicated in an INSERT statement.

Para uma visão geral das verificações de conformidade SQL e sugestões de otimização disponíveis, consulte Configure SQL review optimization.

Pré-requisitos

Antes de começar, crie a tabela migration_job com a seguinte instrução:

CREATE TABLE `migration_job` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'Primary key',
  `gmt_create` datetime NOT NULL COMMENT 'Creation time',
  `ref_id` bigint(20) unsigned NOT NULL COMMENT '',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Test';
Nota

Se sua instância usa o modo de controle Security Collaboration, você pode Create a security rule set e Apply a security rule set à instância de banco de dados.

Etapa 1: Configurar regras de segurança

As etapas a seguir configuram regras de otimização de revisão SQL para o modo Security Collaboration. Para os modos Flexible Management ou Stable Change, clique em SQL review optimization ao lado do modo de controle correspondente.

  1. Faça login no DMS 5.0.

  2. Posicione o ponteiro sobre o ícone 2023-01-28_15-57-17.png no canto superior esquerdo e escolha All Features > Security and disaster recovery (DBS) > Security Rules.

    Nota

    Se você usa o console do DMS no modo normal, escolha Security and disaster recovery (DBS) > Security Rules na barra de navegação superior.

  3. Localize o conjunto de regras de segurança desejado e clique em Edit na coluna Actions.

  4. No painel de navegação à esquerda da página Details, clique em SQL audit optimization recommendations.

  5. Localize a regra A table must have a primary key e clique em Edit na coluna Actions.

    Nota

    clique em no ícone image ao lado de Tag, Behavioral action ou Status para filtrar regras. Tag especifica o escopo da regra (DDL ou DML). Status pode ser ativado ou desativado.

  6. Na caixa de diálogo Rule content configuration, configure os parâmetros. Neste exemplo, defina a ação comportamental como Must Improve.

    Nota

    As regras padrão do sistema não incluem Must Improve. Para conhecer as opções disponíveis de behavioral action, consulte System behavioral actions.

  7. clique em OK.

    Nas tarefas subsequentes — como desenvolvimento de dados, alteração de dados e revisão SQL — o DMS verifique suas instruções SQL com base nas regras de segurança configuradas.

Etapa 2: Executar uma alteração de dados

  1. Faça login no DMS 5.0.

  2. Posicione o ponteiro sobre o ícone 2023-01-28_15-57-17.png no canto superior esquerdo do console do DMS e escolha All Features > Database Development > Data Change > Normal Data Modify.

    Nota

    Se você usa o console do DMS no modo normal, escolha Database Development > Data Change > Normal Data Modify na barra de navegação superior.

  3. Na página Data Change Ticket Application, configure os parâmetros e clique em Submit Application.

    Nota

    Para descrição dos parâmetros, consulte Normal Data Modify.

    • selecione a instância de banco de dados associada ao conjunto de regras de segurança desejado.

    • O código SQL para a alteração de dados é o seguinte:

      CREATE TABLE test1 ( 
          id bigint COMMENT 'id', 
          name varchar(60) COMMENT 'name'
      ) DEFAULT CHARSET = utf8mb4 COLLATE utf8mb4_bin ENGINE = INNODB;
      
      INSERT INTO migration_job(id, ref_id, gmt_create, gmt_create) 
      VALUES(1, null, now(), now());
  4. Após o envie do ticket, o sistema verifique as instruções SQL com base nas regras de segurança configuradas na Etapa 1.

    A auditoria identifica um item Must Improve, dois problemas potenciais e um item Suggested Improvement.

  5. clique em View Details. Passe o ponteiro sobre os itens de erro da revisão SQL para visualize as sugestões específicas.

  6. Com base nas sugestões, clique em Modify SQL, otimize o SQL e clique em Confirm Change.

    As modificações são as seguintes:

    • Na instrução CREATE, adicione uma chave primária e um comentário à tabela test1.

    • Na instrução INSERT, remova o campo duplicado gmt_create e insira um valor para o campo ref_id.

    O código SQL modifique é o seguinte:

    CREATE TABLE test1 (
        id bigint PRIMARY KEY COMMENT 'id',
        name varchar(60) COMMENT  'name'
    ) DEFAULT  CHARSET = utf8mb4 COLLATE  utf8mb4_bin ENGINE = INNODB  COMMENT  = 'Comment';
    INSERT INTO migration_job(id, ref_id, gmt_create) VALUES(1, 2, now());
  7. O sistema executa a pré-verificação novamente.

  8. clique em Submit for Approval e aguarde a aprovação de um administrador.

    Após a aprovação, o sistema gera uma tarefa de execução.

  9. Após a aprovação do ticket, clique em Execute Change. Na caixa de diálogo Task Settings, configure os parâmetros de execução e clique em Confirm and Execute.

    Nota
    • Ao crie um ticket, se o Execution Method estiver definido como Automatically execute after approval, o sistema pula automaticamente esta etapa.

    • Se uma tarefa pausada for reiniciada, a execução retoma a partir do ponto em que foi pausada.

    Parâmetro

    Descrição

    Execution strategy

    Opções de estratégia de execução:

    • Execute Immediately: inicia a tarefa ao clicar em Confirm and Execute.

    • Scheduled Execution: executa a tarefa em um horário futuro especificado.

    Enable global transaction

    defina se todas as instruções devem ser encapsuladas em uma transação global. Desativado por padrão.

    • Ativado: todas as alterações sofrem rollback em caso de falha. Aplica-se apenas a instruções DML, não a DDL.

    • Desativado: as instruções são executadas sequencialmente. Em caso de falha, a tarefa é interrompida, mas as alterações anteriores não sofrem rollback.

    Enable backup

    defina se o sistema deve fazer backup das linhas afetadas antes da execução. Ativado por padrão. Permite restauração rápida dos dados a partir do backup.

    Nota

    • O backup é compatível apenas com instruções UPDATE e DELETE.

    • O backup não é compatível com MongoDB e Redis.

    • Ativado: antes de executar instruções UPDATE ou DELETE, o sistema gera um script de backup.

      • Para bancos de dados MySQL e MariaDB, o sistema gera uma instrução de backup REPLACE INTO.

        Nota

        Os bancos de dados MySQL incluem RDS for MySQL, PolarDB for MySQL, PolarDB-X e outras fontes compatíveis com MySQL.

      • Para mecanismos de banco de dados diferentes de MySQL e MariaDB, o sistema gera uma instrução de backup INSERT.

    • Desativado: nenhum script de backup é gerado.

    Nota

    O módulo SQL execution control em security rules monitora a execução de tarefas SQL, incluindo políticas de timeout de bloqueio do banco de dados, carga do banco de dados e sleep pós-execução. Para alterar os padrões, consulte Configure SQL execution control.

    • Após a execução bem-sucedida, clique em Details na coluna Actions para visualize o status de execução, número de execuções, linhas afetadas, scripts e logs.

    • Também é possível conectar-se ao console SQL do banco de dados para verifique as alterações de dados.

Próximas etapas

clique em Details para visualize os logs de execução, incluindo instruções executadas, duração e detalhes de agendamento.