Capítulo 5 - Administrando una Instancia Oracle

Capítulo 5
Administrando una Instancia Oracle

Objetivos de Certificación

1. Describir las etapas de Inicio y Apagado.

2. Modificando los parámetros de Inicialización.

3. Usar Alert Log y Trace File.

4. Usando Data Dictionary y Dynamic Performance Views.

5.1 – DESCRIPCION DE LA ETAPAS DE INICIO Y APAGADO DE UNA BASE DE DATOS.

SECUENCIA DE INICIO RECOMENDADA POR ORACLE

- Database control - Enterprise Manager EM.

- Database Listener – Listener.

- Database – BD.

INICIANDO EL DATABASE CONTROL ENTERPRISE MANAGER

Es una herramienta para la gestión de base de datos. Si hay varias bases de datos corriendo en el mismo server cada base tendrá su propio Database Control. Toda la comunicación con Database Control se realiza atreves de https.

La configuración del Database Control se realiza al momento de la instalación. En la configuración esta incluye dos puntos vitales: el nombre del host y el puerto por donde escucha. Para iniciar el Database Control utilice la herramienta emctl que se encuentra en oracle_home/bin

emctl start dbconsole Inicia

emctl stop dbconsole Detiene.

emctl status dbconsole Status.

PARA ESTO SE DEBE CONFIGURAR LAS VARIABLES DE ENTORNO.

- Path. Es necesaria para que el sistema operativo encuentre la aplicación emctl. La cual está en oracle_home/sid

- Oracle_Home. Es para que emctl pueda encontrar la configuración del Database control.

- Oracle_sid. Es para que emctl pueda encontrar la configuración del database control.

El directorio oracle_home/sysman/config tiene directivas de configuración general que se aplican a todas las instancias de control.

El directorio oracle_home/hostname_sid/sysman/config y un directorio de nombre similar.

Para conectar al Database Control escriba lo siguiente.

https://localhost:puerto/em

Para ver la configuración del puerto será necesario revisar oracle_home/install/portlist.ini

El mecanismo para la gestión de certificados y https variara en función de su navegador y como este configurado. El certificado realmente no importa, no necesita conexiones seguras para la autentificación, solo para el cifrado.

INICIANDO EL LISTENER

El Listener es un proceso que controla un puerto para la conexión de solicitudes a base de datos. Estas solicitudes son manejadas por oracle net.

Hay tres formas de iniciar la escucha de la base de datos.

- lsnrctl.

- emctl.

- Servicio de Windows.

La utilidad Listener se encuentra en oracle_home/bin. El nombre del Listener por default es Listener.

- lsnrctl start

- lsnrctl status

- lsnrctl stop

INICIANDO SQL PLUS

Es una herramienta cliente servidor para conectarse a la base de datos y escribir secuencias de comandos.

Este se invoca desde la línea de comando como sqlplus y en versiones Windows se crea un icono.

Oracle_home/bin

Sqlplus /nolog

INICIO Y PARADA DE LA BASE DE DATOS

CONECTANDOSE CON PRIVILEGIOS APROPIADOS.

Usuarios ordinarios no pueden iniciar y parar la base de datos. Esto se debe a que los usuarios se autentifican contra un diccionario de datos.

Es imposible que un usuario normal pueda detener ya que los datos se pueden leer hasta que el diccionario de datos sea abierto.

Usted se puede autentificar como usuario de sistema operativo si pertenece al grupo con el que fue instalado el software de oracle o mediante

Usuario / password.

connect user/password@instancia

connect user/password@instancia as sysdba

connect user/password@instancia as sysoper

connect / as sysdba

connect / as sysoper

Oracle va a valida el nombre de usuario/contraseña; a combinación con los valores almacenados en el directorio de datos.

SYSOPER Y SYSDBA

Estos son los privilegios o capacidades especiales. Que solo pude ser activado cuando los usuarios se conectan con un método de autentificación externa

sysoper tiene la capacidad de emitir estos comandos.

- startup

- shutdown

- alter database [ mount | open | close | dismount ]

- alter [ database | tablespace ] [ begin | end ] backup

- recover

El privilegio sysdba incluye todo estos, pero edamas tiene la capacidad de crear una base de datos y hacer un recovery asi como crear otros sysoper y sysdba.

sysdba y sysoper no son usuarios son privilegios, de forma predeterminada, solo el usuario sys tiene estos privilegios hasta que se conceden a otros usuarios.

Mostrar el usuario que está actualmente conectado.

show user;

sys es el usuario más poderoso y titular del diccionario de datos.

El uso del privilegio sysoper conecta como un usuario público.

Publico no es un usuario es un usuario con privilegios de administración.

STARTUP: NOMOUNT, MOUNT Y OPEN

