Distribución de los datos en ficheros ..

Si Miguel eso si, pero yo le recomende separar la tempdb porque he visto en
sql2005 un alto consumo de la misma comparado con SQL2000 (sobre todo en las
operaciones que indicas)


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:

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

Hola de Nuevo, Maxi no estoy en absoluto de acuerdo con tu afirmación,
supongo que tendrás tu información y la habrás contrastado, yo estuve en
una presentación con Mirek Sztajno y Wei Xiao del Storage engine y no les
entendí eso que sugieres para nada. Bien al contrario contaron bastantes
improvements sobre el uso de TEMPDB alguno de ellos puede encontrarlo aquí
http://www.scalabilityexperts.com/d...cle&ID5, aunque
de lo que extá hablando no aplica en un caso genérico en el que Tempdb no es
un problema.
Creo que el tema, de todas formas y amén de si SQL 2005 usará más o menos
Tempdb, (por cierto existen dmo para ver el uso), lo que importa no es tanto
eso sino en que caso es un problema y cual es la norma general. En
consultoría yo he recomentado crear tablas temporales y también he
recomendado lo contrario, y esto es por que todos los escenarios no son
iguales en absoluto y como ejemplo te puedo decir que he conseguido que una
consulta que tardaba 40 minutos tarde menos de 3 simplemente creando tablas
temporales, por que las worktables que creaba el Query optimizer y la forma
de ejecutar la consulta no era la mejor de las posibles. También otras veces
he creado índices y he recomendado quitarlas por que perjudicaban el
rendimiento.

De todas formas, por favor, pasame el link de donde dice que SQL Server 2005
tendrá un uso mayor de tempdb.

Saludos

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"


P.D.: Creo que las discusciones técnicas potencian la calidad de este grupo,
es posible que yo esté equivocado, también es posible que no, lo que
realmente importa es que yo pueda demostrar que no lo estoy o tu puedas
demostrarme que si lo estoy. En cualqueira de los dos casos, todos los que
leamos este post aprenderemos mucho, que en resumen es de lo que se trata.




"Miguel Egea" wrote in message
news:

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

En el otro hilo te he explicado por que no estoy de acuerdo :-)
"Maxi" wrote in message
news:OZpU8$

Si Miguel eso si, pero yo le recomende separar la tempdb porque he visto
en sql2005 un alto consumo de la misma comparado con SQL2000 (sobre todo
en las operaciones que indicas)


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:

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

Miguel, coincido contigo!! pero lo que he probado de SQL2005 y en un grupo
de usuarios lo q hemos probado (justamente el jueves hicimos una demo y esto
se vio y se discutio) era el consumo de la tempdb y la recomendacion de
tenerla en un arreglo distinto. Prometo buscarte informacion (le voy a pedir
al orador q me la pase ;-)


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:

Hola de Nuevo, Maxi no estoy en absoluto de acuerdo con tu afirmación,
supongo que tendrás tu información y la habrás contrastado, yo estuve en
una presentación con Mirek Sztajno y Wei Xiao del Storage engine y no les
entendí eso que sugieres para nada. Bien al contrario contaron bastantes
improvements sobre el uso de TEMPDB alguno de ellos puede encontrarlo aquí
http://www.scalabilityexperts.com/d...cle&ID5,
aunque de lo que extá hablando no aplica en un caso genérico en el que
Tempdb no es un problema.
Creo que el tema, de todas formas y amén de si SQL 2005 usará más o menos
Tempdb, (por cierto existen dmo para ver el uso), lo que importa no es
tanto eso sino en que caso es un problema y cual es la norma general. En
consultoría yo he recomentado crear tablas temporales y también he
recomendado lo contrario, y esto es por que todos los escenarios no son
iguales en absoluto y como ejemplo te puedo decir que he conseguido que
una consulta que tardaba 40 minutos tarde menos de 3 simplemente creando
tablas temporales, por que las worktables que creaba el Query optimizer y
la forma de ejecutar la consulta no era la mejor de las posibles. También
otras veces he creado índices y he recomendado quitarlas por que
perjudicaban el rendimiento.

De todas formas, por favor, pasame el link de donde dice que SQL Server
2005 tendrá un uso mayor de tempdb.

Saludos

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"


P.D.: Creo que las discusciones técnicas potencian la calidad de este
grupo, es posible que yo esté equivocado, también es posible que no, lo
que realmente importa es que yo pueda demostrar que no lo estoy o tu
puedas demostrarme que si lo estoy. En cualqueira de los dos casos, todos
los que leamos este post aprenderemos mucho, que en resumen es de lo que
se trata.




"Miguel Egea" wrote in message
news:

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

Si por favor,..


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"

"Maxi" wrote in message
news:

Miguel, coincido contigo!! pero lo que he probado de SQL2005 y en un grupo
de usuarios lo q hemos probado (justamente el jueves hicimos una demo y
esto se vio y se discutio) era el consumo de la tempdb y la recomendacion
de tenerla en un arreglo distinto. Prometo buscarte informacion (le voy a
pedir al orador q me la pase ;-)


Salu2
Maxi [MVP SQL SERVER]


"Miguel Egea" escribió en el mensaje
news:

Hola de Nuevo, Maxi no estoy en absoluto de acuerdo con tu afirmación,
supongo que tendrás tu información y la habrás contrastado, yo estuve en
una presentación con Mirek Sztajno y Wei Xiao del Storage engine y no les
entendí eso que sugieres para nada. Bien al contrario contaron bastantes
improvements sobre el uso de TEMPDB alguno de ellos puede encontrarlo
aquí http://www.scalabilityexperts.com/d...cle&ID5,
aunque de lo que extá hablando no aplica en un caso genérico en el que
Tempdb no es un problema.
Creo que el tema, de todas formas y amén de si SQL 2005 usará más o menos
Tempdb, (por cierto existen dmo para ver el uso), lo que importa no es
tanto eso sino en que caso es un problema y cual es la norma general. En
consultoría yo he recomentado crear tablas temporales y también he
recomendado lo contrario, y esto es por que todos los escenarios no son
iguales en absoluto y como ejemplo te puedo decir que he conseguido que
una consulta que tardaba 40 minutos tarde menos de 3 simplemente creando
tablas temporales, por que las worktables que creaba el Query optimizer y
la forma de ejecutar la consulta no era la mejor de las posibles. También
otras veces he creado índices y he recomendado quitarlas por que
perjudicaban el rendimiento.

De todas formas, por favor, pasame el link de donde dice que SQL Server
2005 tendrá un uso mayor de tempdb.

Saludos

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"


P.D.: Creo que las discusciones técnicas potencian la calidad de este
grupo, es posible que yo esté equivocado, también es posible que no, lo
que realmente importa es que yo pueda demostrar que no lo estoy o tu
puedas demostrarme que si lo estoy. En cualqueira de los dos casos, todos
los que leamos este post aprenderemos mucho, que en resumen es de lo que
se trata.




"Miguel Egea" wrote in message
news:

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