Fórum INCONSISTENCIA NOS DADOS #414987

É apresentado algum erro quando ocorre a duplicação?

É preciso ver como você está gravando no banco para poder tentar te ajudar.

Precisaria ver o techo do código que executa a gravação e se estiver trabalhando com procedures e gatilhos é preciso detalha-los também.

Qual o nome e a versão da distribuição linux, 32 ou 64 bits, versão da glibc e o tipo de sistema de arquivos ?
Qual a versão do Firebird, 32 ou 64 bits, superserver/classic/superclassic ?
Qual a configuração do servidor (processador/RAM/tipo HD) ?
Qual o tamanho da base de dados e qual o crescimento médio após o processamento intensivo ?

É uma estação fazendo o fechamento dos dados que foram gerados em 50 estações ?
São 50 estações, cada uma fazendo o próprio fechamento, todas simultâneamente ?

Com as informações acima é possível tem uma melhor idéia do cenário e ainda verificar se há bugs conhecidos relacionados a versão do Firebird/versão do Linux.

Se o processamento intensivo que é feito uma vez por mês e resulta em erro, há possibilidade de copiar os arquivos de dados para uma máquina de testes para fazer uma simulação ? Há possibilidade de gravar os comandos emitidos ao Firebird ?

Com a simulação, ao reproduzir o erro já será metade do caminho para a solução.

Abraços,

Anderson:.

- Cenário: Tenho um sistema de controle imobiliário, basicamente controla a imobiliária inteira, menos RH. Feito em Delphi usando DBexpress para conectar no banco Firedird 2.5. Todos meus clientes usam como servidor Windows Server ou XP dependendo o tamanho da imobiliária. Mas meu maior cliente usa um servidor Linux, feito por um fornecedor terceiro deles que configurou o Firebird. Nesse meu maior cliente é onde ocorre os meus problemas, já que as outras imobiliárias não tem nem 10% dos funcionários que esta tem.
Eles tem um backup total do sistema a meia-noite, que salva todos os arquivos do servidor. Também existe um sistema web que faz somente leitura do banco de dados para disponibilizar faturas e recibos no site para os clientes.

-Problema 1: O cliente da baixa no imóvel, pois o mesmo por decisão do proprietário não faz parte do mix da imobiliária. O imóvel recebe o status de “Excluído”, a data de exclusão, e o motivo da exclusão do imóvel. É checado se realmente está excluído e esta ok.
No outro dia, em alguns casos aleatórios e esporádicos, o status do imóvel volta a ser “Vago”, como se não tivesse sido excluído, mas as informações de data da exclusão e motivo permanecem preenchidas com os dados informados.
-Problema 2: Como parte do sistema existe um processo de solicitação de serviço e ordem de serviço, onde qualquer um (inquilino, condômino, proprietário, ou pessoa que tenha cadastro na imobiliária) pode solicitar que a imobiliária efetue serviços gerais com seu mix de prestadores de serviços cadastrados.O funcionamento é o seguinte, é gerado uma solicitação de serviço para ser feito diversos orçamentos pelos prestadores de serviços (como se fosse uma concorrência de licitação com um ganhador), após a aceitação dos termos e valores por parte do solicitante, os prestadores de serviços que ganharem (pode ser mais de um, pois são diversos itens de serviço e cada um tem um prestador) vão efetuar o serviço, e sendo assim o sistema irá gerar uma ordem de serviço.Após o serviço feito é dado baixa na ordem de serviço que vai gerar o pagamento ao fornecedor e o boleto ao solicitante. Neste caso existem dois problemas, se eu deixar para baixar a ordem de serviço no outro dia, alguns casos aleatórios e esporádicos o fornecedor duplica o valor, como se houvesse dois lançamentos iguais para a mesma ordem de serviço, para o mesmo fornecedor (mesmo registro gravado duas vezes). O outro problema também em alguns casos aleatórios e esporádicos, após eu baixar a ordem de serviço e gerar os pagamentos aos fornecedores e a cobrança ao solicitante, no outro dia quando vou olhar a ordem de serviço voltou a ficar aberta, como se nunca tivesse sido efetuada, mas os pagamentos aos fornecedores e a cobrança ao solicitante estão gravados nas tabelas de cobrança do banco de dados.
-Problema 3: Usando IBExpert, eu estava fazendo alterações direto no banco de dados que estava rodando o sistema na imobiliária no momento, colocando alguns campos novos e adicionando os dados padrões para o novo campo e ajustando erros em outros campos. O que ocorria é que colocava os dados padrão na tabela, corrigia os erros nos registros e dava commit, ia na janela de SQL Editor executar um SQL para ver se os dados estavam correto e se estava tudo bem, mas nos registros que fiz correções puxava os dados antigos, como se não tivesse corrigido ou dado commit. Eu ia verificar o registro na tabela e estava correto, mas no SQL Editor estava com os dados antigos, então fui no servidor parei o serviço e iniciei novamente, e voltou ao normal, os dados no SQL Editor começaram a mostrar os mesmos dados da tabela.
-Considerações: Este cliente tem mais ou menos 50 maquinas acessando o sistema no método client-server. E é o único que esta apresentando problemas do gênero. Creio que seja algum problema de configuração do SGBD, mas não tenho conhecimento de como funciona no Linux isso e o terceiro que configurou jura de pés juntos que não é problema no servidor. Mas tenho casos estranhos ocorrendo até mesmo com meu acesso direto ao banco. Se alguém conhecer a solução do problema eu agradeço.

