Cuales son los modos de apagado de una base de datos y que hace cada modo

Los modos de apagado de una base de datos son:

Shutdown Normal: Es raramente usado debido a que este espera a que todos completen su trabajo y luego sale. Cuando ocurre un shutdown normal, la base de datos se cierra normalmente y todos los cambios hechos van a los datafiles. Es conocido como un apagado limpio aunque no es practico pues siempre puede haber alguien que halla olvidado loggearse o pueden haber procesos de oracle zombies, y en ese caso la base de datos nunca se va a apagar.
SQL> shutdown

Shutdown Inmediato: Puede ser la mejor manera de apagar la base de datos. Este modo previene cualquier nuevo login, hace un rollback de cualquier transaccion sin commitear y luego apaga la base de datos. Oracle grabara los cambios igual que el apagado normal. Es un modo de apagado más rápido. Funciona la mayoría del tiempo pero hay casos en los que puede fallar.
SQL> shutdown immediate

Oracle Shutdown Abort Command: Es un modo de apagado es una modo garantizado para apagar la base de datos. Es un modo de apagado hard crash y puede resultar en que toma más tiempo empezar la base de datos. Sin embargo, no puede realmente dañar la base de
datos y puede ser util en varias ocasiones, aunque no debería ser el método
que se use normalmente.
SQL> shutdown abort

Shutdown Transaccional: No se permiten nuevas conexiones o no se permiten nuevas transacciones a empezar luego de que se ejecuta la sentencia. Es un modo de apagado para solo la instancia, asi que solo espera las transacciones locales a completarse, no todas las transacciones. Luego que todas las transacciones terminan, cualquier cliente conectado a esta instancia es desconectado.
SQL> shutdown transactional

Shutdown Transaccional Local: Es un modo de apagado para solo la instancia, asi que solo espera las transacciones locales a completarse, no todas las transacciones. SQL> shutdown transactional local

Que son los tablespace del tipo undo y como funcionan

Es el que almacena la información transaccional. Todas las bases de dato oracle deben tener un metodo para mantener la información que es usada para realizar un rollback. Tal información
consiste en registros de acciones de transacciones, antes de realizarse su commit correspondiente. A esta colección de registros se les conoce como Undo. Los registros de Undo son usados para:

• Realizar rollback de transacciones cuando se usa la sentencia ROLLBACK.
• Recuperar la base de datos
• Proveer consistencia de lectura
• Hacer una recuperación de una corrupción lógica

Cuando se realiza una sentencia rollback, los registros en undo son usados para deshacer los cambios que fueron hechos en la base de datos por la transacción que aún no ha sido commiteado. Durante la recuperación de la base de datos, los registros de undo se usan para dehacer los cambios aplicados del redo log. Los registros undo mantienen consistencia de lectura pues mantienen una imagen de la data para los usuarios que acceden a la data al mismo tiempo que otro usuario la está alterando.Oracle administra automaticamente el tablespace de undo si el manejo automatico está habilitado y el ususario no crea su undo tablespace. Pero
uno puede crear su propio undo tablespace usando una sentencia como 'CREATE
UNDO TABLESPACE’.

Por ejemplo para crear un tablespace de undo podemos hacer los siguiente:CREATE undo tablespace undo_tbs datafile ‘/u02/oradata/strinix/undo_tbs_01.dbf’ size 600M;

y luego indicar a oracle que queremos usarlo como undo tablespace

alter system set undo_tablespace = ;

ARQUITECTURA DE BASE DE DATOS ORACLE

La arquitectura Oracle tiene 3 componentes básicos:

• Las estructuras de memoria para almacenar los datos y el código ejecutable
  
• Los procesos que corren el sistema de bases de datos y las tareas de cada usuario conectado a la base de datos
  
• Los archivos que sirven para el almacenamiento físico, en disco, de la información de la base de datos.
  
  

Estructuras de Memoria

Hay 2 clases de memoria, una compartida por todos los usuarios y otra dedicada al trabajo de cada uno.

El SGA (system global area) es el área compartida y se divide en:

• Shared pool: Mantiene el diccionario de datos y las áreas compartidas de las órdenes SQL que se solicitan para su procesamiento.
• Database buffer cache: Es una porción del SGA que almacena los bloques de datos más recientemente usados. Pueden contener datos modificados todavía no escritos a disco. Mantiene los datos traídos de órdenes SQL.
  
