Estrategia de "optimizaciones"

Hola:
Lo acabo de comprobar de nuevo:

En el "administrador de tareas"-> pestaña "rendimiento" me aparecen 16
procesadores, pero esto me ha ocurrido "desde siempre" con los procesadores
Xeon, que por cada uno dice que hay dos.

En el nuevo "monitor de recursos" de 2008, únicamente aparecen 8.

En las "propiedades del servidor" del Management Studio, me dice que tengo
16 procesadores.

Obviamente, el dato "correcto" son 8 núcleos, pero... ¿para SQL será lo
óptimo 8 o 16?

Por otra parte, sobre "como colocar los datos (tablas, índices) en los
ficheros, aquí creo que no tengo nada que hacer, ya que la BBDD es de
Navision (Dynamics Nav 2009) y toda esa gestión la hace la aplicación.

Gracias otra vez por tu ayuda.
Diego Fernández

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

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

Parece que está habilitado hyperthreading, pero la opción affinity mask de
SQL Server está configurada de tal modo que sólo se usan los núcleos "de
verdad". Algo que me suena extraño, porque nunca había oído hablar de ello,
pero puede que lo haga el programa de instalación directamente...

Normalmente no es una buena práctica habilitar hyperthreading en un servidor
dedicado a SQL Server. Revisa si esto está así (en
http://blogs.msdn.com/arvindsh/arch...ading.aspx
se muestra una forma de ver el número de sockets, núcleos y CPU lógicas)

Una vez que compruebes esto, lo suyo sería crear esos 8 ficheros (2 CPU x 4
núcleos)

"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:
Lo acabo de comprobar de nuevo:

En el "administrador de tareas"-> pestaña "rendimiento" me aparecen 16
procesadores, pero esto me ha ocurrido "desde siempre" con los
procesadores Xeon, que por cada uno dice que hay dos.

En el nuevo "monitor de recursos" de 2008, únicamente aparecen 8.

En las "propiedades del servidor" del Management Studio, me dice que tengo
16 procesadores.

Obviamente, el dato "correcto" son 8 núcleos, pero... ¿para SQL será lo
óptimo 8 o 16?

Por otra parte, sobre "como colocar los datos (tablas, índices) en los
ficheros, aquí creo que no tengo nada que hacer, ya que la BBDD es de
Navision (Dynamics Nav 2009) y toda esa gestión la hace la aplicación.

Gracias otra vez por tu ayuda.
Diego Fernández

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

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

Hola de nuevo:

Efectivamente, el coreinfo de SysInternals me dice que tengo ocho núcleos
con Hyper-threading, tal y como tú decias...
Esta es la información que saca:
Logical to Physical Processor Map:
**-- Physical Processor 0 (Hyperthreaded)
-**- Physical Processor 2 (Hyperthreaded)
**-- Physical Processor 3 (Hyperthreaded)
-**- Physical Processor 5 (Hyperthreaded)
**-- Physical Processor 6 (Hyperthreaded)
...

Voy a desactivar el Hyper-threading y crear esos ocho ficheros.
Además de en tempdb y la BBDD de la aplicación ¿lo hago con master, model,
etc...?
¿Tengo que hacer 8 ficheros únicamente para la parte de BBDD o también para
el Log de transacciones debo tener 8?

Gracias de nuevo.
Diego.

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

Parece que está habilitado hyperthreading, pero la opción affinity mask de
SQL Server está configurada de tal modo que sólo se usan los núcleos "de
verdad". Algo que me suena extraño, porque nunca había oído hablar de
ello, pero puede que lo haga el programa de instalación directamente...

Normalmente no es una buena práctica habilitar hyperthreading en un
servidor dedicado a SQL Server. Revisa si esto está así (en
http://blogs.msdn.com/arvindsh/arch...ading.aspx
se muestra una forma de ver el número de sockets, núcleos y CPU lógicas)

Una vez que compruebes esto, lo suyo sería crear esos 8 ficheros (2 CPU x
4 núcleos)

