Rendimiento

Hola Inte:
Me alegra "ver" a un Tico por aqui. Yo empezaria por monitorear las
siguientes medidas (Nombres en Ingles) de SQL, aparte de los recuros del
Sistema Operativo (Procesador, Disco, Memoria y Red):
SLQServer:Buffer Manager- Buffer Cache Hit Ratio: Idealmente 99% es
bueno si es mayor de 95%. Mas bajo de eso, probablemente memoria ayudaria.
Revisar Indices y Estadisticas.
SQLServer:Latches: Average Lacth Wait Time: Bloqueo de recursos
internos, Valores altos son problemas de bloqueos, normalmente por diseno de
la aplicacion, difiles de solucionar con Hardware.
SQLServer:Locks: Average Wait Time: Cuellos de Botella por bloqueos,
valores altos son normalmente problemas de diseno de aplicacion, dificiles
de solucionar con hardware.
SQLServer:Locks - Lock Timeouts/sec: Peticiones de bloqueos por
segundo cuyo tiempo de espera se agotó, incluidas peticiones internas de
bloqueos NOWAIT. Indicador de cuellos de botella por bloqueos en el
Servidor.

Podrias cambiar la configuracion del BOOT.INI para incrementar la
memoria RAM a 3Gb si agregas el parametro asi:
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Advanced Server"
/3Gb /basevideo /sos

Es normal que el procesador suba con alguna frecuencia a 100%, pero no
es bueno que permaneza de forma consistente ahi.
Dudo que la defragmentacion de disco ayude. Problemas en los Discos
Duros (bloques malos) producen este tipo de problema, asegurate respaldos.
Algunas otras ideas sueltas: Se estan ejecutando planes de mantenimiento
con Reindexacion y Revision de la BD?, Estas las Estadisticas en la BD en
AutoCreate y AutoUpdate?, Estan los clientes usando OLE-DB o ODBC?.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Inte escribio:

Nuestro Servidor:
SQL 2K Standard + SP3a
W2K Server + SP4
2 Processador Xeon 933 MHz
4 GB de RAM
100GB en Raid 5 (donde esta SQL) a 10K RPM
Conexion a 1GB

Ambiente:
90 Estaciones accesando al SQL donde 35 pueden hacer actualizaciones
simultaneamente mientras que las otras hacen consultas constantes via
Crystal Reports 8.5

Se que la version standard solo soporta hasta 2 GB en RAM y el
monitoreo de esta se mantiene en 1.8 GB. En cambio los procesadores
es comun verlos cerca del 100% de utilizacion, casi todo corresponde
al proceso sqlservr.exe, provocando que el sistema se vuelva muy
lento. Antes se podia monitorear picos que se acercaban al 100%.

Que tal la idea de considerar el desfragmentar el disco donde reside
el SQL?

Alguna sugerencia para q la utilizacion del CPU no suba tanto?

Saludos!

Antes aparecia con Jaisol, el mismo del mensaje: Sobre archivos LOG (LDF)
... del 5/20/2003
Cambie el nick x motivos de trabajo.
X cierto javier, te debo una llamadita. Queda p' este lunes sin falta
gracias nuevamente.


"Javier Loria" wrote in message
news:eo%

Hola Inte:
Me alegra "ver" a un Tico por aqui. Yo empezaria por monitorear las
siguientes medidas (Nombres en Ingles) de SQL, aparte de los recuros del
Sistema Operativo (Procesador, Disco, Memoria y Red):
SLQServer:Buffer Manager- Buffer Cache Hit Ratio: Idealmente 99%

es

bueno si es mayor de 95%. Mas bajo de eso, probablemente memoria ayudaria.
Revisar Indices y Estadisticas.
SQLServer:Latches: Average Lacth Wait Time: Bloqueo de recursos
internos, Valores altos son problemas de bloqueos, normalmente por diseno

de

la aplicacion, difiles de solucionar con Hardware.
SQLServer:Locks: Average Wait Time: Cuellos de Botella por

bloqueos,

valores altos son normalmente problemas de diseno de aplicacion, dificiles
de solucionar con hardware.
SQLServer:Locks - Lock Timeouts/sec: Peticiones de bloqueos por
segundo cuyo tiempo de espera se agotó, incluidas peticiones internas de
bloqueos NOWAIT. Indicador de cuellos de botella por bloqueos en el
Servidor.

Podrias cambiar la configuracion del BOOT.INI para incrementar la
memoria RAM a 3Gb si agregas el parametro asi:
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Advanced Server"
/3Gb /basevideo /sos

Es normal que el procesador suba con alguna frecuencia a 100%, pero no
es bueno que permaneza de forma consistente ahi.
Dudo que la defragmentacion de disco ayude. Problemas en los Discos
Duros (bloques malos) producen este tipo de problema, asegurate respaldos.
Algunas otras ideas sueltas: Se estan ejecutando planes de

