Problema de SQL Lento

Vale, pondre un profiler..., disculpa la consulta, pero que contadores
necesitas de eso.?????

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

Hola,

yo he visto algo pero no llego a ver la causa:

Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure

cache

pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que el
valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de 200

MB,

ok?

quitando esa escala de tiempo, si pasamos a la traza completa, tenemos un
máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto si
está bien.

para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo a
escala 3000, verás que "valle" hay formado...

otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad de
fallos de página altísimo: media de 470 fallos de página por segundo y un
máximo de 2613!!! eso indica que en ese momento los disco estaban

trabajando

a tope

¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el proceso
de inserción masiva que comentas; deberías poner profiler para ver qué
operaciones llegan al servidor, y si eres capaz de encontrar las más
costosas, creo que estaremos en buen camino...


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 no le veo nada. Tienes bloqueos, pero muchos. El page Split no es

alto

> (salvo momentos puntuales) y Full Scan tampoco tiene muchos.
>
> Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que

no

> vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta que
no
> se reinicie).
>
> Asumiendo que los problemas son de disco, comentaste que haces backup

del

> log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de
log?
> ¿Tienes separados los datos del log en discos diferentes? ¿Y el backup,

lo

> haces a los mismos discos o a otros distintos?
>
> qwalgrande
>
> qwalgrande
>
>
> "Carlo Sorrel" wrote in message
> news:%
> Estiamdos, el archivo es bastante grande para poder postearlo..., lo

estoy

> comprimiendo en RAR. Aqui va de nuevo.
> "Eladio Rincón" escribió en el mensaje
> news:
> > 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
> > >
> > >
> >
> >
>
>
>
>

Hola,

en ese minuto se suceden los fallos de página que seguramente derivan el
lecturas físicas;
sin embargo, la bajada del caché de procedimientos es entre las 10.00 y las
12.30; y la bajada es considerable; de 1.6GB usados en los extremos del
rango a una media de poco menos de 160MB: es diez veces menos!

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:OEUw$

Hola.

Lo que no veo es un motivo para la ralentización "en general". Si estamos
hablando de un periodo de 1 minuto que coincide con una hora en punto, es

la

típica hora en que se lanzan las cosas gordas, pero tendríamos un problema
de rendimiento puntual, no una sensación de lentitud en general. La

verdad,

yo no le saco punta a esto.

Carlo, ¿sería posible que pusieras una traza con profiler para traerte las
consultas que tarden más de 2000 milisegundos? Igual nos encontramos con

que

hay alguna consulta que se repite cientos de veces y que habría que tratar
de optimizar al máximo.

qwalgrande


"Eladio Rincón" wrote in message
news:
Hola,

yo he visto algo pero no llego a ver la causa:

Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure

cache

pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que el
valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de 200

MB,

ok?

quitando esa escala de tiempo, si pasamos a la traza completa, tenemos un
máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto si
está bien.

para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo a
escala 3000, verás que "valle" hay formado...

otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad de
fallos de página altísimo: media de 470 fallos de página por segundo y un
máximo de 2613!!! eso indica que en ese momento los disco estaban

trabajando

a tope

¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el proceso
de inserción masiva que comentas; deberías poner profiler para ver qué
operaciones llegan al servidor, y si eres capaz de encontrar las más
costosas, creo que estaremos en buen camino...


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 no le veo nada. Tienes bloqueos, pero muchos. El page Split no es

alto

> (salvo momentos puntuales) y Full Scan tampoco tiene muchos.
>
> Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que

no

> vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta que
no
> se reinicie).
>
> Asumiendo que los problemas son de disco, comentaste que haces backup

del

> log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de
log?
> ¿Tienes separados los datos del log en discos diferentes? ¿Y el backup,

lo

> haces a los mismos discos o a otros distintos?
>
> qwalgrande
>
> qwalgrande
>
>
> "Carlo Sorrel" wrote in message
> news:%
> Estiamdos, el archivo es bastante grande para poder postearlo..., lo

estoy

> comprimiendo en RAR. Aqui va de nuevo.
> "Eladio Rincón" escribió en el mensaje
> news:
> > 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
> > >
> > >
> >
> >
>
>
>
>