Recuerde que la instancia y la bd son entidades separadas. Puede existir independientemente uno de otro.

EL INICIO POR ETAPAS

1 - Primero la construcción de la instancia en memoria.

2 - Segundo habilitar una conexión a la base de datos por montaje de esta.

3 - Tercero abrir la base de datos para su uso.

En cualquier momento una base de datos estará en cualquiera de estos estados.

- shutdown.

- nomount.

- mount.

- open.

- shutdown. Cuando la base de datos está cerrada y la instancia no existe.

- nomount. La instancia se ha construido en la memoria sga se han creados los procesos de fondo de acuerdo a lo especificado en el archivo de parámetros.

Pero no se ha establecido la conexión a la base de datos. De hecho es posible que la base de datos no exista.

- mount. La instancia localiza y lee los control files de la base de datos.

- open. Todos los archivos de base de datos son localizados y abiertos y la base de datos está disponible para usuarios finales.

Por ejemplo. Si el archivo de control está dañado, o una copia de multiplicación falta. Usted no será capaz de montar la base de datos.

Pero deteniendo en modo nomount puede ser capaz de reparar el daÑo.

Del mismo modo. Si hay problemas con archivos de datos o redo logs puede ser capaz de reparar en modo mount antes de abrir open la base de datos.

En cada etapa la instancia debe encontrar los archivos que necesita y exactamente lo que sucede. Inicie con nomount.

Cuando se emite un comando de inicio para localizar un archivo de parámetros hay tres nombres de archivos por defecto.

Unix.

$oracle_home/dbs/spfilesid.ora

$oracle_home/dbs/spfile.ora

$oracle_home/dbs/initsid.ora

Window

$oracle_home/database/spfilesid.ora

$oracle_home/database/spfile.ora

$oracle_home/database/initsid.ora

spfileSID.ora es sin duda el archivo más conveniente utilizar como parámetro archivo. Normalmente, sólo se utilizará spfile.ora en un entorno RAC, donde un archivo puede ser usado para ejecutar varias instancias. Sólo se utilizará un archivo initSID.ora si por alguna razón, tiene que realizar manualmente las modificaciones; spfiles son archivos binarios y no puede ser modificado manualmente.

En todos los casos, SID se refiere al nombre de la instancia que el archivo de parámetros se de inicio. El orden anterior es importante! Oracle trabajará su camino hacia abajo la lista, usando el primer archivo que encuentra e ignorando el resto. Si ninguno de ellos existe, la instancia no se de inicio. Los archivos sólo se utiliza en modo de nomount son el archivo de parámetros y alertar a la registro. Los parámetros en el archivo de parámetros se utilizan para construir el SGA en la memoria y iniciar los procesos de fondo. Las entradas serán escrito en el registro de alerta que describe este proceso. ¿Dónde está el registro de alerta? En el lugar determinado por el BACKGROUND_ DUMP_DEST parámetro, que se pueden encontrar en el archivo de parámetros o ejecutando

Los archivos solo se utilizan en modo nomount son el archivo de parámetros y la descripción del registro. Estos se utilizan para construir los procesos en la sga e iniciar los procesos de fondo.

Las entradas se escriben en el registro de altertas donde se encuentra en spfile background_dump_dest o ejecutando lo siguiente.

show parameter background

--- pfile background_dump_dest en archivos tracer

Un archivo init es conocido como un archivo de parámetros estático o un pfile. Porque solo se lee una vez al inicia de la instancia.

Un spfile es conocido como un archivo de parámetros dinámico ya que oracle lee y actualiza continuamente durante la ejecución de la instancia.

Nota. En los archivos tracer que se encuentran en show parameter background se encuentra información donde se inicia la base donde se inicia la memoria sga.

Esta información también la obtenemos con background_dump_dest este parámetro se encuentra en background_dump_dest.

Una vez que una instancia ha sido iniciada en modo nomount, se pude realizar la transición a la modalidad mount y leer los archivos controlfiles.

Los archivos controlfile se localizan por medio de los parámetros control_files del archivo de parámetros.

Si los control files estan dañados o cualquier copia multiplexada la base de datos no se montara y tendrá que tomar medidas adecuadas.

Todas las copias de los controlfile deben de ser identicas para que el montado sea exitoso.

Como parte del proceso de mount. El nombre y localización de los datafiles y online redo logs son leídos desde el archivo de control pero Oracle todavía no trata de encontrarlos.

Si durante la transición a modo open. Si los archivos no están presentes o dañado, la base de datos se mantendrá en modo mount y no se puede abrir hasta se tomen medidas.

Además, incluso si todos los archivos están presentes deben ser sincronizados antes de abrir la base.

