Base de datos Log

Hola,

Básicamente por rendimiento, así cuando se produzcan actualizaciones irá más
rápido, al utilizar los dos discos.

Un saludo
Salvador Ramos
Murcia - España

[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL Server y .NET)


"Miguel" escribió en el mensaje
news:

¿Por qué es recomendable según me informan separar la base de datos log de
la de datos, es decir colocar cada una en discos diferentes?

Gracias


Miguel

Muchas gracias

"Salvador Ramos" wrote in message
news:

Hola,

Básicamente por rendimiento, así cuando se produzcan actualizaciones irá

más

rápido, al utilizar los dos discos.

Un saludo
Salvador Ramos
Murcia - España

[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL Server y .NET)


"Miguel" escribió en el mensaje
news:
> ¿Por qué es recomendable según me informan separar la base de datos log

de

> la de datos, es decir colocar cada una en discos diferentes?
>
> Gracias
>
>
> Miguel
>
>

Por completar la información de salva, esto viene de que tienen roles
distintos, el log de transacciones es un fichero al que se accede
fundamentalmente para escrituras y de forma secuencial, los ficheros de
datos tienen accessos fundamentalmente de lectura y fundamentalmente
aleatorio, de ahí que al menos dos discos distintos, con redudancia lo más
rápida posible para escrituras en el fichero de log es lo recomendado.

Si tienes además varios ficheros de datos en varios discos distintos y las
controladoras de estos discos permiten accesos concurrentes, mejor, más
rendimiento aún claro :-)


Miguel Egea
Visita mi web http://www.portalsql.com
SQL Server MVP, Mentor
Solid Quality Learning
http://www.SolidQualityLearning.com
"Solid Quality Learning is the trusted global provider of advanced education
and solutions for the entire Microsoft database platform"

"Miguel" wrote in message
news:e%

Muchas gracias

"Salvador Ramos" wrote in message
news:

Hola,

Básicamente por rendimiento, así cuando se produzcan actualizaciones irá

más

rápido, al utilizar los dos discos.

Un saludo
Salvador Ramos
Murcia - España

[Microsoft MVP SQL Server]
www.helpdna.net (información sobre SQL Server y .NET)


"Miguel" escribió en el mensaje
news:
> ¿Por qué es recomendable según me informan separar la base de datos log

de

> la de datos, es decir colocar cada una en discos diferentes?
>
> Gracias
>
>
> Miguel
>
>

Los datos e indices, es información cuya naturaleza es la Lectura. Por
ejemplo, una factura la insertas una vez... sin embargo la lees en multitud
de ocasiones (previsualizar factura, imprimir factura, generación impuestos
trimestrales, generación impuestos anuales, auditorías internas, etc.). Es
lógico... si guardo un dato, es pa leerlo !! vaya tontería sino... Esto es lo
habitual, salvo que tengas una gran base de datos de auditoría (por ejemplo),
dónde te limitas a almacenar información "porque sí", y no la vuelvas a leer
salvo que se produzcan ciertas situaciones.

Sin embargo, el Log es al contrario, pues su naturaleza es la Escritura. Es
decir, en el se escribe constantemente, y su principal razón para leer es
ejecutar un RollBack, algo no muy habitual... normal... si tu inserción o
update produce un rollback... ¿pa que lo intentas? hacerlo pa naa es
tontería...

Por ello, lo apropiado es poner tus datos e indices en un RAID5 (premian las
lecturas paralelas, pero las escrituras son penalizadas por la paridad... y
de todos los discos de tu volumen sólo pierdes uno por la paridad. Y sobre
todo, tienes redundancia al fallo), y tu log en un RAID1 (no penalizas las
escrituras al no haber paridad, pero de dos discos pierdes uno que hace de
espejo. También tienes redundancia).

Como nos interesa diferentes niveles de RAID, lá única manera de conseguirlo
es con volúmenes diferentes: uno o varios volúmenes en RAID5 y uno o varios
volúmenes en RAID0.

A todo esto, si no tenemos discos sufientes, poco vamos a hacer...

En una ocasión, un amigo mío se tomó la molestia de probar diferentes
escenarios, combinando el tener todo en el mismo volumen (datos, indices y
log), o separado (cada cosa en su volumen, o datos e indices en un volumen y
log en otro, etc). Obviamente, estas combinaciones se realizaban con RAID5
y/ó RAID1, claro, y partimos que el sistema dispone de sus propios discos (la
máquina en cuestión: un DELL con con armario de discos fiber channel, 20 ó 30
discos SCSI y 4 CPUs Xeon)

Al final resultó prácticamente lo comido por lo servido. Después de probar
bastantes combinaciones, y lanzar diferentes procesos bastante costosos, la
diferencia no era muy apreciable... es decir, en función de si tus procesos
premiaban las lecturas o las escrituras, en si ejecutaban lecturas completas
de tablas o de índices, etc., pues obviamente o mejoras una cosa más que
otras, u otra más que unas !! Si admito que podías mejorar un 10 ó 15% en
algo... pero ojo, ten en cuenta que con otra combinación mejorarías a lo
mejor un 10% ó 15% en otro factor !!

En términos generales, mejorás más cambiando tu subsistema de E/S (ej:de
SCSI a Fiber Channel), manteniendo defragmentados tus discos, eliminando los
cursores de los programadores "novatos", optimizando la indexación de tu
BBDD, o particionando tablas, que dejándote los cuernos en las múltiples
combinaciones posibles de tus discos y las consiguientes pruebas de
performance.

Saludos,
Guillermo