Estimados, les cuento que tengo corriendo las trazas solicitadas, además que
nos hemos podido habilitar los contadores de disco, por lo que estare esta
noche reinstalando la maquina de cero, por lo que en "teoria" deberian
quedar operativos los benditos contadores mañana, es linda esta vida
no...???, mi señora esta con la sonrisa de oreja a oreja.
Saludos y Gracias nuevamente por su ayuda.

Atte.,
Carlo Sorrel

"Carlo Sorrel" escribió en el mensaje
news:

Vale, pondre un profiler..., disculpa la consulta, pero que contadores
necesitas de eso.?????

"Eladio Rincón" escribió en el mensaje
news:
> Hola,
>
> yo he visto algo pero no llego a ver la causa:
>
> Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure
cache
> pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que

el

> valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de 200
MB,
> ok?
>
> quitando esa escala de tiempo, si pasamos a la traza completa, tenemos

un

> máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto si
> está bien.
>
> para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo a
> escala 3000, verás que "valle" hay formado...
>
> otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad de
> fallos de página altísimo: media de 470 fallos de página por segundo y

un

> máximo de 2613!!! eso indica que en ese momento los disco estaban
trabajando
> a tope
>
> ¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el

proceso

> de inserción masiva que comentas; deberías poner profiler para ver qué
> operaciones llegan al servidor, y si eres capaz de encontrar las más
> costosas, creo que estaremos en buen camino...
>
>
> 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 no le veo nada. Tienes bloqueos, pero muchos. El page Split no es
alto
> > (salvo momentos puntuales) y Full Scan tampoco tiene muchos.
> >
> > Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que
no
> > vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta

que

> no
> > se reinicie).
> >
> > Asumiendo que los problemas son de disco, comentaste que haces backup
del
> > log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de
> log?
> > ¿Tienes separados los datos del log en discos diferentes? ¿Y el

backup,

lo
> > haces a los mismos discos o a otros distintos?
> >
> > qwalgrande
> >
> > qwalgrande
> >
> >
> > "Carlo Sorrel" wrote in message
> > news:%
> > Estiamdos, el archivo es bastante grande para poder postearlo..., lo
estoy
> > comprimiendo en RAR. Aqui va de nuevo.
> > "Eladio Rincón" escribió en el mensaje
> > news:
> > > 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
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>

¿Qué tal fue la intervención? ¿Hemos mejorado algo?

Sobre la traza que mandaste, salvo una consulta de unos 6 minutos y otro par
o tres que parecían verse bloqueadas, la verdad es que son muy pocas
consultas lentas para una hora de actividad. A lo mejor el problema está en
muchísimas consultas muy pequeñas. Quizá sería por donde habría que seguir
mirando.

qwalgrande


"Carlo Sorrel" wrote in message
news:%23$
Estimados, les cuento que tengo corriendo las trazas solicitadas, además que
nos hemos podido habilitar los contadores de disco, por lo que estare esta
noche reinstalando la maquina de cero, por lo que en "teoria" deberian
quedar operativos los benditos contadores mañana, es linda esta vida
no...???, mi señora esta con la sonrisa de oreja a oreja.
Saludos y Gracias nuevamente por su ayuda.

Atte.,
Carlo Sorrel

"Carlo Sorrel" escribió en el mensaje
news:

Vale, pondre un profiler..., disculpa la consulta, pero que contadores
necesitas de eso.?????

"Eladio Rincón" escribió en el mensaje
news:
> Hola,
>
> yo he visto algo pero no llego a ver la causa:
>
> Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure
cache
> pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que

el

> valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de 200
MB,
> ok?
>
> quitando esa escala de tiempo, si pasamos a la traza completa, tenemos

un

> máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto si
> está bien.
>
> para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo a
> escala 3000, verás que "valle" hay formado...
>
> otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad de
> fallos de página altísimo: media de 470 fallos de página por segundo y

un

> máximo de 2613!!! eso indica que en ese momento los disco estaban
trabajando
> a tope
>
> ¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el

proceso

> de inserción masiva que comentas; deberías poner profiler para ver qué
> operaciones llegan al servidor, y si eres capaz de encontrar las más
> costosas, creo que estaremos en buen camino...
>
>
> 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 no le veo nada. Tienes bloqueos, pero muchos. El page Split no es
alto
> > (salvo momentos puntuales) y Full Scan tampoco tiene muchos.
> >
> > Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo que
no
> > vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta

que

> no
> > se reinicie).
> >
> > Asumiendo que los problemas son de disco, comentaste que haces backup
del
> > log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup de
> log?
> > ¿Tienes separados los datos del log en discos diferentes? ¿Y el