Si el ultimo cierre fue ordenado todos los database buffers dentro del database buffer se escriben en el disco por dbwn entonces se sincronizaran.

Oracle sabe que todas las transacciones commit son almacenadas seguramente en los datafiles y las transacción no commit son regresadas roll back.

Sin embargo si el ultimo cierre fue desordenado como apagón o el servidor se reinicia entonces oracle debe reparar el daño y es considerado como estado incoherente.

El proceso que se monta y se abre la base lo lleva a cabo el proceso smon. Solo una vez que sea abierto la base oracle otorga permiso para que se conecten usuarios.

El apagado debe ser el reverso de un startup. Durante un apagado ordenado. La base de datos es primeramente cerrada, después desmontada y final detenido de la instancia.

Durante la fase de cerrado, todas la sesión se terminan, operaciones activas se deshacen y transacciones completadas se escriben en el disco por dbwn y los archivos de datos

Y redo logs son cerrados.

Durante el desmount. Se cierran los controlfiles. La instancia es detenida y liberada la memoria sga y terminación de los procesos background.

Si alguien en medio de una actualización o por ejemplo estaban cargando información cuando está cerrando la base la fase de rollback entonces la base de datos se tardara en cerrar ya que limpiara esa actualización la regresara.

SHUTDOWN: NORMAL, IMMEDIATE, TRANSACTIONAL AND ABORT

Estas opciones pueden ser usadas por sysdba y sysoper.

shutdown [ normal | transactional | immediate | abort ]

Típicamente un apagado normal es inútil, siempre hay alguien conectado, incluso si es solo el enterprise manager.

- transactional. No son permitidas nuevas transacciones. Sesiones existentes que no están en transacción se terminan. Sesiones que están transaccionando se esperan a que terminen y luego se terminan. Hasta que todas las sessiones terminen de transaccionar se pagara la base.

- immediate. No se permiten nuevas transacciones. Y los actuales se terminan. Cualquier transacción activa se hace roll back y la base se cierra.

- abort. En lo que respecta a oracle, esto es equivalente a un corte de energía. La instancia termina inmediatamente. Nada es escrito en disco. Y no hay ningún intento de poner fin a las transacciones que puedan estar en curso.

Un shutdown abort no dañara la base de datos. Pero algunas operaciones no son recomendables después de un abort. Tales como copias de seguridad.

Los modos de apagado normal, immediate, transactional suelen llamarse como consistentes limpieza u ordenadas.

Después que todas las sessiones son terminadas pmon revertirá todas las transacciones incompletas. Entonces el este punto se forza al dbwn a escribir en el disco todos del buffer database.

Lgwr tambien vuelca los vectors de la memoria en los log files a continuación los encabezados de archivo se actualiza y los identificadores de archivo cerrados.

El modo abort se denomina en cierre desordenada deja la base de datos en modo incoherente, es muy posible que las transacciones confirmadas se han perdido porque solo existían en la memoria y dbwn aun no habia escrito los datos en archivos.

Igualmente puede haber comprometido las operaciones de los archivos de datos que todavía no se han revertido.

Hay un comando startup que es startup force este puede ahorrar tiempo. Estos son dos comandos en uno: un shutdown abort seguido de un startup.

Un cierre ordenado es un proceso gradual y en teoría es posible controlar las etapas.

Alter database close;
Alter database dismount;

Estos comandos son exactamente el inverso de una secuencia de inicio. En la práctica sin embargo no hay ningún valor para ellos, un dba nunca los utilizara.

EJERCICIO
Realizar un startup y un shutdown.

1.- Inicie una sesión de oracle.

2.- Verifique el estado de los listener y si es necesario inícielos.

3.- Verifique el estado del Enterprise Manager.

4.- Login a slqplus como /nolog.

5.- Conéctese como sys.

6.- Inicie solo la instancia.

7.- Monte la base de datos.

8.- Abrir la base de datos.

9.- Confirme que la base de datos está abierta con el siguiente query.

select count(*) from dba_data_files;

10.- Conectese al enterprise manager con sys.

11.- Apague la base desde Enterprise Manager.

RESUMEN
GESTION DE LA INSTANCIA DE ORACLE

La instancia abre una base de datos. Pero son diferentes cosas. La instancia solo lee el archivo de parámetros para construir en memoria. A continuación se monta la base de datos mediante la lectura de los archivos controlfiles.

Cuya ubicación se especifica por un parámetro. Los controlfile tiene punteros a el resto de la base de datos.

Cuando se inicia una base de datos en etapas. El modo nomount requiere solo del archivo de parametros.

El modo mount requiere de los archivos controlfiles y el modo open requiere de los datafiles y online redo log.

La instancia y el archivo controlfile puede ser interrogado a traves en mount y no mount. En modo open el diccionario de datos puede ser interrogado.

