Estrategia de "optimizaciones"

¿Siempre tarda 3 veces más? ¿Has vuelto a hacer la prueba? ¿Estás lanzando
la misma instrucción? ¿Está la base de datos configurada igual (por ejemplo,
que antes tuvieras creado filegroups diferentes para datos e índices en
discos físicos distintos y ahora no) ?

El plan de mantenimiento es más o menos el mismo. No recomiendo en absoluto
reducir el tamaño de la base de datos, con eso sólo consigues mayor
fragmentación y por tanto peor rendimiento. A cambio añadiría la opción de
comprobar la integridad de la base de datos, algo que no parece que hagas.

Te recomiendo implementar la solución de Ola Hallengren
(http://ola.hallengren.com/), que es mejor (por muchas razones) que los
planes de mantenimiento de SQL Server.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:

Hola a todos:
Aquí sigo, peleando con el SQL 2008... pero eso es bueno.

La pregunta, (me imagino la mayoría de las respuestas) es: ¿que estrategia
de "optimizaciones" de BBDD me recomendais)?

Como plan de mantenimiento hago esto (es lo mismo que hacía con SQL 2000,
pero me da la sensación de que ahora con 2008 no es lo bueno que debería):

* Reducir BBDD.
* Backup completo.
* Backup del log de transacciones (se repite cada seis horas).
* Reorganizar índices (únicamente dos días a la semana).

¿Es correcto?
Con el servidor antiguo, (menos recursos, 32bits y SQL 2000) la tarea
"reorganizar índices" tardaba seis horas (BBDD de 200Gb), sin embargo,
ahora con el servidor nuevo (todavía en pruebas) que es mucho mas potente,
de 64bits y SQL 2008 tarda ¡18 horas!, con lo que supongo que algo estoy
haciendo mal.

¿Podríais orientarme?

Gracias una vez mas por vuestra magnífica ayuda.
Diego Fernández

Hola:

La BBDD está configurada igual, a excepción de que el tipo de almacenamiento
ha cambiado (antes era fibra óptica y ahora es iSCSI), pero en teoría
debería ir incluso más rápido el nuevo (iSCSI) debido a que tiene mas ancho
de banda que el antiguo.

No conocía la solución de Ola Hallengren, voy a leerme la documentación y
intentar utilizarla.

Una pregunta sobre los filegroups: si están el la misma unidad lógica (es
decir, en los mismos discos físicos y mismo RAID) ¿se consigue algo poniendo
mas de un fichero (tipo bbdd.mdf y bbdd_1.ndf)?, es que he leido que se
recomienda poner esos dos ficheros (mdf y ndf) pero no entiendo cual puede
ser la "mejoría" si están en el mismo recurso de hardware.

Un saludo.
Diego Fernández



"Carlos Sacristan" escribió en el mensaje de
noticias:

¿Siempre tarda 3 veces más? ¿Has vuelto a hacer la prueba? ¿Estás lanzando
la misma instrucción? ¿Está la base de datos configurada igual (por
ejemplo, que antes tuvieras creado filegroups diferentes para datos e
índices en discos físicos distintos y ahora no) ?

El plan de mantenimiento es más o menos el mismo. No recomiendo en
absoluto reducir el tamaño de la base de datos, con eso sólo consigues
mayor fragmentación y por tanto peor rendimiento. A cambio añadiría la
opción de comprobar la integridad de la base de datos, algo que no parece
que hagas.

Te recomiendo implementar la solución de Ola Hallengren
(http://ola.hallengren.com/), que es mejor (por muchas razones) que los
planes de mantenimiento de SQL Server.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:

Hola a todos:
Aquí sigo, peleando con el SQL 2008... pero eso es bueno.

La pregunta, (me imagino la mayoría de las respuestas) es: ¿que
estrategia de "optimizaciones" de BBDD me recomendais)?

Como plan de mantenimiento hago esto (es lo mismo que hacía con SQL 2000,
pero me da la sensación de que ahora con 2008 no es lo bueno que
debería):

* Reducir BBDD.
* Backup completo.
* Backup del log de transacciones (se repite cada seis horas).
* Reorganizar índices (únicamente dos días a la semana).

¿Es correcto?
Con el servidor antiguo, (menos recursos, 32bits y SQL 2000) la tarea
"reorganizar índices" tardaba seis horas (BBDD de 200Gb), sin embargo,
ahora con el servidor nuevo (todavía en pruebas) que es mucho mas
potente, de 64bits y SQL 2008 tarda ¡18 horas!, con lo que supongo que
algo estoy haciendo mal.

¿Podríais orientarme?

Gracias una vez mas por vuestra magnífica ayuda.
Diego Fernández

