locked
Perda de dados RRS feed

  • Pergunta

  • Boa tarde a todos.

    Gostaria de obter ajuda para solucionar problema sério que vem ocorrendo com minha base de dados armazenada no sql server 2000.

    Temos um aplicativo desenvolvido internamente que se utiliza exclusivamente de procedures armazenadas no sql (este é o cenário - a grosso modo).

    O aplicativo vem funcionando normalmente, no entanto vem ocorrendo perda de dados no sql e retrocesso de alteração de dados. Exemplo: O usuário lança uma série de dados, finaliza determinadas operações(liberação de pedido, por exemplo) e depois de algumas horas o pedido nao esta liberado, alguns registros do banco de dados simplesmente não estao mais la.

     Minha pergunta é: O que verificar no SQL e como fazer isso?

    SQL profiler ???

    EventView ???

    Locks ????

    Se alguém tiver uma idéia, por favor me responda.

     

    Flávio

     

     

    sábado, 2 de dezembro de 2006 15:51

Todas as Respostas

  •  

     Flavia...

          Os motivos de perda de dados devem está relacionados a falta de COMMIT TRAN na procedure, verifique se as procedures possuem BEGIN TRANSACTION, COMMIT TRANSACTION, se os dados não forem commitados no banco, eles só valem para a sessão que iniciou a transação.

          Você pode monitorar pelo Profile, e verificar se a procedure está executando um COMMIT ou ROLLBACK.

     

    domingo, 3 de dezembro de 2006 17:49
  • vc ja procurou se se existe alguma trigger nas tabelas, outra pegunta essa base esta replicada ?
    segunda-feira, 4 de dezembro de 2006 09:16
  • Flávio,

    O EventView, você deve utilizar para obter as mensagens de erro geradas pelo sistema.

    No caso o Profiler com certeza seria a melhor ferramenta para monitor estas procedures, mas tem um dúvida, você já chegou a observar se o log do seu SQL Server não esta cheio?

     

    segunda-feira, 4 de dezembro de 2006 12:23
    Moderador
  • Flavia,

    Complementando o comentario dos colegas, em que ferramenta foi desenvolvido este aplicativo interno de voces?

    Normalmente situações como esta estao relacionadas a problema de falta de commit em transacoes abertas. E ai é importante saber em que ferramenta o aplicativo foi desenvolvido, pois alem do controle de transacoes nas procedures mencionado pelo Rafael, voce pode ter tambem transacoes implicitas iniciadas pelo aplicativo e ai se voce nao realiza o commit pelo aplicativo, os dados nao sao gravados (mensmo que voce tenha o begin e o commit na procedure).

    Caso o controle de trasacoes esteja correto (tanto nas procedures quanto no aplicativo) ai entao o problema pode ser o mencionado pelo Marcelo Colla, alguma trigger que esta alterando dados de modo incorreto ou dados sendo sobrescritos por replicacao...

    O profiler é uma boa ferramenta para voce identificar a origem desse problema...

    Abs

    segunda-feira, 4 de dezembro de 2006 12:24
  • Rafaela,

    é o seguinte: Me parece ser o mais lógico, mas hoje eu revisei as 90 e poucas procedures armazenadas e não encontrei um begin tran sem commit e rollback sendo controlado.

    segunda-feira, 4 de dezembro de 2006 13:52
  • Não existe triggers. Estou analisando a questão do controle da transação, me parece ser o mais logico, mas esta dificil chegar uma conclusão.

    O tamanho do arquivo transaction LOG é fator importante para esse problema???

    segunda-feira, 4 de dezembro de 2006 13:54
  • Cristiana,

    O aplicativo foi escrito em Delphi e não controlamos transações por ele, para insert/update/delete fazemos apenas referencia as procedures armazenadas deixado o controle da transação para o servidor.

    Usei o profile, mas retardou consideravelmente o desempenho do aplicativo. Estou tentando filtrar ou restringir o profile.

     

     

    Obrigado

     

    segunda-feira, 4 de dezembro de 2006 13:58
  • Pois é. Isto esta me deixando preocupado. O arquivo transaction Log esta com o volume considerável.

    O MDF com 400 MB

    LOG com 2 GB

    Ta normal?

     

    segunda-feira, 4 de dezembro de 2006 14:02
  • Flavio,

    Como é que esta a configuracao de transacoes implicitas no Delphi?

    Normalmente o Delphi trabalha com o ImplicitTransactions = ON o que significa que ele cria transacao implicita para tudo que é feito no banco. O problema para esta configuracao é que se vc nao realiza o commit depois que houve alguma alteracao de dados pelo usuario, os dados podem ser perdidos, exatamente como voce mencionou que esta acontecendo...

    Abs.

    segunda-feira, 4 de dezembro de 2006 19:23
  • Cristiano,

    É o seguinte: Não examinei ainda a configuração no delphi. Apenas confirmo que estou usando o modo default de isolamento "ready commited";

    A configuração que voçe me diz é "setada" nos parâmetros (ADOConnection) de conexão?

    Confirmando, eu uso o objeto ADOProcedure mais ou menos assim:

    1.Cria ADOProcedure

    2."Seta" os parâmetros de conexão

    3.Passa os parâmetros definidos na SP

    4.Executa

    5.Testa o retorno (habitualmente eu uso o return(0) na SP para considerar sucesso na execução

    PS) Estou chegando a conclusão que não é na aplicação o problema e sim no Banco de Dados, especificamente em alguma procedure armazenada. Revisei as SPs e encontrei alguns problemas como:

    Uma sp chamando outra. Na qual a primeira ja estava transacionada(begin tran/commit/rollback) e a outra (a chamada) tambem estava transacionada. E os commits e rollbacks nao explicitava qual transacao deveria ser tratada.

    Não sei, mas estou trabalhando nisso. Agradeço imensamente a colaboração que voçe (e todos) vêm me dando.

    Fico a disposição para dividir experiências.

    Obrigado

    qualquer novidade post aqui e se tiver mais algumas sugestões agradeço

     

    segunda-feira, 4 de dezembro de 2006 21:54
  • Flavio,

    Sobre o log de transacao do banco do 2GB, voce deve estar trabalhando com seu banco no recovery model full ou bulk-load. Estes modos de recovery normalmente sao utilizados quando voce precisa voltar o backup do banco em um determinado dia e horário diferente do dia e horario que voce fez o backup full. Se o backup full ja atende sua necessidade de backup diario altere o recovery model para simple. Ou entao faca um backup do log de transacao. Com isso seu arquivo de log vai ficar com pouco espaco utilizado e voce pode diminuir o tamanho fazendo um Shrink. Normalmente os arquivos de log de um banco ficam com cerca de 20% do tamanho do MDF.

    Abs.

    terça-feira, 5 de dezembro de 2006 16:23
  • Flavio,

    A configuracao do ADO é AUTOCOMMIT. Se estiver definido como ON, a cada comando que é enviado um begin e um commit tambem é enviado. Se estiver definido como OFF, ai voce tem que colocar os COMMITs para que as alteracoes sejam gravadas.

    De qualquer modo, a revisao das procs que chamam outras com transacao entre elas é um item importate. Qualquer coisa retorne.

    abs.

    terça-feira, 5 de dezembro de 2006 16:36
  • Obrigado, acho que vou fazer isso.

    O que me preocupa quanta a essa instabilidade que relatei no primeiro "post" é que a perda de dados se generaliza para tabelas que nada tem a ver com os procedimentos que são realizados a noite (quando o problema é percebido); ou seja a única coisa em comum e de fato é que a perda de dados ocorre para "TODOS" os registros (insert, update e delete) feitos no DIA.

    Continuo a observar.

     

    Obrigado

    Flavio

     

    quarta-feira, 6 de dezembro de 2006 14:48