5.2 ASIGNANDO VALORES DE INICIALIZACION DE LA BASE DE DATOS.

Una instancia es definida por los parámetros utilizados para su construcción en la memoria. Se puede cambiar después del arranque mediante el ajuste de estos parámetros, si los parámetros son los que se puede modificar en tiempo de ejecución. Algunos se fijan en el tiempo de inicio y sólo pueden ser modificados por el cierre de la instancia y comenzar de nuevo.

Los parámetros utilizados para crear la instancia inicial.

Vienen desde el archivo de parámetros que puede ser un pfile(estático) o un spfile(dinámico) o de valores por defecto.

Cada parámetro tiene un valor predeterminado, excepto para el parámetro DB_NAME, lo que siempre debe ser especificado.

En total hay cerca de trescientos parámetros (el número exacto puede variar entre las distintas versiones y plataformas) que es aceptable para el DBA para configurar. Hay de hecho acerca de otros mil quinientos parámetros, conocido como "ocultos" los parámetros, que el DBA no se supone que establece, los cuales generalmente no son visibles y sólo se mantendrá en Oracle Support.

Los (aproximadamente) de trescientos parámetros se dividen en "básicos" y "Avanzados". La idea es que la mayoría de los casos la base de datos funcionará correctamente con un valor predeterminado valores para los parámetros avanzados. Sólo alrededor de treinta y tres (el número exacto puede variar entre versiones) son "básicos". Por lo tanto los parámetros de configuración no es una tarea enorme. Pero es muy importante.

PARAMETROS ESTATICOS Y DINAMICOS Y EL ARCHIVO DE PARAMETROS.

Para ver los parámetros y sus valores actuales, ejecute la siguiente consulta:

select name,value from v$parameter order by name;

Una consulta que puede dar resultados ligeramente diferentes

select name,value from v$spparameter order by name;

La diferencia es la vista desde el cual los nombres de parámetros y valores son tomados. V$PARAMETER muestra los parámetros y valores actuales de la instancia que se está ejecutando. V$SPPARAMETER muestra los parámetros y valores del spfile guardado en disco. Por lo general, estos serán los mismos. Pero no siempre. Algunos parámetros suelen ser cambiados durante la ejecución de la instancia. Otros, conocidos como parámetros estáticos, se fijan en el momento de inicio de la instancia. Un cambio realizado en los parámetros modificables tendrá un efecto inmediato y opcionalmente se puede escribir a la spfile. Si se hace esto, entonces el cambio será permanente: la próxima vez que la instancia se detiene y se inicia la instancia, el nuevo valor será leído del spfile. Si el cambio no se guarda en la spfile, entonces el cambio sólo persiste hasta que la instancia sea detenida. Para cambiar un parámetro estático, el cambio debe ser por escrito a la spfile, a continuación, entrará en vigor en el siguiente inicio. Si la salida de las dos consultas anteriores es diferente, eso normalmente será porque el DBA ha realizado un trabajo de optimización que aún no ha hecho permanente, o consideró necesario ajustar un parámetro estático y aún no ha reiniciado la instancia. Las otras columnas de V$PARAMETER Y V$SPPARAMETER son fácil de entender. Ellos muestran la información tal como si el parámetro se puede cambiar (Por un período de sesiones o para la instancia conjunto), si se ha cambiado, y si se ha especificado en absoluto o se encuentra en forma predeterminada. Las vistas V$PARAMETER y V$SPPARAMETER pueden ser vistas atreves del Database Control. De la Página principal en el TAB Server en el Link Parámetros de Inicialización.

Para cambiar parámetros con sqlplus utilice el comando: ALTER SYSTEM:

El prime query muestra el valor del parámetro DB_CREATE_FILE_DEST, el que esta ejecutándose en memoria y el que está en el archivo spfile. Los siguientes dos comandos asignan valores distintos pero usando la palabra SCOPE. Los resultados se ven en la segunda consulta. El ultimo comando utilice SCOPE = BOTH los dos al mismo tiempo.

Pregunta de examen: Un intento de cambiar un parámetro estático causara error a menos que se especifique en el SCOPE como SPFILE. Valor predeterminado es SCOPE = BOTH La instancia en ejecución y el archivo spfile. Si la instancia se inicia con pfile a continuación el SCOPE = spfile fallará.

Como se vio en el capítulo 4, cuando una instancia de base de datos se creó por primera vez, será fruto de un pfile. Esto tiene que ser convertido a un spfile. El comando es:

create spfile [='spfilename'] from pfile [='pfilename'];

Si los nombres no se dan para spfilename o pfilename, a continuación, los nombres predeterminados basados estarán basados en ORACLE_HOME y el SID se deben asumir. Para la ingeniería inversa de un spfile en un pfile, el comando es

