Criar arquivos de script (SybaseToSQL)

  • Artigo

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, ou seja:

  1. config: permite que o usuário defina os parâmetros de configuração do aplicativo de console.

  2. servers: permite que o usuário defina as definições do servidor de origem/destino. Ele também pode estar em um arquivo de conexão de servidor separado.

  3. script-commands: permite que o usuário execute os comandos de fluxo de trabalho do SSMA.

Cada seção é descrita em detalhes a seguir:

Configurar as configurações do console Sybase

As configurações de um script são exibidas no arquivo de script do console.

Se qualquer um dos elementos for especificado no nó de configuração, eles serão definidos como a configuração global, ou seja, serão aplicáveis 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 se o usuário quiser substituir a configuração global.

As opções configuráveis pelo usuário incluem:

  1. Provedor da janela de saída: se o atributo suppress-messages estiver definido como 'true', as mensagens específicas do comando não serão exibidas no console. A descrição dos atributos é fornecida abaixo:

    • destination: especifica se a saída precisa ser impressa em um arquivo ou em um stdout. Esse valor é falso por padrão.

    • file-name: o caminho do arquivo (opcional).

    • suppress-messages: suprime mensagens no console. Esse valor é falso por padrão.

    Exemplo:

    <output-providers>  

  <output-window  

    suppress-messages="<true/false>"   (optional)  

    destination="<file/stdout>"        (optional)  

    file-name="<file-name>"            (optional)  

   />  

</output-providers>

    ou

    <...All commands...>  

  <output-window  

     suppress-messages="<true/false>"   (optional)  

     destination="<file/stdout>"        (optional)  

     file-name="<file-name>"            (optional)  

   />  

</...All commands...>

  2. 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.

    Apenas um dos atributos especificados 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>

    ou

    <migrate-data>  

  <data-migration-connection   source-server="<source-server-unique-name>"  

                               target-use-last-used="true"/>  

</migrate-data>

  3. 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>

    ou

    <!-- Connect to target database -->  

<connect-target-database server="<target-server-unique-name>">  

  <user-input-popup mode="<ask-user/continue/error>"/>  

</connect-target-database>

  4. 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 ao último servidor usado no máximo 5 vezes.

    • generate-an-error: se a conexão não estiver ativa, um erro será gerado.

    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>

    ou

    <!--synchronization-->  

<synchronize-target>  

  <reconnect-manager on-target-reconnect="reconnect-to-last-used-server"/>  

</synchronize-target>

    ou

    <!--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>

  5. Provedor de substituição do conversor: permite que o usuário manipule 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. Essa ação é executada por padrão.

    • skip: o console ignora os objetos que já existem no banco de dados

    • ask-user: solicita ao usuário a entrada ('yes'/ 'no')

    Exemplo:

    <output-providers>  

  <object-overwrite action="<error/skip/overwrite/ask-user>"/>  

</output-providers>

    ou

    <convert-schema object-name="<object-name>">  

  <object-overwrite action="<error/skip/overwrite/ask-user>"/>  

</convert-schema>

  6. 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>

  7. Parar operação: no meio da operação, se o usuário quiser interrompê-la, a tecla de atalho 'Ctrl+C' poderá ser usada. O SSMA para o console Sysbase 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

  8. 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

    • every-1%

    • every-2%

    • every-5%

    • every-10%

    • every-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>

    ou

    <...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...>

  9. 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 registro 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.

    Nota

    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>

    ou

    <...All commands...>  

  <log-verbosity level="fatal-error/error/warning/info/debug"/>  

</...All commands...>

  10. Substituir senha criptografada: se for 'true', a senha de 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 salva no armazenamento protegido, se existir. Se nenhuma senha for especificada em texto não criptografado, o usuário será solicitado a inserir a senha.

    Aqui, existem dois casos:

    1. Se a opção de substituição for false, a ordem da pesquisa será Protected storage->Script File->Server Connection File-> Prompt User.

    2. 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 uma conexão estabelecida atinge o tempo limite ou é interrompida devido a uma falha de rede, o servidor precisa ser reconectado. As tentativas de reconexão são permitidas até um máximo de 5 vezes. Depois disso, o console executa 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 definidos no arquivo de script ou no arquivo de conexão do servidor. Para obter mais detalhes, veja a seção Criar arquivos de conexão do servidor (SybaseToSQL)

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 Oracle segue a hierarquia de: banco de dados->esquema ->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 (SybaseToSQL)

Validação de arquivo de script

O usuário pode validar facilmente seu arquivo script em relação ao arquivo de definição de esquema S2SSConsoleScriptServersSchema.xsd disponível na pasta “Esquemas”

Próxima etapa

A próxima etapa na operação do console é Criar arquivos de valor variável (SybaseToSQL).

Confira também

Criar arquivos de valor da variável (SybaseToSQL)