Distribución de los datos en ficheros ..

No deduzcas eso de TEMPDB por que no es verdad, verás al final en esto no
hay ningún misterio

Los ficheros de log necesitan escrituras rápidas, esto es por que son
estructura secuenciales fundamentalmente de escritura (también se leen
obviamente pero el proceso no afecta tan directamente al rendimiento). De
ahí que se suelan separar de los archivos de datos, fundamentalmente de
lecturas aleatorias para buscar un dato acá y otro allá. Además de esto se
separan del disco C por dos razones fundamentalmente, la primera, por que si
se te llena la unidad es un problema muy grave y afecta al sistema y eso con
una base de datos ahí es más fácil, lo segundo por el fichero de paginación,
Windows actúa mucho con ese fichero sobre todo si no tiene mucha memoria,
por lo que potencialmente entrará en conflicto de intereses con SQL. ¿y
Tempdb? Que se le ha perdido a TempDB en todo esto, bueno, el caso de tempdb
es muy particular, es usada por varios procesos de la ejecución de un query
por ejemplo para hacer ordenaciones o cuando el plan de ejecucíon necesita
una workTable. En muchísimas ocasiones su uso masivo está relacionado con
pobre indexacion etc. Con 8 discos yo me lo habría montado así

2 discos en espejo para el SO.
4 discos en RAid 5 para los ficheros de datos
2 discos en espejo para los logs.

De todas formas monitoriza la longitud media de la cola de disco desde el
performance moonitor y siempre que no pase de 2xNúmero de discos, no te
preocupes que ahí no estará tu problema.

La configuración que yo te he propuesto puede maximizar rendimientos, pero
si al final la controladora es una sola, pues seguramente el problema será
el mismo, aunque los discos estén organizados "mejor".

Lo que si que te digo es que separar tempdb, está bien si tiene un fuerte
uso, pero no es una regla fija, y además siempre que tempdb tenga un uso
fuerte, hay que plantearse el porqúe de ese uso, y si se puede resolverlo.

Saludos
Miguel Egea



"Oscar" wrote in message
news:%

Hola Maxi,

Ahora mismo no tenemos problemas de rendimiento, ya que el sistema esta
entorno al 5% de la carga que deberá soportar, el caso es que en breve
tendre una ventana de tiempo donde podré parar el sistema y mover ficheros
de un sitio a otro.

El sistema consta de 8 discos físicos que forman dos volúmenes de datos en
configuración Raid 1 + 0 (striping entre dos discos y mirroring con los
otros dos),

Por lo que me cuentas , deducco que es más importante separar el tempdb de
las bases de datos que el resto de bases de datos del sistema .. ¿No?,
¿Incluso teniendo la replicación activa?

Dado que solo dispongo de dos sistemas de ficheros , que te parece esta
configuración :

DISCO C:
DISCO D:

Saludos y gracias.


www.metasincro.es
"Maxi" wrote in message
news:

Oscar, lo primero seria

BDD en un juego de discos (fisicos)
Tempdb (en otro juego de discos fisicos)
log (si es posible en otro juego)

Ahora, cuantos mas juegos pongas mas performante sera, de todas maneras
yo haria la configuracion minima que te mencione arriba, no pondria la
otra base en otro disco, y veria los consumos de i/o, quizas el problema
de performance este en otro lado


Salu2
Maxi [MVP SQL SERVER]


"Oscar" escribió en el mensaje
news:

Hola,

Bueno pues aqui estamos con más dudas existenciales, ahora le toca el
turno a la distribución de los distintos ficheros en los distintos
sistemas de ficheros.
En mi caso concreto tengo dos bases de datos de usuario DB1 y DB2. DB1
tiene un único fichero de 40GB para los datos y un fichero de 10GB para
el log, por su parte la DB2 tiene un fichero para datos de 10GB y otro
de 2GB para el log.
Todos los ficheros residen en el disco D: que esta montado sobre un
sistema raid 1 + 0, el sistema operativo reside en el disco C: (otro
raid 1+ 0).
Todos los ficheros de las bases de datos del sistema msdb, master,
tempdb residen en el disco D: (en el mismo directorio que los datos).

Teniendo en cuenta que se usará merge replication, que se trata de un
sistema OLPT con bastantes trasacciones simultaneas , existe unas
fuertes restricciones en cuanto al tiemopo máximo en el que se pueden
recuperar los datos , y se trata de un sistema 24x7

¿Cual es la mejor forma de distribuir los datos .?.

En principio lo que tengo intención de hacer es lo siguiente :

1) Mover los ficheros de las transaction Log de DB1 y DB2 al disco C.

preguntillas varias ..

a) Las bases de datos del sistema en el mismo disco que las bases de
datos de usuario (D) o en el otro.
¿Y los transaction logs?

b) Un único fichero por bbdd o varios??
Y si son varios, ¿Como es mejor distribuirlos ?

En fin cualquier recomendación será bienvenida.

Saludos.


www.metasincro.es

Hola Miguel, en sql2005 pensas q es igual? por ej, que pasa en sql2005
cuando usas CTE


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:eT$

No deduzcas eso de TEMPDB por que no es verdad, verás al final en esto no
hay ningún misterio

Los ficheros de log necesitan escrituras rápidas, esto es por que son
estructura secuenciales fundamentalmente de escritura (también se leen
obviamente pero el proceso no afecta tan directamente al rendimiento). De
ahí que se suelan separar de los archivos de datos, fundamentalmente de
lecturas aleatorias para buscar un dato acá y otro allá. Además de esto
se separan del disco C por dos razones fundamentalmente, la primera, por
que si se te llena la unidad es un problema muy grave y afecta al sistema
y eso con una base de datos ahí es más fácil, lo segundo por el fichero de
paginación, Windows actúa mucho con ese fichero sobre todo si no tiene
mucha memoria, por lo que potencialmente entrará en conflicto de intereses
con SQL. ¿y Tempdb? Que se le ha perdido a TempDB en todo esto, bueno, el
caso de tempdb es muy particular, es usada por varios procesos de la
ejecución de un query por ejemplo para hacer ordenaciones o cuando el plan
de ejecucíon necesita una workTable. En muchísimas ocasiones su uso masivo
está relacionado con pobre indexacion etc. Con 8 discos yo me lo habría
montado así

2 discos en espejo para el SO.
4 discos en RAid 5 para los ficheros de datos
2 discos en espejo para los logs.

De todas formas monitoriza la longitud media de la cola de disco desde el
performance moonitor y siempre que no pase de 2xNúmero de discos, no te
preocupes que ahí no estará tu problema.

La configuración que yo te he propuesto puede maximizar rendimientos, pero
si al final la controladora es una sola, pues seguramente el problema será
el mismo, aunque los discos estén organizados "mejor".

Lo que si que te digo es que separar tempdb, está bien si tiene un fuerte
uso, pero no es una regla fija, y además siempre que tempdb tenga un uso
fuerte, hay que plantearse el porqúe de ese uso, y si se puede resolverlo.

Saludos
Miguel Egea



"Oscar" wrote in message
news:%

Hola Maxi,

Ahora mismo no tenemos problemas de rendimiento, ya que el sistema esta
entorno al 5% de la carga que deberá soportar, el caso es que en breve
tendre una ventana de tiempo donde podré parar el sistema y mover
ficheros de un sitio a otro.

El sistema consta de 8 discos físicos que forman dos volúmenes de datos
en configuración Raid 1 + 0 (striping entre dos discos y mirroring con
los otros dos),

Por lo que me cuentas , deducco que es más importante separar el tempdb
de las bases de datos que el resto de bases de datos del sistema ..
¿No?,
¿Incluso teniendo la replicación activa?

Dado que solo dispongo de dos sistemas de ficheros , que te parece esta
configuración :

DISCO C:
DISCO D:

Saludos y gracias.


www.metasincro.es
"Maxi" wrote in message
news:

Oscar, lo primero seria

