stagingcopy, utilitaire

L'utilitaire stagingcopy effectue la copie des données de la base de données de production vers les données prêtes pour la production sur un environnement de transfert ou d'exécution.

Important :
  • Votre environnement de transfert et de production doit être au même niveau de maintenance pour exécuter avec succès l'utilitaire stagingprop.
  • Si le site utilise l'utilitaire de flux Web, exportez le contenu de la table CMFEEDLOG, puis importez le contenu après l'exécution de l'utilitaire stagingcopy.
    • DB2
      export to /backupdata/cmfbackup.del of del select * from cmfeedlog
      import from /backupdata/cmfbackup.del of del insert into cmfeedlog
      
      Pour plus d'informations, voir EXPORT command et IMPORT command.
    • Oracle
      exp userid/password FILE=cmfeedlog.dmp TABLES=cmfeedlog
      imp userid/password FILE=cmfeedlog.dmp FROMUSER=userid TABLES=cmfeedlog  IGNORE=Y
      Pour en savoir davantage, reportez-vous à la documentation Oracle.
  • OracleSi la journalisation des archives est activée, l'exécution de l'utilitaire stagingcopy peut entraîner une augmentation non linéaire de la quantité d'espace disque utilisée par la base de données de destination. La quantité d'espace disque qui est utilisée par les journaux d'archivage peut atteindre 4 à 8 fois la taille finale de la base de données de destination. Vérifiez que vous pouvez contrôler la taille du système de fichiers pour éviter de manquer d'espace disque pour la base de données de destination.
stagingcopy diagramme de syntaxe de l'utilitaire.

Valeurs des paramètres

dbtype
Facultatif.
  • DB2Spécifiez DB2. DB2 est le type de base de données par défaut et vous pouvez omettre le paramètre -dbtype de la commande.
  • OracleSpécifiez Oracle.
scope
Obligatoire : niveau de portée de la copie sur l'environnement de transfert ou de création. Indiquez l'un des niveaux suivants :
_all_
Copie à la fois les enregistrements associés au site et ceux associés à tous les commerçants. Les enregistrements sont copiés dans l'ordre suivant :
  1. Les enregistrements de site sont copiés à partir de STGSITETAB
  2. Les enregistrements de site sont copiés à partir de STGMRSTTAB
  3. Les enregistrements de commerçant sont copiés à partir de STGMERTAB
  4. Les enregistrements de commerçant sont copiés à partir de STGMRSTTAB
_site_
Copie uniquement les enregistrements associés au site. Ces enregistrements sont des données communes à tous les commerçants, par exemple, la langue et le code de pays ou de région utilisés par le système. Ces données proviennent de la table STGSITETAB.
_merchant_
Copie uniquement les enregistrements associés à chaque commerçant. Par exemple, les informations de magasin sont personnalisées pour chaque commerçant et les lignes des tables de magasin peuvent être spécifiques de chaque commerçant. Vous devez copier toutes les données pour tous les commerçants et non pas uniquement les données pour un commerçant spécifique. Ces données proviennent de la table STGMERTAB.

Si vous ne définissez pas la portée par _all_ :

  • Copiez les données de site avant les données de commerçant, car les données de site sont utilisées par tous les commerçants. Dans le cas contraire, la copie échoue en raison d'un conflit entre les clés externes et primaires.
  • Lorsque vous utilisez le paramètre cleanup_stage_db pour nettoyer les données de site, les données de commerçant peuvent être supprimées en raison de la suppression en cascade. Nettoyez les données de commerçant avant les données de site, puis copiez les données de site avant les données de commerçant.
Remarque :
  • Ces tables sont référencées uniquement à partir de l'environnement de transfert ou de création, mais pas de l'environnement de production.
  • Les données de table MEMBER ne sont pas nettoyées pour les membres utilisateur : Enregistrements de table MEMBER avec la valeur de colonne TYPE pour "U". Toutefois, si des contraintes de clé externe CASCADE DELETE sont présentes, le nettoyage des membres non-utilisateurs peut entraîner la perte de données dans les tables qui conservent des relations avec des utilisateurs membres. Par exemple, MBRREL, MBRGRPMBR et MBRROLE. Si les informations contenues dans ces tables de relations doivent être conservées, vérifiez qu'une sauvegarde de la base de données de destination (de transfert ou de création) existe.
dbtable
Nom de table spécifique à copier. Tous les enregistrements de cette table sont copiés, à condition qu'ils entrent dans le niveau de portée indiqué par le paramètre scope. Sinon, aucun enregistrement n'est copié.
sourcedb
Obligatoire : nom de la base de données dans l'environnement de production.
s doit être une URL JDBC valide et complète ou suivre la convention de nom de base de données Type 4 :
  • DB2db_server:db_port/db_name.

Si vous utilisez script_file, pensez à définir script_sourcedb également.

