Administración de Base de Datos Oracle: febrero 2015

martes, 24 de febrero de 2015

Copias Inconsistentes de Base de Datos

Una copia inconsistente, online o caliente se realiza mientras la base de datos está en uso.
Un fichero de datos copiado de forma online no estará sincronizado con ningún SCN particular, se copia mientras está en uso, siendo leido por los procesos de servidor y escrito por DBWn. No es posible hacer una copia incosistente en modo <<noarchivelog>>.

Una base de datos puede permancecer abierta siempre y estar correctamente protegida por copias insonsistentes.

Existen varios pasos para hacer una copia inconsistente gestionada por el usuario:

-Copiar el controlfile
-Copiar los ficheros de datos, mientras estan en modo copia.
-Archivar los ficheros de redo log online

Para copiar el controlfile mientras la base de datos está abierta, tenemos 2 opciones:

ALTER DATABASE BACKUP CONTROLFILE TO 'fichero';
ALTER DATABASE BACKUP CONTROLFILE TO TRACE AS 'fichero';

El primer comando realiza una copia binaria byte a byte similar al controlfile actual: es una instantanea consistente en lectura del controlfile.

El segundo construye un comando CREATE CONTROLFILE y lo almacena en el script determinado por fichero. Está escrito en ASCII y puede editarse con cualquier editor de texto. Este script se puede utilizar mientras la instancia está en modo NOMOUNT para crear un nuevo controlfile con los mismos contenidos que el original del que fue generado.

Si no se especifica la clausula <<AS fichero>> se generará en el directorio <<USER_DUMP_DEST>> y su nombre vendrá determinado por el de la instancia y por el ID del proceso de servidor que atiende a nuestra sesión.

Los ficheros de datos antes de copiarlos, hay que ponerlos en modo copia con el siguiente comando:

ALTER TABLESPACE nombre_tablespace BEGIN BACKUP;

Este comando fuerza un checkpoint parcial. Todos los buffers del buffer caché que contienen bloques de fichero de datos del tablespace nombre_tablespace se escribirán en disco. Este comando, además, permite ajustar el mecanismo de generación de redo para los cambios que se apliquen en los bloques de esos ficheros de datos, ya que es necesario tener en cuenta la situacion en la que un bloque se modifica mientras se copia.

Nomenclatura estándar de Base de datos

Normas Generales

· Mantener nombres cortos y descriptivos.

· Mantener nombres de objetos únicos, por ejemplo evitar crear la tabla ALMACEN y un rol o vista con el mismo nombre.

· Por defecto, no se aceptan espacios en blanco en medio de los identificadores; sin embargo, su uso está permitido si se usan identificadores delimitados por comillas dobles. En el presente estándar, no se permiten los espacios en blanco como parte de un identificador.

· Para la definición de nombre de objetos de base de datos de acuerdo al caso se usará el caracter underscore “_” para separar las palabras_del_nombre.

Es recomendado el uso de una nomenclatura para los objetos de la base de datos de manera de mantener u orden dentro de ésta.

Algunos ejemplos de abreviaciones:

Tablas: aplicación del prefijo <TBL>

EJ: TBL_CLIENTES, TBL_PRODUCTOS

Procedimientos Almacenados: agregar el prefijo <SP>

ej: SP_INGRESACLIENTE, SP_ACTUALIZAFICHA

Funciones: agregar el prefijo <FN>

ej: FN_CALCULAVALOR, FN_CONVIERTEFECHA

Packages: agregar el prefijo <PKG>

ej: PKG_FICHAS, PKG_PRODUCTOS

Usuarios: agregar prefijo <USR>

ej: Juan Pérez = USR_JPEREZ

Triggers: agregar prefijo <TR>

ej: TR_ACTUALIZAPAGOS

Estás prácticas nos ayudaran a mantener un orden dentro de la base de datos y para diferenciar a los objetos contenidos en cada uno de los esquemas.

Duplicar una base de datos usando RMAN

Introducción

Se puede utilizar RMAN para duplicar una base de datos con el comando DUPLICATE a partir de los backups de la base de datos original manteniendo la base de datos original intacta. La base de datos duplicada (con nuevo DBID) será idéntica a la base de datos target o podrá contener solo una parte de la misma. Por otra parte, la base de datos target y la duplicada pueden estar en el mismo servidor o en servidores diferentes.

El uso que suele darse a la duplicación es:

Probar las copias de seguridad y sus recuperaciones.
Exportar datos que se hayan borrado accidentalmente de la base de datos original. Se puede exportar una tabla de la copia e importarla en la base de datos original.

Una base de datos duplicada no es igual que una base de datos Standby, aunque ambas se hayan creado con el comando DUPLICATE. La base de datos STANDBY es actualizada periódicamente con los Archived Redo Logs y en caso de caída de la principal puede ser utilizada como la base de datos primaria; una base de datos duplicada no.
Desde versión 10g de Oracle, el comando DUPLICATE realiza todas las operaciones necesarias para obtener una copia de una base de datos. Sin embargo, puede seguir usándose el procedimiento manual de versiones anteriores.

Arquitectura de la duplicación

El proceso de duplicación puede ser dividido en varias fases:

RMAN determina los backups necesarios para realizar la operación.
RMAN reserva los canales auxiliares para la instancia auxiliar.
RMAN restaura los ficheros de datos en la instancia auxiliar.
RMAN construye un nuevo fichero de control auxiliar.
RMAN restaura los ficheros de log archivados del backup (si es necesario) y realiza el recovery.
RMAN establece el DBID a la instancia auxiliar y abre la base de datos con la opción resetlogs.

Tareas básicas parala duplicación de base de datos

Para preparar la instancia auxiliar que RMAN utilizará durante el proceso de duplicación se deben realizar las siguientes tareas:
Crear un fichero de contraseñas para la instancia auxiliar
Seguir el procedimiento de administración usando el ejecutable orapwd. Por ejemplo:

> orapwd

Usage: orapwd file=<fname> password=<password> entries=<users> force=<y/n>

 where

  file - name of password file (mand),

  password - password for SYS (mand),

  entries - maximum number of distinct DBAs and OPERs (opt),

  force - whether to overwrite existing file (opt)

There are no spaces around the equal-to (=) character.

El siguiente comando crea un fichero de contraseñas denominado acct.pwd que permite la conexión de 30 usuarios privilegiados. La contraseña de los usuarios que se conecten como SYS será secret.

orapwd FILE=acct.pwd PASSWORD=secret ENTRIES=30

Comprobar la conectividad vía OracleNet a la instancia auxiliar

La instancia auxiliar debe ser accesible via Oracle Net. Antes de proceder a la duplicación se debe comprobar el acceso a la misma. La conexión ha de realizarse como SYSDBA por lo que el fichero de contraseñas debe existir.
Crear un fichero de parámetros de inicialización para la instancia auxiliar
Se debe crear un fichero de parámetros para la instancia auxiliar. Los parámetros mínimos requeridos son:
DB_NAME – El mismo nombre que el utilizado con el comando DUPLICATE de RMAN. No se puede usar el mismo nombre que la base de datos target si la duplicación se realiza en el mismo Oracle Home. Si la duplicación se realiza en diferentes Oracle Home, el nombre de la base de datos auxiliar no podrá ser el mismo que las que estén en ese home.
CONTROL_FILES – Se aplica de igual forma que en la creación de una base de datos nueva. Ha de cumplir las mismas condiciones.
DB_BLOCK_SIZE – Igual que en base de datos target.
DB_FILE_NAME_CONVERT – Se utilizará para establecer una nueva ruta o nombre a los ficheros de datos de la base de datos auxiliar.
LOG_FILE_NAME_CONVERT – Se utilizará para establecer una nueva ruta o nombre a los ficheros de log de la base de datos auxiliar.
Si no se establecen parámetros de conversión de nombres de ficheros se pueden usar los parámetros de gestión de OMF (Oracle Managed Files) DB_CREATE_FILE_DEST, DB_CREATE_ONLINE_LOG_DEST_n, or DB_RECOVERY_FILE_DEST. En este caso se podrá obviar el parámetro CONTROL_FILES, creándose los ficheros de control en la ruta OMF.
A continuación se muestra un fichero de parámetros de inicialización para la instancia auxiliar de una duplicación:

DB_NAME=newdb

CONTROL_FILES=(/dup/oracle/oradata/trgt/control01.ctl,

               /dup/oracle/oradata/trgt/control02.ctl)

DB_FILE_NAME_CONVERT=(/oracle/oradata/trgt/,/dup/oracle/oradata/trgt/)

LOG_FILE_NAME_CONVERT=(/oracle/oradata/trgt/redo,/dup/oracle/oradata/trgt/redo)

Una vez generado el fichero de parámetros de inicialización (init.ora) se ejecutará el comando CREATE SPFILE para crear el fichero de parámetros servidor (spfile.ora). Es muy importante crear este fichero de parámetros en la ruta por defecto para que RMAN lo encuentre cuando comience el proceso de duplicación. Un ejemplo de creación de este fichero podría ser:

CREATE SPFILE FROM PFILE='/tmp/initDUPDB.ora';

Arrancar la instancia auxiliar
Antes de que RMAN comience la operación de duplicación se debe hacer una conexión a la instancia auxiliar con SQL*Plus y arrancar la instancia (NOMOUNT). Por ejemplo:

CONNECT SYS/oracle@aux AS SYSDBA

STARTUP FORCE NOMOUNT

Montar y abrir la base de datos target
La base de datos target ha de estar montada y abierta:

SQL> CONNECT SYS/oracle@trgt AS SYSDBA;

STARTUP MOUNT;

Comprobar los backups precisos para la duplicación
Asegurar que todos los ficheros de datos del backup de la base de datos target son accesibles desde el servidor en el que está generada la instancia auxiliar. El backup puede ser completo, de ficheros individuales o incremental.
Por otra parte, los redo log archivados necesarios para hacer la duplicación a un punto en el tiempo deben estar accesibles desde el servidor en el que está duplicada la base de datos.
Reservar canales auxiliares si los canales automáticos no están configurados
Arrancar RMAN con una conexión a la base de datos target, a la instancia auxiliar y al catálogo de recuperación, si procede.

% rman TARGET SYS/oracle@trgt CATALOG rman/cat@catdb AUXILIARY SYS/oracle@aux

Si no hay canales automáticos configurados, deben ser reservados manualmente dentro del mismo bloque RUN en el que se realizará la duplicación de la base de datos. Por ejemplo:

RUN

  ALLOCATE AUXILIARY CHANNEL ch1 DEVICE TYPE sbt;

  ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;

  ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;

  ALLOCATE AUXILIARY CHANNEL aux3 DEVICE TYPE DISK;

  DUPLICATE TARGET DATABASE TO dupdb;

Duplicar una base de datos en servidor remoto con igual estructura de directorios

Este es el caso mas simple de duplicación de una base de datos. En este supuesto no es necesario cambiar la localización de los ficheros en el fichero de parámetros de inicialización.
Se realizarán las tareas previas descritas en el apartado anterior y se procederá a la duplicación.
El comando DUPLICATE de RMAN será ejecutado con la opción NOFILENAMECHECK (igual nombre de ficheros en origen y destino).

DUPLICATE TARGET DATABASE TO dupdb

  PFILE = /dup/oracle/dbs/initDUPDB.ora # si aplica

  NOFILENAMECHECK;

Duplicar base de datos en servidor remoto con diferente estructura de directorios

En este supuesto se debe tener en cuenta la generación de los nuevos nombres de ficheros en la nueva estructura de directorios.
Los nombres de los nuevos ficheros pueden establecerse por dos métodos: mediante el fichero de parámetros de inicialización o a través de comandos específicos de RMAN.
Método 1: Fichero de parámetros de inicialización
Se deben establecer los parámetros de inicialización con la nueva ruta en la que se duplicarán los ficheros: DB_FILE_NAME_CONVERT y LOG_FILE_NAME_CONVERT. A continuación se ejecutará el comando DUPLICATE de RMAN.
El siguiente ejemplo asume que los servidores origen y destino tienen capacidad para acceder a la misma unidad de cinta. En el ejemplo se duplica la base de datos usando un canal de tipo sbt automático y un fichero de parámetros servidor (spfile) localizado en el servidor en el que se generó la instancia auxiliar:

DUPLICATE

  TARGET DATABASE TO dupdb

  DEVICE TYPE sbt;

Método 2: Opciones AUXNAME y NEWNAME de RMAN
Otra posibilidad a la hora de renombrar los ficheros de la base de datos auxiliar es utilizar los comandos CONFIGURE AUXNAME o SET NEWNAME de RMAN.
El siguiente ejemplo utiliza canales preconfigurados y el fichero de parámetros servidor (SPFILE) para el proceso de duplicación:

RUN

  # establecer nuevos nombres a los ficheros

  SET NEWNAME FOR DATAFILE 1 TO '/dup/oracle/oradata/trgt/system01.dbf';

  SET NEWNAME FOR DATAFILE 2 TO '/dup/oracle/oradata/trgt/undotbs01.dbf';

  . . .

  # lanzar comando duplicate

  DUPLICATE TARGET DATABASE TO dupdb

  # crear grupos de redo log

  LOGFILE

    GROUP1

      '/dup/oracle/oradata/trgt/redo01a.log',

      '/dup/oracle/oradata/trgt/redo01b.log',

      '/dup/oracle/oradata/trgt/redo01c.log';

    ) SIZE 200K,

    GROUP2

      '/dup/oracle/oradata/trgt/redo02a.log',

      '/dup/oracle/oradata/trgt/redo02b.log',

      '/dup/oracle/oradata/trgt/redo02c.log';

    ) SIZE 200K,

    GROUP3

      '/dup/oracle/oradata/trgt/redo03a.log',

      '/dup/oracle/oradata/trgt/redo03b.log',

      '/dup/oracle/oradata/trgt/redo03c.log';

    ) SIZE 200K;

El siguiente ejemplo usa el comando CONFIGURE AUXNAME para establecer los nuevos nombres a los ficheros de datos. Usa fichero de parámetros servidor para la duplicación de base de datos y claúsula LOGFILE para especificar los nombres y tamaños de los ficheros redo log online.
Primero se ejecuta el comando CONFIGURE AUXNAME:

# establecer nuevos nombres a los ficheros

 CONFIGURE AUXNAME FOR DATAFILE 1

        TO '/dup/oracle/oradata/trgt/system01.dbf';

 CONFIGURE AUXNAME FOR DATAFILE 2

        TO '/dup/oracle/oradata/trgt/undotbs01.dbf';

# ... y mas hasta establecer todos los nombres necesarios

y posteriormente se ejecuta el comando DUPLICATE:

DUPLICATE TARGET DATABASE TO dupdb

# establecer fichero de parámetros si es preciso(si no hay SPFILE)

PFILE = /dup/oracle/dbs/initDUPDB.ora

