Varias Bases de Datos en Oracle - Parte 2

Introducción

En la primera parte de Cómo Instalar varias bases de datos en un mismo motor, parece que llegamos a la conclusión de que con cuatro comandos y dos cosillas todo está hecho, ...., pues la verdad es que no.

Antes de dar el paso a "OnLine" hay que tener muy claro y definido todos aquellos puntos en los cuales podemos encontrar los problemas, y como en todas las puestas en producción de Sistemas, aquello que no esté totalmente planificado, no sólo fallará, sino que será con las peores consecuencias <leyes de Murphy>

Pasar de una arquitectura de una única base de datos por nodo a una configuración de varias, requiere el uso de gestores de recursos a nivel de Sistema Operativo, y por lo tanto, mayor control de las herramientas que Solaris nos ofrece. Pongamos un ejemplo sencillo, pasaremos del startup de Oracle a, primero asignar el resource, privilegios, etc para esa base de datos y posteriormente hacer el startup.

Dicho esto, vamos a ver como podemos verificar los recursos, rendimiento y dimensionado de nuestra máquina para definir un CheckList y de esta forma minimizar los errores del paso a producción.

Nº Usuarios, Conexiones Dedicated, Shared, Acceso WAN, LAN

Debemos tener en cuenta cuántos usuarios tenemos, las formas de acceso y nuestro soporte, es decir, Acceso LAN o WAN.

Para ello, empezaremos contestando a las siguientes preguntas:

• Cuántos usuarios tengo con la DB de media?
• Cuántos Usuarios tengo con Carga Máxima?
• Cuándo son los picos máximos y mínimos de carga?

Cómo los medimos?

SQL> select count(1) from v$session;

Memoria, Ethernet y CPU

Debemos tener en cuenta que cuando consolidemos varias Oracles de diferentes máquinas en una única, los requisitos de Memoria, Ethernet y CPU serán más de la suma de ambas bases de datos. Por ello, debemos tener repuesta a las siguientes preguntas:

• Cuanta memoria consume cada Base de Datos?
• Cuanta memoria consumen las sesiones?
• Cómo se distribuye la carga de CPU?

Cómo lo medimos?

Cada session consume entorno a 5Mb, por lo tanto podemos utilizar

SQL> show parameter sga;
SQL> show sga;
SQL> select 5*1024*count(1) as SESSION_SIZE from v$session;

Para la carga de CPU utilizaremos los comandos mpstat y prstat

HBA e incremento de IO

Será en esta parte donde tendremos los mayores problemas. Cuando las base de datos se encuentran separadas, cada una puede "campar a sus anchas", pero al consolidar los recursos de la máquina se comparte y por ello, debemos tener mucho cuidado con el incremento de IO, debiendo responder a las siguientes preguntas:

• Están correctamente segmentados los TableSpace?
• Está la instalación definida sobre OFA?
• Están las LUNs esparcidas por la SAN?

Cómo lo medimos?

Podemos obtener la ubicación de nuestros DataFile y analizar si debemos mover algunos a otra LUN accesibe desde otra HBA, si nuestros n datafile más leidos están en la misma LUN tendremos un problema de IO, seguro.

SQL> select name from v$datafile;
SQL> desc DBA_HIST_FILESTATXS;
SQL> select filename as DataFile, phyrds as PhysicalReads from dba_hist_filestatxs;

Para el acceso a disco y latencia utilizaremos iostat y nos fijaremos en los valores de asvc_t y %b. Un valor de asvc_t > 8 significa que ese disco es lento.

Jobs de Oracle

Antes cada una de las Bases de datos, tenía su propio espacio de tiempo, ahora esta compartido, es decir, ahora las 24h deberán ser para todas las bases de datos y deberemos evitar que varios JOBs se lancen simultáneamente para evitar un colapso de IO y CPU

SQL> select job,last_date,interval,what from dba_jobs;

AWR, OSW y Herramientas de diagnóstico de Oracle

Es muy importante utilizar las herramientas de diagnóstico de Oracle para ver qué está sucediendo y qué partes de nuestro core SQL podemos optimizar.

• Hemos hecho Tuning del SQL
• Cuántos count(*) hay por el código?
• Tenemos muchos Access Full?

Cómo lo hacemos?

