Base de datos interna deficiente: ¿reemplazarla o colocarle hardware?

Entonces, tenemos una base de datos interna de la compañía, el tipo de cosas habituales: gestiona clientes, llamadas telefónicas, ofertas de ventas y acuerdos / esquemas de clientes.

Es un front-end de Access 2000 y un back-end de SQL Server 2000 Standard. Servidor único, Xeon dual de 3.2GHz, 2GB de RAM, Windows Server 2003, recibe alrededor del 40% de carga de CPU todo el día, distribuido en los 4 núcleos visibles para el sistema operativo (HT).

La base de datos de back-end está mal diseñada y ha crecido orgánicamente durante más de 10 años, mantenida por personas poco cualificadas. Está muy normalizado, y algunos de los problemas obvios incluyen tablas con decenas de miles de filas sin clave primaria o índice, que también se usan mucho en uniones de tablas múltiples para algunas de las partes más utilizadas del sistema (por ejemplo, un aplicación de administrador de llamadas que se encuentra en el segundo monitor de todos durante 8 horas al día y ejecuta una consulta grande e ineficiente cada pocos segundos).

El front-end no es mucho mejor, es el desorden típico de cientos de formularios, consultas guardadas anidadas, SQL incrustado mal escrito en el código VBA, docenas de "peculiaridades", etc., y cada vez que se realiza un cambio, algo no relacionado parece romperse. Nos hemos decidido por un MDB que funciona "lo suficientemente bien" y ahora tenemos una política de no cambio al respecto, ya que no tenemos pesos pesados ​​de Access en la empresa (y tampoco tenemos planes de contratar uno).

La compañía ahora está creciendo lentamente, aumentando el número de clientes, llamadas, etc., así como un aumento modesto en el número de usuarios concurrentes, y el rendimiento ha empeorado notablemente recientemente (esperando moverse entre formularios, esperando que se llenen las listas, etc. )

Perfmon dice:

• Transferencias de disco por segundo: entre 0 y 30, promedio 4.
• Longitud actual de la cola del disco: ronda 1

El generador de perfiles de SQL Server ve cientos de miles de consultas cada minuto. El uso de la CPU en los clientes es prácticamente nulo, lo que indica que está esperando que se ejecuten las consultas del lado del servidor. Puse esta carga de trabajo a través del DB Engine Tuning Advisor, apliqué sus sugerencias a una copia de seguridad de prueba, pero esto realmente no ha hecho mucha diferencia.

Por cierto, tenemos una mezcla de 100 MB y ethernet gigabit, todo en una subred, 40 usuarios en dos plantas.

A la pregunta.

A mi entender, tenemos dos opciones para resolver / mejorar esta situación.

• Podemos descartarlo y reemplazarlo con un sistema CRM completamente nuevo, ya sea a medida o parcialmente a medida
• Podemos extender la vida útil de este sistema arrojándole hardware.

Podemos construir un sistema Intel i7 con números de rendimiento locos por un orden de magnitud menor costo que reemplazar el software.

Cuando finalmente se desarrolla un nuevo sistema, se puede alojar en este cuadro, por lo que no hay desperdicio de hardware. Un nuevo sistema de CRM se sigue apagando, apagando y apagando, no veo que eso suceda durante al menos un año.

Cualquier idea sobre esta situación, especialmente si ha estado aquí usted mismo, sería muy apreciada.

Gracias

Voy a estar en desacuerdo con todos aquí. Lanza algo de hardware. Es barato, rápido, fácil y le dará el tiempo necesario para implementar una solución CRM adecuada. La razón por la que estoy abogando por algo que es anatema para casi todos, no solo en este tablero, sino también en stackoverflow, es que he sido gerente / gerente de proyectos y he estado en el lado de "Negocios" por un tiempo (negocios está entre comillas debido a mi odio por la palabra). Según su descripción del software, llevará cerca de un año reconstruir otra cosa. Simplemente descubrir / documentar las reglas / peculiaridades del negocio, probablemente tomará 2 meses. También será increíblemente costoso de desarrollar. Especialmente cuando se compara con el costo de un servidor engañado.

De hecho, estoy a punto de alojar un conjunto de aplicaciones web para una empresa por esa misma razón. El departamento interno de TI no lo trasladará a un mejor hardware porque desean volver a desarrollarlos en una nueva plataforma. Ese costo es aproximadamente el triple de lo que costaría moverlo a un nuevo hardware. Sin mencionar que la compañía podría no renovar el contrato en un año.

Es posible que tampoco necesite hacerlo. Mi sugerencia es simplemente agregar algunos índices / claves a la tabla.

tablas con decenas de miles de filas sin clave principal o índice, que también se utilizan mucho en combinaciones de varias tablas

Antes de gastar mucho dinero o tiempo, tómese un par de horas y agregue índices (o claves principales si puede) a las tablas involucradas en esas uniones ... particularmente para las columnas utilizadas en una cláusula where. Podría mejorar fácilmente el rendimiento por un factor de 10 en solo unas pocas horas.

La falta de E / S de disco implica que las consultas se alimentan principalmente de RAM. Si 'de repente' tiene sus mesas calientes ya no caben en la RAM y el servidor comienza a trabajar con los discos, es posible que tenga un mal viaje. 2GB o RAM no es mucho en estos días, pero en la era SQL2000 habría sido considerable. Supongo que la cantidad de datos que la aplicación normalmente manipula es menor que la RAM que tiene. Es posible que desee ver la cantidad de espacio "usado" en los archivos de datos. Esto le dará una idea de cuánta RAM podría consumir la base de datos, en el peor de los casos. SQL Server no guarda los datos que no necesita en la RAM, pero puede ser difícil saber qué tablas se usan y cuándo.

Hyperthreading no siempre es útil con SQL Server. Puede obtener un mejor rendimiento apagándolo. Es difícil de probar porque encenderlo y encenderlo requiere un reinicio, y eso es una gran molestia en un servidor de producción.

"Cientos de miles de consultas por minuto" se traduce en miles de consultas por segundo. Eso suena bastante ocupado, pero gran parte de ese tráfico puede ser solo captación de cursor por parte de Access. El acceso es particularmente malo en la recuperación eficiente de conjuntos de resultados de SQL. Puede obtener un mejor rendimiento al desactivar la configuración de paralelización de SQL Server.

También quieres buscar bloqueos. Lanzar hardware a un problema de bloqueo no siempre produce la mejora dramática esperada. Si no hay mucho bloqueo y las consultas son satisfechas por la RAM, en lugar del disco, básicamente está confiando en el gruñido del procesador y su capacidad para extraer datos a través de los canales de memoria. En ese caso, un hardware más rápido debería proporcionar una buena mejora. Si tiene prisa (para superar este problema) y crece lentamente, eso podría ser lo suficientemente bueno.

Como solución, agregar hardware no escala tan bien como las mejoras en la base de datos. Si obtiene un aumento en el crecimiento, es posible que su nuevo hardware tenga dificultades. Otro pensamiento es que las aplicaciones exitosas atraen a los usuarios. Si la aplicación se vuelve más receptiva, es más probable que los usuarios ejecuten más informes y tal cosa que si necesitaran ir a tomar un café mientras esperan que termine el informe.

Si el esquema de la base de datos es realmente malo, puede obtener algunas ganancias de rendimiento simplemente mirando la indexación en las tablas. Concéntrese en las mesas que sabe que se consultan a menudo. Puede usar Profiler para ver las consultas que se ejecutan en el servidor, solo dígale que busque consultas que lean muchos datos (como 100,000 páginas) y luego trabaje hacia consultas que no leen mucho. Usted mencionó que algunas de las tablas no tienen claves. ¿Existen claves naturales en los datos, simplemente no forzadas por restricciones o índices únicos?

¿Las tablas tienen índices agrupados? La falta de indexación agrupada puede causar todo tipo de efectos secundarios.

¿Hay muchos índices no agrupados, con muchas columnas? Esto es a menudo un intento de construir muchos índices de cobertura, en lugar de implementar una estrategia de indexación más efectiva. SQL Server puede construir efectivamente índices de cobertura sobre la marcha durante una consulta, si tiene sentido hacerlo y hay índices de soporte no agrupados y agrupados.

Por último, vale la pena preguntar: ¿Se está realizando el mantenimiento (reindexación y / o actualización de estadísticas) en las tablas?

Esta es una pregunta de negocios, no una pregunta técnica.

Como propietario de un negocio: ¿Qué tan estratégico es el sistema para el negocio? cuanto menos estratégico, menos me importa, lo reparo y el dinero gastado, es dinero que podría usar en otro lugar para hacer crecer mi negocio.

La gente de la computadora me asusta cuando todos entran en una habitación grande y discuten sobre el diseño y me cuestan una fortuna. ¡Mantén el sistema funcionando! ya sea que esto signifique un ajuste de rendimiento (sin rediseñar) o arrojarle más hardware, es solo una prioridad si deja de funcionar.

Como consultor de TI: su sistema es heredado y tiene costos operativos ocultos. Podemos diseñar un sistema que sea adecuado para usted, que se amplíe y brinde una plataforma para el crecimiento futuro y la ventaja estratégica. Firme aquí y todos sus sueños se harán realidad.

