Mejoras posibles de la BD

Una opinión personal: Lo primero que recomendaría es analizar es la lógica
de las aplicaciones que están generando tantos bloqueos. Obviamente allí hay
un problema, y los bloqueos son normalmente responsabilidad de las
aplicaciones.

Sólo mis dos centavos :-)
gux

Gustavo Larriera
Uruguay LatAm
http://sqljunkies.com/weblog/gux/
Este mensaje se proporciona "COMO ESTA" sin garantias y no otorga ningun
derecho / This posting is provided "AS IS" with no warranties, and confers
no rights.
"Ian Tanner" wrote in message
news:27eef01c46369$73cfa340$
Hola,
tengo una base de datos que ha crecido mucho.
Y a horas que hay muchos accesos, la CPU sube mucho y los
bloqueos se disparan.
Normalmente, ejecutando el sp_Lock suelo tener menos de 27
bloqueos. Pero en esos instantes llego a tener más de 3000.

He probado a cambiar los índices pero no he conseguido
mejorarlo.

He pensado en que podía dividir la BD en dos, una para las
insert, delete y updates y otra para las selects
principalmente.

Y que la segunda se actualizara mediante replicación de la
primera.
El problema es que la replicación transaccional requiere
que las tablas tengan un índice único. Hay consultas de
tablas de muchos registros que en cuanto les pongo un
índice único uniqueidentifier con un valor por defecto
newid() se ralentizan muchísimo.

¿Qué solución puedo tomar?

Muchas gracias.

Hola:
Aparte del muy acertado comentario de Gustavo, la Replicacion aunque muy
flexible y poderosa impone una importante carga sobre el servidor.
Probablmente despues de revisar la aplicacion, la siguiente alternativa
seria servidores federados (revisa la Documentacion en Linea si es algo que
te interesaria ser) o la segunda opcion seria un Servidor de Reserva
(tambien en los Documentacion en Linea hay bastante informacion), la
replicacion seria la 4 opcion.
Saludos,


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

Hola,
tengo una base de datos que ha crecido mucho.
Y a horas que hay muchos accesos, la CPU sube mucho y los
bloqueos se disparan.
Normalmente, ejecutando el sp_Lock suelo tener menos de 27
bloqueos. Pero en esos instantes llego a tener más de 3000.

He probado a cambiar los índices pero no he conseguido
mejorarlo.

He pensado en que podía dividir la BD en dos, una para las
insert, delete y updates y otra para las selects
principalmente.

Y que la segunda se actualizara mediante replicación de la
primera.
El problema es que la replicación transaccional requiere
que las tablas tengan un índice único. Hay consultas de
tablas de muchos registros que en cuanto les pongo un
índice único uniqueidentifier con un valor por defecto
newid() se ralentizan muchísimo.

¿Qué solución puedo tomar?

Muchas gracias.

Hola otra vez,
tengo la posibilidad de utilizar otro servidor.

Por ello, estoy pensando en la solución siguiente:
Utilizar el primer servidor para el trabajo en tiempo
real, esto es, las inserts, updates y las deletes, y
utilizar el segundo servidor para las consultas de tipo
estadítico, es decir, selects.

De esa manera, podría cambiar las indexaciones en cada
servidor y ajustarlos a las necesidades de cada uno.

¿Cómo puedo hacer la actualizxación del segundo, para que
esté siempre lo más actualizada posible?

Quiero evitar la replicación transaccional. Debido su
compleja administración y la necesidad de índice único en
las tablas, que como comentabas, carga bastante el
servidor.

¿Usar triggers en las tablas para poner al día datos en el
segundo servidor, que sería un Linked Servers?
¿Algún otro modo de hacer eso?
Las vistas sobre particiones federadas se hacen sobre
Linked-Servers,¿es eso no?.

He visto también la opción de trasvase de registros (Log
Shipping), pero no parece una buena idea ya que no se
puede utilizar la base de datos de destino mientras se
están recuperando los registros.
¿Alguna otra posibilidad?

¡¡Muchas gracias!!

Hola:
Aparte del muy acertado comentario de Gustavo, la

Replicacion aunque muy

flexible y poderosa impone una importante carga sobre el

servidor.

Probablmente despues de revisar la aplicacion, la

siguiente alternativa

seria servidores federados (revisa la Documentacion en

Linea si es algo que

te interesaria ser) o la segunda opcion seria un Servidor

de Reserva

(tambien en los Documentacion en Linea hay bastante

informacion), la

replicacion seria la 4 opcion.
Saludos,


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

Hola,
tengo una base de datos que ha crecido mucho.
Y a horas que hay muchos accesos, la CPU sube mucho y

los

bloqueos se disparan.
Normalmente, ejecutando el sp_Lock suelo tener menos de

27

bloqueos. Pero en esos instantes llego a tener más de

