Introducción
Dimensionar la Memoria
Debemos tener en cuenta que la memoria asignada a Oracle no debe superar el 80% de la memoria del sistema. Como el dimensionado es algo muy particular yo utilizo una OO Calc para poder tener unos valores aproximados, puedes descargarte mi Super Oracle Calc desde aquí
Uso de OFA y separación de peticiones I/O
Es muy importante intentar separar los accesos I/O de las bases de datos en diferentes devices, de esta forma, el rendimiento no se verá tan afectado. Para ello, utilizaremos OFA ya que nos permite distribuir de una forma sencilla la estructura de Oracle, en la Instalación de Oracle Parte 2 hay una explicación más detallada sobre OFA, mira el siguiente ejemplo
Una vez definido todos los puntos necesarios, podemos comenzar con la instalación de la nueva base de datos, para ello, lo único que debemos hacer es asignar nuestro nuevo ORACLE_SID y comenzar con la instalación de forma normal, puedes encontrar los pasos en Referencias, pero ... si estás aquí es que ya sabes Instalar Oracle sin Ayuda :D
Conclusión
Hemos visto que antes de ponernos manos a la obra debemos tener en cuenta varios factores y planificar la instalación de forma detallada para evitar que colapsemos la máquina, sin embargo, el uso de Solaris projects, nos permite modificar la parametrización para hacerla dinámica y ajustada a las necesidades reales.
Espero no haberos aburrido,
ya sabéis que ante cualquier duda, podéis contactar conmigo.
Referencias
En los post anteriores hemos visto cómo instalar Oracle 10g sobre Solaris y cómo podemos configurarlo para utilizar SMF en la gestión de los listener, en esta ocasión vamos a ver cómo podemos instalar varias bases de datos sobre un único motor.
Antes de ponernos manos a la obra, debemos tener en cuenta varios puntos:
- No podemos, o mejor dicho no es útil, instalar nuestra base de datos principal y su stand by sobre el mismo motor, principalmente porque cuando queramos parchear Oracle, ambas deberán estar detenidas
- Debemos tener definidas las prioridades de cada base de datos, por ejemplo, si compartimos nuestra base de datos transacional (OLTP) con el DatawareHouse, van a estar peleando por los recursos de la máquina?
- Qué tipo de planificador vamos a usar, FX, TS, FSS. En este caso la mejor (única) opción será utilizar FSS y para ello deberemos definir los cpu-shares de cada project.
- Cuánta memoria voy a asignar a cada instancia? Es muy importante dimensionar Oracle para que no tire de swap
Definición del planificador FSS y Sus Shares
En este punto, cuando tenemos que ejecutar diferentes bases de datos con diferentes prioridades, la mejor solución es utilizar el planificador FSS con división de cargas. Me explico, vamos a definir cuánta CPU puede utilizar cada proceso: listener, logwritter, archivelog, rman, etc. De esta forma, nos aseguraremos que un proceso no colapse a los demás
Lo primero que debemos hacer es asignar el planificador FSS como predeterminado (si no lo hemos hecho ya), aquí tienes cómo asignarlo
Una vez asignado, debemos definir los cpu-shares de cada proyecto, vamos a ver cómo podemos separarlos. En nuestro ejemplo, tenemos dos bases de datos, una OLTP pura, y otra dedicada a Internet, partiendo de esta base haremos la tabla de repartos contando con la siguiente fórmula:
Veamos un ejemplo, si tenemos tres projects: listener, database, rman y queremos que el reparto de uso de CPU sea: 40%, 50% y 10% tendremos el siguiente reparto:
- Project Listener, cpu-shares = 40 --> 40/(40+50+10)*100
- Project Database, cpu-shares = 50 --> 50/(50+40+10)*100
- Project Rman, cpu-shares = 10 --> 10/(10+40+50)*100
En este ejemplo es fácil ver los valores ya que hemos utilizado unos "números sencillos", pero con este tipo de asignación, nos quedamos con un margen de maniobra mínimo. Por ejemplo, si necesitamos separar los procesos de la base de datos en: logwritter, archivelog, jobs, etc. tan sólo tenemos 10 cpu-shares libres porque nuestra escala es de 100. Vamos a ver un ejemplo con una escala de 1700 cpu-shares y añadiendo tres project más, nos quedaría el siguiente reparto:
- Project Listener, cpu-shares=375 --> 375/1685*100=22,26% CPU
- Project Database, cpu-shares=300 --> 300/1685*100=17,8% CPU
- Project Rman, cpu-shares=100 --> 100/1685*100=5,93% CPU
- Project LogWritter, cpu-shares=860 -> 860/1685*100=51,04% CPU
- Project archivelog, cpu-shares=40 -> 40/1685*100=2,37% CPU
- Project jobs, cpu-shares=10 -> 10/1685*100=0,59% CPU
Esto es un ejemplo de lo que podemos hacer y cómo calcular el valor de %CPU que estamos asignando a cada project y cada instalación es un mundo aunque intentaré hacerlo sencillo, xD
Uso de projecmod para modificar los cpu-shares
Una de las venatajas de utilizar projects es que nos permite modificar la parametrización dinámicamente (no confundir con Solaris Dynamic Reconfiguration u Oracle Dynamic Intimated Shared Memory) utilizando el comando projmod, por ejemplo, si queremos redistribuir la carga de cpu-shares entre nuestros projectos utilizaremos lo siguiente para asignar como nuevo cpu-shares 750 al project oltp2.dedicated
Aquí os muestro un de nuestras Oracle, en una M4000 sobre Solaris 10 con dos bases de datos y un único motor 10.2.0.4
Una de las venatajas de utilizar projects es que nos permite modificar la parametrización dinámicamente (no confundir con Solaris Dynamic Reconfiguration u Oracle Dynamic Intimated Shared Memory) utilizando el comando projmod, por ejemplo, si queremos redistribuir la carga de cpu-shares entre nuestros projectos utilizaremos lo siguiente para asignar como nuevo cpu-shares 750 al project oltp2.dedicated
# projmod -sK "project.cpu-shares=(privileged,750,none)" oltp2.dedicatedUn Resultado Real usando projects
Aquí os muestro un de nuestras Oracle, en una M4000 sobre Solaris 10 con dos bases de datos y un único motor 10.2.0.4
Debemos tener en cuenta que la memoria asignada a Oracle no debe superar el 80% de la memoria del sistema. Como el dimensionado es algo muy particular yo utilizo una OO Calc para poder tener unos valores aproximados, puedes descargarte mi Super Oracle Calc desde aquí
Uso de OFA y separación de peticiones I/O
Es muy importante intentar separar los accesos I/O de las bases de datos en diferentes devices, de esta forma, el rendimiento no se verá tan afectado. Para ello, utilizaremos OFA ya que nos permite distribuir de una forma sencilla la estructura de Oracle, en la Instalación de Oracle Parte 2 hay una explicación más detallada sobre OFA, mira el siguiente ejemplo
$ iostat -xnpzm 6Instalación de nueva Base de datos Oracle sobre un motor único
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
0.3 0.2 2.8 0.2 0.0 0.0 1.0 11.5 0 0 sd0
0.3 0.2 2.8 0.2 0.0 0.0 1.0 11.5 0 0 sd0,a
0.0 0.0 0.0 0.0 0.0 0.0 0.0 6.5 0 0 sd0,b
0.0 0.1 0.1 0.2 0.0 0.0 0.8 18.7 0 0 sd2
0.0 0.1 0.1 0.2 0.0 0.0 0.8 18.7 0 0 sd2,g
413.1 119.0 5553.3 889.4 0.0 0.4 0.0 0.7 0 22 ssd11
413.1 119.0 5553.3 889.4 0.0 0.4 0.0 0.7 0 22 ssd11,g
5.2 34.1 1303.1 482.0 0.0 0.1 0.0 2.8 0 3 ssd12
0.0 0.0 0.0 0.0 0.0 0.0 0.0 10.9 0 0 ssd14
15.9 3.8 344.6 59.0 0.0 0.0 0.0 1.3 0 2 ssd15
15.9 3.8 344.6 59.0 0.0 0.0 0.0 1.3 0 2 ssd15,g
1.9 7.5 473.1 112.6 0.0 0.0 0.0 2.0 0 1 ssd16
1.9 7.5 473.1 112.6 0.0 0.0 0.0 2.0 0 1 ssd16,g
0.8 7.5 59.2 114.6 0.0 0.0 0.0 1.0 0 1 ssd18
0.8 7.5 59.2 114.6 0.0 0.0 0.0 1.0 0 1 ssd18,g
0.6 7.1 20.3 105.0 0.0 0.0 0.0 0.9 0 1 ssd19
0.6 7.1 20.3 105.0 0.0 0.0 0.0 0.9 0 1 ssd19,g
3.9 1.2 2926.1 628.9 0.0 0.0 0.0 7.9 0 3 ssd24
3.9 1.2 2926.1 628.9 0.0 0.0 0.0 7.9 0 3 ssd24,g
0.1 0.1 13.1 3.2 0.0 0.0 0.0 3.4 0 0 ssd33
0.1 0.1 13.1 3.2 0.0 0.0 0.0 3.4 0 0 ssd33,g
0.2 0.1 11.6 3.6 0.0 0.0 0.0 2.2 0 0 ssd34
0.2 0.1 11.6 3.6 0.0 0.0 0.0 2.2 0 0 ssd34,g
0.0 0.1 4.1 1.2 0.0 0.0 0.0 2.4 0 0 ssd35
0.0 0.1 4.1 1.2 0.0 0.0 0.0 2.4 0 0 ssd35
Una vez definido todos los puntos necesarios, podemos comenzar con la instalación de la nueva base de datos, para ello, lo único que debemos hacer es asignar nuestro nuevo ORACLE_SID y comenzar con la instalación de forma normal, puedes encontrar los pasos en Referencias, pero ... si estás aquí es que ya sabes Instalar Oracle sin Ayuda :D
Conclusión
Hemos visto que antes de ponernos manos a la obra debemos tener en cuenta varios factores y planificar la instalación de forma detallada para evitar que colapsemos la máquina, sin embargo, el uso de Solaris projects, nos permite modificar la parametrización para hacerla dinámica y ajustada a las necesidades reales.
Espero no haberos aburrido,
ya sabéis que ante cualquier duda, podéis contactar conmigo.
Referencias
No hay comentarios:
Publicar un comentario