Création de fichiers de script (SybaseToSQL)
La première étape avant de lancer l’application console SSMA consiste à créer le fichier de script et, si nécessaire, à 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, viz.., :
config : permet à l’utilisateur de définir les paramètres de configuration de l’application console.
serveurs : permet à l’utilisateur de définir les définitions de serveur source/cible. Cela peut également se trouver dans un fichier de connexion de serveur distinct.
commandes de script : permet à l’utilisateur d’exécuter des commandes de flux de travail SSMA.
Chaque section est décrite en détail ci-dessous :
Configuration des paramètres de la console Sybase
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, c’est-à-dire applicables à toutes les commandes de script. Ces éléments de configuration peuvent également être définis dans chaque commande de la section script-commande si l’utilisateur souhaite remplacer le paramètre global.
Les options configurables par l’utilisateur sont les suivantes :
Fournisseur de fenêtres de sortie : si l’attribut suppress-messages a la valeur « true », les messages spécifiques à la commande ne s’affichent pas sur la console. La description des attributs est indiquée ci-dessous :
destination : spécifie si la sortie doit être imprimée dans un fichier ou stdout. Cette valeur est false par défaut.
nom de fichier : chemin d’accès du fichier (facultatif).
suppress-messages : supprime les messages sur la console. Il s’agit de « 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...>Fournisseur de connexions de migration de données : spécifie le serveur source/cible à prendre en compte pour la migration de 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. L’utilisateur peut également spécifier le serveur (source ou cible) à l’aide des attributs source-server ou target-server.
Un seul ou l’autre attribut spécifié peut être utilisé, c’est-à-dire :
source-use-last-used="true » (par défaut) ou source-server="source_servername »
target-use-last-used="true » (valeur par défaut) ou target-server="target_servername »
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>Fenêtre contextuelle d’entrée utilisateur : cela permet de gérer les erreurs lorsque les objets sont chargés à partir de la base de données. L’utilisateur fournit les modes d’entrée et, en cas d’erreur, la console se poursuit à mesure que l’utilisateur le spécifie.
Les modes sont les suivants :
ask-user : invite l’utilisateur à continuer('oui') ou à effectuer une erreur ('non').
erreur : la console affiche une erreur et arrête l’exécution.
continue - La console poursuit l’exécution.
Le mode par défaut est une erreur.
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>Fournisseur de reconnexion : cela permet à l’utilisateur de définir les paramètres de reconnexion en cas d’échecs de connexion. Cela peut être défini pour les serveurs source et cible.
Les modes de reconnexion sont les suivants :
reconnect-to-last-used-server : si la connexion n’est pas active, elle tente de se reconnecter au dernier serveur utilisé au plus 5 fois.
generate-an-error : si la connexion n’est pas active, une erreur est générée.
Le mode par défaut est généré par erreur.
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>Fournisseur de remplacement de convertisseur : cela permet à l’utilisateur de gérer les objets déjà présents sur le métabase cible. Les actions possibles sont les suivantes :
erreur : la console affiche une erreur et arrête l’exécution.
remplacer : remplace les valeurs d’objet existantes. Cette action est effectuée par défaut.
skip : la console ignore les objets qui existent déjà sur la base de données
ask-user : invite l’utilisateur à entrer ('oui'/ 'non')
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>Fournisseur de conditions préalables ayant échoué : cela permet à l’utilisateur de gérer les conditions préalables requises pour le traitement d’une commande. Par défaut, le mode strict est « false ». S’il est défini sur « true », une exception est générée en cas de défaillance pour répondre aux conditions préalables.
Exemple :
<output-providers> <prerequisites strict-mode="<true/false>"/> </output-providers>Arrêt de l’opération : pendant l’opération intermédiaire, si l’utilisateur souhaite arrêter l’opération, la touche d’accès rapide « Ctrl+C » peut être utilisée. SSMA pour la console Sybase attend que l’opération se termine et termine l’exécution de la console.
Si l’utilisateur souhaite arrêter immédiatement l’exécution, la touche d’accès rapide « Ctrl+C » peut être enfoncée à nouveau pour l’arrêt brusque de l’application console SSMA
Fournisseur de progression : informe la progression de chaque commande de console. Elle est désactivée par défaut. Les attributs de rapport de progression sont les suivants :
arrêt
tous les 1 %
tous les 2 %
tous les 5 %
tous les 10 %
tous les 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...>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. Par défaut, le niveau de détail du journal est « erreur ».
Les options au niveau de l’enregistreur d’événements sont les suivantes :
erreur irrécupérable : seuls les messages d’erreur irrécupérables sont enregistrés.
erreur : seuls les messages d’erreur irrécupérables sont enregistrés.
avertissement : tous les niveaux, à l’exception du débogage et des messages d’informations, sont enregistrés.
informations : tous les niveaux à l’exception des messages de débogage sont enregistrés.
débogage : tous les niveaux de messages enregistrés.
Note
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...>Remplacer le mot de passe chiffré : si la valeur est « 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, l’utilisateur est invité à entrer le mot de passe.
Voici deux cas :
Si l’option de remplacement est false, l’ordre de recherche est Protégé storage-Script> File-Server Connection File-Server Connection File->> Prompt User.
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 configurable 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 au 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 la section Création des fichiers de connexion de serveur (SybaseToSQL)
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 Sybase suit la hiérarchie de : Database-Schema> ->Table.
Lorsque toutes les commandes du fichier de script sont exécutées avec succès, l’application console SSMA se ferme et retourne le contrôle à l’utilisateur. 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 :
<!--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>
Les modèles composés de 3 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 l’exécution de la console SSMA (SybaseToSQL)
Validation du fichier de script
L’utilisateur peut facilement valider son fichier de script par rapport au fichier de définition de schéma « S2SSConsoleScriptSchema.xsd » disponible dans le dossier « Schemas »
Étape suivante
L’étape suivante dans l’exploitation de la console consiste à créer des fichiers de valeur variable (SybaseToSQL).
Voir aussi
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour