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,

Muchas gracias por tu contestación , me ha aclarado algunas cosa, y la
distribución que propones me parece muy buena, salvo por un detalle,
el RAID 5. Teniendo en cuenta que es una base de datos transaccional donde
continuamente se realizan inserciones y borrados (y en menor medida
updates),
no me queda nada claro el uso del RAID 5, este volumen creo que lo dejare
como esta con un RAID 10.

En cuanto al uso del disco C, no habia caido en el uso del espacio de
swap, que si me parece un buena razon para plantearse el cambio a otro
disco.

El uso del tempdb, en el sistema será bajo , ya que no se utilizan apenas
ordenaciones, (y muy pocas funciones de agregación), además todas las
querys usan indices. La parte del sistema que se "salta" este
planteamiento es la generación de listados donde si se realizan
ordenaciones, se usan funcines de agregación ... etc, pero pare este caso
concreto nos estamos planteando realizar estas operaciones en una base de
datos en otro servidor que se sincronize con el pricipal mediante
backup/restore , log shipping ..


Saludos y muchas gracias de nuevo.


www.metasincro.es
"Miguel Egea" wrote in message
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