GDII › Repaso para el examen de conocimientos
00

Gerenciamiento de Datos II

Dashboard interactivo de repaso de las semanas 1 a 5: arquitectura de Oracle Database, gestión de la instancia, SQL DDL y seguridad.

Oracle Database 19cS01–S05Teoría + guías de laboratorioAutoevaluación
10temas de repaso
15simuladores interactivos
20preguntas de quiz
60+comandos y vistas

Mapa de temas

1 de 13
S01 › Arquitectura › Instancia
01

Instancia Oracle

La parte viva del servidor: estructuras de memoria y procesos background que dan acceso a la base de datos.

SGAPGADBWn · LGWR · CKPTSMON · PMON · ARCn

Oracle Server = instancia + base de datos

Un servidor Oracle tiene dos partes que no deben confundirse. La instancia es el medio para acceder a los datos: estructuras de memoria y procesos background que viven mientras el servicio está arriba. La base de datos es una colección de archivos en disco que se tratan como una unidad.

🧠

Instancia

Memoria (SGA y PGA) más procesos background. Se crea en cada STARTUP y desaparece en cada SHUTDOWN.

Lógica · volátil
💽

Base de datos

Datafiles, control files y online redo log files. Persisten aunque el servidor se apague.

Física · persistente
⚠️
Perder la instancia no es un problema grave: se vuelve a iniciar y SMON la recupera. Perder los datafiles sin respaldo equivale a perder la base de datos.

Estructuras de memoria

EstructuraÁmbitoQué guarda
Database Buffer CacheSGACopias en memoria de los bloques leídos de los datafiles. Los bloques modificados y aún no escritos se llaman dirty buffers.
Redo Log BufferSGARegistro de cada cambio realizado, antes de que LGWR lo lleve a disco.
Shared PoolSGASentencias SQL ya analizadas (library cache) y la caché del diccionario de datos.
Large PoolSGAÁrea opcional para operaciones que consumen mucha memoria, como respaldos.
PGAPrivadaMemoria exclusiva de cada proceso servidor: variables de sesión y áreas de ordenamiento.

Procesos background

Escribe los bloques modificados del Database Buffer Cache a los datafiles. No escribe en cada COMMIT, sino cuando ocurre alguno de estos eventos:

  • Un checkpoint.
  • No quedan buffers libres.
  • Un tablespace pasa a OFFLINE, READ ONLY o BEGIN BACKUP.
  • Se ejecuta DROP o TRUNCATE sobre una tabla.

Escribe de forma secuencial el Redo Log Buffer en los online redo log files, con fines de recuperación. Se activa cuando:

  • Hay un COMMIT.
  • El buffer está lleno en un tercio o más.
  • Pasan 3 segundos (timeout).
  • Antes de que DBWn escriba un bloque modificado.

Genera un SCN y actualiza los control files y las cabeceras de los datafiles con la información del punto de control. Es clave para la recuperación porque marca hasta dónde los datos en disco están al día.

Ejecuta la recuperación de la instancia tras una caída: aplica los cambios registrados en el redo, abre la base de datos y revierte las transacciones no confirmadas, dejándola en un estado estable.

Vigila los procesos de usuario. Si una sesión pierde la conexión, deshace su transacción, libera los bloqueos de tablas o filas y otros recursos. También supervisa a otros procesos background.

Proceso opcional. Copia automáticamente los redo logs llenos a archive logs cuando la base de datos está en modo ARCHIVELOG, conservando el historial completo de cambios.

🔍

Consultar la instancia

Comandos de SQL*Plus y vistas V$

Estas consultas confirman qué instancia está arriba y cómo está repartida su memoria.

sqlplus sys/oracle as sysdba
SQL> show sga
SQL> show user
SQL> select instance_name, status from v$instance;
SQL> select name, open_mode from v$database;
💡
El valor de STATUS en v$instance refleja el estado de inicio: STARTED equivale a NOMOUNT, MOUNTED a MOUNT y OPEN a base de datos abierta.
El área de soporte de una caja municipal reporta que “la base de datos está caída”. Te conectas como SYSDBA y show sga devuelve valores, pero select name from v$database responde ORA-01507.

La instancia sí está iniciada (hay SGA), pero la base de datos no está montada. El problema no es de memoria ni de procesos, sino de la fase MOUNT: hay que revisar el control file y el alert log.

🧩

Clasifica los componentes

Simulador · drag & drop

Ubica cada componente en la parte de la arquitectura a la que pertenece.

🧠

Arquitectura de Oracle Server

Clasificación de memoria, procesos y archivos

⏱️

¿Quién escribe y cuándo?

Tabla de disparadores
EventoProceso que actúaDestino en disco
COMMIT de una transacciónLGWROnline redo log files
CheckpointCKPT y DBWnCabeceras, control file y datafiles
Buffer cache sin espacio libreDBWnDatafiles
Redo log lleno en modo ARCHIVELOGARCnArchive log files
Sesión de usuario caídaPMONNo escribe: libera recursos
Inicio tras SHUTDOWN ABORTSMONAplica redo y revierte con UNDO
📝
Regla de examen: el redo siempre se escribe antes que el dato. LGWR graba antes de que DBWn escriba el bloque modificado.

La planilla que no se perdió

Análisis
En una empresa textil de Gamarra, la asistente de RR. HH. confirma con COMMIT el pago de 240 trabajadores. Dos segundos después se va la luz y el servidor se apaga sin UPS. Al volver la energía, el DBA inicia la base de datos y los 240 pagos están registrados.
  1. ¿Qué proceso garantizó que el cambio sobreviviera al corte?
  2. ¿Estaban los bloques modificados necesariamente en los datafiles?
  3. ¿Qué proceso reconstruyó el estado al iniciar?

1. LGWR: al hacer COMMIT escribió el Redo Log Buffer en los online redo log files.

2. No. DBWn escribe de forma diferida; es muy probable que los bloques siguieran solo en el Database Buffer Cache, que se perdió con la memoria.

3. SMON, durante la recuperación de la instancia, reaplicó los cambios desde el redo y revirtió lo que no tenía COMMIT.

La sesión colgada

Diagnóstico
En un call center de Lima, el aplicativo de un operador se cierra de golpe mientras actualizaba el estado de un reclamo. Otros operadores no pueden modificar ese mismo reclamo durante unos segundos y luego todo vuelve a la normalidad.
  1. ¿Qué recurso quedó retenido?
  2. ¿Qué proceso lo liberó?
  3. ¿Se guardó el cambio del operador?

1. Un bloqueo de fila perteneciente a la transacción no confirmada.

2. PMON detectó la sesión fallida, deshizo la transacción y liberó los bloqueos.

3. No: al no existir COMMIT, la transacción se revirtió.

Memoria compartida o privada

Clasificación
Una fintech tiene 300 sesiones concurrentes. Muchas ejecutan la misma consulta de saldo y algunas generan reportes con ORDER BY sobre miles de filas.
  1. ¿Dónde se reutiliza el plan de la consulta repetida?
  2. ¿Dónde se realiza el ordenamiento de cada reporte?
  3. ¿Qué estructura evita leer del disco los mismos bloques una y otra vez?

1. En el Shared Pool, que guarda el SQL ya analizado para compartirlo entre sesiones.

2. En la PGA de cada proceso servidor; si no alcanza, se usa el tablespace temporal.

3. El Database Buffer Cache.

No. La instancia es memoria más procesos background; la base de datos son los archivos físicos. Puede existir una instancia iniciada sin base de datos montada (estado NOMOUNT), y los archivos existen aunque la instancia esté apagada.
No. El COMMIT dispara a LGWR, no a DBWn. DBWn escribe en lotes cuando hay un checkpoint, faltan buffers libres o por los otros eventos listados. Esto es lo que hace rápido al COMMIT: basta una escritura secuencial en el redo log.
SMON actúa a nivel de instancia: la recupera después de una caída. PMON actúa a nivel de sesiones: limpia lo que deja un proceso de usuario que falla y libera sus bloqueos. Un truco: S de System, P de Process.
Nada, si la base de datos está en NOARCHIVELOG, que es el modo por defecto: ARCn es opcional. En ARCHIVELOG, en cambio, un redo log lleno no puede reutilizarse hasta que haya sido archivado.
La SGA es compartida por todos los procesos de la instancia y se asigna al iniciar. La PGA es privada: cada proceso servidor tiene la suya y no es visible para los demás.
Porque registra en el control file y en las cabeceras de los datafiles hasta qué SCN los datos están escritos en disco. En una recuperación, SMON solo necesita aplicar el redo posterior a ese punto.
2 de 13
S01 › Arquitectura › Archivos de control y redo
02

Control file y redo log

Los archivos que sostienen la integridad y la recuperación: cómo se consultan, se multiplexan y se protegen.

V$CONTROLFILEV$LOG · V$LOGFILELog switchARCHIVELOG

Control file

Es un archivo binario, no editable, que registra toda la estructura física de la base de datos y mantiene su integridad. Está vinculado a una sola base de datos, se lee al pasar al estado MOUNT y se necesita durante toda la operación.

📛

Identidad

Nombre e identificador de la base de datos, fecha y hora de creación.

🗺️

Mapa físico

Tablespaces, nombre y ubicación de datafiles y redo log files.

🔢

Estado

Número de secuencia actual del redo, información de checkpoint y de undo.

🗄️

Historial

Información de archive logs y de respaldos.

✅
Buena práctica: tener como mínimo dos copias del control file y, de preferencia, tres en discos distintos. A esto se le llama multiplexar.

Online redo log

Los redo log files graban todos los cambios realizados en la base de datos y son el mecanismo de recuperación. Se organizan en grupos; cada grupo tiene uno o más miembros idénticos, idealmente en discos diferentes.

