lunes, 19 de marzo de 2012

¿Qué es un PGA de Oracle?


Las siglas provienen de Program/Private Global Area, y es la memoria privada de cada proceso servidor. En esta memoria cada proceso almacena información que sólo es necesaria para su propio funcionamiento como por ejemplo sus variables globales, el estado actual de cada cursor (SQL) que se ejecuta… etc.
La PGA se compone de:
  • Área SQL privada: cada SQL que se ejecuta necesita de este espacio para poder llevar el control de las operaciones propias de la sentencia. Se asigna cuando se abre el cursor y se libera completamente cuando se cierra. Esta parte de memoria se subdivide en dos:
    • a) area persistente: perdura durante toda la vida del cursor. Guarda las bind variables además de otras cosas.
    • b) area en tiempo de ejecución: se libera cuando finaliza la ejecución de la sentencia SQL (aunque no se haya cerrado el cursor ).
  • Memoria de las sesiones: guarda información relativa a la sesión como el login, variables de sesión… etc. En servidores compartidos (shared servers) este área pasa a ser pública ya que diferentes usuarios comparten los mismos procesos servidores.


  • Un PGA es un área de memoria no compartida en la que puede escribir un proceso.
  • Para cada proceso del servidor se asigna un PGA.
    • Ese PGA es exclusivo para ese proceso
    • Ese PGA se lee y se escribe por Oracle, que actúa en nombre de ese proceso.
  •  Un PGA, pues, es asignado por Oracle cuando un usuario se conecta a una base de datos y crea una sesión.
  • Un PGA siempre contiene un espacio que contiene las variables de la sesión, y alguna otra información. Este espacio es denominado stack space.
  • El tamaño de un PGA depende del sistema operativo específico.
¿Dónde se almacena la PGA?
La PGA se almacena en la memoria del servidor pero fuera de la SGA. Por tanto, para dimensionar ambas áreas hay que tener en cuenta que la suma de las dos no supere los límites específicos del servidor y la plataforma (tamaño máximo memoria RAM, 2 GB en Windows sin /3GB, 3 GB en Windows con /3GB... etc.). 

¿El tamaño de la PGA es configurable?
Sí, pero únicamente es configurable el tamaño de las áreas de trabajo. Desde Oracle9i el DBA puede fijar el tamaño máximo del cónjunto de todas las PGAs de la Instancia a través del parámetro PGA_AGGREGATE_TARGET. De esta forma, Oracle dinámicamente gestiona el tamaño de cada área de trabajo para que la suma de todas las PGAs (no de todas las áreas, que es un parte de la PGA como ya se ha indicado) no exceda del límite impuesto. En versiones anteriores la forma de controlar el tamaño de cada área de trabajo era a través de los parámetros SORT_AREA_SIZE, HASH_AREA_SIZE, BITMAP_MERGE_AREA_SIZE y CREATE_BITMAP_AREA_SIZE.

Para que la Instancia tenga el cuenta el parámetro PGA_AGGREGATE_TARGET, el parámetro WORKAREA_SIZE_POLICY se debe asignar a AUTO (por omisión). Con MANUAL, se indica que se trabaja de la forma anterior y se fija cada parámetro *_AREA_SIZE por separado. 

¿Cuándo se crea la PGA?
La crea el Listener durante la creación del proceso servidor. Si esta memoria no puede ser asignada o reservada la creación del proceso servidor falla y el Listener devuelve un ORA-12500: TNS:listener failed to start a dedicated server process. Igualmente, si durante la ejecución de alguna sentencia es necesario incrementar el tamaño de la PGA y el sistema operativo no tiene más memoria para darle se devuelve un error indicándolo. 

¿Cuándo se destruye la PGA?
Al cerrar el proceso servidor su PGA asociada se libera y se devuelve al sistema operativo el espacio reservado. El proceso servidor se cierra cuando el usuario ejecuta EXIT o DISCONNECT, lanza un Ctrl+C, se pierde la comunicación con el servidor, se produce un ORA-600 que desconecta la sesión, el DBA lanza un KILL SESSION, etc.

¿Cuánto ocupa cada PGA?
En cada versión de Oracle, e incluso en cada release, el tamaño mínimo cambia. No obstante, como el tamaño es cambiante en función del área de trabajo, lo mejor que se puede hacer para comprobar cuánto ocupa o cómo ocupa es monitorizarlas.

¿Cómo se monitoriza la PGA?
Hay diferentes vistas para saber cuánto ocupa cada PGA individual o para saber cuánto ocupan todas las PGAs o incluso para saber si está bien configurado el parámetro PGA_AGGREGGATE_TARGET. 

¿Qué es un SGA de Oracle?

Arquitectura de ORACLE

La arquitectura de ORACLE tiene tres componentes basicos: la estructuras de memoria para almacenar los datos y el codigo ejecutable, los procesos que corren el sistema de bases de datos y las tareas de cada usuario conectado a la base de datos y los archivos que sirven para el almacenamiento fisico, en disco, de la informacion de la base de datos.