BDD en un juego de discos (fisicos)
Tempdb (en otro juego de discos fisicos)
log (si es posible en otro juego)

Ahora, cuantos mas juegos pongas mas performante sera, de todas maneras
yo haria la configuracion minima que te mencione arriba, no pondria la
otra base en otro disco, y veria los consumos de i/o, quizas el problema
de performance este en otro lado


Salu2
Maxi [MVP SQL SERVER]


"Oscar" escribió en el mensaje
news:

Hola,

Bueno pues aqui estamos con más dudas existenciales, ahora le toca el
turno a la distribución de los distintos ficheros en los distintos
sistemas de ficheros.
En mi caso concreto tengo dos bases de datos de usuario DB1 y DB2. DB1
tiene un único fichero de 40GB para los datos y un fichero de 10GB para
el log, por su parte la DB2 tiene un fichero para datos de 10GB y otro
de 2GB para el log.
Todos los ficheros residen en el disco D: que esta montado sobre un
sistema raid 1 + 0, el sistema operativo reside en el disco C: (otro
raid 1+ 0).
Todos los ficheros de las bases de datos del sistema msdb, master,
tempdb residen en el disco D: (en el mismo directorio que los datos).

Teniendo en cuenta que se usará merge replication, que se trata de un
sistema OLPT con bastantes trasacciones simultaneas , existe unas
fuertes restricciones en cuanto al tiemopo máximo en el que se pueden
recuperar los datos , y se trata de un sistema 24x7

¿Cual es la mejor forma de distribuir los datos .?.

En principio lo que tengo intención de hacer es lo siguiente :

1) Mover los ficheros de las transaction Log de DB1 y DB2 al disco C.

preguntillas varias ..

a) Las bases de datos del sistema en el mismo disco que las bases de
datos de usuario (D) o en el otro.
¿Y los transaction logs?

b) Un único fichero por bbdd o varios??
Y si son varios, ¿Como es mejor distribuirlos ?

En fin cualquier recomendación será bienvenida.

Saludos.


www.metasincro.es

