Problema de SQL Lento

Carlos,

de los datos que adjuntas (de 50 minutos de trabajo) veo lo siguiente:

Procesador:
sin mucho trabajo; mínimo 0.5%, máximo 94,1% y MEDIA!!! 24.77%
Tamaño de la cola de entrada en procesador: me indica un valor máximo de 14;
sin embargo los valores mínimo, último y media 0.
El procesador no tiene carga de trabajo a considerar

SQL Server:
Recompilaciones por segundo; valor medio de 0.004; BUENO!, hay que
recompilar poco
Buffer Cache hit ratio: media de 98.6%!!!! BUENÍSIMO! las páginas que
necesita están casi siempre en caché; esto quiere decir que el 1.4% de las
veces que SQL Server necesita una página de datos tiene que ir a leerlas de
disco.
Procedure Cache Pages: una media de 61.000 páginas de planes de ejecución en
caché; BUENO!
Como ves SQL Server va sobrado también.

Memoria:
Páginas por segundo: Max.160, min.0; media 5.0; 5 páginas de media que se
leen/escriben de disco; eso es poquísimo.
Fallos de página por segundo: Max. 1696.0, min.25.9; media 153.8; quiere
decir que la página está en memoria pero en otra ubicación; no es un valor
malo.
Tampoco veo problemas de memoria,

De este análisis de 50 minutos (sería prudente tenerlo de un perido de
tiempo más grande), puedo decir que no hay ningun dato que indique que hay
problemas en el servidor;

me gustaría ver los contadores de bloqueos:
SQL Server: Locks Object:Average Wait Time(ms)
SQL Server: Locks Object:Lock Timeouts/sec
SQL Server: Locks Object:Lock Waits/sec
SQL Server: Locks Object:Number of Deadlocks/sec

también quisiera algún contador más de memoria:
SQL Server: Memory Manager Object:Target Server Memory(KB)
SQL Server: Memory Manager Object:Total Server Memory(KB)


Otra cosa; has comentado que has establecido los parametros de diskperf para
los contadores de disco; hasta donde yo se, esa reconfiguración no tiene
efecto hasta que se ha reiniciado del servidor; sobre lo que comentas de que
no ves ningún valor para los dispositivos lógicos de disco no lo entiendo...

Otra cosilla; dices que funciona lento el servidor; ¿cual es la sensación?
en general, ciertos procesos, cuando hay muchos usuarios conectados,

Saludos,

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Carlo Sorrel" wrote in message
news:Ovj$

Aqui va de nuevo.., parece que es muy grande..., va en Zip...
"Eladio Rincón" escribió en el mensaje
news:#R$
> Hola Carlos,
>
> coincido con Alberto en que lo primero que hay que identificar es el
> problema; he leido el hilo varias veces y no acabo de ver que hayas
llegado
> a la conclusión de que estamos ante un problema de disco; para ello,

como

ha
> comentado Alberto, debes ejecutar el monitor de rendimiento para ver la
> causa del problema; el monitor de rendimiento lo puedes ejecutar desde
> cualquier pc en el que hayas logeado con un usuario que tiene permisos

de

> administrador sobre el servidor (net use \\servidor ...); de esta forma
> ejecutará perfmon desde tu pc sin cargar al servidor con una aplicación
más;
>
> para empezar podríamos ver cual es la carga de trabajo de procesador,

uso

de
> memoria y discos (como ya se ha comentado)...
>
> mira a ver si puedes obtener valores de estos contadores:
>
> Procesador:
> Processor/% Processor Time,
> System/Processor Queue Length
> Processor Queue es el tamaño medio de la cola de espera de procesos a

ser

> atendidos por el procesador.
>
> Memoria:
> Pages/sec
> Page Faults/sec
> Qué obtenemos de aquí? Pages/sec es el número de páginas que se leen por
> segundo de disco; Page Faults/sec es el número de de páginas que ha
> necesitado leer el procesador de disco o de otra posición de memoria;
>
> Discos (como has comentado que no tienes acceso a contadores de disco
> físico, leeremos de Logical Disk):
> % Disk Time
> Avg. Disk Queue Length
> de aquí? % Disk Time no necesita ser explicado; Avg. Disk Queue Length

es

el
> tamaño de la cola de espera de procesos a realizar operaciones de E/S:
Este
> valor habrá que dividirlos por el número de discos que formen en
dispositivo
> lógico.
>
> Añadiría los siguientes contadores de SQL Server:
> SQL Server:Buffer Manager/Buffer cache hit ratio:
> Muy importante: indica el porcentaje de acierto de páginas requeridas