SGA (Área Global del Sistema) es una estructura básica de memoria de Oracle que sirve para facilitar la transferencia de información entre usuarios y también almacena la información estructural de la BD más frecuentemente requerida.
El área global del sistema y un conjunto de procesos de la base de datos constituyen una instancia de una base de datos Oracle. La base de datos Oracle automáticamente reserva memoria para el área global del sistema cuando se inicia una instancia, y el sistema operativo reclama la memoria cuando se apaga dicha instancia. Cada instancia tiene su propia SGA.

¿Que contiene el SGA?
Memoria Oracle (SGA) Su tamaño está determinado por los parámetros:
    • Shared_Pool_Size= Tamaño en bytes del área para SQL compartidos y sentencias PL/SQL.
    • Db_Block_Size = Tamaño en bytes de un solo bloque de datos.
    • Db_Block_Buffers = Numero de Buffers a localizar en memoria.
    • Log_Buffer = Numero de bytes localizados para los Redo Log Buffer.


La SGA se divide en varias partes:

Buffers de BD, Database Buffer Cache
    Es el caché que almacena los bloques de datos leidos de los segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el parámetro DB_BLOCK_BUFFERS del fichero init.ora.
    Como el tamaño del buffer suele ser pequeño para almacenar todos los bloques de datos leidos, su gestión se hace mediante el algoritmo LRU.



Buffer Redo Log
    Los registros Redo describen los cámbios realizados en la BD y son escritos en los ficheros redo log para que puedan ser utilizados en las operaciones de recuperación hacia adelante, roll-forward, durante las recuperaciones de la BD. Pero antes de ser escritos en los ficheros redo log son escritos en un caché de la SGA llamado redo log buffer. El servidor escribe periódicamente los registrosredo log en los ficheros redo log.
    El tamaño del buffer redo log se fija por el parámetro LOG_BUFFER.

Área de SQL Compartido, Shared SQL Pool
    En esta zona se encuentran las sentencias SQL que han sido analizadas. El analisis sintáctico de las sentencias SQL lleva su tiempo y Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente igual en la zona de SQL compartido. Si es así, no la analiza y pasa directamente a ejecutar la que mantinene en memoria. De esta manera se premia la uniformidad en la programación de las aplicaciones. La igualdad se entiende que es lexicografica, espacios en blanco y variables incluidas. El contenido de la zona de SQL compartido es:
    • Plan de ejecución de la sentencia SQL.
    • Texto de la sentencia.
    • Lista de objetos referenciados.
    Los pasos de procesamiento de cada petición de análisis de una sentencia SQL son:
    • Comprobar si la sentencia se encuentra en el área compartida.
    • Comprobar si los objetos referenciados son los mismos.
    • Comprobar si el usuario tiene acceso a los objetos referenciados.
    Si no, la sentencia es nueva, se analiza y los datos de análisis se almacenan en la zona de SQL compartida.
    También se almacena en la zona de SQL compartido el caché del diccionario. La información sobre los objetos de la BD se encuentra almacenada en las tablas del diccionario. Cuando esta información se necesita, se leen las tablas del diccionario y su información se guarda en el caché del diccionario de la SGA.
    Este caché también se administra mediante el algoritmo LRU. El tamaño del caché está gestionado internamente por el servidor, pero es parte del shared pool, cuyo manaño viene determinado por el parámetro SHARED_POOL_SIZE.

Procesos que acceden al SGA

Procesos de primer plano
  • Verificación de permisos de usuario
  • Elaboración del plan de ejecución para las sentencias
  • Recuperación de datos de la caché
  • Recuperación en caso de fallos
  • Bloqueos


Procesos de Segundo plano

A diferencia de los procesos de primer plano, los procesos de Segundo plano viven desde que la base de datos se inicia hasta que ésta es apagada.

Procesos de segundo plano
  • Database Writer
  • Log Writer
  • Archiver
  • Procesos de Checkpoint


System Monitor, SMON
    El SMON es el supervisor del sistema y se encarga de todas las recuperaciones que sean necesarias durante el arranque. Esto puede ser necesario si la BD se paró inesperadamente por fallo físico, lógico u otras causas. Este proceso realiza la recuperación de la instancia de BD a partir de los ficheros redo log. Además límpia los segmentos temporales no utilizados y compacta los huecos libres contiguos en los ficheros de datos. Este proceso se despierta regularmente para comprobar si debe intervenir.
Process Monitor, PMON
    Este proceso restaura las transacciones no validadas de los procesos de usuario que abortan, liberando los bloqueos y los recursos de la SGA. Asume la identidad del usuario que ha fallado, liberando todos los recursos de la BD que estuviera utilizando, y anula la transacción cancelada. Este proceso se despierta regularmente para comprobar si su intervención es necesaria.