¿Has vuelto a ejecutar el proceso para ver si tarda lo mismo?

En cuanto a los ficheros, la idea para mejorar el rendimiento es separarlos
en discos distintos. Si están en el mismo no vas a obtener mejora en ese
sentido. Existe un artículo muy bueno sobre diseño físico en
http://technet.microsoft.com/es-es/...px?ppud=4;
en él se hace referencia a
http://technet.microsoft.com/es-es/...us%29.aspx en el
que hay un apartado específico que responde detalladamente a las preguntas

- ¿cuántos archivos crear por grupo de archivos?
- ¿cuántos grupos de archivos crear?
- ¿cómo colocar los objetos de usuario (tablas e índices) en estos
grupos de archivos?
- ¿cómo configurar el hw para obtener el máximo rendimiento?
- ¿hay que crear grupos de archivos en base de datos pequeñas?

Recomiendo su lectura.

En cuanto a la solución de Ola, la verdad es que cuando la descubrí me
pareció muy buena, y según he ido conociéndola mejor me parece aún. Además
puedes comentar con el creador cualquier tema que te surja (problemas y/o
mejoras), es una persona muy accesible en ese sentido.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:uD%

Hola:

La BBDD está configurada igual, a excepción de que el tipo de
almacenamiento ha cambiado (antes era fibra óptica y ahora es iSCSI), pero
en teoría debería ir incluso más rápido el nuevo (iSCSI) debido a que
tiene mas ancho de banda que el antiguo.

No conocía la solución de Ola Hallengren, voy a leerme la documentación y
intentar utilizarla.

Una pregunta sobre los filegroups: si están el la misma unidad lógica (es
decir, en los mismos discos físicos y mismo RAID) ¿se consigue algo
poniendo mas de un fichero (tipo bbdd.mdf y bbdd_1.ndf)?, es que he leido
que se recomienda poner esos dos ficheros (mdf y ndf) pero no entiendo
cual puede ser la "mejoría" si están en el mismo recurso de hardware.

Un saludo.
Diego Fernández



"Carlos Sacristan" escribió en el mensaje de
noticias:

¿Siempre tarda 3 veces más? ¿Has vuelto a hacer la prueba? ¿Estás
lanzando la misma instrucción? ¿Está la base de datos configurada igual
(por ejemplo, que antes tuvieras creado filegroups diferentes para datos
e índices en discos físicos distintos y ahora no) ?

El plan de mantenimiento es más o menos el mismo. No recomiendo en
absoluto reducir el tamaño de la base de datos, con eso sólo consigues
mayor fragmentación y por tanto peor rendimiento. A cambio añadiría la
opción de comprobar la integridad de la base de datos, algo que no parece
que hagas.

Te recomiendo implementar la solución de Ola Hallengren
(http://ola.hallengren.com/), que es mejor (por muchas razones) que los
planes de mantenimiento de SQL Server.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:

Hola a todos:
Aquí sigo, peleando con el SQL 2008... pero eso es bueno.

La pregunta, (me imagino la mayoría de las respuestas) es: ¿que
estrategia de "optimizaciones" de BBDD me recomendais)?

Como plan de mantenimiento hago esto (es lo mismo que hacía con SQL
2000, pero me da la sensación de que ahora con 2008 no es lo bueno que
debería):

* Reducir BBDD.
* Backup completo.
* Backup del log de transacciones (se repite cada seis horas).
* Reorganizar índices (únicamente dos días a la semana).

¿Es correcto?
Con el servidor antiguo, (menos recursos, 32bits y SQL 2000) la tarea
"reorganizar índices" tardaba seis horas (BBDD de 200Gb), sin embargo,
ahora con el servidor nuevo (todavía en pruebas) que es mucho mas
potente, de 64bits y SQL 2008 tarda ¡18 horas!, con lo que supongo que
algo estoy haciendo mal.

¿Podríais orientarme?

Gracias una vez mas por vuestra magnífica ayuda.
Diego Fernández

Ufff, acabo de leer en ese artículo un dato que me deja "extrañado":

"The number of data files within a single filegroup should equal to the
number of CPU cores. "

No entiendo el motivo de esto, aunque no tengo ningún problema en hacerlo.
Aún así, como tengo 2 Xeon quadcore (Windows los ve como 16 núcleos)...
¿tendría que crear 16 ficheros o 8 ficheros?

No he vuelto a lanzar la optimización para ver si tardaba lo mismo, pero
ahora mismo está lanzada la optimización mediante el proceso de Ola y veré
cuanto tarda.

Bueno, continúo "aprendiendo" lo que puedo...

Un saludo.
Diego Fernández


"Carlos Sacristan" escribió en el mensaje de
noticias:

