DevMedia
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Este é um post disponível para assinantes MVP
Este post também está disponível para assinantes da SQL Magazine DIGITAL
ou para quem possui Créditos DevMedia.

Clique aqui para saber como acessar este post

1) Torne-se um assinante MVP e por apenas R$ 69,90 por mês você terá acesso completo a todos os posts. Assinar MVP

2) Adquira Créditos: comprando R$ 180,00 em créditos esse post custará R$ 1,20. Comprar Créditos

Artigo SQL Magazine 39 - Estratégias de recuperação de “desastres” no Firebird - Principais problemas e como evitar/solucionar

Artigo da Revista SQL Magazine - Edição 39.

[fechar]

Você não gostou da qualidade deste conteúdo?

(opcional) Você poderia comentar o que não lhe agradou?

Confirmo meu voto negativo

Clique aqui para ler todos os artigos desta edição

Estratégias de recuperação de “desastres” no Firebird

Principais problemas e como evitar/solucionar

Numa rápida procura no Google, conversando com alunos e professores de instituições de ensino superior, ou participando de listas de discussões sobre os mais variados assuntos ligados ao desenvolvimento de software ou banco de dados, vemos comumente pessoas reclamando de corrupção de dados com Firebird 1.X. Mas porque isto acontece? Como uma base de dados corrompe? O que são os tão temidos “internal gds software consistency check” e “Database file appears corrupt”? E principalmente: como evitar?

Problemas comuns

Talvez o leitor não acredite, mas o Firebird é um dos SGBDs mais fantásticos que conheço. Isto por que a maioria dos SGBDs disponível no mercado (Oracle, MS SQL Server, DB/2, PostgreSQL) não funcionaria ou suportaria um terço das desventuras que muitos candidatos à DBA em Firebird realizam. Sem maiores rodeios, vejamos as fontes de problemas mais comuns em bases de dados Firebird.

 

Equipamento Precário / Falhas de Hardware

Parece piada, mas há realmente casos de pessoas utilizando Windows 95 com 16 MB de RAM como servidor de rede; pessoas trabalhando há meses (ou anos) sem fazer um backup; ou sequer cogitar a compra de um UPS (no-break); pessoas utilizando jogos 3D no servidor (por ser a melhor máquina, e reiniciando indiscriminadamente ao primeiro sintoma de lentidão ou travamento); pessoas que desligam o cabo do servidor do HUB ou switch porque a internet está lenta (internet compartilhada). Tudo isto enquanto os demais tentam utilizar normalmente o banco de dados.

Isto sem contar aqueles casos de máquinas com memórias de qualidade duvidosa, discos defeituosos, processadores superaquecidos, sistemas operacionais com arquivos corrompidos ou danificados, servidores com vírus, rede mal projetada, HUBS “inteligentes” (de marcas conhecidas por produzirem equipamentos de baixo custo) que travam com um fluxo de dados relativamente baixo, cabos de força, telefone e rede passando na mesma tubulação, etc.

Em resumo, se houver algum hardware problemático, as chances de acontecerem falhas no banco de dados aumentam muito.

 

Alterações em Tabelas de Sistema

Existe um temor que rodeia a alteração de tabelas de sistema. Esta operação, no Firebird, está se tornando natural. Ferramentas como o IBExpert possibilitam operações não suportadas nativamente via SQL (inclusive em alguns momentos “mentindo” para o seu utilizador exibindo comandos que não existem) alterando diretamente as tabelas de sistema sem avisar aos candidatos a DBA (ou vítima, como preferirem) os reais riscos e problemas possíveis. Sendo assim, alterações aparentemente simples para o desenvolvedor e extremamente comuns durante o processo de modelagem e desenvolvimento, como trocar a obrigatoriedade ou não de um campo, podem danificar profundamente uma base de dados.

 

Utilização de versões Snapshot, Alfa, Beta e Release Candidate em produção

Comumente, programadores, analistas e alguns DBAs são pessoas que por necessidade ou simples prazer, precisam estar atentas às novidades e modismos.

Infelizmente, em se tratando de banco de dados open-source, esta prática está se tornando cada vez mais comum. O ciclo de desenvolvimento do Firebird é mais longo do que nós desejamos ou estamos acostumados, fazendo com que empresas realizem previsões que ao término do desenvolvimento da aplicação exista a versão definitiva do banco, e que podem ser obrigados a adiar o produto ou utilizar a versão Beta ou Release Candidate do mesmo.

 

Formas indevidas de Backup

Por mais que teimamos em duvidar, mudanças e acidentes acontecem. Não importa se aquele maravilhoso servidor funciona ininterruptamente durante cinco ou dez anos sem nunca ter tido um problema, mais cedo ou mais tarde certamente vai apresentar problemas ou alguém vai sugerir trocá-"

A exibição deste artigo foi interrompida

Este post está disponível para assinantes MVP.



é tecnólogo em processamento de dados, pós-graduado em banco de dados pela UNOPAR. Aluno de Mestrado em Ciências da Computação - UNIMEP. Desenvolve comercialmente aplicativos desde 1993, e utilizando SGBDs deste 1999. Membro do Te [...]

O que você achou deste post?
Publicidade
Serviços

Mais posts