Problema de SQL Lento

08/02/2005 - 01:01 por Carlo Sorrel | Informe spam
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

Preguntas similare

Leer las respuestas

#11 qwalgrande
08/02/2005 - 17:57 | Informe spam
Hola.

Aquí estamos para ayudarnos, aunque sea moralmente. Con respecto a lo que
comentas, me reitero en lo que te dije anteriormente, necesitas saber cuál es
el problema y hasta que no des con el problema no podrás solucionarlo (salvo
que tengas suerte y las acciones que tomes resulten perfectas para lo que te
ocurre). ¿No puedes poner contadores? ¿No puedes tampoco poner una traza,
aunque sea para ver si hay alguna consulta que tarde mucho y/o se repita
mucho? En cualquier caso, todo mi ánimo y mucha calma.

Sobre los filegroups, lo típico es colocar los índices clustered y los datos
por un lado y los índices no clustered por otro.

qwalgrande

"Carlo Sorrel" wrote:

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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >



Respuesta Responder a este mensaje
#12 Carlo Sorrel
08/02/2005 - 19:19 | Informe spam
como es eso de los indices no clustered por otro...???, en otro disco..???

"qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
news:
Hola.

Aquí estamos para ayudarnos, aunque sea moralmente. Con respecto a lo que
comentas, me reitero en lo que te dije anteriormente, necesitas saber cuál


es
el problema y hasta que no des con el problema no podrás solucionarlo


(salvo
que tengas suerte y las acciones que tomes resulten perfectas para lo que


te
ocurre). ¿No puedes poner contadores? ¿No puedes tampoco poner una traza,
aunque sea para ver si hay alguna consulta que tarde mucho y/o se repita
mucho? En cualquier caso, todo mi ánimo y mucha calma.

Sobre los filegroups, lo típico es colocar los índices clustered y los


datos
por un lado y los índices no clustered por otro.

qwalgrande

"Carlo Sorrel" wrote:

> 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>
Respuesta Responder a este mensaje
#13 Maxi
08/02/2005 - 20:47 | Informe spam
Carlos, podrias empezar por poner el log en solo 300mb y probar? creo que
eso podria ayudarte mucho


Salu2
Maxi


"Carlo Sorrel" escribió en el mensaje
news:
como es eso de los indices no clustered por otro...???, en otro disco..???

"qwalgrande" <qwalgrande*nospam*@yahoo.es> escribió en el mensaje
news:
Hola.

Aquí estamos para ayudarnos, aunque sea moralmente. Con respecto a lo que
comentas, me reitero en lo que te dije anteriormente, necesitas saber
cuál


es
el problema y hasta que no des con el problema no podrás solucionarlo


(salvo
que tengas suerte y las acciones que tomes resulten perfectas para lo que


te
ocurre). ¿No puedes poner contadores? ¿No puedes tampoco poner una traza,
aunque sea para ver si hay alguna consulta que tarde mucho y/o se repita
mucho? En cualquier caso, todo mi ánimo y mucha calma.

Sobre los filegroups, lo típico es colocar los índices clustered y los


datos
por un lado y los índices no clustered por otro.

qwalgrande

"Carlo Sorrel" wrote:

> 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>
>




Respuesta Responder a este mensaje
#14 Eladio Rincón
08/02/2005 - 21:13 | Informe spam
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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > > >
> >
> >
> >


Respuesta Responder a este mensaje
#15 Carlo Sorrel
08/02/2005 - 21:38 | Informe spam
Estimados, nuevamente gracias por su ayuda..., Maxi, ya tengo el log en 1
GB, no puedo achicarlo más, ya que crece alrededor de ese tamaño cada 20
minutos..., lo cual me degradaria mas la maquina con el autogrow, con
respecto a lo que comentaba Eladio, tengo corriendo los contadores (tampoco
me muestra los de LogicalDisk), por lo que tengo todos los otros
disponibles, apenas tenga al menos una hora de muestra lo posteo para que lo
miren.

"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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >
>
>


Respuesta Responder a este mensaje
Ads by Google
Help Hacer una preguntaSiguiente AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida