Entendiendo Como Oracle Arranca

En este artículo vamos a tratar de explicar de una manera muy sencilla como intervienen los procesos de una instancia de Oracle cuando esta es iniciada.

Primero hay que diferenciar dos cosas: Una instancia no se abre ni se cierra; una instancia se inicia o se detiene. Por otro lado, la base de datos se monta y abre, o se desmonta y se cierra. Entendido este aspecto básico vamos a explicar como se arranca la base de datos y los procesos que intervienen.Existen 4 estados en los que la base puede estar en cualquier momento: SHUTDOWN, NOMOUNT, MOUNT y OPEN.

• Cuando la base está en modo SHUTDOWN todos los archivos están cerrados y no existe instancia en memoria, es decir no hay instancia ni tampoco está abierta la base de datos.
• Del estado SHUTDOWN la base pasa al estado NOMOUNT. En este estado la instancia es construida en memoria mediante la lectura del Parameter File. La lectura del Parameter File se la realiza en el siguiente orden: primero intenta leer el archivo dinámico SPFILE.ora, si no lo encuentra continúa con el SPFILE.ora y si no lo encuentra continúa con el archivo estático INIT.ora. (Estos archivos están en el directorio %ORACLE_HOME%\DATABASE\). En este estado Se crea la SGA y se inician los background processes, pero no se establece una conexión con la base de datos.
• Del estado NOMOUNT la base pasa al estado MOUNT, mediante la lectura del Control File (En caso de tener algunos Control Files Multiplexados, se localizan y verifica que ninguna copia esté perdida y que todas sean iguales) de acuerdo a las especificaciones del Parameter File. . En este estado la base de datos es asociada a la instancia iniciada. Cuando el Control File es leído se obtiene los nombres y el status de de los Datafiles y de los Online Redo Log Files (Pero no se verifica su existencia)
• Del estado MOUNT la base pasa al estado OPEN. En este estado se abre los Datafiles y los Online Redo Log Files (Oracle se asegura de tenerlos sincronizados; si no están sincronizados, la base permanece en estado Mount). Una vez abiertos estos archivos es posible establecer sesiones de usuario. En caso de que se encuentre algún error, el proceso SMON inicia Instance Recovery.
  

Arquitectura de Oracle

Este artículo mostrará brevemente como es la arquitectura de un servidor Oracle.
Un servidor Oracle consiste de dos entidades: La instancia y la base de datos (independientes pero conectados). Durante el proceso de creación de una base de datos, se crea primero la instancia, y de ahí se crea la base de datos.

Una instancia de Oracle consta tiene estructuras de memoria estructuras de memoria y procesos; su existencia es pasajera ya que se halla en la RAM y el CPU, es decir, el tiempo de vida de la instancia durará mientras exista en memoria. Por otro lado, la base de datos consta de archivos físicos localizados en el disco duro, y una vez creada existirá indefinidamente (hasta que deliberadamente los archivos sean eliminados). Oracle define esta arquitectura para garantizar una abstracción e independencia entre las estructuras lógicas (que ven los programadores) de las estructuras físicas (que ven los administradores de sistemas); únicamente el DBA conoce las dos partes de la historia.

Instancia:
La instancia de Oracle consta de un área de memoria compartida conocida como SGA (System Global Area). Esta área de memoria consta de menos tres estructuras básicas:

• Shared Pool: Incluye la Library Cache (área de memoria que almacena código recientemente ejecutado) y el Data Dictionary Cache (área que almacena las definiciones de objetos usados recientemente)
• Database Buffer Cache: Área de trabajo para la ejecución de SQL
• Log Buffer: Área que almacena todos los cambios que son realizados en el Database Buffer Cache

A parte de estas tres estructuras principales, también existen otras 3 que son opcionales:

• Large Pool: Área utilizada para mejorar el rendimiento en servidores compartidos (multithreaded) o para procesos I/O de disco y cinta
• Java Pool: Área utilizada si se tiene una aplicación que va a ejecutar procedimientos Java (ya que Oracle maneja sus APIs con Java muchos administradores consideran a esta área de memoria como obligatoria)
• Streams Pool: Utilizado para manejo de Streams

A parte del SGA, la instancia de Oracle tiene 5 procesos conocidos como Background process:

• SMON: Habilita la conexión entre la instancia y la base de datos. Permite la recuperación de la base de datos después de una falla
• PMON: Se encarga de gestionar las sesiones de usuario. Cuando un proceso de usuario falla, se encarga de limpiar los procesos restantes
• CKPT: Se asegura que la instancia esté sincronizada con la base de datos.
• LGWR: Escribe todos los cambios a los datos que se realizaron en el Database Buffer Cache en los Redo Log Files del disco
• DBWn: Escribe los bloques modificados desde el Database Buffer Cache a los archivos de disco