mantenimiento

con Reindexacion y Revision de la BD?, Estas las Estadisticas en la BD en
AutoCreate y AutoUpdate?, Estan los clientes usando OLE-DB o ODBC?.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Inte escribio:
> Nuestro Servidor:
> SQL 2K Standard + SP3a
> W2K Server + SP4
> 2 Processador Xeon 933 MHz
> 4 GB de RAM
> 100GB en Raid 5 (donde esta SQL) a 10K RPM
> Conexion a 1GB
>
> Ambiente:
> 90 Estaciones accesando al SQL donde 35 pueden hacer actualizaciones
> simultaneamente mientras que las otras hacen consultas constantes via
> Crystal Reports 8.5
>
> Se que la version standard solo soporta hasta 2 GB en RAM y el
> monitoreo de esta se mantiene en 1.8 GB. En cambio los procesadores
> es comun verlos cerca del 100% de utilizacion, casi todo corresponde
> al proceso sqlservr.exe, provocando que el sistema se vuelva muy
> lento. Antes se podia monitorear picos que se acercaban al 100%.
>
> Que tal la idea de considerar el desfragmentar el disco donde reside
> el SQL?
>
> Alguna sugerencia para q la utilizacion del CPU no suba tanto?
>
> Saludos!

Antes aparecia con Jaisol, el mismo del mensaje: Sobre archivos LOG (LDF)
... del 5/20/2003
Cambie el nick x motivos de trabajo.
X cierto javier, te debo una llamadita. Queda p' este lunes sin falta
gracias nuevamente.


"Javier Loria" wrote in message
news:eo%

Hola Inte:
Me alegra "ver" a un Tico por aqui. Yo empezaria por monitorear las
siguientes medidas (Nombres en Ingles) de SQL, aparte de los recuros del
Sistema Operativo (Procesador, Disco, Memoria y Red):
SLQServer:Buffer Manager- Buffer Cache Hit Ratio: Idealmente 99%

es

bueno si es mayor de 95%. Mas bajo de eso, probablemente memoria ayudaria.
Revisar Indices y Estadisticas.
SQLServer:Latches: Average Lacth Wait Time: Bloqueo de recursos
internos, Valores altos son problemas de bloqueos, normalmente por diseno

de

la aplicacion, difiles de solucionar con Hardware.
SQLServer:Locks: Average Wait Time: Cuellos de Botella por

bloqueos,

valores altos son normalmente problemas de diseno de aplicacion, dificiles
de solucionar con hardware.
SQLServer:Locks - Lock Timeouts/sec: Peticiones de bloqueos por
segundo cuyo tiempo de espera se agotó, incluidas peticiones internas de
bloqueos NOWAIT. Indicador de cuellos de botella por bloqueos en el
Servidor.

Podrias cambiar la configuracion del BOOT.INI para incrementar la
memoria RAM a 3Gb si agregas el parametro asi:
multi(0)disk(0)rdisk(0)partition(1)\WINNT="Windows 2000 Advanced Server"
/3Gb /basevideo /sos

Es normal que el procesador suba con alguna frecuencia a 100%, pero no
es bueno que permaneza de forma consistente ahi.
Dudo que la defragmentacion de disco ayude. Problemas en los Discos
Duros (bloques malos) producen este tipo de problema, asegurate respaldos.
Algunas otras ideas sueltas: Se estan ejecutando planes de

mantenimiento

con Reindexacion y Revision de la BD?, Estas las Estadisticas en la BD en
AutoCreate y AutoUpdate?, Estan los clientes usando OLE-DB o ODBC?.
Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.

Inte escribio:
> Nuestro Servidor:
> SQL 2K Standard + SP3a
> W2K Server + SP4
> 2 Processador Xeon 933 MHz
> 4 GB de RAM
> 100GB en Raid 5 (donde esta SQL) a 10K RPM
> Conexion a 1GB
>
> Ambiente:
> 90 Estaciones accesando al SQL donde 35 pueden hacer actualizaciones
> simultaneamente mientras que las otras hacen consultas constantes via
> Crystal Reports 8.5
>
> Se que la version standard solo soporta hasta 2 GB en RAM y el
> monitoreo de esta se mantiene en 1.8 GB. En cambio los procesadores
> es comun verlos cerca del 100% de utilizacion, casi todo corresponde
> al proceso sqlservr.exe, provocando que el sistema se vuelva muy
> lento. Antes se podia monitorear picos que se acercaban al 100%.
>
> Que tal la idea de considerar el desfragmentar el disco donde reside
> el SQL?
>
> Alguna sugerencia para q la utilizacion del CPU no suba tanto?
>
> Saludos!