¿Cómo aumentar el rendimiento de una base de datos?

Question

He diseñado bases de datos varias veces en mi compañía. Para aumentar el rendimiento de la base de datos, busco Normalización e Indexación solamente.

Si le pidieron que aumente el rendimiento de una base de datos que tiene aproximadamente 250 tablas y algunas tablas con millones de registros, ¿qué cosas diferentes buscaría?

Gracias de antemano.

Answer 1

Optimizar el diseño lógico

El nivel lógico es acerca de la estructura de la consulta y las propias tablas. Intenta maximizar esto primero. El objetivo es acceder a la menor cantidad posible de datos en el nivel lógico.

• Hacer que el SQL más eficiente consulta
• Diseño de un esquema lógico que apoyan la necesidad de la aplicación (por ejemplo, tipo de las columnas, etc.)
• Diseño disyuntiva de apoyar algunos casos de uso mejor que otra
• restricciones relacionales
• normalización

Optimizar el diseño físico

El nivel físico se ocupa de la consideración no lógica, como el tipo de índices, los parámetros de las tablas, etc. El objetivo es optimizar el IO que siempre es el cuello de botella. Sintonice cada tabla para que se ajuste a sus necesidades. Se puede cargar una tabla pequeña permanentemente cargada en el caché DBMS, la tabla con baja tasa de escritura puede tener diferentes configuraciones que la tabla con alta tasa de actualización para tomar menos espacios de disco, etc. Dependiendo de las consultas, se puede usar un índice diferente, etc. datos no normalizados transparente con vistas materializadas, etc.

• Tablas paremeters (tamaño de asignación, etc.)
• índices (combinados, tipos, etc.)
• parámetros de todo el sistema (tamaño de caché, etc.)
• Particionado
• Denormalización

Primero intente mejorar el diseño lógico, luego el diseño físico. (El límite entre ambos es sin embargo impreciso, entonces podemos discutir sobre mi categorización).

Optimizar el mantenimiento

base de datos debe funcionar correctamente para mantenerse lo más eficiente posible. Esto incluye algunas tomas de mantenimiento que pueden tener impacto en el rendimiento, p.

• mantener estadísticas al día
• Re-secuencia de cuadros críticos periódicamente
• mantenimiento del disco
• Toda la materia sistema tenga un servidor que mece

Answer 2

Para su conjunto de herramientas de normalización e indexación, con tablas extremadamente grandes, es posible que también desee considerar los pros y los contras de la partición de las tablas. Pero ya tienes los más importantes.

Answer 3

Si una consulta es extremadamente crítica, puede que desee considerar de -normalización, para reducir el número de búsquedas de tabla por consulta. Aparte de eso, si necesita más rendimiento más allá de lo que pueden realizar la indexación y la desnormalización, puede buscar el lado del programa: almacenamiento en caché, optimización de consultas/procedimientos almacenados, etc.

Answer 4

Esa es una pregunta muy vaga.

Dice que busca la indexación, pero no puede ver la indexación aisladamente. Debe observar las consultas que se están ejecutando, los planes de ejecución, los índices que se usan y cómo se usan. La herramienta Profiler puede ayudar mucho al determinar qué consultas son ineficaces.

Aparte de eso, asegúrese de que se haya configurado un plan de mantenimiento. Debería actualizar estadísticas y desfragmentar/reconstruir índices al menos una vez a la semana en una base de datos transaccional pesada.

Si tiene la infraestructura, mire la configuración de archivos y grupos de archivos. Debería intentar colocar tablas y/o índices que sean grandes y se usen con frecuencia en diferentes unidades físicas, si es posible. Si tiene tablas muy grandes, puede pensar en particionarlas.

Si todavía tiene problemas de rendimiento, desnormalización a veces puede ayudar, pero todo depende de la situación.

Voy a detenerme allí; no quiero que esta respuesta se convierta en la lista más aleatoria del mundo de sugerencias de rendimiento de SQL. Recomiendo que sea más específico sobre dónde cree que están los problemas de rendimiento y cuéntenos un poco más sobre la base de datos (tamaño, estrategia de indexación actual, frecuencia de las transacciones, cualquier informe grande que necesite generar, etc.)

