none
Um transação aberta em um banco de dados, pode indiretamente afetar um outro banco de dados. RRS feed

  • Pergunta

  • Senhores, sei que a pergunta é estúpida, mas é para eu confirmar.....

    Se eu esquecer uma transação aberta (begin tran) em um banco, um outro banco de dados pode ser afetado?

    Exemplo 

    use BancoA
    
    begin tran
    select BancoA.dbo.TabelaA where Id = 1

    Este código pode afetar o BancoB por exemplo? 

    Afetar em qualquer sentido, deixar transações lentas (foi a reclamação que recebi) ou qualquer outra coisa?

    quarta-feira, 30 de outubro de 2013 19:12

Respostas

  • Wesley,

    Pode causar lentidão sim, isto por que as demais consultas que estão aguardando esta transação finalizar vão ocupar a memória destinada ao servidor SQL e a outras consultas de outros bancos de dados. Se o seu servidor SQL tem limitação de memória na instância, o problema de lentidão ficará isolado naquela instância do SQL, caso contrário, todo servidor pode ser afetado.

    Tenha cuidado ao utilizar transações, mas se você tem essa necessidade e ainda tem dúvidas sobre os casos que podem mantem uma transação aberta, utilize o comando abaixo sempre antes de iniciar um comando com transações:

    SET XACT_ABORT ON;

    Espero que seja útil para você.

    Abraços,

    Durval Ramos
     Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    • Marcado como Resposta Wesley Baldan quinta-feira, 31 de outubro de 2013 14:02
    quarta-feira, 30 de outubro de 2013 22:34
    Moderador
  • @Wesley de fato é estranho. Se foi bloqueio, então certamente havia um lock na tabela. Se é lentidão, aí a estória é outra. Recomendo que você solicite maiores explicações, se possível com algum log, hehe. Pessoalmente, sem analisar o ambiente me baseando no cenário, continuo com as ideias das primeiras postagens. 

    Isso foi um evento isolado ou tem alguma frequência? Se for isolado, tenho um forte palpite....

    @Durval, no caso o XACT_ABORT só daria rollback em transações que resultassem em erro, certo? O comando possui outra intenção? Transações com lógica incorreta porém sintaticamente válidas ainda necessitariam de um rollback explícito nesse caso. 

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.


    • Editado Renato Siqueira quinta-feira, 31 de outubro de 2013 01:19
    • Marcado como Resposta Wesley Baldan quinta-feira, 31 de outubro de 2013 14:02
    quinta-feira, 31 de outubro de 2013 01:19