Como empleado de TI: ¡puedo ser el superhéroe aquí y salvar a la compañía evitando un desastre inminente al optimizar al máximo esta cosa! mi gerente me colmará de regalos y elogios, ya que habré ahorrado a la compañía miles.

Yo digo hacer las dos cosas.

¿Ahora estás en un 40% de CPU que dijiste? ¿Ya te estás quejando (mucho)? Si no, todavía tienes espacio para respirar. Más memoria podría ser suficiente para hacerlo por un tiempo.

Pregunta sobre el camino a seguir, ¿tiene desarrolladores de software internos? Si la respuesta es NO, entonces ni siquiera intentes rehacerla. Terminarás exactamente donde estás ahora.

Suponiendo que tiene desarrolladores internos, ¿tienen los desarrolladores internos la capacidad de hacer un proyecto correctamente? Estoy hablando de una línea de tiempo completa, adecuada (relistic), básicamente igual que si se tratara del proyecto de un cliente. Si no es así, no te molestes o terminará donde estás ahora.

Hasta que las empresas se den cuenta de que también son clientes de sí mismas y necesitan dar los mismos recursos a los proyectos internos, terminarás exactamente donde estás ahora. He estado allí, hecho eso, conseguí una cómoda completa de camisetas.

Entonces, si no puede hacerlo correctamente, tiene dos opciones listas para usar, lo que su personal odiará porque ahora tiene que adaptarse al molde del sistema que compra. O será personalizable y aún tendrá que pasar el tiempo del PROYECTO personalizándolo.

O Refactorice lo que tiene. Recuerde que las personas esperarán la misma funcionalidad completa cuando llegue la nueva, por eso, de cualquier otra manera, tiene que hacer todo de una vez. Si vuelve a factorizarlo, tiene la oportunidad de descubrir cómo funciona y luego, en lugar de realizar cambios ad-hoc, lo planifica en muchos pequeños subproyectos.

Sin ver el sistema, probablemente vería la normalización tanto como pueda en el back-end, mover la mayor parte del SQL a los procesos almacenados. Luego, cree un nuevo front-end ya sea con C # Forms o con una aplicación web. Si puede sacar su lógica de negocios y SQL del front end, será más fácil volver a hacerlo más tarde. Al guardar lo que haces en proyectos pequeños, si se deja de lado en cualquier momento o se detiene, habrás hecho progresos que se utilizarán.

Algunas buenas respuestas aquí ya, pero podría señalar que (suponiendo que haya desarrolladores internos) una cantidad relativamente pequeña de trabajo tendrá un gran impacto: agregue las claves principales (ni siquiera debería tener que cambiar todas sus consultas a úselos), agregue índices a los campos que sí usa, y ajuste sus consultas un poco y podría ver un aumento absolutamente enorme. Cómprate un poco de RAM para comprar el tiempo y el margen que necesitas para arreglarlo, y luego ponte a trabajar.

Sobre el tema de "arreglarlo o deshacerse de él", si las características del sistema básicamente funcionan para usted y hacen lo que necesita, no vuelva a escribir la rueda. Si sus usuarios tienen que hacer gimnasia para usar la cosa porque no se ajusta a sus necesidades, entonces no tiene sentido ponerle esfuerzo.

Bueno ... esto fue hace un tiempo, pero pensé que grabaría el resultado aquí.

Al final, pasé por el VBA línea por línea para lidiar con otro problema. Fue entonces cuando me di cuenta de que algunas llamadas para recuperar conjuntos de filas se bloquearon durante más de 20-30 segundos.

Cuando profundicé en ellos, descubrí que el conjunto de filas se basaba en una consulta de MS Access.

Eso fue seleccionar datos de otra consulta de Access.

Eso fue seleccionar datos de otra consulta de Access.

Todo lo cual parecía que habían sido arrastrados y soltados juntos usando el diseñador de consultas.

Revisé la media docena de puntos críticos del usuario y descubrí que sin falta todos eran exactamente lo mismo.

Así que eliminé por completo las pilas de consultas encadenadas y las reemplacé con una única consulta de transferencia que podría escribirse en T-SQL y ejecutarse directamente en el servidor.

La mejora fue absolutamente enorme en todos los casos sin falta y ya no hubo que esperar más consultas para nadie.

Y luego dejé la compañía. No tengo idea de si todavía está allí ... pero no lo extraño.

Estoy publicando una respuesta por separado en lugar de solo agregarla a la respuesta de Dayton porque hay un costo que las primeras personas no tienen en cuenta para publicar una respuesta: el costo de volver a capacitar a los usuarios y el costo de cambiar los procedimientos de su negocio para que encajen Un nuevo programa de software. De lo contrario, lo que dijo.

Una de las principales razones por las que las empresas desarrollan su propio software es que tienen procedimientos comerciales que no coinciden con algo que está en el mercado. Lo que es genial: los procedimientos comerciales individuales de una empresa son una parte importante del valor que una empresa aporta y SON la ventaja competitiva que una empresa tiene sobre el resto de su mercado. Reemplazar el software con algo genérico requeriría que vuelva a capacitar a su personal y sacrifique la ventaja competitiva, o tendría que personalizar la solución para que coincida con sus procesos comerciales. Ambos son caros y requieren mucho tiempo. Como consultor comercial y administrador de sistemas, he visto que estos costos matan a las pequeñas empresas por sí mismas.

Según sus declaraciones, parece que está prácticamente vinculado al procesador / software. Haría dos cosas: agregar índices (dentro de los límites), especialmente a las columnas que actualmente no los usan. Y arrojaría el conjunto más rápido de procesadores que pueda, porque parece que ahí es donde está vinculando si no tiene tantas lecturas de unidad en el pico.

(Además, actualizaría la edición del servidor en la medida de lo posible; para cuando lo instale, Access 2000 y SQL Server 2000 tendrán diez años. ¡Eso es ANTIGUO en años de computadora!)

Esto necesita una reestructuración total (reestructuración). Reconstruya el sistema desde cero. Esto le ahorrará mucho a largo plazo (costos generales en mantenimiento). Mientras tanto, tírele el hardware. Creo que esta pregunta es más un "caso de negocios" que una consulta técnica. Técnicamente, la respuesta es un rotundo "arrojar más poder". En cuanto a negocios, ¡construya un nuevo sistema!

Respuesta técnica:

Tienes una cantidad de sugerencias que indican que las claves principales y la indexación deben revisarse a fondo. A Access también le gusta usar una columna de SQL Server TimeStamp, también conocida como RowVersion, en cada tabla, ya que esto reduce mucho tiempo que Access dedica a decidir si un registro se ha cambiado a la hora de actualizar los registros.

Respuesta comercial:

Una nueva solución CRM es mucho trabajo en la capacitación de personas y nunca terminará con un sistema que se adapte exactamente a los requisitos de su negocio.

Encontraría una buena persona de Access que también es muy conocedora de SQL Server y conseguiría que pasara 3 o 6 meses normalizando las tablas y arreglando los puntos débiles del usuario. Asegúrese de que esa persona trabaje en los mismos pisos como sus usuarios, aunque en un espacio tranquilo y accesible. Aunque no demasiado accesible. A los desarrolladores no les gustan las interrupciones. S

Basado en la información dada, reemplazaría el sistema. Preferiblemente con otro CRM que permita una integración flexible con otros sistemas (que comprometería su ERP IS ).

La parte más difícil será convencer a la administración y a los usuarios de que necesiten una actualización.

administración

Exprese su preocupación por los problemas técnicos, el bajo rendimiento, el miedo a las fallas bizantinas, etc. Luego presente 2 CRM alternativos. Hable acerca de la integración empresarial, la estrategia general de ERP para el negocio y, lo más importante, cómo esto hará que los empleados sean más productivos y rentables. Estudios de casos de uso. No haga más de 15 minutos (a menos que quieran más información). Luego, debe convencer a los usuarios.

Los usuarios

Planes de capacitación (que un proveedor puede suministrar [y la administración necesitaría respaldar]), comunicación continua con el 20% superior de sus usuarios (los usuarios avanzados, aquellos que causan problemas) y un compromiso sólido para mantener el sistema 100% operativo durante el primer mes (el primer mes creará o interrumpirá cualquier IS nuevo).

Existen muchos productos CRM, elija el que mejor se adapte a las necesidades de su negocio.

Lanzar hardware solo fomenta un diseño y una administración más deficientes, hasta que el sistema sea tan patético que no funcionará bien incluso en el hardware más reciente y mejor. Es hora de ver una mejor implementación. Primero analice lo que se requiere. Solo cuando comprenda completamente los requisitos podrá comenzar a buscar la mejor manera de implementarlos. Una vez que esté seguro de comprender los requisitos, comience a analizar si es mejor / más rentable modificar lo que tiene o comenzar desde cero, posiblemente con algo completamente diferente.

A la larga, probablemente sería mejor rehacer la base de datos. Lanzarle más hardware resolverá su problema por un tiempo, pero si continúa usándolo, terminará teniendo que lanzarle más hardware después de un tiempo.