PD: en la prueba de tener junto datos, indices y log en un único RAID5, la
diferencia se notaba un 10%-15% aproximadamente. En la prueba de separar
datos e indices en diferentes volúmenes, la diferencia era ridícula (nos
quedamos con ganas de probar con una máquina con diferentes
canales/controladoras de E/S).

"Miguel" wrote:

¿Por qué es recomendable según me informan separar la base de datos log de
la de datos, es decir colocar cada una en discos diferentes?

Gracias


Miguel

Hola Guillermo

PD: en la prueba de tener junto datos, indices y log en un único RAID5, la
diferencia se notaba un 10%-15% aproximadamente. En la prueba de separar
datos e indices en diferentes volúmenes, la diferencia era ridícula (nos
quedamos con ganas de probar con una máquina con diferentes
canales/controladoras de E/S).

supongo que no tendrás a mano los scripts que utilizaste para llegar a esta
conclusión, pero aunque un 10-15% es un valor a considerar, en los entornos
en los que nosotros trabajamos (a partir de 2000 transacciones por segundo),
resultaría inmanejable tener juntos datos, índices, y log.

Yo recomendaría que comprobaríais el uso de los discos desde perfmon (%uso,
bytes leidos, escritos, long de cola de disco), y lo contrastárais con
fn_virtualfilestats

sobre datos e índices en distintas unidades, evidentemente deberás tener
consultas que accedan a los índices en paralelo; puedo asegurar que la
diferencia también es notable... ¿porcentaje? es relativo... en entorno de
pruebas puedes tener obtener reducción de tiempo de altos porcentajes, pero
lo importante es cuando está en producción, y la sensación general del
rendimiento del sistema ;-)

Eladio Rincón,
http://www.siquelnet.com

Mentor, SQL Server MVP
Solid Quality Learning Iberoamericana
http://www.solidqualitylearning.com

"Guillermo Roldan" wrote in
message news:

Los datos e indices, es información cuya naturaleza es la Lectura. Por
ejemplo, una factura la insertas una vez... sin embargo la lees en
multitud
de ocasiones (previsualizar factura, imprimir factura, generación
impuestos
trimestrales, generación impuestos anuales, auditorías internas, etc.). Es
lógico... si guardo un dato, es pa leerlo !! vaya tontería sino... Esto es
lo
habitual, salvo que tengas una gran base de datos de auditoría (por
ejemplo),
dónde te limitas a almacenar información "porque sí", y no la vuelvas a
leer
salvo que se produzcan ciertas situaciones.

Sin embargo, el Log es al contrario, pues su naturaleza es la Escritura.
Es
decir, en el se escribe constantemente, y su principal razón para leer es
ejecutar un RollBack, algo no muy habitual... normal... si tu inserción o
update produce un rollback... ¿pa que lo intentas? hacerlo pa naa es
tontería...

Por ello, lo apropiado es poner tus datos e indices en un RAID5 (premian
las
lecturas paralelas, pero las escrituras son penalizadas por la paridad...
y
de todos los discos de tu volumen sólo pierdes uno por la paridad. Y sobre
todo, tienes redundancia al fallo), y tu log en un RAID1 (no penalizas las
escrituras al no haber paridad, pero de dos discos pierdes uno que hace de
espejo. También tienes redundancia).

Como nos interesa diferentes niveles de RAID, lá única manera de
conseguirlo
es con volúmenes diferentes: uno o varios volúmenes en RAID5 y uno o
varios
volúmenes en RAID0.

A todo esto, si no tenemos discos sufientes, poco vamos a hacer...

En una ocasión, un amigo mío se tomó la molestia de probar diferentes
escenarios, combinando el tener todo en el mismo volumen (datos, indices y
log), o separado (cada cosa en su volumen, o datos e indices en un volumen
y
log en otro, etc). Obviamente, estas combinaciones se realizaban con RAID5
y/ó RAID1, claro, y partimos que el sistema dispone de sus propios discos
(la
máquina en cuestión: un DELL con con armario de discos fiber channel, 20 ó
30
discos SCSI y 4 CPUs Xeon)

Al final resultó prácticamente lo comido por lo servido. Después de probar
bastantes combinaciones, y lanzar diferentes procesos bastante costosos,
la
diferencia no era muy apreciable... es decir, en función de si tus
procesos
premiaban las lecturas o las escrituras, en si ejecutaban lecturas
completas
de tablas o de índices, etc., pues obviamente o mejoras una cosa más que
otras, u otra más que unas !! Si admito que podías mejorar un 10 ó 15% en
algo... pero ojo, ten en cuenta que con otra combinación mejorarías a lo
mejor un 10% ó 15% en otro factor !!

En términos generales, mejorás más cambiando tu subsistema de E/S (ej:de
SCSI a Fiber Channel), manteniendo defragmentados tus discos, eliminando
los
cursores de los programadores "novatos", optimizando la indexación de tu
BBDD, o particionando tablas, que dejándote los cuernos en las múltiples
combinaciones posibles de tus discos y las consiguientes pruebas de
performance.

Saludos,
Guillermo

PD: en la prueba de tener junto datos, indices y log en un único RAID5, la
diferencia se notaba un 10%-15% aproximadamente. En la prueba de separar
datos e indices en diferentes volúmenes, la diferencia era ridícula (nos
quedamos con ganas de probar con una máquina con diferentes
canales/controladoras de E/S).

"Miguel" wrote:

¿Por qué es recomendable según me informan separar la base de datos log
de
la de datos, es decir colocar cada una en discos diferentes?

Gracias


Miguel