SELECT name FROM sys.databases
WHERE
name
not in
('master','model','msdb','tempdb','ReportServer','ReportServerTempDB','1303VISBOC')
AND
CASE WHEN state_desc = 'ONLINE'
THEN OBJECT_ID(QUOTENAME(name) + '.[dbo].[_LOOK_UP_TABLE]', 'U')
END IS NOT NULL
Estou usando o acima para preencher uma caixa de combinação no projeto ac# winforms. -A razão pela qual estou filtrando bancos de dados que não incluem a tabela é para fins de segurança.
Eu adicionei o WHERE clause
como antes de fazer que estava demorando até 21 segundos!? (Isso está em uma máquina de desenvolvimento local com 4 bancos de dados (não incluindo os bancos de dados do sistema), apenas um dos quais possui a tabela que eu estava procurando.)
Agora que adicionei a cláusula where, leva apenas nove segundos.
Não posso deixá-lo rodando tão devagar, pois o programa que estou escrevendo será usado em máquinas que podem ter até 20 bancos de dados nelas. -Todos com cerca de 35 mesas. (Estes não são servidores, são Support Monkey Machines!)
Pelo Plano de Execução Real vejo que são três Clustered Index Seek's
ocupando 22%, 24% e 48%. -Como esta é uma consulta de 'sistema', há algo que eu possa realmente fazer sobre isso?!
E, finalmente, a bomba para tornar isso um pouco mais difícil: não tenho controle sobre os índices dos bancos de dados e não posso alterá-los de forma alguma.
A consulta é bastante simples e deve ser executada com rapidez suficiente.
Meu palpite é que você tem uma transação de execução longa realizando DDL em um dos bancos de dados e sua consulta está sendo bloqueada aguardando um bloqueio.
Infelizmente, as funções de metadados, como
OBJECT_ID
não levam em conta o nível de isolamento da transação externa, portanto, mesmo definir o nível de isolamento para permitir leituras sujas não ajudaria.Você pode tentar este método alternativo de fazer a mesma operação e relatar? (Se ainda estiver lento, tente adicionar
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
ao início)Isso funcionaria? Livrou-se da instrução case na cláusula where ...
Apenas por diversão, por que não tentar este SQL, que reorganiza um pouco as coisas:
Muitas vezes descobri que o operador IN é uma fonte de problemas de desempenho no passado e o evito sempre que posso (o que é quase sempre).