Answer 5

In Para aumentar el rendimiento, primero deberá supervisar su base de datos. Puede rastrear y luego cargarlo en el perfil de servidor SQL para averiguar cuáles son las consultas más lentas. Después de eso, puedes concentrarte en ellos.

También puede usar vistas dinámicas y funciones de administración para averiguar qué índices faltan. También podrá recuperar estadísticas sobre índices existentes, como el uso del índice y los índices perdidos.

Answer 6

Optimizar las consultas que se utilizan para acceder a esa base de datos es lo más importante. Solo agregando índices no garantiza que las consultas los usarán.

Answer 7

Compresión. Para la gran mayoría de las cargas que he intentado, usar compresión fue una tremenda jugada gratuita. Tamaño de datos reducido significa que la reducción de E/S significa un mejor rendimiento. En SQL Server 2005, las opciones de compresión son limitadas (vardecimal).Pero consideraría seriamente actualizar a 2008 solo para la compresión de páginas. O 2008 R2 si usa nvarchar con frecuencia para obtener la compresión Unicode.

Retención de datos. Estableciendo políticas de retención y eliminando datos antiguos de manera agresiva. Menos datos significa menos E/S, significa un mejor rendimiento. A menudo esto se considera operativo, no de diseño, pero me gusta pensar en este tema como un problema de diseño de la aplicación.

Por supuesto, supongo que ya supervisa todas y cada una de las consultas para asegurarse de que ninguna haga exploraciones de tabla estúpidas de extremo a extremo.

Muchos impulsores de rendimiento son en su mayoría más operativa o de implementación, no de diseño: mantenimiento (desfragmentación, reconstrucción de índices, etc.), I/O y el diseño de almacenamiento, etc.

Y por último pero no menos importante entender el costo oculto de varios a su vez soluciones clave Como, por ejemplo, Replicación o Duplicación de base de datos.

Answer 8

No hemos escrito sobre un bit de rendimiento:

Hardware.

Las bases de datos son intensamente impulsadas por E/S. Pasar a un disco duro más rápido debería aumentar la velocidad de las consultas a la base de datos. Dividir la base de datos entre muchos discos duros rápidos podría mejorarlo aún más.

Answer 9

Hay muchas cosas que podrías hacer, muchas de ellas ya sugeridas anteriormente. Algunos que miraría (en este orden):

• Errores/registros: muchos motores db tienen herramientas de informes que señalan áreas problemáticas en una base de datos. Comience aquí para ver si hay algo en lo que pueda concentrarse de inmediato.
• Retención de datos: compruebe la especificación comercial de cuánto tiempo se deben guardar los datos, asegúrese de que los datos anteriores se trasladen a un depósito de datos para mantener el tamaño de la tabla pequeño. (¿Por qué conservar 5 años de datos si solo son necesarios 3 últimos meses?)
• Busque escaneos de tablas, indexe los datos si esto ayuda (tiene que calibrar este frente a las escrituras de tablas). Los registros de su servidor probablemente lo ayuden a encontrar escaneos de tablas.
• Elementos atómicos de trabajo, ¿algunas escrituras mantienen bloqueos en diferentes tablas antes de llegar a un punto de confirmación? ¿Pueden simplificarse esos elementos de trabajo o moverse puntos de compromiso para acelerar el rendimiento? Aquí es donde necesitarás que un desarrollador mire el código.
• Busque sentencias de SQL de larga ejecución, ¿puede hacerse más eficiente? A veces, las consultas mal estructuradas pueden arruinar realmente una aplicación. Es posible que deba sugerir un cambio de codificación para mejorar el rendimiento.
• dba realm: observe cómo se asignan las tablas: tamaño de página, segmentos múltiples, etc. Aquí es donde las herramientas de diagnóstico del proveedor son útiles, ya que a menudo pueden sugerir cómo puede estructurar una tabla en función del historial de uso. Un dba experimentado sería útil aquí.
• busca los cuellos de botella de hardware/red. Aquí es donde necesitarías un tipo de hardware. :)

