Bloqueos y rendimiento

Lee este articulo:

http://www.configuracionesintegrale...articulo%6
Saludos
IIslas


"JSR" escribió:

Saludos al grupo.

En estos días he tenido demasiados bloqueos a las tablas, a tal punto que
SQL corre demasiado lento. La carga de trabajo a nivel de servidor es
normal, menos del 30%, pero cualquier transacción a las bases es demasiado
lenta, es decir el motor baja su rendimiento. Tenemos dos aplicaciones
independientes, la A (con fuentes) que trabaja con 5 bases de datos y la B
(sin fuentes) con 1 base diferente. La cuestión es que en la aplicación A
existen procesos que bajan el rendimiento del motor que ni la aplicación B
corre normal. Como puedo detectar que proceso, sentencia SQL, etc. me está
dando el problema. Solo lo puedo hacer por el Query Analyzer, porque el
Enterprise Manager tambien se bloquea. Entonces una de mis pregunta es,
como detectar el proceso que me hace caer el rendimiento del motor por medio
del QA. Así mismo, utilizando el profiler, que plantilla o parámetros debo
configurar para revisar el rendimiento. Otras preguntas más:

a partir de que tamaño de la base de datos es aconsejable definirla como
filegroup. De las bases, las más grandes son de 4 y 2.5 GB, definidas como
un archivo cada base. ¿Definirlas en varios archivos me ayudaría en el
rendimiento? de ser así, donde obtengo los pasos para pasar una base de un
solo archivo a un filegroup, y de que tamaño máximo deberían ser los
archivos.

A nivel de índices ya he revisado con el Index Tuning Wizard con un trace de
todo un día y no me da ajustes.

A nivel de aplicación, y para que me confirmen, que es más óptimo, que la
aplicación envíe las sentencias SQL a ejecutar o que se las haga a través de
stored procedures?

Gracias por cualquier ayuda que me puedan dar.
Slds,
Juan

Hola.

Utiliza profiler, la traza que viene por defecto cuando le arrancas,pero
dejando sólamente los eventos de procedimientos almacenados y T-Sql que
vienen marcados y quitando todos los demás. Con eso detectarás qué
sentencias son las que más tardan y podrás depurarlas. Pero tiene toda la
pinta de ser un problema de bloqueos, ya que el uso de CPU es muy bajo.
Asegúrate de que tus transacciones son lo más cortas posibles y que el nivel
de aislamiento es el más bajo que pueda garantizarte la integridad de los
datos que manejes.

Sobre el tamaño de las bases de datos y cuándo pasar a tener más de un
filegroup, bueno, creo que es un tamaño razonablemente pequeño aún. Te
ayudaría algo en rendimiento si tuvieras los índices no clustered en otro
filegroup ubicado en otro volumen diferente del que tienes los datos y los
índices clustered. Yo aún no daría el paso, pero a lo mejor es una opción.
Más que eso, vería cómo son esos discos, dónde se ubican los log (separados
de los data), dónde tienes tempdb (preferiblemente en discos dedicados),
antes de crear más de un filegroup por base de datos.

Y sobre la tercera pregunta, esa sí que es más sencilla... de responder, que
no de poner en marcha quizá. El problema que tienen las sentencias lanzadas
directamente es que no se hace un buen aprovechamiento de la caché de planes
de ejecución, algo que garantizas con los procedimientos almacenados, que
sólo se compilan la primera vez que se ejecutan (salvo que expresamente los
configures para lo contrario). La generación de planes de ejecución consume
CPU, y ello te daría un ahorro principalmente en uso de CPU, que creo que
ahora mismo no es tu mayor problema.

Alberto López Grande (qwalgrande)
"JSR" escribió en el mensaje
news:

Saludos al grupo.

En estos días he tenido demasiados bloqueos a las tablas, a tal punto que
SQL corre demasiado lento. La carga de trabajo a nivel de servidor es
normal, menos del 30%, pero cualquier transacción a las bases es demasiado
lenta, es decir el motor baja su rendimiento. Tenemos dos aplicaciones
independientes, la A (con fuentes) que trabaja con 5 bases de datos y la B
(sin fuentes) con 1 base diferente. La cuestión es que en la aplicación A
existen procesos que bajan el rendimiento del motor que ni la aplicación B
corre normal. Como puedo detectar que proceso, sentencia SQL, etc. me
está dando el problema. Solo lo puedo hacer por el Query Analyzer, porque
el Enterprise Manager tambien se bloquea. Entonces una de mis pregunta
es, como detectar el proceso que me hace caer el rendimiento del motor por
medio del QA. Así mismo, utilizando el profiler, que plantilla o
parámetros debo configurar para revisar el rendimiento. Otras preguntas
más:

a partir de que tamaño de la base de datos es aconsejable definirla como
filegroup. De las bases, las más grandes son de 4 y 2.5 GB, definidas como
un archivo cada base. ¿Definirlas en varios archivos me ayudaría en el
rendimiento? de ser así, donde obtengo los pasos para pasar una base de
un solo archivo a un filegroup, y de que tamaño máximo deberían ser los
archivos.