create pfile [='pfilename'] from spfile [='spfilename'] ;

El PFILE CREATE y crear comandos SPFILE se puede ejecutar desde SQL * Plus en cualquier momento, incluso antes de la instancia se ha iniciado.

LOS PARAMETROS BASICOS.

Los parámetros considerados básicos en una instancia son los que deben ser considerados por cada base de datos. En algunos casos, el valor por default va a estar bien. Para ver los básicos utilice esta consulta.

select name,value from v$parameter where isbasic='TRUE' order by name;

Una consulta que puede dar resultados ligeramente diferentes.

select s.name,s.value from v$spparameter s join v$parameter p on s.name=p.name where p.isbasic='TRUE' order by name;

PARAMETRO	PROPOSITO
cluster_database	Indica si la base de datos esta en RAC o en Single Instancia.
compatible	La versión de la instancia se emulará. Normalmente, esto sería la versión actual, pero puede parecerse a versiones anteriores.
control_files	Nombre y localización del control files.
db_block_size	Tamaño de block por default para el formato de los datafile.
db_create_file_dest	Localización default para los datafiles.
db_create_online_log_dest_1	Localización default para los online redo log files.
db_create_online_log_dest_2	Localización default para los online redo log files copias multiplexadas.
db_domain	El nombre de dominio que puede agregarse a la db_name para generar un nombre único en el mundo.
db_name	Nombre de la base de datos.
db_recovery_file_dest	Localización del Área de Recuperación Flash.
db_recovery_file_dest_size	Cantidad de datos que se pueden escribir en el área de recuperación flash.
db_unique_name	Único nombre de base de datos, necesarios si hay dos bases de datos con el mismo db_name en un mismo equipo.
Instance_number	Se utiliza para distinguir entre dos instancias RAC de abrir la misma base de datos. Otra indicación de que se considera estándar RAC
job_queue_processes	Numero de procesos disponibles para ejecutar trabajos programados.
log_archive_dest_1	Destino para el archivado de los redo log files
log_archive_dest_2	Destino para las copias multiplexadas de los redo log files.
log_archive_dest_state_1	Indicador si el destino está habilitado sí o no.
log_archive_dest_state_2	Indicador si el destino está habilitado sí o no.
nls_languaje	El lenguaje de la Instancia.
nls_territory	La ubicación geográfica de la instancia.
open_cursors	El número de áreas de trabajo de SQL que una sesión puede tener abiertos a la vez.
pga_aggregate_target	Cantidad total de memoria de la instancia para alojar la PGA.
processes	Número máximo de procesos (incluyendo los procesos del servidor de sesiones) pueden conectarse a la instancia
remote_listener	Direcciones de los Listener en otra máquina con la que la instancia deben inscribirse, otro parámetro que sólo es relevante para un RAC
remote_login_passwordfile	Sea o no utilizar un archivo de contraseñas externa, para permitir el archivo de contraseñas autenticación.
rollback_segments	Casi obsoleto, reemplazado por los parámetros que siguen UNDO
sessions	Cantidad máxima de sesiones permitida en la instancia.
sga_target	El tamaño del SGA, dentro del cual Oracle gestionará las diversas SGA estructuras de memoria.
shared_server	El número de procesos de servidor compartido para poner en marcha, en sesiones que no son establecido con los procesos de servidor dedicado
star_transformation_enabled	Ya sea para permitir que el optimizador de consultas que volver a escribir unirse a la dimensiones de una tabla de hechos
undo_management	Ya sea deshacer datos deben ser gestionados de forma automática deshacer de tablas, o de forma manual en los segmentos de rollback gestionados
undo_tablespace	Si se utiliza la gestión automática de deshacer, donde los datos deben residir deshacer

CAMBIANDO PARAMETROS
Los parámetros estáticos no se puede cambiar más que con un ALTER SYSTEM con SCOPE=SPFILE o BOTH.
Un ejemplo de parámetro estático es LOG_BUFFER, si tu deseas redimensionar el tamaño a 6m usas el siguiente comando.

alter system set log_buffer=6m;

El comando fallará pero lo puedes cambiar SCOPE=SPFILE y el cambio resultara hasta que reinicies.
El default log buffer probablemente es el correcto. Si usted lo plantea, esposible que comprometer la transformación se lleve más tiempo.
Si lo haces más pequeño que por defecto, será en hecho de ser internamente ajustado hasta el tamaño predeterminado.

EJERCICIO 5-2.
CONSULTAS Y AJUSTE DE PARAMETROS DE INICIALIZACION.

1.- Conéctese a la base de datos con el usuario sys y privilegios sysdba.
2.- Despliegue todos los parámetros básicos, verificando si se han establecidos o son los default.