por

> SQL Server que ya se encuentran en memoria; si este contador es bajo,
quiere
> decir que tenemos un problema; consultas que se hacen sobre el servidor

y

no
> se encuentran en memoria, hay que traerlas a memoria; para ello se
necesita
> leer las páginas de datos lo cual requiere acceso a disco...
> SQL Server:Buffer Manager/Procedure cache pages:
> Muy importante también; indica las páginas de planes de ejecución de
> procedimientos almacenados y consultas que se encuentran en caché; qué
> quiere decir esto? si está en caché no hay que compilar el plan, lo cual
> quiere decir que no tendremos que "gastar" CPU/memoria en compilar el
> plan...
> SQL Server: SQL Statistics Object/SQL Recompilations:
> Sentencia SQL que se recompilan por segundo; las consecuencias son
similares
> a las del contador anterior.
>
> mandanos resultados de estos contadores para saber más cosas de tu
problema
>
> Eladio Rincón
> SQL Server MVP
>
> Solid Quality Learning (http://www.solidqualitylearning.com)
> "Comparte lo que sabes, aprende lo que no sepas", FGG
>
> Consulte el histórico del grupo en Google
> http://groups.google.com/groups?gro....sqlserver
>
> ¿Te interesa participar en las reuniones
> del grupo de Usuarios de SQL-Server y .NET
> Se harán en levante de España, (Alicante o Murcia)?
>
> "Carlo Sorrel" wrote in message
> news:
> > Gracias por su apoyo muchachos, de corazon, con respecto a tus
> > consultas..., no utilizamos Full-Text search, no corre ninguna
> > re-indexación durante las horas laborales (las 24 hrs. en mi caso)...,
> > corren solamente los días domingo, desgraciamdamente la base es

tan

> > grande que no se alcanza a realizar completa, por lo que ya opte por
> > re-indexar a mano las tablas mas utilizadas, y no, no se han
realizado
> > cambios de nodo ultimamente.
> > Ya tengo agendado para estas noches cambios de tablas e indices...,

voy

a
> > crear dos filegroup en raid 1 distintos..., como se tratan los indices
en
> > este caso..???, deben quedar todos en el mismo filegroup..???
> >
> > "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
> > news:
> > > Hola.
> > >
> > > Por partes. Como sabes, para que se activen los contadores de disco,
> debes
> > > hacer un reinicio (ojo, antes de hacer el cambio de nodo, para todos
los
> > > contadores que tengas, en concreto los de SQL o los perderás

también).

> > Luego,
> > > es posible que obtengas una ralentización aún mayor, pero tienes que
> poner
> > > contadores o no sabrás qué pasa. Ponlos desde otra máquina, por
> supuesto.
> > En
> > > pocos minutos tendrás una primera aproximación para seguir
investigando.
> > >
> > > Por decir un par de cosas,
> > > - ¿tienes full-text search? Si lo tienes, asegurate de que el
> catálogo
> > > está funcionando. A veces se queda roto y las consultas te van a las
> > tablas
> > > directamente (las que sean compatibles, claro), con lo que el

servidor

> > entero
> > > se muere y es muy difícil de dar con ello. Para arreglarlo (en caso

de

> que
> > no
> > > vaya) le haces un full populate.
> > > - asegúrate de que ninguna reindexación (las cuales harás más o
menos
> a
> > > menudo), ningún backup, ningún chequeo de integridad está corriendo

en

> el
> > > servidor fuera de su horario normal. Si crees que el problema es de
> disco,
> > > estas operaciones lo agravarían.
> > > - ¿Has cambiado el servicio de nodo últimamente? En ocasiones, un
> nodo
> > > está instalado diferente que el otro, por ahí te pueden llegar
infinidad
> > de
> > > problemas.
> > >
> > > En fin, suerte y no dejes de comentarnos.
> > >
> > > qwalgrande
> > >
> > > "Carlo Sorrel" wrote:
> > >
> > > > En realidad no todavia..., con contadores tomados anteriormente

todo

> > > > indicaba a los discos..., tenian un encolamiento horrible,

pero

> > ahora
> > > > estamos re-estructurando de a poco, pero no notamos cambios..., y
ayer
> > se
> > > > puso horriblemente lento..., lo cual persiste el día de hoy.,

en

> > > > realidad no se que puede estar pasando, ahora se me sumo otro
> > > > problema..., al agregarle discos a la maquina, se me

desaparecieron

> los
> > > > contadores de disco, active el diskperf pero no pasa nada...,
> alguna
> > > > idea...???
> > > >
> > > > "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
> > > > news:
> > > > > Hola.
> > > > >
> > > > > Te voy a indicar los que yo mido para todo lo relacionado con la
> red,
> > que
> > > > no
> > > > > significa que sean los perfectos:
> > > > > Network Interface: Bytes Total/sec
> > > > > Network Segment: % Network Utilization
> > > > > Network Interface: Current Bandwidth
> > > > > Server: Bytes Received/sec
> > > > > Server: Bytes Transm/sec
> > > > > SQL Server: SQL Statistics: Batch Request/sec
> > > > >
> > > > > ¿Tienes ya alguna pista de por dónde puede estar el cuello de
> botella?
> > > > >
> > > > > qwalgrande
> > > > > "Carlo Sorrel" wrote:
> > > > >
> > > > > > Me podrias indicar que puedo medir de la interface de red por
> > favor,
> > > > ese
> > > > > > no lo he medido
> > > > > >
> > > > > > "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el
mensaje
> > > > > > news:
> > > > > > > Hola.
> > > > > > >
> > > > > > > Necesitas averiguar dónde tienes el cuello (o cuellos) de
> botella.
> > > > Para
> > > > > > ello
> > > > > > > pon unos contadores (los de siempre) para determinar si el
mayor
> > > > problema
> > > > > > lo
> > > > > > > tienes en CPU, memoria, I/O, red o del propio SQL Server. Te
> > podría
> > > > decir
> > > > > > un
> > > > > > > montón de contadores, pero no sé si estás familiarizado con

el

> > tema,
> > > > con
> > > > > > lo
> > > > > > > que seguramente sabrás cuáles poner. Dependiendo del

resultado

> que
> > > > > > observes,
> > > > > > > las medidas a tomar serán unas u otras, pero para arreglar

el

> > > > problema,
> > > > > > > primero hay que saber cuál es el problema. Cualquier otra

cosa

> > sería
> > > > dar
> > > > > > > palos de ciego.
> > > > > > >
> > > > > > > Si quieres más info, no dudes en preguntar.
> > > > > > >
> > > > > > > qwalgrande
> > > > > > >
> > > > > > > "Carlo Sorrel" wrote:
> > > > > > >
> > > > > > > > Si le hago..., de hecho el log me pesa actualmente unos 60
> > mb.,
> > > > de 9
> > > > > > Gb
> > > > > > > > que tiene de espacio asignado, el gran problema es que
la
> > base
> > > > es de
> > > > > > > > Solomon, la cual no se puede modificar mucho, es un
> producto
> > ERP
> > > > de
> > > > > > > > Microsoft, y en realidad me tiene loco, te
cuento,
> > esta
> > > > > > maquina
> > > > > > > > esta en Cluster, con otra de similares

caracteristicas,

lo
> > único
> > > > que
> > > > > > > > hace es dar el Servicio de SQL..., a mi juicio es un
> > maquinon,
> > > > el
> > > > > > > > problema puede estar en que es un Raid 5 con 8 discos, el
log
> lo
> > > > tengo
> > > > > > > > separado y la tempdb tambien, pero aún asi esta lento,
el
> > > > problema
> > > > > > esta
> > > > > > > > basicamente al realizar las liberaciones de datos...,
bloquea
> > casi
> > > > las
> > > > > > > > tablas en forma completa
> > > > > > > > "MAXI" escribió en el
mensaje
> > > > > > > > news:
> > > > > > > > > Hola, pues primero habria que identificar si el problema
es
> en
> > el
> > > > > > servidor
> > > > > > > > > de BDD.
> > > > > > > > >
> > > > > > > > > Podrias mirar para ello algunos contadores como por ej
> > > > > > > > >
> > > > > > > > > Utilizacion CPU
> > > > > > > > > Escritura en disco
> > > > > > > > >
> > > > > > > > > Si esto esta ok, yo revisaria el tema de bloqueos con el
> > profiler
> > > > por
> > > > > > ej.
> > > > > > > > >
> > > > > > > > > Le haces un mantenimiento al log no?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Maxi
> > > > > > > > >
> > > > > > > > > Buenos Aires - Argentina
> > > > > > > > > Desarrollador .NET 3 Estrellas
> > > > > > > > > Microsoft User Group (MUG)
> > > > > > > > >
> > > > > > > > > MSN:
> > > > > > > > > "Carlo Sorrel" escribió en el
mensaje
> > > > > > > > > news:%23Qr$
> > > > > > > > > > Estimados, necesito ayuda, tengo un Solomon 5.0 que
ataca
> > una
> > > > base
> > > > > > de
> > > > > > > > > > datos
> > > > > > > > > > SQL 2000 Enterprise Edition con una maquina de 2
> > procesadores
> > > > Xeon
> > > > > > MP de
> > > > > > > > > > 2Mb
> > > > > > > > > > de cache y 6 GB de RAM, la base pesa actualmente 97

GB,

la
> > cual
> > > > > > trabaja
> > > > > > > > > > sumamente lento. Tengo el log separado en otro disco
duro,
> > la
> > > > tempdb
> > > > > > > > > > tambien
> > > > > > > > > > en otros disco, con respaldos de Log cada 20 minutos,
> > > > diferenciales
> > > > > > > > > > diarios
> > > > > > > > > > y Full Semanal, pero de todas formas es muy lento. Que
me
> > puede
> > > > > > estar
> > > > > > > > > > pasando...???, Seria recomendable realizar
> filegroup's..???,
> > los
> > > > > > indices
> > > > > > > > > > como deben quedar...???
> > > > > > > > > > Agradezco cualquier ayuda que me puedan dar..???
> > > > > > > > > >
> > > > > > > > > > Atte.,
> > > > > > > > > > Carlo Sorrel
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
>
>

Eladio, primero que nada, gracias por tomarte el tiempo de analizar los
datos que envie., contestando tus preguntas...
Al momento de asignarle mas discos al Servidor, se perdieron esos contadores
(los de discos), los actiive en su momento con el diskperf y bootee
nuevamente la maquina, pero no aparecen..., la gente me dice que funciona
lento, al momento de cargar datos masivos, liberar estos datos dentro del
SQL., esta maquina esta en exclusividad para albergar las bases de
nuestro ERP Solomon IV versión 5.0 (de Microsoft). La cantidad de data que
se mueve es exorbitante, piensa que la base crece un promedio de 360 Mb
diario.., lo cual creo que es bastante..., la base pesa actualmente 97
Gb, con una taza de creciemiento promedio los últimos meses de 8 GB. Voy a
agregar los contadores que me solictaste y te los envio.
De neuvo muchas gracias.
Saludos.

Atte.,
Carlo Sorrel

"Eladio Rincón" escribió en el mensaje
news:

Carlos,

de los datos que adjuntas (de 50 minutos de trabajo) veo lo siguiente:

Procesador:
sin mucho trabajo; mínimo 0.5%, máximo 94,1% y MEDIA!!! 24.77%
Tamaño de la cola de entrada en procesador: me indica un valor máximo de

14;

sin embargo los valores mínimo, último y media 0.
El procesador no tiene carga de trabajo a considerar

SQL Server:
Recompilaciones por segundo; valor medio de 0.004; BUENO!, hay que
recompilar poco
Buffer Cache hit ratio: media de 98.6%!!!! BUENÍSIMO! las páginas que
necesita están casi siempre en caché; esto quiere decir que el 1.4% de las
veces que SQL Server necesita una página de datos tiene que ir a leerlas

de

disco.
Procedure Cache Pages: una media de 61.000 páginas de planes de ejecución

en

caché; BUENO!
Como ves SQL Server va sobrado también.

Memoria:
Páginas por segundo: Max.160, min.0; media 5.0; 5 páginas de media que se
leen/escriben de disco; eso es poquísimo.
Fallos de página por segundo: Max. 1696.0, min.25.9; media 153.8; quiere
decir que la página está en memoria pero en otra ubicación; no es un valor
malo.
Tampoco veo problemas de memoria,

De este análisis de 50 minutos (sería prudente tenerlo de un perido de
tiempo más grande), puedo decir que no hay ningun dato que indique que hay
problemas en el servidor;

me gustaría ver los contadores de bloqueos:
SQL Server: Locks Object:Average Wait Time(ms)
SQL Server: Locks Object:Lock Timeouts/sec
SQL Server: Locks Object:Lock Waits/sec
SQL Server: Locks Object:Number of Deadlocks/sec

también quisiera algún contador más de memoria:
SQL Server: Memory Manager Object:Target Server Memory(KB)
SQL Server: Memory Manager Object:Total Server Memory(KB)


Otra cosa; has comentado que has establecido los parametros de diskperf

para

los contadores de disco; hasta donde yo se, esa reconfiguración no tiene
efecto hasta que se ha reiniciado del servidor; sobre lo que comentas de

que

no ves ningún valor para los dispositivos lógicos de disco no lo

entiendo...

Otra cosilla; dices que funciona lento el servidor; ¿cual es la sensación?
en general, ciertos procesos, cuando hay muchos usuarios conectados,

Saludos,

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"Carlo Sorrel" wrote in message
news:Ovj$
> Aqui va de nuevo.., parece que es muy grande..., va en Zip...
> "Eladio Rincón" escribió en el mensaje
> news:#R$
> > Hola Carlos,
> >
> > coincido con Alberto en que lo primero que hay que identificar es el
> > problema; he leido el hilo varias veces y no acabo de ver que hayas
> llegado
> > a la conclusión de que estamos ante un problema de disco; para ello,
como
> ha
> > comentado Alberto, debes ejecutar el monitor de rendimiento para ver

la

> > causa del problema; el monitor de rendimiento lo puedes ejecutar desde
> > cualquier pc en el que hayas logeado con un usuario que tiene permisos
de
> > administrador sobre el servidor (net use \\servidor ...); de esta

forma

> > ejecutará perfmon desde tu pc sin cargar al servidor con una

aplicación

> más;
> >
> > para empezar podríamos ver cual es la carga de trabajo de procesador,
uso
> de
> > memoria y discos (como ya se ha comentado)...
> >
> > mira a ver si puedes obtener valores de estos contadores:
> >
> > Procesador:
> > Processor/% Processor Time,
> > System/Processor Queue Length
> > Processor Queue es el tamaño medio de la cola de espera de procesos a
ser
> > atendidos por el procesador.
> >
> > Memoria:
> > Pages/sec
> > Page Faults/sec
> > Qué obtenemos de aquí? Pages/sec es el número de páginas que se leen

por

> > segundo de disco; Page Faults/sec es el número de de páginas que ha
> > necesitado leer el procesador de disco o de otra posición de memoria;
> >
> > Discos (como has comentado que no tienes acceso a contadores de disco
> > físico, leeremos de Logical Disk):
> > % Disk Time
> > Avg. Disk Queue Length
> > de aquí? % Disk Time no necesita ser explicado; Avg. Disk Queue Length
es
> el
> > tamaño de la cola de espera de procesos a realizar operaciones de E/S:
> Este
> > valor habrá que dividirlos por el número de discos que formen en
> dispositivo
> > lógico.
> >
> > Añadiría los siguientes contadores de SQL Server:
> > SQL Server:Buffer Manager/Buffer cache hit ratio:
> > Muy importante: indica el porcentaje de acierto de páginas requeridas
por
> > SQL Server que ya se encuentran en memoria; si este contador es bajo,
> quiere
> > decir que tenemos un problema; consultas que se hacen sobre el

servidor

y
> no
> > se encuentran en memoria, hay que traerlas a memoria; para ello se
> necesita
> > leer las páginas de datos lo cual requiere acceso a disco...
> > SQL Server:Buffer Manager/Procedure cache pages:
> > Muy importante también; indica las páginas de planes de ejecución de
> > procedimientos almacenados y consultas que se encuentran en caché; qué
> > quiere decir esto? si está en caché no hay que compilar el plan, lo

cual

> > quiere decir que no tendremos que "gastar" CPU/memoria en compilar el
> > plan...
> > SQL Server: SQL Statistics Object/SQL Recompilations:
> > Sentencia SQL que se recompilan por segundo; las consecuencias son
> similares
> > a las del contador anterior.
> >
> > mandanos resultados de estos contadores para saber más cosas de tu
> problema
> >
> > Eladio Rincón
> > SQL Server MVP
> >
> > Solid Quality Learning (http://www.solidqualitylearning.com)
> > "Comparte lo que sabes, aprende lo que no sepas", FGG
> >
> > Consulte el histórico del grupo en Google
> > http://groups.google.com/groups?gro....sqlserver
> >
> > ¿Te interesa participar en las reuniones
> > del grupo de Usuarios de SQL-Server y .NET
> > Se harán en levante de España, (Alicante o Murcia)?
> >
> > "Carlo Sorrel" wrote in message
> > news:
> > > Gracias por su apoyo muchachos, de corazon, con respecto a tus
> > > consultas..., no utilizamos Full-Text search, no corre ninguna
> > > re-indexación durante las horas laborales (las 24 hrs. en mi

caso)...,

> > > corren solamente los días domingo, desgraciamdamente la base es
tan
> > > grande que no se alcanza a realizar completa, por lo que ya opte por
> > > re-indexar a mano las tablas mas utilizadas, y no, no se han
> realizado
> > > cambios de nodo ultimamente.
> > > Ya tengo agendado para estas noches cambios de tablas e indices...,
voy
> a
> > > crear dos filegroup en raid 1 distintos..., como se tratan los

indices

> en
> > > este caso..???, deben quedar todos en el mismo filegroup..???
> > >
> > > "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
> > > news:
> > > > Hola.
> > > >
> > > > Por partes. Como sabes, para que se activen los contadores de

disco,

> > debes
> > > > hacer un reinicio (ojo, antes de hacer el cambio de nodo, para

todos

> los
> > > > contadores que tengas, en concreto los de SQL o los perderás
también).
> > > Luego,
> > > > es posible que obtengas una ralentización aún mayor, pero tienes

que

> > poner
> > > > contadores o no sabrás qué pasa. Ponlos desde otra máquina, por
> > supuesto.
> > > En
> > > > pocos minutos tendrás una primera aproximación para seguir
> investigando.
> > > >
> > > > Por decir un par de cosas,
> > > > - ¿tienes full-text search? Si lo tienes, asegurate de que el
> > catálogo
> > > > está funcionando. A veces se queda roto y las consultas te van a

las

> > > tablas
> > > > directamente (las que sean compatibles, claro), con lo que el
servidor
> > > entero
> > > > se muere y es muy difícil de dar con ello. Para arreglarlo (en

caso

de
> > que
> > > no
> > > > vaya) le haces un full populate.
> > > > - asegúrate de que ninguna reindexación (las cuales harás más o
> menos
> > a
> > > > menudo), ningún backup, ningún chequeo de integridad está

corriendo

en
> > el
> > > > servidor fuera de su horario normal. Si crees que el problema es

de

> > disco,
> > > > estas operaciones lo agravarían.
> > > > - ¿Has cambiado el servicio de nodo últimamente? En ocasiones,

un

> > nodo
> > > > está instalado diferente que el otro, por ahí te pueden llegar
> infinidad
> > > de
> > > > problemas.
> > > >
> > > > En fin, suerte y no dejes de comentarnos.
> > > >
> > > > qwalgrande
> > > >
> > > > "Carlo Sorrel" wrote:
> > > >
> > > > > En realidad no todavia..., con contadores tomados anteriormente
todo
> > > > > indicaba a los discos..., tenian un encolamiento horrible,
pero
> > > ahora
> > > > > estamos re-estructurando de a poco, pero no notamos cambios...,

y

> ayer
> > > se
> > > > > puso horriblemente lento..., lo cual persiste el día de

hoy.,

en
> > > > > realidad no se que puede estar pasando, ahora se me sumo

otro

> > > > > problema..., al agregarle discos a la maquina, se me
desaparecieron
> > los
> > > > > contadores de disco, active el diskperf pero no pasa

nada...,

> > alguna
> > > > > idea...???
> > > > >
> > > > > "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el

mensaje

> > > > > news:
> > > > > > Hola.
> > > > > >
> > > > > > Te voy a indicar los que yo mido para todo lo relacionado con

la

> > red,
> > > que
> > > > > no
> > > > > > significa que sean los perfectos:
> > > > > > Network Interface: Bytes Total/sec
> > > > > > Network Segment: % Network Utilization
> > > > > > Network Interface: Current Bandwidth
> > > > > > Server: Bytes Received/sec
> > > > > > Server: Bytes Transm/sec
> > > > > > SQL Server: SQL Statistics: Batch Request/sec
> > > > > >
> > > > > > ¿Tienes ya alguna pista de por dónde puede estar el cuello de
> > botella?
> > > > > >
> > > > > > qwalgrande
> > > > > > "Carlo Sorrel" wrote:
> > > > > >
> > > > > > > Me podrias indicar que puedo medir de la interface de red

por

> > > favor,
> > > > > ese
> > > > > > > no lo he medido
> > > > > > >
> > > > > > > "qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el
> mensaje
> > > > > > > news:
> > > > > > > > Hola.
> > > > > > > >
> > > > > > > > Necesitas averiguar dónde tienes el cuello (o cuellos) de
> > botella.
> > > > > Para
> > > > > > > ello
> > > > > > > > pon unos contadores (los de siempre) para determinar si el
> mayor
> > > > > problema
> > > > > > > lo
> > > > > > > > tienes en CPU, memoria, I/O, red o del propio SQL Server.

Te

> > > podría
> > > > > decir
> > > > > > > un
> > > > > > > > montón de contadores, pero no sé si estás familiarizado

con

el
> > > tema,
> > > > > con
> > > > > > > lo
> > > > > > > > que seguramente sabrás cuáles poner. Dependiendo del
resultado
> > que
> > > > > > > observes,
> > > > > > > > las medidas a tomar serán unas u otras, pero para arreglar
el
> > > > > problema,
> > > > > > > > primero hay que saber cuál es el problema. Cualquier otra
cosa
> > > sería
> > > > > dar
> > > > > > > > palos de ciego.
> > > > > > > >
> > > > > > > > Si quieres más info, no dudes en preguntar.
> > > > > > > >
> > > > > > > > qwalgrande
> > > > > > > >
> > > > > > > > "Carlo Sorrel" wrote:
> > > > > > > >
> > > > > > > > > Si le hago..., de hecho el log me pesa actualmente unos

60

> > > mb.,
> > > > > de 9
> > > > > > > Gb
> > > > > > > > > que tiene de espacio asignado, el gran problema es

que

> la
> > > base
> > > > > es de
> > > > > > > > > Solomon, la cual no se puede modificar mucho, es un
> > producto
> > > ERP
> > > > > de
> > > > > > > > > Microsoft, y en realidad me tiene loco, te
> cuento,
> > > esta
> > > > > > > maquina
> > > > > > > > > esta en Cluster, con otra de similares
caracteristicas,
> lo
> > > único
> > > > > que
> > > > > > > > > hace es dar el Servicio de SQL..., a mi juicio es un
> > > maquinon,
> > > > > el
> > > > > > > > > problema puede estar en que es un Raid 5 con 8 discos,

el

> log
> > lo
> > > > > tengo
> > > > > > > > > separado y la tempdb tambien, pero aún asi esta

lento,

> el
> > > > > problema
> > > > > > > esta
> > > > > > > > > basicamente al realizar las liberaciones de datos...,
> bloquea
> > > casi
> > > > > las
> > > > > > > > > tablas en forma completa
> > > > > > > > > "MAXI" escribió en el
> mensaje
> > > > > > > > > news:
> > > > > > > > > > Hola, pues primero habria que identificar si el

problema

> es
> > en
> > > el
> > > > > > > servidor
> > > > > > > > > > de BDD.
> > > > > > > > > >
> > > > > > > > > > Podrias mirar para ello algunos contadores como por ej
> > > > > > > > > >
> > > > > > > > > > Utilizacion CPU
> > > > > > > > > > Escritura en disco
> > > > > > > > > >
> > > > > > > > > > Si esto esta ok, yo revisaria el tema de bloqueos con

el

> > > profiler
> > > > > por
> > > > > > > ej.
> > > > > > > > > >
> > > > > > > > > > Le haces un mantenimiento al log no?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Maxi
> > > > > > > > > >
> > > > > > > > > > Buenos Aires - Argentina
> > > > > > > > > > Desarrollador .NET 3 Estrellas
> > > > > > > > > > Microsoft User Group (MUG)
> > > > > > > > > >
> > > > > > > > > > MSN:
> > > > > > > > > > "Carlo Sorrel" escribió en el
> mensaje
> > > > > > > > > > news:%23Qr$
> > > > > > > > > > > Estimados, necesito ayuda, tengo un Solomon 5.0 que
> ataca
> > > una
> > > > > base
> > > > > > > de
> > > > > > > > > > > datos
> > > > > > > > > > > SQL 2000 Enterprise Edition con una maquina de 2
> > > procesadores
> > > > > Xeon
> > > > > > > MP de
> > > > > > > > > > > 2Mb
> > > > > > > > > > > de cache y 6 GB de RAM, la base pesa actualmente 97
GB,
> la
> > > cual
> > > > > > > trabaja
> > > > > > > > > > > sumamente lento. Tengo el log separado en otro disco
> duro,
> > > la
> > > > > tempdb
> > > > > > > > > > > tambien
> > > > > > > > > > > en otros disco, con respaldos de Log cada 20

minutos,

> > > > > diferenciales
> > > > > > > > > > > diarios
> > > > > > > > > > > y Full Semanal, pero de todas formas es muy lento.

Que

> me
> > > puede
> > > > > > > estar
> > > > > > > > > > > pasando...???, Seria recomendable realizar
> > filegroup's..???,
> > > los
> > > > > > > indices
> > > > > > > > > > > como deben quedar...???
> > > > > > > > > > > Agradezco cualquier ayuda que me puedan dar..???
> > > > > > > > > > >
> > > > > > > > > > > Atte.,
> > > > > > > > > > > Carlo Sorrel
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> >
> >
>
>
>

Hola.

Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa hoy.
Espero que nos lo sigas contando.

Además de los contadores que indicó Eladio, que están orientados a buscar
problemas de bloqueos, yo le pondría un par de ellos más, los dos del mismo
objeto:
SQLServer Access Method: Page Split/sec
SQLServer Access Method: Full Scans/sec

El motivo, intentar elucubrar si hay problemas de indexación sin usar los
contadores de disco. Un valor alto en estos contadores puede indicarnos que
la indexación no es todo lo buena que debiera. Sería una mala noticia, ya
que en un producto cerrado, tocar la indexación puede traerte otros
contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una traza de
profiler para traernos consultas con muchas lecturas lógicas y/o mucho
tiempo con ciertas garantías.

(por cierto, Carlo, hemos tenido mucha suerte con la participación de
Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de estos
de rendimiento y contadores siempre acaba dejándome con la boca abierta.
Eladio, gracias por otra lección más.)

qwalgrande

opino lo mismo.., realmente es MUY BUENO.
Agregare los contadores que me comentas

"qwalgrande" escribió en el mensaje
news:

Hola.

Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa

hoy.

Espero que nos lo sigas contando.

Además de los contadores que indicó Eladio, que están orientados a buscar
problemas de bloqueos, yo le pondría un par de ellos más, los dos del

mismo

objeto:
SQLServer Access Method: Page Split/sec
SQLServer Access Method: Full Scans/sec

El motivo, intentar elucubrar si hay problemas de indexación sin usar los
contadores de disco. Un valor alto en estos contadores puede indicarnos

que

la indexación no es todo lo buena que debiera. Sería una mala noticia, ya
que en un producto cerrado, tocar la indexación puede traerte otros
contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una traza

de

profiler para traernos consultas con muchas lecturas lógicas y/o mucho
tiempo con ciertas garantías.

(por cierto, Carlo, hemos tenido mucha suerte con la participación de
Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de

estos

de rendimiento y contadores siempre acaba dejándome con la boca abierta.
Eladio, gracias por otra lección más.)

qwalgrande

estos problemas "enganchan" de verdad... luego subes a las tantas a dormir y
tu novia te lo acaba confirmando con un lacónico "estás enganchaooo!" :-)

lección? por los datos enviados por Carlo, saltaba a la vista que el
servidor estaba muy "relajado"... a ver quien se atreve a interpretar la
siguiente traza que nos pase Carlo... eso si será un reto ;-)