Base de datos:

La base de datos abarca las estructuras físicas que se encuentran en disco. Estos archivos se dividen en dos: Requeridos y Externos.
Entre los archivos requeridos están:

• Control File: Almacena el status de las estructuras físicas de la base de datos.
• Online Redo Log Files: Almacenan un registro de los cambios realizados a la base de datos mientras estos de van dando
• Datafiles: Son el repositorio de la información

En cambio, los archivos externos son:

• Parameter File: Define la instancia y los parámetros de inicialización. Hay de dos tipos Dinámico (binario, que no se puede ejecutar y se actualiza constantemente) y estático (que se lo puede editar mediante un editor ASCII y que solamente es leído una sola vez cuando la instancia se inicia.)
• Password File: Archivo de sistema que almacena los nombres de usuario y contraseña (encriptadas) para poder autenticar a un usuario sin la necesidad del diccionario de datos.
• Archive Log Files: Copias de los Online Redo Log Files llenos.

NAS y SAN

Muchos profesionales en el área de TI tienen que administrar sus centros de datos (Data Centers); entre las muchas actividades que tiene que realizar es el manejo y control de los datos de una red, específicamente: Almacenamiento. Existen hoy en día muchas tecnologías que facilitan el manejo de la información en lo que respecta a almacenamiento, pero que solución realmente debe ser la mejor? En este artículo nos vamos a enfocar en las estrategias de uso de NAS y SAN para manejo de Data Centers.

Primero definamos brevemente lo que es cada una de estas tecnologías:
NAS (Network Attached Storage) es un sistema de almacenamiento de archivos a través de una red local, que consta de uno o más dispositivos (conocidos como servidores de archivos o file servers) que manejan sistemas operativos que proporcionen ciertas funcionalidades específcias de almacenamiento de datos, acceso a disco por protocolos TCP/IP, así como una interfaz de gestión. Por otro lado, SAN (Storage Area Network) abarca toda una infraestructura de red dedicada únicamente al transporte de información para su almacenamiento mediante un canal de fibra o iSCSI independiente de la red de área local, permitiendo tener dispositivos de almacenamiento compartidos entre todos los servidores de la red como recursos individuales.

Ahora definido esto, analicemos cuales son las diferencias entre una y otra para ver cual nos conviene en nuestra infraestructura:

• El factor más importante es la velocidad de transmisión, y por ende su medio de transmisión: SAN transmite mediante canal de fibra (Que puede llegar a velocidades de 1, 2 y 4 gbps, mientras que NAS usa redes TCP/IP (Ethernet, FDDI, ATM) (Cuya máxima velocidad es 1 gbps, con un rendimiento real entre 600 y 800 mbps).
• Otro factor a tener en cuenta es el protocolo que utilizan: SAN utiliza SCSI encapsulado o iSCSI mientras que NAS utiliza TCP/IP y NFS/CIFS/http.
• La identificación de datos se maneja diferente. SAN identifica el dato por número de bloque de disco, mientras que NAS identifica el dato por nombre de archivo y su respectivo meta data manteniendo durante la transmisión los parámetros de seguridad, autenticación de usuario y bloqueo de archivos
• Backups y mirrors se manejan de forma diferente. En una SAN se hace una copia bloque por bloque, mientras que en una NAS se manejan copias instantáneas de los archivos (para ahorrar el consumo de ancho de banda)

Ahora que conocemos esto, debemos analizar nuestra infraestructura de red y de aplicaciones. A continuación podemos definir que estrategia utilizar basados en los diferentes tipos de usos:

NAS trabaja mejor con

• File serving
• File Sharing
• User’s home directories
• Meta data directories
• Repositorios de email (.pst files)
• Grid Computing
• P2P Data sharing
• Cualquier aplicación que requiera balance de carga, tolerancia a fallos y servidor web

SAN trabaja mejor con:

• Bases de datos
• Server Clustering
• Aplicaciones de mensajería
• Replicación de datos
• Data Warehousing
• Recuperación de archivos
• Replicación de datos
• Cualquier aplicación que necesite baja latencia y alto ancho de banda para transmisión de datos

Algo que hay que tener en cuenta es la velocidad. Actualmente se podría decir que SAN es mejor porque transmite a 4 gbps, pero en un futuro muy cercano tendremos la nueva versión de Ethernet (actualmente en Beta) que transmitirá a 10 gbps. Habrá que ver si se vuelve un estándar y ver que estrategia mismo es la que más nos conviene en nuestro negocio