Posso melhorar o desempenho em tabelas de sistema inchadas?

Antecedentes:
Eu tenho vários bancos de dados com um grande número de VIEW e um número extremamente grande de SYNONYM. Por exemplo, um banco de dados possui mais de 10k VIEW e mais de 2 milhões de SYNONYMs.

Problema geral: as
consultas que envolvem sys.objects(e as tabelas do sistema em geral) tendem a ser lentas. As consultas que envolvem sys.synonymssão glaciais. Gostaria de saber o que posso fazer para melhorar o desempenho.

Exemplo específico
Este comando é executado por uma ferramenta de terceiros. É lento no aplicativo e no SSMS:

exec sp_tables_rowset;2 NULL,NULL

Minha pergunta :
Como posso fazer isso funcionar mais rápido?

O que eu tentei :
Se SET STATISTICS IO ONeu receber essa saída:

(2201538 linhas afetadas)
Tabela 'sysobjrdb'. Contagem de varredura 1, leituras lógicas 28, leituras físicas 0, leituras antecipadas 0, leituras lógicas 0, lob leituras físicas 0, leituras físicas lob 0, leituras antecipadas lob 0,
tabela 'sysschobjs'. Contagem de varredura 1, leituras lógicas 53926, leituras físicas 0, leituras antecipadas 0, leituras lógicas lob 0, leituras físicas lob 0, leituras físicas lob 0, leituras antecipadas lob.

Consegui atualizar as estatísticas nas tabelas subjacentes do sistema. Isso funcionou nos meus SQL 2008 R2 ou em ambientes mais recentes:

UPDATE STATISTICS sys.sysobjrdb WITH FULLSCAN
UPDATE STATISTICS sys.sysschobjs WITH FULLSCAN

Também pude executar a manutenção do índice. Isso funciona no meu SQL 2012 ou em ambientes mais recentes. Por exemplo, a execução sp_help 'sys.sysschobjs'identifica os índices na tabela e a partir daí eu crio e executo estes comandos:

ALTER INDEX clst ON sys.sysschobjs REORGANIZE
ALTER INDEX nc1 ON sys.sysschobjs REORGANIZE
ALTER INDEX nc2 ON sys.sysschobjs REORGANIZE
ALTER INDEX nc3 ON sys.sysschobjs REORGANIZE

Atualizar estatísticas e reorganizar índices ajuda, mas não muito.

sql-server system-tables

— Dave Mason
fonte

Ai. Suponho que você esteja fazendo algum tipo de inquilino confuso, mantendo os dados de todos nas mesmas tabelas e filtrando-os com visualizações e usando sinônimos para nomeá-los após o objeto base, em larga escala? De qualquer maneira, eu sinto por você

— Philᵀᴹ

Multi inquilino? Na verdade não. Não é. Muito bagunçado, certo? FWIW, entendo que, para cada usuário do aplicativo, existem 5 SYNONYMs criados para cada tabela. Sorte minha.

— Dave Mason

A remoção de permissões para alguns desses objetos aumenta o desempenho (para que haja menos deles potencialmente a serem usados?) Não sei se isso é uma opção no nível do usuário.

— ConstantineK

Seria interessante ver um plano de execução sobre isso. talvez você possa postar um do sql sentry plan explorer em answers.sqlperformance.com e vincular a ele, a menos que haja uma maneira de incorporar isso aqui também. Eu seria interessante olhar para ele #

— SheldonH 10/16/16

Se você ainda não o fez, poderá obter desempenho movendo o arquivo de dados primário para um conjunto separado de eixos do restante dos dados (consulte Arquitetura de Arquivos e Grupos de Arquivos e SQL Server: grupo de arquivos apenas para tabelas de sistema? ).

— Ziggy Crueltyfree Zeitgeister
fonte

Acho que esse é um bom conselho, no entanto, seria negado ao impactar muito se a configuração de E / S não fosse um servidor físico padrão com discos conectados, por exemplo, instância virtual com SAN ou unidades SSD minimizariam o impacto perceptível da separação de arquivos de dados primários para um local diferente, certo?

— SheldonH

Se você possui o controle do hardware (ou seja, não está sendo hospedado por terceiros), pode ter diferentes conjuntos de eixos em uma SAN (por exemplo, dois ou mais volumes RAID-10 separados). Se você estiver usando (ou hospedado) com SSDs, não haverá eixos, e a E / S seria limitada principalmente pelo gargalo entre as unidades e a placa-mãe (por exemplo, placa SATA, RAID ou NIC, cabeamento, roteadores / switches , SAN, SSDs), para que você não ganhe nada separando os arquivos nesse caso.

— Ziggy Crueltyfree Zeitgeister