1
Grupo 1LGWR escribe hasta llenarlo
→
2
Log switchPasa al siguiente grupo y hay checkpoint
→
3
Grupo 2Ahora es el CURRENT
→
4
Grupo 3Y luego vuelve al grupo 1
STATUS en V$LOGSignificado
CURRENTGrupo en el que LGWR está escribiendo ahora.
ACTIVEYa no se escribe en él, pero aún se necesita para recuperar la instancia.
INACTIVEYa no se necesita para la recuperación de instancia; puede reutilizarse o eliminarse.
UNUSEDGrupo recién creado en el que todavía no se ha escrito.
📌
Restricciones: la instancia requiere al menos dos grupos, el grupo actual no puede eliminarse y no se puede eliminar el último miembro válido de un grupo.

Modo ARCHIVELOG

Por defecto la base de datos se crea en NOARCHIVELOG: al reutilizar un grupo, su contenido anterior se pierde. En ARCHIVELOG, ARCn copia cada redo log lleno a un archive log antes de que pueda reutilizarse.

AspectoNOARCHIVELOGARCHIVELOG
RecuperaciónSolo hasta el último respaldo completoDe todas las transacciones confirmadas
RespaldoCon la base de datos cerradaCon la base de datos abierta
Espacio en discoNo genera archivos extraRequiere administrar los archive logs
Reutilizar un redo llenoInmediatoSolo después de archivarlo
🗂️

Control files

Consulta y multiplexación
SQL> select status, name from v$controlfile;
SQL> select name, value from v$parameter where name = 'control_files';
SQL> show parameter control_files

-- Multiplexar: agregar una tercera copia
SQL> alter system set control_files =
       'C:\ORADATA\CDB\CONTROL01.CTL',
       'C:\FRA\CDB\CONTROL02.CTL',
       'D:\ORADATA\CONTROL03.CTL' scope=spfile;
SQL> shutdown immediate
-- copiar CONTROL01.CTL como D:\ORADATA\CONTROL03.CTL en el sistema operativo
SQL> startup
⛔
La copia física del control file debe hacerse con la instancia detenida. Si se copia con la base de datos abierta, el archivo queda inconsistente.
🔢

Ordena el procedimiento

Constructor de secuencia · tres escenarios

🔁

Redo log

Grupos, miembros y log switch
SQL> select group#, status, member from v$logfile;
SQL> select group#, sequence#, status from v$log;
SQL> alter system switch logfile;

SQL> alter database add logfile group 4 ('D:\ORADATA\REDO04A.LOG') size 50M;
SQL> alter database add logfile member 'E:\ORADATA\REDO01B.LOG' to group 1;
SQL> alter database drop logfile member 'E:\ORADATA\REDO01B.LOG';
SQL> alter database drop logfile group 4;
💡
Un miembro recién agregado aparece con estado INVALID en V$LOGFILE. Es normal: el estado se limpia cuando LGWR escribe en él por primera vez.
🔁

Log switch en vivo

Observa CURRENT, ACTIVE e INACTIVE

En una distribuidora de Arequipa se borra por error el archivo REDO02B.LOG, segundo miembro del grupo 2. El grupo conserva su miembro REDO02A.LOG.

La operación normal de la instancia no se ve afectada porque el grupo aún tiene un miembro válido; el alert log registra que no encuentra el archivo. Para corregirlo: alter database drop logfile member del miembro perdido y luego add logfile member … to group 2 para volver a multiplexar.

🗄️

ARCHIVELOG

Activar y desactivar
SQL> select name, log_mode from v$database;
SQL> select dest_name, status, destination from v$archive_dest where status = 'VALID';
SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;     -- o: alter database noarchivelog;
SQL> alter database open;
SQL> alter system switch logfile;

El arranque que se quedó a medias

Diagnóstico
En una cooperativa de ahorro de Huancayo, tras un mantenimiento de discos el DBA ejecuta STARTUP y obtiene “ORACLE instance started” seguido de ORA-00205. La consulta a v$instance muestra STATUS = STARTED.
  1. ¿En qué estado quedó la instancia y por qué?
  2. ¿Dónde se confirma qué archivo falta?
  3. ¿Cómo se recupera si existe otra copia del control file?

1. En NOMOUNT: la instancia inició, pero no pudo abrir todas las copias del control file indicadas en CONTROL_FILES, así que no pasó a MOUNT.

2. En el alert log (carpeta trace del directorio diag), que muestra ORA-00202 con la ruta del archivo y el error del sistema operativo.

3. SHUTDOWN IMMEDIATE, copiar la copia válida con el nombre y ruta del archivo faltante, y STARTUP. Luego verificar OPEN y READ WRITE.

Respaldos sin apagar la tienda

Decisión
Un e-commerce de Lima vende las 24 horas y no puede detener su base de datos para respaldar. Además, la gerencia exige no perder ninguna venta confirmada si falla un disco.
  1. ¿Qué modo de log necesita?
  2. ¿Qué proceso entra en juego?
  3. Escribe la secuencia para activarlo.

1. ARCHIVELOG: permite respaldar con la base abierta y recuperar todas las transacciones confirmadas.

2. ARCn, que archiva cada redo log lleno antes de que se reutilice.

3.

shutdown immediate
startup mount
alter database archivelog;
alter database open;

No me deja borrar el grupo

Interpretación
Una base de datos tiene tres grupos de redo. V$LOG muestra: grupo 1 INACTIVE, grupo 2 CURRENT, grupo 3 ACTIVE. El DBA quiere eliminar el grupo 2 para recrearlo con mayor tamaño.
  1. ¿Puede eliminarlo de inmediato?
  2. ¿Qué debe hacer primero?
  3. ¿Qué ocurriría si solo existieran dos grupos?

1. No: el grupo CURRENT no puede eliminarse.

2. Forzar un log switch con alter system switch logfile y esperar a que el grupo 2 quede INACTIVE (tras el checkpoint). Recién entonces drop logfile group 2 y borrar el archivo del disco.

3. Tampoco podría: la instancia exige un mínimo de dos grupos. Tendría que agregar primero el grupo nuevo.

No. Es un archivo binario que solo Oracle mantiene. Su contenido se consulta mediante vistas como V$CONTROLFILE o V$DATABASE, y su ubicación se cambia con el parámetro CONTROL_FILES.
El grupo es la unidad lógica en la que LGWR escribe; los miembros son copias idénticas de ese grupo en distintos archivos. Multiplexar significa tener dos o más miembros por grupo para que la pérdida de un archivo no signifique perder el redo.
Porque es un parámetro estático: no puede cambiar en la instancia en ejecución. Se graba en el archivo de parámetros y toma efecto en el siguiente inicio, momento en el que las copias físicas ya deben existir.
Ocurre de forma automática cuando el grupo actual se llena, o manualmente con ALTER SYSTEM SWITCH LOGFILE. En cada log switch se produce un checkpoint y la información se actualiza en el control file.
Porque el modo de log se registra en el control file y no puede cambiarse con los datafiles abiertos. Además, el cierre previo debe ser limpio, por eso se usa SHUTDOWN IMMEDIATE y no ABORT.
No. Los archivos existentes permanecen en el destino de archivado; simplemente dejan de generarse nuevos al hacer log switch.
3 de 13
S01 › Arquitectura › Almacenamiento
03

Tablespaces y datafiles

De la tabla al disco: tablespace, segmento, extent y bloque, y cómo administrar los archivos que los respaldan.

DBA_TABLESPACESDBA_DATA_FILESRESIZE · ADD · RENAMEUNDO · TEMP

Estructura lógica y física

Oracle separa cómo se organizan los datos (estructura lógica) de dónde se guardan en disco (estructura física). El punto de unión es el tablespace, que agrupa lógicamente los datos y está respaldado por uno o más datafiles.

1
TablespaceAgrupación lógica
→
2
SegmentoEspacio de un objeto
→
3
ExtentBloques contiguos
→
4
BloqueUnidad mínima
ElementoTipoReglas clave
TablespaceLógicoPertenece a una sola base de datos; contiene uno o más segmentos; puede ponerse OFFLINE o READ ONLY.
DatafileFísicoPertenece a un solo tablespace; puede redimensionarse o crecer automáticamente.
SegmentoLógicoEspacio asignado a una tabla o índice. No abarca varios tablespaces, pero sí varios datafiles del mismo tablespace.
ExtentLógicoConjunto de bloques contiguos; el segmento crece agregando extents.
Bloque de datosLógicoUnidad más pequeña que Oracle asigna, lee o escribe. Su tamaño estándar lo fija DB_BLOCK_SIZE al crear la base.
💡
Relaciones que suelen preguntarse: un tablespace tiene uno o muchos datafiles, pero un datafile pertenece a un único tablespace.

Tipos de tablespace

📚

SYSTEM

Contiene el diccionario de datos. No puede ponerse offline.

🧰

SYSAUX

Tablespace auxiliar para componentes de la base de datos.

↩️

UNDO

Guarda la imagen previa de los datos: rollback, lectura consistente y flashback.

🔃

TEMP

Usado para operaciones de ordenamiento que no caben en memoria.

👥

USERS

Tablespace por defecto para los usuarios creados después de la instalación.

🏢

De aplicación

Creados a demanda para separar los datos de cada sistema.

🏗️

Crear tablespaces

Permanente, UNDO y temporal
SQL> select tablespace_name, status from dba_tablespaces;
SQL> select tablespace_name, file_name, bytes from dba_data_files;

SQL> create tablespace datos_app
       datafile 'D:\ORADATA\PDB1\datos_app01.dbf' size 100M
       extent management local uniform size 1M;

SQL> create undo tablespace undo02
       datafile 'D:\ORADATA\undo02.dbf' size 50M;

SQL> create temporary tablespace temp02
       tempfile 'D:\ORADATA\PDB1\temp02.dbf' size 50M
       extent management local uniform size 1M;
📝
Los tablespaces temporales usan TEMPFILE en lugar de DATAFILE y se consultan en DBA_TEMP_FILES, no en DBA_DATA_FILES.
📐

Administrar datafiles

Redimensionar, agregar, mover y eliminar
SQL> alter database datafile 'D:\ORADATA\PDB1\datos_app01.dbf' resize 250M;
SQL> alter tablespace datos_app add datafile 'D:\ORADATA\PDB1\datos_app02.dbf' size 100M;