Llegados a este punto, debemos utilizar AWR para obtener los resultados de rendimiento de nuestra Oracle en los puntos de uso de CPU, Usuarios, etc. para corregir los problemas que podamos ir observando. Nos es recomendable hacer reports de más de 1h de diferencia, ya que los picos se pueden difuminar.

SQL> @?/rdbms/admin/addmrpt.sql
SQL> @?/rdbms/admin/awrrpt.sql

Parametrización Oracle

Al consolidar, no podemos usar ResourceLimit ya que el planificador de Oracle no es capáz de ponerse en contacto con el del sistema <de momento> y por lo tanto, no puede optimizar los recursos. Oracle recomienda que si se está utilizando Gestión de Recursos a Nivel de Sistema Operativo, se desactive el de Oracle, ya que las consecuencias son impredecibles.

Además cuidado con el parámetro cursor_sharing='FORCE' ya que nos puede dar más de un susto, xD

Plan de Backup

Nuestros planes de backup va a suponer un punto muy importante en nuestro impacto de rendimiento. Lo más importante es saber que desde la versión 9i RMAN ya es "utilizable" y debe ser nuestra solución, lo demás, debemos ir poniendolo a EOL

Cómo lo hacemos?

RMAN> show all;
RMAN> configure backup optimization on;
RMAN> configure controlfile autobackup on;

Asignación de Límites de Recursos

Qué tipo de Resource Limits quiero asignar, memoria, cpu, IO. En nuestro sistema vamos a utilizar FSS y la propiedad cpu-shares para limitar el porcentaje de CPU que vamos a asignar, sin embargo, existen muchas otras opciones que podemos incluir, como por ejemplo, tiempo de CPU, Nº de Threads, ..., en nuestro caso el Nº Threads no será necesario.

Puede que tengamos nuestro sistema configurado con una precisión perfecta, pero debemos verificar el correcto funcionamiento, y poder ir adaptando nuestra configuración a los requisitos de nuestro core. Para ello, utilizaremos projmod, newtask -p <project> para hacer los cambios necesarios.

Cómo lo hacemos?

Debemos tener en cuenta que el mayor impacto en el rendimiento está establecido por los cambios de contexto involuntarios icsw del comando mpstat. Si tenemos un valor superior a 1000 debemos evaluar introducir más CPU o crear un PSET para limitar el máximo de cambios de contextos, también podemos utilizar los comando pbind para unir procesos a procesadores y así evitar los cambios de contexto.

No Saturar la vt102
En física cuántica, el mero hecho de observar supone alterar el sistema, .... pues en Solaris tambíen! No debemos estar con 100+1 terminales con prstat, mpstat, iostat, ... ya que ésto hará que las métricas varien y lo más importante, nuestra máquina se verá resentida....

Y entonces, cómo puedo obtener las métricas? Lo mejor es utilizar la herramienta OSWatch de Oracle que nos proporciona todas las métricas y además, nos permite hacer gráficas y ver el rendimiento de nuestra máquina. OSWatcher puedes descargarlo de Metalink ID 301137.1 pero para el rendimiento de Solaris en general, la herramienta que debemos utilizar es Solaris SE ToolKit

Conclusión

Aunque los preparativos sean comunes a todos, análisis de métricas, consumos y rendimientos la parametrización de Oracle y los recursos del Sistema son totalmente dependientes, es decir, los valores que a mí me funcionan, puede que no te sirvan para nada a ti, por ello, el tuning es una mezcla de arte y prueba-error.

En la siguiente entrega veremos cómo trabajar con varias bases de datos y cómo desenvolverse en este tipo de entornos, hasta entonces ... toca esperar.

Referencias

• Instalar Oracle 10g2 en Solaris 10 - Parte 1
• Instalar Oracle 10g2 en Solaris 10 - Parte 2
• Instalar Oracle 10g2 en Solaris 10 - Parte 3
• Instalar Oracle 10g2 en Solaris 10 - Parte 4
• Cómo cambiar el planificador por defecto de Solaris
• Activar Oracle Dynamic Intimated Shared Memory
• Instalar Varias DB en Solaris 10
• Configurar PSET en Solaris 10
• Solaris SE Toolkit
• Oracle OSWatcher Guide