Todas as Respostas

  • Boa tarde,

    Deixar uma transação aberta causa bloqueio (depende de query e dos registros envolvidos) o que onera a rede, que é um recurso compartilhado na instância, então, aqui, existe overhead.

    OU

    Pode afetar se existe alguma relação entre os objetos envolvidos na transação do BancoA com objetos no BancoB. Por exemplo, BancoA tem ViewA que referencia Tabela B no banco B.  Se abrirem uma transação no BancoA de update direto na view, por exemplo, a tabela B (referenciada pela View A) recebe um bloqueio (assim como a view) exclusivo e aí fica lento/inacessível até que aquela transação termine.

    OU

    O que pode estar prejudicando o desempenho do banco sejam consultas onerosas.

    Mas, cada caso é um caso... Qualquer coisa, passe mais detalhes que a gente tenta ajudar.

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.

    quarta-feira, 30 de outubro de 2013 20:31
  • @Renato Siqueira...... É como está o exemplo, simples daquele jeito.. Não há nenhum vinculo com o outro BD, e o outro BD não se utiliza das tabelas envolvidas na transação... Aliás, o outro BD não tem nenhum vínculo com o BancoA. O único vínculo é que estão no mesmo HD e na mesma instância.

    aliás, o comando correto é

    use BancoA
    
    begin tran
    update BancoA.dbo.TabelaA 
     set Descricao = 'XPTO'
    where Id = 1

    É bem simples mesmo... 

    quarta-feira, 30 de outubro de 2013 20:40
  • @Wesley

    Opa, comando simples. Esse update numa transação aberta até ser fechada causa bloqueio exclusivo (conforme citado acima), então, isso explica bloqueios mas que referenciem o objeto em questão (o que não é o caso, certo?).

    Nesse caso, avaliando por fora, a lentidão parece estar na rede, ou até mesmo do próprio servidor que hospeda a instância. Esse servidor é sobrecarregado? Qual a versão e edição do SQL Server? Dependendo, o problema pode estar na infraestrutura do servidor.

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.

    quarta-feira, 30 de outubro de 2013 21:01
  • @Renato Siqueira é que sei lá né, achei o questionamento tão estúpido deste comando bloquear outro database, que por um instante eu achei o cara mais tolo da terra. Por isso que mandei a pergunta.....

    Juro que eu faria um curso básico de SQL, pq se aquele comando bloqueasse outro BD, eu realmente não sabia mais nada de SQL, nem os princípios básicos. 

    SQL 2008.. não sei te dizer, pq eu tenho acesso as infos do outro BD. 

    Eu juro para vc, tive uma crise quando fui questionado sobre isso.

    quarta-feira, 30 de outubro de 2013 21:16
  • Wesley,

    Pode causar lentidão sim, isto por que as demais consultas que estão aguardando esta transação finalizar vão ocupar a memória destinada ao servidor SQL e a outras consultas de outros bancos de dados. Se o seu servidor SQL tem limitação de memória na instância, o problema de lentidão ficará isolado naquela instância do SQL, caso contrário, todo servidor pode ser afetado.

    Tenha cuidado ao utilizar transações, mas se você tem essa necessidade e ainda tem dúvidas sobre os casos que podem mantem uma transação aberta, utilize o comando abaixo sempre antes de iniciar um comando com transações:

    SET XACT_ABORT ON;

    Espero que seja útil para você.

    Abraços,

    Durval Ramos
     Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    • Marcado como Resposta Wesley Baldan quinta-feira, 31 de outubro de 2013 14:02
    quarta-feira, 30 de outubro de 2013 22:34
    Moderador
  • @Wesley de fato é estranho. Se foi bloqueio, então certamente havia um lock na tabela. Se é lentidão, aí a estória é outra. Recomendo que você solicite maiores explicações, se possível com algum log, hehe. Pessoalmente, sem analisar o ambiente me baseando no cenário, continuo com as ideias das primeiras postagens. 

    Isso foi um evento isolado ou tem alguma frequência? Se for isolado, tenho um forte palpite....

    @Durval, no caso o XACT_ABORT só daria rollback em transações que resultassem em erro, certo? O comando possui outra intenção? Transações com lógica incorreta porém sintaticamente válidas ainda necessitariam de um rollback explícito nesse caso. 

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.


    • Editado Renato Siqueira quinta-feira, 31 de outubro de 2013 01:19
    • Marcado como Resposta Wesley Baldan quinta-feira, 31 de outubro de 2013 14:02
    quinta-feira, 31 de outubro de 2013 01:19
  • @Renato foi um evento isolado. Com a resposta do @Durval, fui analisar se o comando do begin tran poderia causar uma espécie de fila de espera, mas como o comando é um update em registro específico, não acredito que ficou comandos em espera por esta transação. E esta tabela  na aplicação não há comando para capturar todos os registros ou um filtro que retorne um lote... Esta tabela é tipo um rastreio de operações. No máximo, poderia ter uns 4 ou 5 registros de fila de espera.....isto se o usuário for rastrear seus dados, o que não é muito comum.

    Acredito que ou o problema é o comando da outra equipe ou uma lentidão. Temos vários bancos na mesma instância e apenas um apresentou lentidão. Nem o banco onde foi deixada a transação aberta estava lento.

    Bom, obrigado a todos pelo suporte.


    quinta-feira, 31 de outubro de 2013 13:09
  • @Wesley, então beleza, o bloqueio é de linha, se outra transação não ler tal registro deve funcionar.

    Bem, nesse caso, desejo sucesso ao verificar o comando da outra equipe. Qualquer coisa conta pra gente se conseguiu identificar com precisão a raíz problema.

    []'s


    Se a resposta ajudou, classifique e ajude outros membros da comunidade.

    quinta-feira, 31 de outubro de 2013 13:55
  • Renato,

    XACT_ABORT executa o ROLLBACK, implícitamente, sempre que ocorrer um erro, seja de sintaxe ou caso algum objeto (view, tabela, function,...) deixar de existir. Todos os comandos válidos até o momento do erro serão descartados.

    O COMMIT TRAN continua sendo necessário, explicitamente, para cada transação aberta no contexto da execução.

    Para maiores informações sobre o uso de XACT_ABORT, consulte http://technet.microsoft.com/pt-br/library/ms188792.aspx

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 31 de outubro de 2013 17:01
    Moderador