-- mover un datafile
SQL> alter tablespace datos_app offline normal;
--   (mover el archivo en el sistema operativo)
SQL> alter tablespace datos_app rename datafile
       'D:\ORADATA\PDB1\datos_app02.dbf' to 'E:\ORADATA\datos_app02.dbf';
SQL> alter tablespace datos_app online;

SQL> alter tablespace datos_app drop datafile 'E:\ORADATA\datos_app02.dbf';
SQL> drop tablespace datos_app including contents and datafiles;
🔢

Ordena el procedimiento

Constructor de secuencia · dos escenarios

🧮

Calculadora de capacidad

Simulador · cálculo en tiempo real

Estima cuántos extents y bloques ofrece un tablespace con extents uniformes y si alcanza para el volumen de datos previsto.

🧮

Capacidad de un tablespace

Datafiles × tamaño, extents uniformes y ocupación

Una clínica de Trujillo crea el tablespace HISTORIAS con un datafile de 2 MB y UNIFORM SIZE 100K. A las pocas semanas las inserciones fallan por falta de espacio.

Con 2 MB y extents de 100 KB solo hay unos 20 extents. Opciones: alter database datafile … resize para ampliar el archivo, o alter tablespace historias add datafile para sumar otro. Ambas se ejecutan con el tablespace en línea.

El disco D se llenó

Procedimiento
En una universidad, el datafile notas02.dbf del tablespace NOTAS está en el disco D, que alcanzó el 98 % de uso. Hay espacio libre en el disco E y el sistema de matrícula puede detenerse 10 minutos.
  1. ¿Qué estado debe tener el tablespace antes de mover el archivo?
  2. Escribe la secuencia de comandos.
  3. ¿Qué vista confirma el resultado?

1. OFFLINE. La base de datos sigue abierta; solo ese tablespace queda inaccesible.

2.

alter tablespace notas offline normal;
-- mover notas02.dbf de D: a E: desde el sistema operativo
alter tablespace notas rename datafile 'D:\ORADATA\notas02.dbf' to 'E:\ORADATA\notas02.dbf';
alter tablespace notas online;

3. DBA_DATA_FILES muestra la nueva ruta y DBA_TABLESPACES el estado ONLINE.

¿Lógico o físico?

Conceptual
Un practicante afirma: “La tabla VENTAS es un archivo .dbf, y si crece demasiado Oracle crea otra tabla”.
  1. ¿Qué estructura representa a la tabla dentro del almacenamiento?
  2. ¿Cómo crece esa estructura?
  3. ¿Puede la tabla ocupar dos datafiles? ¿Y dos tablespaces?

1. Un segmento, almacenado dentro de un tablespace. El .dbf es el datafile, que puede contener muchos segmentos.

2. Agregando extents, cada uno formado por bloques contiguos.

3. Sí puede abarcar varios datafiles siempre que sean del mismo tablespace; un segmento no puede abarcar varios tablespaces.

Sin espacio para ordenar

Diagnóstico
En una empresa de transporte, un reporte anual con ORDER BY sobre millones de registros falla indicando que no puede extender el segmento temporal.
  1. ¿Qué tipo de tablespace está involucrado?
  2. ¿Qué sentencia crearía uno adicional?
  3. ¿En qué vista se consultan sus archivos?

1. El tablespace temporal (TEMP), que se usa cuando el ordenamiento no cabe en la PGA.

2. create temporary tablespace temp02 tempfile '…' size 500M;

3. En DBA_TEMP_FILES.

No. La relación es de uno a muchos: un tablespace puede tener varios datafiles, pero cada datafile pertenece a un único tablespace de una única base de datos.
RESIZE cambia el tamaño de un archivo existente (ALTER DATABASE DATAFILE … RESIZE). ADD DATAFILE agrega un archivo nuevo al tablespace (ALTER TABLESPACE … ADD DATAFILE). Ambos aumentan la capacidad; el segundo permite además repartir los datos en otro disco.
Porque contiene el diccionario de datos, indispensable para que la base de datos funcione. Tampoco puede desconectarse un tablespace con un segmento UNDO activo.
Que el propio tablespace administra sus extents mediante un mapa interno y que todos tendrán el mismo tamaño. Simplifica la administración y evita la fragmentación.
Al eliminar el tablespace, borra también los segmentos que contiene y los archivos físicos del sistema operativo. Sin AND DATAFILES, los archivos quedan en disco y deben eliminarse manualmente.
El tamaño estándar se define con DB_BLOCK_SIZE al crear la base de datos y no se modifica luego. Por eso es una decisión de diseño inicial.
4 de 13
S02 › Gestión de instancia › Multitenant
04

Multitenant: CDB y PDB

Una instancia, muchos inquilinos: contenedores, estados de las PDBs y vistas del diccionario.

CDB$ROOTPDB$SEEDSHOW PDBSSAVE STATECDB_ vs DBA_

De la arquitectura tradicional a la multitenant

En la arquitectura tradicional cada base de datos tiene su propia instancia: su memoria, sus procesos y sus archivos. En la arquitectura multitenant, una sola instancia atiende a una base de datos contenedora (CDB) que aloja varias bases de datos conectables (PDB).

🏛️

CDB$ROOT

Contenedor raíz. Hay exactamente uno por CDB; guarda los metadatos y usuarios comunes.

CON_ID 1
🌱

PDB$SEED

Plantilla de solo lectura a partir de la cual se crean nuevas PDBs.

CON_ID 2
🧩

PDBs de usuario

Cero o más. Cada una es una colección de esquemas y objetos, vista por la aplicación como una base de datos independiente.

CON_ID 3 en adelante

Ventajas

  • Aumenta la escalabilidad y el aprovechamiento del servidor.
  • Permite administrar varias bases de datos como si fueran una.
  • Mantiene separadas las bases de datos sin cambiar las aplicaciones ni los accesos.
  • Facilita el mantenimiento, la clonación y el respaldo.
  • Gestión de recursos integrada para cumplir niveles de servicio.
⚖️
La contraparte: como todas las PDBs comparten una única SGA y los mismos procesos background, hay que dimensionar los recursos con mucha precisión.

Qué se comparte y qué no

ElementoÁmbito
SGA y procesos backgroundCompartidos por toda la CDB
Control files y online redo logsDe la CDB, comunes a todas las PDBs
UNDOEn el root (o local por PDB, según configuración)
Datafiles SYSTEM, SYSAUX y de aplicaciónPropios de cada PDB
Tablespace temporalCada PDB puede tener el suyo
Sesión conectada a una PDBSolo ve esa PDB
💡
Una PDB es compatible con una base de datos tradicional: la aplicación se conecta a su servicio y no necesita saber que vive dentro de un contenedor.
🔗

Conectarse y ubicarse

SQL*Plus
C:\> sqlplus /nolog
C:\> sqlplus sys/oracle@cdb as sysdba
SQL> connect sys/oracle@pdb_ventas as sysdba
SQL> show con_name
SQL> show con_id
SQL> show user
SQL> desc dba_tables
📎
Para conectarse a una PDB por nombre se necesita su entrada en TNSNAMES.ORA y que el HOST de LISTENER.ORA coincida con el nombre del servidor.
🚦

Estados de las PDBs

Abrir, cerrar y guardar estado
SQL> show pdbs
SQL> select name, open_mode, con_id from v$pdbs;
SQL> alter pluggable database pdb_ventas open;
SQL> alter pluggable database pdb_ventas close;
SQL> alter pluggable database all open;
SQL> alter pluggable database all close;
SQL> alter pluggable database pdb_ventas save state;
📌
Al reiniciar la CDB, las PDBs quedan en MOUNTED por defecto. SAVE STATE guarda el estado que tiene la PDB en ese momento: si está en READ WRITE, se abrirá sola en el siguiente reinicio.
🚦

Consola de PDBs

Abre, cierra, guarda estado y reinicia la CDB

Cada lunes, tras el reinicio programado del servidor, el sistema de almacén de una ferretería industrial no conecta hasta que alguien de TI “hace algo” en SQL*Plus.

La PDB queda MOUNTED después de cada reinicio y alguien la abre manualmente. Solución permanente: abrirla y ejecutar alter pluggable database pdb_almacen save state; para que se abra automáticamente.

📖

Diccionario en CDB y PDB

Vistas CDB_, DBA_ y V$
SQL> select instance_name, con_id from v$instance;
SQL> select file_name, tablespace_name, con_id from cdb_data_files order by tablespace_name;
SQL> select file_name, tablespace_name from dba_data_files;
SQL> select file_name, tablespace_name from dba_temp_files;
SQL> select group#, member, con_id from v$logfile;
SQL> select count(*) from cdb_objects;
SQL> select count(*) from dba_objects;
PrefijoAlcance
CDB_Todos los contenedores; incluye la columna CON_ID. Desde el root muestra la CDB completa.
DBA_Todo el contenedor al que se está conectado.
USER_Solo los objetos del esquema conectado.
V$Vistas dinámicas de rendimiento, alimentadas por la instancia y el control file.

Tres sedes, un servidor

Diseño
Una cadena de farmacias tiene tres bases de datos Oracle tradicionales (Lima, Cusco y Piura), cada una en su propio servidor con uso de CPU menor al 15 %. La gerencia quiere reducir costos de hardware y licencias sin modificar las aplicaciones.
  1. ¿Qué arquitectura propondrías?
  2. ¿Qué comparten y qué mantienen separado las tres sedes?
  3. ¿Qué riesgo debes advertir?

1. Una CDB con tres PDBs: PDB_LIMA, PDB_CUSCO y PDB_PIURA.

2. Comparten instancia (SGA y procesos background), control files y redo logs. Mantienen separados sus datafiles, esquemas y usuarios locales; cada aplicación sigue conectándose a su propio servicio.

3. El dimensionamiento: al compartir memoria y CPU, una PDB con carga excesiva puede afectar a las demás; además, una caída de la instancia afecta a las tres.

La consulta que devuelve distinto

