Firebird e InterBase razões corrupções

Erros de hardware relacionados

desligamento anormal

desligamentos anormais são a principal causa da corrupção. Elas podem

ser causadas pela perda de energia em um computador sem UPS quando
uma toupeira grande mutante come a cabo a sua cidade, fonte de
alimentação (ou qualquer outra explicação a sua empresa de energia
pode dar), ou a senhora da limpeza retira o "cabo" errado durante a
limpeza do seu escritório . Às vezes as pessoas só poder desligar seus
computadores sem a preocupação de que a máquina poderá ser
contratado dentro Qualquer uma destas condições podem levar à
corrupção.
No entanto, você provavelmente já observou que nem todos os
desligamento anormal leva à corrupção. O projeto inicial do IB foi, com
algumas restrições, perdoando-vos para tais ambientes instáveis. Como
você deve saber, as versões anteriores do IB foram utilizadas no sistema
de controle de incêndio da plataforma de artilharia MLRPS. Cada rajada de
MPLRS foi acompanhado por um forte impulso eletromagnético,
provocando o reboot computerto a bordo de cada vez. Foi uma forte
exigência de que o servidor de banco de dados on-board ser capaz de
recarregar em segundos ser robusto contra o potencial de corrupção
causados pelo corte de energia. InterBase equipado duas condições: que
começou de forma rápida e sua arquitetura multi-geração tornou capaz
de contornar ou mesmo não confirmadas corrompido versões de
registros, e manter a sua capacidade de ler bons registros.
Mas o tempo passa. Em versões posteriores avançado cache foi
implementado e "civil" versões "InterBase tornou-se mais vulnerável no
encerramento anormal. O problema mais conhecido é relacionado com
Forced Writes no Windows. Forçado escreve é uma bandeira, definido no
arquivo de banco de dados, que determina o comportamento de cache do
Windows para este arquivo. Recomendamos vivamente Forced Writes
configuração no Windows para ON, porque o Windows é muito
"preguiçoso" sobre a liberação de seu esconderijo e poderia estar
segurando dias de trabalho pálido.

Light corrupção HDD

Light corrupção de um disco rígido que acontece quando apenas alguns

conjuntos corrompido. Normalmente, o sistema operacional avisa que o
arquivo está ilegível. O efeito da corrupção é tal que o arquivo de banco
de dados tem várias lacunas dentro dela que são preenchidos com zeros
ou, ocasionalmente, informações de lixo. As lacunas quebrar a estrutura
interna do banco de dados, que podem dar origem a uma ampla gama de
possíveis erros.

Heavy HDD corruption4

Às vezes, o disco rígido pode quebrar em uma pilha completamente