Database Writer, DBWR
    El proceso DBWR es el responsable de gestionar el contenido de los buffers de datos y del caché del diccionario. Él lee los bloques de los ficheros de datos y los almacena en la SGA. Luego escribe en los ficheros de datos los bloques cuyo contenido ha variado. La escritura de los bloques a disco es diferida buscando mejorar la eficiencia de la E/S.
    Es el único proceso que puede escribir en la BD. Esto asegura la integridad. Se encarga de escribir los bloques de datos modificados por las transacciones, tomando la información del buffer de la BD cuando se valida una transacción. Cada validación no se lleva a la BD física de manera inmediata sino que los bloques de la BD modificados se vuelcan a los ficheros de datos periodicamente o cuando sucede algún checkpoint o punto de sincronizaión: grabación diferida:
    • Los bloques del buffer de la BD (bloques del segmento de rollback y bloques de datos) menos recientemente utilizados son volcados en el disco continuamente para dejar sitio a los nuevos bloques.
    • El bloque del segmento de rollback se escribe SIEMPRE antes que el correspondiente bloque de datos.
    • Múltiples transacciones pueden solapar los cambios en un sólo bloque antes de escribirlo en el disco.
    Mientras, para que se mantenga la integridad y coherencia de la BD, todas las operaciones se guardan en los ficheros de redo log. El proceso de escritura es asíncrono y puede realizar grabaciones multibloque para aumentar la velocidad.
Log Writer, LGWR
    El proceso LGWR es el encargado de escribir los registros redo log en los ficheros redo log. Los registros redo log siempre contienen el estado más reciente de la BD, ya que puede que el DBWR deba esperar para escribir los bloques modificados desde el buffer de datos a los ficheros de datos.
    Conviene tener en cuenta que el LGWR es el único proceso que escribe en los ficheros de redo log y el único que lee directamente los buffers de redo log durante el funcionamiento normal de la BD.
    Coloca la información de los redo log buffers en los ficheros de redo log. Los redo log buffers almacenan una copia de las transacciones que se llevan a cabo en la BD. Esto se produce:
    • a cada validación de transacción, y antes de que se comunique al proceso que todo ha ido bien,
    • cuando se llena el grupo de buffers de redo log
    • cuando el DBWR escribe buffers de datos modificados en disco.
    Así, aunque los ficheros de DB no se actualicen en ese instante con los buffers de BD, la operación queda guardada y se puede reproducir. Oracle no tiene que consumir sus recursos escribiendo el resultado de las modificaciones de los datos en los archivos de datos de manera inmediata. Esto se hace porque los registros de redo log casi siempre tendrán un tamaño menor que los bloques afectados por las modificaciones de una transacción, y por lo tanto el tiempo que emplea en guardarlos es menor que el que emplearía en almacenar los bloques sucios resultado de una transacción; que ya serán trasladados a los ficheros por el DBWR. El LGWR es un proceso único, para asegurar la integridad. Es asíncrono. Además permite las grabaciones multibloque.
Checkpoint, CKPT
    Este proceso escribe en los ficheros de control los checkpoints. Estos puntos de sincronización son referencias al estado coherente de todos los ficheros de la BD en un instante determinado, en un punto de sincronización. Esto significa que los bloques sucios de la BD se vuelcan a los ficheros de BD, asegurándose de que todos los bloques de datos modificados desde el último checkpoint se escriben realmente en los ficheros de datos y no sólo en los ficheros redo log; y que los ficheros de redo log también almacenan los registros de redo log hasta este instante. La secuencia de puntos de control se almacena en los ficheros de datos, redo log y control. Los checkpoints se produce cuando:
    • un espacio de tabla se pone inactivo, offline,
    • se llena el fichero de redo log activo,
    • se para la BD,
    • el número de bloques escritos en el redo log desde el último checkpoint alcanza el límite definido en el parámetro LOG_CHECKPOINT_INTERVAL,
    • cuando transcurra el número de segundos indicado por el parámetro LOG_CHECKPOINT_TIMEOUT desde el último checkpoint.
    Está activo si el parámetro CHECKPOINT_PROCESS tiene un valor verdadero.
Archiver, ARCH
    El proceso archivador tiene que ver con los ficheros redo log. Por defecto, estos ficheros se reutilizan de manera cíclica de modo que se van perdiendo los registros redo log que tienen una cierta antiguedad. Cuando la BD se ejecuta en modo ARCHIVELOG, antes de reutilizar un fichero redo log realiza una copia del mismo. De esta manera se mantiene una copia de todos los registros redo logpor si fueran necesarios para una recuperación. Este es el trabajo del proceso archivador.