Interpretación
Un analista ejecuta select count(*) from cdb_data_files conectado al root y obtiene 14. Luego se conecta a PDB_CUSCO, ejecuta select count(*) from dba_data_files y obtiene 4.
  1. ¿Por qué difieren los resultados?
  2. ¿Qué columna permite saber a qué contenedor pertenece cada archivo?
  3. ¿Qué mostraría show con_name en cada conexión?

1. CDB_DATA_FILES desde el root lista los datafiles de todos los contenedores abiertos; DBA_DATA_FILES solo los del contenedor actual.

2. CON_ID.

3. CDB$ROOT en la primera y PDB_CUSCO en la segunda.

Crear una PDB nueva

Conceptual
El área de BI solicita una base de datos aislada para pruebas. El DBA la crea en pocos minutos desde el asistente gráfico, indicando nombre, usuario administrador y contraseña.
  1. ¿De qué contenedor se copia la estructura inicial?
  2. ¿En qué estado conviene dejarla para que el equipo trabaje?
  3. ¿Qué archivo del cliente debe actualizarse para conectarse por nombre?

1. De PDB$SEED, la plantilla de solo lectura.

2. READ WRITE, con SAVE STATE para que se abra tras cada reinicio.

3. TNSNAMES.ORA, agregando una entrada con el nombre de servicio de la nueva PDB.

Exactamente uno de cada uno. Además puede tener cero o más PDBs creadas por el usuario.
Los comandos que se ejecutan en el laboratorio son ALTER PLUGGABLE DATABASE nombre OPEN y CLOSE, y ALL OPEN o ALL CLOSE para todas. Piensa en iniciar y detener como la idea, y en OPEN y CLOSE como la sintaxis.
Porque es una plantilla. Oracle la mantiene de solo lectura para que no se altere y pueda servir de base limpia al crear nuevas PDBs.
No. Todas las PDBs comparten la única instancia de la CDB: una SGA y un conjunto de procesos background. Por eso v$instance devuelve el mismo nombre de instancia desde cualquier contenedor.
MOUNTED significa que la PDB está cerrada: existe en la CDB, pero sus datos no son accesibles para los usuarios. READ WRITE significa que está abierta para lectura y escritura.
No. Las sesiones externas solo ven la PDB a la que se conectan. Esa separación es la que permite consolidar sin mezclar la información.
5 de 13
S02 › Gestión de instancia › Ciclo de vida
05

Inicio y apagado

Las etapas NOMOUNT, MOUNT y OPEN, y los cuatro modos de SHUTDOWN con sus consecuencias.

STARTUPALTER DATABASESHUTDOWN IMMEDIATERecuperación de instancia

Estados de inicio

Abrir una base de datos Oracle es un proceso de tres etapas. En cada una se lee un tipo de archivo distinto, y solo es posible avanzar hacia adelante.

1
SHUTDOWNInstancia detenida
→
2
NOMOUNTSe inicia la instancia
→
3
MOUNTSe abre el control file
→
4
OPENSe abren datafiles y redo logs
EstadoQué ocurrePara qué se usa
NOMOUNTSe lee el archivo de parámetros, se asigna la SGA y arrancan los procesos background.Crear una base de datos o recrear control files.
MOUNTSe abre el control file indicado en CONTROL_FILES.Cambiar el modo ARCHIVELOG, renombrar archivos, recuperar.
OPENSe abren todos los archivos descritos en el control file.Operación normal de los usuarios.
💡
El comando STARTUP sin opciones recorre las tres etapas de una sola vez. Con ALTER DATABASE se avanza manualmente: de NOMOUNT a MOUNT y de MOUNT a OPEN.

Modos de apagado

ComportamientoABORTIMMEDIATETRANSACTIONALNORMAL
Permite nuevas conexionesNoNoNoNo
Espera a que las sesiones terminenNoNoNoSí
Espera a que las transacciones terminenNoNoSíSí
Fuerza checkpoint y cierra archivosNoSíSíSí
🧼

Cierre consistente

NORMAL, TRANSACTIONAL e IMMEDIATE: se escriben los dirty buffers, se revierte lo no confirmado y no se requiere recuperación al iniciar.

Base limpia
💥

Cierre inconsistente

ABORT, falla de instancia o STARTUP FORCE: no se escriben los buffers ni se revierte nada. Al iniciar, SMON usa redo y UNDO para recuperar.

Base sucia
✅
Recomendación del curso: usar SHUTDOWN IMMEDIATE como apagado habitual y reservar ABORT para situaciones críticas.
▶️

Iniciar por etapas

STARTUP y ALTER DATABASE
SQL> startup nomount
SQL> alter database mount;
SQL> alter database open;

SQL> startup mount       -- llega directo a MOUNT
SQL> startup             -- llega directo a OPEN
SQL> select instance_name, status from v$instance;
SQL> select name, open_mode from v$database;
▶️

Máquina de estados de la instancia

Ejecuta comandos y observa el estado y los errores

⏹️

Apagar la instancia

Cuatro modos de SHUTDOWN
SQL> shutdown normal
SQL> shutdown transactional
SQL> shutdown immediate
SQL> shutdown abort

Completa la matriz marcando SÍ o NO en cada celda y luego presiona Verificar.

⏹️

Matriz de modos de apagado

Selecciona el modo de marcado y haz clic en las celdas

Son las 11:50 p. m. en una empresa de courier. El DBA debe apagar la base de datos para aplicar un parche a medianoche. Hay 40 sesiones conectadas, varias inactivas desde la tarde.

SHUTDOWN NORMAL esperaría indefinidamente a que las 40 sesiones se desconecten. La opción adecuada es SHUTDOWN IMMEDIATE: revierte las transacciones sin confirmar, desconecta las sesiones, hace checkpoint y deja la base consistente.

Mantenimiento en MOUNT

Procedimiento
El DBA de una aseguradora necesita activar el modo ARCHIVELOG. La base de datos está abierta y en uso.
  1. ¿En qué estado debe estar la base de datos para ejecutar el cambio?
  2. ¿Puede pasar de OPEN a MOUNT con ALTER DATABASE?
  3. Indica la secuencia completa.

1. En MOUNT.

2. No. Solo se avanza hacia adelante; para retroceder hay que apagar la instancia.

3. SHUTDOWN IMMEDIATE, STARTUP MOUNT, ALTER DATABASE ARCHIVELOG y ALTER DATABASE OPEN.

El apagado que no termina

Diagnóstico
Un operador ejecuta SHUTDOWN y la consola queda sin respuesta durante 20 minutos. No hay errores.
  1. ¿Qué modo se aplicó al no indicar opción?
  2. ¿Por qué no termina?
  3. ¿Qué habría sido mejor?

1. NORMAL, que es el modo por defecto.

2. Porque espera a que todas las sesiones conectadas se desconecten por sí mismas.

3. SHUTDOWN IMMEDIATE, o TRANSACTIONAL si se quería dejar terminar las transacciones en curso.

Después del ABORT

Análisis
Ante un bloqueo total del servidor de una empresa minera, el DBA ejecuta SHUTDOWN ABORT y luego STARTUP. La base de datos demora más de lo normal en abrir.
  1. ¿En qué condición quedó la base de datos tras el ABORT?
  2. ¿Qué hace Oracle durante ese tiempo adicional?
  3. ¿Se pierden las transacciones confirmadas?

1. Inconsistente: los buffers modificados no se escribieron y las transacciones pendientes no se revirtieron.

2. SMON recupera la instancia: reaplica los cambios desde los online redo logs y deshace lo no confirmado usando los segmentos UNDO.

3. No. Todo lo que tuvo COMMIT está en los redo logs y se reaplica.

En NOMOUNT, el archivo de parámetros. En MOUNT, el control file. En OPEN, los datafiles y los online redo log files.
No con ALTER DATABASE. La secuencia solo avanza: SHUTDOWN, NOMOUNT, MOUNT, OPEN. Para volver a un estado anterior se apaga la instancia y se inicia en el modo deseado.
No. Revierte únicamente las transacciones que no tenían COMMIT, escribe los buffers pendientes y cierra los archivos de forma consistente.
Cuando la instancia no responde a los otros modos o hay una situación crítica que afecta la seguridad o estabilidad del sistema. No daña los datos confirmados, pero obliga a una recuperación de instancia en el siguiente inicio.
STATUS = STARTED. En ese estado, consultar v$database devuelve ORA-01507 porque esa vista depende del control file, que aún no se ha abierto.
TRANSACTIONAL deja que cada transacción activa termine con su COMMIT o ROLLBACK antes de desconectar la sesión. IMMEDIATE no espera: revierte de inmediato lo que esté en curso.
6 de 13
Evaluación › Bloque 1
Q1

Quiz 1 · Arquitectura y gestión

Diez preguntas sobre los temas 01 a 05. Cada respuesta trae su explicación.

InstanciaRedo y control fileTablespacesMultitenantStartup y shutdown
7 de 13
S03–S04 › SQL DDL › Objetos
06

Objetos y tablas (DDL)

Los objetos de un esquema Oracle y las sentencias para crearlos, documentarlos y eliminarlos.

CREATE TABLETipos de datosDROP · TRUNCATEVistas · Secuencias · Sinónimos

Objetos de base de datos

📋

Tabla

Unidad básica de almacenamiento, compuesta por filas y columnas.

🪟

Vista

Representación lógica de datos de una o más tablas. Se guarda su definición, no los datos.

🔢

Secuencia

Genera valores únicos, por ejemplo para llaves primarias.

⚡

Índice

Estructura opcional que acelera el acceso a las filas.

🏷️

Sinónimo

Alias de otro objeto: tabla, vista, procedimiento, función o paquete.

Esquema y nombres

