Processo de migração de dados para arquivamento de dados da tabela de campos de não referência para campos de referência

  • Versão de lançamento: Xanadu
  • Atualizado 1 de ago. 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. Há scripts e anotações especiais a serem compreendidos 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 sys_dictionary do trabalho de tabelas migradas (ArchiveRefJob)

    Depois que as tabelas associadas a uma regra de arquivamento forem completamente migradas, 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 uma falha de nó enquanto esses trabalhos estiverem em execução, o status da migração de dados será deixado em um estado impróprio. Se o RefCopyJob falhar, ele poderá deixar uma tabela em um 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 um período extraordinariamente longo (quantificar?). Atualize o status da linha específica de migrando para em espera 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 encerrado no meio da mudança dos tipos de campo. Você pode resolver essa condição configurando um trabalho de gatilho para ser executado em um script em segundo plano, o que reinicia o processo:
    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();