servidor excesivamente lento

[cacr]

Saludos

Hay tres servidores sql server 2000, uno para cada BD de la ofic. La excusa es que no soporta ponerlo todo en uno sólo, pero creo que es un problema de:
1.- configuración del sevidor +
2.- diseño de la BD +
3.- ancho de banda
4.- configuración de los equipos computacionales

Vale decir, que no hay un administrador de BD designado. Yo estoy preparando el terreno para una migración a postgresql...

la Pregunta: existe alguna forma, desde php u otra, de medir el rendimiento del servidor sql y de las consultas?

Gracias de una

[monkyta]

Cuando empiezan a aparecer sintomas de lentitud; lo primero que hay que revisar son todos los procedimientos almacenados o querys que se lanzan al servidor y medir los tiempos..... esto usando show plan, etc. o usando el analizador de consultas del sql server.... De ahi, podras ver que muchas de las querys realizan table scan y por ende, las querys corren muy lentas.... si eso ocurre, deberas de revisar cada tabla y verificar que en cada una de ellas exista a lo menos un indice unico clustered, mas otros indices que sean altamente usados.... sino existen dichos indices, debes de crearlos y volver a recompilar cada procedimiento.... despues vuelves a hacer show plan para ver los tiempos involucrados.
Si despues de la revision exhaustiva a todos los procesos sospechosos del alto consumo de recursos; deberas de seguir con la configuracion del sql server y de la maquina en donde esta alojado; en terminos de uso de cpu, memoria utilizada, etc... ademas, se deben de ajustar muchos parametros de configuracion que no siempre vienen bien seteados; como por ejemplo, el del tamaño del packet_size para manejo de ancho de banda; el de maximo de conexiones, del maximo del locks permitidos, memoria asignada al servidor sql, etc.Por parte de la maquina; debes de revisar que otros servicios estan instalados y que procesos mas carga el servidor.
Tambien, es bueno que las bases de datos que son muy voluminosas, separar en diferentes discos el area de data, log e indices no clustered
Por parte del cliente; siempre es bueno balancear la carga de trabajo; es decir, tratar siempre por todos los medios realizar las operaciones al sql server usando llamadas a procedimientos almacenados en vez de sql embutidos; ya que estos usan mucho ancho de banda por tener que enviarse toda la query cada vez... esto satura.... tambien se satura el ancho de banda cuando hay querys por ejemplo que extraen miles y miles de filas en un solo tiempo; esto hay que evitarlo por todos los medios; ya sea, acotando las querys por medio del where o bien, usando set rowcount xxxx, o select top xxx......

Eso es lo que puedo aportar por ahora

[cacr]

vale...

Olvidé decir que la BD más grande, tiene alrededor de los 24 mil registros...

[monkyta]

Hubieses partido por ahí.... el problema esta claro que no es servidor fisico ni servidor sql server.... son tus programas, tablas sin indices o procedimientos almacenados mal construidos..... revisa esto y veras que tengo razón

[cacr]

te creo... y te creo justamenet, porque no son mis programas...

Se supone que me contrataron para rehacer todo lo que no sirve, pero los verdaderos dueños de esos programas, que aún trabajan aquí, no me dan la información necesaria, ni colaboran con el rediseño de los procesos y bases de datos... y claro, como no tengo la suficiente autoridad, pues....

Ahora bien, (esto se está convirtiendo en OT), si la migración es un hecho a otro SMBD, no tiene sentido reparar los fallos, ¿cierto? ¿es mejor adrle de una con el rediseño?

[monkyta]

Hay veces que tiene mucho sentido; es cuando, el modelo que migras es identico al origen; con excepcion de los tipos de datos; que pueden cambiarse sin afectar el modelo... en este caso, siempre es aconsejable, optimizar y reparar lo malo antes de proceder..... yo he participado en varias migraciones vsam-db2, db2-datacom, datacom-sybase , sybase-sqlserver, y otras y te anticipo que me ha tocado arreglar las fallas antes de migrar, y otras, botar todo el modelo y partir de cero, solo con las especificaciones claras de lo que se quiere y ambas son costosas.
Ademas, cuando haces reingenieria completa de modelo, implica reprogramar todo... y eso es otro cuento

[Mithrandir]

corre perfmon (desde la terminal de DOS). Ahi verás andanadas de medidores de rendimiento para el servidor. Incluso lo puedes medir remotamente

Meterse a monitorear la actividad con el SQL Profiler es otra buena opcion. Monitorea las sentencias más usadas y asegúrate de tener índices en esas tablas (y sobre esos campos).

Sobre las sentencias más usadas particularmente puedes revisar el plan de ejecución y revisar que sea el qurý más óptimo en términos de rendimiento, aunque esto ya es mucho más esotérico y requiere más conocimiento del servidor.