3000.

He probado a cambiar los índices pero no he conseguido
mejorarlo.

He pensado en que podía dividir la BD en dos, una para

las

insert, delete y updates y otra para las selects
principalmente.

Y que la segunda se actualizara mediante replicación de

la

primera.
El problema es que la replicación transaccional requiere
que las tablas tengan un índice único. Hay consultas de
tablas de muchos registros que en cuanto les pongo un
índice único uniqueidentifier con un valor por defecto
newid() se ralentizan muchísimo.

¿Qué solución puedo tomar?

Muchas gracias.

.

Hola:
Revisa la documentacion en linea sobre los Servidores de Reserva
(StandBy).
Un servidor de Reserva se utiliza haciendo un respaldo de la BD del
Servidor "en vivo" y restaurandolo en el servidor de Reserva y luego con
mucha frecuencia se hacen respaldos del transaction log del servidor "en
Vivo" y se restauran en el de Reserva. Estos respaldos pueden ser tan
frequecuentes como quieras (5 minutos!).
Luego configuras tu aplicacion para que los reportes y analisis que no
necesitan informacion al segundo obtengan los resultados del servidor de
Reserva.
Esta solucion es facil de instalar, te da cierta grado de tolerancia
contra fallos de hardware), y requiere cambios en la aplicacion pero no
demasiados.
La alternativa de Servidores Federados es mucho mas escalable, asume que
puedes particionar los datos de las tablas que mas carga generan en 2 o mas
Tablas que pueden residir en varios servidores o en varios dispositivos.
Luego se crean vistas que son UNION ALL de todas estas tablas. La aplicacion
se configura para que utilice unicamente las vistas.
En general estas soluciones son "pesadas", con frecuencia cambios en la
arquitectura de las aplicaciones logran beneficios mucho mayores. Algunas
elementos a considerar que se me ocurren: BD bien normalizadas, 0 cursores,
muy pocas o ninguna tabla temporal, muy pocos o ningun trigger (en su
defecto triggers muy bien disenados), que se este utilizando OLE-DB como
cliente, que las transacciones sean muy cortas, que se use el nivel de
bloqueo minimo y optimistas.
Saludos,


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

Hola otra vez,
tengo la posibilidad de utilizar otro servidor.

Por ello, estoy pensando en la solución siguiente:
Utilizar el primer servidor para el trabajo en tiempo
real, esto es, las inserts, updates y las deletes, y
utilizar el segundo servidor para las consultas de tipo
estadítico, es decir, selects.

De esa manera, podría cambiar las indexaciones en cada
servidor y ajustarlos a las necesidades de cada uno.

¿Cómo puedo hacer la actualizxación del segundo, para que
esté siempre lo más actualizada posible?

Quiero evitar la replicación transaccional. Debido su
compleja administración y la necesidad de índice único en
las tablas, que como comentabas, carga bastante el
servidor.

¿Usar triggers en las tablas para poner al día datos en el
segundo servidor, que sería un Linked Servers?
¿Algún otro modo de hacer eso?
Las vistas sobre particiones federadas se hacen sobre
Linked-Servers,¿es eso no?.

He visto también la opción de trasvase de registros (Log
Shipping), pero no parece una buena idea ya que no se
puede utilizar la base de datos de destino mientras se
están recuperando los registros.
¿Alguna otra posibilidad?

¡¡Muchas gracias!!

Hola:
Aparte del muy acertado comentario de Gustavo, la Replicacion
aunque muy flexible y poderosa impone una importante carga sobre el
servidor. Probablmente despues de revisar la aplicacion, la
siguiente alternativa seria servidores federados (revisa la
Documentacion en Linea si es algo que te interesaria ser) o la
segunda opcion seria un Servidor de Reserva (tambien en los
Documentacion en Linea hay bastante informacion), la replicacion
seria la 4 opcion. Saludos,


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

Hola,
tengo una base de datos que ha crecido mucho.
Y a horas que hay muchos accesos, la CPU sube mucho y los
bloqueos se disparan.
Normalmente, ejecutando el sp_Lock suelo tener menos de 27
bloqueos. Pero en esos instantes llego a tener más de 3000.

He probado a cambiar los índices pero no he conseguido
mejorarlo.

He pensado en que podía dividir la BD en dos, una para las
insert, delete y updates y otra para las selects
principalmente.

Y que la segunda se actualizara mediante replicación de la
primera.
El problema es que la replicación transaccional requiere
que las tablas tengan un índice único. Hay consultas de
tablas de muchos registros que en cuanto les pongo un
índice único uniqueidentifier con un valor por defecto
newid() se ralentizan muchísimo.

¿Qué solución puedo tomar?

Muchas gracias.

.

Gracias,
el probelma más grande que veo es que en el primer
servidor únicamente querría tener los datos necesarios y
los actuales (los de el día actual), y no todos los datos
de fechas anteriores.

