Eu tenho uma tabela que armazena imagens que variam em tamanho entre 16-100 KB cada. Como as imagens são muito pequenas, segui o conselho da Microsoft e não usei o tipo de dados FILESTREAM. A tabela é construída de forma simples:
CREATE TABLE Screenshot(
Id bigint NOT NULL,
Data varbinary(max) NOT NULL,
CONSTRAINT PK_Screenshot PRIMARY KEY CLUSTERED
(
Id ASC
)WITH (PAD_INDEX = OFF,
STATISTICS_NORECOMPUTE = OFF,
IGNORE_DUP_KEY = OFF,
ALLOW_ROW_LOCKS = ON,
ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
A tabela está fortemente inserida (2 milhões de registros na última semana) e raramente selecionada. A chave é usar um algoritmo hilo , portanto, na maioria das vezes, novas linhas são adicionadas no final.
Tenho tido problemas quando muitos processos tentam inserir nessa tabela por causa de travamento e contenção. As consultas estão expirando devido à espera de bloqueios.
Devo migrar esta tabela para seu próprio grupo de arquivos e unidade? Como posso melhorar a performance do insert e diminuir a contenção neste tipo de situação?
Você pode tentar alterar a geração de id para que as inserções não entrem em conflito ou considere definir
ALLOW_PAGE_LOCKS = OFF, observando as implicações para a manutenção do índice (que provavelmente são relevantes apenas se você também estiver fazendo atualizações)Como você mencionou o FILESTREAM, imagino que esteja usando o SQL Server 2008. Em vez de adivinhar qual é o gargalo e como melhorá-lo, você deve identificá-lo usando eventos estendidos e fazendo um teste de carga [http://www.datamanipulation.net/sqlquerystress /] nesta atividade.
http://blogs.technet.com/b/sqlos/archive/2008/07/18/debugging-slow-response-times-in-sql-server-2008.aspx
Depois de identificar o gargalo, descobrir a solução sempre será fácil, correto e correto.