¿Por qué son necesarias las llaves primarias o primary key en una tabla?

Las llaves primarias o primary key son necesarias en una tabla para poder evitar duplicidad, es decir, identificar de manera inequívoca un registro.
Un ejemplo clásico son tablas que registran datos de personas como empleados en los que por lo general tiene una columna de documento de identidad  también conocido como Cédula de Ciudadanía (CC), Tarjeta de Identidad (TI), Registro Civil (RC), Cédula de Extranjería (CE), Carné de Identidad (CI), Cédula de Identidad (CI), Documento Nacional de Identidad (DNI), Documento Único de Identidad(DUI), identificación oficial o simplemente identificación (ID).
Los siguientes países: Australia, Canadá, Dinamarca, Irlanda, Estados Unidos, Japón y Reino Unido no tienen documento nacional de identidad, sin embargo, cuando crean una tabla de personas en sus bases de datos es indispensable tener un código interno para poder relacionar los datos de la tabla de personas con las demás tablas que contengan datos relacionados a la persona a través del código interno.

Arquitectura de una solución de Alta Disponibilidad de base de datos Oracle con RAC (Real Application Clusters).

La gráfica anterior muestra la arquitectura de una solución de alta disponibilidad de BD Oracle con RAC:

En términos simples, una solución RAC nos permite no solo balancear la carga sino también nos asegura la disponibilidad ante una falla en uno de los nodos o servidores de base de datos a tal punto que puede llegar a ser transparente al usuario, es decir, la caída de un nodo o servidor de base de datos puede no implicar cortes en el aplicativo o interrupciones al usuario.

Sentencia SQL para conocer el espacio asignado, usado y libre de los tablespaces de una base de datos Oracle

La siguiente sentencia SQL nos permite conocer cuál es el espacio usado, el espacio asignado y el espacio libre de los tablespaces de una base de datos Oracle que no son temporary. Estoy seguro le va a ser útil a  todo DBA Oracle para alertar problemas de espacio en la base de datos.


SELECT A.TABLESPACE_NAME, A.MB_ASIGNADOS, B.MB_USADOS, A.MB_ASIGNADOS - B.MB_USADOS AS MB_LIBRES, (B.MB_USADOS / A.MB_ASIGNADOS) *100 PORCENTAJE_USADO
FROM
(
SELECT TABLESPACE_NAME, SUM(BYTES)/1024/1024 AS MB_ASIGNADOS, COUNT(1) AS CANT_DATAFILES
FROM DBA_DATA_FILES
GROUP BY TABLESPACE_NAME
) A,
(
SELECT TABLESPACE_NAME, SUM(BYTES)/1024/1024 AS MB_USADOS, COUNT(1) AS CANT_SEGMENTOS
FROM DBA_SEGMENTS
GROUP BY TABLESPACE_NAME
) B
WHERE A.TABLESPACE_NAME=B.TABLESPACE_NAME;

Por qué es imprescindible para un DBA conocer SQL

Los nuevos DBA Oracle son reacios de aprender el  lenguaje de consulta de base de datos SQL. Esto probablemente es consecuencia de haber publicitado que partir de la versión Oracle Database 10g un DBA solo necesita de las interfaces gráficas de la consolas (OEM o dbconsole) haciendo aparentemente "prescindible" elaborar una sentencia SQL para realizar nuestro trabajo.

La realidad nos demuestra lo contrario pues un DBA necesita:

• Consultar las vistas DBA_*, ALL_*, USER_*, V$*, GV$* para recolectar información de estados, los objetos, cruzar información, etc.
• Comunicarse en el mismo lenguaje de los desarrolladores de consultas SQL, sentencias SQL, código PL/SQL
• Analizar los planes de ejecución de las sentencias SQL para plantear alternativas de optimización.  
• Elaborar sentencias SQL para automatizar validaciones.
• Controlar los cambios (pases) en los objetos de base de datos que se dan con sentencias DDL
• Otorgar privilegios de objetos o privilegios de sistema.
• Orientar a los usuarios de la BD en mejores practicas de codificación SQL o PL/SQL.
• Explicar a los usuarios por qué una sentencia genera un alto costo de CPU, I/O Disk, etc. 