Por ello el sergundo servidor no sería una copia del
actual.

Sería el histórico completo, más lo nuevo que llegue del
primer servidor. Y en el primer servidor se irían borrando
los datos viejos con el fin de que tenga el menor número
de registros posibles.
Por ello, no podría hacer copia del transaction log, a
menos que se puedan indicar qué pasos no se quieren
realizar (los de borrado de datos viejos no los debería
hacer en el segundo servidor).

Por ello no veo claro el modo de pasar los datos de un
servidor a otro.

Gracias.

Hola:
Revisa la documentacion en linea sobre los Servidores

de Reserva

(StandBy).
Un servidor de Reserva se utiliza haciendo un

respaldo de la BD del

Servidor "en vivo" y restaurandolo en el servidor de

Reserva y luego con

mucha frecuencia se hacen respaldos del transaction log

del servidor "en

Vivo" y se restauran en el de Reserva. Estos respaldos

pueden ser tan

frequecuentes como quieras (5 minutos!).
Luego configuras tu aplicacion para que los reportes

y analisis que no

necesitan informacion al segundo obtengan los resultados

del servidor de

Reserva.
Esta solucion es facil de instalar, te da cierta

grado de tolerancia

contra fallos de hardware), y requiere cambios en la

aplicacion pero no

demasiados.
La alternativa de Servidores Federados es mucho mas

escalable, asume que

puedes particionar los datos de las tablas que mas carga

generan en 2 o mas

Tablas que pueden residir en varios servidores o en

varios dispositivos.

Luego se crean vistas que son UNION ALL de todas estas

tablas. La aplicacion

se configura para que utilice unicamente las vistas.
En general estas soluciones son "pesadas", con

frecuencia cambios en la

arquitectura de las aplicaciones logran beneficios mucho

mayores. Algunas

elementos a considerar que se me ocurren: BD bien

normalizadas, 0 cursores,

muy pocas o ninguna tabla temporal, muy pocos o ningun

trigger (en su

defecto triggers muy bien disenados), que se este

utilizando OLE-DB como

cliente, que las transacciones sean muy cortas, que se

use el nivel de

bloqueo minimo y optimistas.
Saludos,


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

Hola otra vez,
tengo la posibilidad de utilizar otro servidor.

Por ello, estoy pensando en la solución siguiente:
Utilizar el primer servidor para el trabajo en tiempo
real, esto es, las inserts, updates y las deletes, y
utilizar el segundo servidor para las consultas de tipo
estadítico, es decir, selects.

De esa manera, podría cambiar las indexaciones en cada
servidor y ajustarlos a las necesidades de cada uno.

¿Cómo puedo hacer la actualizxación del segundo, para

que

esté siempre lo más actualizada posible?

Quiero evitar la replicación transaccional. Debido su
compleja administración y la necesidad de índice único

en

las tablas, que como comentabas, carga bastante el
servidor.

¿Usar triggers en las tablas para poner al día datos en

el

segundo servidor, que sería un Linked Servers?
¿Algún otro modo de hacer eso?
Las vistas sobre particiones federadas se hacen sobre
Linked-Servers,¿es eso no?.

He visto también la opción de trasvase de registros (Log
Shipping), pero no parece una buena idea ya que no se
puede utilizar la base de datos de destino mientras se
están recuperando los registros.
¿Alguna otra posibilidad?

¡¡Muchas gracias!!

Hola:
Aparte del muy acertado comentario de Gustavo, la

Replicacion

aunque muy flexible y poderosa impone una importante

carga sobre el

servidor. Probablmente despues de revisar la

aplicacion, la

siguiente alternativa seria servidores federados

(revisa la

Documentacion en Linea si es algo que te interesaria

ser) o la

segunda opcion seria un Servidor de Reserva (tambien

en los

Documentacion en Linea hay bastante informacion), la

replicacion

seria la 4 opcion. Saludos,


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

Hola,
tengo una base de datos que ha crecido mucho.
Y a horas que hay muchos accesos, la CPU sube mucho y

los

bloqueos se disparan.
Normalmente, ejecutando el sp_Lock suelo tener menos

de 27

bloqueos. Pero en esos instantes llego a tener más de

3000.

He probado a cambiar los índices pero no he conseguido
mejorarlo.

He pensado en que podía dividir la BD en dos, una

para las

insert, delete y updates y otra para las selects
principalmente.

Y que la segunda se actualizara mediante replicación

de la

primera.
El problema es que la replicación transaccional

requiere

que las tablas tengan un índice único. Hay consultas

de

tablas de muchos registros que en cuanto les pongo un
índice único uniqueidentifier con un valor por defecto
newid() se ralentizan muchísimo.

¿Qué solución puedo tomar?

Muchas gracias.

.

.