Contratar a un especialista en OLP SqlServer, ¿Qué experiencia o requisitos debo buscar? [cerrado]

StackOverflow https://stackoverflow.com/questions/415419

Pregunta

Me encuentro con problemas de rendimiento de Db con un proyecto OTLP en el que estoy trabajando. Otro desarrollador y yo hemos llegado al final de nuestro conocimiento de rendimiento acumulado y buscamos a una persona para que se una al equipo y nos ayude a acelerar nuestra aplicación.

Para algunos antecedentes, hemos realizado cambios de esquema para desnormalizar partes de los datos, optimizamos cada consulta, ejecutamos múltiples asesores de ajuste de bases de datos para obtener nuestros índices correctamente, ajustamos las opciones del servidor de MSSql.

No necesitamos que alguien venga y nos diga que las uniones pueden ser lentas y lo que es un punto muerto, necesitamos a alguien que sepa qué hacer después de agotar todos los pasos mencionados anteriormente.

¿Alguien tiene algún consejo o experiencia para contratar DBA OLTP para compartir? ¿Qué tipo de preguntas podemos hacerle al DBA durante el proceso de entrevista?

Es una situación extraña, sabemos que necesitamos a alguien que sepa más que el equipo actual, pero no sabemos qué preguntas hacer porque no sabemos cuáles son los próximos pasos. ¿Tiene sentido eso?

¿Fue útil?

Solución

Ok, esto me dice algo:

  

Para algunos antecedentes, hemos realizado cambios de esquema para desnormalizar partes de los datos, optimizamos cada consulta, ejecutamos múltiples asesores de ajuste de bases de datos para obtener nuestros índices correctamente, ajustamos las opciones del servidor de MSSql.

Ya ha igualado o superado lo que el 90% de las personas que se llaman a sí mismas DBA podrán hacer.

El problema es que muchos DBA no son realmente programadores, sino que están más relacionados con la administración del sistema. Necesita un programador de DBA que no solo sea realmente bueno en TSQL, sino que también conozca sus otros lenguajes de programación.

Paso una parte importante de mi tiempo en problemas de ajuste de bases de datos como este, y la solución a menudo implica rediseños significativos desde el front-end hasta el esquema de la base de datos. No puede resolver estos problemas de forma aislada, y sin un control completo (y una comprensión total) de toda la arquitectura, nunca obtendrá el rendimiento que necesita.

Usted podría ser la mejor persona para el trabajo, y podría ser más inteligente para usted contratar a alguien para que le quite el trabajo ocupado y pueda concentrarse en los problemas de rendimiento de OLTP.

Otros consejos

Debe ser muy cuidadoso aquí, puede terminar contratando a un Guru DBA, que mejore el rendimiento de la base de datos de manera significativa y aún tenga problemas con su aplicación que estén enraizados en su arquitectura.

Algunas ideas:

  1. Tome la consulta más compleja que optimizó, déselo al candidato DBA con QA y haga que él / ella lo optimice nuevamente. Pídales que describan lo que hicieron y cómo lo hicieron.

  2. Asegúrese de que esta persona entienda el hardware, cuando usaría múltiples grupos de archivos, matrices de incursiones, particionamiento de datos, rendimiento de 64 contra 32 bits, etc. ...

  3. Busque a alguien que también tenga experiencia en arquitectura de software.

  4. Hágales algunas preguntas más difíciles sobre el servidor SQL, por ejemplo. ¿Qué es la declaración OVER? ¿Los GUID son buenas claves principales y por qué es preferible la identidad int?

Desactive su DB un poco antes de su propia optimización y entréguesela. Vea si pueden ajustarlo para que funcione tan bien o mejor en comparación con los cambios que realizó.

Pregunte por qué eligieron esa técnica.

Tome referencias e infórmese sobre los entornos de los que provienen que tienen más probabilidades de coincidir con el suyo.

Un buen DBA podrá decirle en la entrevista a un alto nivel qué pasos tomarán a continuación. Debería prestar más atención a los procesos de pensamiento aquí, en lugar de la solución al problema. Cuando el DBA haya dado algunas soluciones, regrese, pregúnteles y pregúnteles por qué el problema debería resolverse de esa manera.

Este método distinguirá rápidamente a los hombres de los niños, por así decirlo.

¿Qué tan cerca está del rendimiento máximo de la base de datos? Es muy fácil crear un problema OLTP que no puede resolverse con esta tecnología. Como dijo Eric, el rediseño total de la arquitectura podría estar en orden. Más ram, solo agrega más ram :)

Ciertamente, sin ver la base de datos es difícil decir cuál podría ser la mejor manera de optimizar. Dado lo que ha hecho, es probable que necesite contratar un diseñador de base de datos, uno con experiencia en el diseño y ajuste de bases de datos en el rango de tamaño que tiene. Al preguntar cómo abordarían el problema, ver si el entrevistador vería primero las consultas de bajo rendimiento y ejecutaría el generador de perfiles para ver qué está sucediendo e identificarlos. La persona debe poder responder preguntas específicas sobre la detección de parámetros y cómo evitarlo, cuáles son los métodos que se pueden usar para evitar los cursores, por qué las estadísticas deben actualizarse, lo que hace que una consulta sea almacenable. Hay algunas cosas comunes que me gustaría ver en el ajuste de rendimiento. ¿Está la red al máximo (a veces no es la base de datos), el diseño general está mal pensado, está utilizando un código SQl que, en general, funciona mal? Si todas sus búsquedas permiten un carácter comodín como el primer carácter, por ejemplo, ni siquiera es posible que sean rápidos. Si sus combinaciones están en claves naturales de varias columnas, son más lentas de lo que deberían ser. ¿Está almacenando más de una pieza de información en un campo causando mucha manipulación para recuperar los datos? ¿Estás utilizando cursores? ¿Estás usando funciones? ¿Estás reutilizando el código cuando no deberías? ¿Siempre estás devolviendo la información mínima necesaria? ¿Estás cerrando conexiones? ¿Está consiguiendo puntos muertos? ¿Las filas de tu mesa son demasiado anchas? ¿Tiene demasiados registros en tablas particulares (purgar registros antiguos o colocarlos en una base de datos de archivos puede hacer una gran diferencia)? ¿Cuánto de su código está orientado a filas y no está orientado a conjuntos? Estos son ejemplos de los tipos de cosas que una persona con base de datos con experiencia vería y, por lo tanto, los tipos de cosas de las que deberían hablar en la entrevista.

Algunos ejemplos de códigos erróneos (ya sabes lo que ya has optimizado) pueden darte una buena idea sobre su enfoque de cómo ajustarlos. Deseas a alguien que sea metódico y tenga conocimientos profundos de SQL.

Hay algunos buenos libros sobre la optimización del rendimiento; sugeriría obtenerlos y familiarizarse con ellos antes de la entrevista.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top