Servidor ORACLE

[FaiTCRaH]

Bien, estoy aprendiendo esto de DBA, de a poco... digamos que por "asignación del equipo de trabajo".

Resulta que necesitamos comprar un servidor nuevo para el proyecto en el que estamos, y es un "pequeño" servidor. Ya hemos calculado algo del tamaño de la data que vamos a utilizar, algo así como 6TB (estamos hablando de cruces de más de 150 millones de registros). En cuanto a los procesos, prácticamente no habrá en paralelo, por lo que a lo más necesitaríamos 2 procesadores (probablemente Intel Xeon o AMD Opteron, quizás Core2Duo).

Mi consulta va por el lado de la RAM, cosa de que las consultas no se demoren días o nos quedemos sin memoria. Estamos calculando alrededor de 4 GB por procesador, pero creo que se me hace chico, por lo que podrían ser 8 GB por procesador.

Necesito alguna recomendación referente a este punto, o bien, alguien que tenga experiencia con ese nivel de datos.

Gracias de antemano...

P.D.: el proyecto es una 2da versión, y en la 1a versión se quiedaron literalmente sin espacio... es una cantidad gigante de datos, y no es chiste.

[matanga]

Hola,

Es un sugerencia muy dificil de dar o estimar, como dijo una persona que sabe muchisimo de Oracle

size of database is almost not relevant.
what is DONE in the database is.

El tamaño de la base de datos es casi irrelevante.
Lo que se hace en la base de datos lo es.

En fin, para comentar algunos numeros, puedo decir que,

Una forma de dividir la memoria del servidor es un 50/60% para la SGA dejando el resto para los procesos en modo servidor dedicado, que utilizan la PGA, y un 20/10% de memoria para el sistema operativo, dependiendo si es Winows o Linux/Unix.

La cantidad de SGA dependera, en grandes ramas, de cuanto quieras asignar a buffer cache, cache para datos, o shared pool, cache para codigo SQL / PLSQL. Y la cantidad de PGA dependera, de la cantidad de conexiones que tengas a la base y de la cantidad de operaciones que se realicen, operaciones de Sort (ORDER BY, GROUP BY, ROLLUP,etc), Hash-join, Bitmap merge, Bitmap create, escrituras en buffer realizadas por operaciones de carga bulk.

Otra forma es configurar la base de datos en modo servidor compartido, en este caso la SGA se puede incrementar hasta un 70/80%.

Ademas hay que tener en cuenta si el servidor es dedicado para Oracle, o tendras otras aplicaciones.

Como experiencia, te comento que trabaje en un Data Warehouse de 5TB, que el servidor tenia 16G de memoria y 8 procesadores SPARC, donde el grado de paralelismo para las consultas era muy importante y desde luego en entornos de 64 Bits.

En cuanto a los procesos, prácticamente no habrá en paralelo, por lo que a lo más necesitaríamos 2 procesadores

No estoy seguro de a que te refieres con esto, pero cuando se hacen full-scan sobre tablas grandes, una de las formas de optimizarlo es con parallel-query y mas de dos procesadores te ayudaran notablemente.

Saludos.

[FaiTCRaH]

el servidor es exclusivo para Oracle... tendrá Linux, aunque está en veremos lo de la distribución (entre SUSE y CentOS)

a lo que me refiero es a que no habrá paralelismo de procesos creados por nosotros... un select corriendo a la vez, por decirlo así...

[matanga]

Hola,

Tambien esta disponible la nueva distribucion de linux de Oracle, http://www.oracle.com/lang/es/technologies/linux/index.html es gratuita para bajar y utilizar y dispone diferentes tipos de soporte, pagos claro.

En cuanto a paralelismo, aunque tengas una sola consulta ejecutandose por vez, a veces es necesario que un solo SELECT inicie multiples procesos para recorrer una tabla grande en forma paralela, de ahi el termino de parallel-query, pero para que esto sea eficiente, cada subproceso debe ejecutarse en un procesador diferente.

Por ejemplo, en un full-scan sobre una tabla con parallel-query definido en el SELECT

Código:

SELECT /*+ PARALLEL (T1, 4) */ 
COUNT(*) FROM T1;

Y parallel-query definido en una tabla a traves de la sentencia ALTER TABLE

ALTER TABLE T1 PARALLEL (DEGREE 4);

En este segundo caso, cada vez que se haga un full-scan sobre la tabla, se resolvera con una grado de paralelismo de 4.

De todos modos es una forma de hacer tunning sobre SQL, no es mandatorio de utilizar, solo queria comentar como podrian ser de utilidad mas de 2 procesadores.

Saludos.

[FaiTCRaH]

gracias por el tip... en ese caso, sí ocuparía paralelismo en el caso del select, ya q el volumen de datos es bastante grande y mientras menos se demore, mejor...


referente al

Código:

ALTER TABLE T1 PARALLEL (DEGREE 4)

el valor 4 es debido a la cantidad de procesadores?

[matanga]

Hola,

El valor de parallel, ya sea en el HINT o en el ALTER TABLE, hace referencia a la cantidad de procesos que se van a iniciar para recorrer la tabla + 1, este 1 adicional es el coordinador de la consulta, es decir el que gobierna los 4 restantes. Pero, la cantidad de procesos puede llegar al doble si en la misma consulta hay un ORDER BY o GROUP BY.

Para redondear, si la consulta fuese,

Código:

SELECT /*+ PARALLEL (T1, 4) */  * FROM T1;

Habran 4 procesos recorriendo la tabla mas 1 que gobierna, y si la consulta fuese,

Código:

SELECT /*+ PARALLEL (T1, 4) */  * FROM T1 GROUP BY campo1

Los procesos pueden llegar hasta 9.

Siempre, el modelo optimo es que cada proceso tenga su propio procesador, o al menos su propio nucleo (ahora que estan los Dual Core o Quad Core), pero no es obligatorio, se pueden tener mejoras de rendimiento aun cuando la cantidad de procesos supera la cantidad de procesadores, esto ya es particular de cada consulta y de la carga del equipo.

Saludos.