A nivel de índices ya he revisado con el Index Tuning Wizard con un trace
de todo un día y no me da ajustes.

A nivel de aplicación, y para que me confirmen, que es más óptimo, que la
aplicación envíe las sentencias SQL a ejecutar o que se las haga a través
de stored procedures?

Gracias por cualquier ayuda que me puedan dar.
Slds,
Juan

Si la otra aplicación se ve afectada, seguramente sea por una de
lassiguiente 2 cosas, ambas bloquean objetos en Tempdb o bien tu primera
hace un consmo exagerado de disco.

Los bloqueos con el artículoque te recomienda isaías podrás empezar a
cazarlos, (quien sabe si a evitarlos), revisa el nivel de aislamiento de tu
base de datos,si has usado com+ será serializable y no es para nada
necesario (generalmente), puedes bajarlo al por defecto, REad committed
mucho más amble con la concurrencia. Pon el monitor de rendimiento ymide la
longitud media de la cola de disco, con valores <=2*numero de discos no
tienes problemas de contención. Luego como te decía Alberto centraté en
mejorar las consultas que tienen mayor consumo. Revisa cast y converts en
la parte de where o joins. como ejemplo busca la que más tarde de todas y
nos la publicas aquí a ver que podemos recomendarte...

Saludos
Miguel Egea

"JSR" wrote in message
news:

Saludos al grupo.

En estos días he tenido demasiados bloqueos a las tablas, a tal punto que
SQL corre demasiado lento. La carga de trabajo a nivel de servidor es
normal, menos del 30%, pero cualquier transacción a las bases es demasiado
lenta, es decir el motor baja su rendimiento. Tenemos dos aplicaciones
independientes, la A (con fuentes) que trabaja con 5 bases de datos y la B
(sin fuentes) con 1 base diferente. La cuestión es que en la aplicación A
existen procesos que bajan el rendimiento del motor que ni la aplicación B
corre normal. Como puedo detectar que proceso, sentencia SQL, etc. me
está dando el problema. Solo lo puedo hacer por el Query Analyzer, porque
el Enterprise Manager tambien se bloquea. Entonces una de mis pregunta
es, como detectar el proceso que me hace caer el rendimiento del motor por
medio del QA. Así mismo, utilizando el profiler, que plantilla o
parámetros debo configurar para revisar el rendimiento. Otras preguntas
más:

a partir de que tamaño de la base de datos es aconsejable definirla como
filegroup. De las bases, las más grandes son de 4 y 2.5 GB, definidas como
un archivo cada base. ¿Definirlas en varios archivos me ayudaría en el
rendimiento? de ser así, donde obtengo los pasos para pasar una base de
un solo archivo a un filegroup, y de que tamaño máximo deberían ser los
archivos.

A nivel de índices ya he revisado con el Index Tuning Wizard con un trace
de todo un día y no me da ajustes.

A nivel de aplicación, y para que me confirmen, que es más óptimo, que la
aplicación envíe las sentencias SQL a ejecutar o que se las haga a través
de stored procedures?

Gracias por cualquier ayuda que me puedan dar.
Slds,
Juan

Gracias a todos por su respuestas. Ya comencé a seguir algunos de los
consejos, por ahora he reubicado las bases, y en esta semana comienzo a
"cazar" al que me está haciendo los bloqueos.
Nuevamente gracias,
Slds,
Juan.

"JSR" escribió en el mensaje
news:

Saludos al grupo.

En estos días he tenido demasiados bloqueos a las tablas, a tal punto que
SQL corre demasiado lento. La carga de trabajo a nivel de servidor es
normal, menos del 30%, pero cualquier transacción a las bases es demasiado
lenta, es decir el motor baja su rendimiento. Tenemos dos aplicaciones
independientes, la A (con fuentes) que trabaja con 5 bases de datos y la B
(sin fuentes) con 1 base diferente. La cuestión es que en la aplicación A
existen procesos que bajan el rendimiento del motor que ni la aplicación B
corre normal. Como puedo detectar que proceso, sentencia SQL, etc. me
está dando el problema. Solo lo puedo hacer por el Query Analyzer, porque
el Enterprise Manager tambien se bloquea. Entonces una de mis pregunta
es, como detectar el proceso que me hace caer el rendimiento del motor por
medio del QA. Así mismo, utilizando el profiler, que plantilla o
parámetros debo configurar para revisar el rendimiento. Otras preguntas
más:

a partir de que tamaño de la base de datos es aconsejable definirla como
filegroup. De las bases, las más grandes son de 4 y 2.5 GB, definidas como
un archivo cada base. ¿Definirlas en varios archivos me ayudaría en el
rendimiento? de ser así, donde obtengo los pasos para pasar una base de
un solo archivo a un filegroup, y de que tamaño máximo deberían ser los
archivos.

A nivel de índices ya he revisado con el Index Tuning Wizard con un trace
de todo un día y no me da ajustes.

A nivel de aplicación, y para que me confirmen, que es más óptimo, que la
aplicación envíe las sentencias SQL a ejecutar o que se las haga a través
de stored procedures?

Gracias por cualquier ayuda que me puedan dar.
Slds,
Juan