Posso migliorare le prestazioni su tabelle di sistema gonfiate?

Contesto:
ho numerosi database con un gran numero di VIEW e un numero estremamente elevato di SYNONYM. Ad esempio, un db ha più di 10k VIEW e 2+ milioni di SYNONYM.

Problema generale: le
query che coinvolgono sys.objects(e le tabelle di sistema in generale) tendono ad essere lente. Le domande che coinvolgono sys.synonymssono glaciali. Mi chiedo cosa posso fare per migliorare le prestazioni.

Esempio specifico
Questo comando viene eseguito da uno strumento di terze parti. È lento sia nell'app, sia in SSMS:

exec sp_tables_rowset;2 NULL,NULL

La mia domanda :
come posso farlo funzionare più velocemente?

Cosa ho provato :
se SET STATISTICS IO ONottengo questo risultato:

(2201538 righe interessate)
Tabella 'sysobjrdb'. Conteggio scansioni 1, letture logiche 28, letture fisiche 0, letture read-ahead 0, letture logiche lob 0, letture fisiche lob 0, letture read lob
iniziali 0. Tabella "sysschobjs". Conteggio scansioni 1, letture logiche 53926, letture fisiche 0, letture read-ahead 0, letture log lob 0, letture fisiche lob 0, letture read lob 0.

Sono stato in grado di aggiornare le statistiche sulle tabelle di sistema sottostanti. Questo ha funzionato nel mio SQL 2008 R2 o negli ambienti più recenti:

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

Sono stato anche in grado di eseguire la manutenzione dell'indice. Funziona nel mio SQL 2012 o negli ambienti più recenti. Ad esempio, in esecuzione sp_help 'sys.sysschobjs'identifica gli indici sulla tabella e da lì creo ed eseguo questi comandi:

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

L'aggiornamento delle statistiche e la riorganizzazione degli indici aiuta, ma non di molto.

sql-server system-tables

— Dave Mason
fonte

Ahia. Immagino che stai facendo qualche tipo di multi tenant incasinato, mantenendo i dati di tutti nelle stesse tabelle e filtrandoli con le viste e usando sinonimi per denominarli come oggetto di base, su larga scala? Ad ogni modo, mi sento per te

— Phil

Multi inquilino? In realtà no. Non lo è. Abbastanza incasinato, vero? FWIW, ho capito che per ogni utente dell'applicazione, ci sono 5 SYNONYM creati per ogni tabella. Fortunato me.

— Dave Mason,

La rimozione delle autorizzazioni per alcuni di questi oggetti aumenta le prestazioni (in modo che ce ne siano meno da utilizzare potenzialmente?) Non so se sia anche un'opzione a livello di utente.

— ConstantineK

Sarebbe interessante vedere un piano di esecuzione su questo. forse potresti inviarne uno da sql sentry plan explorer a answer.sqlperformance.com e collegarti ad esso, a meno che non ci sia un modo per incorporarlo anche qui. Sarei interessante a guardarlo

— SheldonH,

Se non lo si è già fatto, è possibile ottenere prestazioni spostando il file di dati primario in un set separato di fusi dal resto dei dati (vedere Architettura di file e filegroup e SQL Server: filegroup solo per le tabelle di sistema? ).

— Ziggy Crueltyfree Zeitgeister
fonte

Penso che questo sia un buon consiglio, tuttavia, sarebbe negato sull'impatto molto se l'installazione di I / O non è un server fisico standard con dischi collegati, ad esempio un'istanza virtuale con SAN o unità SSD minimizzerebbe l'impatto notevole della separazione dei file di dati primari in un'altra posizione, giusto?

— SheldonH,

Se hai il controllo dell'hardware (ovvero non sei ospitato da terzi), puoi avere diversi set di mandrini in una SAN (ad esempio due o più volumi RAID-10 separati). Se stai usando (o ospitato) con SSD, allora non ci sono mandrini e IO sarebbe limitato principalmente da qualsiasi collo di bottiglia tra le unità e la scheda madre (ad es. Scheda SATA, RAID o NIC, cablaggio, router / switch , SAN, velocità SSD), quindi non otterresti nulla separando i file in quel caso.

— Ziggy Crueltyfree Zeitgeister,