[firebase-br] Perda de Dados

Rodrigo Gomes da Silva rodrgomes em gmail.com
Sex Nov 1 15:22:08 -03 2013


Isto de arquivo fantasma eu diria que é longe de ser um problema do linux,
e sim um recurso. O windows tem um lock mais rigido e nao permite vc mexer
no arquivo em uso. Não vejo isto como problema no caso relatado, e sim o
fato de pq foi feita a substituição do banco com ele em uso, sem parar o
firebird, ou pelo menos um shutdown naquele banco antes. E mesmo sem parar,
os casos de prb ocorrem apenas em ambientes com conexoes persistentes, pq
ninguem mais vai conseguir abrir uma nova conexão no banco antigo, todas
feitas apos a substituição já seram feitas no banco novo.

Por outro lado, isto no linux permite vc fazer coisas como renomear o
banco, ele continuar funcionando para outras pessoas, e para vc que sabe o
outro nome, mas impedir qq outra conexao. Outro caso foi quando um tecnico
apagou por engano o banco de produção do cliente, mas tinha conexões
abertas. Ai foi possivel por meio do handle da conexão aberta fazer uma
copia do banco apagado, mas ainda não desalocado sem nem ter algum tipo de
corrupção.


Em 31 de outubro de 2013 16:17, Carlos H. Cantu
<listas em warmboot.com.br>escreveu:

> "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!"
>
> http://www.ib-aid.com/articles/item70
>
>



Mais detalhes sobre a lista de discussão lista