Select name, value, isdefault from v$parameter where isbasic = ‘TRUE’

3.- Los parámetros básicos que están en default se debe investigar para ver si el predeterminado es correcto.
De hecho, todos los parámetros básicos deben ser considerados. Lea sobre todos ellos en la documentación de Oracle ahora. El volumen que necesidad se titula Oracle Database referencia. Parte1, Capítulo 1 tiene un párrafo describir todos los parámetros de inicialización.

OBJETIVOS DE CERTIFICACION 5.03
USO DE ALERT LOG Y ARCHIVOS TRACE
El Alert Log es un registro continuo de las operaciones esenciales aplicado a la instancia y la base de datos. Su ubicación es determinada por el parámetro background_dump_dest y su nombres es alert_SID donde SID es el nombre de la base de datos.
Las operaciones guardadas en el alert log son:
Todos los comandos de inicio y cierre, incluidos los comandos intermedios, tales como alter database mount.
Todos los errores internos a la instancia (el ORA-600 errores, sobre la cual el DBA puede hacer otra cosa que informe a Oracle Support).
Cualquier corrupción de block de datafiles.
Cualquier bloqueo de registro ocurrido.
Todas las operaciones que afectan a la estructura física de la base de datos, tales como la creación de Datafile o cambiar de nombre de los redo log.
Todos los comandos Alter System que ajustan valores de parámetros.
Todos los log switch y log archives.

El Alert Log para un inicio muestra todos los parámetros de inicialización no predeterminada. Esta información, junto con el registro de secuencia de cambios para la instancia con ALTER SYSTEM y la estructura física de la base de datos con ALTER DATABASE, significa que siempre es posible reconstruir la historia de los cambios en la base de datos y la instancia. Esto puede ser muy valioso cuando se trata de dar marcha atrás con el fin de encontrar el origen de un problema.

EN EL TRABAJO
Para muchos administradores de bases, lo primero que hacen cuando se les pide que mire una base de datos por primera vez que se localice el registro de alertas y escanear a través de él, sólo para tener una idea de lo que ha estado sucediendo.
Los archivos trace son generados por varios procesos background generalmente cuando ocurra un error. Se generan archivos en BACKGROUND_DUMP_DEST junto con el Alert Log. Si un proceso background falla por algún error. El archivo trace es de gran valor para diagnosticar el problema.

EJERCICIO 5-3.
USO DE ALERT LOG

En este ejercicio. Localiza el alert log y bsucar la entrada para el parámetro cambiado en el ejercicio 5-2 y el inicio y parada del ejercicio 5-1.

1. Conéctese a la base de datos con sqlplus y buscar el valor del parámetro background-dump_dest .
Select nama, value from v$parameter where name = ‘background_dump_dest’
2. Localice el directorio del paso n.1.
3. Abrir el archivo alert log.
4. Localice los alter system en los ejercicios anteriores.

OBJETIVOS DE CERTIFICACION 5.04
USO DEL DICCIONARIO DE DATOS Y VISTAS DINAMICAS DE RENDIMIENTO
Una base de datos se define por un Diccionario de Datos. El diccionario no es muy entendible para los seres humanos. Por esta razón. Oracle ofrece un conjunto de vistas hacia el diccionario de datos mucho más fácil de entender. Estas vistas son la herramienta para un dba para ver que está ocurriendo en la base de datos. La instancia también tiene un conjunto de tablas también no comprensible. Esto también se puede ver mediante vistas para entender que está ocurriendo en la base de datos.

VISTAS AL DICCIONARIO DE DATOS.
El diccionario de datos son metadatos, datos sobre los datos, en el se describe la base de datos física, lógicamente y su contenido. Definiciones de usuario, seguridad de la información, restricciones de integridad desde la versión 10 la información de supervisión del rendimiento son todos parte del diccionario de datos. El diccionario de datos se almacena en un conjunto de segmentos en los tablespace SYSTEM y SYSAUX.
En muchos sentidos. Los segmentos que componen el diccionario de datos son segmentos como los demás: solo tablas e índices. La diferencia principal es que el diccionario de datos las tablas son creadas en el proceso de creación de la base de datos y nose permite el acceso directamente. No hay nada que impida a un DBA la investigación del diccionario de datos directamente, pero si hace actualizaciones puede causar daños irreparables, oracle no ofrece soporte para estos casos.
La creación de un diccionario de datos es parte del proceso de creación de la base de datos. Se mantiene posteriormente por los comandos del Lenguaje de Definición. Al emitir el comando CREATE TABLE, lo que hace es insertar filas en tablas del diccionario de datos, así como también con: CREATE USER o GRANT.
Para consultar el diccionario de datos. Oracle ofrece un conjunto de vistas. Las opciones de dividen en tres formas, los prefijos son: DBA_, ALL_ o USER_. La mayoría de las vistas están en los tres prefijos. Cualquier vista con prefijo USER_ se rellenará con files que describen objetos de propiedad del usuario.
Así que no hay dos personas que podrán ver el mismo contenido. Si el usuario SCOTT consulta USER_TABLES mostrara información de sus tablas. Si consulta USER_TABLES, se mostraran información sobre las tablas. Cualquier vista con el prefijo ALL_ se rellenará con filas que describen objetos a los que tiene acceso. Así ALL_TABLES contendrá registros describiendo sus propias tablas, además tablas que se tienen permiso aun que no sean de el. Cualquier vista con el prefijo DBA_ tendrá filas para cada objeto en la base de datos. Para DBA_TABLES tendrá una fila para cada tabla en la base de datos sin importar quien la creo. Estas vistas se crean como parte del proceso de creación de la base de datos asi como un gran número de paquetes PL/SQL.

