miércoles, 22 de abril de 2009

Modos de apagado de una BD y Tablespaces Undo

¿Cuàles son los modos de apagado de una base de datos?

Para apagar una Base de Datos en Sql*Plus se utiliza el comando SHUTDOWN, el cual tiene Las siguientes opciones: normal, transactional, immediate, abort.

1..- NORMAL:

Espera a que los usuarios conectados actualmente finalicen TODAS las operaciones.Evita nuevas conexiones. Los usuarios que intentan conectarse reciben el mensaje "Shutdown in progress".Cierra y desmonta la B.D. Cierra la SGA para los procesos background.No necesita recuperacion al arrancar la base de datos.

SQLPLUS> connect sys as sysdba
connected
SQLPLUS> shutdown normal

2.- TRANSACTIONAL: Después de ejecutarla, los clientes no podrán comenzar nuevas transacciones, y la base de datos se parará cuando todas se hayan confirmado (commit) o anulado (rollback).

No permite establecer una nueva conexión con la bd, espera que las conexiones establecidas actualmente sean comprometidas o reversadas(comprometidas vía commit o reversadas vía rollback) y luego cierra la conexión de los usuarios. Luego de esto, baja la base de datos.

SQLPLUS> connect sys as sysdba
connected
SQLPLUS> shutdown transactional

3.- IMMEDIATE: Espera a que las transacciones actuales se completenEvita nuevas transacciones y nuevas conexiones. Los usuarios que intentan conectarse o los que ya están conectados al intentar realizar una nueva transacción reciben el mensaje "Shutdown in progress".El proceso PMON finaliza las sesiones no activas y realiza ROLLBACK de aquellas transacciones que no estén validadas.Cierra y desmonta la B.D. Cierra la SGA para los procesos background.No necesita recuperacion al arrancar la base de datos.


SQLPLUS> connect sys as sysdba
connected
SQLPLUS> shutdown immediate

4.- ABORT: Parada drástica, no espera a que los usuarios conectados actualmente finalicen sus transacciones. El usuario conectado recibe el mensaje "No logged on".No se realiza ROLLBACK de las transacciones pendientes.El proceso PMON finaliza las sesiones no activas y realiza ROLLBACK de aquellas transacciones que no estén validadas.SI necesita recuperacion al arrancar la base de datos.

SQLPLUS> connect sys as sysdba
connected
SQLPLUS> shutdown abort

¿Què son los tablespace del tipo unido, y como funcionan?


Un tablespace undo almacena información transaccional. El tablespace undo se usa para almacenar los segmentos de undo (similares a los segmentos de "rollback") y está diseñado para permitir la gestión automática de información de anulación. Aunque puede haber mas de un tablespace de undo por instancia, solo uno esta activo. Los segmentos de undo crecen o se encogen de acuerdo a las necesidades de las transacciones.


Se utiliza para:
• Rollback de las transacciones.
• Lectura consistente.
• Operaciones de recuperación de la base de datos.
• Funcionalidad de Flashback.

Se utilizan para gestionar poder deshacer las transacciones incompletas. En versiones anteriores se utilizaban los segmentos de Rollback para realizar esta tarea.

viernes, 3 de abril de 2009

Arquitectura de base de datos de Oracle