sourcedb_user
Obligatoire : ID de connexion de l'administrateur de la base de données qui a créé le schéma de la base de données source.
sourcedb_passwd
Obligatoire : Mot de passe associé à l'ID de connexion indiqué par le paramètre sourcedb_user.
sourcedb_schema
Facultatif : spécifie le schéma sur la base de données source où toutes les opérations d'entreprise sont conduites. Spécifiquement, ce schéma doit avoir tous les objets de base de données requis par une instance HCL Commerce active. Lorsque ce paramètre n'est pas spécifié, sa valeur par défaut est le schéma actif dans la base de données source lorsqu'une connexion est établie.
destdb
Obligatoire : nom de la base de données dans l'environnement de transfert.
s doit être une URL JDBC valide et complète ou suivre la convention de nom de base de données Type 4 :
  • DB2db_server:db_port/db_name.

Si vous utilisez script_file, pensez à définir script_destdb également.

destdb_user
Obligatoire : ID de connexion de l'administrateur de la base de données qui a créé le schéma de la base de données de transfert ou d'exécution. Ce paramètre est obligatoire en cas d'utilisation d'une base de données distante.
destdb_passwd
Obligatoire : mot de passe associé à l'ID de connexion indiqué par le paramètre destdb_user. Si vous n'indiquez rien, le système vous invite à saisir le mot de passe. Ce paramètre est obligatoire en cas d'utilisation d'une base de données distante.
destdb_schema
Facultatif : spécifie le schéma sur la base de données cible où toutes les opérations d'entreprise sont conduites. Spécifiquement, ce schéma doit avoir tous les objets de base de données requis par une instance HCL Commerce active. Lorsque ce paramètre n'est pas spécifié, cette valeur par défaut est le schéma actif dans la base de données de destination lorsqu'une connexion est établie.
script_file
Facultatif. Nom du fichier de script SQL généré par l'utilitaire stagingcopy lors de l'utilisation des fonctions d'exportation et d'importation pour copier la base de données de production vers les données prêtes pour la production sur la portée spécifiée. Ce fichier script génère également les instructions de suppression qui vont nettoyer la base de données production_ready si vous utilisez la valeur par défaut ou que vous spécifiez -cleanup_stage_db _yes.
Il existe plusieurs conditions préalables supplémentaires pour l'utilisation du paramètre script_file :
  • Avant d'exécuter le script, vérifiez que vous disposez de suffisamment d'espace disque pour contenir les tables exportées. Ce fichier script est situé dans le répertoire de l'utilitaire stagingcopy à partir duquel vous lancez l'utilitaire stagingcopy.
  • Avant d'exécuter le script, copiez les fichiers suivants sur votre serveur de base de données :
    • stage_copy.sql
    • utilities_root/schema/9.0.0.0/dbtype/wcs.stage.trigger.sql
    • utilities_root/schema/9.0.0.0/dbtype/wcs.droptrigger.sql
    dbtype est db2 ou oracle.
  • Configurez les options script_sourcedb et script_destdb avec script_file.
DB2De même, avant d'exécuter le script, vous devez définir la page de codes correcte pour votre session de ligne de commande DB2. Sinon, vous pouvez perdre des données pendant la conversion de caractères. Dans la mesure où la base de données HCL Commerce utilise le caractère Unicode, la session client DB2 doit également être définie à l'aide d'une page de codes Unicode. Pour cela, définissez la variable d'environnement DB2CODEPAGE du système d'exploitation.
Remarque : Vous devez terminer la session en cours et démarrer une nouvelle session de ligne de commande pour que la nouvelle variable d'environnement soit prise en compte.
Par exemple,

export DB2CODEPAGE=1208
db2 terminate 
Lancez les commandes suivantes pour exécuter le fichier de script : db2 -vtd# -f wcs.droptrigger.sql db2 -vtd# -f script_file_namedb2 -vtd# -f wcs.stage.trigger.sql

OracleLancez la commande suivante pour exécuter le fichier de script : sqlplus /nolog @wcs.droptrigger.sql sqlplus /nolog @script_file_namesqlplus /nolog @wcs.stage.trigger.sql

script_sourcedb
Facultatif. Spécifications de base de données à utiliser pour la base de données source lorsque les commandes et instructions de base de données sont générées vers un fichier spécifié par le paramètre script_file.

La valeur par défaut est celle de sourcedb. Si script_file n'est pas indiqué, script_sourcedb et sa valeur sont ignorés.

Vous pouvez définir cette option si la valeur de sourcedb n'est pas d'un type pouvant être compris par un interpréteur de fichier ou de ligne de commande de la base de données sous-jacente. Par exemple, utilisez le paramètre sourcedb pour indiquer l'adresse URL JDBC complète. Utilisez le paramètre script_sourcedb pour utiliser un identificateur ou un alias de base de données source catalogué localement dans le fichier généré par script_file.

script_destdb
Facultatif. Spécifications de base de données à utiliser pour la base de données cible lorsque les commandes et instructions de base de données sont générées vers un fichier spécifié par le paramètre script_file.

La valeur par défaut est celle de destdb. Si script_file n'est pas indiqué, script_destdb et sa valeur sont ignorés.