• Redo log buffer: Registra los cambios hechos a la base de datos.
  
• 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.

Las 3 últimas antes mencionadas son opcionales.

Para cada sesión de usuario se crea también un área específica en memoria llamada PGA (program/process global area), la cual no se comparte con las otras sesiones de usuario.  

Procesos

Los procesos son programas que se ejecutan para permitir el acceso a los datos. Los procesos se cargan en memoria y son transparentes para los usuarios. Los procesos se clasifican en 3: procesos de base (background), de usuario y de proveedores.

Los procesos background son los que se encargan de traer datos desde y hacia la SGA; mejorando el desempeño al consolidar las tareas que son impartidas por todos los usuarios. Son:

• Escritor de la BD (DBWR – Database writer): Es un proceso obligatorio que escribe los bloques modificados por los usuarios en los archivos que componen la BD cuando LGWR le envía el mensaje de hacerlo.
• Escritor de registros (LGWR – Log writer): Escribe datos desde la SGA a los archivos redo log que sirven en caso de fallas en la instancia. Este proceso es obligatorio. LWGR envía la orden de escritura a l proceso DBWR.
  
• Punto de control (CKPT - Check point): El punto de comprobación es un proceso opcional que ocurre cuando los usuarios conectados a la BD hacen solicitudes de exámenes de datos.
  
• Supervisor del sistema (SMON – System monitor): Recupera el sistema ante una falla de la instancia.
• Supervisor del proceso (PMON): Limpia el database buffer cache y libera recursos después de un proceso fallido.
  
• Archivador (ARCH - Archive): Copia los registros de rehacer de la RAM en archivos de datos que permiten la recuperación cuando se presentan fallas de los medios magnéticos. 
  
• Recuperador (RECO - Recovery): Recupera ante las fallas, en una transacción en ambientes distribuidos.
• Bloqueo (LCKn - Lock): Efectúa los bloqueos entre instancias en caso de ambientes con servidores paralelos. Proceso opcional.
  

Los procesos de usuario suceden cuando un usuario se conecta a la base. Se crea un proceso que se encarga de ejecutar el código de aplicación del usuario y manejar el perfil del usuario con sus variables de ambiente. No se pueden comunicar directamente con la BD, sólo lo hacen a través de  procesos de servidor.

Los procesos de servidores ejecutan las órdenes SQL de los usuarios y llevan los datos al Database buffer caché, para que los procesos de usuario puedan tener acceso a los datos. 

Archivos

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. Sirven para el almacenamiento físico de las tablas, índices o agrupamientos (clusters) y procedimientos. Las unidades lógicas más grandes manejadas por Oracle son los tablespaces, que le permiten controlar espacios en el disco. Los tablespaces consisten de 1 o más datafiles. El espacio de tablas creado automáticamente es System. Un objeto de BD puede ser una tabla, un índice, un archivo temporal, los cuales se almacenan físicamente en segmentos, que son una colección de segmentos, que son una colección de data blocks, que son mapeados a los bloques del SO.
  

 

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.
• Backup Files: Copias de seguridad.

¿Qué es el Listener?

Es un programa residente en memoria que se encarga de recibir las llamadas que llegan a la base de datos desde la red, y de pasárselas a esta. Una base de datos que no tenga un listenercargado, no podrá recibir llamadas remotas. El listener se comunica con el servicio de red.

Cuando una se pide una conexión a la base de datos, el listener devuelve la información relativa a la conexión. La información de una conexión para una instancia de una base de datos provee el nombre de usuario, la contraseña y el SID de la base de datos. Si estos datos no son correctos se devolverá un mensaje de error.Por defecto el puerto del listener es el 1521. El listener no limita el número de conexiones a la base de datos.

¿QUE ES TNSNAMES?

El archivo tnsnames.ora es un archivo de configuración que contiene nombres de servicios en red mapeados, asignados a descriptores a través de los cuales se nos permite acceder. Está ubicado en los clientes.

Los parámetros del archivo son:

HOST: Dirección ip del servidor con el cual queremos conectar

PORT: Puerto donde escucha la base de datos

SERVICE_NAME: Nombre del servicio de base de datos al que queremos conectar

DESCRIPTOR DE CONEXION: En este caso el descriptor para conectarnos es CNNORASITE

En windows se ubica en the %ORACLE_HOME%\network\admin directory on Windows operating systems.

(Fuente: http://www.orasite.com/tutoriales/archivos-configuracion-red-oracle.html)