Recoverer, RECO

    El proceso de recuperación está asociado al servidor distribuido. En un servidor distribuido los datos se encuentran repartidos en varias localizaciones físicas, y estas se han de mantener sincronizadas. Cuando una transacción distribuida se lleva a cabo puede que problemas en la red de comunicación haga que una de las localizaciones no aplique las modificaciones debidas. Esta transacción dudosadebe ser resuelta de algún modo, y esa es la tarea del proceso recuperador. Está activo si el parámetro DISTRIBUTED_TRANSACTIONS tiene un valor distinto de 0.

Lock, LCK

    El proceso de bloqueo está asociado al servidor en paralelo.
Procesos del Usuario


Cuando un usuario se conecta a la base de datos, se crea un proceso de usuario que se encarga de ejecutar el codigo de aplicacion y manejar el perfil del usuario con sus variables de ambiente. Los procesos de usuario no se pueden comunicar directamente con la base de datos, unicamente lo hacen a traves de procesos servidores.

Procesos Servidores

Ejecutan las ordenes SQL de los usuarios y llevan los datos al "database buffer cache", para que los procesos del usuario puedan tener acceso a los datos. Se pueden tener distintas arquitecturas para trabajar en ORACLE, segun los tipos de servidores: dedicados o multihilos.


¿Cuáles son los roles de un DBA?

