Processus de migration de données pour l’archivage des données de table à partir de champs non référencés vers des champs de référence

  • Rversion finale: Xanadu
  • Mis à jour 1 août 2024
  • 2 minutes de lecture
  • Le processus de migration des données déplace les données d’une table d’archivage existante, y compris les tables descendantes et connexes. Il existe des scripts et des notes spéciaux à comprendre lors de la réalisation de ce processus.

    Tâche de migration de données (RefCopyJob)

    Pour chaque table qui passe par le processus de migration, le RefCopyJob identifie l’sys_id des champs de référence et met à jour la valeur d’affichage pour être la sys_id correcte. La tâche configure 10 000 enregistrements à la fois, sauf s’il existe plus de 10 000 enregistrements avec le même horodatage. La progression de la migration dépend de l’horodatage archivé. Le script détermine les tables à migrer :
    var tables = GlideDBObjectManager.get().getAllExtensions(current.table);
        for (i = 0; i < tables.size(); i++) {
            var gr = new GlideRecord('sys_archive_ref_migration');
            gr.addQuery('table', 'ar_' + tables.get(i));
            gr.query();
            if (!gr.next()) {
                if (GlideTableDescriptor.isValid('ar_' + tables.get(i))) {
                    var gr2 = new GlideRecord("sys_archive_ref_migration");
                    gr2.initialize();
                    gr2.setValue('rule', current.sys_id);
                    gr2.setValue('table', 'ar_' + tables.get(i));
                    gr2.setValue('reference_migration_progress', 'waiting');
                    gr2.insert();
                }
            }
        }
        //Also get insert related records tables as well
        var map = new GlideRecord('sys_archive');
        map.addQuery('table', current.table);
        map.query();
        if (map.next()) {
            var id = map.getValue('sys_id');
            if (!(id === undefined)) {
                var related = new GlideRecord('sys_archive_related');
                related.addQuery('archive_map', id);
                related.addQuery('action', 'archive');
                related.query();
                while (related.next()) {
                    if (!GlideTableDescriptor.isValid('ar_' + related.getValue('table'))) {
                        gs.log('Related Record table: ' + related.getValue('table') + ' not created yet');
                        continue;
                    }
     
                    var gr3 = new GlideRecord("sys_archive_ref_migration");
                    gr3.initialize();
                    gr3.setValue('rule', current.sys_id);
                    gr3.setValue('table', 'ar_' + related.getValue('table'));
                    gr3.setValue('reference_migration_progress', 'waiting');
                    gr3.insert();
                }
            }
        }

    Modifier les types de sys_dictionary des tâches de tables migrées (ArchiveRefJob)

    Une fois que les tables associées à une règle d’archivage ont complètement migré, la tâche ArchiveRefJob s’exécute. Cette tâche modifie les types de sys_dictionary de la table d’archivage de Chaîne à Référence.

    Correction des défaillances de nœud pour RefCopyJob et ArchiveRefJob

    Si une défaillance du nœud se produit pendant l’exécution de ces tâches, l’état de la migration de données reste incorrect. En cas d’échec RefCopyJob , une table peut quitter un état de migration. Vous pouvez vérifier cette condition en vérifiant si les lignes du sys_archive_ref_migration sont bloquées dans l’état de migration pendant une durée extraordinaire (quantifier ?). Mettez à jour l’état de la ligne spécifique de la migration à l’attente et poursuit RefCopyJob la migration des données sur la table lorsque la tâche s’exécute à nouveau.

    Le nœud peut également tomber en panne lorsque le ArchiveRefJob se termine prématurément. Vérifiez si les tables ont des champs qui sont des champs de référence et d’autres qui sont toujours des champs de type chaîne. Le travail peut être mort au milieu de la modification des types de champs. Vous pouvez résoudre cette condition en configurant une tâche de déclenchement à exécuter dans un script en arrière-plan, qui redémarre le processus :
    GlideRecord trigger = new GlideRecord('sys_trigger');
    trigger.initialize();
    trigger.setValue('state', 0);
    trigger.setValue('trigger_type', 0);
    trigger.setValue('next_action', new GlideDateTime());
    trigger.setValue('job_context', 'fcRuleId=' + ruleId);
    trigger.setValue('name', 'Job Reference Migration' + ' Node - ' + new GlideClusterSynchronizer().getSystemID());
    trigger.setValue('trigger_class', 'com.glide.db.auxiliary.job.ArchiveRefJob');
    trigger.insert();