Transações incompletas podem armazenar grande número de bloqueios e causar bloqueio

Quando uma transação não é concluída porque uma consulta expira ou porque o lote é cancelado no meio de uma transação sem emitir uma instrução COMMIT ou ROLLBACK para concluir a transação, a transação é deixada aberta e continuam todos os bloqueios adquiridos durante essa transação a ser mantido. Transações subseqüentes executadas sob a mesma conexão são tratadas como transações aninhadas, para que todos os bloqueios adquiridos nessas transações concluídas não são liberados. Esse problema se repete todas as transações executadas da mesma conexão até que um ROLLBACK é executado. Como resultado, um grande número de bloqueios é mantido, os usuários são bloqueados e as transações são perdidos, que resulta em dados que seja diferentes da esperada.


O exemplo a seguir ilustra como os bloqueios não são liberados como resultado de uma transação aberta incompleta:
Abra o SQL Server Query Analyzer e execute o seguinte lote mas cancelar a transação antes que ela conclua:

Begin Tran
Update autores set state = 'CA'
waitfor delay "00:02:00" --Cancela o comando
Commit Tran

Exibir os bloqueios mantidas pelo executando o seguinte comando:
sp_lock

você verá que os bloqueios são mantidos para a tabela autores .

Da mesmo processo de identificação do servidor (SPID), executar o próximo lote:
Begin Tran
Update tituloautores set au_ord = 0
Commit Tran -  Transação Completa

Exibir os bloqueios mantidas pelo executando o seguinte comando:
sp_lock

você verá que, embora a última transação é concluída, bloqueios são mantidos nas tabelas de autores e títuloautores . O motivo é que a primeira transação não foi concluída e quando a transação segunda foi executada da mesma conexão, ele foi tratado como uma transação aninhada.

Você pode exibir a contagem de transação, verificando @@ trancount variável global emitindo a instrução a seguir:
select @@trancount

esta consulta retorna 1, que indica que uma transação pendente.

Quaisquer outras transações que são executadas a partir desta conexão são tratadas como aninhados. Bloqueios continuar acumular e não são liberados até que um ROLLBACK é executada, quais reversões para a transação mais externa ou para um ponto de salvamento.
Continuar com o exemplo, você pode ver como uma reversão pode causar uma transação a ser negado ao executar a transação a seguir da mesma conexão concluída:

Begin Tran
Update titles set royalty = 0
Rollback

A reversão traz o lote de volta para a transação externa, embora não haja uma transação concluída (2) em títuloautores . A reversão na transação concluída ocorre porque a transação concluída é tratada como uma transação aninhada.

Para evitar esse tipo de problema, verificar após cada transação para saber se a transação foi concluída usando a instrução a seguir:
If @@trancount > 0 rollback

fonte : microsft

abraço a todos ...

The transaction log for database is full - Erro no Sql Server

Erro: Ao tentar utilizar uma aplicação com a base de dados em SQL Server 2005, o usuário encontrava o seguinte erro: “The transaction log for database ‘MyBase’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases ”

Código do erro: 9002

Severity: 17

State: 2

No SQL Server 7.0, no SQL Server 2000 e no SQL Server 2005, marcando a configuração de crescimento automático, arquivos de log podem crescer automaticamente. Apesar do tamanho do LOG estabilizar depois de um período inicial de crescimento, em algumas situações o log pode se tornar muito grande atingindo o espaço em disco disponível. O log pode crescer inesperadamente devido a diversas questões, entre elas:

Transações não comitadas
Transações estremante grandes
Operações como DBCC REINDEX ou CREATE INDEX
Restore a partir de logs de transação
 

Normalmente, você receberá a seguinte mensagem de erro quando o transaction log atingir o espaço em disco disponível e não é possível expandir mais:

The log file for database '%.*ls' is full.

Se você estiver usando o SQL Server 2005 ou 2008,  a mensagem é a mesma que mostrada no início do post.

Solução: Como esta base era utilizada apenas para homologação, resolvi rapidamente truncando o log com o comando BACKUP LOG ‘MyBase’ WITH TRUNCATE_ONLY

Apesar desta solução resolver o problema, é necessário entender que truncar o log, quebra o LOG CHAIN, portanto uma vez que isto é feito, não é mais possível efetuar backup dos logs até que se faça um full ou diif backup da base. Case um backup do log seja tentado, a seguinte mensagem poderá ocorrer:

Msg 4214, Level 16, State 1, Line 1

BACKUP LOG cannot be performed because there is no current database backup.

Msg 3013, Level 16, State 1, Line 1

BACKUP LOG is terminating abnormally.

Abraço a todos ...

Funk do Mortal Kombat (Games)

Para os fãs de games, ai esta o Funk do mortal kombat

abraço a todos ...

Próximo "Dia do Jogo Justo" terá três dias e mais games

Próximo "Dia do Jogo Justo" terá três dias e mais games - Computação Pessoal - IDG Now!: "Criador da iniciativa espera que 2ª edição do evento tenha 'mais impacto' que a anterior, quando foram vendidos 5 mil jogos em um dia.

Após o sucesso da primeira edição, realizada em janeiro, o criador da iniciativa, Moacyr Alves Jr., afirma com convicção ao IDG Now! que o segundo Dia do Jogo Justo “será maior, com mais jogos e mais lojas parceiras”.

Para isso, a próxima edição do evento do projeto que busca reduzir os preços dos games importados no País terá três dias em vez de apenas um. Além disso, os títulos à venda com preço reduzido também superarão os números da original, que trouxe três games em promoção para as plataformas PS3, Xbox 360 e Wii: “PES 2011”, “Castlevania: Lords of Shadow” e “Assassin´s Creed: Brotherhood”.

No total, foram vendidos cinco mil unidades em 12h, já que alguns sites saíram do ar temporariamente em razão da grande demanda, resultando, assim, em uma impressionante média de sete jogos comercializados por minuto."

Fonte : Computação Pessoal - IDG Now!