Las CTE's tendrán su plan de ejecución específico, si se usan en su forma
más simple no dejan de ser una subconsulta, si se usan en su forma más
complicada para buscar jerarquias (como explica magníficamente Itzik ben-gan
en MSDN
http://msdn.microsoft.com/library/e...nhance.asp ))
tendrá su plan de ejcución para resolver esa problemática. Si ese plan de
ejecución en concreto usa o no Tempdb, francamente no lo se, si te interesa
mucho puedo enterarme, pero lo cierto es que la regla general es la misma,
al menos en lo que yo he leido hasta ahora y siempre basandome en mi
experiencia.

Saludos
Miguel Egea





"Maxi" wrote in message
news:

Hola Miguel, en sql2005 pensas q es igual? por ej, que pasa en sql2005
cuando usas CTE


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:eT$

No deduzcas eso de TEMPDB por que no es verdad, verás al final en esto no
hay ningún misterio

Los ficheros de log necesitan escrituras rápidas, esto es por que son
estructura secuenciales fundamentalmente de escritura (también se leen
obviamente pero el proceso no afecta tan directamente al rendimiento). De
ahí que se suelan separar de los archivos de datos, fundamentalmente de
lecturas aleatorias para buscar un dato acá y otro allá. Además de esto
se separan del disco C por dos razones fundamentalmente, la primera, por
que si se te llena la unidad es un problema muy grave y afecta al sistema
y eso con una base de datos ahí es más fácil, lo segundo por el fichero
de paginación, Windows actúa mucho con ese fichero sobre todo si no tiene
mucha memoria, por lo que potencialmente entrará en conflicto de
intereses con SQL. ¿y Tempdb? Que se le ha perdido a TempDB en todo esto,
bueno, el caso de tempdb es muy particular, es usada por varios procesos
de la ejecución de un query por ejemplo para hacer ordenaciones o cuando
el plan de ejecucíon necesita una workTable. En muchísimas ocasiones su
uso masivo está relacionado con pobre indexacion etc. Con 8 discos yo
me lo habría montado así

2 discos en espejo para el SO.
4 discos en RAid 5 para los ficheros de datos
2 discos en espejo para los logs.

De todas formas monitoriza la longitud media de la cola de disco desde el
performance moonitor y siempre que no pase de 2xNúmero de discos, no te
preocupes que ahí no estará tu problema.

La configuración que yo te he propuesto puede maximizar rendimientos,
pero si al final la controladora es una sola, pues seguramente el
problema será el mismo, aunque los discos estén organizados "mejor".

Lo que si que te digo es que separar tempdb, está bien si tiene un fuerte
uso, pero no es una regla fija, y además siempre que tempdb tenga un uso
fuerte, hay que plantearse el porqúe de ese uso, y si se puede
resolverlo.

Saludos
Miguel Egea



"Oscar" wrote in message
news:%

Hola Maxi,

Ahora mismo no tenemos problemas de rendimiento, ya que el sistema esta
entorno al 5% de la carga que deberá soportar, el caso es que en breve
tendre una ventana de tiempo donde podré parar el sistema y mover
ficheros de un sitio a otro.

El sistema consta de 8 discos físicos que forman dos volúmenes de datos
en configuración Raid 1 + 0 (striping entre dos discos y mirroring con
los otros dos),

Por lo que me cuentas , deducco que es más importante separar el tempdb
de las bases de datos que el resto de bases de datos del sistema ..
¿No?,
¿Incluso teniendo la replicación activa?

Dado que solo dispongo de dos sistemas de ficheros , que te parece esta
configuración :

DISCO C:
DISCO D:

Saludos y gracias.


www.metasincro.es
"Maxi" wrote in message
news:

Oscar, lo primero seria

BDD en un juego de discos (fisicos)
Tempdb (en otro juego de discos fisicos)
log (si es posible en otro juego)

Ahora, cuantos mas juegos pongas mas performante sera, de todas maneras
yo haria la configuracion minima que te mencione arriba, no pondria la
otra base en otro disco, y veria los consumos de i/o, quizas el
problema de performance este en otro lado


Salu2
Maxi [MVP SQL SERVER]


"Oscar" escribió en el mensaje
news:

Hola,

Bueno pues aqui estamos con más dudas existenciales, ahora le toca el
turno a la distribución de los distintos ficheros en los distintos
sistemas de ficheros.
En mi caso concreto tengo dos bases de datos de usuario DB1 y DB2.
DB1 tiene un único fichero de 40GB para los datos y un fichero de 10GB
para el log, por su parte la DB2 tiene un fichero para datos de 10GB y
otro de 2GB para el log.
Todos los ficheros residen en el disco D: que esta montado sobre un
sistema raid 1 + 0, el sistema operativo reside en el disco C: (otro
raid 1+ 0).
Todos los ficheros de las bases de datos del sistema msdb, master,
tempdb residen en el disco D: (en el mismo directorio que los datos).

Teniendo en cuenta que se usará merge replication, que se trata de un
sistema OLPT con bastantes trasacciones simultaneas , existe unas
fuertes restricciones en cuanto al tiemopo máximo en el que se pueden
recuperar los datos , y se trata de un sistema 24x7

¿Cual es la mejor forma de distribuir los datos .?.

En principio lo que tengo intención de hacer es lo siguiente :

1) Mover los ficheros de las transaction Log de DB1 y DB2 al disco C.

preguntillas varias ..

a) Las bases de datos del sistema en el mismo disco que las bases de
datos de usuario (D) o en el otro.
¿Y los transaction logs?

b) Un único fichero por bbdd o varios??
Y si son varios, ¿Como es mejor distribuirlos ?

En fin cualquier recomendación será bienvenida.

Saludos.


www.metasincro.es