el DBA, es un profesional en el procesamiento de datos. La tarea del DBA es crear la base de datos en sí y poner en vigor los controles tecnicos necesarios para apoyar las politicas dictadas por el administrador de datos. El DBA se encarga tambien de garantizar el funcionamiento adecuado del sistema y de proporcionar otros servicios de indole tecnica relacionados. El DBA cuenta por lo regular con un grupo de programadores de sistemas y otros asistentes tecnicos.
La responsabildiad general del DBA es facilitar el desarrollo y el uso de la Base de Datos dentro de las guias de accion definidas por la administracion de los datos

    • Administrar la estructura de la Base de Datos
    • Administrar la actividad de los datos
    • Administrar el Sistema Manejador de Base de Datos
    • Establecer el Diccionario de Datos
    • Asegurar la confiabilidad de la Base de Datos
    • Confirmar la seguridad de la Base de Datos
  • Administración de la estructura de la Base de Datos
  • La administración de la estructura de la Base de Datos incluye participar en el diseño inicial de la misma y su puesta en practica así como controlar, y administrar sus requerimientos, ayudando a evaluar alternativas, incluyendo los DBMS a utilizar y ayudando en el diseño general de BD. En los casos de grandes aplicaciones de tipo organizacional, el DBA es un gerente que supervisa el trabajo del personal de diseño de la BD.
    Una vez diseñada la BD, es puesta en practica utilizando productos del DBMS, procediéndose entonces a la creación de los datos (captura inicial). El DBA participa en el desarrollo de procedimientos y controles para asegurar la calidad y la alta integridad de la BD.
    Los requerimientos de los usuarios van modificándose, estos encuentran nuevas formas o métodos para lograr sus objetivos; la tecnología de la BD se va modificando y los fabricantes del DBMS actualizan sus productos. Todas las modificaciones en las estructuras o procedimientos de BD requieren de una cuidadosa administración.
     
    • Implicaciones por la modificación de los esquemas
    Las solicitudes de modificación son inevitables una vez que el sistema ha entrado en operación, pueden aparecer solicitudes de nuevos requerimientos o estos pueden resultar de una comprensión inadecuada de los mismos. En cualquier caso, deberán efectuarse modificaciones en relación con toda la comunidad de la BD, ya que el impacto de tales alteraciones será resentido por mas de una aplicación. En algunos casos, pueden darse modificaciones que presentan efectos negativos para algunos usuarios; estos casos deberán ser tratados esgrimiendo como argumento los beneficios globales que serán obtenidos de tales alteraciones.Una administración eficaz de la BD debe incluir procedimientos y políticas mediante las cuales los usuarios puedan registrar sus necesidades de modificaciones, y así la comunidad podrá analizar y discutir los impactos de dichas modificaciones, determinándose entonces la puesta o no en practica de tales alteraciones.En razón del tamaño y complejidad de una BD y de sus aplicaciones, las modificaciones pudieran tener resultados inesperados. El DBA debe estar preparado para reparar la BD y reunir suficiente información para diagnosticar y corregir el problema provocado por la falla. Después de un cambio la BD es más vulnerable a fallas. 

    • Documentación
    La responsabilidad final de un DBA en la administración de la estructura de una BD es la DOCUMENTACIÓN. Es de suma importancia saber que modificaciones han sido efectuadas, como fueron realizada y cuando fueron establecidas. Una modificación sobre la estructura de la BD pudiera ocasionar un error que no apareciera a corto plazo; una vez que este surja, sin la documentación adecuada sobre las modificaciones realizadas, él diagnostico resultaría extremadamente complicado. En estos casos, se haría necesario una secuencia de rejecuciones para intentar detectar el punto en conflicto; el riesgo de este procedimiento radica en que es posible afectar la información contenida en la BD. Para identificar un cambio es de suma importancia mantener un registro de los formatos de prueba y de las ejecuciones de las pruebas efectuadas. Si se utilizan procedimientos de prueba formatos de pruebas y métodos de registro estandarizados, el registro de los resultados de la prueba no consumirá tiempo excesivo.Comúnmente el tiempo de la documentación es tedioso y esto ocasiona que algunos DBA tienden a reducir o abreviar la información que se registra en ella e incluso llegan a desatenderla. Cuando ocurre un siniestro, la documentación completa y organizada puede ser la diferencia entre resolver o no un problema de extrema importancia y en la mayoría de los casos, que implica costos cuantiosos a la empresa.La tarea de la documentación es cada vez más ligera y precisa cuando se utilizan DBMS que integran herramientas CASE para las tareas de diseño, mantenimiento y documentación. Estas mismas herramientas CASE proporcionan en la, mayoría de los casos la facilidad de generar y mantener en forma automática el Diccionario de Datos.Una razón más para documentar consiste en la necesidad de mantener organizados datos históricos. Ocurre comúnmente que se desea realizar una consulta sobre los respaldos para conocer el estado que guardaba la información en un periodo determinado que transcurrió previamente. Los registros de modificación existentes en la documentación permitirá resolver problemas de incompatibilidad entre las estructuras que eran vigentes en el periodo de respaldo y las que lo son ahora; permitirá también el desarrollo de módulos de ajuste que faciliten la traducción de formatos y/o escalas para valores almacenados.En los casos de caídas del sistema se presenta una situación parecida; los respaldos son requeridos y habrá de verificarse su estructura; formato y escala para integrarlos a la operación del sistema.  
  • Administración de la actividad de datos

  • Aunque el DBA protege los datos, no los procesa. El DBA no es usuario del sistema, en consecuencia, no administra valores de datos; el DBA administra actividad de datos. Dado que la BD es un recurso compartido, el DBA debe proporcionar estándares, guías de acción, procedimientos de control y la documentación necesaria para garantizar que los usuarios trabajan en forma cooperativa y complementaria al procesar datos en la BD.
    Como es de suponerse, existe una gran actividad al interior de un DBMS. La concurrencia de múltiples usuarios requieren de estandarizar los procesos de operación; el DBA es responsable de tales especificaciones y de asegurarse que estas lleguen a quienes concierne. Todo el ámbito de la BD se rige por estándares, desde la forma como se capture la información (tipo, longitud, formato), como es procesada y presentada. El nivel de estandarización alcanza hasta los aspectos más internos de la BD; como sé accesa a un archivo, como se determinan los índices primarios y auxiliares, la foliación de los registros y demás.
    Debe procurarse siempre que los estándares que serán aplicados beneficien también a los usuarios, privilegiando siempre la optimización en la operación del DBMS y el apego de las políticas de la empresa.
    Una administración de BD efectiva deberá disponer siempre de este tipo de estándares; entre las funciones del DBA se encuentra la de revisarlos periódicamente para determinar su operatividad, y en su caso ajustarlos, ampliarlos o cancelarlos. Es también su responsabilidad el que estos se cumplan.
    Cuando se definen estándares sobre la estructura de la BD, estos deben registrarse en una sección del diccionario de datos a la que todos aquellos usuarios relacionados con ese tipo de proceso pueden acceder.
    Otro de los aspectos que el administrador debe atender es el de coordinar las nuevas propuestas para realizar ajustes en los derechos de acceso a datos compartidos y aplicaciones específicamente propuestas serían analizados en conjunto con los supervisores o directivos de las áreas involucradas para determinar si procede pudieran aparecer problemas cuando dos o más grupos de usuarios quedan autorizados para notificar los mismos datos. Uno de tales conflictos es el de la actualización perdida; este ocurre cuando el trabajo de un usuario queda sobrescrito sobre por el de un segundo usuario. El DBA queda responsabilizado para identificar la posible ocurrencia de dichos problemas así como de crear normas y procedimientos para su eliminación.
    Se obtendrán este tipo de garantías cuando el DBMS sea capaz de implementar las restricciones aplicables al acceso concurrente, y este sea utilizado adecuadamente por programadores y usuarios; para borrar lo anterior, se hace indispensable el apego a los estándares el seguimiento de instructivos y manuales y las reglas establecidas para los diversos procesamientos y procedimientos que se llevan acabo.
    Entre las alternativas mas utilizadas por el DBA para tratar de resolver o minimizar este problema se encuentran las siguientes:
        a) Restringir el acceso a los procedimientos para ciertos usuarios.
        b) Restringir al acceso a los datos para ciertos usuarios procedimientos y/o datos.
        c) Evitar la coincidencia de horarios para usuarios que comparten.
    Las técnicas de recuperación son otra función esencial del DBA al administrar la actividad de datos. A pesar de que el DBMS lleva a cabo una parte del proceso de recuperación, los usuarios determinan en forma critica la operatividad de esos sistemas de protección. El DBA debe anticipar fallas y definir procedimientos estándares de operación; los usuarios deben saber que hacer cuando el sistema este caído y que es lo primero que debe realizarse cuando el sistema este puesto en marcha nuevamente. El personal de operación deberá saber como iniciar el proceso de recuperación de la BD que copias de seguridad utilizar; como programar la rejecución del tiempo perdido y de las tareas pendientes; es importante también establecer un calendario para llevar a cabo estas actividades sin afectar a otros sistemas dentro de la organización que hagan uso de los mismos recursos de computo. Destacan por su importancia en el proceso de recuperación y a su vez en la atención que prestan a otros sectores de la organización. Los dispositivos de comunicación remota, los sistemas de interconexión y otros accesorios de uso compartido.
    El DBA es el responsable de la publicación y mantenimiento de la documentación en relación con la actividad de los datos, incluyendo los estándares de la BD, los derechos de recuperación y de acceso a la BD, los estándares para la recuperación de caídas y el cumplimiento de las políticas establecidas. Los productos DBMS más populares que se encuentran en el mercado proporcionan servicios de utilerias para ayudar al DBA en la administración de los datos y su actividad. Algunos sistemas registran en forma automática los nombres de los usuarios y de las aplicaciones a las que tienen acceso así como a otros objetos de la BD. Incorpora también utilerias que permitan definir en el diccionario de datos las restricciones para que determinadas aplicaciones o módulos de ellas solo tengan acceso a segmentos específicos de la BD.

    Administrar el Sistema Manejador de Base de Datos.
    Existe una gran actividad al interior de un DBMS. La concurrencia de múltiples usuarios requiere la estandarización de los procesos de operación; el DBA es responsable de éstas especificaciones y de asegurarse que estas lleguen a quienes concierne. Todo el ámbito de la base de datos se rige por estándares, desde la forma de como se captura la información (tipo de dato, longitud, formato), como es procesada y presentada. El nivel de estandarización alcanza hasta los aspectos más internos de la base de datos; como sé accesa a un archivo, como se determinan los índices primarios y auxiliares, registros, etc.
    El DBA debe procurar siempre que los estándares que serán aplicados beneficien también a los usuarios, privilegiando siempre la optimización en la operación del DBMS y el apego de las políticas de la empresa.  Entre las funciones del DBA se encuentra la de revisar los estándares periódicamente para determinar su operatividad, ajustarlos, ampliarlos o cancelarlos y hacer que éstos se cumplan.
    Establecer el Diccionario de Datos.
    Cuando se definen estándares sobre la estructura de la base de datos, se deben de registrarse en una sección del diccionario de datos a la que todos aquellos usuarios relacionados con ese tipo de proceso pueden acceder. Este metadato debe precisar información que nos indique con claridad el tipo de datos que serán utilizados, sus ámbitos de influencia y sus limitantes de seguridad.
    Asegurar la Confiabilidad de la Base de Datos
    Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea capaz de recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las herramientas necesarias para la reparación de los posibles errores que las bases de datos pueden sufrir, por ejemplo tras un corte inesperado de luz.
    Confirmar la Seguridad de la Base de Datos.
    Coordinar las nuevas propuestas para realizar ajustes en los derechos de acceso a datos compartidos y aplicaciones específicamente propuestas serían analizados en conjunto con los supervisores o directivos de las áreas involucradas para determinar si procede pudieran aparecer problemas cuando dos o más grupos de usuarios quedan autorizados para notificar los mismos datos. Uno de tales conflictos es el de la actualización perdida; este ocurre cuando el trabajo de un usuario queda sobrescrito sobre por el de un segundo usuario. El DBA queda responsabilizado para identificar la posible ocurrencia de dichos problemas así como de crear normas y procedimientos para su eliminación. Se obtendrán este tipo de garantías cuando el DBMS sea capaz de implementar las restricciones aplicables al acceso concurrente, y este sea utilizado adecuadamente por programadores y usuarios; para borrar lo anterior, se hace indispensable el apego a los estándares el seguimiento de instructivos y manuales y las reglas establecidas para los diversos procesamientos y procedimientos que se llevan acabo.
    Entre las alternativas mas utilizadas por el DBA para tratar de resolver o minimizar este problema se encuentran las siguientes:
    • Restringir el acceso a los procedimientos para ciertos usuarios.
    • Restringir al acceso a los datos para ciertos usuarios procedimientos y/o datos.
    • Evitar la coincidencia de horarios para usuarios que comparten.
    Las técnicas de recuperación son otra función esencial del DBA al administrar la actividad de datos. A pesar de que el DBMS lleva a cabo una parte del proceso de recuperación, los usuarios determinan en forma critica la operatividad de esos sistemas de protección. El DBA debe anticipar fallas y definir procedimientos estándares de operación; los usuarios deben saber que hacer cuando el sistema este caído y que es lo primero que debe realizarse cuando el sistema este puesto en marcha nuevamente. El personal de operación deberá saber como iniciar el proceso de recuperación de la BD que copias de seguridad utilizar; como programar la reejecución del tiempo perdido y de las tareas pendientes; es importante también establecer un calendario para llevar a cabo estas actividades sin afectar a otros sistemas dentro de la organización que hagan uso de los mismos recursos de computo. Destacan por su importancia en el proceso de recuperación y a su vez en la atención que prestan a otros sectores de la organización. Los dispositivos de comunicación remota, los sistemas de interconexión y otros accesorios de uso compartido.
    El DBA es el responsable de la publicación y mantenimiento de la documentación en relación con la actividad de los datos, incluyendo los estándares de la BD, los derechos de recuperación y de acceso a la BD, los estándares para la recuperación de caídas y el cumplimiento de las políticas establecidas. Los productos DBMS más populares que se encuentran en el mercado proporcionan servicios de utilerías para ayudar al DBA en la administración de los datos y su actividad. Algunos sistemas registran en forma automática los nombres de los usuarios y de las aplicaciones a las que tienen acceso así como a otros objetos de la BD. Incorpora también utilerías que permitan definir en el diccionario de datos las restricciones para que determinadas aplicaciones o módulos de ellas solo tengan acceso a segmentos específicos de la BD.

          Funciones del Administrador de Bases de Datos (DATE)

    • Definir el esquema conceptual: es tarea del administrador de datos decidir con exactitud cual es la información que debe mantenerse en la base de datos, es decir, identificar las entidades que interesan a la empresa y la información que debe registrarse acerca de esas entidades. Este proceso por lo general se denomina diseño lógico –a veces conceptual- de bases de datos. Cuando el administrador de datos decide el contenido de la base de datos en un nivel abstracto, el DBA crea a continuación el esquema conceptual correspondiente, empleando el DDL conceptual. El DBMS utilizará la versión objeto (compilada) de ese esquema para responder a las solicitudes de acceso. La versión fuente sin compilar servirá como documento de referencia para los usuarios del sistema.
    • Definir el esquema interno: el DBA debe decidir también como se representará la información en la base de datos almacenada. A este proceso suele llamársele diseño físico de la base de datos. Una vez hecho esto el DBA deberá crear la definición de estructura de almacenamiento correspondiente (es decir el esquema interno) valiéndose del DDL interno. Además deberá definir la correspondencia pertinente entre los esquemas interno y conceptual. En la práctica, ya sea el DDL conceptual o bien el DDL interno incluirán seguramente los medios para definir dicha correspondencia, pero las dos funciones (crear el esquema, definir la correspondencia) deberán poder separarse con nitidez. Al igual que el esquema conceptual, el esquema interno y la correspondencia asociada existirán tanto en la versión fuente como en la versión objeto.
    • Vincularse con los usuarios: el DBA debe encargarse de la comunicación con los usuarios, garantizar la disponibilidad de los datos que requieren y escribir - o ayudar a los usuarios a escribir- los esquemas externos necesarios, empleando el DDL externo aplicable. Además, será preciso definir la correspondencia entre cualquier esquema externo y el esquema conceptual. En la práctica, el DDL externo incluirá con toda probabilidad los medios para especificar dicha correspondencia, pero en este caso también el esquema y la correspondencia deberán poder separarse con claridad. Cada esquema externo y la correspondencia asociada existirán en ambas versiones fuentes y objeto. Otros aspectos de la función de enlace con los usuarios incluyen las consultas sobre diseño de aplicaciones, la impetración de instrucción técnica, la ayuda en la localización y resolución de problemas, y otros servicios profesionales similares relacionados con el sistema.
    • Definir las verificaciones de seguridad e integridad: las verificaciones de seguridad y de integridad pueden considerarse parte del esquema conceptual. El DDL conceptual incluirá los medios para especificar dichas verificaciones.
    • Definir procedimientos de respaldo y recuperación: cuando una empresa se decide a utilizar un sistema de base de datos, se vuelve dependiente en grado sumo del funcionamiento correcto de ese sistema. En caso de que sufra daño cualquier porción de la base de datos – por causa de un error humano, digamos, o una falla en el equipo o en el sistema que lo apoya – resulta esencial poder reparar los datos implicados con un mínimo de retraso y afectando lo menos posible el resto del sistema. En teoría, por ejemplo la disponibilidad de los datos no dañados no debería verse afectada. El DBA debe definir y poner en practica un plan de recuperación adecuado que incluya, por ejemplo una descarga o "vaciado" periódico de la base de datos en un medio de almacenamiento de respaldo, y procedimientos para cargar otra vez la base de datos a partir de vaciado más reciente cuando sea necesario.
    • Supervisar el desempeño y responder a cambios en los requerimientos: es responsabilidad del DBA organizar el sistema de modo que se obtenga el desempeño que sea "mejor para la empresa", y realizar los ajustes apropiados cuando cambien los requerimientos.
    Funciones del Administrador de Bases de Datos (KORTH)
    • Definición del esquema: el esquema original de la base de datos se crea escribiendo un conjunto de definiciones que son traducidas por el compilador de DDL a un conjunto de tablas que son almacenadas permanentemente en el DICCIONARIO DE DATOS.
    • Definición de la estructura de almacenamiento y del método de acceso: estructuras de almacenamiento y métodos de acceso adecuados se crean escribiendo un conjunto de definiciones que son traducidas por el compilador del lenguaje de almacenamiento y definición de datos.
    • Modificación del esquema y de la organización física: las modificaciones, tanto al esquema de la base de datos como a la descripción de la organización física de almacenamiento, aunque relativamente poco comunes, se logran escribiendo un conjunto de definiciones que son usadas bien por el compilador del DDL o bien por el compilador del lenguaje de almacenamiento y definición de datos para generar modificaciones a las tablas internas apropiadas del sistema (por ejemplo, el diccionario de datos).
    • Concesión de autorización para el acceso a los datos: la concesión de diferentes tipos de autorización permite al administrador de la base de datos regular qué partes de la base de datos van a poder ser accedidas por varios usuarios.
    • Especificación de las restricciones de integridad: las restricciones de integridad se mantienen en una estructura especial del sistema que consulta el gestor de la base de datos cada vez que tiene lugar una actualización en el sistema.

    Administración del DBMS
