Bajo Rendimiento sql2000 | SQL Server Performance Forums

SQL Server Performance Forum – Threads Archive

Bajo Rendimiento sql2000

Hola, tengo un servidor CompaqProliant de 4 procesadores PIII a 500MHz, con 1Gg de Memoria Ram, y 3HD que en total suman 160 Gigas. Tengo instalado W2000 Server con Sp2 y hasta hace un par de semanas tenia SqlServer7 instalado. Ahora he migrado a Sql2000 standard edition SP3. La migracion la hice haciendo un backup de la B.D., desinstalando el sql7, instalando sql2000, creé las B.D. en vacio y luego hice un restore (no tuve ningun tipo de problema). Al servidor "atacan" unos 60 usuarios con una aplicacion Cliente/servidor, a una base de Datos de unos 11 gigas. El problema es que desde la migracion la aplicacion va mucho mas lenta, hasta ese momento iba todo muy bien y tenia todos los indices necesarios.
¿que es lo que puede mirar para detectar el problema?¿Puede que los indices que en sql7 iban bien ahora en sql2000 pueden bajar rendimiento?¿necesito a lo mejor mas memoria? Ademas tengo otra pregunta, yo hasta ahora tenia puesto en el sql7 que hiciera el autoshrink y el recalculo de estadistica automaticamente, he leido que no lo recomiendas. Tengo unos planes de mantenimiento todas las noches que hacen un backup, validacion de la integridad y Reorganizacion de indices. ¿con esto ya es necesario?¿la reorganizacion recalcula todas las estadisticas?¿el job que hace el shrink lo programo antes o despues de la reorganizacion?¿creo otro job que recalcules las estadisticas con el 100% de los datos? ¿Debo desmarcar en las propiedades del servidor "Aumentar la prioridad de sql en windows" y "utilizar intraprocesos de windows Nt"? Muchas gracias.
Bueno vamos por partes. El problema de la baja de performance al pasar de sql7 a 2000 en un 90% se debe a la actulización de estadísticas. Cuando hiciste el backup y restore en el sql2000, es necesario actualizar todas las estadísticas en un 100%. Te suguiero que a tu base las dejes con autocreate statistics on y con autoupdate statistics off.
Con respecto a la reindexación de índices, de hecho implica update statiscics de la tabla que se reindexan los índices. Un buena idea sería crear un job que ejecute el reindex de acuerdo a la necesidad y no a todas las tablas aunque no lo necesiten. Para eso te recomiento leer el Artículo de Tom Pullen en este Forum en la sección Artículos, en donde encontrarás un procedimiento que reindexa índices de acuerdo a la fragmentación del mismo. Con respecto al shrink, este proceso deshace todo lo realizado anteriormente en cuanto a actualizar estadísticas o reindexar índices.
Por lo tanto, si te resulta imprescindible realizar el shrink, entonces hacelo luego del backup, pero antes de reindexar o actulizar estadísticas. Si optas por implementar la store procedure de Tom Pullen, te sugiero qenerar un job que se ejecute todos lo días para actualizar las estadísticas de las tablas más críticas, y en fin de semana un job que actualize las estadísticas de toda la base. Esto es dado que, el proceso de Tom, solo reindexa los indices necesarios y, por lo tanto, las estadísticas se actualizan solamente de esos índices. Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
Gracias por tu respuesta, pero sigo teniendo alguna duda, la reorganizacion de Indices hace un recalculo de las estadisticas, pero, ¿lo hace para el 100% de los datos? ¿es necesario crear un job que recalcule los indice para un 100%?
Además, ¿Debo desmarcar en las propiedades del servidor "Aumentar la prioridad de sql en windows" y "utilizar intraprocesos de windows Nt"?
El modo fibra (intraprocesos) se activa o desactiva usando el parámetro "lightweight pooling" de SQL Server. El valor default es "0", lo que significa que el modo fibra está desactivado. En términos generales, el modo fibra se beneficioso cuando se dan las siguientes condiciones: •El servidor tiene dos o más CPUs (a mayor cantidad de CPUs, mayor es el beneficio).
•Todas las CPUs están corriendo cerca de su capacidad máxima (95-100%) la mayoría del tiempo.
•Hay una gran cantidad de cambios de contexto (context switching) ocurriendo en el servidor (reportado por el contador del Performance Monitor llamado System Object: Context Switches/sec. Más de 5,000 cambios de contexto por segundo se considera elevado).
•SQL Server está haciendo poco o ningún uso de queries distribuidos o extended stored procedures. Microsoft recomienda desmarcar en la propiedad de servidor "Aumentar la prioridad de sql en windows".

Con respecto al tema de reorganización de índices, el hecho de reindexar todos los índices de una tabla, implica el update statistics del 100%. Los índices se reorganizan o no, no tiene términos medios, por eso te decía que si utilizas el procedimiento de Tom Pullen, tu debes tener jobs diarios que actualicen las estadísticas de las tabla más críticas y de todas en el fin de semana.
Luis Martin
Moderator
SQL-Server-Performance.com One of the symptoms of an approaching nervous breakdown is the belief that one’s work is terribly important
Bertrand Russell
All postings are provided “AS IS” with no warranties for accuracy.
Hola, Tengo el siguiente problema: Tengo algunos SP que tardan demasiado tiempo (cerca de 20 segundos), pero luego de editarlos y sin tocar nada del codigo vuelvo a correrlo (o sea, hago un alter sin modificar nada), el tiempo de proceso desciende a menos de un segundo. Esto me sucedía anteriormente con SQL 7, y desde que migré a 2005 me sucede más seguido, ¿Que puede estar sucediendo? Gracias! Saludos!
Luego de la migración a 2005, has actualizado las estadísticas?. Por otro lado te suguiero siempre habrir un post nuevo cada vez que inicies un tema. Saludos,
Luis Martin
Moderator
SQL-Server-Performance.com All in Love is Fair
Stevie Wonder
All postings are provided “AS IS” with no warranties for accuracy.
]]>