¿Puedo mejorar el rendimiento en tablas de sistema hinchado?


12

Antecedentes:
tengo numerosas bases de datos con una gran cantidad de VIEW y una cantidad extremadamente grande de SYNONYM. Por ejemplo, una base de datos tiene más de 10k VIEW y más de 2 millones de SYNONYM.

Problema general: las
consultas que involucran sys.objects(y las tablas del sistema en general) tienden a ser lentas. Las consultas que involucran sys.synonymsson glaciales. Me pregunto qué puedo hacer para mejorar el rendimiento.

Ejemplo específico
Este comando lo ejecuta una herramienta de terceros. Es lento tanto en la aplicación como en SSMS:

exec sp_tables_rowset;2 NULL,NULL

Mi pregunta :
¿Cómo puedo hacer que esto funcione más rápido?

Lo que he intentado :
si SET STATISTICS IO ONobtengo este resultado:

(2201538 filas afectadas)
Tabla 'sysobjrdb'. Recuento de escaneo 1, lecturas lógicas 28, lecturas físicas 0, lecturas de lectura anticipada 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas de lectura anticipada 0.
Tabla 'sysschobjs'. Cuenta de escaneo 1, lecturas lógicas 53926, lecturas físicas 0, lecturas de lectura anticipada 0, lecturas lógicas lob 0, lecturas físicas lob 0, lecturas de lectura lob 0.

He podido actualizar estadísticas en las tablas del sistema subyacente. Esto ha funcionado en mi SQL 2008 R2 o en entornos más nuevos:

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

También he podido realizar el mantenimiento del índice. Esto funciona en mi SQL 2012 o entornos más nuevos. Por ejemplo, la ejecución sp_help 'sys.sysschobjs'identifica los índices en la tabla, y desde allí creo y ejecuto estos 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

La actualización de estadísticas y la reorganización de índices ayuda, pero no mucho.


Ay. ¿Supongo que estás haciendo algún tipo de inquilino múltiple desordenado, manteniendo los datos de todos en las mismas tablas y filtrándolos con vistas y usando sinónimos para nombrarlos después del objeto base, a gran escala? De cualquier manera, lo siento por ti
Philᵀᴹ

2
Multi inquilino? En realidad no. No lo es Bastante en mal estado, ¿verdad? FWIW, entiendo que para cada usuario de la aplicación, se crean 5 SINONIMOS para cada tabla. Suerte la mía.
Dave Mason

¿Eliminar permisos para algunos de esos objetos aumenta el rendimiento (de modo que hay menos de ellos para usar potencialmente?) No sé si esa es incluso una opción a nivel de usuario.
ConstantineK

Sería interesante ver un plan de ejecución sobre esto. tal vez podría publicar uno de sql sentry plan explorer en answers.sqlperformance.com y vincularlo, a menos que haya una manera de insertar esto aquí también. Sería interesante mirarlo
SheldonH

Respuestas:


1

Si aún no lo ha hecho, podría obtener rendimiento moviendo el archivo de datos primario a un conjunto separado de ejes del resto de los datos (consulte Archivos y arquitectura de grupos de archivos y SQL Server: ¿grupo de archivos solo para tablas del sistema? ).


Creo que este es un buen consejo, sin embargo, se negaría a impactar mucho si la configuración de E / S no es un servidor físico estándar con discos conectados, por ejemplo, una instancia virtual con SAN, o las unidades SSD minimizarían el impacto notable de separar archivos de datos primarios a una ubicación diferente, ¿verdad?
SheldonH

1
Si tiene control del hardware (es decir, no está alojado por un tercero), puede tener diferentes conjuntos de ejes en una SAN (por ejemplo, dos o más volúmenes RAID-10 separados). Si está utilizando (o alojado) con SSD, entonces no hay ejes, y la E / S estaría limitada principalmente por el cuello de botella entre las unidades y la placa base (es decir, tarjeta SATA, RAID o NIC, cableado, enrutadores / conmutadores , SAN, SSD), por lo que no ganaría nada separando los archivos en ese caso.
Ziggy Crueltyfree Zeitgeister
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.