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: Washingtondc
  • Mis à jour 1 févr. 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, la RefCopyJob société identifie la sys_id des champs de référence et met à jour la valeur d’affichage pour qu’elle soit 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 des données reste incorrect. En cas d’échec RefCopyJob , il peut laisser une table dans un état de migration. Vous pouvez vérifier cette condition en vérifiant si les lignes du sys_archive_ref_migration sont bloquées à l’état de migration pendant une durée extraordinaire (quantifier ?). Mettez à jour l’état de la ligne spécifique de la migration à l’attente RefCopyJob et poursuivez 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 encore des champs de type chaîne. La tâche a peut-être été interrompue au milieu de la modification des types de champ. Vous pouvez résoudre cette condition en configurant une tâche de déclencheur à 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();