DENTRO DEL EXAMEN
Que vista le mostrará todas las tablas de la base de datos. DBA_TABLES no ALL_TABLES.

Hay cientos de vistas al diccionario de datos, algunos de los más comunes utilizados por los dbas son:

- DBA_OBJECTS. Una fila para descrbir cada objeto de base de datos.
- DBA_DATA_FILES. Una fila para describir cada datafile.
- DBA_USERS. Una fila para describir cada usuario.
- DBA_TABLES: Una fila para describir cada tabla.
- DBA_ALERT_HISTORY. Una fila para describir últimas condiciones de alerta.

Hay muchos más que éstos, algunos de los cuales se utilizarán en capítulos posteriores. Como
así como las vistas, no son sinónimos públicos en los puntos de vista.

select object_name,owner, object_type from dba_objects where object_name='DBA_OBJECTS';

Demostrará que en realidad no hay una vista llamada DBA_OBJECTS propiedad de SYS y
sinónimo público con el mismo nombre.

VISTAS DINAMICAS
Hay más de trescientos vistas dinámicas. Son invocadas con prefijos v$.

La figura muestra v$sql, que tiene una fila por cada sentencia sql actualmente almacenados en el shared pool, con información como la frecuencia de la declaración ha sido ejecutada.

Obtener todas las vistas.

Select * from dba_object where object_name like ‘v$*’

Las vistas acceden a una cantidad fenomenal de información acerca de la instancia y acerca de la base de datos. La mayoría de las vistas son generadas a partir de la información de la instancia. El resto de los controlfile. Todas ellas brindan información de tiempo real. Las vistas dinamicas se rellenan apartir de la instancia, como v$instance o v%sysstat están disponibles cuando la instancia esta en modo nomount. Las vistas dinamicas se rellenan de los controlfile como v$database o v$datafile no se pueden consultar a menos que la instancia se halla montado. Que es cuando los controfile se han leído. Por el contrario las vistas al diccionario de datos se puede consultar hasta que la base de datos se ha abierto.

EXAMEN
Las vistas se rellenan apartir de la instancia y controlfiles. Las ALL_, DBA_, USER_ se rellenan a partir del diccionario de datos. Esta diferencia marca que podemos consultar en las diferentes fase de inicio de una instancia.
Las vistas dinámicas son creadas en el inicio, actualizando durante la vida de la instancia y eliminada al apagar la instancia. Esto significa que contendrá valores que se han acumulado desde el inicio de la instancia. Si tu base de datos ha estado abierta durante seis meses sin parar, se disponen de datos acumulados durante ese periodo. Después de un apagado/inicio, va iniciar desde el principio. Si bien los totales pueden ser interesantes, no le dirá nada acerca de lo que sucedió durante ciertos periodos definidos, cuando puede haber habido problemas de rendimiento. Por esta razón. Esto es generalmente cierto las vista dinámicas obtienen las estadísticas y no las métricas. La conversión de estas estadísticas en metricas es un trabajo calificado y algunas veces esta tarea consume mucho tiempo, mucho más fácil por el ajuste automático y capacidades de monitoreo de la base de datos.

EN EL TRABAJO
Existe cierta coincidencia entre v$ vistas y vistas del diccionario de datos. Para la instancia, V$TABLESPACE tiene un registro para cada tablespace, al igual que DBA_TABLESPACE. Tenga en cuenta por regla general. V$ Vistas son singular y data dictionary son plural. Pero hay excepciones.