¿Has vuelto a ejecutar el proceso para ver si tarda lo mismo?

En cuanto a los ficheros, la idea para mejorar el rendimiento es
separarlos en discos distintos. Si están en el mismo no vas a obtener
mejora en ese sentido. Existe un artículo muy bueno sobre diseño físico en
http://technet.microsoft.com/es-es/...px?ppud=4;
en él se hace referencia a
http://technet.microsoft.com/es-es/...us%29.aspx en el
que hay un apartado específico que responde detalladamente a las preguntas

- ¿cuántos archivos crear por grupo de archivos?
- ¿cuántos grupos de archivos crear?
- ¿cómo colocar los objetos de usuario (tablas e índices) en estos
grupos de archivos?
- ¿cómo configurar el hw para obtener el máximo rendimiento?
- ¿hay que crear grupos de archivos en base de datos pequeñas?

Recomiendo su lectura.

En cuanto a la solución de Ola, la verdad es que cuando la descubrí me
pareció muy buena, y según he ido conociéndola mejor me parece aún. Además
puedes comentar con el creador cualquier tema que te surja (problemas y/o
mejoras), es una persona muy accesible en ese sentido.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:uD%

Hola:

La BBDD está configurada igual, a excepción de que el tipo de
almacenamiento ha cambiado (antes era fibra óptica y ahora es iSCSI),
pero en teoría debería ir incluso más rápido el nuevo (iSCSI) debido a
que tiene mas ancho de banda que el antiguo.

No conocía la solución de Ola Hallengren, voy a leerme la documentación y
intentar utilizarla.

Una pregunta sobre los filegroups: si están el la misma unidad lógica (es
decir, en los mismos discos físicos y mismo RAID) ¿se consigue algo
poniendo mas de un fichero (tipo bbdd.mdf y bbdd_1.ndf)?, es que he leido
que se recomienda poner esos dos ficheros (mdf y ndf) pero no entiendo
cual puede ser la "mejoría" si están en el mismo recurso de hardware.

Un saludo.
Diego Fernández



"Carlos Sacristan" escribió en el mensaje de
noticias:

¿Siempre tarda 3 veces más? ¿Has vuelto a hacer la prueba? ¿Estás
lanzando la misma instrucción? ¿Está la base de datos configurada igual
(por ejemplo, que antes tuvieras creado filegroups diferentes para datos
e índices en discos físicos distintos y ahora no) ?

El plan de mantenimiento es más o menos el mismo. No recomiendo en
absoluto reducir el tamaño de la base de datos, con eso sólo consigues
mayor fragmentación y por tanto peor rendimiento. A cambio añadiría la
opción de comprobar la integridad de la base de datos, algo que no
parece que hagas.

Te recomiendo implementar la solución de Ola Hallengren
(http://ola.hallengren.com/), que es mejor (por muchas razones) que los
planes de mantenimiento de SQL Server.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:

Hola a todos:
Aquí sigo, peleando con el SQL 2008... pero eso es bueno.

La pregunta, (me imagino la mayoría de las respuestas) es: ¿que
estrategia de "optimizaciones" de BBDD me recomendais)?

Como plan de mantenimiento hago esto (es lo mismo que hacía con SQL
2000, pero me da la sensación de que ahora con 2008 no es lo bueno que
debería):

* Reducir BBDD.
* Backup completo.
* Backup del log de transacciones (se repite cada seis horas).
* Reorganizar índices (únicamente dos días a la semana).

¿Es correcto?
Con el servidor antiguo, (menos recursos, 32bits y SQL 2000) la tarea
"reorganizar índices" tardaba seis horas (BBDD de 200Gb), sin embargo,
ahora con el servidor nuevo (todavía en pruebas) que es mucho mas
potente, de 64bits y SQL 2008 tarda ¡18 horas!, con lo que supongo que
algo estoy haciendo mal.

¿Podríais orientarme?

Gracias una vez mas por vuestra magnífica ayuda.
Diego Fernández

Sí, eso es una recomendación típica que se supone que mejora el rendimiento
de escritura, al poder distribuir la carga entre las distintas CPU y
distintos ficheros. Se aplica también (y muy especialmente) a tempdb.

En cuanto al número de ficheros a crear, sería igual al número de CPU que
SQL Server detecta. 2 CPU quadcore son 8 núcleos, y así los debería ver
Windows y por tanto SQL Server. ¿Dices que W detecta 16? ¿Estás seguro que
sólo tienes 2 quadcore?

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:

Ufff, acabo de leer en ese artículo un dato que me deja "extrañado":

"The number of data files within a single filegroup should equal to the
number of CPU cores. "