Hola, pues lamento informarte que en sql2005 hay un consumo mucho mayor de
la tempdb :(


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:%

Las CTE's tendrán su plan de ejecución específico, si se usan en su forma
más simple no dejan de ser una subconsulta, si se usan en su forma más
complicada para buscar jerarquias (como explica magníficamente Itzik
ben-gan en MSDN
http://msdn.microsoft.com/library/e...nhance.asp
)) tendrá su plan de ejcución para resolver esa problemática. Si ese plan
de ejecución en concreto usa o no Tempdb, francamente no lo se, si te
interesa mucho puedo enterarme, pero lo cierto es que la regla general es
la misma, al menos en lo que yo he leido hasta ahora y siempre basandome
en mi experiencia.

Saludos
Miguel Egea





"Maxi" wrote in message
news:

Hola Miguel, en sql2005 pensas q es igual? por ej, que pasa en sql2005
cuando usas CTE


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:eT$

No deduzcas eso de TEMPDB por que no es verdad, verás al final en esto
no hay ningún misterio

Los ficheros de log necesitan escrituras rápidas, esto es por que son
estructura secuenciales fundamentalmente de escritura (también se leen
obviamente pero el proceso no afecta tan directamente al rendimiento).
De ahí que se suelan separar de los archivos de datos, fundamentalmente
de lecturas aleatorias para buscar un dato acá y otro allá. Además de
esto se separan del disco C por dos razones fundamentalmente, la
primera, por que si se te llena la unidad es un problema muy grave y
afecta al sistema y eso con una base de datos ahí es más fácil, lo
segundo por el fichero de paginación, Windows actúa mucho con ese
fichero sobre todo si no tiene mucha memoria, por lo que potencialmente
entrará en conflicto de intereses con SQL. ¿y Tempdb? Que se le ha
perdido a TempDB en todo esto, bueno, el caso de tempdb es muy
particular, es usada por varios procesos de la ejecución de un query por
ejemplo para hacer ordenaciones o cuando el plan de ejecucíon necesita
una workTable. En muchísimas ocasiones su uso masivo está relacionado
con pobre indexacion etc. Con 8 discos yo me lo habría montado así

2 discos en espejo para el SO.
4 discos en RAid 5 para los ficheros de datos
2 discos en espejo para los logs.

De todas formas monitoriza la longitud media de la cola de disco desde
el performance moonitor y siempre que no pase de 2xNúmero de discos, no
te preocupes que ahí no estará tu problema.

La configuración que yo te he propuesto puede maximizar rendimientos,
pero si al final la controladora es una sola, pues seguramente el
problema será el mismo, aunque los discos estén organizados "mejor".

Lo que si que te digo es que separar tempdb, está bien si tiene un
fuerte uso, pero no es una regla fija, y además siempre que tempdb tenga
un uso fuerte, hay que plantearse el porqúe de ese uso, y si se puede
resolverlo.

Saludos
Miguel Egea



"Oscar" wrote in message
news:%

Hola Maxi,

Ahora mismo no tenemos problemas de rendimiento, ya que el sistema esta
entorno al 5% de la carga que deberá soportar, el caso es que en breve
tendre una ventana de tiempo donde podré parar el sistema y mover
ficheros de un sitio a otro.

El sistema consta de 8 discos físicos que forman dos volúmenes de datos
en configuración Raid 1 + 0 (striping entre dos discos y mirroring con
los otros dos),

Por lo que me cuentas , deducco que es más importante separar el tempdb
de las bases de datos que el resto de bases de datos del sistema ..
¿No?,
¿Incluso teniendo la replicación activa?

Dado que solo dispongo de dos sistemas de ficheros , que te parece esta
configuración :

DISCO C:
DISCO D:

Saludos y gracias.


www.metasincro.es
"Maxi" wrote in message
news:

Oscar, lo primero seria

BDD en un juego de discos (fisicos)
Tempdb (en otro juego de discos fisicos)
log (si es posible en otro juego)

Ahora, cuantos mas juegos pongas mas performante sera, de todas
maneras yo haria la configuracion minima que te mencione arriba, no
pondria la otra base en otro disco, y veria los consumos de i/o,
quizas el problema de performance este en otro lado