Escenario y Solución
Usted esta ha carga la administración de una base de datos. Como iniciaría?	Mirar el registro de alerta (Alert Log). Tú puedes verificar esto buscando el parámetro BACKGROUND_DUMP_DEST. Mirar todos los parámetros  non-default para ver como se construyó la instancia. Consultar las vistas que muestran la estructura física: V$DATAFILE, V$LOGFILE.
Si usted no tiene un login para la base de datos. Se puede hacer algo.	Si. Usted puede. Si usted tiene un inicio de sesión de sistema operativo apropiado, como un usuario de sistema operativo que es miembro del grupo al que pertenece  ORACLE_HOME, se puede conectar como sys usando la autentificación del sistema operativo. A continuación, puede crear un usuario normal, le concede privilegios como dba y conectarse con este nuevo usuario a partir de ahora.
En Windows. Siempre parece que hay dos maneras de iniciar las cosas: BAT o CMD Scripts Shells, o Servicios. ¿Cómo puede administrar el inicio del Entorno de Oracle?	Si hay dos opciones: Iniciar los servicios definidos en el registro, o escribiendo un archivo por lotes que iniciará los procesos. La excepción es la instancia de la base de datos. El servicio debe ser iniciado y luego el servicio puede seguir iniciar la instancia, o puede iniciar la instancia con un comando sql plus llamado desde un archivo por lotes. Las personas se familiarizan definiendo servicios, en particular con la definición la dependencias entre ellos, prefieren este método. Las personas menos familiarizadas con los servicios o quieran un despliegue del inicio prefieren utilizar Shell script.

EJERCICIO 5-4.
CONSULTAS AL DICCIONARIO DE DATOS Y VISTAS DINAMICAS
En este ejercicio, investigará la estructura física de la base de datos consultando vistas.

1.Conéctese a la base de datos con Sql plus o Sql Developer.
2.Use vistas dinámicas para determinar los datafile y tablespaces.
Select t.name, d.name, d.bytes from v$tablespace t join v$datafile d on t.ts# = d.ts# order by t.name
3.Obtener la misma información del diccionario de datos.
Select t.tablespace _name, d.file_name, d.bytes from dba_tablespace t join dba_data_files d on t.tablespace_name = d.tablespace_name order by tablespace_name
4.Determinar la localización de las copias de los controlfiles. Use dos técnicas.
Select * from v$controlfile;
Select value from v$parameter where name=’control_files’;
5.Determine la locacizacion de los online redo log file miembros. Y su tamaño. Como el tamaño es un atributo del grupo y no del miembro. Tú tienes que realizar in join de vistas.
select m.group#,m.member,g.bytes from v$log g join v$logfile m on m.group#=g.group# order by m.group#,m.member;

RESUMEN DE CERTIFICACION.
El inicio de una base de datos es un proceso en etapas. Cada etapa requiere varios archivos que estén disponibles. Solo cuando todas las etapas son completadas usuarios regulares pueden logearse. Antes de eso, solo usuarios con privilegios SYSDBA o SYSOPER pueden conectarse y deben utilizar una forma de autentificación que no sea el diccionario de datos. La instancia se construye de acuerdo a los parámetros almacenados en un archivo de parámetros. Muchos de estos parámetros pueden ser cambiados con la instancia ejecutándose, pero otros solo pueden ser escritos en el archivo de parámetros y estos afectaran la instancia hasta que sea reiniciada. En el modo NOMOUNT y MOUNT, varias vistas dinámicas serán visibles. Una vez en modo OPEN el diccionario de datos puede ser consultado.

DOS MINUTOS DE ESTUDIO.
Describe las etapas de Inicio y Parada de la Base de Datos.
- Las etapas son NOMOUNT, MOUNT y OPEN.
- Modo NOMOUNT requiere de un Archivo de parámetros.
- Modo MOUNT requiere de los controlfiles.
- Modo OPEN. Requiere de los datafiles y online redo log files.

Establecer parámetros en la base de datos.
- Los parámetros estáticos no pueden ser cambiados sin una shutdown/startup.
- Otros parámetros pueden ser cambiados dinámicamente. Para la instancia o una sesión.
- Los parámetros pueden ser visulizados con vistas dinamicas, las cuales son V$PARAMETER y V$SPPARAMETER.

Usando los Alert Log y Trace Files.
- Los alert log son un continuo flujo de mensajes con respecto a las operaciones criticas.
- Las trace files son generados por procesos de fondo, usualmente cuando hay errores.

Usando diccionario de datos y Vistas dinamicas.
- Las vistas dinámicas son llenadas de la instacia o el controlfiles.
- El diccionario de datos son llenados de el diccionario de datos.
- Las vistas dinámicas acumulan valores durante el tiempo de vida de la instancia y son reiniciados con un startup.
- El diccionario de datos muestra información que persiste atraves de shutdown y startup.
- Ambos el diccionario de datos y vistas dinámicas son publicados atreves de sinónimos.