Por lo general, cuando hay problemas de rendimiento, se miran cosas como cuellos de botella de E / S en discos duros / RAID, fragmentación de la base de datos, etc., pero para cosas como fragmentación, es necesario que la base de datos esté diseñada adecuadamente para aprovecharla. Por lo que parece, su aplicación nunca podrá escalar.

A largo plazo, rehacer la base de datos y el software front-end para reflejar mejor sus necesidades comerciales actuales le servirá mejor a largo plazo. Sus usuarios se lo agradecerán, su hardware durará más y, a la larga, ahorrará mucho más dinero que arrojar hardware gigantesco al problema.

Dada su descripción, la creación de un sistema a medida completamente nuevo no tiene sentido: va a terminar justo donde comenzó, o tal vez incluso peor de lo que es ahora. Entonces, a menos que pueda convencer a alguien de comprar una solución de terceros, su mejor opción es refactorizar lo mejor que pueda y lanzarle hardware.

Yo diría que debe hacer dos cosas: 1) Análisis de rendimiento en el servidor SQL. Parece que ha identificado el lado del servidor como la fuente de los retrasos, por lo que ahora necesita saber qué consultas están retrasadas y por qué. Con toda probabilidad, puede encontrar algunas consultas de puntos críticos para optimizar que le brindarán grandes beneficios. Demonios, si tiene clientes que se actualizan cada pocos segundos, vea si puede disminuir su velocidad de actualización (¿REALMENTE la lista en la pantalla necesita actualizarse cada 5 segundos? ¿Sería 30 correcto? Si no, ¿qué tal 15? ) Las cosas tontas como aumentar los temporizadores de actualización podrían ahorrarle una gran cantidad de sobrecarga, si puede salirse con la suya.

2) Lanza más hardware. ESPECIALMENTE arroja grandes cantidades de carnero. Desea tanta memoria que la base de datos se ajuste completamente en la RAM. Esté atento a su sistema operativo y versiones de software ( aparentemente hay muchas reglas con las versiones de Windows y qué hardware realmente admiten). Si puedes convencerte a ti mismo de que más núcleos ayudarían, entonces lanza tantas CPU y núcleos como puedas.

Has mencionado RAM y procesadores, pero no discos. Admito que ha pasado casi una década desde que traté con el servidor SQL de MS, pero está vinculado a los discos tanto como a cualquier otra base de datos, si no cabe en la memoria.

Probablemente primero intentaría llenar la máquina con tanta RAM como sea posible, luego me aseguraría de que los registros se escriban en discos que no se usan para tablas o índices. Luego trataría de asegurarme de que ninguna tabla tenga sus índices en el mismo eje.

Después de eso, me preocuparía el ajuste del nivel de la base de datos, pero con eso, tendrá que definir sus pruebas y un objetivo de optimización para que no rompa las cosas o empeore las consultas. Aunque dijo que las claves primarias no mostraban mucha ventaja en su base de datos de prueba, debe mirar su metodología de prueba: las claves primarias pueden permitir que algunas bases de datos (no estoy seguro si MS SQL es una de ellas) usen el bloqueo de nivel de registro , en lugar de bloqueos a nivel de tabla, que pueden reducir la contención que podría no mostrarse en las pruebas con solo unos pocos usuarios.

Primero, estoy de acuerdo con Kyle Hodgson y agrego PK. Es barato (solo tiempo) y es posible que vea un aumento en sus consultas. ¿Qué pasa con los índices en las columnas de unión en sus 10 consultas más feas? ¿Dónde están los escaneos de mesa?

Segundo, ¿qué pasa con el recorte de datos en la base de datos? ¿Se devuelven más filas en las consultas de las que realmente se necesitan? También estoy de acuerdo con la sugerencia de RAM de Kyle (dos GB más).

Pon todo esto en tu redacción (Joseph Kern) sobre lo que propones para el interino mientras trazas el futuro. Pregunte a la gerencia y a los usuarios qué le sucede a la organización si la aplicación CRM actual se bloquea y no está disponible. Quizás eso los ayude a pensar en el futuro.

¡Consigue el hardware!

Por el momento, la lata no solo es muy barata si eliges un chip de la serie Xeon 55xx, sino que gritará por cualquier cosa que puedas arrojarle.

Es solo una cuestión de riesgo / recompensa: puede gastar dinero y mucho tiempo mejorando la base de datos o comprar su camino más rápido y más barato.

Considere activar el interruptor de memoria de 3GB y agregar otros 2GB de memoria.