Segue as informações sobre o servidor:

Qual a versão do linux no servidor (Nome da distro e número) ?
[root@diomedes ~]# cat /etc/issue
CentOS release 5.5 (Final)

[root@diomedes ~]# uname -a
Linux diomedes.nostracasa.com.br 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20 EST 2010 x86_64 x86_64 x86_64 GNU/Linux

Qual a versão da glibc no servidor ?
[root@diomedes ~]# rpm -qa | grep glibc
glibc-2.5-49.el5_5.7

Qual a versão do Firebird (2.5.?.?...) ?
[root@diomedes ~]# rpm -qa | grep Firebird
FirebirdSS-2.5.0.26074-0

Qual o modo de execução do Firebird (Classic/SuperServer/SuperClassic) ?
FirebirdSS-2.5.0.26074-0
SuperServer

Servidor Firebird configurado com Forced-Writes ON ou OFF ?

[root@diomedes bin]# ./gstat -z /home/raiz/sisimo/BDSISIMO/SISLOC.FDB

gstat version LI-V2.5.0.26074 Firebird 2.5



Database /home/raiz/sisimo/BDSISIMO/SISLOC.FDB

Database header page information:

Flags 0

Checksum 12345

Generation 7005708

Page size 16384

ODS version 11.0

Oldest transaction 6946737

Oldest active 6948247

Oldest snapshot 6948247

Next transaction 7002378

Bumped transaction 1

Sequence number 0

Next attachment ID 3224122

Implementation ID 16

Shadow count 0

Page buffers 0

Next header page 0

Database dialect 3

Creation date Nov 28, 2010 22:11:50

Attributes force write



Variable header data:

Sweep interval: 20000

*END*




[root@diomedes bin]# ./gstat -z /home/raiz/sisimo/BuscaCEPS/bancodedados/CEP.FDB

gstat version LI-V2.5.0.26074 Firebird 2.5



Database /home/raiz/sisimo/BuscaCEPS/bancodedados/CEP.FDB

Database header page information:

Flags 0

Checksum 12345

Generation 3420171

Page size 16384

ODS version 11.2

Oldest transaction 3419984

Oldest active 3419985

Oldest snapshot 3419985

Next transaction 3419986

Bumped transaction 1

Sequence number 0

Next attachment ID 1738681

Implementation ID 16

Shadow count 0

Page buffers 0

Next header page 0

Database dialect 3

Creation date Dec 3, 2010 15:56:30

Attributes force write



Variable header data:

*END*

Olá Jorge Roberto Trento, sua questão não é fácil de responder, ainda mais estando longe do cenário (por isto este monte de perguntas).

É uma estação fazendo o fechamento dos dados que foram gerados em 50 estações ?
São 50 estações, cada uma fazendo o próprio fechamento, todas simultâneamente ?
Qual a configuração do servidor (processador/RAM/tipo HD) ?
Qual o tamanho da base de dados e qual o crescimento médio após o processamento intensivo ?

Caso seja um fechamento em massa, ou seja uma estação dá a ordem e faz o processamento de todos os registros, poderemos simular um fechamento de mês, pegando os dados do cliente e copiando para uma máquina de testes. Nesta máquina de testes, deleta-se as movimentações resultantes do processamento e faz-se um novo fechamento.

