PEDRO SALGUEIRO GÓMEZ 2011
Tabla de contenidos
I. NOCIONES SOBRE BASES DE DATOS Y ORACLE 6
1. Arquitectura de Oracle Database 11g... 6
1.1. Fundamentos de bases de datos. ... 6
1.2. Fundamentos de bases de datos relacionales... 8
1.3. Bases de datos e instancias en Oracle. ... 11
1.4. Organización de las bases de datos en Oracle. ... 11
1.5. Selección de arquitecturas y opciones. ... 14
2. Instalar Oracle Database 11g y crear una base de datos ... 15
2.1. Descripción de la licencia y opciones de instalación. ... 15
3. Servidor de Oracle ... 24
3.1. Elementos del servidor Oracle ... 24
3.2. Conexiones. ... 24
3.3. Estructura de las bases de datos Oracle. ... 25
3.4. Instancia de la base de datos. ... 25
3.5. Procesamiento de instrucciones SQL. ... 26
3.6. Archivos de inicialización ... 27
3.7. Arranque y parada de la base de datos... 28
4. Introducción a los conceptos del sistema Oracle ... 29
4.1. Almacenamiento. ... 29
4.2. Transacciones. ... 29
4.3. Usuarios. ... 29
4.4. Pérdidas de información. ... 30
4.5. Copias de seguridad. ... 30
4.6. Bases de datos distribuidas. ... 30
4.7. Herramientas de Oracle. ... 30
II. LENGUAJE DE CONSULTAS ... 32
1. SQL para Oracle ... 32
1.1. Introducción. ... 32
1.2. Código SQL y normas de escritura. ... 32
1.3. SQL*Plus. ... 32
1.4. Versión gráfica de SQL*Plus. ... 33
1.5. iSQL*Plus. ... 33
2. Estructura del lenguaje SQL... 34
2.1. Tipos de datos... 34
2.2. Operadores ... 35
2.3. Funciones predefinidas... 36
3. Trabajando con objetos ... 52
3.1. Introducción. ... 52
3.2. Diccionario de datos de Oracle. ... 52
3.3. Crear y usar bases de datos. ... 53
3.4. Crear y usar tablespaces. ... 53
3.5. Crear esquemas. ... 55
3.6. Crear y usar tablas. ... 56
3.7. Restricciones. ... 59
3.8. Crear y eliminar índices. ... 61
3.9. Uso de tablas particionadas. ... 64
3.10. Clústeres (o cubos). ... 67 3.11. Secuencias. ... 68 3.12. Sinónimos... 69 3.13. Inserción de registros. ... 69 3.14. Actualización de registros. ... 72 3.15. Eliminación de registros. ... 72
3.16. Combinar registros con MERGE. ... 73
4. Consultas de selección ... 73
4.1. Consultas básicas. ... 74
4.2. Alias... 74
4.3. Ordenar los registros. ... 74
4.4. Consultas con predicado... 75
4.5. Recuperación de valores calculados. ... 75
4.6. La cláusula «WHERE». ... 76
4.7. Consultas que incluyen nulos ... 76
5. Criterios de selección ... 76
5.1. Operadores lógicos. ... 76
5.2. Intervalos de valores. ... 77
5.3. El operador «Like». ... 77
5.4. El operador «In». ... 77
6. Consultas sobre más de una tabla ... 78
6.1. Reunión de una tabla consigo misma. ... 78
6.2. Consultas de unión internas. ... 78
6.3. Consultas con operaciones de conjuntos... 80
7. Agrupaciones ... 80
7.1. Funciones de agregado. ... 80
7.2. La cláusula «Group by». ... 83
8. Subconsultas ... 84
8.1. Introducción. ... 84
8.2. Recuperación de datos con subconsulta... 84
8.3. Subconsultas correlacionadas. ... 85
8.4. Subconsultas con operador de comparación distinto de «IN». ... 85
8.5. Funciones de agregado en subconsultas. ... 86
8.6. Subconsultas con «EXISTS». ... 86
8.7. Expresiones de columna con subconsultas ... 86
8.8. Subconsultas como origen de registros para «FROM». ... 87
9. Vistas ... 87
9.1. Introducción. ... 87
9.2. Crear y consultar vistas. ... 88
9.3. Ejecución de comandos DML sobre vistas. ... 88
9.4. Estabilidad de una vista. ... 88
9.5. Mostrar la lista de vistas. ... 89
9.6. Borrar vistas. ... 89
10. Comandos internos en SQL*PLUS e iSQL*Plus ... 89
10.1. Variables de sustitución. ... 89
10.2. Comando «SET». ... 90
10.3. Encabezado y pie de informe. ... 90
10.4. Comando «COLUMN». ... 91
10.5. Comando «BREAK». ... 91
10.6. Comando «COMPUTE». ... 92
10.7. Guardar consultas en ficheros. ... 93
10.8. Redirigir la salida de SQL*Plus con «SPOOL». ... 93
11. Consultas avanzadas ... 94
11.1. Consultas con «ROWNUM». ... 94
11.2. Consultas con «ROWID». ... 94
11.3. Consultas con «RANK». ... 95
11.4. Consultas sobre estructuras jerárquicas. ... 96
11.5. Consultas de agrupación avanzada. ... 98
III. PL/SQL ... 101
1. Estructura del lenguaje PL/SQL ... 101
1.1. Fundamentos de PL/SQL. ... 101
1.2. Estructuras de control en PL/SQL. ... 102
2. Bloques PL/SQL... 103
2.1. Introducción. ... 103
2.2. Estructura de un Bloque. ... 103
2.3. Sección de declaración de variables. ... 104
2.4. El paquete «DBMS_OUTPUT». ... 105
2.5. Asignación de variables... 106
3. Excepciones en PL/SQL. ... 107
3.1. Manejo de excepciones. ... 107
3.2. Excepciones predefinidas. ... 107
3.3. Excepciones definidas por el usuario. ... 108
3.4. Uso de «SQLCODE» y «SQLERRM». ... 109
3.5. Excepciones personalizadas en PL/SQL. ... 109
3.6. Propagación de excepciones en PL/SQL. ... 109
4. Cursores ... 109
4.1. Cursores implícitos. ... 110
4.2. Cursores explícitos. ... 110
4.3. Cursores con parámetros. ... 111
4.4. Cursores de actualización. ... 111
5. Subprogramas en PL/SQL ... 112
5.1. Permisos requeridos. ... 112
5.2. Procedimientos, funciones y paquetes. ... 113
5.3. Procedimientos almacenados. ... 113
5.4. Funciones en PL/SQL. ... 114
5.5. Subprogramas en bloques procedimentales. ... 115
5.7. Paquetes en PL/SQL. ... 115
5.8. Viendo el código fuente de objetos procedimentales... 118
5.9. Compilando procedimientos, funciones y paquetes... 118
6. Transacciones ... 119
6.1. Estado de los datos durante la transacción. ... 119
6.2. Control de transacciones en PL/SQL. ... 119 6.3. Puntos de ruptura. ... 120 6.4. Transacciones autónomas ... 120 7. Triggers ... 121 7.1. Permisos requeridos. ... 121 7.2. Tipos de triggers. ... 121
7.3. Triggers asociados a tablas. ... 122
7.4. Triggers para eventos DDL. ... 125
7.5. Triggers para eventos del sistema. ... 128
7.6. Triggers de sustitución. ... 129
7.7. Activar y desactivar triggers. ... 130
8. Tipos de datos complejos y operaciones masivas. ... 131
8.1. Registros (RECORD). ... 131
8.2. Arrays asociativos (TABLE). ... 132
8.3. Arrays variables (VARRAY)... 133
8.4. Acceso masivo a los datos (BULK COLLECT). ... 135
8.5. Funciones en línea. ... 136
8.6. Instrucción «FORALL». ... 137
8.7. Objetos grandes (LOB). ... 138
9. SQL Dinámico ... 142
9.1. Sentencias DML con SQL dinámico. ... 143
9.2. Cursores con SQL dinámico. ... 143
9.3. Un ejemplo de cómo usar y cómo no usar SQL dinámico.146 10. PL/SQL y Java ... 146
10.1. Creación de Objetos Java en la base de datos ORACLE.146 10.2. Ejecución de programas Java con PL/SQL ... 147
10.3. Correspondencia de tipos entre Java y Oracle. ... 148
10.4. Paso de cursores Oracle a métodos de Java. ... 148
10.5. Paso de objetos Oracle a métodos de Java. ... 149
10.6. Paso de arrays desde un programa Java a un procedimiento almacenado de Oracle. ... 150
10.7. Cómo pasar y retornar un array de objetos a través de un procedimiento almacenado... 151
10.8. Paquete «DBMS_JAVA». ... 152
IV. CARACTERÍSTICAS DE ORACLE GRID... 155
1. Arquitectura de Rejilla ... 155
1.1. Hardware y elementos de configuración del sistema operativo. ... 155
1.2. Añadiendo servidores a la rejilla. ... 157
1.3. Compartir datos entre la rejilla. ... 157
1.4. Administración de la rejilla. ... 158
1.5. Lanzar OEM. ... 159
2. Oracle Real Application Clusters ... 160
2.1. Pasos de preinstalación. ... 160
2.2. Instalación de RAC. ... 161
2.3. Inicia y parar instancias RAC. ... 163
2.4. Transparencia de sobrefallos de aplicación... 164
2.5. Añadir nodos e instancias a un clúster. ... 165
2.6. Administración de registro y servicios del clúster. ... 165
3. Seguridad en Oracle ... 166
3.1. Creación de usuarios. ... 166
3.2. Eliminación de usuarios. ... 167
3.3. Gestión de contraseñas. ... 167
3.4. Perfiles de usuario... 169
3.5. Cuentas de base de datos sobre cuentas del sistema operativo. ... 170
3.6. Usuarios globales. ... 170
3.7. Usuarios con permisos especiales: SYSOPER y SYSDBA.171 3.8. Roles estándar. ... 172
3.9. Permisos del sistema. ... 173
3.10. Metadatos sobre permisos y usuarios. ... 181
4. Bases de datos virtuales privadas. ... 181
4.1. Cómo implementar VPD a nivel de tabla. ... 182
4.2. Cómo implementar VPD a nivel de columna. ... 186
4.3. Cómo desactivar VPD. ... 186
4.4. Contenido del paquete «SYS.DBMS_RLS». ... 186
4.5. Cómo usar grupos de políticas. ... 187
5. Trabajando con espacios de tabla... 187
5.1. Tablespaces y la estructura de las bases de datos. ... 188
5.2. Planificando el uso de nuestro tablespace. ... 196
6. Usar SQL*Loader para cargar datos ... 197
6.1. El fichero de control. ... 197
6.2. Comienzo de la carga. ... 199
6.3. Sobre la sintaxis del fichero de control. ... 201
6.4. Administración de la carga de datos. ... 202
6.5. Ajustar la carga de datos. ... 203
6.6. Funcionalidades adicionales. ... 205
7. Importar y exportar con «Data Pump» ... 205
7.1. Creando un directorio. ... 205
7.2. Opciones de «Data Pump Export». ... 206
7.3. Iniciando una tarea de «Data Pump Export». ... 207
7.4. Opciones para «Data Pump Import». ... 210
7.5. Iniciando una tarea de «Data Pump Import». ... 211
8. Acceso a datos remotos ... 214
8.1. Enlaces de base de datos. ... 214
8.2. Usando sinónimos para transparencia de localización. .... 218
8.3. Usando la pseudo-columna «USER» en vistas... 219
8.4. Enlaces dinámicos: usando el comando de copia de SQL*Plus. ... 220
8.5. Conectándose a una base de datos remota. ... 221
9. Vistas materializadas. ... 222
9.1. Funcionalidad. ... 222
9.2. Permisos requeridos. ... 222
9.3. Solo-lectura contra actualizable. ... 223
9.4. Sintaxis de creación de vistas materializadas. ... 223
9.5. Usando vistas materializadas para modificar rutas de ejecución de consultas. ... 227
9.6. Usando «DBMS_ADVISOR». ... 228
9.7. Refrescando vista materializadas. ... 229
9.8. Sintaxis para crear registros de vista materializada. ... 233
9.9. Modificando vistas materializadas y registros. ... 234
9.10. Eliminando vistas materializadas y registros. ... 234
10. Oracle Text... 235
10.1. Añadiendo texto a la base de datos. ... 235
10.2. Consultas de texto e índices de texto. ... 235
10.3. Conjuntos de índices. ... 243
11. Uso de tablas externas ... 244
11.1. Accediendo a datos externos. ... 244
11.2. Creando una tabla externa. ... 245
11.3. Modificación de tablas externas. ... 250
11.4. Limitaciones, beneficios y usos potenciales de las tablas externas. ... 251
12. Consultas flashback ... 252
12.1. Ejemplo de consulta flashback basada en el tiempo. ... 253
12.2. Guardando los datos. ... 254
12.3. Ejemplo de consulta flashback basada en SCN. ... 254
12.4. ¿Qué ocurre si falla una consulta flashback? ... 255
12.5. ¿Qué SCN está asociado con cada registro? ... 255
12.6. Consultas de versión flashback. ... 256
12.7. Planificación de las consultas flashback. ... 257
13. Tablas y bases de datos flashback ... 258
13.1. El comando «FLASHBACK TABLE». ... 258
13.2. El comando «FLASHBACK DATABASE». ... 260
V. SOPORTE DE OBJETOS Y XML ... 263
1. Modelo objeto-relacional de Oracle ... 263
1.1. Tipos abstractos de datos (clases y objetos). ... 263
1.2. Seguridad para tipos de datos abstractos. ... 264
1.3. Herencia de clases. ... 266
1.4. Métodos. ... 266
1.5. Tablas relacionales de objetos. ... 269
1.6. Tipos referencia (REF). ... 271
1.7. Tablas anidadas y arrays variables. ... 272
1.8. Vistas de objeto. ... 274
1.9. Trabajando con tipos SQL desde aplicaciones JDBC. ... 275
1.10. Crear y usar clases de objetos Java personalizadas para objetos Oracle. ... 275
2.1. «XMLType». ... 281
2.2. Mapeado de «XMLType» dado un esquema XML. ... 281
2.3. Crear tablas/columnas «XMLType». ... 282
2.4. Operaciones con columnas XMLType. ... 283
2.5. Validar los documentos XML sobre un esquema. ... 286
2.6. Indexar elementos «XMLType». ... 287
2.7. SQLX, generar XML de los datos relacionales. ... 287
2.8. Vistas «XMLType». ... 291
VI. PROCEDIMIENTOS DE GESTIÓN DE LA BASE DE DATOS. ... 294
1. Diccionario de datos de Oracle ... 294
1.1. Las vistas «DICTIONARY» (DICT) y «DICT_COLUMNS». ... 294
1.2. Cosas que podemos seleccionar de: tablas (y columnas), vistas, sinónimos y secuencias. ... 295
1.3. Papelera: USER_RECYCLEBIN y DBA_RECYCLEBIN300 1.4. Restricciones y comentarios. ... 300
1.5. Índices y clústeres. ... 303
1.6. Tipos de datos abstractos, estructuras ORDBMS y LOB's.306 1.7. Enlaces de base de datos y vistas materializadas. ... 308
1.8. Triggers, procedimientos, funciones y paquetes... 310
1.9. Dimensiones. ... 311
1.10. Asignación y uso de espacio, incluyendo particiones y subparticiones. ... 312
1.11. Usuarios y permisos. ... 316
1.12. Roles. ... 318
1.13. Auditoría. ... 318
1.14. Supervisión: las tablas de rendimiento dinámico V$. .... 320
2. Administración de la base de datos. ... 325
2.1. Creación de una base de datos. ... 325
2.2. Iniciación y parado de la base de datos... 326
2.3. Tamaño y gestión de las áreas de memoria. ... 326
2.4. Asignar y gestionar espacio para objetos. ... 327
3. Auditoría de Seguridad ... 329
3.1. Auditando conexiones. ... 330
3.2. Auditando Acciones ... 330
3.3. Auditando objetos. ... 331
I. NOCIONES SOBRE BASES DE DATOS Y ORACLE
1. Arquitectura de Oracle Database 11g
Oracle Database 11g es una actualización significativa de Oracle. Se han añadido nuevas funcionalidades para los programadores, administradores de base de datos, y los usuarios finales tienen un mayor control sobre el almacenamiento, procesamiento y recuperación de los datos.
1.1. Fundamentos de bases de datos.
Todas las bases de datos relacionales manejan una serie de conceptos, los cuales pueden ser implementados de forma diferente en cada base de datos.
▪ Dato. Es un conjunto de caracteres con algún significado; que pueden ser numéricos, alfabéticos, o
alfanuméricos.
▪ Información. Es un conjunto ordenado de datos, los cuales son manejados según la necesidad del
usuario. Para que un conjunto de datos pueda ser procesado eficientemente y pueda dar lugar a información, primero se deben guardar lógicamente en archivos.
▪ Base de datos (BD).Es un conjunto de información relacionada que se organiza y estructura de alguna
manera en archivos. En ese sentido, cualquier conjunto de fichas organizadas y guardadas en un archivador constituye una base de datos.
En nuestro entorno cotidiano existen muchos ejemplos de bases de datos: registros de bibliotecas (con información sobre libros, lectores, préstamos, etc.), registros de empresas (con información sobre empleados, ocupaciones, productos, etc.), el censo de una población (con la información personal de sus habitantes), etc.
La utilidad y eficacia de una base de datos depende de la forma en que se estructura la información que contiene. Por ejemplo, en un archivador, la información se distribuye en un número determinado de fichas que poseen la misma estructura.
▪ Registro. Es cada una de las fichas o filas de que consta una base de datos.
▪ Campos o atributos. Son cada una de las características diferenciadas que definen un registro. Cada
registro o ficha está constituido por una serie de apartados en los que se introduce una determinada información (Nombre, Apellidos, Fecha, Dirección, Ocupación, etc.).
▪ Archivo o fichero. Es la unión de todos los registros con la misma estructura.
▪ Sistema Gestor de Base de Datos (SGBD). Es una colección de rutinas o programas interrelacionados,
que permiten crear y manipular una base de datos.
El objetivo primordial de un sistema gestor es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer, almacenar y manipular información de la base de datos. Todas las peticiones de acceso a la base de datos se manejan centralizadamente por medio del SGBD, por lo que este paquete funciona como una interfaz entre los usuarios y la base de datos.
▪ Esquema de base de datos. Es la estructura por la que está formada la base de datos. Se especifica por
medio de un conjunto de definiciones que se expresa mediante un lenguaje especial llamado lenguaje de definición de datos (DDL).
▪ Administrador de base de datos (DBA). Es la persona o equipo de personas profesionales
responsables del control y manejo del sistema de base de datos, generalmente tiene(n) experiencia en SGBD, diseño de bases de datos, Sistemas operativos, comunicación de datos, hardware y programación.
1.1.1. Objetivos de los sistemas de bases de datos.
Los sistemas de base de datos se diseñan para manejar grandes cantidades de información. La manipulación de los datos involucra dos aspectos:
- la definición de estructuras para el almacenamiento de la información, y - aportar mecanismos para la manipulación de la información.
Además, un sistema de base de datos debe de tener implementados mecanismos de seguridad que garanticen la integridad de la información, bien ante caídas del sistema o bien ante intentos de accesos no autorizados. Por tanto, el objetivo principal de un sistema de base de datos es minimizar los siguientes aspectos:
▪ Redundancia e inconsistencia de datos. Puesto que los archivos que mantienen almacenada la
información son creados por diferentes tipos de aplicaciones, existe la posibilidad de que si no se controla detalladamente el almacenamiento, se pueda originar un duplicado de información (que la misma información esté en más de un soporte). Esto aumenta los costes de almacenamiento y acceso a los datos, además de que puede originar la inconsistencia de los datos.
▪ Dificultad para tener acceso a los datos. Un sistema de base de datos debe contemplar un entorno de
datos que le facilite al usuario el manejo de los mismos. Supóngase un banco, y que uno de los gerentes necesita averiguar los nombres de todos los clientes que viven en una zona con el código postal 78733. El gerente pide al departamento de procesamiento de datos que genere la lista correspondiente. Si esta situación no fue prevista en el diseño del sistema, obtener tal lista se convertirá en una tarea difícil.
▪ Aislamiento de los datos. Puesto que los datos están repartidos en varios archivos, y éstos pueden
tener diferentes formatos, es difícil crear nuevos programas para obtener los datos apropiados.
▪ Anomalías del acceso concurrente. Para mejorar el funcionamiento global del sistema y obtener un
tiempo de respuesta más rápido, muchos sistemas permiten que múltiples usuarios actualicen los datos simultáneamente. En un entorno así, la interacción de actualizaciones concurrentes puede dar por resultado datos inconsistentes. Para prevenir esta posibilidad debe mantenerse alguna forma de supervisión en el sistema.
▪ Problemas de seguridad. La información de toda empresa es importante, aunque unos datos lo son
más que otros; por tal motivo se debe considerar el control de acceso a los mismos. No todos los usuarios podrán visualizar determinada información; y por tal motivo, para que un sistema de base de datos sea confiable, debe mantener un grado de seguridad que garantice la autentificación y protección de los datos. ▪ Problemas de integridad. Los valores de datos almacenados en la base de datos deben satisfacer cierto
tipo de restricciones de consistencia. Estas restricciones se hacen cumplir en el sistema añadiendo códigos apropiados en los diversos programas.
1.1.2. Abstracción de la información.
Una base de datos es en esencia una colección de archivos relacionados entre sí, de la cual los usuarios pueden extraer información sin que tengan que conocer la estructura interna de los archivos.
Un objetivo importante de un sistema de base de datos es proporcionar a los usuarios una visión abstracta de los datos; es decir, el sistema debe esconder ciertos detalles de cómo se almacenan y mantienen los datos. Sin embargo, para que el sistema sea manejable, los datos se deben extraer eficientemente.
Existen diferentes niveles de abstracción para simplificar la interacción de los usuarios con el sistema:
▪ Nivel físico. Es la representación del nivel más bajo de abstracción; en éste se describe en detalle la forma en cómo se almacenan los datos en los dispositivos de almacenamiento (por ejemplo, mediante índices para el acceso aleatorio a los datos).
▪ Nivel conceptual. El siguiente nivel más alto de abstracción describe qué datos son almacenados realmente en la BD y las relaciones que existen entre los mismos. Describe completamente la base de datos en términos de su estructura de diseño.
El nivel conceptual de abstracción lo usan los administradores de BD, quienes deben decidir qué información se va a guardar en la base de datos. Consta de las siguientes definiciones:
1) Definición de los datos: se describen el tipo de dato y sus características.
2) Relaciones entre datos: se definen las relaciones entre datos, para enlazar tipos de registros relacionados, para su procesamiento posterior.
▪ Nivel de visión. Es el nivel más alto de abstracción; es lo que el usuario final puede visualizar del sistema terminado. Sólo describe una parte de la BD según el usuario acreditado para verla. El sistema puede proporcionar muchas visiones para la misma BD.
Nivel de visión
Vista 1 . . . Vista n
Nivel conceptual
Nivel físico
1.2. Fundamentos de bases de datos relacionales.
El modelo relacional de base de datos nace en 1970, cuando Edgar Codd escribe el artículo "A relational model of data for large strared data tanks". Es a partir de 1980 cuando aparecen los primeros gestores de base de datos cuyo modelo de datos subyacente es el relacional.
El modelo relacional conecta registros mediante los valores que éstos contienen. De hecho, Codd propone una estructura tabular (correspondiente a tablas) para representar los datos.
Es decir, si queremos representar toda la información contenida en los registros de un archivo podemos utilizar una estructura de tabla. Por ejemplo, la información del censo de una población podemos representarla de la siguiente manera:
DNI Nombre Fecha Ocupación
23444325 Pedro Salgueiro 20/12/64 Profesor 65335544 José Martínez 14/07/72 Carpintero 11143442 Esther López 03/07/72 Carpintero 66442444 José Martínez 12/10/65 Ingeniero
Como vemos, los registros se disponen por filas mientras que los campos se disponen por columnas. Esta forma particular de estructurar y representar la información se conoce como base de datos relacionales.
Cada tabla es la representación física de una entidad o una relación, y se corresponde con un archivo o
fichero de la BD.
Cada fila de la tabla se corresponde con un registro, llamado también intensión o tupla.
Cada columna se corresponde con los valores de un campo o atributo, siendo éstos una característica
distinguible de una entidad o relación. Cada atributo tiene asignado un dominio, del cual tomará valores.
1.2.1. Campos clave.
Las BD relacionales se basan en un concepto fundamental: cada registro de la tabla debe ser único, no pudiendo haber registros repetidos. Para asegurar esta circunstancia surge el concepto de clave, como aquel
campo de la tabla cuyo valor para cada registro es único.
En el ejemplo anterior podemos comprobar que existen nombres, apellidos y ocupaciones repetidas en varios registros; por lo tanto, ninguno de estos tres campos puede ser clave. Vemos que ninguna fecha se repite, pero nada nos asegura que no podamos insertar dos personas que hayan nacido en la misma fecha. Sin embargo, el DNI de una persona, por su propia definición, suele ser un valor único. Por tanto el campo DNI sí puede ser la clave para esta tabla.
Puede darse el caso de que en una tabla ninguno de los campos sea clave. Entonces podemos probar a unir varios campos, de forma que el valor conjunto de estos campos sea único. En el ejemplo anterior podemos considerar que el valor conjunto de los campos Nombre y Fecha no suele repetirse (es decir, no suele haber dos personas con el mismo nombre y que han nacido en la misma fecha). En ese caso, los campos (Nombre, Fecha) constituyen una clave compuesta.
Si en una tabla no existen claves simples ni claves compuestas, debemos inventarnos un nuevo campo que actúe como clave. Este nuevo campo normalmente es un código o identificador numérico que se va asignando a cada nuevo registro que se introduce en la tabla, de forma que nunca se repita.
1.2.2. Operaciones básicas sobre registros.
Con los registros de una tabla podemos realizar las siguientes operaciones básicas:
▪ Añadir un registro. Cuando añadimos un nuevo registro en la tabla debemos comprobar que el valor (o
conjunto de valores) de la clave no esté repetido. Si otro registro posee esa clave no podrá añadirse el nuevo registro.
▪ Borrar un registro. No existen limitaciones para borrar un registro. (Normalmente los registros no se
borran inmediatamente de la tabla, sino que internamente se les pone una marca para indicar que están pendientes de borrado.)
▪ Actualizar un registro. Se puede modificar la información de un registro en cualquiera de sus campos,
excepto en los campos que pertenezcan a la clave.
1.2.3. Operaciones relacionales sobre tablas.
Podemos realizar las siguientes operaciones sobre una tabla:
▪ La Intersección ( ∩ ). Sólo es aplicable sobre tablas con esquemas similares. Produce una nueva tabla con el mismo esquema, y que contendrá los registros comunes en ambas tablas.
▪ La Unión ( U ). También es sólo aplicable a tablas con el mismo esquema. Produce una nueva tabla con el mismo esquema y con todos los registros de ambas tablas (excluyendo los registros repetidos).
▪ Diferencia ( – ). Produce una nueva tabla con aquellos registros de la primera tabla que no pertenecen a la segunda tabla.
1.2.4. Operaciones propias del modelo relacional.
▪ Selección ( ∑). Se aplica sobre una tabla, y produce una nueva tabla con aquellos registros que en algunos atributos cumplen una condición determinada.
▪ Proyección ( ∏ ). Aplicada sobre una tabla, produce una nueva tabla con todos los registros de la original, pero cuyo esquema contiene sólo alguno de los atributos de la tabla original.
▪ Join ( ). Se aplica sobre dos tablas de distinto esquema pero con atributos comunes (o compatibles). Genera una nueva tabla que es el producto cartesiano de ambas tablas, seleccionando los registros con valores idénticos en los atributos comunes y eliminando las columnas repetidas.
1.2.5. Relaciones entre tablas.
La gran potencia y eficacia de las bases de datos relacionales se comprueba cuando debemos asociar la información contenida en dos o más tablas relacionadas.
Consideremos el ejemplo de una concesionaria de automóviles, la cual posee una base de datos con información sobre sus clientes y los coches que vende. En este caso, la base de datos se compone de dos tablas: una con los datos de los clientes, y otra con los datos de coches disponibles.
TABLA DE CLIENTES TABLA DE COCHES
DNI Nombre Apellidos TipoPago Matrícula Marca Precio 11252111 PEDRO PÉREZ CONTADO M-2345-AF OPEL 1200000 12323253 JUAN GARCÍA PLAZOS M-3443-HW CITROEN 2100000 56344323 LUÍSA GÓMEZ PLAZOS M-1278-HZ CITROEN 1500000
La clave de la tabla CLIENTES es el campo DNI, y la clave de la tabla COCHES es Matrícula. Aunque estas dos tablas recogen toda la información disponible sobre clientes y coches, no tenemos manera de saber qué clientes han comprado qué coches. Es necesario relacionar estas dos tablas asociando cada registro de un cliente al registro del coche que ha comprado.
Para relacionar tablas en una BD relacional surge el concepto de clave foránea. En una de las tablas se añade
un nuevo campo que se corresponda con la clave de la otra tabla, actuando el nuevo campo como clave foránea.
Existen cuatro tipos de relaciones posibles:
▪ Relación uno a uno. Sólo podemos asociar un registro de la primera tabla con un registro de la segunda
tabla y viceversa. En nuestro ejemplo significa que un cliente sólo puede comprar un coche y un coche sólo puede ser comprado por un cliente.
Esta relación se resuelve introduciendo en una de las tablas, como clave foránea, la clave de la otra tabla. Tenemos dos soluciones para nuestro ejemplo.
Matrícula Marca Precio CLIENTES COCHES 1 1 DNI Nombre Apellidos TipoPago Matrícula Matrícula Marca Precio DNI CLIENTES COCHES 1 1 DNI Nombre Apellidos TipoPago
▪ Relación uno a varios. Podemos asociar un registro de la primera tabla con varios registros de la
segunda tabla, y un registro de la segunda tabla con un registro de la primera. En nuestro ejemplo significa que un cliente puede comprar varios coches, pero un coche sólo puede ser comprado por un cliente. Se resuelve introduciendo en la segunda tabla la clave de la primera.
Matrícula Marca Precio DNI CLIENTES COCHES 1 DNI Nombre Apellidos TipoPago
▪ Relación varios a uno. Esta relación es análoga a la anterior. Indica que un cliente sólo puede comprar
un coche, pero un coche puede ser comprado por varios clientes. Se resuelve introduciendo en la primera tabla la clave de la segunda.
Matrícula Marca Precio CLIENTES COCHES 1 DNI Nombre Apellidos TipoPago Matrícula
▪ Relación varios a varios. Podemos asociar un registro de la primera tabla con varios registros de la
segunda tabla, y podemos asociar un registro de la segunda tabla con varios de la primera. En nuestro ejemplo significa que un cliente puede comprar varios coches y un coche puede ser comprado por varios clientes.
Esta relación se resuelve creando una nueva tabla cuya estructura hereda los campos claves de las tablas relacionadas. Para nuestro ejemplo crearemos la tabla COMPRA, con dos campos:
- DNI, clave foránea heredada de la tabla CLIENTES.
- Matrícula, clave foránea heredada de la tabla COCHES.
La clave de esta nueva tabla puede estar formada por ambos campos, y por lo tanto será compuesta; o bien podemos añadir una nuevo campo que actúe de clave.
1 1 Matrícula Marca Precio CLIENTES COCHES DNI Nombre Apellidos TipoPago Matrícula COMPRA DNI Matrícula 1.2.6. Reglas de integridad.
En las bases de datos relacionales deben cumplirse dos reglas fundamentales:
1ª REGLA (Integridad de entidad): dice que ningún campo que forme parte de una clave puede carecer
de valor (o dicho en términos informáticos; no puede tomar el valor nulo).
Esto es así porque si un registro careciese de valor en su clave ya no podría ser identificado de forma única.
2ª REGLA (Integridad referencial): dice que no se puede introducir en una clave foránea valores que
no pertenezcan a la clave de la tabla referenciada.
No tiene sentido indicar en una tabla referenciada valores que no existen en la tabla principal. En el ejemplo de la concesionaria, no tiene sentido indicar que un coche ha sido comprado por un cliente del cual no se tiene ninguna referencia.
La segunda regla puede crear problemas en el caso de que se quieran borrar registros con una clave foránea referenciada por otra tabla. Para evitar este problema existen tres soluciones:
- Prohibir el borrado. Por ejemplo, no se podrán eliminar clientes que hayan comprado algún coche.
- Borrar en cascada. Por ejemplo, si se elimina un cliente, se eliminarán también todos los coches
comprados por ese cliente.
- Nulificar. Por ejemplo, si se elimina un cliente, en los registros de coches vendidos a ese cliente se
pondrá un valor nulo en el DNI.
1.2.7. Diseño de una base de datos relacional.
Una vez establecido un problema, para diseñar una BD relacional debemos seguir los siguientes pasos:
1) Decidir cuántas tablas necesitamos. Normalmente se creará una tabla por cada entidad que
podamos distinguir en nuestro problema.
2) Definir la estructura de cada tabla. De qué campos se componen y cuál es la clave.
3) Determinar para cada campo su tipo de dato, su tamaño (si es necesario) y los valores posibles que
podemos asignarle (su dominio).
4) Establecer las relaciones entre las tablas. Para ello debemos incluir en cada tabla las claves foráneas
que sean necesarias o crear nuevas tablas.
Una vez diseñada la base de datos podemos crearla utilizando un gestor de base de datos.
1.3. Bases de datos e instancias en Oracle.
Una base de datos de Oracle es una colección de datos en uno o más archivos. La base de datos de Oracle contiene estructuras físicas y lógicas. Durante el desarrollo de una aplicación podemos crear estructuras como tablas e índices para almacenar filas y acelerar su recuperación. Podemos crear sinónimos para los nombres de objetos, vistas de objetos en varias bases de datos y podemos restringir el acceso a los objetos. También podemos usar tablas externas para acceder a ficheros fuera de la base de datos como si las filas en los ficheros fuesen filas de tablas.
Una instancia de Oracle comprende un área de memoria llamada Área Global del Sistema (SGA) y los procesos de fondo que interactúan entre el SGA y los ficheros de la base de datos en disco. En una "Real Application Cluster de Oracle" (RAC) más de una instancia será usada sobre la misma base de datos; las instancias generalmente estarán sobre servidores independientes conectados mediante una interconexión de alta velocidad.
1.4. Organización de las bases de datos en Oracle.
Dentro de una base de datos de Oracle, la estructura básica en la tabla. Oracle Database 11g soporta muchos tipos de tablas, incluyendo las siguientes:
■ Tablas relacionales. Usando los tipos de datos soportados por Oracle, podemos crear tablas para
almacenar las filas insertadas y manipularlas en nuestras aplicaciones. Las tablas tienen definiciones de columna, y podemos añadir o quitar columnas según los requerimientos de nuestras aplicaciones.
usar las capacidades objeto-relacional de Oracle. Podemos definir nuestros propios tipos de datos y usarlos como base para la definición de columnas, tablas de objetos, tablas anidadas, arrays variables y más.
■ Tablas organizadas por índice. Podemos crear una tabla que almacene sus datos como una estructura
de índice, permitiendo que los datos sean ordenados dentro de la tabla.
■ Tablas externas. Los datos almacenados en ficheros planos pueden ser tratados como tablas que los
usuarios pueden consultar directamente y relacionar con otras tablas en consultas. Podemos usar tablas externas para acceder a grandes volúmenes de datos sin tener que cargarlos en nuestra base de datos. Oracle también soporta tipos de datos BFILE, un puntero a un fichero binario externo.
■ Tablas particionadas. Podemos dividir una tabla en varias particiones, lo cual permite controlar
independientemente cada parte de la tabla. Podemos añadir una nueva partición a una tabla, separar particiones existentes, y administrar una partición a parte de otra partición de la tabla. El particionado puede simplificar o mejorar el rendimiento de actividades de mantenimiento y de las consultas de usuario. Podemos particionar tablas según rangos de valores, según una lista de valores, según códigos de valores de columna, o según una combinación de estas opciones.
■ Vistas materializadas. Una vista materializada en una réplica de los datos recuperados por una
consulta. Las consultas de usuario pueden ser redireccionadas a las vistas materializadas para evitar tablas largas durante la ejecución (el optimizador rescribirá las consultas automáticamente). Podemos establecer y controlar tareas de refresco para obtener los datos actualizados en las vistas materializadas según las necesidades del negocio.
■ Tablas temporales. Podemos usar tablas temporales globales para crear una tabla en la cual varios
usuarios puedan insertar registros. Cada usuario sólo verá sus filas en la tabla.
■ Tablas de clúster (o cubo).Si dos tablas son normalmente consultadas conjuntamente, podemos
almacenarlas físicamente juntas a través de una estructura llamada clúster (o cubo).
■ Tablas eliminadas. Desde Oracle Database 10g, podemos recuperar rápidamente tablas eliminadas
mediante el comando DROP. Podemos recuperar varias tablas de una vez o recuperar toda la base de datos en un momento concreto. Oracle soporta consultas de deshacer, las cuales retornan versiones anteriores de filas en una tabla existente.
Como soporte en el acceso a las tablas, podemos usar vistas que realicen combinaciones y agregaciones, limitar las filas retornadas, o modificar las columnas mostradas. Las vistas pueden ser de sólo lectura o modificables, y pueden referenciar tablas locales y remotas. Las tablas remotas pueden ser accedidas a través de enlaces a bases de datos. Podemos usar sinónimos para enmascarar la localización física de las tablas. Para controlar los accesos a las tablas, Oracle soporta muchos tipos de índices, incluyendo los siguientes:
■ Índices B*-tree. Un índice B*-tree es el tipo estándar de índices disponibles en Oracle, y es muy usado
para seleccionar filas por un criterio de equivalencia o una criterio de rango.
■ Índices Bitmap. Para columnas que tienen pocos valores únicos, un índice bitmap puede mejorar el
rendimiento de las consultas. Los índices bitmap deberían usarse sólo cuando los datos se cargan por lotes (como en muchos depósitos de datos o aplicaciones de informes).
■ Índices de clave inversa. Si hay problemas de contención de E/S durante la inserción de valores
secuenciales, Oracle puede invertir dinámicamente los valores de índice antes de almacenarlos.
■ Índices basados en funciones. En vez de indexar una columna, como Nombre, podemos indexar una columna basada en una función, como UPPER(Nombre). Este tipo de índice tiene opciones adicionales del optimizador de Oracle cuando seleccionamos una ruta de ejecución.
■ Índices particionados. Podemos particionar índices para soportar tablas particionadas o para
simplificar la gestión de índices. Los índices particionados pueden ser locales para cada partición de la tabla o pueden aplicarse globalmente a todas las filas de la tabla.
■ Índices de texto. Podemos indexar valores de texto para soportar capacidades de búsqueda avanzada,
como palabras derivadas o búsqueda de frases. Los índices de texto son conjuntos de tablas e índices mantenidos por Oracle para soportar requerimientos de búsqueda de texto complejos. Oracle Database 11g ofrece facilidades para indexar texto que simplifique su administración y mantenimiento.
1.4.1. Almacenando los datos.
Toda la estructura lógica de una base de datos debe ser almacenada en algún sitio dentro de la base de datos. Oracle mantiene una diccionario de datos que registra los metadatos acerca de cada objeto (el propietario del objeto, una definición, privilegios relacionados, y cosas así). Para los objetos que requieren un espacio de almacenamiento físico de sí mismos, Oracle reserva espacio dentro de un tablespace.
Tablespaces.
Un tablespace consiste de uno o más ficheros de datos; un fichero de datos puede ser parte de un y solo un único tablespace. Oracle Database 11g crea al menos dos tablespaces para cada base de datos (SYSTEM y
SYSAUX) para soportar las necesidades de administración interna. Podemos usar el «Administrador de Ficheros de Oracle» (OMF) para simplificar la creación y mantenimiento de ficheros de datos.
A partir de Oracle Database 10g, podemos crear un tipo especial de tablespace, llamado "bigfile tablespace", que puede tener muchos miles de terabytes de tamaño. Con OMF, la administración de bigfiles hace la gestión de tablespace completamente transparente para el administrador de base de datos (DBA); el DBA puede administrar los tablespace como una unidad sin preocuparse sobre el tamaño y estructura de los ficheros de datos subyacentes.
Si un tablespace esta designado como un tablespace temporal, el tablespace mismo es permanente; sólo los segmentos guardados en el tablespace son temporales. Oracle usa tablespaces temporales para soportar operaciones de ordenación en la creación de índices y procesos de combinación. Los segmentos temporales no deberían ser almacenados en el mismo tablespace como objetos permanentes.
Los tablespaces pueden ser gestionados en diccionario o gestionados localmente. En una gestión de diccionario, el espacio gestionado es registrado en el diccionario de datos. En una gestión local (por defecto en Oracle Database 11g), Oracle mantiene una mapa de cada fichero de datos del tablespace para rastrear la disponibilidad de espacio. En el diccionario de datos sólo se gestionan cuotas, lo cual reduce dramáticamente la contención de tablas del diccionario de datos.
Gestión automática de almacenamiento.
La gestión automática de almacenamiento (ASM), disponible desde Oracle Database 10g, automatiza el diseño de ficheros de datos y otros ficheros del nivel del sistema operativo usados por la base de datos, distribuyéndolos entre los disco disponibles. Cuando un nuevo disco es añadido a la instancia ASM, los ficheros de datos son automáticamente redistribuidos a través de todos los discos en los grupos de discos definidos para optimizar el rendimiento.
Las características de multiplexión de una instancia ASM minimizan la posibilidad de pérdida de datos y es generalmente más efectiva que un esquema manual que pone ficheros críticos y ficheros de respaldo en diferentes unidades físicas.
Gestión automática de deshacer.
Para soportar nuestras transacciones, Oracle puede crear y administrar dinámicamente segmento de deshacer, los cuales ayudan a mantener imágenes prioritarias de los bloques y filas cambiadas. Los usuarios que consultaron previamente las filas que hemos cambiado todavía verán las filas tal como existían cuando las consultaron. La gestión automática de deshacer (AUM) permite a Oracle administrar los segmentos de deshacer directamente sin la intervención del administrador de base de datos. El uso de AUM también simplifica el uso de consultas de flashback.
Desde Oracle Database 10g, podemos ejecutar consultas de versiones pasadas para ver diferentes versiones de un fichero tal como ha cambiado durante un intervalo de tiempo específico.
Datos eliminados.
El concepto de cajón de reciclado introducido con Oracle Database 10g afecta a las exigencias de espacio requerido para nuestros tablespaces y ficheros de datos. En Oracle Database 11g el comportamiento por defecto para el borrado de una tabla es que la tabla retenga su espacio asignado; podemos ver este espacio usando la vista RECYCLEBIN del diccionario de datos. Si creamos y borramos una tabla dos veces, habrá dos copias de la tabla en el cajón de reciclado. Aunque esta arquitectura simplifica enormemente las recuperaciones de borrados de tablas accidentales, puede incrementar considerablemente el espacio usado por la base de datos. Se usa el comando PURGE para quitar entradas antiguas del cajón de reciclado.
1.4.2. Guardando los datos.
Podemos controlar completamente el acceso a nuestros datos. Podemos conceder privilegios a otros usuarios para realizar funciones específicas (como seleccionar, insertar y más) sobre nuestros objetos. Podemos adquirir privilegios desde roles, los cuales son entonces concedidos a los usuarios, agrupando así privilegios dentro de conjuntos manejables.
Oracle soporta un nivel muy detallado de permisos; podemos controlar qué filas son accesibles y, durante auditoría, qué filas desencadenan eventos de auditoria que sean registrados. Cuando se usa la opción Base de datos Privada Virtual (VPD), las consultas de usuario sobre tablas son siempre limitadas independientemente del método a través del cual se accede a las tablas. Desde Oracle Database 10g, VPD ha ido más lejos incluyendo enmascaramiento de columna para columnas que contienen datos sensibles.
Además del acceso seguro a los datos, podemos auditar actividades en la base de datos. Los eventos auditables incluyen acciones privilegiadas (como crear usuarios), cambios en las estructuras de datos y accesos a filas y tablas específicas.
1.4.3. Soporte para programación.
Oracle soporta una gran cantidad de métodos de acceso a programación. El lenguaje SQL es la clave para cualquier esfuerzo de programación de aplicaciones. Otros métodos de acceso incluyen los siguientes:
■ PL/SQL.PL/SQL es un componente crítico en la implementación de muchas aplicaciones. Podemos
usar PL/SQL para crear procedimientos y funciones almacenados, y entonces podemos llamar a las funciones dentro de consultas. Los procedimientos y funciones pueden ser recolectados dentro de paquetes. También podemos crear desencadenadores (triggers), los cuales dicen a la base de datos qué pasos deben seguir con varios eventos que ocurren dentro de la base de datos. Los triggers pueden ocurrir durante eventos de la base de datos (como el acceso inicial a la base de datos), cambios en la estructura (como un intento de borrar tablas), o cambios en las filas. En cada caso, se usa PL/SQL para controlar el comportamiento de la base de datos o aplicaciones en los cuales ocurren los eventos.
■ SQL Dinámico. Podemos generar SQL en tiempo de ejecución y pasarlo a procedimientos que lo
ejecuten a través de SQL Dinámico.
■ SQL*Plus. SQL*Plus proporciona una interfaz sencilla para las bases de datos de Oracle. SQL*Plus
puede soportar requerimientos de informes rudimentarios, pero es mejor conocerlo para soportar scripting. Proporciona una interfaz consistente para recuperar datos del diccionario de datos y crear objetos en la base de datos.
■ Java y JDBC. Oracle da soporte a Java y JDBC, permitiéndonos usar Java en lugar de PL/SQL en
muchas operaciones. Podemos todavía escribir procedimientos almacenados basados en Java. Las capacidades del Java de Oracle han sido ampliadas y realzadas con cada nueva versión.
■ XML. Podemos usar interfaces y tipos XML de Oracle para soportar la inserción y recuperación de
datos en formato XML.
■ SQL y PL/SQL orientados a objetos. Podemos usar Oracle para crear y acceder a estructuras
orientadas a objetos, incluyendo tipos de datos definidos por el usuario, métodos, objetos grandes (LOB's), tablas de objetos, y tablas anidadas.
■ Data Pump. «Data Pump Import» y «Data Pump Export», ambos introducidos en Oracle Database
10g, realzan enormemente la manejabilidad y rendimiento de las recientes utilidades de importación y exportación. Podemos usar Data Pump para extraer rápidamente datos y moverlos a diferentes bases de datos mientras alteramos el esquema y cambiamos las filas.
■ SQL*Loader. Podemos usar SQL*Loader para cargar rápidamente ficheros planos dentro de tablas de
Oracle. Un único fichero plano puede ser cargado dentro de varias tablas durante la misma carga, y la carga puede ser paralela.
■ Programas y procedimientos externos. Podemos embeber SQL dentro de programas externos, o
podemos crear librerías de procedimientos que más tarde sean enlazadas a Oracle.
■ UTL_MAIL. Un paquete introducido en Oracle Database 10g, UTL_MAIL, permite a programadores de aplicaciones PL/SQL enviar correos electrónicos sin tener que conocer la pila de protocolos SMTP subyacente.
1.5. Selección de arquitecturas y opciones.
Oracle proporciona un completo conjunto de herramientas para programar aplicaciones basadas en Oracle Database 11g. Podemos usar el servidor de aplicaciones de Oracle como la capa intermedia para aplicaciones de tres capas que acceden a Oracle Database 11g.
Muchas de las funcionalidades introducidas con Oracle Database 11g estarán disponibles independientemente de la arquitectura de aplicación seleccionada. Estas funcionalidades incluyen administración de base de datos como gestión automática de almacenamiento, tuneado automático, y redimensionado automático de las áreas de memoria en el SGA.
Oracle proporciona un conjunto de procedimientos que ayudan a gestionar la planificación de refresco de las vistas materializadas. Por ejemplo, podemos ejecutar un procedimiento que genere una descripción de los problemas con los refrescos y las configuraciones que nos impiden usar las opciones más rápidas posibles. Podemos usar otro procedimiento de Oracle para generar recomendaciones para tunear estructuras de vistas materializadas según un conjunto de consultas previstas.
nuestra aplicación o nuestro código. Por ejemplo, desde Oracle Database 10g están disponibles búsquedas usando expresiones regulares.
2. Instalar Oracle Database 11g y crear una base de datos
El software de instalación del Oracle se hace más fácil de usar con cada nueva versión; basta con abrir la caja de cedés y comenzar la instalación enseguida. Si queremos experimentar con alguna nueva funcionalidad de base de datos, se requiere una mayor planificación para realizar una instalación sucesiva sin tener que hacer todo el trabajo de reinstalación. En este capítulo veremos lo básico de una instalación de Oracle usando el Instalador Universal de Oracle (OUI), así como una plantilla básica para hacer una instalación manual de la base de datos usando el comando CREATE.
Las siguientes cosas deben ser resueltas antes de empezar la instalación:
• Decidir un nombre de base de datos local, y en qué dominio será contenido la base de datos. Estos nombres serán asignados en los parámetros de inicialización DB_NAME y DB_DOMAIN.
• Para el primer proyecto que usará la base de datos, estimar el número de tablas e índices, así como su tamaño, para planificar el espacio en disco además del requerido por los tablespace SYSTEM y el software y herramientas asociadas de Oracle.
• Planificar la ubicación de los ficheros de datos físicos en el disco del servidor para maximizar el rendimiento y recuperación. En general, cuantos más disco físicos mejor. Si un RAID o Almacén de red son usados por los ficheros de datos, podemos usar el «Administrador de Ficheros de Oracle» para gestionar la ubicación de los ficheros de datos. Desde Oracle Database 10g podemos usar almacenamiento automático (ASM) para simplificar la gestión de almacenamiento.
• Revisar y comprender los parámetros básicos de inicialización.
• Seleccionar el juego de caracteres de la base de datos, con un juego de caracteres alternativos. Aunque podemos dejar el juego de caracteres por defecto aplicado durante la instalación, podemos necesitar considerar dónde estarán localizados los usuarios de la base de datos y sus requerimientos de idioma. El juego de caracteres puede ser cambiado después de la instalación sólo si el nuevo juego de caracteres es un superjuego del existente.
• Decidir el mejor tamaño por defecto de los bloques de base de datos. El tamaño por defecto definido por DB_BLOCK_SIZE no puede ser cambiado después sin reinstalar la base de datos. Oracle puede soportar varios tamaños de bloques dentro de una única base de datos.
• Planificar el almacenamiento de objetos de usuarios distintos de SYSTEM en tablespaces distintos de
SYSTEM. Hay que asegurarse de que todos los usuarios no administrativos son asignados a un tablespace distinto de SYSTEM por defecto.
• Planificar la implementación del «Administrador Automático de Deshacer» para que sea fácil la administración de transacciones que rehagan al información.
• Planificar una estrategia de copias de seguridad y recuperación. Decidir cómo la base de datos necesita ser recuperada, y cuánto a menudo. Planificar usar más de un método para recuperar la base de datos.
2.1. Descripción de la licencia y opciones de instalación.
Una instalación inicial acertada del software es el primer paso. Independientemente de la plataforma de software y hardware sobre la cual decidamos instalar Oracle, los tipos de instalaciones que podemos realizar son los mismos. Aunque puede haber cambios en cada versión del producto, normalmente se incluyen los siguientes tipos de instalación:
• Edición Empresarial. Es la versión más extensa, con más funcionalidades. Incluye funciones como
Flashback Database y permite añadir piezas adicionales de funcionalidades con licencia, como Oracle Spatial, Oracle OLAP, Oracle Label Security, y Oracle Data Mining.
• Edición Estándar. Esta versión proporciona un buen subconjunto de funcionalidades, incluyendo las
que necesitan la mayoría de negocios.
• Edición Personal. Esta versión permite el desarrollo de aplicaciones que se ejecutarán sobre la Edición
Estándar o Empresarial. Esta edición no puede ser usada en un entorno de producción.
Desde Oracle Database 10g, la licencia de Oracle es sólo para un nombre de usuario o una CPU, y no hay la opción de licenciar a usuarios concurrentes. Por lo tanto, el DBA debería usar el parámetro de inicialización
LICENSE_MAX_USERS para especificar el número máximo de usuarios que pueden ser creados en la base de datos. Como resultado, los parámetros LICENSE_MAX_SESSIONS y LICENSE_SESSIONS_WARNING están obsoletos en Oracle Database 11g.
Además, el servidor de Oracle puede ser instalado durante una instalación del lado servidor o cliente. Sin embargo, es recomendable que esta instalación sea realizada después de que una instalación básica sea completada.
2.1.1. Usando OUI para instalar el software de Oracle.
Usaremos el «Instalador Universal de Oracle» (OUI) para instalar y administrar todos los componentes de Oracle tanto en el lado servidor como el lado cliente. Podemos también desinstalar cualquier producto de Oracle desde la pantalla inicial del OUI.
Durante la instalación del servidor, podemos elegir la versión de Oracle Database 11g: Empresarial, Estándar, o una de las otras opciones disponibles para nuestra plataforma. Es recomendable crear una base de datos de arranque cuando nos lo soliciten durante la instalación. Crear la base de datos de arranque es un buen modo de asegurarnos de que el entorno servidor se instale correctamente, así como repasar cualquier nueva funcionalidad de Oracle Database 11g. La base de datos de arranque también puede ser un buen candidato como repositorio tanto del «Administrador Empresarial de Oracle» (OEM) como del «Administrador de Recuperación».
El flujo exacto del proceso de instalación puede cambiar dependiendo de nuestro entorno operativo y la versión de Oracle.
Nota. En entornos UNIX, necesitamos asignar un valor apropiado a la variable de entorno DISPLAY
y habilitar xhost previamente para empezar el OUI a través del script runInstaller. En general, los pasos serán como sigue:
1) En la pantalla de apertura, elegir entre instalar un producto o desinstalar un producto previamente instalado.
2) Especificar la ubicación del fichero fuente para el producto que queremos instalar y el directorio inicial dentro del cual el software de Oracle será instalado. El instalador debería presentarnos valores por defecto. En general, los valores por defecto para los archivos fuente de software deberían ser válidos, mientras que otros pueden necesitar ser cambiados.
3) Seleccionar un producto a instalar. Nuestras opciones incluirán la base de datos y el cliente. Si seleccionamos la opción "database", el OUI instalará un base de datos de arranque preconfigurada, opciones de producto, herramientas administrativas, servicios de red, utilidades, herramientas de desarrollo, precompiladores, y software cliente básico.
Para la primera instalación, deberíamos usar la opción "database" para crear la base de datos de arranque. 4) Elegir el tipo de instalación: Edición Empresarial, Edición Estándar, o personalizada.
5) Si se ha elegido la opción "database" en el paso 3, ahora se nos pedirá que confirmemos la creación de la base de datos de arranque.
6) Se nos pedirá que elijamos entre configuraciones de base de datos estándar: propósito general, procesamiento de transacciones, o depósitos de datos (warehouse).
7) Para la base de datos de arranque, elegir las opciones de configuración. Estas opciones incluyen el nombre global de la base de datos, el nombre de la instancia, el juego de caracteres, y si incluimos o no esquemas de ejemplo.
8) Especificar una única contraseña que será usada por todos los esquemas precargados en la base de datos de arranque, o contraseñas independientes para cada cuenta.
9) Especificar la opción de almacenamiento que se usará. Si estamos usando ficheros del sistema, especificar los directorios a usar. Otras opciones incluyen administración automática de almacenamiento y dispositivos raw.
10) Nos solicitarán finalizar la selección de opciones de administración y servicios previos para aceptar la configuración e inicio de la instalación.
Durante la instalación del software, el «Asistente de Configuración de la Base de datos» (DBCA) nos solicita los parámetros necesarios de tamaño y configura nuestra base de datos (comenzando en el paso 6). Los pasos de instalación en la siguiente sesión asumen que hemos completado la instalación del software y creado una base de datos de arranque. Ahora crearemos y configuraremos una segunda base de datos sobre el mismo servidor con DBCA.
Nota. Desde Oracle 10g, DBCA puede configurar nodos en un entorno de «Real Application
2.1.2. Usando el DBCA para crear una base de datos.
En UNIX, podemos comenzar el «Asistente de Configuración de la Base de datos» (DBCA) ejecutando el fichero dbca ubicado en el directorio $ORACLE_HOME/bin. Debemos configurar la variable de entorno
DISPLAY y asignar xhost antes de empezar el DBCA. En Windows, el DBCA está ubicado en el submenú "Herramienta de configuración y migración" del menú "Oracle".
En las subsecciones que siguen, se indican pautas y guías para la mayor parte de las pantallas durante la creación de la base de datos.
Opciones del DBCA.
Después de una pantalla de bienvenida inicial, se nos presenta una selección de cuatro opciones:
■ Crear una base de datos. Esta opción crea una nueva base de datos desde el principio, usando una
plantilla como punto de partida.
■ Configurar opciones de base de datos en una base de datos. Esta opción permite cambiar alguno
de los parámetros de sistema para una instalación de base de datos existente, como cambiar desde un servidor dedicado a un servidor compartido.
■ Eliminar una base de datos. Esta opción elimina todos los ficheros de datos y ficheros de control
asociados con la base de datos. Necesitamos la contraseña del usuario SYS o SYSTEM para ejecutar esta opción.
■ Administrar plantillas. Esta opción permite añadir, modificar o eliminar plantillas. Durante una sesión
del DBCA, una vez que todos los parámetros de base de datos han sido reunidos, tenemos la opción de guardar las asignaciones como una plantilla. En muchos casos, las plantillas predefinidas que Oracle proporciona no son exactamente perfectas para nuestro entorno, y ahorra tiempo poder guardar nuestras opciones como una plantilla para una futura sesión del DBCA.
Seleccionando una plantilla de base de datos.
La figura siguiente muestra la lista de plantillas disponibles. Si creamos una plantilla en una sesión previa del DBCA aparecerá en esta pantalla también.
Las plantillas a seleccionar son las siguientes:
■ Base de datos personalizada. Se usa esta opción si hemos realizado muchas instalaciones y sabemos
de antemano los valores para todas las opciones que necesita la base de datos. Esta opción es mejor si creamos una nueva plantilla desde el principio o tenemos exigencias muy específicas para la configuración de nuestra base de datos.
■ Depósito de datos. Esta plantilla es para entornos de base de datos donde los usuarios realizan
■ Propósito general. Si todavía no estamos seguros de para qué se empleará nuestra base de datos, o si
tenemos que soportar a usuarios con requerimientos de procesamiento analítico y transaccional, se recomienda esta plantilla.
■ Procesamiento de transacciones. En entornos donde el número de usuarios es alto, las transacciones
son pesadas pero cortas, y la mayor parte de la actividad es crear y actualizar, se recomienda esta plantilla. Para continuar con la instalación, seleccionaremos la plantilla de propósito general. Esta plantilla combina las funcionalidades de los depósitos de datos y un entorno OLTP en una única base de datos.
Identificación de la base de datos.
En el siguiente paso del DBCA, debemos identificar el nombre de la instancia junto con el nombre de la base de datos global.
Nota. Si el nombre de la base de datos global necesita ser cambiado en el futuro, debemos usar el
comando ALTER DATABASE para cambiarlo, además de cambiarlo en el fichero de parámetros de inicialización. El nombre de la base de datos global es almacenado en el diccionario de datos cuando se crea la base de datos.
A menos que tengamos un dominio existente, debemos usar el nombre de dominio por defecto .world. Deberíamos comprobar con el administrador de sistemas si deberíamos usar un nombre específico para la base de datos global.
Credenciales de la base de datos.
La siguiente figura muestra la pantalla de asignación de contraseñas para las cuentas de usuario SYS y
SYSTEM. Después de la instalación, debemos asegurarnos de crear al menos una cuenta con privilegios DBA
para no tener que usar los usuarios SYS o SYSTEM en las tareas administrativas del día a día.
En esta pantalla, podemos también indicar que esta instancia sea incluida como un nodo administrativo en un entorno de Administración Empresarial de Oracle (OEM) existente, o podemos especificar esta instancia como un repositorio OEM. Si especificamos esta instancia como un repositorio OEM, es extremadamente recomendable que este nodo sea usado sólo para este propósito.
Opciones de almacenamiento.
Las bases de datos pueden usar una cantidad de métodos diferentes para almacenar ficheros de datos, ficheros de control y ficheros de deshacer. La siguiente figura muestra la pantalla donde podemos seleccionar el mecanismo de almacenamiento.
Si tenemos la posibilidad de dedicar otra instancia de base de datos para administrar espacio de disco, debemos elegir la opción ASM. Si estamos en un entorno «Real Application Clusters» y no tenemos un sistema de ficheros de clúster disponible (como un OCFS) debemos elegir la opción "Raw Devices".
Localización de ficheros.
En la pantalla mostrada a continuación es donde podemos seleccionar la localización de los archivos de datos, ficheros de control, ficheros de deshacer, así como las localizaciones de archivado, copias de seguridad y recuperación.
Un concepto nuevo desde Oracle Database 10g es el Área de Recuperación Flash. Ésta es una localización del disco dedicada, separada de la localización de los ficheros operacionales de la base de datos, que contiene
ficheros de respaldo del Administrador de Respaldo (RMAN). Es altamente recomendado usar el Área de Recuperación Flash para que el RMAN pueda administrar más fácilmente copias de respaldo y operaciones de recuperación. Deberemos asegurarnos de que el Área de Recuperación Flash tenga el espacio necesario para al menos dos copias de todos los ficheros de datos, copias de respaldo incrementales, ficheros de control, SPFILE's, y ficheros de deshacer que están todavía en el disco.
Podemos también habilitar el modo ARCHIVELOG, para especificar la localización o localizaciones de los ficheros de deshacer. Se recomienda dejar el archivado deshabilitado hasta que la base de datos se instale, porque habilitarlo incrementa el tiempo de creación de la base de datos. Los parámetros para el modo
ARCHIVELOG pueden ser modificados fácilmente en el fichero init.ora o el SPFILE inmediatamente después de que la base de datos esté activa y ejecutándose.
Componentes de la base de datos.
En el siguiente paso de la sesión del DBCA, se nos pregunta acerca de la instalación de los esquemas de ejemplo. En bases de datos de no-producción, es altamente recomendable instalar esquemas de ejemplo; muchos tutoriales y guías de estudio se apoyan en los esquemas de ejemplo de la base de datos. Son también útiles en esto los ejemplos demostrativos de casi todos los tipos de datos y constructores disponibles en la base de datos, rangos de mapas de índices para tablas en clústeres y tipos de objetos.
Parámetros de inicialización.
La siguiente pantalla mostrada a continuación permite al DBA ajustar los parámetros clave de inicialización para la base de datos.
La figura muestra la ficha de Memoria. Si seleccionamos típica (Typical) o si seleccionamos personalizada (Custom) con administración automática de la memoria compartida, Oracle hará asunciones acerca de la memoria que podemos usar para el SGA y los procesos de segundo plano. Incluso usando por defecto muchos de los parámetros en una configuración típica, todavía podemos especificar qué cantidad de la memoria física del servidor debería usar Oracle, dependiendo de cuánta memoria es usada por el sistema operativo y si cualquier otra aplicación está siendo ejecutada en este servidor junto con Oracle. El valor para Java Pool debe ser al menos el tamaño de una fracción de la base de datos, entre 4 MB o 16 MB, pero al menos se recomiendan 20MB.
Las últimas pantallas de esta sección del DBCA permiten especificar el tamaño de bloque por defecto de la base de datos, el número total de procesos que serán simultáneamente conectados, el modo de conexión usado, y el juego de caracteres para la base de datos.
Almacenamiento de la base de datos.
ficheros de control, ficheros de datos y ficheros de deshacer, así como multiplexar los ficheros de control y crear grupos de ficheros de deshacer. Los nombres y localizaciones de los ficheros de control en esta pantalla determinan el valor de CONTROL_FILES en el fichero de parámetros de inicialización.
Opciones de creación.
En la siguiente figura se muestra la pantalla para crear la base de datos. Además, podemos usar la información proporcionada en las pantallas previas y guardarla en una plantilla. Ante la duda guardar como una plantilla; el almacenamiento requerido para guardar sólo una plantilla es mínimo y puede fácilmente ser suprimido más tarde por nueva ejecución del DBCA.
Antes de que la base de datos sea creada, se presenta un resumen de nuestra plantilla, y tenemos la opción de guardar este informe como un archivo HTML para propósitos de documentación.
Completando la instalación.
Después de pulsar el botón "OK" de la pantalla de resumen, el DBCA realiza las tareas necesarias para crear la base de datos e iniciar la instancia. Se ejecuta un conjunto de scripts estándar cuando la base de datos inicia por primera vez; esto incluye el script que crea los esquemas de ejemplo, más cualquier script personalizado especificado previamente. El conjunto estándar de scripts varía dependiendo de las opciones seleccionadas a través del DBCA.
Una vez completados los scripts de inicialización y creación, se presenta una pantalla de resumen, mostrando la localización de los ficheros de registro de esta instalación. Es recomendable revisar estos ficheros de registro para asegurarnos que no ocurrieron errores durante la instalación. Deberíamos también guardar este fichero de registro con otra documentación de esta base de datos; esto puede ser útil para futuras instalaciones.
La base de datos de Oracle recién creada es activada y ejecutada. Tenemos la opción de desbloquear otras cuentas creadas durante esta instalación y asignarles contraseñas.
2.1.3. Creación manual de una base de datos.
El DBCA puede soportar requerimientos de instalación complejos. Por ejemplo, si necesitamos crear la misma base de datos en varios servidores, podemos usar el DBCA para crear y ejecutar plantillas. Podemos crear manualmente una base de datos en vez de usar el DBCA. Oracle proporciona un script de ejemplo de creación de base de datos que puede ser personalizado para una instalación manual.
A continuación se describen los pasos necesarios para crear una base de datos manualmente. Algunos de estos pasos son dependientes del sistema operativo o de la plataforma. Por ejemplo, bajo Windows necesitamos ejecutar la utilidad oradim para crear el proceso de fondo de Oracle y para asignar los valores de
