Usando o SQL Server 2008 R2:
Como posso gravar no log de erros do SQL Server? Eu tenho uma instrução ROLLBACK que gostaria de associar a uma instrução gravada no log de erros para monitoramento externo.
Exemplo:
BEGIN TRAN
INSERT INTO table1
SELECT *
FROM table2
IF @@ERROR <> 0
BEGIN
ROLLBACK TRAN
--Write to log
RETURN
END
COMMIT TRAN
EDITAR:
Gostaria de esclarecer - quero gravar no log "Logs do SQL Server", log "Atual", na pasta "Gerenciamento" no explorador de objetos.
Usando o SQL Server 2008 R2:
No momento, estou tentando rastrear a causa de um problema de impasse que temos. Não tenho certeza para onde virar. Aqui está a configuração.
TABLE Scores:
id INT IDENTITY(1,1),
first_name VARCHAR(50),
last_name VARCHAR(50),
player_id VARCHAR(50),
score INT
PRIMARY KEY/CLUSTERED INDEX:
id
NON-CLUSTERED INDEX:
first_name, last_name INCLUDES id, player_id, score
Um aplicativo multithread processa mensagens e, em seguida, chama um dos dois procedimentos armazenados para cada mensagem.
Se o aplicativo não tiver processado o usuário, ele chamará um procedimento armazenado que insere uma linha na tabela.
Se o aplicativo tiver processado o usuário, ele atualizará qualquer um ou todos os first_name, last_name, scores, com base em first_namee last_name player_idnão será alterado.
Haverá apenas uma linha na tabela por player_id.
O thread que o aplicativo processa as mensagens é escolhido com base no player_id, portanto, dois threads NÃO processarão mensagens para o mesmo player ao mesmo tempo.
As instruções INSERT e UPDATE estão usando a WITH (ROWLOCK)diretiva.
Aqui está o problema:
O processo está causando deadlocks com o thread 1 bloqueando o índice clusterizado primário e o thread 2 bloqueando o índice não clusterizado.
Não entendo por que os bloqueios estão ocorrendo - as instruções UPDATE e INSERT estão usando bloqueios de linha e foi testado e comprovado que os threads não estão acessando as mesmas linhas.
O que eu poderia fazer para corrigir esse problema?
Ressalvas:
Devem existir dois stored procedures, um de atualização e outro de inserção. Por mais que eu queira mudar para um único MERGE, isso não vai acontecer. : /
Atualmente em execução no SQL Server 2008 R2
Estou tentando aumentar o desempenho de uma instrução UPDATE. Eu noto uma operação Eager Spool no showplan aparecendo. Minha compreensão das operações de spool é bastante básica - elas criam armazenamento temporário para a tabela durante a atualização.
Também sei que, embora estejam impedindo tempos de execução muito piores, os spools ansiosos geralmente são indicativos de problemas subjacentes com a estrutura da tabela e/ou instruções de consulta.
Minha pergunta é bem simples: quando você vê um Eager Spool em seu plano de consulta, quais problemas você procura resolver primeiro?
Estarei analisando cada parte do nosso sistema para aumentar o desempenho - estou apenas procurando orientação sobre por onde devo começar.
Usando: SQL Server 2008 R2
Em que circunstâncias você definiria as opções Affinity Mask e Affinity I/O Mask em sp_configure no SQL Server?
Atualmente estamos rodando em uma máquina com 16 núcleos dedicados ao SQL Server. Também estamos vendo lentidão em nossas operações de E/S. Algumas gravações (inserir 1 linha) podem levar até 500 ms. Gostaríamos de oferecer suporte a muitas gravações por segundo. O processo que insere dados pode gerar até 4 threads para executar as operações de inserção.
Estou pensando em dedicar 8 núcleos à máscara de afinidade e os outros 8 à máscara de E/S de afinidade.
Isso é recomendado?
Usando: SQL Server 2008 R2
No momento, estou percorrendo um plano de execução de consulta e encontrei uma instância de atualização de índice clusterizado em uma tabela. O problema aqui é que as colunas que estão sendo atualizadas NÃO fazem parte do índice clusterizado.
Mesa:
<table>
id INT IDENTITY(1,1) -- Clustered Index
, name VARCHAR(20) -- Nonclustered Index
, status CHAR(1)
, quantity INT
, price FLOAT
Declaração de atualização:
UPDATE a
SET a.status = @status
, a.quantity = @quantity
, a.price = @price
FROM <table> a
WHERE a.name = @name
O plano de execução mostra um Eager Spool com custo de 36%, uma atualização de índice clusterizado com custo de 55% e uma busca de índice no índice de nome com 9%, entre os itens Compute Scalar e Top com custo de 0%.
Por que o plano está mostrando uma atualização de índice clusterizado? O que eu poderia fazer para evitar isso e evitar o carretel ansioso?