# crear grupos de redo log online

 LOGFILE

    GROUP1

      '/dup/oracle/oradata/trgt/redo01a.log',

      '/dup/oracle/oradata/trgt/redo01b.log',

      '/dup/oracle/oradata/trgt/redo01c.log';

    ) SIZE 200K,

    GROUP2

      '/dup/oracle/oradata/trgt/redo02a.log',

      '/dup/oracle/oradata/trgt/redo02b.log',

      '/dup/oracle/oradata/trgt/redo02c.log';

    ) SIZE 200K,

    GROUP3

      '/dup/oracle/oradata/trgt/redo03a.log',

      '/dup/oracle/oradata/trgt/redo03b.log',

      '/dup/oracle/oradata/trgt/redo03c.log';

    ) SIZE 200K;

Tras la duplicación se deben eliminar las configuraciones de nombres de ficheros establecidas al efecto:

CONFIGURE AUXNAME FOR DATAFILE 1 CLEAR;

CONFIGURE AUXNAME FOR DATAFILE 2 CLEAR;

Duplicar una base de datos en el servidor local

Se debe seguir un procedimiento igual al utilizado para duplicar una base de datos en un servidor remoto con diferente estructura de directorios.
Dentro del mismo servidor, se puede duplicar la base de datos en el mismo Oracle Home cuidando que el nombre de la base de datos sea diferente al de la base de datos target.
Es muy importante NO USARLA CLAÚSULA NOFILENAMECHEK.Si se utiliza, el comando DUPLICATE puede sobreescribir los ficheros de datos de la base de datos target.

Operaciones realizadas por RMAN enla duplicación debase de datos

RMAN ejecutará las siguientes acciones como parte del proceso de duplicado:

Restaurará los ficheros de datos de la base de datos original en la base de datos duplicada y ejecutará una recuperación incompleta utilizando los backups y los Archived Redo Logs.
Parará e iniciará la base de datos duplicada.
Abrirá la base de datos duplicada con la opción RESETLOGS después de la recuperación incompleta. Exceptuando si la base de datos es STANDBY DUPLICATE… FOR STANDBY en cuyo caso RMAN no abrirá la base de datos.
Generará un nuevo y único DBID para la base de datos duplicada, a excepción de si es Standby.
Durante la duplicación RMAN ejecuta una recuperación incompleta puesto que los Redo Logs Online no están en las copias de seguridad y no pueden ser aplicados.

Opciones de duplicación

Cuando se duplica una base de datos se puede especificar las siguientes opciones:

Ejecutar el comando DUPLICATE con o sin un catálogo de recuperación.
Saltarse o no duplicar los tablespaces de sólo lectura con la opción SKIP READONLY. En la base de datos duplicada aparecerán estos tablespaces dentro del diccionario por si se desean activar más tarde. Ej. Un tablespace que sea un CD-ROM.

En la vista V$DATAFILE aparecerán estos tablespaces con los siguientes valores en las columnas:

STATUS = OFFLINE
ENABLED = READ ONLY
NAME = MISSING

En la columna STATUS de la vista DBA_DATA_FILES aparecerán con el valor AVAILABLE.
En la columna STATUS de la vista DBA_TABLESPACES aparecerán con el valor READ ONLY.

Saltarse tablespaces con la opción SKIP TABLESPACE. El único que no se puede saltar es el tablespace SYSTEM.

En la vista V$DATAFILE aparecerán estos tablespaces con los siguientes valores en las columnas:

STATUS = OFFLINE
ENABLED = READ ONLY
NAME = MISSING

En la columna STATUS de la vista DBA_DATA_FILES aparecerán con el valor AVAILABLE.
En la columna STATUS de la vista DBA_TABLESPACES aparecerán con el valor READ ONLY.

Crear la base de datos en una nueva máquina o host. Si la estructura de directorios es la misma se puede especificar la cláusula NOFILENAMECHECK y reutilizar los mismos nombres de los archivos para los ficheros de datos duplicados.
Usar el comando SET UNTIL o la cláusula UNTIL en el comando DUPLICATE para fijar el punto de recuperación incompleta. Por defecto, es el punto más reciente contenido en los archivos de backup y los Archived Redo Logs.
Registrar la base de datos duplicada en el mismo catálogo de recuperación puesto que RMAN genera un nuevo DBID durante la duplicación.

Comparación entre SQL SERVER y ORACLE

Sistemas operativos compatibles

Microsoft SQL Server ha sido siempre una parte de la familia de servidores Windows y hay pocas posibilidades de que Microsoft vaya a lanzar una versión para otro sistema operativo. En la actualidad, SQL Server se ejecuta en XP, Vista, Windows Server 2000, 2003 y 2008. La plataforma de base de datos está disponible para los de 32 bits y 64 bits de Windows.
Para el caso de Oracle, software de base de datos con soporte multiplataforma incluye no sólo Windows (32 bits y 64 bits), pero Linux y diferentes variantes de Unix (Solaris, HP-UX, AIX, etc) también.

Versiones y ediciones

En el momento de escribir esto, SQL Server 2008 es la versión actual del producto de base de datos de Microsoft. La próxima versión que saldrá es SQL Server 2008 R2 que se encuentra en su fase de CTP. La versión anterior, SQL Server 2005, vio una importante actualización de su predecesor, SQL Server 2000. SQL Server 2005 es todavía relativamente nueva para muchas empresas y hay todavía un gran número de organizaciones que utilicen bases de datos de SQL Server 2000.
Oracle por otro lado ha recorrido un largo camino desde sus primeros días y ahora está en la versión 11g R2. La versión más prominente de 10g R2 ha estado presente en el mercado por algún tiempo y es considerado un caballo de batalla. 10g es la primera versión de Oracle que introdujo el concepto de “grid computing”. Hay empresas que siguen utilizando Oracle 9i para sus aplicaciones de negocio.
En términos de ediciones de SQL Server 2008 R2 ofrece actualmente los siguientes:

Enterprise Edition: La edición Enterprise tiene todas habilitadas las características avanzadas y es apto para a gran escala, sitios de base de datos de alto volumen.
Standard Edition: Esto ofrece una plataforma asequible para las empresas que no requieren de las funciones avanzadas de la Enterprise Edition. La mayoría de las empresas suele desplegar sus bases de datos en los instancias de la edición estándar.
Workgroup Edition: La edición de grupo de trabajo es adecuada para pequeñas aplicaciones departamentales e incorpora las características esenciales del producto.
Web Edition: Esta es la destinada a ser utilizada por los proveedores de alojamiento como solución back-end de bajo coste para aplicaciones web.
Express Edition: motor del servidor SQL embebido que puede ser utilizados para el almacenamiento local de datos y sistema de desarrollo de pequeñas escala. La edición Express se puede descargar gratis y pueden ser distribuída gratuitamente con un software.
Compact Edition: La edición Compact permite a los usuarios desarrollar aplicaciones para computadoras de escritorio de Windows y dispositivos de mano.
Developer Edition: Todas las características de la versión Enterprise Edition está disponible en la edición para desarrolladores. Sin embargo, tiene licencia de uso por un usuario a la vez y está destinado a ser utilizado para fines de desarrollo y pruebas.

Aparte de la versión Enterprise Edition, SQL Server 2008 R2 también ofrecerá dos ediciones “premium” para los grandes centros de datos y data warehouses. Estas ediciones se llamarán Datacenter Edition y el Parallel Data Warehouse Edition, respectivamente.
Para Oracle 11g R2, los variantes son:

Enterprise Edition: Esta ofrece el máximo rendimiento por tu dinero. Al igual que el SQL Server Enterprise Edition, todas las características y las capacidades del producto están permitido en esta edición.
Standard Edition: Al igual que el estándar SQL Server Edition, la edición estándar de Oracle tiene habilitadas las principales características del producto y es adecuado para aplicaciones de negocios.
Standard Edition One: Esta edición está diseñada para pequeños grupos de trabajo y la licencia para un mñaximo de 5 usuarios.
Express Edition: En pequeña escala, base de datos inicial para fines de desarrollo y tiene licencia para redistribuirlo libremente. Express Edition 10g está todavía en la versión R2.