No entiendo el motivo de esto, aunque no tengo ningún problema en hacerlo.
Aún así, como tengo 2 Xeon quadcore (Windows los ve como 16 núcleos)...
¿tendría que crear 16 ficheros o 8 ficheros?

No he vuelto a lanzar la optimización para ver si tardaba lo mismo, pero
ahora mismo está lanzada la optimización mediante el proceso de Ola y veré
cuanto tarda.

Bueno, continúo "aprendiendo" lo que puedo...

Un saludo.
Diego Fernández


"Carlos Sacristan" escribió en el mensaje de
noticias:

¿Has vuelto a ejecutar el proceso para ver si tarda lo mismo?

En cuanto a los ficheros, la idea para mejorar el rendimiento es
separarlos en discos distintos. Si están en el mismo no vas a obtener
mejora en ese sentido. Existe un artículo muy bueno sobre diseño físico
en
http://technet.microsoft.com/es-es/...px?ppud=4;
en él se hace referencia a
http://technet.microsoft.com/es-es/...us%29.aspx en el
que hay un apartado específico que responde detalladamente a las
preguntas

- ¿cuántos archivos crear por grupo de archivos?
- ¿cuántos grupos de archivos crear?
- ¿cómo colocar los objetos de usuario (tablas e índices) en estos
grupos de archivos?
- ¿cómo configurar el hw para obtener el máximo rendimiento?
- ¿hay que crear grupos de archivos en base de datos pequeñas?

Recomiendo su lectura.

En cuanto a la solución de Ola, la verdad es que cuando la descubrí me
pareció muy buena, y según he ido conociéndola mejor me parece aún.
Además puedes comentar con el creador cualquier tema que te surja
(problemas y/o mejoras), es una persona muy accesible en ese sentido.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:uD%

Hola:

La BBDD está configurada igual, a excepción de que el tipo de
almacenamiento ha cambiado (antes era fibra óptica y ahora es iSCSI),
pero en teoría debería ir incluso más rápido el nuevo (iSCSI) debido a
que tiene mas ancho de banda que el antiguo.

No conocía la solución de Ola Hallengren, voy a leerme la documentación
y intentar utilizarla.

Una pregunta sobre los filegroups: si están el la misma unidad lógica
(es decir, en los mismos discos físicos y mismo RAID) ¿se consigue algo
poniendo mas de un fichero (tipo bbdd.mdf y bbdd_1.ndf)?, es que he
leido que se recomienda poner esos dos ficheros (mdf y ndf) pero no
entiendo cual puede ser la "mejoría" si están en el mismo recurso de
hardware.

Un saludo.
Diego Fernández



"Carlos Sacristan" escribió en el mensaje de
noticias:

¿Siempre tarda 3 veces más? ¿Has vuelto a hacer la prueba? ¿Estás
lanzando la misma instrucción? ¿Está la base de datos configurada igual
(por ejemplo, que antes tuvieras creado filegroups diferentes para
datos e índices en discos físicos distintos y ahora no) ?

El plan de mantenimiento es más o menos el mismo. No recomiendo en
absoluto reducir el tamaño de la base de datos, con eso sólo consigues
mayor fragmentación y por tanto peor rendimiento. A cambio añadiría la
opción de comprobar la integridad de la base de datos, algo que no
parece que hagas.

Te recomiendo implementar la solución de Ola Hallengren
(http://ola.hallengren.com/), que es mejor (por muchas razones) que los
planes de mantenimiento de SQL Server.

"Caminar sobre el agua y desarrollar software a partir de unas
especificaciones es fácil, si ambas están congeladas."
Edward V. Berard, ingeniero informático


"Diego Fernández" wrote in message
news:

Hola a todos:
Aquí sigo, peleando con el SQL 2008... pero eso es bueno.

La pregunta, (me imagino la mayoría de las respuestas) es: ¿que
estrategia de "optimizaciones" de BBDD me recomendais)?

Como plan de mantenimiento hago esto (es lo mismo que hacía con SQL
2000, pero me da la sensación de que ahora con 2008 no es lo bueno que
debería):

* Reducir BBDD.
* Backup completo.
* Backup del log de transacciones (se repite cada seis horas).
* Reorganizar índices (únicamente dos días a la semana).

¿Es correcto?
Con el servidor antiguo, (menos recursos, 32bits y SQL 2000) la tarea
"reorganizar índices" tardaba seis horas (BBDD de 200Gb), sin embargo,
ahora con el servidor nuevo (todavía en pruebas) que es mucho mas
potente, de 64bits y SQL 2008 tarda ¡18 horas!, con lo que supongo que
algo estoy haciendo mal.

¿Podríais orientarme?

Gracias una vez mas por vuestra magnífica ayuda.
Diego Fernández