[firebase-br] Perda de dados 2 dias

Magno System magnosysteminformatica em gmail.com
Qua Dez 23 10:49:50 -03 2009


Um processo bem arroz com feijão e básico é o seguinte.

1 - Mexa o que tem de mexer no banco (exclua, renomeie, etc...).

2 - Reinicie o servidor.

3 - Confira alguma informação no banco que confirme que os dados estão OK.

Agora pessoal, o meu ponto de vista. Sei que isso não é um bug no linux. Sei 
também que o linux é um excelente servidor. Agora eu queria saber qual a 
real vantagem de poder mexer em arquivo com ele em uso? Porque ao meu ver a 
desvantagem é imensa, dados os casos apresentados. Eu sei, que é por falta 
de conhecimento, mas a minha lógica é a seguinte. Se o LINUX permite uma 
operação que POR DESCONHECIMENTO DO USUÁRIO pode causar danos irreparáveis, 
é porque em algum aspecto deve haver uma grande vantagem alterar arquivos em 
uso.

Você como programador, se existe uma operação no seu software que se o 
usuário fizer em determinado momento, vai causar danos irreparáveis no 
sistema, e você como programador, tem consciência disto, o mais correto não 
seria você bloquear esta operação, ou no mínimo, notificar o usuário ? Aí 
você pode me dizer que isto é uma característica do seu software e não um 
bug. Contanto existe um outro software paralelo que bloqueia e não deixa o 
usuário cometer o erro. Ao meu ver, este outro software, NESTE QUESITO, é 
mais seguro.

Queria deixar claro que sou muito fã do LINUX e estou analisando SOMENTE 
ESTE QUESITO de alterar arquivo em uso.




----- Original Message ----- 
From: "Marcelo Geyer" <estanisgeyer em gmail.com>
To: "FireBase" <lista em firebase.com.br>
Sent: Wednesday, December 23, 2009 9:58 AM
Subject: Re: [firebase-br] Perda de dados 2 dias


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
______________________________________________
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 





Mais detalhes sobre a lista de discussão lista