El siguiente cuadro muestra la comparación entre las distintas ediciones de SQL Server y Oracle:

SQL Server 2008 R2	Oracle Database 11g R2
Enterprise Edition	Enterprise Edition
Standard Edition	Standard Edition
Workgroup Edition	Standard Edition One
Edición Express	Express Edition
Web Edition	X
Compact Edition	X
Developer Edition	Enterprise Edition

Instancias, bases de datos y de tablas

Tal vez la primera diferencia de nivel entre la arquitectura de SQL Server y Oracle se encuentra en el concepto de instancias y bases de datos.
Una instancia en términos de SQL Server, significa un servicio de aplicación autocontenida que implica archivos del sistema operativo, las estructuras de memoria, los procesos de segundo plano y la información de registro. Una instancia está representada por un servicio en Windows y puede estar en ejecución o estado detenido. Cuando se ejecuta, una instancia ocupa una porción de la memoria del servidor, y también genera una serie de procesos de segundo plano.
Lo central de una instancia de SQL Server son sus bases de datos. Una base de datos de SQL Server es el repositorio de datos y el código del programa para la manipulación de esos datos. Si una instancia no se está ejecutando, las bases de datos dentro de ella no se puede acceder.
Hay dos tipos de bases de datos de SQL Server: bases de datos de sistema y de bases de datos de usuario. Cuando una instancia de SQL Server se instala por primera vez, cinco bases de datos del sistema se crean: model, tempdb, master, msdb y resource. Si existe más de una instancia de SQL Server que se ejecuta en un equipo, cada instancia tendrá su propio grupo dedicado de bases de datos del sistema. Una instancia no puede iniciar si cualquiera de sus bases de datos del sistema, excepto msdb esta inaccesible o está dañada. Las bases de datos del usuario por otro lado son creadas por desarrolladores y administradores de bases después que la instancia se ha instalado y el sistema de bases de datos ha iniciado. Estas son las bases de datos que almacenan la información de negocios de las organizaciones.
Así pues, en definitiva, una instancia de SQL Server siempre incluye bases de datos (incluso si sólo están las del sistema) y una base de datos estará siempre asociado con una (y sólo una) instancia.
En el nivel físico, una base de datos de SQL Server está representada por un conjunto de archivos del sistema operativo que residen en el sistema de disco del servidor. Hay dos tipos de archivos de base de datos: el archivo de datos (data file) y el archivo de registro de transacciones (transaction log file). Como mínimo, una base de datos tendrá un archivo de datos y un archivo de registro de transacciones. Un archivo de datos es el repositorio central de información en una base de datos SQL. Un archivo de registro de transacciones de otro lado registra los cambios que se han aplicado a los datos. Este archivo es requerido por SQL Server para la recuperación del sistema. Un archivo de datos o de registro siempre pertenecen a una determinada base de datos: no hay dos bases de datos pueden compartir los mismos datos o archivo de registro. Si la base de datos es grande, puede tener múltiples archivos de datos. Múltiples archivos de datos de en una base de datos puede ser lógicamente agrupadas en estructuras conocidas como grupos de archivos.
Con Oracle, las cosas funcionan en la dirección inversa. Cuando Oracle se inicia, funciona igual que SQL en que una porción de la memoria del servidor se asigna para su funcionamiento. Esta área de memoria, conocido como el Área Global de Sistema (SGA), se divide en una serie de estructuras diferentes. Junto con el espacio de memoria, una serie de procesos de fondo que también se inician para interactuar con el SGA. En conjunto, el espacio de memoria y los procesos constituyen una instancia de Oracle. Tenga en cuenta que la base de datos Oracle todavía no está presente. De hecho, una instancia de Oracle podría estar funcionando perfectamente bien sin su base de datos en línea o incluso ser accesible. Cuando instalas Oracle, hay una opción para instalar sólo el software y crear la base de datos más tarde.
Una base de datos en Oracle es una colección de archivos de sistema operativo. A diferencia de SQL Server, una base de datos Oracle no representan a la agrupación lógica de los objetos, sino que es un único término genérico para una serie de archivos en el disco que principalmente tienen datos.
Los archivos que componen una base de datos de Oracle se pueden clasificar en tres tipos: el archivo de datos (data file), archivo de rehacer (redo log file) y el archivo de control (control file). Los archivos de datos es donde residen todos los datos. Puede haber cualquier número de archivos de datos en una base de datos de Oracle. Archivos Rehacer son como los archivos de registro de transacciones de SQL Server que registra que cada cambio realizado a los datos y se utiliza para la recuperación del sistema. Los archivos de control son un tipo especial de archivo que contiene pequeñas piezas de información vital acerca de la base de datos. Sin este archivo, la instancia no será capaz de abrir la base de datos.
Aparte de los archivos de datos, archivos rehacer y los archivos de control, la base de datos contendrá también un archivo de parámetros , y un archivo de contraseñas, opcionalmente,archivos de registro de archivado (archive log file). Vamos a discutir acerca de cada tipo de archivos de base de datos Oracle en breve.
Cuando se inicia un sistema de Oracle, primero la instancia se crea en la memoria. La instancia a continuación, se conecta a la base de datos que residen en el disco y, finalmente, se abre la base de datos para la interacción del usuario. Cuando el sistema se apaga, la instancia se borrará de la memoria: todas las estructuras de memoria y los procesos se terminan, pero la base de datos todavía existen en el disco, aunque en un estado cerrado. Como se dijo anteriormente, es posible tener la instancia de Oracle que se ejecutan sin necesidad de abrir la base de datos – es una gran diferencia de SQL Server donde una instancia no puede comenzar sin primero tener sus bases de datos de sistemas en línea. Sin embargo, como SQL Server, es imposible conectarse a una base de datos de Oracle, si la instancia no ha comenzado.
En general, la relación entre una instancia de Oracle y su base de datos es uno a uno. Una instancia tendrá una base de datos asociada con ella. Una base de datos por otra parte puede tener una o más instancias para acceder a ella. Una instalación independiente de Oracle constará de una única instancia de acceso a una base de datos única. Las instalaciones de Oracle configuradas como RAC (Real Application Cluster) tendrán varias instancias que se ejecutan en diferentes máquinas que acceden a la misma base de datos en un disco compartido.
Entonces, ¿dónde está la agrupación lógica de los objetos de base de datos Oracle? En SQL Server, esta agrupación lógica es realizada por la propia base de datos. Para Oracle, se realiza a través de algo llamado espacios de tablas (tablespaces). Un espacio de tablas de Oracle es una estructura lógica que agrupa a las tablas, vistas, índices y otros objetos de la base de datos. Por ejemplo, la base de datos Oracle de producción puede tener uno de tablas dedicado a la aplicación de recursos humanos y otro de tablas para la nómina. Cada espacio de tablas está físicamente representado por uno o más archivos de datos en el disco y forma parte de la base de datos. La base de datos es, lógicamente, compuesto de una serie de espacios de tabla y los espacios de tabla, a su vez están físicamente compuesto de uno o más archivos de datos.

El equivalente de Oracle para las base de datos de SQL Server es un espacio de tablas.

Y puesto que son tan similares en sus funciones, el proceso de creación de una base de datos en SQL Server es muy similar a la creación de un espacio de tablas en Oracle. Cuando se crea una base de datos o de un espacio de tablas, el DBA debe especificar un nombre. El DBA asigna uno o más archivos de datos a la base de datos o tablas de espacios y especifica el tamaño inicial y los incrementos de crecimiento de cada archivo.
Al igual que una base de datos de usuario de SQL Server se puede poner fuera de línea o de sólo lectura, también se puede en un espacio de tablas de usuario de Oracle. Y al igual que uno o más archivos de datos en una base de datos de usuarios de SQL Server puede ser de sólo lectura, uno o más archivos de datos en un espacio de tablas de usuarios de Oracle pueden ser marcados fuera de línea.
Sin embargo, las bases de datos y de tablas difieren entre sí en las siguientes puntos:

En SQL Server, los archivos de datos puede ser, lógicamente, agrupados en grupos de archivos. Los espacios de tablas de Oracle no tienen este concepto.
En las bases de datos SQL Server, cada base de datos tendrá su propio registro de transacciones y las propiedades del archivo de registro deberá ser especificado durante la creación de bases de datos. Para Oracle, las transacciones de la base de datos completa (esto significa que por cada espacio de tablas) se registran en un registro rehacer (redo log). Por consiguiente, no existe ninguna disposición para crear archivos de registro individuales para espacios de tablas.
Para SQL Server, la base de datos puede ser creada con el modo de recuperación simple. El modo de recuperación simple: la parte inactiva del registro de base de datos se trunca después de cada punto de control. Oracle tiene un concepto similar, que veremos más adelante – pero no es posible configurar esa propiedad para espacios de tablas individuales.

Los nombres de instancia vs SID

Ambos SQL Server y Oracle permiten ejecutar simultáneamente varias instancias del software servidor en el mismo equipo. Estos múltiples contextos de ejecución son totalmente independientes unos de otros: en lo que se refiere a un motor de base de datos, no sabe ni le importa si otro se está ejecutando en el mismo equipo.
En SQL Server, este mecanismo se activa a través del concepto de instancias. SQL Server puede funcionar tanto como una instancia nombrada o como una instancia predeterminada. La instancia predeterminada tiene el mismo nombre que el servidor de Windows que lo hospeda. Obviamente, puede ser acogida una sola instancia predeterminada, pero es posible ejecutar varias instancias nombradas en esa misma máquina. Una instancia con nombre se identifica en la forma de HOSTNAME\INSTANCE_NAME, donde cada INSTANCE_NAME ejecutándose en la máquina tiene que ser único. Cada instancia tendrá su propio conjunto de archivos binarios con algunos componentes comunes y compartidos entre todos.
Para Oracle, funciona de la misma manera. Cuando se instala Oracle, el DBA debe especificar un nombre global de base de datos (Global Database Name) y un identificador del sistema (SID). La instancia y bases de datos son entidades completamente separadas en Oracle. Un nombre de base de datos global identifica unívocamente a una base de datos en la red donde se encuentra alojada y puede tener un nombre completo en la forma de database_name.network_domain_name. Un SID por otra parte identifica la instancia asociada con la base de datos. En la mayoría de los casos una sola instancia se asocia a una única base de datos, el SID y el nombre de base de datos será el mismo. Los entornos de Oracle Real Application Cluster (RAC) son una excepción: RAC permite que múltiples instancias accedan a la misma base de datos alojada en un almacenamiento compartido; los nombres de instancia son diferentes del nombre de base de datos en estos casos. Sin embargo, al igual que un equipo de SQL Server, un servidor de base de datos Oracle no puede tener dos instancias en ejecución con el mismo SID.
Un DBA de SQL Server puede ejecutar la siguiente consulta para saber el nombre de la instancia a la que está actualmente conectado a:

SELECT @@SERVERNAME

Un DBA Oracle ejecutar consultas como la siguiente para obtener la instancia y el nombre de base de datos:

SELECT INSTANCE_NAME, HOST_NAME, VERSION, DATABASE_STATUS FROM V$INSTANCE;

SELECT NAME, DATABASE_ROLE, CREATED FROM V$DATABASE;

Sistema de bases de datos y sistema de tablas

Una instancia de SQL Server dispondrá de cinco bases de datos de sistema (cuatro para las versiones anteriores de 2005) presente: master, model, msdb, tempdb y resource. Una base de datos Oracle necesita un mínimo de tres espacios de tablas de sistema para su funcionamiento: SYSTEM , SYSAUX y TEMP.
Las base de datos master y resource son los repositorios centrales de toda la información de SQL Server para gestionar las necesidades de sí mismo. Entre muchas otras cosas, contiene la configuración de su sistema, la lista de bases de datos y la ubicación de sus archivos, puntos finales, servidores vinculados y las cuentas de usuario (o “logins”). Objetos de nivel de sistema se almacenan en una base de datos de sólo lectura conocida como base de datos “resource”.
Para Oracle, el espacio de tablas del sistema es el equivalente de la base de datos master. El espacio de tablas SYSTEM contiene el diccionario de datos, que son los metadatos de Oracle sobre sí misma. El diccionario de datos se puede comparar con la base de datos de recursos de SQL. Y probablemente ya has adivinado: Oracle no se iniciará si el espacio de tablas del sistema no está disponible o está dañado.
Para una instancia de SQL Server, la base de datos model es la “plantilla” que se utiliza para crear cada nueva base de datos en esa instancia. Se puede realizar un cambio en la base de datos model y el cambio se reflejará después en cada nueva base de datos creada. Para Oracle, no existe tal modelo, pero cuando se crea un espacio de tablas, puede especificar si será un espacio de tablas permanente o de cualquier otro tipo como un espacio de tablas TEMP o UNDO. Los espacios de tablas permanentes son los que contienen datos de usuario.
Tempdb de SQL Server se utiliza como una “scratch pad” para la instancia en su conjunto. Tempdb se crea cada vez que la instancia se reinicia y destruyó cada vez que la instancia se cierra. Los espacio de tablas TEMP de después hacen más o menos la misma tarea: se utiliza para ordenar los resultados que tienen operaciones a gran escala. Sin embargo, tempdb de SQL también se puede utilizar para versionado de filas. Cuando se activa para una base de datos, el versionado de filas asegura que el motor de base de datos mantiene un registro de cada versión de una fila de datos cuando se modifican. El copia pre-modificada de la fila es copiada en un almacén de versiones en la base de datos tempdb. Las consultas solicitando la fila de datos siempre tendrán la última versión confirmada. Cuando una operación de lectura utiliza un nivel de aislamiento basado en versionado de filas, no bloquea otras transacciones que intentan modificar los mismos datos. Esto es porque la consulta de lectura no pone un bloqueo compartido en las filas de datos. Sin embargo, este comportamiento debe ser explícitamente habilitado para cada base de datos.
Oracle utiliza el mismo concepto con otro tipo de espacios de tablas – conocido como el espacio de tablas UNDO. Un espacio de tablas UNDO tiene la posibilidad de copiar lecturas consistentes de datos que están siendo modificadas por una declaración DML. Cuando un usuario comienza a hacer cambios a los datos, una versión previa a la modificación de los datos es almacenada en el espacio de tabla UNDO. Si otro usuario desea consultar las mismas filas de los datos, obtendrá la versión previa a la modificación desde el espacio de tabla UNDO. A diferencia de SQL, esta función no tiene que ser activada explícitamente – es parte del mecanismo de acceso concurrente a datos de Oracle.
Por último, la base de datos msdb de SQL Server es necesaria para el funcionamiento de su servicio de Agente. El Agente SQL Server es el responsable de los trabajos programados, alertas, la replicación y el trasvase entre muchas otras cosas. Sin la base de datos msdb, el servicio del agente no se ejecuta.
No existe un equivalente claro de msdb en Oracle. El espacio de tablas SYSAUX es un espacio de tablas del sistema, creado durante el proceso de instalación. Contiene información como el Repositorio de Carga de Trabajo Automático (AWR) de Oracle, datos espaciales y multimedia, bases de datos XML, etc

Funciones que desempeña un DBA