A demás de administrar la actividad de datos y la estructura de la BD, el DBA debe administrar el DBMS mismo. Deberá compilar y analizar estadísticas relativas al rendimiento del sistema e identificar áreas potenciales del problema. Dado que la BD esta sirviendo a muchos grupos de usuarios, el DBA requiere investigar todas las quejas sobre el tiempo de respuesta del sistema, la precisión de los datos y la facilidad de uso. Si se requieren cambios el DBA deberá planearlos y ponerlos en practica.El DBA deberá vigilar periódica y continuamente las actividades de los usuarios en la BD. Los productos DBMS incluyen tecnologías que reúnen y publican estadísticas. Estos informes pudieran indicar cuales fueron los usuarios activos, que archivos y que elementos de datos han sido utilizados, e incluso el método de acceso que se ha aplicado. Pueden capturarse y reportarse las tasas de error y los tipos de errores. El DBA analizará estos datos para determinar si se necesita una modificación en el diseño de la BD para manejar su rendimiento o para facilitar las tareas de los usuarios; de ser así, el DBA la llevará a cabo.
El DBA deberá analizar las estadísticas de tiempo de ejecución sobre la actividad de la BD y su rendimiento. Cuando se identifique un problema de rendimiento, ya sea mediante una queja o un informe, el DBA deberá determinar si resulta apropiada una modificación a la estructura de la BD o al sistema. Casos como la adición de nuevas claves o su eliminación, nuevas relaciones entre los datos y otras situaciones típicas deberán ser analizadas para determinar el tipo de modificación procedente.
Cuando el fabricante del DBMS en uso anuncie una nueva versión del producto, debe realizarse un análisis de las características que esta incorpora e insopesarlas contra las necesidades de la comunidad de usuarios. Si se decide la adquisición del producto, los usuarios deben ser notificados y capacitados en su uso. El DBA deberá administrar y controlar la migración tanto de las estructuras, como de los datos y las aplicaciones.
El software de soporte y otras características de hardware pueden implicar también modificaciones de las que el DBA es responsable ocasionalmente, estas modificaciones traen como consecuencia cambios en la configuración o en algunos parámetros de operación del DBMS.
Las opciones del DBMS son ajustadas al principio, es decir, en la puesta en marcha del sistema; en este momento se conoce muy poca información sobre las características de funcionamiento y respuesta que proporcionará a los grupos de usuarios. El análisis de la experiencia operacional y su rendimiento en un periodo determinado de tiempo pudieran revelar que se requiere un campo. Si el rendimiento parece aceptable, el DBA puede considerar a un modificar algunas opciones y observar su efecto sobre el sistema, esto en búsqueda de la optimización o afinación del mismo. 

          Conclusiones


          El administrador de base de datos, es la persona responsable de los aspectos ambientales de una
          base de datos. En general esto incluye lo siguiente:
    • Recuperabilidad - Crear y probar Respaldos
    • Integridad - Verificar o ayudar a la verificación en la integridad de datos
    • Seguridad - Definir o implementar controles de acceso a los datos
    • Disponibilidad - Asegurarse del mayor tiempo de encendido
    • Desempeño - Asegurarse del máximo desempeño incluso con las limitaciones
    • Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos.