Processo de migração de dados para arquivar dados da tabela de campos sem referência para campos de referência

  • Versão de lançamento: Washingtondc
  • Atualizado 1 de fev. de 2024
  • 2 min. de leitura
  • O processo de migração de dados move dados de uma tabela de arquivamento existente, incluindo tabelas descendentes e relacionadas. Existem scripts e anotações especiais para entender ao concluir este processo.

    Trabalho de migração de dados (RefCopyJob)

    Para cada tabela que passa pelo processo de migração, o RefCopyJob identifica o sys_id dos campos de referência e atualiza o valor de exibição para o sys_id correto. O trabalho configura 10 mil registros por vez, a menos que haja mais de 10 mil registros com o mesmo carimbo de data/hora. O andamento da migração depende do carimbo de data/hora arquivado. O script determina as tabelas a serem migradas:
    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();
                }
            }
        }

    Alterar os tipos de sys_dictionary do trabalho de tabelas migradas (ArchiveRefJob)

    Depois que as tabelas associadas a uma regra de arquivamento forem migradas completamente, o trabalho ArchiveRefJob será executado. Este trabalho muda os tipos sys_dictionary da tabela de arquivamento de cadeia de caracteres para referência.

    Correção de falhas de nó para RefCopyJob e ArchiveRefJob

    Se ocorrer falha de nó enquanto esses trabalhos estiverem em execução, isso deixará o status da migração de dados em um estado inadequado. Se o RefCopyJob falhar, ele poderá deixar uma tabela com status de migração. Você pode verificar essa condição verificando se as linhas em sys_archive_ref_migration estão travadas no status de migração por uma quantidade extraordinaria de tempo (quantificar?). Atualize o status da linha específica de migrando para aguardando e o RefCopyJob continuará a migração de dados na tabela quando o trabalho for executado novamente.

    O nó também pode falhar quando o ArchiveRefJob termina prematuramente. Verifique se as tabelas têm campos que são campos de referência e alguns que ainda são campos do tipo cadeia de caracteres. O trabalho pode ter sido desativado no meio da mudança dos tipos de campo. Você pode resolver essa condição configurando um trabalho de gatilho para executar em um script em segundo plano que inicia o processo novamente:
    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();