Creating Script Files (MySQLToSQL)
A primeira etapa antes de iniciar o aplicativo de console SSMA é criar o arquivo de script e, se necessário, criar o arquivo de valor variável e o arquivo de conexão do servidor.
O arquivo de script pode ser dividido em três seções:
config: permite que o usuário defina os parâmetros de configuração do aplicativo de console.
servers: permite que o usuário configure as definições do servidor de origem/destino. Também podem estar em um arquivo de conexão de servidor separado.
script-commands: permite que o usuário execute os comandos de fluxo de trabalho do SSMA.
Cada seção é descrita em detalhes abaixo:
Como configurar as definições do console MySQL
As configurações de um script são exibidas no arquivo de script do console.
Se algum dos elementos for especificado no nó de configuração, ele será definido como a configuração global, ou seja, será aplicável a todos os comandos de script. Esses elementos de configuração também podem ser definidos dentro de cada comando na seção script-command, caso o usuário deseje substituir a configuração global.
As opções configuráveis pelo usuário incluem:
Provedor da janela de saída: se o atributo suppress-messages for definido como “true”, as mensagens de comando específicas não serão exibidas no console. A descrição de Atributos é fornecida abaixo:
destination: especifica se a saída precisa ser impressa em um arquivo ou em um stdout. Esse valor é false por padrão.
file-name: o caminho do arquivo (opcional).
suppress-messages: suprime mensagens no console. Esse valor é “false” por padrão.
Exemplo:
<output-providers> <output-window suppress-messages="<true/false>" (optional) destination="<file/stdout>" (optional) file-name="<file-name>" (optional) /> </output-providers>or
<...All commands...> <output-window suppress-messages="<true/false>" (optional) destination="<file/stdout>" (optional) file-name="<file-name>" (optional) /> </...All commands...>Provedor de conexão de migração de dados: especifica qual servidor de origem/destino deve ser considerado para a migração de dados. Source-use-last-used indica que o último servidor de origem usado será empregado na migração de dados. Da mesma forma, target-use-last-used indica que o último servidor de destino usado será empregado na migração de dados. O usuário também pode especificar o servidor (origem ou destino) usando os atributos source-server ou target-server.
Somente um ou outro atributo especificado pode ser usado, ou seja:
source-use-last-used="true" (padrão) ou source-server="source_servername"
target-use-last-used="true" (padrão) ou target-server="target_servername"
Exemplo:
<output-providers> <data-migration-connection source-use-last-used="true" target-server="<target-server-unique-name>"/> </output-providers>or
<migrate-data> <data-migration-connection source-server="<source-server-unique-name>" target-use-last-used="true"/> </migrate-data>Pop-up de entrada do usuário: permite o tratamento de erros quando os objetos são carregados do banco de dados. O usuário fornece os modos de entrada e, em caso de erro, o console prossegue conforme especificado pelo usuário.
Os modos incluem:
ask-user - solicita ao usuário para continuar(“yes”) ou exibir o erro(“no").
error- o console exibe um erro e interrompe a execução.
continue- o console prossegue com a execução.
O modo padrão é error.
Exemplo:
<output-providers> <user-input-popup mode="<ask-user/continue/error>"/> </output-providers>or
<!-- Connect to target database --> <connect-target-database server="<target-server-unique-name>"> <user-input-popup mode="<ask-user/continue/error>"/> </connect-target-database>Provedor de reconexão: permite que o usuário defina as configurações de reconexão em caso de falhas de conexão. Pode ser definido para servidores de origem e de destino.
Os modos de reconexão são:
reconnect-to-last-used-server: se a conexão não estiver ativa, ela tentará se reconectar, no máximo 5 vezes, ao último servidor usado.
generate-an-error: se a conexão não estiver ativa, será gerado um erro.
O modo padrão é generate-an-error.
Exemplo:
<output-providers> <reconnect-manager on-source-reconnect="<reconnect-to-last-used-server/generate-an-error>" on-target-reconnect="<reconnect-to-last-used-server/generate-an-error>"/> </output-providers>or
<!--synchronization--> <synchronize-target> <reconnect-manager on-target-reconnect="reconnect-to-last-used-server"/> </synchronize-target>or
<!--data migration--> <migrate-data server="target-server-unique-name"> <reconnect-manager on-source-reconnect="reconnect-to-last-used-server" on-target-reconnect="generate-an-error"/> </migrate-data>Provedor de substituição do conversor: permite que o usuário lide com objetos que já estão presentes na metabase de destino. As ações possíveis incluem:
error: o console exibe um erro e interrompe a execução.
overwrite: substitui os valores de objetos existentes. Esta é a ação padrão.
skip: o console ignora os objetos que já existem no banco de dados
ask-user: solicita a entrada ao usuário (“yes”/ “no”)
Exemplo:
<output-providers> <object-overwrite action="<error/skip/overwrite/ask-user>"/> </output-providers>or
<convert-schema object-name="<object-name>"> <object-overwrite action="<error/skip/overwrite/ask-user>"/> </convert-schema>Provedor de pré-requisitos com falha: permite que o usuário manipule quaisquer pré-requisitos necessários para processar um comando. Por padrão, o modo estrito é “false” Se ele for configurado como “true”, será gerada uma exceção por falha em atender aos pré-requisitos.
Exemplo:
<output-providers> <prerequisites strict-mode="<true/false>"/> </output-providers>Parar operação: se o usuário quiser parar a operação no meio, a tecla de atalho““Ctrl+C" pode ser usada. O SSMA para o console do MySQL aguardará a conclusão da operação e encerrará a execução do console.
Se o usuário desejar interromper a execução imediatamente, poderá pressionar novamente a tecla de atalho“Ctrl+C” para o encerramento abrupto do aplicativo de console do SSMA
Provedor de progresso: informa o andamento de cada comando do console. Isso está desabilitado por padrão. Os atributos do relatório de progresso incluem:
off
a cada 1%
a cada 2%
a cada 5%
a cada 10%
a cada 20%
Exemplo:
<output-providers> <progress-reporting enable="<true/false>" (optional) report-messages="<true/false>" (optional) report-progress="<every-1%/every-2%/every-5%/every-10%/every-20%/off>" (optional)/> </output-providers>or
<...All commands...> <progress-reporting enable="<true/false>" (optional) report-messages="<true/false>" (optional) report-progress="<every-1%/every-2%/every-5%/every-10%/every-20%/off>" (optional)/> </...All commands...>Detalhamento do agente: define o nível de detalhamento do registro em log. Ele corresponde à opção Todas as Categorias na interface do usuário. Por padrão, o nível de detalhamento do log é "error".
As opções de nível de agente incluem:
fatal-error: somente mensagens de erro fatal são registradas.
error: somente mensagens de erro e de erro fatal são registradas.
warning: todos os níveis, exceto as mensagens de depuração e informações, são registrados.
info: todos os níveis, exceto as mensagens de depuração, são registrados.
debug: todos os níveis de mensagens são registrados.
Observação
As mensagens obrigatórias são registradas em qualquer nível.
Exemplo:
<output-providers> <log-verbosity level="<fatal-error/error/warning/info/debug>"/> </output-providers>or
<...All commands...> <log-verbosity level="<fatal-error/error/warning/info/debug>"/> </...All commands...>Substituir senha criptografada: quando for marcado como “true”, a senha com texto não criptografado especificada na seção de definição do servidor do arquivo de conexão do servidor ou no arquivo de script substituirá a senha criptografada armazenada no armazenamento protegido, caso ele exista. Se não for especificada nenhuma senha em texto não criptografado, será solicitado que o usuário insira a senha.
Aqui, existem dois casos:
Se a opção de substituição for false, a ordem da pesquisa será Protected storage->Script File->Server Connection File-> Prompt User.
Se a opção de substituição for true, a ordem de pesquisa será Script File->Server Connection File->Prompt User.
Exemplo:
<output-providers> <encrypted-password override="<true/false>"/> </output-providers>
A opção não configurável é:
- Máximo de tentativas de reconexão: quando um tempo de conexão estabelecido atingir o tempo limite ou for interrompido devido a uma falha de rede, o servidor precisará ser reconectado. As tentativas de reconexão são permitidas até um máximo de 5 vezes. Depois disso, o console executará automaticamente a reconexão. A facilidade de reconexão automática reduz o esforço em executar novamente o script.
Parâmetros de conexão do servidor
Os parâmetros de conexão do servidor podem ser configurados no arquivo de script ou no arquivo de conexão do servidor. Consulte a seção Criar arquivos de conexão do servidor (MySQLToSQL) para obter mais detalhes.
Comandos de script
O arquivo de script contém uma sequência de comandos para o fluxo de trabalho de migração no formato XML. O aplicativo de console do SSMA processa a migração na ordem dos comandos que aparecem no arquivo de script.
Por exemplo, uma típica migração de dados de uma tabela específica em um banco de dados do MySQL segue a hierarquia de: Banco de dados -> Tabela.
Quando todos os comandos no arquivo de script forem executados com êxito, o aplicativo de console do SSMA sairá e devolverá o controle para o usuário. O conteúdo de um arquivo de script é mais ou menos estático com informações de variáveis contidas em Arquivos de Valor de Variável ou em uma seção separada dentro do arquivo de script para valores de variáveis.
Exemplo:
<!--Sample of script file commands -->
<ssma-script-file>
<script-commands>
<create-new-project project-folder="<project-folder>"
project-name="<project-name>"
overwrite-if-exists="<true/false>"/>
<connect-source-database server="<source-server-unique-name>"/>
<save-project/>
<close-project/>
</script-commands>
</ssma-script-file>
Os modelos que consistem em 3 arquivos de script (para executar vários cenários), arquivo de valor variável e um arquivo de conexão de servidor são fornecidos na pasta Exemplos de Scripts de Console do diretório do produto:
AssessmentReportGenerationSample.xml
ConversionAndDataMigrationSample.xml
SqlStatementConversionSample.xml
VariableValueFileSample.xml
ServersConnectionFileSample.xml
Você pode executar os modelos (arquivos) depois de alterar os parâmetros exibidos neles conforme a relevância.
A lista completa de comandos de script pode ser encontrada em Executar o console do SSMA (MySQLToSQL)
Validação de arquivo de script
O usuário pode validar facilmente seu arquivo de script em relação ao arquivo de definição de esquema 'M2SSConsoleScriptSchema.xsd'disponível na pasta “Esquemas”.
Próxima etapa
A próxima etapa na operação do console é Criar arquivos de valor variável (MySQLToSQL).