Instalación de nuevos componentes del software
Una de las tareas principales del DBA consiste en la instalación periódica de nuevas actualizaciones de software de Oracle, tanto en lo referente a programas de aplicaciones como a herramientas administrativas. También es recomendable que el propio DBA y otros usuarios de Oracle prueben la instalación y nuevas configuraciones antes de migrarlas a los ambientes de producción.
Interacción con el administrador del sistema
En la mayoría de los casos los programas sólo pueden ser instalados o accedidos por el administrador del sistema. En este caso, el DBA debe trabajar siempre muy bien coordinado con él para garantizar que tanto la instalación y configuración de software como de hardware permita un adecuado funcionamiento del motor de base de datos y de las aplicaciones.
Garantizar la seguridad del sistema
El DBA debe siempre monitorear y administrar la seguridad del sistema. Esto involucra la incorporación y eliminación de usuarios, administración de espacios de disco (cuotas), auditorias y una revisión periódica para detectar probables problemas de seguridad.
Monitorización
El DBA debe monitorear continuamente el rendimiento del sistema y estar preparado para efectuar ajustes de sintonización de éste. En ciertas oportunidades esto involucra cambiar sólo algunos parámetros y otras veces reconstruir índices o reestructurar tablas.
Respaldos
Debido a que la tarea más importante del DBA es proteger la integridad de los datos, se deberá desarrollar una estrategia efectiva de respaldos y recuperación de datos para mantener la estabilidad de toda la información guardada. Las frecuencias de estos respaldos deberán decidirse dependiendo de la cantidad de procesos que alteran los datos a través del tiempo.
Prevención de riesgos
Otra tarea del DBA es la de calendarizar mantenciones a las bases de datos (archivos lógicos) o cooperar en el mantenimiento de las máquinas al administrador del sistema. El DBA debe fortalecer sus esfuerzos en orden a eliminar problemas o situaciones potencialmente peligrosas.

TAREAS ADICIONALES DEL DBA

Otras tareas de importancia que corresponden con frecuencia realizar a un DBA son:

Analizar datos y efectuar recomendaciones concernientes a mejorar el rendimiento y la eficiencia en el manejo de aquellos datos que se encuentran almacenados.
Apoyar en el diseño y optimización de modelos de datos.
Asistir a los desarrolladores con sus conocimientos de SQL y de construcción de procedimientos almacenados y triggers, entre otros.
Apoyar en la definición de estándares de diseño y nomenclatura de objetos.
Documentar y mantener un registro periódico de las mantenciones, actualizaciones de hardware y software, cambios en las aplicaciones y, en general, todos aquellos eventos relacionados con cambios en el entorno de utilización de una base de datos.

Glosario de Términos de DBA Oracle

La siguiente es una lista de los términos más utilizados cuando se trabaja con bases de datos Oracle. Las definiciones ayudarán a comprender con mayor claridad algunos conceptos técnicos.

Administrador de Base de Datos
El administrador o DBA es el principal responsable de la operación, configuración y rendimiento de una base de datos. Su principal tarea consiste en resguardar la integridad de los datos almacenados en la base, proveyendo para esto mecanismos de respaldo, efectuando monitorizaciones periódicas al sistema, implementando medidas de seguridad, etc. Bloque
Un bloque es la unidad más pequeña de almacenamiento en una base de datos Oracle. El tamaño mínimo es de 2 KB y el máximo no debiera superar los 16 KB.
Buffer
Este término se refiere a una cantidad de memoria utilizada para almacenar información.
Un buffer comúnmente almacena datos que están a punto de ser usados o se acaban de
utilizar recientemente. En la mayoría de los casos son copias exactas de datos que se encuentran almacenados en el disco y se mantienen en memoria con el fin de lograr un acceso más rápido y ayudar de esa manera a mejorar el rendimiento de un sistema.
En Oracle, los buffers del SGA almacenan los bloques de datos usados más recientemente.
El conjunto de buffers que guardan estos bloques reciben el nombre de database buffer cache; y aquellos que se utilizan para guardar temporalmente las entradas del tipo redo log hasta que se escriben en el disco, se conocen como redo log buffers.
Caché
Es un área de almacenamiento implementada en la memoria RAM del computador que
permite accesos más rápidos a la información ya que es mucho más veloz que la memoria.
En Oracle, los buffers de bloques y el área shared pool son consideradas áreas caché. Estas guardan los datos que se utilizan con mayor frecuencia y los mantienen disponibles por si son requeridos en los procesos de consulta hasta que nuevos datos más frecuentemente usados los reemplazan.
Checkpoint
Un checkpoint es una operación que fuerza a que todos los cambios registrados en bloques de datos en memoria, sean escritos en el disco.
Clean buffer
Un buffer de este tipo es aquel que no ha sido modificado y que por lo tanto el proceso DBWR no utilizará para confirmar los cambios en el disco (porque no ha sufrido cambios).
Concurrencia
Este término se refiere a la capacidad de permitir muchas funciones al mismo tiempo.
Oracle provee a muchos usuarios el acceso simultáneo a sus servicios, implementando de esta forma la concurrencia.
DBA
DBA Significa Administrador de la Base de Datos, en inglés. Concepto manejado líneas arriba.
DBMS
El database management system o DBMS corresponde al software y grupo de herramientas que permiten manejar la base de datos. Un RDBMS es un DBMS relacional, es decir, cuya naturaleza es la formación de relaciones al interior del mismo.
DDL (comandos DDL)
Los comandos DDL (data definition language) son utilizados en la creación y modificación de objetos del esquema. Proveen la habilidad de crear, alterar e incluso eliminar objetos de un esquema, otorgar y revocar privilegios y roles a los usuarios, establecer opciones de auditoria e incluso agregar comentarios al diccionario de datos del sistema. Estos comandos están estrechamente relacionados con las labores de administración de la base de datos.
Diccionario de Datos
El diccionario de datos es un grupo de tablas de Oracle que se utilizan para almacenar información sobre el resto de las tablas, índices, clusters y otros objetos de la base de datos.
DML (comandos DML)
Los comandos DML (data manipulation language) son menos poderosos que los comandos
DDL en cuanto a administración se refiere, de hecho, implementan modificaciones sobre la información que se guarda en los objetos de una base de datos. Estas sentencias son del tipo DELETE, INSERT, SELECT y UPDATE, principalmente.
Esquema
Un esquema es una colección de objetos asociados dentro de una base de datos.
Función Una función es un grupo de sentencias SQL, escritas generalmente en PL/SQL que implementan una serie de rutinas que devuelven un valor. Son casi idénticas a los procedimientos y sólo se diferencian en esa última condición. Implementando funciones en el servidor de base de datos se reduce el tráfico de comunicaciones en la red, ya que sólo se envían a la función los parámetros de entrada y ésta sólo devuelve el valor al final de todo el proceso, el que es ejecutado en la misma máquina donde reside la base de datos mejorando así el rendimiento general del sistema.
Memoria Virtual
Indica la memoria que puede ser utilizada por programas que corren en un sistema
operativo y que está implementada físicamente en sectores del disco y no en la RAM. El proceso de copiar datos de la RAM al disco (o memoria virtual) se llama paginación (paging, en inglés). El archivo resultante es llamado el “swap file” y cada vez que un programa accede a esta memoria virtual disminuye el rendimiento del mismo debido a que realmente está accediendo al disco y no a la RAM.
Procedimiento
Un Procedimiento almacenado es un grupo de sentencias SQL o PL/SQL que implementan
un programa que se ejecuta en el servidor de base de datos, pero que a diferencia de las funciones, no devuelve un valor. Al igual que las funciones su implementación permite reducir el tráfico en la red, potenciando el rendimiento del sistema.
Query
Es una consulta efectuada contra la base de datos en lenguaje SQL. Se genera utilizando la sentencia SELECT. Su principal característica es que no efectúa cambios en la base de datos; por este motivo es llamada también una transacción de sólo lectura.
System Global Area (SGA)
El SGA es un área compartida de memoria que utiliza Oracle para guardar información de control en una instancia. Se asigna un espacio a esta área en cuando la instancia se levanta (startup) y se elimina cuando ésta se baja (shutdown). Cada instancia de Oracle maneja su propia SGA y guarda información de los buffers y la shared pool.
Tablas de rendimiento dinámicas
Estas tablas son creadas cuando se levanta una instancia y se usan para guardar información acerca del rendimiento de ésta. Esta información incluye notas acerca de la conexión, datos que manejan los procesos de entrada/salida, valores de los parámetros de inicialización, entre otros.
Transacción
Una transacción es una unidad lógica de trabajo que consiste de una o más sentencias SQL, que pueden finalizar con un commit o un rollback. Las métricas de rendimiento utilizan comúnmente las unidades “transacciones por segundo” o “transacciones por minuto”.
Trigger
Un trigger es un mecanismo que permite escribir procedimientos que son ejecutados en forma automática (sin una orden explícita del usuario o programador) cuando ocurre un evento de INSERT, UPDATE o DELTE sobre una tabla o vista. Generalmente se utilizan los triggers para forzar las restricciones de integridad entre las tablas o automatizar alguna otra función específica.