La arquitectura de Oracle incluye un número primario de componentes, los cuales son:
  1. Servidor Oracle: Hay varios archivos, procesos, y estructuras de memoria en un servidor Oracle, pero no todos ellos son usados cuando se procesa una instrucción SQL. Algunos son usados para mejorar el rendimiento de la base de datos, asegurando que la base de datos pueda ser recuperada en el evento de un error de software o de hardware, o ejecutar algunas tareas necesarias para la mantención de la base de datos. EL servidor Oracle consiste de una Instancia de Oracle y una base de datos Oracle.
  2. Instancia Oracle: Una instancia de Oracle, es la combinación de los procesos en segundo plano, y estructuras de memoria. La Instancia debe ser iniciada al accesar datos en la base de datos. Cada vez que una instancia es iniciada, una Area Global del Sistema (SGA) es asignada y los procesos en segundo plano de Oracle son iniciados. Los procesos en segundo plano realizan funciones en ayuda a los procesos invocados.
  3. Base de Datos de Oracle: Una base de datos en Oracle consiste de archivos del sistema operativo, conocidos como, archivos de base de datos, que proveen la actual información del almacenaje físico en la base de datos. Los archivos de base de datos son usados para asegurarse que los datos sean mantenidos de forma consistente y puedan recuperarse en el evento de una falla de la Instancia.
  4. Otros archivos claves: Archivos que no son de la base de datos, son usados para configurar la Instancia, autenticar los privilegios de usuarios, y recuperar la base de datos en el evento de una falla de disco.
  5. Procesos de Usuario y Servidor: Los procesos de usuario y servidor, son procesos primarios que son llamados cuando una instrucción SQL es ejecutada, no obstante, otros procesos pueden ayudar al servidor para que complete el procesamiento de la instrucción SQL.
  6. Otros Procesos: Muchos otros procesos existen y son usados por otros, tales como: Advanced Queuing, Real Applcation Clusters, Shared Server, Advanced Replication y más.

¿Qué es LISTENER?

Listener es un proceso servidor que provee la conectividad de red con la base de datos Oracle. El listener está configurado para escuchar la conexión en un puerto específico en el servidor de base de datos. 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 Toda la información del listener la contiene un archivo denominado listener.ora ( $ORACLE_HOME/network/admin. ) El comando para gestionar el listener es lsnrctl. Mediante este comando podemos:

  1. Parar el listener.
  2. Ver el estado del listener.
  3. Arrancar el listener.
  4. Rearrancar el listener.

SEGURIDAD LISTENER ORACLE 10G (securing the listener):

El principal paso para realizar la seguridad en el listener es ponerle una contraseña password. El primer método para poner una contraseña al listener es editando el fichero listener.ora y escribiendo la siguiente línea: PASSWORDS_LISTENER = orapass. Cuando guardemos el fichero con los cambios realizamos un reload del listener lsnrctl> reload

Nota: El comando para entrar en el listener es lsnrctl ( $ORACLE_HOME/bin )

El segundo método para poder cambiar la contraseña al listener es el siguiente: lsnrctl> change_password
Este comando te pedirá la clave antigua y la nueva clave.Si es la primera vez que ejecutas este comando la contraseña antigua ( old password ) habrá que dejarla en blanco.El comando SET y SAVE CONFIG permite guardar esos cambios en el listener porque ahora el listener está gobernado por un password.

  1. lsnrctl > set password
  2. lsnrctl > save config

La información antigua se guardará enlistener.bck y listener.ora se actualizará con los nuevos datos.
Ejemplo de configuración del listener.ora LISTENER9 =(DESCRIPTION_LIST =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = 193.168.4.220)(PORT = 2484)))))SID_LIST_LISTENER9 =(SID_LIST =(SID_DESC =(GLOBAL_DBNAME = orasite)(ORACLE_HOME = /oracle9/product/9.2.0)(SID_NAME = orasite)))

Parámetros del archivo:

  • HOST: Dirección ip del servidor de base de datos
  • PORT: Puerto de escucha de la base de datos ( por defecto suele ser el 1521 )
  • CLOBAL_DB_NAME: Nombre de la base de datos
  • ORACLE_HOME: Directorio de instalación de ORACLE ( ORACLE_HOME )
  • SID_NAME: SID de la base de datos ( muchas veces coincide con el GLOBAL_DB_NAME )

Este archivo incluye: Direcciones de protocolo en las que acepta solicitudes de conexión.Servicios de base de datosParámetros de control utilizados por el listener.

¿Qué es TNSNAME?

