Partager via

Créer des fichiers de script (Db2ToSQL)

  • Article

Avant de pouvoir lancer l’application console Assistant Migration SQL Server (SSMA), vous devez créer le fichier de script. Si nécessaire, vous pouvez également créer le fichier de valeur de variable et le fichier de connexion du serveur.

Le fichier de script peut être divisé en trois sections :

Section Description
config Définissez les paramètres de configuration de l’application console.
servers Définissez les définitions de serveur source/cible. Peut également se trouver dans un fichier de connexion de serveur distinct.
script-commands Exécutez des commandes de flux de travail SSMA.

Chaque section est décrite en détail dans cet article.

Configurer les paramètres de l’application console SSMA

Les configurations d’un script s’affichent dans le fichier de script de console.

Si l’un des éléments est spécifié dans le nœud de configuration, ils sont définis comme paramètre global. En d’autres termes, ils s’appliquent à toutes les commandes de script. Ces éléments de configuration peuvent également être définis dans chaque commande de la section script-commande si vous souhaitez remplacer le paramètre global.

Les options configurables par l’utilisateur sont les suivantes :

  1. Fournisseur de fenêtre de sortie : si suppress-messages l’attribut est défini truesur , les messages spécifiques à la commande ne sont pas affichés sur la console.

    Attribut Description
    destination Spécifie si la sortie doit être imprimée dans un fichier ou un stdout. false par défaut.
    file-name (facultatif) Chemin d’accès au fichier.
    suppress-messages Supprime les messages sur la console. false par défaut.

    Exemple :

    <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. Fournisseur de connexions de migration de données : spécifie le serveur source/cible à prendre en compte pour la migration des données. L’utilisation source-last-used indique que le dernier serveur source utilisé est utilisé pour la migration de données. De même, target-use-last-used indique que le dernier serveur cible utilisé est utilisé pour la migration de données. Vous pouvez également spécifier le serveur (source ou cible) à l’aide des attributs source-server ou target-server.

    Un seul de ces attributs peut être défini à la fois :

    • source-use-last-used="true" (par défaut) ou source-server="<source-server-unique-name>"
    • target-use-last-used="true" (par défaut) ou target-server="<target-server-unique-name>"

    Exemple :

    <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. Fenêtre contextuelle d’entrée utilisateur : autorise la gestion des erreurs lorsque les objets sont chargés à partir de la base de données. Vous fournissez les modes d’entrée et, s’il existe une erreur, la console se poursuit comme spécifié.

    Mode Description
    ask-user Vous invite à continuer (yes) ou à effectuer une erreur (no).
    error (valeur par défaut) La console affiche une erreur et arrête l’exécution.
    continue La console poursuit l’exécution.

    Exemple :

    <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. Fournisseur de reconnexion : vous permet de définir les paramètres de reconnexion en cas d’échec de connexion. Cela peut être défini pour les serveurs source et cible.

    Mode de reconnexion Description
    reconnect-to-last-used-server Si la connexion n’est pas active, elle tente de se reconnecter au dernier serveur utilisé cinq fois au maximum.
    generate-an-error (valeur par défaut) Si la connexion n’est pas active, une erreur est générée.

    Exemple :

    <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. Fournisseur de remplacement de convertisseur : vous permet de gérer les objets déjà présents sur le métabase cible.

    Action Description
    error La console affiche une erreur et arrête l’exécution.
    overwrite (valeur par défaut) Remplace les valeurs d’objet existantes.
    skip La console ignore les objets qui existent déjà sur la base de données.
    ask-user Vous invite à entrer (yes / no).

    Exemple :

    <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. Fournisseur de conditions préalables ayant échoué : vous pouvez gérer les conditions préalables requises pour le traitement d’une commande. Par défaut, strict-mode est false. Si true, une exception est générée en cas de défaillance de la configuration requise.

    Exemple :

    <output-providers>
  <prerequisites strict-mode="<true/false>"/>