Clonar una base de datos Oracle usando DBCA

Clonar una base de datos con DBCA es uno de los métodos mas rapidos y eficaces.A continuación se mencionan los pasos a seguir para clonar una base de datos en Oracle 11G.

Inicia el Database Configuration Assistant (DBCA). Se encuentra en Todos los programas :: Oracle – OracleDb10g_home1 :: Configuration and Migration Tools :: Database Configuration Assistant. También puede ser invocado al escribir “dbca” desde el símbolo del sistema.
En la pantalla “Welcome” haz clic en el botón “Next”.
En la pantalla “Operations” selecciona la opción ” Manage Templates” y haz clic en el botón “Next”.
En la pantalla “Manage Templates” selecciona la opción “Create a database template” y seleccione la sub-opción ” From and existing database (structure as well as data)” y haz clic en el botón “Next”.
En la ” Source database” pantalla de selección de la instancia de base de datos correspondiente y haga clic en el botón “Next”.
En la pantalla “Template properties” introduce un nombre adecuado y una descripción para la plantilla, confirma la ubicación de los archivos de la plantilla y haz clic en el botón “Next”.
En la pantalla ” Location of database related files” elige entre mantener la ubicación de los archivos (maintain the file locations) o convertirlos a la estructura OFA (convert to OFA structure), la segunda es la recomendada y luego haz clic en el botón “Finish”.
En la pantalla “Confirmation” haz clic en el botón “Ok”.
Espere mientras el asistente la barra de progreso va avanzando y recoge información sobre la base de datos origen, respalda la base de datos y crea la plantilla.
Dependiendo del tamaño de la base de datos esto tomará algún tiempo. Para mi base de datos de 8GB, tomó alrededor de 8 minutos. Ahora tenemos la plantilla creada, la cual usaremos para crear nuestra base de datos.
Haz clic en la “Next Operation”.
Selecciona “Create a Database” y haz clic en “Next”.
En “Select a template from the following list to create a database” selecciona el nombre de la plantilla que ingresastes en el paso 6 y haz clic en “Next”.
Proporciona el nombre del nuevo servicio para la nueva base de datos. El SID se ajustará automáticamente al nombre del servicio ingresado. Haz clic en “Next”.
Deja marcadas las opciones “Configure the Database with Enterprise Manager” y “Use Database Control for Database Management”. Haz clic en “Next”.
Proporciona una contraseña para SYS y haz clic en “Next”.
Deja marcada la opción “File System” a menos que desees utilizar ASM o RAW para tu nueva base de datos.
Deja marcado “Use Database File Locations from Template”. Esto es importante. Haz clic en “Next”.
Deja como están los valores por defecto para “Flash Recover Area” y haz clic en “Next”.
Deja como esta “No Scripts to run” y haz clic en “Next”.
Puedes mantener los valores por defecto para la memoria (Memory) y tamaño (Sizing) o modificarlas según tus necesidades y haz clic en “Next”.
Ahora estas en la pantalla final en donde puedes ver todas las configuraciones y verificar que estén correctas. Haz clic en “Next”, DBCA hará todo el trabajo y tu base de datos debe estar en funcionamiento en los próximos 15 a 20 minutos.
Por último antes de ingresar a la nueva base de datos con EM, Revisa el tnsnames.ora y mira si se ha creado una entrada para la nueva base de datos de lo contrario agrega una. Debes agregar un nuevo listener en tu listener.ora. Luego si quieres hacer un “lsnrctl reload” para volver a cargar los listeners.
Por último haz un tnsping a tu nueva base de datos para comprobar todos está bien.
Inicia sesión usando EM y debes tener lista tu DB en modo Open.
Ten en cuenta que todas las cuentas de usuario, además de la cuenta del sistema están bloqueadas y expiradas por lo que necesitas desbloquearlas para permitir a los usuarios conectarse a la nueva base de datos.

Desbloqueo de Usuarios de BD Oracle

Mediante la tabla dba_users podemos ver los usuarios bloqueados filtrando por los que el atributo lock_date no sea null:

SQL> select username,account_status from dba_users where lock_date is not null;

USERNAME         ACCOUNT_STATUS
------------------------------ --------------------------------
SYSTEMADMIN         LOCKED(TIMED)

(...)

9 rows selected.

Una vez identificado el usuario bloqueado, lo podremos desbloquear mediante account unlock:

SQL> alter user SYSTEMADMIN account unlock;

User altered.

Podemos ver como el account_status cambia de “LOCKED(TIMED)” a “OPEN“:

SQL> SELECT username, account_status FROM dba_users;

USERNAME         ACCOUNT_STATUS
------------------------------ --------------------------------
SYSTEMADMIN                OPEN

(...)

42 rows selected

Funciones de Seguridad y Gestión de Contraseñas en Oracle

Los perfiles tienen la doble función de establecer politicas de contraseñas y restringir los recursos que una sesión puede obtener.
Para habilitar el control de recursos, el parámetro RESOURCE_LIMIT debe estar establecido a TRUE (por defecto está en FALSE). Los perfiles estan habilitados automaticamente, aunque el perfil por defecto habilitado tiene pocas restricciones.

GESTION DE CONTRASEÑAS
Los parámetros mediante los que se puede aplicar limites a las contraseñas son:

FAILED_LOGIN_ATTEMPTS: Numero de errores consecutivos en la contraseña antes de que se bloquee la cuenta. Si se introduce la contraseña correcta antes de alcanzar el limite, el contador se resetea a cero.

PASSWORD_LOCK_TIME: Numero de dias de bloqueo de la cuenta cuando se alcanza el limite FAILED_LOGIN_ATTEMPTS.

PASSWORD_LIFE_TIME: Numero de dias antes de que la contraseña expire. Se podrá utilizar la contraseña mas allá de este tiempo si se establece el parámetro PASSWORD_GRACE_TIME.

PASSWORD_REUSE_TIME: Numero de dias antes de que la contraseña se pueda usar nuevamente.

PASSWORD_REUSE_MAX: Numero maximo de veces que una contraseña se pueda usar de nuevo.

PASSWORD_VERIFY_FUNCTION: Nombre de la función a ejecutar cada vez que se cambia la contraseña, para añadir un mayor nivel de complejidad en la evaluación de la misma.