"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:
Lo acabo de comprobar de nuevo:

En el "administrador de tareas"-> pestaña "rendimiento" me aparecen 16
procesadores, pero esto me ha ocurrido "desde siempre" con los
procesadores Xeon, que por cada uno dice que hay dos.

En el nuevo "monitor de recursos" de 2008, únicamente aparecen 8.

En las "propiedades del servidor" del Management Studio, me dice que
tengo 16 procesadores.

Obviamente, el dato "correcto" son 8 núcleos, pero... ¿para SQL será lo
óptimo 8 o 16?

Por otra parte, sobre "como colocar los datos (tablas, índices) en los
ficheros, aquí creo que no tengo nada que hacer, ya que la BBDD es de
Navision (Dynamics Nav 2009) y toda esa gestión la hace la aplicación.

Gracias otra vez por tu ayuda.
Diego Fernández

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

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

Ni en model ni en master te va a permitir crear archivos adicionales. Esa
recomendación se refiere únicamente a tempdb y las bases de datos de
usuario.

El log de transacciones no se ve beneficiado por el hecho de tener más de un
fichero, ya que su naturaleza es circular y por tanto sólo estaría usando un
archivo cada vez.

En cuanto a lo de Navision, habría que mirar la garantía, pero igual sí que
se puede modificar la base de datos que te crea la instalación del producto
para que los datos (índices agrupados) vayan a un filegroup (marcándolo como
predeterminado) y crear otro filegroup para los índices no agrupados. Los
ficheros de esos filegroups estarían en discos distintos, claro.

"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 de nuevo:

Efectivamente, el coreinfo de SysInternals me dice que tengo ocho núcleos
con Hyper-threading, tal y como tú decias...
Esta es la información que saca:
Logical to Physical Processor Map:
**-- Physical Processor 0 (Hyperthreaded)
-**- Physical Processor 2 (Hyperthreaded)
**-- Physical Processor 3 (Hyperthreaded)
-**- Physical Processor 5 (Hyperthreaded)
**-- Physical Processor 6 (Hyperthreaded)
...

Voy a desactivar el Hyper-threading y crear esos ocho ficheros.
Además de en tempdb y la BBDD de la aplicación ¿lo hago con master, model,
etc...?
¿Tengo que hacer 8 ficheros únicamente para la parte de BBDD o también
para el Log de transacciones debo tener 8?

Gracias de nuevo.
Diego.

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

Parece que está habilitado hyperthreading, pero la opción affinity mask
de SQL Server está configurada de tal modo que sólo se usan los núcleos
"de verdad". Algo que me suena extraño, porque nunca había oído hablar de
ello, pero puede que lo haga el programa de instalación directamente...

Normalmente no es una buena práctica habilitar hyperthreading en un
servidor dedicado a SQL Server. Revisa si esto está así (en
http://blogs.msdn.com/arvindsh/arch...ading.aspx
se muestra una forma de ver el número de sockets, núcleos y CPU lógicas)

Una vez que compruebes esto, lo suyo sería crear esos 8 ficheros (2 CPU x
4 núcleos)

"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:
Lo acabo de comprobar de nuevo:

En el "administrador de tareas"-> pestaña "rendimiento" me aparecen 16
procesadores, pero esto me ha ocurrido "desde siempre" con los
procesadores Xeon, que por cada uno dice que hay dos.

En el nuevo "monitor de recursos" de 2008, únicamente aparecen 8.

En las "propiedades del servidor" del Management Studio, me dice que
tengo 16 procesadores.

Obviamente, el dato "correcto" son 8 núcleos, pero... ¿para SQL será lo
óptimo 8 o 16?

Por otra parte, sobre "como colocar los datos (tablas, índices) en los
ficheros, aquí creo que no tengo nada que hacer, ya que la BBDD es de
Navision (Dynamics Nav 2009) y toda esa gestión la hace la aplicación.

Gracias otra vez por tu ayuda.
Diego Fernández

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

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