Un esquema es la colección de objetos que pertenecen a un usuario; por eso un objeto de otro esquema se referencia como esquema.objeto. Dos objetos no pueden tener el mismo nombre dentro del mismo esquema.

  • Los nombres sin comillas deben comenzar con una letra.
  • Pueden contener letras, números, guion bajo (_), signo dólar ($) y numeral (#).
  • No pueden ser palabras reservadas de Oracle.
  • No se recomienda usar nombres entre comillas.

Tipos de datos más usados

TipoDescripciónEjemplo
CHAR(n)Cadena de longitud fija; rellena con espacios.sexo CHAR(1)
VARCHAR2(n)Cadena de longitud variable hasta n.nombre VARCHAR2(50)
NUMBER(p,s)Número con precisión p y escala s (decimales).precio NUMBER(8,2)
DATEFecha y hora con precisión de segundos.fec_registro DATE DEFAULT SYSDATE
CLOB / BLOBObjetos grandes de texto o binarios.contrato CLOB

DROP, TRUNCATE y DELETE

AspectoDELETETRUNCATEDROP TABLE
CategoríaDMLDDLDDL
EliminaFilas (con o sin WHERE)Todas las filasFilas, estructura, índices, triggers y privilegios
Genera UNDOSíNoNo
ROLLBACK posibleSíNo: COMMIT implícitoNo (salvo papelera, si no se usó PURGE)
Con FK que la referenciaValida fila por filaNo permitido si la FK está activaRequiere CASCADE CONSTRAINTS
📌
DROP TABLE admite dos cláusulas: CASCADE CONSTRAINTS elimina las restricciones de integridad referencial que dependen de la tabla, y PURGE la borra sin pasar por la papelera de reciclaje, de modo que no hay flashback posible.
🏗️

Crear y documentar tablas

CREATE TABLE y COMMENT
CREATE TABLE almacen.producto (
  id_producto   NUMBER(6),
  descripcion   VARCHAR2(80)  NOT NULL,
  precio_lista  NUMBER(8,2),
  estado        CHAR(1)       DEFAULT 'A',
  fec_registro  DATE          DEFAULT SYSDATE
) TABLESPACE datos_app;

COMMENT ON TABLE  almacen.producto IS 'Catálogo de productos';
COMMENT ON COLUMN almacen.producto.id_producto IS 'Llave primaria';

DESC producto
DROP TABLE producto CASCADE CONSTRAINTS PURGE;
TRUNCATE TABLE producto;
💡
La cláusula TABLESPACE es opcional: si se omite, la tabla se crea en el tablespace por defecto del usuario.
🪟

Vistas, secuencias y sinónimos

Otros objetos de esquema
CREATE OR REPLACE VIEW v_producto_activo AS
  SELECT id_producto, descripcion, precio_lista
  FROM   producto WHERE estado = 'A';

CREATE SEQUENCE seq_producto START WITH 1 INCREMENT BY 1 NOCACHE;
INSERT INTO producto (id_producto, descripcion)
  VALUES (seq_producto.NEXTVAL, 'Taladro percutor');
SELECT seq_producto.CURRVAL FROM dual;

CREATE SYNONYM prod FOR almacen.producto;
Los vendedores de una importadora deben ver el catálogo, pero no el costo de compra ni el margen que también están en la tabla PRODUCTO.

Se crea una vista que selecciona solo las columnas permitidas y se otorga SELECT sobre la vista, no sobre la tabla. La vista no duplica datos: guarda únicamente la consulta.

📖

Diccionario de datos

¿Dónde consulto lo que creé?
VistaInformación
USER_TABLES / DBA_TABLESTablas del esquema o de toda la base
DBA_OBJECTSTodos los objetos y su tipo
USER_TAB_COLUMNSColumnas, tipo y longitud
USER_TAB_COMMENTS / USER_COL_COMMENTSComentarios de tablas y columnas
DBA_EXTENTSExtents asignados a un segmento
SELECT column_name, data_type, data_length
FROM   user_tab_columns WHERE table_name = 'PRODUCTO';

SELECT file_id, block_id, blocks FROM dba_extents
WHERE  owner = 'ALMACEN' AND segment_name = 'PRODUCTO' AND segment_type = 'TABLE';
🧩

Clasifica las sentencias

Simulador · drag & drop
🧩

¿DDL, DML, DCL o TCL?

Arrastra cada sentencia a su categoría

El borrado que no se pudo deshacer

Análisis
En una agencia de viajes, un analista quería limpiar los registros de prueba de la tabla COTIZACION. Ejecutó TRUNCATE TABLE cotizacion; notó que también había datos reales e intentó ROLLBACK, sin efecto.
  1. ¿Por qué el ROLLBACK no recuperó los datos?
  2. ¿Qué sentencia debió usar?
  3. ¿Qué más se truncó junto con la tabla?

1. TRUNCATE es DDL: no genera UNDO y ejecuta un COMMIT implícito.

2. DELETE FROM cotizacion WHERE …, que es DML y puede revertirse antes del COMMIT.

3. Los índices de la tabla.

Diseña la tabla

Construcción
Una veterinaria necesita registrar mascotas: código de hasta 6 dígitos, nombre de hasta 40 caracteres obligatorio, especie con un código fijo de 3 letras, peso con dos decimales (máximo 999.99) y fecha de registro que por defecto sea la fecha actual.
  1. Escribe el CREATE TABLE.
  2. Agrega un comentario a la tabla.
  3. ¿Qué vista confirma los tipos de las columnas?
CREATE TABLE mascota (
  id_mascota   NUMBER(6),
  nombre       VARCHAR2(40) NOT NULL,
  especie      CHAR(3),
  peso         NUMBER(5,2),
  fec_registro DATE DEFAULT SYSDATE
);
COMMENT ON TABLE mascota IS 'Pacientes de la veterinaria';

La vista USER_TAB_COLUMNS, o el comando DESC mascota.

No me deja eliminar la tabla

Diagnóstico
Al ejecutar DROP TABLE categoria; el DBA de una librería recibe un error que indica que la tabla tiene llaves únicas o primarias referenciadas por llaves foráneas.
  1. ¿Qué está impidiendo el borrado?
  2. ¿Qué cláusula lo permite?
  3. ¿Qué pasa con la tabla hija?

1. Otra tabla (por ejemplo LIBRO) tiene una FOREIGN KEY que referencia a CATEGORIA.

2. DROP TABLE categoria CASCADE CONSTRAINTS;

3. La tabla hija y sus filas permanecen; solo se elimina su restricción de llave foránea.

No. En la base de datos solo se guarda la definición de la vista (su consulta). Los datos se obtienen de las tablas base cada vez que se consulta.
CHAR es de longitud fija y completa con espacios hasta el tamaño declarado; VARCHAR2 es de longitud variable y almacena solo los caracteres ingresados. CHAR conviene en códigos de tamaño constante.
Ocho dígitos significativos en total, de los cuales dos son decimales. El valor máximo es 999999.99.
NEXTVAL avanza la secuencia y devuelve el nuevo valor. CURRVAL devuelve el último valor generado en la sesión actual, por lo que requiere haber llamado antes a NEXTVAL.
Se usan de forma intercambiable porque cada usuario tiene un esquema con su mismo nombre. En rigor, el usuario es la cuenta y el esquema es la colección de objetos que le pertenecen.
Los datos, la estructura de la tabla, sus índices, sus triggers y los privilegios otorgados sobre ella.
8 de 13
S03–S04 › SQL DDL › Integridad
07

Constraints

Las cinco restricciones que convierten las reglas del negocio en garantías de la base de datos.

NOT NULLUNIQUEPRIMARY KEYFOREIGN KEYCHECK

Integridad de datos

Integridad de datos significa que los datos de una base de datos se adhieren a las reglas del negocio. Puede imponerse con código de aplicación, con triggers o con restricciones (constraints); estas últimas son la forma declarativa y la preferida, porque la regla vive junto a la tabla.

RestricciónQué garantizaTipo en USER_CONSTRAINTS
NOT NULLLa columna no puede contener valores nulos.C
UNIQUELa columna o combinación de columnas no repite valores.U
PRIMARY KEYIdentifica cada fila: única y no nula. Una por tabla.P
FOREIGN KEYEl valor debe existir en la tabla padre (integridad referencial).R
CHECKCada fila debe cumplir una condición.C

Reglas generales

  • Si no se nombra la restricción, Oracle genera un nombre con el formato SYS_Cn.
  • Puede crearse junto con la tabla o después, con ALTER TABLE.
  • Puede definirse a nivel de columna o a nivel de tabla.
  • Las restricciones impiden eliminar una tabla si hay dependencias.
📍

Nivel de columna

Se escribe junto a la definición de la columna y afecta solo a esa columna. NOT NULL únicamente puede declararse así.

📐

Nivel de tabla

Se escribe después de las columnas. Es obligatorio para restricciones que involucran varias columnas, como una llave compuesta.

Llave foránea y borrado

CláusulaEfecto al borrar la fila padre
Sin cláusulaEl borrado se rechaza si existen filas hijas.
ON DELETE CASCADESe eliminan también las filas dependientes de la tabla hija.
ON DELETE SET NULLLas filas hijas se conservan con la llave foránea en nulo.
🚫
En un CHECK no se permite: referenciar las pseudocolumnas CURRVAL, NEXTVAL, LEVEL o ROWNUM; llamar a SYSDATE, UID, USER o USERENV; ni usar consultas a otras tablas.
💡
Al crear una PRIMARY KEY o una UNIQUE, Oracle crea implícitamente un índice único con el mismo nombre de la restricción.
🧱

Definir restricciones

En CREATE TABLE
CREATE TABLE socio (
  id_socio        NUMBER(6)    CONSTRAINT pk_socio PRIMARY KEY,       -- nivel de columna
  nombre          VARCHAR2(40) CONSTRAINT socio_nom_nn NOT NULL,
  dni             CHAR(8),
  fec_inscripcion DATE         CONSTRAINT socio_fins_nn NOT NULL,
  CONSTRAINT uk_socio_dni UNIQUE (dni)                                -- nivel de tabla
);

CREATE TABLE reserva (
  id_reserva  NUMBER(6),
  id_socio    NUMBER(6) NOT NULL,
  hora_inicio NUMBER(2),
  hora_fin    NUMBER(2),
  monto       NUMBER(6,2),
  CONSTRAINT pk_reserva        PRIMARY KEY (id_reserva),
  CONSTRAINT fk_reserva_socio  FOREIGN KEY (id_socio) REFERENCES socio (id_socio),
  CONSTRAINT ck_reserva_horas  CHECK (hora_fin > hora_inicio)
);
🔧

Agregar, eliminar y consultar

ALTER TABLE y diccionario
ALTER TABLE reserva ADD CONSTRAINT ck_reserva_monto CHECK (monto >= 0);
ALTER TABLE reserva ADD CONSTRAINT fk_reserva_cancha
  FOREIGN KEY (id_cancha) REFERENCES cancha (id_cancha) ON DELETE CASCADE;
ALTER TABLE reserva DROP CONSTRAINT ck_reserva_monto;

SELECT table_name, constraint_name, constraint_type, r_constraint_name
FROM   user_constraints WHERE table_name = 'RESERVA';

SELECT constraint_name, column_name, position
FROM   user_cons_columns WHERE table_name = 'RESERVA';

SELECT index_name, index_type, uniqueness FROM user_indexes;
🔎
USER_CONSTRAINTS indica el tipo de cada restricción y USER_CONS_COLUMNS, las columnas que abarca. Con privilegios de DBA se usan DBA_CONSTRAINTS y DBA_CONS_COLUMNS.
🚦

¿Qué restricción se viola?

Simulador · flujo de decisiones

Sistema de reservas de canchas con las tablas SOCIO, CANCHA y RESERVA. Predice el resultado de cada sentencia.

🚦

Validador de restricciones

Cinco pasos con puntaje acumulado

Al cargar 5 000 reservas históricas, el proceso se detiene con ORA-02291 en la fila 3 112.

Esa fila referencia un socio que no existe en la tabla padre. Hay que cargar primero los padres faltantes o corregir el dato; desactivar la llave foránea solo trasladaría el problema, dejando datos sin integridad.

La data que no entra

Corrección de datos
En el sistema de un gimnasio, la tabla PLAN tiene PK_PLAN sobre ID_PLAN, y MATRICULA tiene NOT NULL en FEC_INICIO y una FK hacia PLAN. Se intenta cargar: planes (1, Mensual), (2, Trimestral), (2, Anual); matrículas (10, plan 1, 05/03/2026), (11, plan 3, 07/03/2026), (12, plan 2, sin fecha).
  1. ¿Qué filas se rechazan y por qué restricción?
  2. ¿Qué corrección aplicarías a cada una?
  3. ¿En qué orden deben cargarse las tablas?

1. Plan (2, Anual): viola PK_PLAN por duplicar el 2. Matrícula 11: viola la FK porque el plan 3 no existe. Matrícula 12: viola NOT NULL en FEC_INICIO.

2. Registrar el plan Anual con código 3 (lo que además resuelve la matrícula 11) y asignar una fecha a la matrícula 12.

3. Primero la tabla padre PLAN y luego MATRICULA.

Reglas del negocio a restricciones

Diseño
Una empresa de alquiler de maquinaria define: cada contrato tiene un número único; no puede existir un contrato sin cliente; la fecha de devolución debe ser posterior a la de entrega; el RUC del cliente no se repite; la tarifa diaria no puede ser negativa.
  1. Asigna la restricción adecuada a cada regla.
  2. ¿Cuáles deben ir obligatoriamente a nivel de tabla?
  3. Propón nombres para dos de ellas.

1. Número único de contrato: PRIMARY KEY. Contrato sin cliente: NOT NULL más FOREIGN KEY hacia CLIENTE. Fechas: CHECK (fec_devolucion > fec_entrega). RUC: UNIQUE. Tarifa: CHECK (tarifa_diaria >= 0).

2. El CHECK de fechas, porque compara dos columnas.

3. Por ejemplo PK_CONTRATO y CK_CONTRATO_FECHAS.

Leer el diccionario

Interpretación
USER_CONSTRAINTS de la tabla FACTURA muestra: SYS_C0012040 tipo C; SYS_C0012041 tipo C; PK_FACTURA tipo P; FK_FACTURA_CLIENTE tipo R con R_CONSTRAINT_NAME = PK_CLIENTE.
  1. ¿Qué son las dos primeras?
  2. ¿Qué indica el tipo R?
  3. ¿Qué índice existe con seguridad?

1. Restricciones NOT NULL o CHECK que no fueron nombradas, por lo que Oracle les asignó SYS_Cn.

2. Integridad referencial: una llave foránea que apunta a la llave primaria PK_CLIENTE.

3. El índice único PK_FACTURA, creado implícitamente con la llave primaria.

Ambas impiden duplicados, pero la llave primaria además no admite nulos y solo puede haber una por tabla. UNIQUE permite nulos y puede haber varias en la misma tabla.
Porque el nombre aparece en el mensaje de error. Un ORA-02290 sobre CK_RESERVA_HORAS se entiende de inmediato; sobre SYS_C0011183 obliga a buscar en el diccionario.
No. Es la única restricción que solo se declara a nivel de columna. En el diccionario aparece con tipo C, igual que un CHECK.
No. Las restricciones CHECK no admiten SYSDATE, USER, UID ni USERENV, ni pseudocolumnas, ni subconsultas. Esa validación se resuelve con un trigger o en la aplicación.
La columna referenciada debe tener una restricción PRIMARY KEY o UNIQUE. Además, los tipos de dato de ambas columnas deben ser compatibles.
ORA-02292: registro hijo encontrado, salvo que la llave foránea tenga ON DELETE CASCADE u ON DELETE SET NULL.
9 de 13
S03–S04 › SQL DDL › Rendimiento
08

Índices

Estructuras opcionales que aceleran las consultas: cuándo elegir B-Tree, cuándo Bitmap y cuándo ninguno.

B-TreeBitmapCardinalidadUSER_INDEXES

¿Qué es un índice?

Un índice es una estructura opcional asociada a una tabla que puede acelerar el acceso a los datos al reducir las lecturas de disco. Es independiente de la tabla: puede crearse o eliminarse sin afectar las filas.

B-Tree frente a Bitmap

CriterioB-TreeBitmap
Cardinalidad recomendadaAlta: muchos valores distintosBaja: pocos valores distintos
Actualizaciones sobre la columnaNo son costosasSon costosas
Consultas con ORIneficienteEfectivo
Entorno típicoOLTPData warehousing
SintaxisCREATE INDEXCREATE BITMAP INDEX

Oracle ofrece además índices basados en función, que indexan el resultado de una expresión.

Cuándo no indexar

🐢

Costo en DML

Cada INSERT, UPDATE o DELETE debe mantener también los índices. Indexar todas las columnas degrada las operaciones de escritura.

🎯

Indexar con criterio

Se crean índices según la cantidad de valores distintos de la columna y las consultas reales que la usan en el WHERE.

🧾

Índices implícitos

PRIMARY KEY y UNIQUE ya crean su propio índice único: no hace falta crear otro.

✅
Conclusión del curso: los índices agilizan los tiempos de respuesta de las consultas, pero no deben asignarse a todas las columnas porque afectan las operaciones DML.
⚙️

Crear, mover y eliminar

Sintaxis
CREATE INDEX cli_dni_ix ON cliente (dni) TABLESPACE indices01;
CREATE BITMAP INDEX vta_region_bx ON venta (region);

ALTER INDEX cli_dni_ix REBUILD TABLESPACE indices02;
DROP INDEX vta_region_bx;

SET TIMING ON
SELECT COUNT(1) FROM venta WHERE region = 'SUR';

SELECT table_name, index_name, index_type, uniqueness
FROM   user_indexes WHERE table_name = 'VENTA';
VistaContenido
DBA_INDEXES / USER_INDEXESÍndices, tipo (NORMAL, BITMAP) y unicidad
DBA_IND_COLUMNSColumnas que componen cada índice
V$OBJECT_USAGESeguimiento del uso de los índices
💡
En USER_INDEXES, un índice B-Tree aparece con INDEX_TYPE = NORMAL y uno bitmap, con BITMAP.
🎚️

¿B-Tree o Bitmap?

Simulador · sliders con gráfico

Ajusta las características de la columna y observa la recomendación. El gráfico es un modelo didáctico de afinidad, no una medición real del optimizador.

🎚️

Selector de tipo de índice

Tabla de referencia: 1 000 000 de filas

En una tabla de prueba con cientos de miles de empleados, contar los de un país tarda 0.14 s sin índice, 0.10 s con un B-Tree sobre el país y 0.01 s con un Bitmap sobre la misma columna.

El país tiene pocos valores distintos frente al total de filas: baja cardinalidad. El B-Tree casi no ayuda porque cada valor apunta a miles de filas; el Bitmap resuelve el conteo operando directamente sobre los mapas de bits.

Dos columnas, dos índices

Decisión
Una empresa de telecomunicaciones tiene la tabla CLIENTE con 3 millones de filas. Se consulta con frecuencia por NOMBRE_COMPLETO y por DEPARTAMENTO (25 valores). La tabla vive en un data warehouse que se carga de noche.
  1. ¿Qué tipo de índice corresponde a cada columna?
  2. Escribe las sentencias.
  3. ¿Cambiaría tu respuesta si la tabla fuera OLTP con actualizaciones constantes?

1. NOMBRE_COMPLETO: B-Tree, por alta cardinalidad. DEPARTAMENTO: Bitmap, por baja cardinalidad en un entorno analítico.

CREATE INDEX cli_nombre_ix ON cliente (nombre_completo);
CREATE BITMAP INDEX cli_depto_bx ON cliente (departamento);

3. Sí: en OLTP las actualizaciones sobre una columna con bitmap son costosas, así que se evitaría el Bitmap.

El sistema se volvió lento al grabar

Diagnóstico
En una empresa de delivery, para “optimizar” se crearon índices sobre las 14 columnas de la tabla PEDIDO. Las consultas mejoraron poco, y registrar un pedido pasó de 20 ms a 180 ms.
  1. ¿Qué explica la degradación?
  2. ¿Qué criterio debió aplicarse?
  3. ¿Cómo se revisa qué índices existen?

1. Cada INSERT debe actualizar la tabla y los 14 índices; el costo de mantenimiento supera el beneficio.

2. Indexar solo las columnas usadas para filtrar o unir y con cardinalidad adecuada.

3. Consultando USER_INDEXES y DBA_IND_COLUMNS; V$OBJECT_USAGE ayuda a detectar los que no se usan.

Reorganizar el almacenamiento

Procedimiento
El tablespace USERS de una municipalidad está casi lleno porque allí se crearon tablas e índices. Existe un tablespace nuevo, IDX_DATA, pensado para índices.
  1. ¿Qué sentencia mueve un índice sin recrearlo manualmente?
  2. ¿Se pierden los datos de la tabla?
  3. ¿Qué cláusula habría evitado el problema al crearlo?

1. ALTER INDEX nombre REBUILD TABLESPACE idx_data;

2. No. El índice es una estructura separada; la tabla no se toca.

3. La cláusula TABLESPACE en CREATE INDEX.

Alta cardinalidad: la columna tiene muchos valores distintos respecto al total de filas, como un DNI o un correo. Baja cardinalidad: pocos valores que se repiten mucho, como sexo, región o estado.
Porque las actualizaciones sobre la columna indexada son costosas: modificar un valor implica reescribir mapas de bits que representan muchas filas, lo que afecta la concurrencia.
No. La definición dice que “puede” acelerar. Si la consulta devuelve una gran parte de la tabla, leerla completa suele ser más barato que pasar por el índice.
No hace falta. Al definir PRIMARY KEY o UNIQUE, Oracle crea implícitamente un índice único con el nombre de la restricción.
Se eliminan junto con la tabla. Con TRUNCATE, los índices se conservan pero quedan truncados.
En SQL*Plus se activa SET TIMING ON y se ejecuta la misma consulta antes y después de crear el índice. Los tiempos varían de un servidor a otro, por lo que interesa la comparación, no el valor absoluto.
10 de 13
S05 › Seguridad › Acceso
09

Usuarios y privilegios

Quién puede entrar y qué puede hacer: cuentas, privilegios de sistema y de objeto, y su revocación.

CREATE USERGRANT · REVOKEADMIN OPTIONGRANT OPTIONQUOTA

La cuenta de usuario

Cada cuenta de usuario de base de datos tiene: un nombre único, un método de autenticación, un tablespace por defecto, un tablespace temporal, un perfil, un grupo consumidor y un estado de bloqueo.

⚠️
Un usuario recién creado no tiene ningún privilegio: no puede ni conectarse. Tampoco puede guardar datos hasta que reciba una cuota sobre un tablespace.

SYS y SYSTEM

CuentaCaracterísticas
SYSDueña del diccionario de datos. Tiene todos los privilegios con ADMIN OPTION. Se requiere para iniciar, apagar y ejecutar mantenimiento.
SYSTEMTiene el rol DBA, pero no accede a las tablas internas X$ ni realiza backup, recovery o upgrade.
📌
Ninguna de las dos cuentas debe usarse para operaciones de rutina.

Dos tipos de privilegios

🏛️

De sistema

Habilitan a ejecutar acciones en la base de datos: CREATE SESSION, CREATE TABLE, CREATE USER. Existen más de 180.

WITH ADMIN OPTION
📦

De objeto

Habilitan a acceder y manipular un objeto específico: SELECT, INSERT, UPDATE, DELETE, EXECUTE sobre un objeto.

WITH GRANT OPTION

El propietario de un objeto tiene todos los privilegios sobre él y puede otorgar privilegios específicos a otros usuarios, a roles o a PUBLIC.

Revocar: la gran diferencia

Tipo de privilegioOpción para delegarEfecto de REVOKE
De sistemaWITH ADMIN OPTIONSin cascada: quienes lo recibieron del usuario revocado lo conservan.
De objetoWITH GRANT OPTIONCon cascada: quienes lo recibieron del usuario revocado también lo pierden.
👤

Administrar cuentas

CREATE, ALTER y DROP USER
CREATE USER caja01 IDENTIFIED BY Clave#2026
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp
  QUOTA 50M ON users
  PASSWORD EXPIRE;

ALTER USER caja01 IDENTIFIED BY NuevaClave1;
ALTER USER caja01 QUOTA UNLIMITED ON users;
ALTER USER caja01 ACCOUNT LOCK;
ALTER USER caja01 ACCOUNT UNLOCK;
DROP USER caja01 CASCADE;

SELECT username, account_status, profile FROM dba_users;
💡
DROP USER requiere CASCADE cuando el esquema del usuario contiene objetos: primero se eliminan los objetos y luego el usuario.
🎟️

Otorgar y revocar

GRANT y REVOKE
-- privilegios de sistema
GRANT CREATE SESSION TO caja01;
GRANT CREATE TABLE TO supervisor WITH ADMIN OPTION;
REVOKE CREATE TABLE FROM supervisor;

-- privilegios de objeto
GRANT SELECT ON ventas.pedido TO caja01, caja02;
GRANT UPDATE (estado, fec_entrega) ON ventas.pedido TO supervisor;
GRANT SELECT, INSERT ON ventas.pedido TO supervisor WITH GRANT OPTION;
GRANT SELECT ON ventas.producto TO PUBLIC;
REVOKE SELECT, INSERT ON ventas.pedido FROM supervisor;
🧩

Clasifica privilegios y roles

Arrastra cada ítem a su tipo

🔎

Analizador de sentencias

Simulador · análisis de texto

Escribe una sentencia de seguridad y el analizador identificará su tipo, sus opciones y sus consecuencias.

🔎

Analizador de GRANT, REVOKE y cuentas

Clasificación por palabras clave

El jefe de una tienda recibió SELECT sobre VENTAS.PEDIDO con GRANT OPTION y se lo pasó a dos vendedores. El jefe cambia de área y el propietario le revoca el privilegio.

Por tratarse de un privilegio de objeto, la revocación es en cascada: los dos vendedores también pierden el acceso y verán ORA-00942. Si deben conservarlo, el propietario tiene que otorgárselo directamente o mediante un rol.

Tres errores seguidos

Diagnóstico
En una notaría se crea el usuario DIGITADOR solo con CREATE USER … IDENTIFIED BY. Sucede lo siguiente: (a) no puede conectarse; (b) tras corregirlo, recibe CREATE TABLE, crea la tabla ESCRITURA, pero no puede insertar; (c) el usuario REVISOR, que sí se conecta, consulta DIGITADOR.ESCRITURA y recibe “la tabla o vista no existe”.
  1. Identifica el error ORA de cada situación.
  2. Escribe la sentencia que lo corrige y quién la ejecuta.

(a) ORA-01045, falta CREATE SESSION. El DBA ejecuta GRANT CONNECT TO digitador;

(b) ORA-01950, sin cuota. El DBA ejecuta ALTER USER digitador QUOTA 100M ON users;

(c) ORA-00942, falta el privilegio de objeto. DIGITADOR, como propietario, ejecuta GRANT SELECT ON escritura TO revisor;

La cadena de permisos

Análisis
En una empresa logística, el DBA otorga CREATE VIEW a KARINA con ADMIN OPTION y ella lo otorga a DIEGO. Aparte, KARINA es dueña de la tabla RUTA y otorga SELECT a DIEGO con GRANT OPTION; DIEGO se lo pasa a PAOLA. Luego el DBA revoca CREATE VIEW a KARINA, y KARINA revoca SELECT sobre RUTA a DIEGO.
  1. ¿Puede DIEGO seguir creando vistas?
  2. ¿Puede PAOLA seguir consultando RUTA?
  3. Explica la regla detrás de cada respuesta.

1. Sí. La revocación de privilegios de sistema no tiene efecto en cascada.

2. No. La revocación de privilegios de objeto sí es en cascada: PAOLA lo recibió a través de DIEGO.

3. ADMIN OPTION delega privilegios de sistema sin dependencia posterior; GRANT OPTION delega privilegios de objeto manteniendo la cadena.

Mínimo privilegio

Diseño
Un estudio contable necesita que el usuario ASISTENTE pueda conectarse, consultar la tabla CONTA.ASIENTO y modificar únicamente la columna GLOSA. No debe crear objetos.
  1. Escribe las sentencias necesarias.
  2. ¿Necesita cuota en algún tablespace?
CREATE USER asistente IDENTIFIED BY Temporal#1 PASSWORD EXPIRE;
GRANT CREATE SESSION TO asistente;
GRANT SELECT ON conta.asiento TO asistente;
GRANT UPDATE (glosa) ON conta.asiento TO asistente;

No necesita cuota: no es dueño de ningún segmento. Los datos que modifica pertenecen al esquema CONTA.

Por seguridad. Cuando un usuario no tiene ningún privilegio sobre un objeto de otro esquema, Oracle responde ORA-00942 para no revelar siquiera que el objeto existe.
WITH ADMIN OPTION se usa con privilegios de sistema y roles; WITH GRANT OPTION, con privilegios de objeto. Ambas permiten al beneficiario otorgar a terceros, pero se comportan distinto al revocar: sin cascada la primera, con cascada la segunda.
Que todos los usuarios de la base de datos, actuales y futuros, lo reciben. Es cómodo, pero riesgoso: debe reservarse para objetos realmente públicos.
Obliga al usuario a cambiar la contraseña en su primer ingreso, de modo que la clave inicial definida por el DBA deja de ser conocida por otra persona.
Es el espacio máximo que el usuario puede ocupar en un tablespace. Sin cuota puede crear la tabla (la definición), pero al insertar la primera fila recibe ORA-01950.
Sí. Se indica la lista de columnas entre paréntesis: GRANT UPDATE (col1, col2) ON tabla TO usuario. Es una forma fina de aplicar el mínimo privilegio.
11 de 13
S05 › Seguridad › Gobierno
10

Roles, perfiles y auditoría

Agrupar privilegios, limitar contraseñas y recursos, y dejar rastro de lo que ocurre.

CREATE ROLECREATE PROFILERESOURCE_LIMITAUDIT_TRAILUNIFIED_AUDIT_TRAIL

Roles

Un rol es un conjunto de privilegios con nombre. Los privilegios se asignan al rol y el rol se asigna a los usuarios.

1
PrivilegiosDe sistema y de objeto
→
2
RolLos agrupa con un nombre
→
3
UsuariosReciben el rol
  • Facilitan la administración de privilegios.
  • Permiten una administración dinámica: al cambiar el rol, cambian todos sus usuarios.
  • Ofrecen disponibilidad selectiva de privilegios.
Rol predefinidoPrivilegios incluidos
CONNECTCREATE SESSION
RESOURCECREATE TABLE, CREATE SEQUENCE, CREATE PROCEDURE, CREATE TRIGGER, CREATE TYPE, CREATE CLUSTER, entre otros
DBALa mayoría de los privilegios de sistema. No debe otorgarse a no administradores.
SELECT_CATALOG_ROLEPrivilegios de objeto sobre el diccionario de datos
SCHEDULER_ADMINAdministración de trabajos programados

Perfiles

Un perfil es un conjunto de directivas que limita el uso de contraseñas y de recursos. Se asigna con CREATE USER o ALTER USER, solo a usuarios (no a roles). Todo usuario sin perfil explícito usa el perfil DEFAULT.

ParámetroControla
FAILED_LOGIN_ATTEMPTSIntentos fallidos consecutivos antes de bloquear la cuenta.
PASSWORD_LOCK_TIMEDías que la cuenta permanece bloqueada.
PASSWORD_LIFE_TIMEDías de vigencia de la contraseña.
PASSWORD_GRACE_TIMEDías de gracia con advertencia antes de que expire.
PASSWORD_REUSE_TIMEDías que deben pasar antes de reutilizar una contraseña.
PASSWORD_REUSE_MAXCambios requeridos antes de reutilizar una contraseña.
PASSWORD_VERIFY_FUNCTIONFunción PL/SQL que valida la complejidad.
ParámetroControla
SESSIONS_PER_USERSesiones simultáneas por usuario.
CPU_PER_SESSION / CPU_PER_CALLTiempo de CPU en centésimas de segundo.
CONNECT_TIMEDuración total de la sesión, en minutos.
IDLE_TIMETiempo de inactividad continua, en minutos.
LOGICAL_READS_PER_SESSION / _PER_CALLBloques de datos leídos.
PRIVATE_SGAEspacio privado en la SGA.
COMPOSITE_LIMITCosto total ponderado de recursos.
📌
Los límites de recursos solo se hacen cumplir cuando el parámetro RESOURCE_LIMIT está en TRUE.

Auditoría

Auditar es monitorizar y registrar los cambios realizados en los datos o en la estructura de los objetos. El parámetro AUDIT_TRAIL define dónde se guardan los registros: NONE (deshabilitada), DB, DB,EXTENDED (incluye el SQL y las variables bind), XML u OS.

TipoDescripción
ObligatoriaSiempre activa: inicio y apagado de la base de datos y conexiones como SYSDBA, SYSOPER o SYSASM.
EstándarSe habilita con el comando AUDIT sobre sentencias, privilegios y objetos.
Basada en valoresCaptura los valores reales modificados por DML, usando triggers.
De grano finoAudita según el contenido accedido o modificado.
Al usuario SYSRegistra en un archivo del sistema operativo; se activa con AUDIT_SYS_OPERATIONS.
MixtaPor defecto en 12c: combina la auditoría tradicional con la unificada.
💡
La auditoría tradicional guarda sus registros en SYS.AUD$. Desde 12c, la auditoría unificada se basa en políticas que se crean, se habilitan por usuario y registran en UNIFIED_AUDIT_TRAIL.
🎭

Roles

Crear, cargar y asignar
CREATE ROLE rol_cajero;
GRANT CREATE SESSION TO rol_cajero;
GRANT SELECT, INSERT ON ventas.comprobante TO rol_cajero;
GRANT rol_cajero TO caja01, caja02;
REVOKE rol_cajero FROM caja02;

SELECT * FROM role_sys_privs WHERE role = 'ROL_CAJERO';
SELECT * FROM role_tab_privs WHERE role = 'ROL_CAJERO';
SELECT * FROM user_role_privs;
VistaMuestra
ROLE_SYS_PRIVSPrivilegios de sistema concedidos a roles
ROLE_TAB_PRIVSPrivilegios sobre tablas concedidos a roles
USER_ROLE_PRIVSRoles accesibles por el usuario
USER_SYS_PRIVSPrivilegios de sistema del usuario
USER_TAB_PRIVS_MADE / _RECDPrivilegios de objeto otorgados y recibidos
📏

Perfiles

Contraseñas y recursos
CREATE PROFILE prf_soporte LIMIT
  FAILED_LOGIN_ATTEMPTS 3
  PASSWORD_LOCK_TIME    1
  PASSWORD_LIFE_TIME    30
  PASSWORD_GRACE_TIME   5
  SESSIONS_PER_USER     2
  IDLE_TIME             60;

ALTER USER soporte01 PROFILE prf_soporte;
ALTER SYSTEM SET resource_limit = TRUE;
SHOW PARAMETER resource

SELECT * FROM dba_profiles WHERE profile = 'PRF_SOPORTE';
SELECT username, account_status, profile FROM dba_users WHERE username = 'SOPORTE01';
🔒

Bloqueo de cuenta por intentos fallidos

Configura el perfil y prueba conexiones

El perfil DEFAULT de una base de datos muestra FAILED_LOGIN_ATTEMPTS = 10 y PASSWORD_LOCK_TIME = 1. Auditoría interna pide bloquear a los usuarios de ventanilla al tercer intento fallido, hasta que TI intervenga.

No se modifica DEFAULT, que afecta a todos. Se crea un perfil específico con FAILED_LOGIN_ATTEMPTS 3 y PASSWORD_LOCK_TIME UNLIMITED, y se asigna a esos usuarios con ALTER USER … PROFILE. El desbloqueo requerirá ALTER USER … ACCOUNT UNLOCK.

🎮

Diagnóstico de errores ORA

Simulador · juego con temporizador

Ocho situaciones reales de administración. Elige la mejor acción antes de que se acabe el tiempo.

🎮

Guardia de DBA

20 segundos por situación · mejor, aceptable o incorrecta

Veinte cajeros, un solo cambio

Diseño
Una cadena de boticas tiene 20 cajeros con los mismos permisos otorgados uno por uno. Ahora deben poder anular comprobantes (UPDATE sobre la columna ESTADO). El DBA tendría que ejecutar 20 sentencias, y repetirlo con cada nuevo cajero.
  1. ¿Qué objeto simplifica esta administración?
  2. Escribe las sentencias para implementarlo.
  3. ¿Qué pasa con los cajeros cuando luego se agrega un privilegio al rol?
CREATE ROLE rol_cajero;
GRANT CREATE SESSION TO rol_cajero;
GRANT SELECT, INSERT ON ventas.comprobante TO rol_cajero;
GRANT UPDATE (estado) ON ventas.comprobante TO rol_cajero;
GRANT rol_cajero TO cajero01, cajero02;  -- y los demás

Todos los usuarios que tienen el rol reciben el nuevo privilegio sin más sentencias: es la administración dinámica de privilegios.

El límite que no limitaba

Diagnóstico
En una consultora se crea un perfil con SESSIONS_PER_USER 2 y se asigna al usuario ANALISTA. Aun así, el usuario abre cinco sesiones simultáneas sin error. En cambio, el bloqueo por FAILED_LOGIN_ATTEMPTS del mismo perfil sí funciona.
  1. ¿Qué explica la diferencia?
  2. ¿Qué sentencia lo corrige?
  3. ¿Qué error aparecerá en la tercera sesión?

1. Los límites de recursos requieren RESOURCE_LIMIT = TRUE; los de contraseña se aplican siempre.

2. ALTER SYSTEM SET resource_limit = TRUE;

3. ORA-02391: ha excedido el límite de SESSIONS_PER_USER simultáneas.

¿Quién cambió los precios?

Decisión
Un supermercado detecta que algunos precios fueron modificados fuera de horario. Gerencia pide saber quién modifica la tabla PRECIO y qué valores cambia, sin llenar el disco con registros innecesarios.
  1. ¿Qué tipo de auditoría registra quién ejecutó el UPDATE?
  2. ¿Cuál captura el valor anterior y el nuevo?
  3. Menciona dos recomendaciones al activar auditoría.

1. La auditoría estándar (o una política de auditoría unificada) sobre UPDATE en esa tabla.

2. La auditoría basada en valores, implementada con triggers.

3. Ser específico en la acción y el objeto auditados en lugar de auditar todo de todos, y considerar activarla de forma temporal; además, registrar en modo base de datos.

No. Los perfiles solo se asignan a usuarios, mediante CREATE USER o ALTER USER. Cada usuario tiene exactamente un perfil; si no se indica, usa DEFAULT.
El rol define qué puede hacer el usuario: agrupa privilegios. El perfil define cuánto y bajo qué reglas: limita recursos y gobierna las contraseñas.
Que la cuenta se bloqueó automáticamente por superar FAILED_LOGIN_ATTEMPTS y se liberará al cumplirse PASSWORD_LOCK_TIME. Si el DBA la bloquea manualmente con ACCOUNT LOCK, el estado es LOCKED.
Porque incluye casi todos los privilegios de sistema. Un error o una cuenta comprometida tendría alcance total. La práctica correcta es el mínimo privilegio mediante roles a medida.
SYS.AUD$ almacena los registros de la auditoría tradicional. UNIFIED_AUDIT_TRAIL concentra los de la auditoría unificada basada en políticas, disponible desde 12c. En modo mixto conviven ambas.
No. Siempre registra el inicio y apagado de la base de datos y las conexiones con privilegios administrativos como SYSDBA o SYSOPER.
Comienza el período de gracia definido en PASSWORD_GRACE_TIME: el usuario puede ingresar, pero recibe una advertencia. Si no cambia la contraseña dentro de ese plazo, esta expira.
12 de 13
Evaluación › Bloque 2
Q2

Quiz 2 · DDL y seguridad

Diez preguntas sobre los temas 06 a 10 y el cierre del repaso.

TablasConstraintsÍndicesPrivilegiosPerfiles y auditoría