Vous pouvez définir cette option si la valeur de destdb n'est pas d'un type pouvant être compris par un interpréteur de fichier ou de ligne de commande de la base de données sous-jacente. Par exemple, utilisez le paramètre destdb pour indiquer l'adresse URL JDBC complète. Utilisez le paramètre script_destdb pour utiliser un identificateur ou un alias de base de données de destination catalogué localement dans le fichier généré par script_file.

script_prtsourcepswd
Facultatif. Indique si le mot de passe de l'utilisateur de la base de données source doit être inscrit avec les instructions de connexion à la base de données dans le fichier généré par script_file.
La valeur par défaut est false. Si script_file n'est pas indiqué, script_prtsourcepswd et sa valeur sont ignorés.
script_prtdestpswd
Facultatif. Indique si le mot de passe de l'utilisateur de la base de données destination doit être inscrit avec les instructions de connexion à la base de données dans le fichier généré par script_file.
La valeur par défaut est false. Si script_file n'est pas indiqué, script_prtdestpswd et sa valeur sont ignorés.
instance
Facultatif : nom de l'instance locale pour la machine sur laquelle vous souhaitez exécuter l'utilitaire stagingcopy.
cleanup_stage_db
Facultatif. Indiquez s'il convient de nettoyer les tables de transfert avant de copier les données. Si vous ne spécifiez pas ce paramètre, les tables de transfert sont automatiquement nettoyées avant la copie des données. Indiquez l'une des valeurs suivantes :
oui
Nettoyez les tables de transfert avant la copie des données. Les données de commerçant peuvent être supprimées du fait de la suppression en cascade.
non
Ne nettoyez pas les tables de transfert avant la copie des données. Rien n'est supprimé des tables de transfert. Il peut arriver que la copie échoue si les données copiées génèrent des conflits ou des clés multiples sur des index à entrées uniques ou à clé primaire.
uniquement
Nettoie les tables de transfert mais aucune donnée provenant de la base de données de production n'est copiée.

Si vous spécifiez le paramètre scope, vous devez effacer et copier les données des commerçants après avoir effacé et copié les données de site.

batchsize
Facultatif. Active et désactive les mises à jour SQL par lots et spécifie le nombre d'enregistrements de journaux des modifications consolidés à inclure dans une instruction SQL par lots.

Si vous ne spécifiez pas ce paramètre, le paramètre batchsize défini par la valeur 100.

La définition du paramètre -batchsize par une valeur 0 (zéro) désactive la mise à jour SQL par lots.

Désactivez le traitement SQL par lots si vous publiez l'une des modifications suivantes à partir des données prêtes pour la production vers l'environnement de production :
  • Utilisation d'un espace de travail pour supprimer un objet HCL Commerce affectant la table MEMBER. Cette table comprend des objets comme utilisateurs, organisations, segments de clientèle, groupes de membres, groupes de territoires de clientèle ou groupes de prix client.

Quand une mise à jour SQL par lots est activée, les enregistrements des journaux des modifications sont triés par type de modification (insertion, mise à jour ou suppression). Chaque lot contient des modifications d'un seul type. Par exemple, s'il y a 102 modifications de type insertion et que le paramètre batchsize est défini par la valeur 100, deux lots SQL seront créés : un lot comportant 100 opérations d'insertion et un autre en comportant deux.

L'utilisation des mises à jour SQL par lots permet d'accélérer la mise à jour de la base de données de production par l'utilitaire stagingcopy.

log
Facultatif. Chemin d'accès et nom du fichier dans lequel l'utilitaire stagingcopy enregistre ses activités et ses erreurs. L'horodatage est ajouté au nom de fichier (par exemple, myLog_yyyy.mm.dd_hh.mm.ss.zzz.log). Si ce paramètre n'est pas indiqué, le fichier journal stagingcopy_yyyy.mm.dd_hh.mm.ss.zzz.log est créé dans le répertoire suivant utilities_root/logs.
transaction
Facultatif. Indique le nombre d'enregistrements avant l'émission d'une validation. Ce nombre s'applique aux enregistrements modifiés au cours des étapes de nettoyage et de copie par StagingCopy.
Remarque : Utilisé avec script_file, le paramètre transaction nécessite l'appel d'une instruction SQL pour estimer le nombre d'instructions DELETE à envoyer vers le fichier généré. Par exemple :
select count(*) num_recs from <tablename> [<scope-filtering-predicate>]
Le nombre d'instructions DELETE générées est 1+(num_recs/n). Une validation est ajoutée après chaque instruction DELETE.

Par défaut, pour chaque table, une validation est émise une fois après le nettoyage et une fois après la copie. Les valeurs de n inférieures ou égales à 0 rétablissent le comportement par défaut de la fonctionnalité.

paramfile
Facultatif. Indique le chemin d'accès au fichier de paramètres qui comprend les arguments et les valeurs de ligne de commande. Chaque argument et chaque valeur doit être au format argument=value avec un seul argument et une seule valeur sur chaque ligne de ce fichier. Tous les mots de passe dans ce fichier de paramètres doivent être chiffrés.