[firebase-br] Perda de dados 2 dias

Marcelo Geyer estanisgeyer em gmail.com
Qua Dez 23 09:58:52 -03 2009


Em resumo, trabalho a 9 anos com Linux e isso é extremamente normal de
ocorrer se o administrador de sistemas não tem conhecimento sobre o sistema
operacional. Se for manipular arquivos, principalmente de banco de dados,
tenha certeza que ninguém está usando o arquivo. No Linux não existe essa de
"O arquivo não pode ser movido ou copiado porque está em uso", você consegue
fazer isso naturalmente.
A regra é: pare o serviço antes de manipular diretamente o arquivo de banco
de dados no Linux.
Fora isso seja feliz.
Para todas as empresas que presto suporte e consultoria, todas estão muito
satisfeitas com o banco de dados rodando em Linux.

Abraços,

Marcelo E. Geyer

2009/12/23 Douglas Silva <forum_firebird em daunebr.com>

> Agora está claro. Isto nao é um defeito do linux e sim uma caracteristica.
> Ou seja, nós que usamos (e amamos) o Firebird precisamos estar atentos a
> esta caracteristica e nao fazer backup nem mexer nos *.fdb da vida sem os
> devidos cuidados.
>
> Aqui vai minha pergunta: usar o nbackup é suficiente ou temos mesmo que
> parar o servidor?
>
> I love this list.
>
>
>
>
> ________________________________
> From: Carlos H. Cantu <listas em warmboot.com.br>
> To: Carlos H. Cantu <listas em warmboot.com.br>; FireBase <
> lista em firebase.com.br>
> Sent: Tue, December 22, 2009 10:46:54 PM
> Subject: Re: [firebase-br] Perda de dados 2 dias
>
> Mais informações:
>
> http://www.ib-aid.com/articles/item70
>
> Disappeared” files on Linux/Unix/HP-UX/...
>
> It is well-known fact that Linux uses the inode mechanism to support
> different file systems. One of the key features of this mechanism is
> the use of cache to handle file descriptors – it means that file
> descriptors are stored both in memory and on disk.
>
> To InterBase and Firebird it brings an onerous side-effect. If you
> replace a database when users are still connected, the server will
> continue to work with the old file, which is wrongly assumed to be
> deleted. The danger here is that, when the last user detaches, the
> server will drop the file forever and the “new” file steps in to
> replace it at that point. You never know it has happened until it is
> too late and then, it is most likely to be discovered by furious
> users: “Where is my work from last week?!”
>
> The longest period of lost data due to such «disappearing» that I have
> observed was 1.5 years. It was a multi-volume database on Linux and
> one of the 4Gb volumes was completely lost.
>
> You may say it is a very rare circumstance but I can stake a case of
> beer on the fact that, right now, at least one hundred server
> installations have this problem. We receive at least one repair
> request due to this problem every two months!
>
> []s
> Carlos H. Cantu
> www.FireBase.com.br - www.firebirdnews.org
> www.warmboot.com.br - blog.firebase.com.br
>
>
> ______________________________________________
> 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
> ______________________________________________
> 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
>



-- 
Marcelo E. Geyer
Standard Net Tecnologia e Informação



Mais detalhes sobre a lista de discussão lista