LIMITES DE RECURSOS
Podemos aplicar los siguientes limites en el uso de recursos,tambien conocidos como limites de Kernel.

SESSIONS_PER_USER: Numero de logins concurrentes que pueden establecerse para el mismo usuario.

CPU_PER_SESSION: Tiempo de cpu (en centesimas de segundo) que un proceso de servidor que atiende una sesion puede usar antes de una finalizacion forzosa.

CPU_PER_CALL: Tiempo de cpu (en centesimas de segundo) que un proceso de servidor que atiende una sesion puede usar para ejecutar una sentencia SQL antes de que la sentencia finalice de manera forzosa.

LOGICAL_READS_PER_SESSION: Numero de bloques que pueden ser leidos por la sesión (del disco o del buffer caché) antes de que la sesion sea forzada a terminar.

LOGICAL_READS_PER_CALL: Numero de bloques que pueden ser leidos por una unica sentencia (del disco o del buffer cache) antes de que la sentencia finalice de manera forzosa.

PRIVATE_SGA: Para sesiones conectadas a traves de la arquitectura de servidor compartido (shared server), numero de kilobytes que una sesion puede tener en la SGA para datos de sesión.

CONNECT_TIME: Duración máxima en minutos de una sesión antes de que finalice de forma forzosa.

IDLE_TIME: Duración máxima en minutos de una sesión que puede estar inactiva antes de que finalice de manera forzosa.

COMPOSITE_LIMIT: Suma ponderada de varios recursos (CPU_PER_SESSION,CONNECT_TIME,LOGICAL_READS_PER_SESSION, PRIVATE_SGA) a alcanzar por una sesión antes de que finalice de manera forzosa.

Roles Predefinidos en Base de datos Oracle 11G

Existen a lo menos 50 roles predefinidos en una base de datos Oracle dependiendo de las opciones que se instalen. Los mas importantes y usados son:

CONNECT: Solo existe por compatibilidad con versiones anteriores en las que se incluian privilegios para crear objetos como tablas. Ahora solo incluye el privilegio CREATE SESSION.

RESOURCE: Puede crear objetos que almacenen datos (como tablas) y objetos procedimentales (como procedimientos PL/SQL). También incluye UNLIMITED TABLESPACE.

DBA: Tiene la mayoria de los privilegios de sistema, privilegios sobre objetos y roles. Un usuario con el rol de DBA puede manejar todos los aspectos de la base de datos, excepto el arranque y parada de la misma.

SELECT_CATALOG_ROLE: Tiene sobre 2000 privilegios sobre objetos del diccionario de datos, pero no privilegios de sistema o privilegios sobre datos de usuario.

SCHEDULER_ADMIN: Privilegios de sistema necesarios para el manejo del servicio de planificacion de trabajos (scheduler job)
PUBLIC: Este rol se concede a todos los usuarios de la base de datos. Cualquier privilegio concedido a PUBLIC estará disponible para todos los usuarios. Este rol se trata de una forma especial, no aparece en la vista DBA_ROLES.

ej:

SQL> GRANT SELECT ON departamento.clientes TO PUBLIC;

Todos los usuarios de la base de datos podrán consultar la tabla departamento.clientes

lunes, 23 de febrero de 2015

Algunas de las Nuevas Características en Oracle Database 12C

-Se aumenta el limite de los tipos de dato VARCHAR2, NVARCHAR2 y RAW de 4K a 32K.
-Se puede crear columnas invisibles:

SQL> create table test (column-name column-type invisible);
SQL> alter table table-name modify column-name invisible;
SQL> alter table table-name modify column-name visible;

Oracle 12c tiene una nueva funcionalidad llamada Identity columns las cuales se incrementan automaticamente a medida que hay inserciones de datos ( Al igual que en Mysql y Sql Server)

SQL> create table dept (dept_id number generated as identity, dept_name varchar);
SQL> create table dept (dept_id number generated as identity (start with 1 increment by 1 cache 20 noorder), dept_name varchar);

undo temporal(para tablas temporales globales) no generará undo. Podemos administrar esto usando el parámetro de inicialización temp_undo_enabled=false.

- No es necesario bajar la base de datos para cambiar a modo archive-log.
- Es posible la creación de indices duplicados y con la misma cantidad de columnas

PL/SQL dentro de SQL: Es posible usar DDL dentro de sentencias SQL.

-Es posible mover y renombrar datafiles de manera ONLINE

SQL> alter database move datafile 'ruta' to 'nueva_ruta';

-El comando TRUNCATE fue reforzado al agregar la opcion CASCADE la cual sigue a los registros hijos.
-Reduce los contenidos de UNDO regulares de manera de optimizar las operaciones flashback.

DBA
- Nuevos procesos en background (LREG- Listener registration, SA-SGA Allocator,RM.
- A los ya conocidos sysadmin, sysdba,sysoper se suman los siguientes privilegios:
-sysbackup: para operaciones de respaldos.
-sysdg: para operaciones de Data Guard
-syskm: para manejo de contraseñas (Key Management)

-La utilidad datapump permite dejar en off los redo para las operaciones de importación.
$ impdp ... transform=disable_archive_logging:y

-expdp incluye vistas de transporte: view_as_tables

Oracle 10g: OPEN_CURSORS y SHARED_OPEN_CURSORS

Pasos que sigue Oracle para procesar una consulta:
1) Validación Sintáctica
2) Validación Semántica
3) Optimización
4) Generación del QEP (Query Execution Plan)
5) Ejecución del QEP (Query Execution Plan)
En algunos entornos nos podemos encontrar con aplicaciones que realizan ciertas consultas (y digo consultas) de forma muy reetiva de forma continua. Cuando el catálogo es muy amplio, continuo e inevitable debemos tener en cuenta dos parámetros de inicialización de la base de datos: open_cursors y session_cached_cursors.
Open_cursors nos permite establecer el límite de cursores por sesión y su seteo es muy directo. Si se necesitan 1000 y no hay nada que optimizar pues 1000 pondremos. En cambio Session_cached_cursors es algo más complejo y requiere analizarse en base al número máximo de cursores (open_cursors) y la cantidad actual de cursores que se mantienen en "cache" actualmente.
Consulta:
select
'session_cached_cursors' parameter,
lpad(value, 5) value,
decode(value, 0, ' n/a', to_char(100 * used / value, '990') || '%') usage
from
( select
max(s.value) used
from
sys.v_$statname n,
sys.v_$sesstat s
where
n.name = 'session cursor cache count' and
s.statistic# = n.statistic#
),
( select
value
from
sys.v_$parameter
where
name = 'session_cached_cursors'
)
union all
select
'open_cursors',
lpad(value, 5),
to_char(100 * used / value, '990') || '%'
from
( select
max(sum(s.value)) used
from
sys.v_$statname n,
sys.v_$sesstat s
where
n.name in ('opened cursors current', 'session cursor cache count') and
s.statistic# = n.statistic#
group by
s.sid
),
( select
value
from
sys.v_$parameter
where
name = 'open_cursors'
) ;

Ejemplo:
PARAMETER VALUE USAGE
---------------------- --------------- -----
session_cached_cursors 100 100%
open_cursors 300 57%
Si con el valor actual observamos que el uso es del 100% podemos incrementar de forma moderada el parámetro session_cached_cursors y observar el resultado. Siempre que este por debajo estamos reutilizando todos los que son posibles y estamos optimizando al evitar el "hard parse" de la consulta reduciendo el uso de cpu. Pero cuidado, tampoco vale igualar este parámetro al número máximo de cursores ya que no es oro todo lo que reluce y cuanto más grande sea este valor mayor memoria estamos consumiendo y en servidores cortitos de harware puede pasar factura por otro sitio.