Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
1
Métodos para recuperar uma base de dados corrompida.
Causas de perda de dados e causas de corrupção.
Estratégias.
ZIM TECHNOLOGIES DO BRASIL
ZIM CORPORATION
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
2
Recuperação de uma base de dados corrompida
I)
Método I - zim0001 corrompido
II)
Método II – zim0001 corrompido
III) Método III – Base geral corrompida
IV) Método IV – Base geral corrompida
V) Método V - Para quem tem problemas de espaço em disco
VI) Causas de perda de dados ou corrupção e estratégiasESTRATEGIAS
1.
EVENTOS.-
2. Backup e Restauração
3.
ESTRATÉGIAS GERAIS
4.
COMO VERIFICAR A INTEGRIDADE DE SEU BANCO DE DADOS.
5. Error! Reference source not found.
6.
INTEGRIDADE E SEGURANÇA DE BANCOS DE DADOS ZIM.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
3
Recuperação de uma base de dados corrompida
I)
Método I - zim0001 corrompido
Neste caso utilize primeiro o zimfix para verificar se existe algum objeto com problemas, se existir os
mesmos devem ser recuperados antes de seguir em diante.
1) Crie uma nova base de dados Zim 7.11 (BaseNova):
# mkdir BaseNova
# cd BaseNova
# $ZIM/ziminit .
# cp ../Base_orig/config.db config.db
2) Copiar os arquivos de dicionário de dados da base de dados com problema, para a nova base de dados Zim
7.11 (BaseNova), EXCETO os arquivos Zim0001 e Zim0099
# cd Base_orig
# cp zim0002 zim0003 zim0004 zim0005 zim0006 zim0007 zim0008 zim0009 zim0010 zim0011 zim0012
zim0013 zim0014 zim0015 zim0016 zim0017 zim0018 zim0019 zim0040 zim0041 zim0042 zim0043
zim0044 zim0045 zim0080 zim0081 zim0082 zim0083 zim0084 zim0085 zim0086 zim0087 ../BaseNova
ou cp zim000[2-9] zim00[1-8]? ../BaseNova
3) # $ZIM/zimfiles +v > zfBase_orig.txt (executar este comando na base “Base_orig”)
4) Na nova base de dados (BaseNova), via DC criamos um novo Zim diretório chamado ZOMOBJ, e
executamos o ZOMCONFIG para configurá-lo para criar os objetos do ZOM neste diretório.
5) Alteramos o arquivo config.db da nova base de dados (BaseNova), aumentando o parâmetro descriptors
para 400.
6) Executamos os comandos abaixo no prompt do Zim da nova base de dados (BaseNova), para criar os
objetos no novo dicionário de dados (zim0001):
> zomenable
> zomreset
> zomcreate +t dirs - n ZIM
> zomcreate +t ents
> zomcreate +t roles
> zomcreate +t docs -pE (não criar docs já criados)
> zomcreate +t forms -pE (não criar forms já criados)
> zomcreate +t consts -pE (rels podem conter constantes)
> zomcreate +t vars
(rels podem conter variáveis)
> zomcreate +t rels
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
4
> zomcreate +t sets
> zomcreate +t disps
> zomcreate +t wins
> zomcreate +t menus
(sets podem envolver rels)
Edite o arquivo “errtrace” , para verificar e corrigir posíveis erros gerados no zomcreate.
7) > bye
# $ZIM/zimfiles +v > zfBaseNova.txt
(executar este comando na base “BaseNova”)
8) Copie os arquivos de dados zim0100 em diante da base original (Base_orig) para a base nova (BaseNova).
Não copie os arquivos de Diretórios (eles foram criados no comando zomcreate +t dirs –n ZIM), para saber
quais arquivos são diretórios, execute o comando “$ZIM/zimfiles +v|grep directory” na base original
(Base_orig).
Antes de copiar Compare os arquivos de dados “zfBaseNova.txt “ e “zfBase_orig.txt “, se existir arquivos
diferentes para a mesma tabela, copie seguindo o exemplo a seguir.
Exemplo: Na base original a tabela Clientes é zim0101
Na base BaseNova a tabela Clientes é zim0200
# cd ../BaseNova
# cp ../Base_orig/zim0101 zim0200
Copie também outros fontes e arquivos de configuração existentes.
9) altere o nome da base “Base_orig” para Base_orig.old
# cd ..
# mv Base_orig Base_orig.old
# mv BaseNova Base_orig
10) Lembre-se que você terá que recompilar todos os programas para pode efetuar seus testes, pois o zim0001
“recuperado” tem numeração de objetos internos do Zim, diferente do zim0001 “danificado”.
11) Para o processo de investigação sobre o problema de corrupção do dicionário de dados, aconselhamos
fortemente que seja executado o comando zomdiagnose, sempre que objetos forem incluídos/modificados,
para podermos descobrir a fonte do problema.
> zomdiagnose ;d zomoutputdoc
Dentro do documento zomoutputdoc terá a saída da execução do comando zomdiagnose.
12) Guarde a base Base_orig.old por um tempo (é a base original corrompida), qualquer problema na
recuperação, temos que usar esta para tentar outros métodos de recuperação.
13) Faça backup da base recuperada.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
5
II)
Método II – zim0001 corrompido
Neste método o zim0002 até zim0087 não podem estar corrompidos
1) Crie uma nova base de dados Zim 7.11 (BaseNova):
# mkdir BaseNova
# cd BaseNova
# $ZIM/ziminit .
# cp ../Base_orig/config.db config.db
2) Copiar os arquivos de dicionário de dados da base de dados com problema, para a nova base de dados Zim
7.11 (BaseNova), EXCETO os arquivos zim0001 e Zim0099
# cd Base_orig
# cp zim0002 zim0003 zim0004 zim0005 zim0006 zim0007 zim0008 zim0009 zim0010 zim0011 zim0012
zim0013 zim0014 zim0015 zim0016 zim0017 zim0018 zim0019 zim0040 zim0041 zim0042 zim0043
zim0044 zim0045 zim0080 zim0081 zim0082 zim0083 zim0084 zim0085 zim0086 zim0087 ../BaseNova
ou
cp zim000[2-9] zim00[1-8]? ../BaseNova
3) # $ZIM/zimfiles +v > zfBase_orig.txt (executar este comando na base “Base_orig”)
4) Na nova base de dados (BaseNova), via DC criamos um novo Zim diretório chamado ZOMOBJ, e
executamos o ZOMCONFIG para configurá-lo para criar os objetos do ZOM neste diretório.
5) Alteramos o arquivo config.db da nova base de dados (BaseNova), aumentando o parâmetro descriptors
para 400.
6) Copiar Objectlist e Keywords da base original
Cp ../Base_orig/dcrt/zim9805 ../BaseNova/dcrt
Cp ../Base_orig/dcrt/zim9808 ../BaseNova/dcrt
7) Executamos os comandos abaixo no prompt do Zim da nova base de dados (BaseNova), para recriar os
objetos no novo dicionário de dados (zim0001):
> zomenable
> let <UseExistingFileum> = $true
> zomfixup
> zomtouch *
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
6
7.1) Opção 1 para criar os objetos
> zomcreate +t dirs - n ZIM
> zomcreate +t ents
> zomcreate +t roles
> zomcreate +t docs -pE
> zomcreate +t forms -pE
> zomcreate +t consts -pE
> zomcreate +t vars
> zomcreate +t rels
> zomcreate +t sets
> zomcreate +t disps
> zomcreate +t wins
> zomcreate +t menus
(não criar docs já criados)
(não criar forms já criados)
(rels podem conter constantes)
(rels podem conter variáveis)
(sets podem envolver rels)
7.2) Opção 2 para criar os objetos
a) Execute o Zomconfig (para configurar o ZOM – e para processar por ordem de
dependência para garantir que objetos dependentes serão criados após os seu owners.
b) no Zomconfig fazer: Sort Order: DependencyLevel
c) no prompt do Zim executar:
> Zomcreate * - K $Ziminit
8) Para verificar se todos os objetos estão criados executar:
> Zomlist +pE! (Este comando lista todos os objetos não criados)
9) Executar novamente o comando:
> Zomcreate * -pE (recomandado pois alguns objetos dependentes de outros podem não ter sido criados ou
podem ter tido algum erro)
10) Edite o arquivo “errtrace” , para verificar e corrigir posíveis erros gerados no zomcreate.
11) > bye
# $ZIM/zimfiles +v > zfBaseNova.txt
(executar este comando na base “BaseNova”)
12) Copie os files zim0100 a zim0900 da base original (Base_orig) para a base nova (BaseNova). Não copie
os arquivos de Diretórios (eles foram criados no comando zomcreate +t dirs –n ZIM), para saber quais
arquivos são diretórios, execute o comando “$ZIM/zimfiles +v|grep directory” na base original (Base_orig).
Antes de copiar Compare os arquivos “zfBaseNova.txt “ e “zfBase_orig.txt “, se existir files diferentes para a
mesma tabela, copie seguindo o exemplo a seguir.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
7
Exemplo: Na base original (Base_orig) a tabela Clientes é zim0101
Na base nova (BaseNova)
a tabela Clientes é zim0200
# cd ../BaseNova
# cp ../Base_orig/zim0101 zim0200
Copie também outros fontes e arquivos de configuração existentes.
OBS.: Não copiar os arquivos de Diretórios Zim (eles foram criados no comando “zomcreate”.
13) altere o nome da base “Base_orig” para Base_orig.old
# cd ..
# mv Base_orig Base_orig.old
# mv BaseNova Base_orig
14) Lembre-se que você terá que recompilar todos os programas para pode efetuar seus testes, pois o zim0001
“recuperado” tem numeração de objetos internos do Zim, diferente do zim0001 “danificado”.
15) Para o processo de investigação sobre o problema de corrupção do dicionário de dados, aconselhamos
fortemente que seja executado o comando zomdiagnose, sempre que objetos forem incluídos/modificados,
para podermos descobrir a fonte do problema.
> zomdiagnose ;d zomoutputdoc
Dentro do documento zomoutputdoc terá a saída da execução do comando zomdiagnose.
16) Guarde a base Base_orig.old por um tempo (é a base original corrompida), qualquer problema na
recuperação, temos que usar esta para tentar outros métodos de recuperação.
17) Faça backup da base recuperada.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
8
III)
Método III – Base geral corrompida
1) Na base corrompida
Na base de dados a recuperar: executar os passos abaixo para gerar o diretório “port”, onde será
exportado o dicionário de dados do Zim:
# cd /basezim/baseorig
# mv port port.old
# mkdir port
# $ZIM/zim
> zomenable
> zomfixup
>zomtouch *
> zomexport *
> bye
# $ZIM/zimfiles +v > zfbaseorig.txt
2) Criar uma nova base de dados Zim: onde será importada as definições do item 1 acima, veja os passos
abaixo:
# mkdir /basezim/Base_orig.
# cd /basezim/Base_orig.
# $ZIM/ziminit.
# cp ../basezim/baseorig/port/* port
3) Executar os passos abaixo na base de dados “nova”: no prompt do Zim, para importar os objetos
utilizando Zomimport:
# $ZIM/zim
> zomenable
> let <UseExistingFileNum> = $true
> zomimport *
> bye
# $ZIM/zimfiles +v > zfBase_orig.txt
OBS o comando em vermelho acima, é utilizado para que o o Zim “crie” os arquivos de dados
(zimXXXX) com os mesmos números da base de dados origem.
4) Comparar o conteúdo dos arquivos zfbaseok.txt e zfBase_orig.txt: para verificar se os números
dos arquivos zimXXXX não foram alterados.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
9
5) Copiar os outros arquivos de configuração do Zim: diretórios de fontes e outros diretórios/arquivos
necessários para que seja possível compilar completamente a aplicação:
# cp ../basezim/baseorig/config.* .
# cp ../basezim/baseorig/dirs.zim .
# cp ../basezim/baseorig/areas.zim .
# cp ../basezim/baseorig/zimprof .
Outrossim, recomendamos fortemente o backup diário do dicionário de dados do Zim, na base de
dados de desenvolvimento, conforme relação abaixo:
# cd /basezim/basedes
# rm –f port/*.z50
# $ZIM/zim
> zomenable
> zomexport *
> bye
# $ZIM/zimfiles +f > zfbasedes.txt
# tar cvfz bkdiariozim.tar.gz ./dpsrt ./dcrt ./zim00* ./zimXXXX ./config.* ./areas.zim ./dirs.zim
./zimprof ./port ./zfbasedes.txt
OBS: os arquivos zimXXXX (em vermelho acima) serão os arquivos que tem diretórios
zimXXXX.ws associados com ele. Vamos supor que você tem o diretório zim0100.ws, você deverá
copiar também o arquivo zim0100.
Para o processo de investigação sobre o problema de corrupção do dicionário de dados (zim0001),
aconselhamos fortemente que seja executado o comando zomdiagnose, sempre que objetos forem
incluídos/modificados, para podermos descobrir a fonte do problema.
> zomdiagnose ;d zomoutputdoc
Dentro do documento zomoutputdoc terá a saída da execução do comando zomdiagnose.
6) Faça um backup da base recuperada
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
10
IV)
Método IV – Base geral corrompida
Para executar este método, é necessário que se cumpram os seguintes requisitos:
1) Manter backup diário de sua base de produção (baseprod)
2) A base de desenvolvimento tem que ser um espelho (idêntica) da base de produção (basedes).
3) Crie um pasta para baixar o backup (basebkp), e copie o backup para esta pasta.
Caso a)
4) Entre no Zim na base baseprod.
5) Execute: - zomenable
- zomexport *
6) Copie a pasta baseprod/port para basebkp/port.
7) Entre no Zim em basebkp
8) Execute:
- Zomenable
- Zomimport *
Caso b) – Ignore os itens 4) ao 8) e execute o item 9).
9) Na base “basebkp” (cd basebkp)
- Entre no Zim
- Entre no DC
- Adicione os objetos criados após o backup.
10) Execute o zomdiagnose com a sintaxe explicada nos métodos anteriores.
11) Teste a integridade desta base, se tudo estiver perfeito.
12) Renomeie a baseprod para baseprod.err (Base original corrompida).
13) Renomeie a basebkp para baseprod.
14) Faça um backup da “baseprod”.
(Base recuperada).
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
11
V)
Método V - Para quem tem problemas de espaço em disco
1) Faça novo backup da base corrompida
2) Copie o backup (sem corrupção) para a base corrompida.
- Entre no Zim
- Entre no DC
3) - Adicione os objetos criados após este backup.
4) Execute o zomdiagnose com a sintaxe explicada nos métodos anteriores.
5) Teste a integridade desta base, se tudo estiver perfeito, faça um backup novamente.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
12
VI)
Causas de perda de dados ou corrupção e estratégias
A perda de dados e corrupção não são comuns na maioria dos sistemas, mas ocorrências ocasionais são
inevitáveis e as causas podem ser diversas. Alguns dos eventos que podem causar perda de dados ou
corromper uma base de dados incluem:
1) EVENTOS.Evento
Descrição
Erro do usuário 1) Registros individuais, ou mesmo arquivos inteiros, podem ser apagados por acidente ou malintencionados.
2) Cancelamento de sessão de usuário: administrador do sistema cancela frequentemente sessões de
usuários (kill -9),(veja item 3);
3) Finalização inadequada da sessão Zim pelo usuário: sessão de usuário que fica "ativa" mas
desconectada, usuário fecha no botão ["X"] do emulador de terminal, ao invés de finalizar a aplicação Zim;
4) Alterar o Dicionário de dados em monousuário (ZIM) enquanto existem usuários trabalhando em
Multiusuário (ZIMMU, ZIMRT, ZIMRTMU,etc).
Terminação
Os arquivos podem ser corrompidos se o software for interrompido no meio de uma atualização por
anormal
eventos tais como uma falha de energia, um sistema de desligamento ou reiniciar, ou um sinal do sistema
do usuário ou a operação para finalizar a execução.
Falha de
Dados podem ser perdidos se um disco de repente, por algum motivo se torna ilegível (problema em
hardware
disco), corrupção de memória, bug do sistema operacional e etc.
Configuração
Alguns parâmetros de configuração com valores errados, podem causar corrupção:
LARGE FILE LOCKING:
O valor padrão para “large file locking” é não, para assegurar a adequada interoperacionalidade entre
versão diferente do Zim e diferentes Sistemas operacionais. Se o “large file locking” está definido no
arquivo config.db como “large file locking yes”, todos os usuários devem iniciar em sistemas que
suportam grandes arquivos, ou pode ocorrer corrupção em arquivos do banco de dados.
MAXIMUM USERS: Todos os usuários de uma determinada aplicação deve usar o mesmo valor para o
“maximum file number” e “maximum users”, ou pode resultar em corrupção de dados. Para garantir que
todos os usuários tenham o mesmo valor, coloque essa opção no banco de dados ou arquivo de
configuração padrão.
Diversos Fatores 1) - Diretórios e programas compilados podem conter ponteiros internos apontando para outras páginas.
Um desses indicadores está errado. .
- Um programa foi compilado e a referência do set está incorreta.
- Houve alteração na estrutura de objetos (Ents,Rels,Roles, forms,etc),
e o programa que invoca estes objetos é executado sem ser recompilado.
2) Não utilização do recurso de NAMED SETS nos programas compilados: aconselhamos fortemente aos
nossos clientes que façam a utilização do recurso de "NAMED SETS", para garantir que um mesmo "SET"
tenha sua estrutura "inalterada" durante seu tempo de utilização no sistema. Imagine o seguinte cenário
onde um "SET" é utilizado para diferentes tipos de tabelas e operações no banco (add, change, update ou
delete), se a estrutura que está sendo utilizado não estiver “adequada” ou “atualizada”, poderá provocar
corrupção de dados, e também do dicionário de dados.
Para utilizar NAMED SETS, basta cadastrar os “SETS” utilizados dentro dos programas, no dicionário de
dados do Zim, para isso entre no DC, opção Objects, Named Sets:
Set Name: informar aqui o nome do set
Directory Name: diretório do Zim onde o objeto deverá ser incluído
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
13
Set Specification: especificar a estrutura do set
Veja o exemplo abaixo para as tabelas tbbanco e tbagencia:
Set Name: SetBancoAgencia
Directory Name: Financeiro
Set Specification: tbbanco rbancoagencia tbagencia
Outros
Observe que na especificação do “SET” deve ser informado a estrutura das tabelas e relacionamentos a
serem utilizados no “SET”, se você mudar a estrutura (objetos Zim na especificação do “SET”) o “SET”
obrigatoriamente deverá ser outro!
find tbagencia rbancoagencia tbbanco ragenciaend tbendereco -> SetBancoAgencia  foi incluído um
objeto a mais no “SET”, portanto ele é um “SET” novo!
Se a corrupção ocorre na compilação de programas:
Aconselhamos que você crie blocos de compilação de programas, até descobrir qual programa está
provocando o erro de corrupção do dicionário de dados do Zim, isolando até chegar no programa ou na
sequência de passos que provoca a corrupção.
Eventos como estes podem acontecer em qualquer lugar, a qualquer momento, você deve planejar como irá
lidar com uma possível perda de dados no futuro. Seu plano deve incluir uma política periódica de tempo para
verificar a integridade de seu banco de dados.
Zim fornece proteção embutida contra esses eventos. Por exemplo, sistemas multi-usuário têm proteção
embutida contra o encerramento anormal. Um arquivo de transações é criado para cada usuário, aplicativo
para armazenar as atualizações para o banco de dados de uma transação em andamento. As atualizações são
copiados a partir do arquivo de transações para o banco de dados somente se a transação for confirmada (ou
seja, o comando é executado ENDTRANSACTION). Se a transação for abortada (ou seja, o comando
QUITTRANSACTION é executada, ou ocorreu um bloqueio) o conteúdo do arquivo de transações serão
descartadas. Como resultado, o encerramento irregular (a menos que ocorra durante a execução do
ENDTRANSACTION) terá o mesmo efeito que uma operação abortada (porque o comando
ENDTRANSACTION não é executado) e, portanto, mudanças parciais não serão feitas para o banco de dados
e o banco de dados permanece livre de corrupção.
A combinação de transações implícitas e explícitas em ZIM muttiusuário assegura que as bases de dados
permaneçam protegidas adequadamente contra a corrupção que pode resultar de múltiplos acessos e, ao
mesmo tempo, permitir o mínimo inconveniente possível aos usuários.
2) Backup e Restauração
Ao mecanismo do ZIM que implementa esta segurança dá-se o nome de auditagem de transações, a
qual somente se aplica aos ambientes multiusuários, e que consiste na constante gravação em arquivos
especialmente designados para esta tarefa de todos os dados alterados pelas transações dos usuários.
Abordando mais profundamente esta questão, cada vez que uma transação qualquer faz uma alteração
sobre algum arquivo de uma base de dados ZIM, esta alteração é registrada num arquivo especial denominado
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
14
arquivo de auditagem e chamado pelo nome de zimtrans.x, onde x é um número que identifica o usuário que
está fazendo a alteração. Como o ZIM trabalha os dados sempre em unidades de 1024 Kbytes denominadas de
páginas, estas é que são jogadas para o arquivo de auditagem conforme a transação for prosseguindo. Durante
a execução da transação, nenhuma alteração é feita sobre os arquivos reais da base de dados. Ao final da
transação, todas as páginas gravadas no arquivo de auditagem são transferidas “de uma vez só” para os
arquivos aos quais cada uma delas pertence. Somente neste ponto a transação é dada como concluída. Esta
forma de fazer as coisas pelo ZIM tem duas vantagens muito importantes, ambas visando à segurança e a
correta manipulação dos dados: primeiro, os arquivos são efetivamente modificados num curto espaço de
tempo; isto significa que a probabilidade dos arquivos ficarem num estado inconsistente é extremamente baixa
porque as páginas são transferidas em rajada para seus lugares definitivos. Em segundo lugar, se algum
problema ocorrer, como pane no equipamento, conflito de concorrência com outro usuário, ou mesmo o
desejo do próprio usuário em voltar atrás nas modificações, o ZIM simplesmente abandona o arquivo de
auditagem, deste modo impedindo que as alterações feitas dentro da transação se concretizem, sem que os
arquivos reais ao menos tenham sido tocados.
O momento em que o ZIM faz a transferência em rajada corresponde ao final da execução de um
comando qualquer numa transação implícita, ou na execução do comando ENDTRANSACTION numa
transação explícita. Por outro lado, o arquivo de auditagem é abandonado quando for executado o comando
QUITTRANSACTION numa transação explícita, ou quando o comando de uma transação implícita for
interrompido em meio à sua execução.
Uma transação é chamada de explícita porque compreende um ou mais comandos ZIM iniciados por
um comando TRANSACTION e terminados por um ENDTRANSACTION ou QUITTRANSACTlON. Uma
transação implícita é qualquer comando ZIM que atue sobre a base de dados, mas que não tenha sido
precedido pelo comando TRANSACTION.
Após o término da transação, normal ou anormalmente, e quando do início da próxima transação, o
ZIM pode dispor do arquivo de auditagem de duas formas diferentes: ou ele grava as alterações da nova
transação sobre aquelas feitas na transação anterior, ou prossegue emendando as novas alterações após as
anteriores. A decisão entre uma e outra é dada pela opção de configuração audit updates que o usuário coloca
no seu arquivo de configuração, que é lido ao iniciar sua sessão do ZIM. Se a opção for yes, o ZIM
prosseguirá emendando umas alterações após as outras; se for no ou não existir, o ZIM reaproveitará o espaço
anteriormente usado para novas transações. Em qualquer caso, se a transação anterior foi interrompida o
espaço eventualmente utilizado no arquivo de auditagem será reaproveitado.
O objetivo final de usar-se a auditagem de transações ligada é poder-se recuperar os arquivos da base
de dados, se for necessário. Esta recuperação é feita pelo utilitário ZIMRCVR (ZIM ReCoVeRy: Recuperador
ZIM).
Se por um lado à auditagem de transações desativada tem a vantagem de poupar área em disco (o
tempo de execução de qualquer transação, entretanto, não é alterado), por outro, não permite que se faça a
recuperação posterior da base de dados através do utilitário ZIMRCVR. Cabe ao Administrador da Base de
Dados determinar qual o caminho a ser seguido: se usar com mais economia os recursos de disco ou aumentar
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
15
a segurança dos dados. Algumas aplicações, pelas suas características de funcionalidade, podem perfeitamente
dispensar a auditagem de transações, enquanto que a maioria exige o emprego deste recurso.
Nesta mesma linha de raciocínio é bem fácil deduzir-se que se um usuário ativar a opção, todos os
outros também deverão ativá-la, pois do contrário, em caso da recuperação da base, algumas atualizações
serão feitas e outras não, deixando a base de dados inconsistente. Além disso, existe um perigo maior ainda
que é o de perder também o registro das atualizações feitas corretamente pelos usuários quando estes saírem
de suas sessões e os arquivos de auditagem coincidirem de ser utilizado por outros usuários que não possuem
a opção ativada. Como se sabe, a cada nova transação o arquivo é reinicializado, provocando a perda das
informações anteriormente gravadas. É por isto que a opção audit updates deve ser sempre colocada no
arquivo de configuração da base de dados, config.db.
Os Arquivos que Armazenam a Auditagem de Transações
Cada base de dados que está sob a execução do ZIM multiusuário possui um conjunto de arquivos
zimtrans que são reservados um para cada usuário que estiver ativo num dado instante. O primeiro usuário a
entrar em operação sobre a base (disparando o ZIMMU, ZIMRTMU ou ZIMQRTMU) começa a trabalhar
com o arquivo zimtrans.0, o segundo com o zimtrans.1 e assim por diante. Quando algum destes usuários
terminar sua sessão, o arquivo correspondente fica disponível para o próximo usuário que entrar (o qual até
poderá ser o mesmo que saiu). Portanto, se a opção audit updates estiver ativada, um determinado arquivo
zimtrans poderá conter as atualizações acumuladas de um ou mais usuários daquela base de dados. Em caso
contrário (isto é, quando a opção audit updates estiver desativada), os arquivos zimtrans só terão sentido
durante a existência de uma transação, podendo ser eliminados após o final da sessão (cuidado!!: somente
faça isto se a opção audit updates estiver desativada e quando todos os usuários também estiverem fora de
suas sessões!).
O local onde o ZIM grava os diversos arquivos de auditagem de transações (zimtrans.0, zimtrans.1,
etc.) é indicado por outra opção do arquivo de configuração do ZIM, audit path. Se esta opção não for
informada, os arquivos de auditagem serão gravados no diretório do sistema operacional onde a base de dados
se encontra. A vantagem do uso desta opção é o aumento da segurança das atualizações sobre a base de dados,
pois permite dissociar fisicamente a base de dados de sua auditagem. Por exemplo, a base de dados pode
residir num disco físico enquanto a auditagem reside em outro; se acontecer um problema com os discos, um
ou outro terá a chance de se salvar, permitindo a recuperação futura. Outra ideia interessante - que só
funcionará se houver memória suficiente disponível, se a opção de configuração audit updates estiver
desligada e se as transações forem bastante pequenas - consiste em desviar os arquivos de auditagem para um
disco virtual na memória, o que permitirá acelerar a execução das transações.
Um arquivo zimtrans contém, para cada transação iniciada, um prólogo indicando o usuário que
iniciou a transação, um número sequencial indicando a ordem da transação, a data e a hora, bem como uma
indicação de que a transação foi terminada com sucesso ou não (esta indicação é gravada ao final da transação
e mostra, se as modificações que vem a seguir podem ser usadas numa posterior e eventual recuperação dos
arquivos aos quais estas informações pertencem). Logo após, vem cada uma das páginas modificadas dos
diversos arquivos físicos envolvidos na transação, inclusive áreas de índices. Finalmente, é gravado um
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
16
epílogo fechando a transação (a ordem dos dados mencionados acima não é necessariamente a ordem física
gravada no arquivo zimtrans).
O conteúdo lógico de um arquivo zimtrans pode ser visualizado pela execução do utilitário ZIMRCVR
com a opção + q não documentada nos manuais, como mostrada no exemplo:
zimrcvr +q zimtrans.5
São mostrados todos os passos executados durante a transação no sentido da proteção e recuperação
dos dados com hora, data, número da transação (aquele contido no arquivo zimlock.zim), números dos
arquivos ZIM e das respectivas páginas alteradas durante o processo, entre outras informações indispensáveis
à recuperação.
Pelo que se viu, deduz-se que o tamanho de um arquivo zimtrans poderá variar enormemente
dependendo do tipo de transação usado e se a opção de configuração audit updates estiver ligada, já que, neste
último caso, o histórico de cada transação vai se empilhando ao longo do dia, a ponto de produzirem-se
arquivos com muitos megabytes de extensão. Comandos do tipo "CHANGE ALL ..." envolvendo entidades
muito populosas costumam produzir arquivos zimtrans muito extensos.
Embora estas considerações possam assustar um pouco, recomenda-se insistentemente que qualquer
modificação sobre os arquivos de uma base de dados ZIM seja feita no ambiente multiusuário, porque, em
caso de qualquer tipo de erro, a transação em andamento é automaticamente desfeita ou abandonada, deixando
os arquivos originais íntegros. Este não é o caso do ambiente monousuário, onde não existe o conceito de
transação e não são utilizados os arquivos zimtrans; as atualizações são feitas diretamente sobre os arquivos
originais: em caso de erro, o comando em execução é interrompido ou abandonado e as modificações ficarão
pela metade, deixando os arquivos originais inconsistentes.
Mas, o que fazer com os arquivos de auditagem de transações gravados ao longo de um determinado
período de tempo?
Supondo que todos os usuários da base de dados usem a opção de configuração audit updates ligada,
estes arquivos poderão ser usados para trazer ou recuperar a base de dados até uma situação onde existe a
confiança de que ela esteja íntegra.
A maneira de usar este recurso pode ser a seguinte: de tempos em tempos - digamos, uma vez ou duas
vezes por dia, dependendo da necessidade - é feita uma cópia de salvamento de todos os arquivos de
auditagem (atenção!!: nenhum usuário deve estar operando sobre a base!).
Após o salvamento, os arquivos de auditagem devem ser apagados, não só para diminuir o espaço
utilizado em disco, como também para evitar a duplicidade do salvamento e a reaplicação da auditagem sobre
os arquivos. Em intervalos maiores de tempo, por exemplo, semanalmente, é feita uma cópia de salvamento
completa da base de dados.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
17
Quando for detectado algum erro na base de dados que justifique o seu abandono, escolhe-se a cópia
de salvamento mais recente que contenha os arquivos corretos da base de dados e aplicam-se os arquivos de
auditagem, em cascata, sobre a base de dados, via o utilitário ZIMRCVR. Deste modo, as transações
realizadas após a cópia de salvamento são refeitas exatamente como na situação original, deixando a base de
dados atualizada e íntegra novamente.
Lembre-se!: Com Audit Update yes, arquivos de auditagem (Zimtrans) e o Zimlock.zim são interrelacionados. Deve sempre fazer backups e removê-los juntos!
•
•
O backup da BD deve estar sincronizado com o dos arquivos de audit e o do Zimlock.zim.
Todos os arquivos de audit devem estar no mesmo diretório.
Uma consideração final relativa ao tempo de processamento de transações em multiusuário:
Por força do uso dos dispositivos de segurança do ambiente multiusuário, como a auditagem, etc., a mesma
transação é executada mais rapidamente em monousuário. Por isto, os usuários são tentados a usar este
ambiente em certos momentos. Isto realmente pode ser feito, desde que se tenha plena consciência do trabalho
em andamento e que se faça uma cópia de salvamento dos arquivos envolvidos antes do início das tarefas. Ao
Administrador da Base de Dados cabe a incumbência de discernir sobre esta questão.
Recuperação Automática do BD.
–
A opção Automatic Recovery permite que transações que falharam durante o estágio de
commit (EndTransaction), sejam recuperadas em uma nova sessão Zim multiusuária.
– O arquivo ‘translog.zim’ é usado para salvar as informações necessárias.
• Depende do "maximum users" (config.db)
• Se "maximum users“ é mudado, apagar o translog.zim.
• Nunca apagar este arquivo se existir algum usuário em sessão na base de dados.
– Todas as transações terminadas são reaplicadas à BD quando uma nova sessão Zim
multiusuária inicia.
– A opção audit path de todos os usuários , se usada, deve apontar sempre para o mesmo
diretório.
• Use o config.db para a opção audit path.
Quando os usuários estiverem em uma rede, "audit path" deve apontar para um arquivo que seja
visível pela rede.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
18
2.1) Controle via configuração. Direcionar para outra pasta todos os arquivos temporários criados pela aplicação Zim.
2.2) Arquivos mais comuns criados em um aplicativo Zim
errors.trc - Durante a execução de um comando ZIM, o interpretador ou executor podem detectar erros ou
situações inconsistentes que são avisadas ao usuário, tanto no seu 1)-vídeo quanto num 2)-arquivo sequencial
especial denominado errors.trc, criado no diretório de trabalho da sessão. O primeiro pode ser desativado via
os comandos específicos “SET MESSAGES OFF”, “SET ERRORS OFF”, etc., enquanto que o segundo pode
ser ativado por estas opções (as mensagens de erro podem ser lançadas em outro meio de saída ao mesmo
tempo). Em princípio, esta opção deveria estar sempre ligada em todas as sessõers ZIM porque auxilia muito
na pesquisa e solução de erros nas diversas fases da vida de um sistema aplicativo. Resumindo este arquivo é
gravado na sessão de cada usuário e não no banco de dados. Para isto, cada usuário deve ter uma base Zim
local com seu respectivo config.zim.
Zimcomp
= Arquivo temporário, criado e usado somente durante as compilações de programas ZIM.
Zimsetd = Arquivo temporário, criado na sessão de cada usuário apontado pelo “work path” do config.zim.
Este arquivo contem informações dos diretórios ZIM para trabalho durante a sessão ZIM em andamento.
Zimsett = Arquivo temporário, criado na sessão de cada usuário apontado pelo “work path” do config.zim.
Este arquivo registra informações relativas aos conjuntos (sets) gerados durante a sessão ZIM em andamento.
zimtrans.nnn = Arquivo de auditagem, registra as alterações efetuadas numa transação qualquer sobre um
arquivo do banco de dados. O local onde o ZIM grava este arquivo é indicado pela opção: audit path, se esta
opção não for informada, os arquivos de auditagem zimtrans.nnn serão gravados no diretório da base de
dados.
A opção audit path de todos os usuários , se usada, deve apontar sempre para o mesmo diretório. Configure
esta opção no arquivo config.db.
zimlock.zim = Faz o controle da concorrência, é o arquivo onde o ZIM sabe o que as outras sessões estão
fazendo através do acesso a este arquivo. O Zimlock.zim também faz a ponte entre os dois níveis onde os
bloqueios são realizados, ou seja, bloqueios controlados pelo ZIM e pelo Sistema Operacional.
Lock path <name> O endereço do diretório onde os arquivos zimlock serão criados (opcional).
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
19
3) COMO VERIFICAR A INTEGRIDADE DE SEU BANCO DE DADOS.
Se você suspeita de corrupção de seu banco de dados, ou se você quiser verificar a integridade do banco de
dados, execute o arquivo (ZIMFIX) para todos os arquivos de dados. O ZIMFIX verifica a integridade
estrutural dos dados, procurando solucionar e reparar os danos encontrados. Em particular, ele verifica em
primeiro lugar, a integridade da estrutura do arquivo; a seguir, verifica a correspondência entre dados e
índices, consertando e reconstruindo qualquer índice inválido.
Nota: Antes de executar o ZIMFIX, execute o ZIMDD que gera arquivos estruturais da base de dados para
uso do ZIMFIX.
Por exemplo, para verificar a integridade dos arquivos de dados correspondentes as entidades com nomes:
Clientes e Produtos, execute os seguintes comandos a nível do sistema operacional:
zimdd
zimfix Clientes
zimfix Produtos
4) DETECTAR OBJETOS CORROMPIDOS VIA Error! Reference source not found.
Você também pode selecionar e corrigir os objetos considerados corruptos pelo ZOM (ou seja, out-of-date).
Um objeto é considerado corrupto se ele depende de outro objeto que tenha sido apagado ou movido para
outro diretório. No comando do exemplo, serão selecionados e listados todos os objetos corruptos:
ZOMList + p ec
5) ESTRATÉGIAS GERAIS
Garantir que o seu banco de dados permanece livre de corrupção envolve:
� manter cópias de backup de seu banco de dados
� reconhecimento das causas potenciais de corrupção de banco de dados
� determinar uma data ou período para verificar a integridade de seu banco de dados
� saber como verificar seu banco de dados para a corrupção
� saber usar suas cópias de backup para restaurar um banco de dados corrompido.
Zim 8.x – Como Recuperar Uma Base de Dados Corrompida
20
6) INTEGRIDADE E SEGURANÇA DE BANCOS DE DADOS ZIM.
O ZIM inclui um conjunto de comandos que os administradores podem usar para implementar providências de
segurança em suas aplicações. O primeiro nível de segurança é o acesso do usuário, o qual exige que o usuário
se “conecte” com uma identificação e senha. Além do simples acesso à aplicação, podemos estabelecer níveis
de permissão para objetos individuais da base de dados por tipo de operação (isto é, leitura, gravação, etc.) e
tipo de usuário da aplicação (propriétário, grupo e outros). Os níveis de permissão podem ser aplicados a
campos individuais da base de dados, se desejado. Para uma segurança adicional, pode ser especificada a
encriptação do armazenamento físico dos dados no disco.
NOTA: Recomendamos a leitura dos tutoriais : “Transações e controle de locks”
“Config.db Comentado para zim 7.11”.
“Alternativas de segurança em Zim”.