[firebase-br] Perda de dados 2 dias

[Sandro Souza]

Bom dia/tarde pessoal.

Trabalho com Linux também, e pelo pouco que sei, ele tem suporte a 
sistemas de arquivos com "journaling", ou seja, sistemas de arquivos 
como o reiserfs, ext2, ext3 e outros.

Nesses tipos de sistemas de arquivos, existe o que chamamos de 
"transação de disco", ou seja, o próprio sistema de arquivos funciona 
como um SGBD.

Nesse caso, cada vez que um processo abre um arquivo, é iniciada uma 
nova transação para aquele arquivo.

Quando deletamos um arquivo que ainda está em uso, ele não é deletado 
realmente, pois ainda existe uma "transação aberta" para aquele arquivo, 
e sendo assim, aquela cópia/versão do arquivo ainda permanecerá no 
disco, ocupando espaço, enquanto durar aquela transação (arquivo ainda 
aberto).

Quando criamos um arquivo com o mesmo nome e na mesma pasta, não 
sobrepomos o arquivo anterior, mas sim é utilizada outra área do disco 
para a nova versão daquele arquivo.

O processo que abriu o arquivo antigo ainda enxerga-o como se nada 
tivesse acontecido, como ocorre em uma transação normal.

Os processos que fizerem um novo acesso aquele arquivo (reabrirem), 
acessarão a nova versão do mesmo.

Como vocês já devem ter adivinhado, apenas quando o(s) processo(s) 
fechar(em) o arquivo antigo, encerrando aquela transação, é que aquela 
versão antiga do arquivo é realmente liberada/descartada.

Com esse esquema de transações, tornando um sistema de arquivos em um 
SGBD de arquivos, ganha-se a mesma segurança que temos nas transações 
normais de um SGBD, ou seja, caso um processo esteja criando uma nova 
versão de um arquivo, a versão atual não é modificada de imediato, 
fazendo com que uma nova área do disco seja utilizada para a nova versão 
do arquivo.

Se por acaso, houver queda de energia antes do processo fechar o novo 
arquivo, assim como ocorre em um SGBD, a transação que estava aberta por 
aquele cliente (processo) é desfeita (rollback), e a versão atual do 
arquivo permanece sem qualquer alteração ou perda de dados.

Se o processo conseguir fechar o arquivo, então é feito o commit da 
transação, momento em que a nova versão daquele arquivo passa a ser a 
"oficial", e a versão anterior é descartada caso nenhum processo esteja 
utilizando-a.

Então, não se trata de um "defeito ou bug de linux", mas sim de um 
sistema de proteção inspirado nos SGBDs.

Vale lembrar também que o sistema de arquivos NTFS também tem o seu 
sistema de journaling, e portanto, também tem semelhança nesse ponto 
discutido, mas com certeza o MS Windows tem suas diferenças no 
tratamento dessas situações.

Pessoal, se eu falei besteira, por favor, queiram me corrigir, pois só 
citei o que "senti na prática", mas não sou nenhum expert no assunto. :D

Espero ter ajudado mais que atrapalhado. :D

Carlos H. Cantu escreveu:
> Não é questão de cache ou de RAM, é a forma que o Linux trabalha com
> arquivos.
>
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org
> www.warmboot.com.br - blog.firebase.com.br
>
> AS> Olá,
>
> AS> Teve um caso bastante curioso na lista há algum tempo onde o banco foi
> AS> excluído e continuou sendo acessado, pois estava na memória ram.
>
> AS> Acredito que a única situação onde uma coisa dessas pode acontecer é um
> AS> banco que não utiliza forced writes e tenha um valor para a quantidade de
> AS> transações a ser escrita bem alta, fazendo com que o cache de transações
> AS> pendentes fique bem cheio.
>
> AS> Se estiver falando bobagem, por favor me corrijam.
>
> AS> []'s
> AS> Alexandre Sousa
>
> AS> ----- Original Message ----- 
> AS> From: "Magno System" <magnosysteminformatica em gmail.com>
> AS> To: "FireBase" <lista em firebase.com.br>
> AS> Sent: Monday, December 21, 2009 3:35 PM
> AS> Subject: Re: [firebase-br] Perda de dados 2 dias
>
>
> AS> Josauro, já aconteceu em um cliente com linux a perda de mais de 6 meses de
> AS> informação que ocorreu em uma queda de luz que durou o tempo suficiente para
> AS> o nobreak não aguentar. Isto foi no final de semana, quando chegou a segunda
> AS> feira aquela surpresa. Com certeza não foi o backup restaurado errado, pois
> AS> eu tinha feito neste meio tempo uma atualização na estrutura do banco e se
> AS> tivesse restaurado o backup de 6 meses atrás, a estrutura do banco seria a
> AS> antiga, contudo, eu conferi era a estrutura do banco atual com os dados de 6
> AS> meses atrás.
>
> AS> O que mais me intriga até hoje é que os GENERATORS não estavam
> AS> incrementados, pois se eu tivesse perdido por exemplo 10000 registros o
> AS> generator tinha que estar acima de 10000, mas não, eles estavam na sequência
> AS> certinha (igual ao último registro gravado no banco).
>
> AS> Até hoje não entendi. Será que é possível o linux colocar a estância do
> AS> banco em cache (haja cache) durante 6 meses ???
>
>
> AS> ----- Original Message ----- 
> AS> From: "Josauro S.J." <josauro em casasoft.inf.br>
> AS> To: <lista em firebase.com.br>
> AS> Sent: Monday, December 21, 2009 3:15 PM
> AS> Subject: [firebase-br] Perda de dados 2 dias
>
>
> AS> É possivel em uma reinicialização de um servidor Linux 4GM memoria e
> AS> firebird 2.0.3 haver perda de dados de 2 dias mais o menos 210 tabelas um
> AS> movimento diario bastante expressivo, sem apresentar qualquer problema no
> AS> banco de dados.
>
> AS> A pergunta é pertinente a um banco de dados que voltou ao seu estado de 2
> AS> dias atras, mais provel o retorno errado de um backup. Porem a pergunta é
> AS> valida para tirar duvidas, sobre responsabilidade do DBA.
>
>
>
> AS> ______________________________________________
> AS> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> AS> Para saber como gerenciar/excluir seu cadastro na lista, use:
> AS> http://www.firebase.com.br/fb/artigo.php?id=1107
> AS> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> AS> ______________________________________________
> AS> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> AS> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> AS> http://www.firebase.com.br/fb/artigo.php?id=1107
> AS> Para consultar mensagens antigas: http://firebase.com.br/pesquisa 
>
>
> AS> ______________________________________________
> AS> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> AS> Para saber como gerenciar/excluir seu cadastro na lista, use:
> AS> http://www.firebase.com.br/fb/artigo.php?id=1107
> AS> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>
>