Por cierto, gracias a Carlo por poder conseguir los contadores que le hemos
pedido porque como sabes, no siempre se puede auditar un servidor como
desearíamos, ¿verdad? ;-)

Eladio Rincón
SQL Server MVP

Solid Quality Learning (http://www.solidqualitylearning.com)
"Comparte lo que sabes, aprende lo que no sepas", FGG

Consulte el histórico del grupo en Google
http://groups.google.com/groups?gro....sqlserver

¿Te interesa participar en las reuniones
del grupo de Usuarios de SQL-Server y .NET
Se harán en levante de España, (Alicante o Murcia)?

"qwalgrande" wrote in message
news:

Hola.

Yo al menos sigo intrigado con este tema. No sé cómo irá ahora la cosa

hoy.

Espero que nos lo sigas contando.

Además de los contadores que indicó Eladio, que están orientados a buscar
problemas de bloqueos, yo le pondría un par de ellos más, los dos del

mismo

objeto:
SQLServer Access Method: Page Split/sec
SQLServer Access Method: Full Scans/sec

El motivo, intentar elucubrar si hay problemas de indexación sin usar los
contadores de disco. Un valor alto en estos contadores puede indicarnos

que

la indexación no es todo lo buena que debiera. Sería una mala noticia, ya
que en un producto cerrado, tocar la indexación puede traerte otros
contratiempos. Si por aquí encontráramos algo, nos tiraríamos a una traza

de

profiler para traernos consultas con muchas lecturas lógicas y/o mucho
tiempo con ciertas garantías.

(por cierto, Carlo, hemos tenido mucha suerte con la participación de
Eladio, a ver si puede seguir ahí y no se "desengancha", con temas de

estos

de rendimiento y contadores siempre acaba dejándome con la boca abierta.
Eladio, gracias por otra lección más.)

qwalgrande