ilegível de metal e plástico. Neste caso, você tem duas opções, a primeira
das quais é tentar reparar a unidade danificada com uma utilitiy especiais
como o R-Studio (http://www.data-recovery-software.net/)
Se isso não ajudar, você pode contar com a ajuda de um serviço de
recuperação de disco rígido. Esses caras podem realmente buscar os
dados da quarta dimensão. Dois problemas estão aqui: primeiro, os
honorários são muito grandes (a partir de USD $ 1000), o que significa
que você tem que pesar que custam até contra a sua estimativa do valor
dos dados perdidos antes de requisitar o serviço. Em segundo lugar, os
dados recuperados são quase sempre misturado - por isso, quero dizer
que as cadeias de clusters são organizados de maneiras que diferem do
banco de dados original.

CD / DVD corrupção

Se você armazena dados em CDs ou DVDs - para fins de arquivamento ou

como um banco de dados read-only dicionário - eles podem quebrar.
Normalmente a exibição de corrupção é que você não pode ler o arquivo
de banco de dados do DVD.
A primeira coisa a fazer é extrair o arquivo corrompido do DVD com
algumas ferramentas como FixDVD!
Infelizmente, em 99% dos casos, um banco de dados de arquivo extraído
de um DVD está em mau estado: o arquivo extraído é o tamanho certo,
mas ele é preenchido com uma mistura de páginas de banco de dados e
de lixo / zero de dados.
A maneira mais acessível ao extrair arquivos de dados de DVD é criar
uma imagem de todo o DVD (4.7GB) e olhar para as páginas do banco de
dados nesta área.

Flash Drive corrupção

Flash drive é uma tecnologia bastante recente, com algumas limitações

na contagem de leitura / gravação ciclos. As primeiras versões eram
incapazes de sustentar até um milhão de ciclos, mas o problema parece
ter desaparecido como a tecnologia evoluiu. No entanto, não posso
recomendar drives flash para uso diário como o armazenamento de dados
principal para um banco de dados Firebird ou Interbase.
O trabalho de um servidor de banco de dados envolve ler muitos / as
operações de gravação no modo de acesso aleatório. Nós seguramos
vários bancos de dados corrompidos que vivem em unidades flash cujos
usuários não foram suficientemente prudentes para back-up. Corrupções
são semelhantes à luz corrupções HDD - várias peças do banco de dados
de arquivos perdidos.

corrupção RAM

Entre todas as corrupções hardware, corrupção RAM é o pesadelo real.

Em geral, é a sorte que a corrupção RAM torna-se aparente com uma
BSOD (Blue Screen Of Death) ou outros eventos críticos, que pode ser
facilmente detectado pelo administrador do sistema. Mas às vezes a
corrupção RAM é tão pequena que só ferramentas especiais pode detectá-
lo e mostra seus dentes apenas durante a utilização intensiva.
Quando ocorrer outras corrupções hardware, é ao nível da página do
banco de dados. páginas inteiras são perdidas enquanto outras páginas
estão intactas. O problema torna-se corrompido quando RAM é que
qualquer pedaço de arquivo de banco de dados pode ser alterado de
forma intermitente 0-1, ou vice-versa. Este tipo de corrupção só é
reconhecível após o fato: ele aparece somente quando alguma página de
dados tornaram-se suficientemente corrompidos para disparar um erro.
Assim, a corrupção RAM é escondido até que o nível de dano torna-se
crítica. Uma vez eu vi um par de bases de dados a partir de um único
servidor com RAM danificada. O cliente enviou-os um por um, com
corrupções várias, antes de pedi-lhe que me envie o interbase.log. Lá, vi
vários erros de comprimento de registro errada, tipo de página errado e
até mesmo vários erros esotérico. Nós testamos a memória RAM com o
memtest ferramenta e encontrei problemas de RAM.
Um outro problema com a corrupção exibida RAM é que a tentativa de
validar o banco de dados com gfix no computador com a RAM pode
produzir resultados diferentes cada vez que executá-lo. Pior ainda, o
trabalho de consertar gfix, que tenta corrigir os erros, pode produzir
corrupção adicionais do banco de dados, pois as visitas a cada página
banco de dados e, por escrito, "remendadas" páginas, pode estabelecer
errado mais bits.

Falta de espaço em disco para o banco de dados

Running out of espaço em disco favorito é o erro de administradores

preguiçosos. A corrupção acontece quando o servidor tenta pedir mais
páginas para alargar o arquivo de banco e descobre que não há espaço
disponível no disco ou partição.
A situação mais perigosa quando ocorre falta de espaço em disco é
combinada com um cache grande e forçada escreve fora. O sistema
operacional tenta descarregar uma grande quantidade de dados em disco
e simplesmente não se não houver espaço suficiente. Neste caso, o banco
de dados será inconsistente, pois a perda do cache significa que todas as
alterações na página e cadeias de registro foram interrompidas.
Quando você tentar reparar dano causado por falta de espaço em disco
com GFIX você pode achar interessante efeito colateral: a interbase.log
será preenchido com uma seqüência de loop de página "duplamente
alocados" erros. Gfix nunca vai acabar, o interbase.log pode crescer muito
grande espaço em disco e podem ser esgotados novamente.

Falta de espaço em disco para arquivos temporários

Se você não tiver espaço em disco configurado para Interbase ou Firebird

a ser usado para armazenar os arquivos temporários que cria para
triagem e operações de fusão, o motor vai usar o diretório especificado no
sistema variável TEMP. Se uma consulta pesada milhões de linhas para
classificar, o tamanho total dos arquivos temporários podem ser muito
grandes. Se as consultas com vários tipos estão em execução, que pode
ocupar muito espaço e esgotamento de espaço livre torna-se uma
possibilidade. Geralmente, essas condições são tratadas corretamente e
que o cliente consulta lançada recebe uma mensagem de erro.
O engraçado é que, em versões antigas do InterBase e Firebird, o texto
foi erro "Sem papel na impressora" devido a uma atribuição errada de
que a mensagem de exceção para o código de erro do sistema Windows.
Mas pode acontecer que a falta de espaço em disco para arquivos
temporários leva à cessação do servidor anormal e corrupção de bases de
dados, especialmente com uma versão anterior do InterBase / Firebird.

Falta de espaço em disco para interbase.log ou firebird.log

Se você não prestar atenção a quantidade de espaço livre na partição

onde o InterBase ou Firebird está instalado, você pode executar fora de
espaço livre lá quando o interbase.log ou firebird.log arquivo cresce muito
grande. Todos os erros em todas as bases de dados no servidor é escrito
para o mesmo arquivo de log para que possam correr para o problema se
você tem um monte de erros de rede, tais como:
My_server (Server) Sat 02 janeiro 2006 15:14:57
INET inet_error /: read errno = 10054
Agora, você pode muito bem supor que esses erros são bastante raras e,
com aplicações bem concebida, nunca deve aparecer. Enquanto isso é
verdade, existem muitos casos onde o espaço livre não se esgota pelo
arquivo de log soprar.
É simples encontrar um exemplo. Imagine que você tem corrupção luz de
um índice em um banco de dados bastante grande e você decidir executar
gfix para corrigi-lo. O que acontece aqui é que o motor marca o índice
corrompido como errado, libera todas as suas páginas e registra a
mensagem "Página" XXX órfãos. Com um índice grande o suficiente, você
vai receber milhares de mensagens deste tipo no arquivo de log que
podem facilmente consumir todo o espaço livre disponível e levar à
corrupção muito mais pesado.
Corrupções causadas por negligência de manutenção

banco de dados acidentalmente suprimidos arquivo

Às vezes, um arquivo de banco de dados podem ser apagados

acidentalmente. Em versões anteriores ao Firebird 1.0 e Interbase 7.0, foi
possível excluir um arquivo de dados mesmo que fosse aberto, ou seja,
durante o I activa operações E / S. O servidor abriu o arquivo de banco de
dados com a bandeira fmShareDenyNone (0x40), para qualquer processo
foi capaz de modificar e apagar.
Mesmo com as versões mais recentes não há garantia de que um arquivo
de banco de dados não ser excluído enquanto o servidor está desligado ou
sem conexões estão ativas. Geralmente isso acontece quando o banco de
dados foi feito backup ou copiado para outro local e é considerado
erradamente que o banco de dados original pode ser excluído. Se o
backup falhou ou o arquivo de destino foi danificado durante a cópia do
arquivo, temos uma situação de arquivo que foi excluído do banco de
dados.
A coisa mais urgente e imediata a fazer é parar toda a atividade no banco
de dados do disco onde estava situado. Se for um disco do sistema,
desligar o computador e voltar a montar o disco como secundário para
evitar que ele escreve.
Em seguida, você precisa encontrar algum software para restaurar
arquivos. Para Windows e Linux, há muitas utilidades e how-to de guias
para recuperar e reparar arquivos. Alguns deles estão listados abaixo:
http://www.stud.tu-ilmenau.de/ ~ mojo / undelete.html
http://recover.sourceforge.net/linux/
http://home.fnal.gov/ Muzaffar ~ Undelete / README.html
Se não escreve ter sido feito ao longo dos sectores arquivo que foi
excluído, você tem uma boa chance de recuperar o arquivo excluído,
talvez até incólume e viável. Normalmente, porém, algumas partes estão
perdidas e esforço de recuperação adicional é necessária.

Disappeared "arquivos em Linux / Unix / HP-UX / ...

É fato bem conhecido que o Linux usa o inode mecanismo para apoiar os
sistemas de arquivos diferentes. Uma das principais características deste
mecanismo é o uso de cache para manipular descritores de arquivo - isso
significa que os descritores de arquivo são armazenadas na memória e no
disco.
Para InterBase e Firebird que traz uma pesada efeito colateral. Se você
substituir um banco de dados quando os usuários ainda estão ligados, o
servidor continuará a trabalhar com o arquivo antigo, que é erradamente
assumido a ser excluído. O perigo aqui é que, quando o usuário destaca
passado, o servidor irá soltar o arquivo para sempre e os "novos passos"
no processo para substituí-lo nesse momento. Você nunca sabe o que
aconteceu até que seja demasiado tarde e, então, é mais provável de ser
descoberto por usuários furiosa: "Onde está o meu trabalho da semana
passada?"
O maior período de perda de dados devido a «tal desaparecimento» que
tenho observado foi de 1,5 anos. Foi um banco de dados multi-volume em
Linux e um dos volumes 4Gb foi completamente perdido.
Você pode dizer que é uma circunstância muito rara, mas eu jogo em um
caixa de cerveja no fato de que, agora, as instalações, pelo menos, cem
servidor tem esse problema. Recebemos pelo menos um pedido de
reparação devido a este problema de dois em dois meses!

Limites de aplicação errada

36.6Gb limite de tamanho de tabela

Trabalhar no incidente de suporte técnico interessante com um de nossos

clientes, observamos que o número máximo de linhas real difere do limite
declarado.
No conjunto de documentação [Guia de Operações para InterBase 6,
página 27, InterBase Specification] podemos ler o seguinte:
"O número máximo de linhas e colunas por tabela: Pelo projeto, 2 ^ 32
linhas, porque as linhas são enumeradas com um inteiro de 32 bits sem
sinal por tabela".
Naturalmente, as linhas enumeradas por inteiro de 32 bits. Triste, mas na
verdade nunca mesa não pode chegar a 2 bilhões de registros limite -
mesmo a tabela com apenas uma coluna.
A razão de tal comportamento é no algoritmo de cálculo de espaço livre
para os novos (inserida) recorde - o integer overflow pode ocorrer e você
verá a seguinte mensagem de erro interbase.log:
página ponteiro desapareceu DPM_next (249)
E, a realidade é que o tamanho da página do banco de dados ou tamanho
da linha não afeta esse limite. O limite é de um tamanho de tabela mágica
que é sempre o mesmo (~ 36,6 gigabytes) e pode ser calculado em
páginas de qualquer tamanho de página do banco de dados como:
Máximo número de páginas para uma tabela pode ser calculado como
MaxDataPageCount = (MaxInt / PageSize) * 17.476
MAXINT, naturalmente, = 2147483647. Coloque o tamanho da página do
banco de dados, em vez de PageSize eo resultado mostra o quanto as
páginas podem ser alocados para qualquer tabela
Por exemplo, a tabela não pode ter mais ~ 9 milhões de páginas de dados
no banco de dados com tamanho de página de 4K.
Do ponto de vista da contagem de registro, tabela com duas colunas
inteiro não pode crescer mais do que 600 milhões (!) Registros (não se
esqueça de que cada registro tem 14 bytes de cabeçalho).
Confuso? Multiplique por MaxDataPageCount PageSize, e dividir o seu
maior resultado com tabela de tamanho recorde média - você sabe
quando esta tabela poderá ultrapassar o limite e seu banco de dados irá
parar de funcionar.
Esse limite foi fixado apenas no Firebird 2. Ainda existe no InterBase
2007.
Além disso: o outro lado deste limite foi descoberto recentemente no
coletor de lixo execução discussão no Firebird 2.0.3: esse erro pode
aparecer em 36.6Gb tabelas durante a coleta de lixo (é causada pela
combinação de condições especiais). Esperamos que isso será corrigido na
próxima sub-release 2.0.4 e em 2.1, com certeza.

BLOB restrições de tamanho máximo

mecanismo BLOBs tem imperfeição implementações. Em versões

anteriores do IB (até 7.1) era de 512Mb, então foi fixado até 2Gb.
Atualmente temos informações sobre imagens de DVD (4.7GB), que
foram armazenados em Firebird 2.0.3. Enfim, não recomendamos para
armazenar arquivos grandes (> 100Mb) dentro Firebird ou InterBase até
que seja absolutamente necessário (neste caso, é recomendável para
testar os limites em primeiro lugar).

Muitas transações no IB pré versões 6,5

InterBase em pré 6,5 versões tem um limite máximo de números de

transação (depende do tamanho da página), até que restaurar (após o
backup / restore operações recomeçar do zero).
número crítico de operações no pré 6,5 servidores InterBase
Banco de
dados de número de transações
tamanho de críticas
página
1024 bytes 131 596 287
2048 bytes 265 814 016
4096 bytes 534 249 472
8192 bytes 1071120384

Muitos geradores

Para InterBase com as versões 6.0.1.6 menos nós temos um limite de

mais errado: o número máximo de geradores no banco de dados
(depende do tamanho da página).
número crítico de geradores em versões anteriores do Interbase
Page size = Page size = Page size = Page size =
Versão
1024 2048 4096 8192
Para 6 248 504 1016 2040
6.0.x 124 257 508 1020
Corrupções causadas por SQL

Criando e destruindo tabelas durante o trabalho de utilizadores

intensivos "

Bem, é o topo da maior parte das vezes as formas de banco de dados

corrompido. Criando e destruindo tabelas enquanto os usuários estão
escrevendo algo no banco de dados pode levar à confusão entre as
páginas do sistema (usado por criados / caiu tabelas) e dados do usuário.
Normalmente essas corrupções leva à perda moderada de dados e podem
ser recuperados usando o serviço IBSurgeon manual.