Salu2
Maxi [MVP SQL SERVER]


"Oscar" escribió en el mensaje
news:

Hola,

Bueno pues aqui estamos con más dudas existenciales, ahora le toca el
turno a la distribución de los distintos ficheros en los distintos
sistemas de ficheros.
En mi caso concreto tengo dos bases de datos de usuario DB1 y DB2.
DB1 tiene un único fichero de 40GB para los datos y un fichero de
10GB para el log, por su parte la DB2 tiene un fichero para datos de
10GB y otro de 2GB para el log.
Todos los ficheros residen en el disco D: que esta montado sobre un
sistema raid 1 + 0, el sistema operativo reside en el disco C: (otro
raid 1+ 0).
Todos los ficheros de las bases de datos del sistema msdb, master,
tempdb residen en el disco D: (en el mismo directorio que los datos).

Teniendo en cuenta que se usará merge replication, que se trata de
un sistema OLPT con bastantes trasacciones simultaneas , existe unas
fuertes restricciones en cuanto al tiemopo máximo en el que se pueden
recuperar los datos , y se trata de un sistema 24x7

¿Cual es la mejor forma de distribuir los datos .?.

En principio lo que tengo intención de hacer es lo siguiente :

1) Mover los ficheros de las transaction Log de DB1 y DB2 al disco C.

preguntillas varias ..

a) Las bases de datos del sistema en el mismo disco que las bases de
datos de usuario (D) o en el otro.
¿Y los transaction logs?

b) Un único fichero por bbdd o varios??
Y si son varios, ¿Como es mejor distribuirlos ?

En fin cualquier recomendación será bienvenida.

Saludos.


www.metasincro.es

maxi, pivot y unpivot, CTE's cross apply, es posible (no conozco el detalle,
aunque lo voy a preguntar ahoramismo ) que necesiten usar tempdb para su
ejecución, pero el optimizador de consultas no va a "empeorar" con el paso
de versiones. Si usas las intrucciones de SQL 2000, el uso debería ser el
mismo.

Saludos
Miguel Egea
"Maxi" wrote in message
news:

Hola, pues lamento informarte que en sql2005 hay un consumo mucho mayor de
la tempdb :(


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:%

Las CTE's tendrán su plan de ejecución específico, si se usan en su forma
más simple no dejan de ser una subconsulta, si se usan en su forma más
complicada para buscar jerarquias (como explica magníficamente Itzik
ben-gan en MSDN
http://msdn.microsoft.com/library/e...nhance.asp )
) tendrá su plan de ejcución para resolver esa problemática. Si ese plan
de ejecución en concreto usa o no Tempdb, francamente no lo se, si te
interesa mucho puedo enterarme, pero lo cierto es que la regla general es
la misma, al menos en lo que yo he leido hasta ahora y siempre basandome
en mi experiencia.

Saludos
Miguel Egea





"Maxi" wrote in message
news:

Hola Miguel, en sql2005 pensas q es igual? por ej, que pasa en sql2005
cuando usas CTE


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:eT$

No deduzcas eso de TEMPDB por que no es verdad, verás al final en esto
no hay ningún misterio

Los ficheros de log necesitan escrituras rápidas, esto es por que son
estructura secuenciales fundamentalmente de escritura (también se leen
obviamente pero el proceso no afecta tan directamente al rendimiento).
De ahí que se suelan separar de los archivos de datos, fundamentalmente
de lecturas aleatorias para buscar un dato acá y otro allá. Además de
esto se separan del disco C por dos razones fundamentalmente, la
primera, por que si se te llena la unidad es un problema muy grave y
afecta al sistema y eso con una base de datos ahí es más fácil, lo
segundo por el fichero de paginación, Windows actúa mucho con ese
fichero sobre todo si no tiene mucha memoria, por lo que potencialmente
entrará en conflicto de intereses con SQL. ¿y Tempdb? Que se le ha
perdido a TempDB en todo esto, bueno, el caso de tempdb es muy
particular, es usada por varios procesos de la ejecución de un query
por ejemplo para hacer ordenaciones o cuando el plan de ejecucíon
necesita una workTable. En muchísimas ocasiones su uso masivo está
relacionado con pobre indexacion etc. Con 8 discos yo me lo habría
montado así

2 discos en espejo para el SO.
4 discos en RAid 5 para los ficheros de datos
2 discos en espejo para los logs.

De todas formas monitoriza la longitud media de la cola de disco desde
el performance moonitor y siempre que no pase de 2xNúmero de discos, no
te preocupes que ahí no estará tu problema.

La configuración que yo te he propuesto puede maximizar rendimientos,
pero si al final la controladora es una sola, pues seguramente el
problema será el mismo, aunque los discos estén organizados "mejor".

Lo que si que te digo es que separar tempdb, está bien si tiene un
fuerte uso, pero no es una regla fija, y además siempre que tempdb
tenga un uso fuerte, hay que plantearse el porqúe de ese uso, y si se
puede resolverlo.

Saludos
Miguel Egea



"Oscar" wrote in message
news:%

Hola Maxi,

Ahora mismo no tenemos problemas de rendimiento, ya que el sistema
esta entorno al 5% de la carga que deberá soportar, el caso es que en
breve tendre una ventana de tiempo donde podré parar el sistema y
mover ficheros de un sitio a otro.

El sistema consta de 8 discos físicos que forman dos volúmenes de
datos en configuración Raid 1 + 0 (striping entre dos discos y
mirroring con los otros dos),

Por lo que me cuentas , deducco que es más importante separar el
tempdb de las bases de datos que el resto de bases de datos del
sistema .. ¿No?,
¿Incluso teniendo la replicación activa?

Dado que solo dispongo de dos sistemas de ficheros , que te parece
esta configuración :

DISCO C:
DISCO D:

Saludos y gracias.


www.metasincro.es
"Maxi" wrote in message
news:

Oscar, lo primero seria

BDD en un juego de discos (fisicos)
Tempdb (en otro juego de discos fisicos)
log (si es posible en otro juego)

Ahora, cuantos mas juegos pongas mas performante sera, de todas
maneras yo haria la configuracion minima que te mencione arriba, no
pondria la otra base en otro disco, y veria los consumos de i/o,
quizas el problema de performance este en otro lado


Salu2
Maxi [MVP SQL SERVER]


"Oscar" escribió en el mensaje
news:

Hola,

Bueno pues aqui estamos con más dudas existenciales, ahora le toca
el turno a la distribución de los distintos ficheros en los
distintos sistemas de ficheros.
En mi caso concreto tengo dos bases de datos de usuario DB1 y DB2.
DB1 tiene un único fichero de 40GB para los datos y un fichero de
10GB para el log, por su parte la DB2 tiene un fichero para datos de
10GB y otro de 2GB para el log.
Todos los ficheros residen en el disco D: que esta montado sobre un
sistema raid 1 + 0, el sistema operativo reside en el disco C: (otro
raid 1+ 0).
Todos los ficheros de las bases de datos del sistema msdb, master,
tempdb residen en el disco D: (en el mismo directorio que los
datos).

Teniendo en cuenta que se usará merge replication, que se trata de
un sistema OLPT con bastantes trasacciones simultaneas , existe unas
fuertes restricciones en cuanto al tiemopo máximo en el que se
pueden recuperar los datos , y se trata de un sistema 24x7

¿Cual es la mejor forma de distribuir los datos .?.

En principio lo que tengo intención de hacer es lo siguiente :

1) Mover los ficheros de las transaction Log de DB1 y DB2 al disco
C.

preguntillas varias ..

a) Las bases de datos del sistema en el mismo disco que las bases
de datos de usuario (D) o en el otro.
¿Y los transaction logs?

b) Un único fichero por bbdd o varios??
Y si son varios, ¿Como es mejor distribuirlos ?

En fin cualquier recomendación será bienvenida.

Saludos.


www.metasincro.es