backup,

lo
> > haces a los mismos discos o a otros distintos?
> >
> > qwalgrande
> >
> > qwalgrande
> >
> >
> > "Carlo Sorrel" wrote in message
> > news:%
> > Estiamdos, el archivo es bastante grande para poder postearlo..., lo
estoy
> > comprimiendo en RAR. Aqui va de nuevo.
> > "Eladio Rincón" escribió en el mensaje
> > news:
> > > 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
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
>
>

Hola,

Carlo también comentó que había procesos de "inserción maviva" de datos,
pero no hemos visto nada de eso todavía...

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:

¿Qué tal fue la intervención? ¿Hemos mejorado algo?

Sobre la traza que mandaste, salvo una consulta de unos 6 minutos y otro

par

o tres que parecían verse bloqueadas, la verdad es que son muy pocas
consultas lentas para una hora de actividad. A lo mejor el problema está

en

muchísimas consultas muy pequeñas. Quizá sería por donde habría que seguir
mirando.

qwalgrande


"Carlo Sorrel" wrote in message
news:%23$
Estimados, les cuento que tengo corriendo las trazas solicitadas, además

que

nos hemos podido habilitar los contadores de disco, por lo que estare esta
noche reinstalando la maquina de cero, por lo que en "teoria" deberian
quedar operativos los benditos contadores mañana, es linda esta vida
no...???, mi señora esta con la sonrisa de oreja a oreja.
Saludos y Gracias nuevamente por su ayuda.

Atte.,
Carlo Sorrel

"Carlo Sorrel" escribió en el mensaje
news:
> Vale, pondre un profiler..., disculpa la consulta, pero que

contadores

> necesitas de eso.?????
>
> "Eladio Rincón" escribió en el mensaje
> news:
> > Hola,
> >
> > yo he visto algo pero no llego a ver la causa:
> >
> > Entre las 10.59 de la mañana y las 12.28, el valor máximo de Procedure
> cache
> > pages es 25725, el medio 19684 y el mínimo 12101; eso quiere decir que
el
> > valor máximo ha sido 25725 * 8 KB = 205800 KB que está por encima de

200

> MB,
> > ok?
> >
> > quitando esa escala de tiempo, si pasamos a la traza completa, tenemos
un
> > máximo de 202441 * 8 KB que representa 1619528 KB; más de 1.6GB; esto

si

> > está bien.
> >
> > para que veas el bajón en proc. caché, puedes abrir la traza y ponerlo

a

> > escala 3000, verás que "valle" hay formado...
> >
> > otra cosa que he visto; entre las 11.59 y las 12.01 hay una cantidad

de

> > fallos de página altísimo: media de 470 fallos de página por segundo y
un
> > máximo de 2613!!! eso indica que en ese momento los disco estaban
> trabajando
> > a tope
> >
> > ¿puedes decirnos que pasa en esos periodos de tiempo? Quizás es el
proceso
> > de inserción masiva que comentas; deberías poner profiler para ver qué
> > operaciones llegan al servidor, y si eres capaz de encontrar las más
> > costosas, creo que estaremos en buen camino...
> >
> >
> > 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 no le veo nada. Tienes bloqueos, pero muchos. El page Split no es
> alto
> > > (salvo momentos puntuales) y Full Scan tampoco tiene muchos.
> > >
> > > Por tanto, dado que no es de nada de lo que vemos, ha de ser de lo

que

> no
> > > vemos, es decir, de disco (cuyos contadores seguimos sin tener hasta
que
> > no
> > > se reinicie).
> > >
> > > Asumiendo que los problemas son de disco, comentaste que haces

backup

> del
> > > log cada 20 minutos. ¿Cuánto tiempo necesita para hacer cada backup

de

> > log?
> > > ¿Tienes separados los datos del log en discos diferentes? ¿Y el
backup,
> lo
> > > haces a los mismos discos o a otros distintos?
> > >
> > > qwalgrande
> > >
> > > qwalgrande
> > >
> > >
> > > "Carlo Sorrel" wrote in message
> > > news:%
> > > Estiamdos, el archivo es bastante grande para poder postearlo..., lo
> estoy
> > > comprimiendo en RAR. Aqui va de nuevo.
> > > "Eladio Rincón" escribió en el mensaje
> > > news:
> > > > 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
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>