El TNSNAME es también llamado método LOCAL, indica que la resolución se hace a través de otro archivo de configuración llamado tnsnames.ora, residente en la misma ubicación.
Por ejemplo cuando queremos conectarnos a una base de datos REMOTA, debemos utilzar una red como vía de comunicación y una nomenclatura para saber con quién queremos comunicarnos. Esta nomenclatura es también llamada nombres de conexión (connection strings) ó alias en el ambiente Oracle.


Existen 3 métodos de resolución de nombres de conexión cuando se conecta un cliente a una BD. El método a utilizar se indica en el archivo $ORACLE_HOME/network/admin/SQLNET.ORA mediante el parámetro names.directory_path: names.directory_path = (TNSNAMES, HOSTNAME, ONAMES)

RESOLUCIÓN POR TNSNAMES.ORA ("LOCAL NAMING")

1.- Configurar el listener del servidor (listener.ora) para que dé servicio a cada una de las BDs de la máquina y arrancarlo. Configurar los clientes (tnsnames.ora) y probar la conexión a las BDs. Al configurar los clientes, la resolución de string de conexión por defecto es a través del archivo TNSNAMES.ORA: parámetro names.directory_path del fichero SQLNET.ORA: names.directory_path = (TNSNAMES, HOSTNAME, ONAMES)
Para ver cómo se crean los procesos servidores dedicados (si no se usa configuración MTS - Servidor compartido):

a) hacer telnet a VENTAS y conectarse con sql*plus ó conectarse a la base validando localmente, y desde sql*plus mirar los procesos que se han creado (el de usuario:sql*plus, y el proceso servidor dedicado (local=YES)); consultando la vista v$session y v$process. Utilizar el comando lsnrctl services y explicar resultado->no pasa por el listener, luego no se refleja la conexión en este comando.


b)conectarse en cliente/servidor a la BD y comprobar de nuevo los procesos (proceso cliente de sql*plus en el cliente, proceso servidor dedicado (local=NO)). Utilizar el comando lsnrctl services y explicar resultado, diferencias con el apartado a)->pasa por el listener, por lo que se refleja el establecimiento de conexión a través del servidor dedicado.

Si la base está configurada en modo compartido, forzar que los clientes se conecten por servidor dedicado en lugar de compartido. Esto se puede hacer de 2 formas:

En el tnsnames.ora del cliente crear un nuevo string de conexión igual que el ya existente para esta BD pero en la sección CONNECT_DATA añadir (SERVER=DEDICATED): VENTAS_DEDICADOS.world = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = 128.0.0.20) (Port = 1521) ) ) (CONNECT_DATA = (SID = orcl) (SERVER=DEDICATED) ) )
y comprobar la conexión a través de este nuevo alias-> irá por servidor dedicado en el sqlnet.ora del cliente añadir el parámetro USE_DEDICATED_SERVER=ON y comprobar cómo se realiza la conexión (usar el string de conexión inicial, no el anterior).

MÉTODO DE RESOLUCIÓN DE CONEXIÓN POR "HOST NAMING"

  1. No se puede usar Oracle Connection Manager, hay que usar TCP/IP, y resolución de direcciones por DNS/NIS/fich.hosts.
  2. Al configurar los clientes, indicar en primer lugar en el fichero SQLNET.ORA el método Host Naming para la resolución de string de conexión:
    names.directory_path = (HOSTNAME, TNSNAMES, ONAMES)
  3. En el servidor de BD hay que poner el global_dbname para cada BD (antes del SDI_NAME) en el listener.ora de la siguiente forma (en lugar de ORACLE_SID.DB_DOMAIN):
    global_dbname=
  4. En el cliente, añadir la dirección IP y el alias de la máquina a la que se quiere acceder (servidor de BD) en el fichero de hosts (si es que no existe DNS o NIS). Y para conectarse usar como string de conexión el nombre o dir.IP de la máquina servidor.