Estos son realmente de alto nivel, también me gustaría echar un vistazo a lo que el proveedor de su motor de db sugiere como mejoras en el rendimiento.

Además, mediría una lista como esta en comparación con lo que mi jefe está dispuesto a pagar y cuánto tiempo tengo. ;)

Espero que esto ayude.

Answer 10

Mi rollo en MySpace era " Mejora de rendimiento DBA/Desarrollador ". Diría que la normalización y los índices son un requisito en las bases de datos de alto rendimiento, pero realmente debe analizar las estructuras e índices de la tabla para desbloquear realmente los poderes del diseño de la base de datos.

Aquí hay algunas sugerencias que tendría para usted;

1. Conozca el motor de DB. Un conocimiento completo de la estructura de E/S subrayada va un largo camino en el diseño de un índice o tabla adecuada. Usando PerfMon y Profiler, junto con su conocimiento de lo que son las E/S de lectura/escritura, puede poner algunos números muy específicos detrás de su teoría de lo que es una solución de tabla/índice bien formada.

2. Comprenda la diferencia entre índices agrupados y no agrupados y cuándo usarlos.

3. Use sys.dm_os_waiting_tasks y sys.dm_os_wait_stats DMV. Le dirán dónde debe esforzarse para reducir el tiempo de espera.

4. Utilice DBCC SET STATISTICS IO/TIME ON, y evalúe sus planes de ejecución para ver si una consulta reduce o aumenta el número de lecturas de página o la duración.

5. DBCC SHOWCONTIG le dirá si sus tablas están muy fragmentadas. Esto a menudo es ignorado por los desarrolladores y DBA Jr. desde el punto de vista del rendimiento, sin embargo, esto puede tener un GRAN efecto en el número de lecturas de página que tiene. Si una tabla tiene una densidad de página de 20% de extensión, eso significa que está leyendo aproximadamente 5 veces los datos que, de otro modo, sería si la tabla y sus índices se desfragmentaran.

6. Evaluar lecturas sucias (nolock, leer sin compromiso). Si pudieras terminar con precisión de milisegundos en las lecturas, ¡guarda los bloqueos!

7. Considere la posibilidad de extraer claves foráneas innecesarias. Son útiles en entornos Dev, no en sistemas transaccionales de alto rendimiento.

8. Las particiones en las tablas grandes suponen una gran diferencia, solo si están diseñadas correctamente.

9. Cambios en la aplicación: si puede programar actualizaciones por lotes para transacciones asincrónicas, colóquelas en un montón libre de índice y trátelas según lo programado para que no actualice de manera constestada las tablas que realiza grandes consultas.

10. Always Always Always !!! use la misma variable de tipo de datos para consultar las columnas de destino; Por ejemplo, la siguiente instrucción utiliza una variable bigint para una columna SMALLINT:

declarar @i bigint conjunto @i = 0

SELECT * FROM MyTable donde Col01SmallInt> = @i

En el proceso de evaluación de las páginas de índice/tabla, el motor de consulta puede optar por convertir sus datos de columna smallint a tipo de datos bigint. Considere, en cambio, cambiar el tipo de varialbe, o al menos convertirlo a smallint en su condición de búsqueda.

11. SQL 2005/08 le da "Informes" en la aplicación de administración, eche un vistazo a los informes sobre el rendimiento de sus índices. ¿Están siendo escaneados, buscados? ¿Cuándo fue tu último escaneo de tabla? Si fue reciente, los índices no cumplen todas las consultas necesarias. Si tiene un índice que apenas se está usando (buscando o escaneando) pero que se actualiza constantemente, considere descartarlo. Puede ahorrarle muchos bloqueos innecesarios y bloqueos de teclas. ..

Eso es todo lo que puedo pensar de la parte superior de mi cabeza. Si se encuentra con un problema más específico, yo tendría una respuesta más específica para usted.