Na impossibilidade de desfazer um fechamento em massa já feito, a solução é copiar os dados do cliente instantes antes realizar o próximo. Anotar os problemas que surgirem após o fechamento para fazer as simulações em máquina de testes.

A versão 2.5.0.26074-0 do Firebird (a primeira da série 2.5) implementou novas funcionalidades e tudo o que é novo esta susceptível a erros (bugs). Um dos bugs (CORE-3137), pode gerar um rollback parcial.

Minha sugestão:

- Identifique o que há de comum entre os registros problemáticos (terminal onde foram gerados, usuário que gerou, data e hora, dados utilizados). Uma sequência de ações incorretas do usuário, dados incompletos ou incorretos podem gerar problemas na gravação (as vezes é uma combinação de fatores).
- Copie os dados para uma máquina de testes e faça uma simulação. O ideal é conseguir reproduzir o erro.
- Se conseguiu reproduzir o erro e não tem origem na sua aplicação e/ou no usuário, então atualize na máquina de testes o Firebird para a versão 2.5.1 que corrige muitos bugs (160 para ser exato). A versão 2.5.2 ainda em desenvolvimento, mas que deverá ser lançada no 2º trimestre de 2012, deverá corrigir outros 65 bugs (ou mais).

Fixes para 2.5.1: http://tracker.firebirdsql.org/browse/CORE/fixforversion/10333
Fixes para 2.5.2: http://tracker.firebirdsql.org/browse/CORE/fixforversion/10450

Se for atualizar a versão do Firebird no cliente, faça testes antes em máquina de desenvolvimento com uma cópia dos dados do cliente (teste todas as ações rotineiras do cliente). Lembre-se, você que resolver um problema e não criar outros.

Considere também a possibilidade de usar a versão Classic Server do Firebird, que embora tenha uma performance menor que a SuperServer, é mais segura para ambientes com muitos terminais acessando os dados (gerenciamento de memória estilo Oracle - vai consumir mais memória, portanto, faça uns cálculos antes). Se a baixa performance tornar-se um problema, há ainda a versão SuperClassic.

Neste link, tem uma explicação bem legal de como funciona cada versão do Firebird e o que é recomendado para cada tipo de cenário: http://www.sinatica.com/blog/br/index.php/artigos/firebird-superserver-classicserver-ou-superclassic


Abraços,

Anderson:.

Em tempo, a versão SuperClassic não é recomentada para o CentOS 5.5 em função da versão da glibc e do bug com o AST, embora há relato de um usuário que tem esta versão rodando nesta plataforma e não tem problemas (a glibc pode estar corrigida nesta distro).

Olá Jorge, alguma novidade ? Conseguiu Resolver ?

Bom Dia

Pois é, migramos todo sistema para o firebird 2.1.4, que foi recomendado por diversas empresas da região por ser mais estavel. Criamos um DB na versão 2.1.4, transferimos a estrutura via sql e os dados via sql, não usamos nem o gbak para ter certeza que os arquivos estavam limpos da versão 2.5;
Porém estou ainda me deparando com problemas, gravo uns dados no banco, eles ficam gravados o dia todo, quando eu volto no outro dia, não estão mais gravados. Durante a noite ocorre o backup como sempre. O firebird agora é 2.1.4 só que agora configurado como classic server, e o linux é o mesmo.
Tem alguma ideia do porque continua ocorrendo isso, se é configuração ou algo assim? Já não sei mais o que fazer.

Estou preparando um server windows 2008, para testar. Com firebird 2.1.4, e configuração default, ja que os dois servers anteriores não foram feitos por mim.

Olá Jorge, chegou a verificar se há algo em comum entre os registros com problema (usuário, data, hora, terminal, ...) ?
Já fez busca sem usar o índice (descartar hipótese de índice corrompido) ?
Chegou a testar a base com a última versão estável do Firebird (v2.1.5.18496-0) ?

Um bug foi corrigido na versão 2.1.5.18496-0 (e também para a versão 2.5.2), que em algumas situações o registro não aparece devido ao fato do índice estar corrompido (mas fazendo uma busca sem utilizar o índice o registro esta lá.

Abraços,

Anderson:.