Recuperando Uma Global Excluída Acidentalmente
InterSystems FAQ rubric
Neste artigo, apresentaremos como lidar com a situação: "Excluí acidentalmente uma global!"
Arquivos de backup e journals são usados para recuperar globais específicas que foram excluídas acidentalmente. A restauração é executada especificando as condições e restaurando registros do journal usando o utilitário ^ZJRNFILT. Dessa forma, você pode aplicar um backup pontual do banco de dados e até incluindo a exclusão de uma global específica para registros do journal que contêm as exclusões. Para obter mais informações sobre o utilitário ^ZJRNFILT, consulte a documentação:
Filter Journal Records Using ^ZJRNFILT [IRIS]
Filter Journal Records Using ^ZJRNFILT
【Exemplo】
- Existe um backup de 14/10/2020 (assumindo que o backup foi executado em 15/10/2020 00:30)
Journal: 1 dia de 15/10/2020 existe (15/10/2020) Após o backup do dia14/10)
・Global alvo: ^TEST1
A imagem está abaixo.
Global ^TEST1 será preenchida a partir de 14/10.
A global ^TEST1 foi excluída acidentalmente com uma instrução KILL às 15:30 do dia 15 de Outubro.
Neste estágio, queremos restaurar a global ^TEST1 imediatamente antes do KILL.
No exemplo, ^TEST1(1) a ^TEST1(100) são restaurados usando o journal da global criado pelos comandos abaixo.
USER>for i=1:1:100 set ^TEST2(i)=$ZTIMESTAMP
USER>kill ^TEST1 // ← Processando até aqui para recuperar usando o arquivo de journal para a global ^TEST1
[Procedimento de Restauração]
- Fazer backup/restauração ou copiar (montar) arquivos de banco de dados de backup (CACHE.DAT/IRIS.DAT) para outro sistema
- Copie os journals após a resturação do backup para outro sistema
- Identificar os registros do journal para o comando kill do último arquivo de journal
- Observação1: Visualizar os registros do journal no Portal de Administração ( Portal de Gerenciamento > [Operações do Sistemas] > [Arquivos de Journals] > clique no link [Exibir] para o arquivo específico)
(Para o exemplo exibido, o deslocamento do registro do journal para o comando KILL é 9060180)
- Observação1: Visualizar os registros do journal no Portal de Administração ( Portal de Gerenciamento > [Operações do Sistemas] > [Arquivos de Journals] > clique no link [Exibir] para o arquivo específico)
-
- Observação 2: Você também pode verificar os registros do journal usando a rotina do sistema SELECT^JRNDUMP.
- Restaure os arquivos de journal em ordem, apenas as globais a serem restauradas estão OK.
- Para o último arquivo use o utilitário ZJRNFILT
- Exporte a global recuperada, copie e importe para o sistema original
Abaixo o código de exemplo da rotina ZJRNFILT utilizada no 5º passo(deve ser criada no namespace %SYS com o nome ZJRNFILT ).
ZJRNFILT (pid,dir,glo,type,restmode,addr,time)
set restmode =1// If TEST1 is included in the global variable name // and the journal record is 9060180 or later, set restmode=0 (=do not restore) if ( glo [ "TEST1" ) & ( addr >=9060180) {
set restmode =0
}
quitAbaixo exemplo da restauração do último arquivo de journal usando ZJRNFILT (as entradas estão em letras azuis em negrito).
- %SYS>do ^JRNRESTO
- This utility uses the contents of journal files
- to bring globals up to date from a backup.
- Restore the Journal? Yes => Yes
- Use current journal filter (ZJRNFILT)? yes
- Use journal marker filter (MARKER^ZJRNFILT)? no
- Apply filter to every selected file? Yes => yes
- Process all journaled globals in all directories? no
- Are journal files imported from a different operating system? No => no
- Directory to restore [? for help]: c:\intersystems\hscv\mgr\user\ c:\intersystems\hscv\mgr\user\
- Redirect to Directory: c:\intersystems\hscv\mgr\user\
- => c:\intersystems\hscv\mgr\user\--> c:\intersystems\hscv\mgr\user\
- Process all globals in c:\intersystems\hscv\mgr\user\? No => no
- Global ^TEST1
- Global ^
- Directory to restore [? for help]:
- Processing globals from the following datasets:
- 1. c:\intersystems\hscv\mgr\user\ Selected Globals:
- ^TEST1
- Specifications correct? Yes => yes
- Are journal files created by this IRIS instance and located in their original
- paths? (Uses journal.log to locate journals)? no
- If you have a copy of the journal history log file from the Cache or IRIS
- instance where the journal files were created, enter its full path below;
- otherwise, press ENTER and continue.
- Journal history log:
- Specify range of files to process (names in YYYYMMDD.NNN format)
- from: <20201012.002> [?] => 20201015.001
- through: <20201015.001> [?] =>
- Provide or confirm the following configuration settings:
- Journal File Prefix: [?] =>
- Files to dejournal will be looked for in:
- c:\intersystems\hscv\mgr\journal\
- in addition to any directories you are going to specify below, UNLESS
- you enter a minus sign ('-' without quotes) at the prompt below,
- in which case ONLY directories given subsequently will be searched
- Directory to search: <return when done>
- Here is a list of directories in the order they will be searched for files:
- c:\intersystems\hscv\mgr\journal\
- Prompt for name of the next file to process? No => no
- The following actions will be performed if you answer YES below:
- * Listing journal files in the order they will be processed
- * Checking for any missing journal file on the list ("a broken chain")
- The basic assumption is that the files to be processed are all
- currently accessible. If that is not the case, e.g., if you plan to
- load journal files from tapes on demand, you should answer NO below.
- Check for missing journal files? Yes => no
- You may disable journaling of updates for faster restore for all
- databases other than mirrored databases. You may not want to do this
- if a database to restore is being shadowed as the shadow will not
- receive the updates.
- Do you want to disable journaling the updates? Yes => yes
- Updates will NOT be journaled
- Before we job off restore daemons, you may tailor the behavior of a
- restore daemon in certain events by choosing from the options below:
- DEFAULT: Continue despite database-related problems (e.g., a target
- database is not journaled, cannot be mounted, etc.), skipping affected
- updates
- ALTERNATE: Abort if an update would have to be skipped due to a
- database-related problem (e.g., a target database is not journaled,
- cannot be mounted, etc.)
- DEFAULT: Abort if an update would have to be skipped due to a
- journal-related problem (e.g., journal corruption, some cases of missing
- journal files, etc.)
- ALTERNATE: Continue despite journal-related problems (e.g., journal
- corruption, some missing journal files, etc.), skipping affected updates
- Would you like to change the default actions? No => no
- Start the restore? Yes => yes
- c:\intersystems\hscv\mgr\journal\20201015.001
- 100.00%
- ***Journal file finished at 15:43:05
- [journal operation completed]
- Do you want to delete your journal filter? yes
- Journal filter ZJRNFILT deleted
- %SYS>
Ao fazer a restauração de uma global o journal , **por segurnaça** nós recomendamos que seja feita uma replicação da base de dados e dos arquivos de journal em ou outro ambiente que não seja o de produção. Para então, exportar a global restaurada e transferir (copiar) no ambiente de produção.
Para detalhes das mensagens exibidas durante a restauração do arquivo de journal, consulte a documentação