</output-providers>

  7. Arrêt de l’opération : pendant l’opération intermédiaire, si vous souhaitez arrêter l’opération, la touche de raccourci Ctrl+C peut être utilisée. L’application console SSMA pour SSMA attend que l’opération se termine et termine l’exécution de la console.

    Si vous souhaitez arrêter l’exécution immédiatement, la touche de raccourci Ctrl+C peut être enfoncée à nouveau pour l’arrêt de l’application console SSMA.

  8. Fournisseur de progression : informe la progression de chaque commande de console. Désactivé par défaut. Les attributs de rapport de progression sont les suivants :

    • off
    • every-1%
    • every-2%
    • every-5%
    • every-10%
    • every-20%

    Exemple :

    <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. Verbosity de l’enregistreur d’événements : définit le niveau de détail du journal. Cela correspond à l’option Toutes les catégories dans l’interface utilisateur.

    Niveau de l’enregistreur d’événements Description
    fatal-error Seuls les messages d’erreur irrécupérables sont enregistrés.
    error (valeur par défaut) Seules les messages d’erreur irrécupérable et d’erreur irrécupérable sont enregistrés.
    warning Tous les niveaux, à l’exception du débogage et des messages d’informations, sont enregistrés.
    info Tous les niveaux à l’exception des messages de débogage sont enregistrés.
    debug Tous les niveaux de messages enregistrés.

    Les messages obligatoires sont enregistrés à n’importe quel niveau.

    Exemple :

    <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. Remplacer le mot de passe chiffré : si true, le mot de passe de texte clair spécifié dans la section définition du serveur du fichier de connexion du serveur ou dans le fichier de script remplace le mot de passe chiffré stocké dans le stockage protégé s’il existe. Si aucun mot de passe n’est spécifié en texte clair, vous êtes invité à entrer le mot de passe.

    Ici, deux cas se produisent :

    1. Si l’option de remplacement est false, l’ordre de recherche est l’utilisateur d’invite de fichiers de connexion > du serveur de fichiers de serveur de fichiers de stockage > > protégé.

    2. Si l’option de remplacement a la valeur true, l’ordre de recherche est l’utilisateur d’invite de fichiers de connexion > du serveur de fichiers de script>.

    Exemple :

    <output-providers>
  <encrypted-password override="<true/false>"/>
</output-providers>

L’option non configurée est la suivante :

  • Tentatives de reconnexion maximale : lorsqu’une connexion établie expire ou s’arrête en raison d’une défaillance réseau, le serveur doit être reconnecté. Les tentatives de reconnexion sont autorisées à un maximum de 5 nouvelles tentatives après quoi la console effectue automatiquement la reconnexion. La fonctionnalité de reconnexion automatique réduit votre effort de réexécution du script.

Paramètres de connexion du serveur

Les paramètres de connexion du serveur peuvent être définis dans le fichier de script ou dans le fichier de connexion du serveur. Pour plus d’informations, consultez Créer les fichiers de connexion du serveur.

Commandes de script

Le fichier de script contient une séquence de commandes de flux de travail de migration au format XML. L’application console SSMA traite la migration dans l’ordre des commandes apparaissant dans le fichier de script.

Par exemple, une migration de données classique d’une table spécifique dans une base de données Db2 suit la hiérarchie de la table de schéma>.

Lorsque toutes les commandes du fichier de script sont exécutées avec succès, l’application console SSMA se ferme. Le contenu d’un fichier de script est plus ou moins statique avec des informations de variable contenues dans un fichier de valeurs de variable ou, dans une section distincte dans le fichier de script pour les valeurs de variable.

Exemple :

Voici un exemple des commandes de fichier de script :

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

Les modèles constitués de trois fichiers de script (pour l’exécution de différents scénarios), d’un fichier de valeur variable et d’un fichier de connexion serveur sont fournis dans le dossier Exemples de scripts de console du répertoire de produit :

  • AssessmentReportGenerationSample.xml
  • ConversionAndDataMigrationSample.xml
  • SqlStatementConversionSample.xml
  • VariableValueFileSample.xml
  • ServersConnectionFileSample.xml

Vous pouvez exécuter les modèles (fichiers) après avoir modifié les paramètres qui y sont affichés pour la pertinence.

Vous trouverez la liste complète des commandes de script dans Exécuter la console SSMA

Validation du fichier de script

Vous pouvez valider le fichier de script par rapport au fichier O2SSConsoleScriptSchema.xsdde définition de schéma, disponible dans le Schemas dossier.

Contenu connexe