# Entendiendo la arquitectura

¿Porque es importante entender la **arquitectura** de una Base de datos Oracle?

Si quieres dominar un tema, antes de aprender comandos debes entender como funciona internamente, eso si quieres ser un **Buen DBA** y no uno mas.

Este tema lo abordaremos con la última versión de la bd Oracle disponible a este momento *26ai*, sin embargo también indicare si aplica para las versiones 11g, 12c y 19c dado que son versiones que aún tienen algunos en producción.

Esta es la arquitectura general: Fuente Oracle

![](https://cdn.hashnode.com/uploads/covers/6a1ba5f97c924da4619cfa34/253a3288-2d15-4290-89be-9a02ecb3f5ed.png align="center")

Para hacerlo simple una instancia Oracle se compone de estructuras de memoria y procesos, no todas las estructuras de memorias y los procesos se encontraran en todas las instancias, esto va a depender de los parámetros configurados y los features implementados.

Y que es eso? Pues los procesos los podemos ver mediante comandos de sistema operativo:

ps -ef | grep oracle

![](https://cdn.hashnode.com/uploads/covers/6a1ba5f97c924da4619cfa34/c24ce10b-7453-4408-b447-47bf5cb85585.png align="center")

Hay distintos procesos algunos son mandatorios y otros opcionales, por ejemplo un proceso mandatorio es el smon.

**Tip:** Si desea saber si una BD esta activa, podría hacerlo validando que ese proceso exista:

ps -ef | grep smon

![](https://cdn.hashnode.com/uploads/covers/6a1ba5f97c924da4619cfa34/818ae3f8-9698-4192-8491-620cbeccdafa.png align="center")

**Tip:** Basado en ese mismo principio si killeo ese proceso la BD cae:

kill -9 19346

Y entonces que es la memoria?

Pues la memoria en Oracle la podemos dividir en 2 grandes bloques:

**SGA** — memoria compartida por toda la instancia. Los componentes clave son el Shared Pool (guarda SQL ya parseado y el diccionario de datos), el Buffer Cache (bloques de datos leídos del disco), el Redo Log Buffer (cambios en tránsito antes de escribirse al redo log), y el Large Pool (para RMAN, paralelismo, sesiones MTS).

**PGA** — memoria privada por cada proceso servidor. Ahí viven el área de sort, hash joins y las variables de sesión. No se comparte.

Y como se ve eso en una Base de datos...

![](https://cdn.hashnode.com/uploads/covers/6a1ba5f97c924da4619cfa34/a1c75cd7-cecb-49ec-9799-d66dddea4a11.png align="center")

![](https://cdn.hashnode.com/uploads/covers/6a1ba5f97c924da4619cfa34/cc3162b3-5a2b-4092-9c23-29568cc8d4f2.png align="center")

Y como se llega a eso valores? pues lo que te puedo decir por ahora es que se configuran a nivel de parámetros de base de datos y va a depender de la cantidad de memoria física del servidor y del workload de la base datos.

El buen dimensionamiento de la memoria es una actividad clave que se debe realizar para optimizar la base de datos...

**Conclusion:** Para gestionar adecuadamente una base de datos se debe conocer su arquitectura y funcionamiento.

Próximos pasos: Conoceremos como customizar nuestra base de datos.