Análisis del rendimiento (performance) de una base de datos

Para realizar un correcto análisis del rendimiento (performance) de una base de datos debemos primero conocer el entorno donde se encuentra. Necesitamos por tanto, conocer lo siguiente:

• El sistema operativo (S.O.) del servidor
• La versión de la base de datos
• Distribución de disco y tipo de RAID usado por las unidades, file system o volumn groups segun corresponda
• Mapa de la RED a donde esta conectado el servidor
• El tipo de uso que tiene la BD, es decir, si es transaccional (OLTP), es es un dataware (DSS) o una combinación de ambos.
• Qué otros servicios corren en el servidor de base de datos

Asimismo, necesitamos contar con información estadística de los siguientes datos del comportamento del servidor en el intervalo de tiempo que se requiere analizar:

• Uso de RED
• Uso de CPU
• Uso de Memoria
• Uso de swap, paginación según corresponda.

Cómo subir/bajar el dbconsole (aplica para Oracle 10g, 11g)

Si estamos trabajando en un entorno UNIX/Linux debemos de saber con qué shell estamos trabajando. (Nota El simbolo # indica es un comentario)

INSTRUCTIVO

Abrir un terminal al servidor con el usuario propietario de la instalación (puede usar putty, telnet desde una ventana DOS, vnc u otra interface)

# Con el siguiente comando averiguo
echo $SHELL

# Si el servidor UNIX/Linux donde estamos trababajando tiene mas de una BD
# entonces debemos de asegurarnos que estamos en la instancia que corresponde a
# la BD sobre la cual queremos levantar el dbconsole.
# visualizar la variable de entorno ORACLE_SID
echo $ORACLE_SID

# asignar un valor a la variable de entorno
export ORACLE_SID=NOMBINST
echo $ORACLE_HOME
echo $PATH
which emctl

# Para subir el dbconsole puede usar el siguiente comando
emctl start dbconsole

# Para bajar el dbconsole puede usar el siguiente comando
emctl stop dbconsole

Analizando sentencias SQL con base de datos Oracle

Para analizar las sentencias SQL con bases de datos Oracle contamos con las siguientes herramientas propias del Oracle, sin embargo, también es necesario conocer de mejores prácticas de programación y diseño para poder recomendar cambios para optimizar una sentencia SQL. 

EXPLAIN PLAN

AUTOTRACE

SQL Trace

TKPROF

Backups o Respaldos de base de datos

Es necesario que los backups o respaldos de las base de datos esten acordes con las necesidades de negocio de la empresa u organización a la que pertenecen.

Los backups en frio (off-line) de bases de datos Oracle se usan en empresas/negocios que hacen uso de la BD solo en horarios de oficina o solo en días laborables por ejemplo lo que permite aprovechar las horas de la madrugada o fines de semana para bajar los servicios de los sistemas que trabajan con la BD y la BD misma para poder tomar el backup en frio (off-line). A este tipo de backup tambien se le conoce como backup CONSISTENTE porque todos los archivos estan sincronizados (tiene la misma hora de actualización) y en caso de una restauración no requieren de archivos de cambios (archivos) para que puedan ser abierta la base de datos.


-- SQL para obtener un listado de archivos de la base de datos Oracle que necesita incluir en un backup en frio (off-line)
SELECT 'DATAFILE' AS TIPO, NAME
FROM V$DATAFILE
UNION ALL
SELECT 'TEMPFILE' AS TIPO, NAME
FROM V$TEMPFILE
UNION ALL
SELECT 'CONTROLFILE' AS TIPO, NAME
FROM V$CONTROLFILE
UNION ALL
SELECT 'ONLINE REDO LOG FILE' AS TIPO, MEMBER
FROM V$LOGFILE;


Los backups en caliente (on-line) de bases de datos Oracle se usan en empresas/negocios que no pueden detener sus base de datos, es decir, que operan las 24 horas de día sin interrupción. A este tipo de backup tambien se le conoce como backup INCONSISTENTE porque los archivos no estan sincronizados (no tiene la misma hora de actualización)  y en caso de una restauración requieren de archivos de cambios (archives) para que pueda ser abierta la base de datos.

-- SQL para obtener un listado de archivos de la base de datos Oracle que necesita incluir en un backup en caliente (on-line)
SELECT 'DATAFILE' AS TIPO, NAME
FROM V$DATAFILE;

-- Adicionalmente es necesario contar con un respaldo de los archivos de cambios (archives)

Objetos de base de datos

¿Cómo obtener informacion sobre los objetos de una base de datos Oracle?

-- Objetos de base de datos con el mismo nombre
SELECT OWNER,
OBJECT_TYPE,
OBJECT_NAME,
STATUS
FROM DBA_OBJECTS
WHERE UPPER(OBJECT_NAME) = UPPER('NOMBRE DEL OBJETO');

-- Espacio en MB que ocupa un objeto segmento (tabla, indice ...)
SELECT OWNER,
SEGMENT_TYPE,
SEGMENT_NAME,
BYTES / (1024*1024) as Megabytes
FROM DBA_SEGMENTS
WHERE UPPER(SEGMENT_NAME) = UPPER('NOMBRE DEL OBJETO');

Documentación sobre Base de Datos Oracle 9i

Administración de Base de Datos Oracle, Conceptos y Referencia

Oracle9i New Features (Nuevas Funciones de Oracle9i): Este manual describe las nuevas funciones, nuevas opciones y mejoras de Oracle9i. Identifica lo que hay disponible con cada edición de Oracle9i (Standard Edition, Enterprise Edition y Personal Edition). Hace referencia a la documentación disponible para Oracle9i e identifica las funciones que han perdido valor o soporte.

Oracle9i Administrator's Guide (Guía del Administrador de Oracle9i): Esta guía está destinada a los usuarios que administran la operación de un sistema de base de datos Oracle. Denominados administradores de base de datos (DBA), son responsables de la creación de bases de datos Oracle que aseguran una operación correcta y controlan su uso.

Consumo de recursos de sentencias SQL en base de datos Oracle

¿Cómo saber el consumo de recursos de las sentencias SQL recientemente ejecutadas o que estan ejecutándose.

-- Sentencias SQL que están ejecutandose:
SELECT * FROM GV$SQLAREA
WHERE USERS_EXECUTING > 0;

-- Consumo de las sentencias SQL x Instancia y Modulo
SELECT INST_ID,
MODULE,
COUNT(1) as Cantidad_SQL,
SUM(DECODE(EXECUTIONS,1,1,0)) as Cantidad_SQL_1_EXECUTION,
SUM(EXECUTIONS) as Total_EXECUTIONS,
SUM(SHARABLE_MEM) as Total_SHARABLE_MEM,
SUM(BUFFER_GETS) as Total_BUFFER_GETS,
SUM(DISK_READS) as Total_DISK_READS,
SUM(CPU_TIME)/1000000 as Total_CPU_TIME_Seconds,
SUM(ELAPSED_TIME)/1000000 as Total_ELAPSED_TIME_Seconds
FROM GV$SQLAREA
GROUP BY INST_ID, MODULE;

Sesiones de base de datos Oracle

¿Cómo saber el estado de las sesiones de base de datos?
Para averiguar sobre el estado de las sesiones de base de datos hemos elaborado las siguientes sentencias SQL que les seran de gran ayuda:

-- Cantidad de sesiones por Instancia:
SELECT INST_ID, count(1) as Cant_Sesiones
FROM GV$SESSION
GROUP BY INST_D;

-- Cantidad de sesiones por Instancia y por Estado:
SELECT INST_ID, STATUS, count(1) as Cant_Sesiones
FROM GV$SESSION
GROUP BY INST_ID, STATUS;

-- Cantidad de sesiones por Instancia y por Modulo:
SELECT INST_ID, MODULE, count(1) as Cant_Sesiones
FROM GV$SESSION
GROUP BY INST_ID, MODULE

-- Cantidad de Sesiones por Instancia, Estado y por Modulo:
SELECT INST_ID, STATUS, MODULE, count(1) as Cant_Sesiones
FROM GV$SESSION
GROUP BY INST_ID, STATUS, MODULE;