Inicio > Database > Oracle Database de la A a la Z

Oracle Database de la A a la Z

En esta entrada intentaré dar algunas descripciones “simples” del vocabulario más común al hablar de BBDD Oracle.

Será un listado de “palabras o frases” con explicaciones sencillas, procurando que sean comprensibles antes que exactas (pido perdón de antemano a los “puristas”).

Quiero empezar con la siguiente frase: “Safe Harbor Statement”. Esta cita encabeza prácticamente todas las presentaciones oficiales de Oracle, que continúan con un párrafo donde se especifica que dicha presentación es a título informativo, carece de propósito contractual y no implica futuros compromisos. Que nadie deberá utilizarla como fundamento para decisiones de compra, técnicas o de estrategia.

Así pues, aplico la frase en cuestión, Safe Harbor Satement: utilizad las siguientes descripciones bajo vuestra responsabilidad; no son oficiales, priman la comprensión a la exactitud, pueden no ajustarse a la realidad en el momento en que leáis el post (teniendo en cuenta que es un producto que cambia mucho y deprisa) y no deben utilizarse para fundamentar decisiones de compra, técnicas ni de cualquier otro tipo. No nos hacemos responsables de las explicaciones y/o interpretaciones que se hagan de ellas y remitimos siempre a consultar:

Nota: En las descripciones van a aparecer muchas palabras que a su vez podremos encontrar descritas en otras definiciones de este mismo post.

Ahora sí, empecemos.

A

ACID: Es una característica de las BBDD Oracle (y de forma total o parcial de otras BBDD) y son las iniciales de las palabras:

Atomicidad: Esto indica que las transacciones son “atómicas”, lo que quiere decir que se hacen completas o no se hacen. Si pedimos a Oracle que haga una serie de cambios, los hace todos o ninguno pero no los dejará a medias pase lo que pase.

Consistencia: La BBDD puede tener definidas unas reglas para el contenido que almacena, relaciones entre diferentes tablas (registros padre y registros hijo), reglas de no duplicidad de registros o de control de los datos entrados. Una BBDD consistente asegura que esas reglas se cumplirán siempre y que no permitirá entrar datos que no se ajusten a ellas.

Aislamiento (Isolation): Una BBDD que cumpla esta condición podrá permitir realizar múltiples cambios al mismo tiempo, pero finalmente cuando estos cambios se “confirmen” tendrán un orden establecido (será como si se hubieran realizado uno tras otro). Oracle en este aspecto es una BBDD con “aislamiento estricto” lo que indica que un usuario no podrá ver los cambios de otro usuario mientras este no los confirme (haga “commit”)

Durabilidad: Esto nos indica que una vez confirmados una serie de cambios estos permanecerán en la BBDD pase lo que pase (incluso si el sistema de cae justo después de confirmar el cambio).

ADDM (Automatic Database Diagnostic Monitor): La BBDD dispone de todo un sistema interno de monitorización que almacena gran cantidad de datos de rendimiento y control en unas tablas llamadas AWR (Automatic Workload Repository). El ADDM son un conjunto de tareas que en horas de baja carga analizan los datos del AWR y nos hacen recomendaciones de mejora del rendimiento.

ADR (Automatic Diagnostic Repository): Es un conjunto de directorios en los que se han ido incorporando la mayoría de ficheros de log y traza. Se ha automatizado su gestión con  herramientas  como el “ADRCI” que permiten revisar estas trazas, purgarlas, localizar las pertenecientes a un determinado incidente e incluso “empaquetarlas” para enviarlas a soporte.

Alert Log: Es el fichero de alerta de la BBDD, en el la BBDD deja notificación de todos los eventos importantes, en caso de problemas es uno de los primeros puntos a revisar. En las versiones más actuales de la BBDD está siendo sustituido por conjunto de ficheros en formato XML que contienen la misma información pero adaptada al formato de uso del repositorio ADR.

Archived Redo Log: Si tenemos la BBDD en modo archivado (archivelog mode) esta mantiene un “registro” de todos los cambios realizados. Estos cambios quedan almacenados en los ficheros de “redo log online”, pero estos ficheros se sobrescriben cada cierto tiempo (tenemos un número limitado de ellos). Para evitar perder los datos de registro la BBDD hace copia de los ficheros “redo log online” una vez llenos y antes de que sean sobrescritos, estas copias que se van numerando mediante una secuencia (y por tanto no se sobrescriben) son los “archived redo logs”. En ellos tenemos el histórico de lo que ha ido sucediendo en la BBDD.

Archivelog Mode: La BBDD puede trabajar en dos modos “arhivelog” o “no archivelog”, en el primer modo le obligamos a guardar histórico de todos los cambios realizados, en el segundo los cambios ya confirmados (y que ya tenemos almacenados permanentemente en los ficheros de datos) no es necesario guardarlos y se descartan. Los cambios realizados se almacenan (independientemente del modo en que trabaje la BBDD) en unos ficheros llamados “redo logs online”, de los que cada BBDD tiene un número determinado, si estamos en modo “no archivelog” los datos en estos ficheros se sobrescriben al cabo de un tiempo, en modo “archivelog” se hace una copia del fichero (llamada “archived redo log” antes de que se sobrescriban).

Archiver Process (ARCn): Son una serie de procesos (o hilos dependiendo del sistema operativo)  que se encargan entre otras cosas de realizar las copias de los “redo log online” a “archived redo log”. Forman parte de los procesos de tipo “background”, o lo que es lo mismo, de los procesos internos de la BBDD.

ASSM Tablespace: Los tablespaces contienen los objetos de la BBDD, los tablespace de tipo ASSM (Automatic Segment Space Management) gestionan su espacio libre mediante una tabla “bitmap” ubicada en el mismo tablespace, este es el tipo de tablespace por defecto en las últimas versiones del gestor de BBDD. Anteriormente con los tablespaces de tipo no ASSM el espacio libre/ocupado se gestionaba en tablas ubicadas en un tablespace especial llamado “SYSTEM”.

Auditing: Todas las versiones de Oracle (tanto la Standard Edition como la Enterprise edition) disponen de un sistema de auditoría que en caso se ser activado permite saber que ha hecho quien y cuando. En la versión “Enterprise” existen variantes más avanzadas que permiten auditoria “condicional” o almacenamiento de los datos de auditoria en un repositorio remoto.

Automatic Undo Management: Cuando realizamos cambios en la BBDD Oracle es optimista y piensa que finalmente los confirmaremos (haremos “commit”) por lo que es posible que antes de confirmarlos ya los esté almacenando en los ficheros de datos. Si por el contrario descartamos los cambios realizados (hacemos “rollback”) Oracle deberá dejar todo nuevamente en su sitio, esto lo hace almacenando de manera temporal todos los cambios que realicemos en unos segmentos (tablas) llamados de UNDO, caso de no confirmar los cambios y mediante estos datos deshará todo lo hecho dejando todo como estaba antes de empezar la transacción. Es el propio Oracle quien se encarga de gestionar el número y tamaño de estos segmentos de UNDO. Anteriormente esto se tenía que hacer manualmente y a estos segmentos los llamaban segmentos de “ROLLBACK”.

Automatic Workload Repository (AWR): Es todo un sistema de instrumentación que almacena los datos de rendimiento y funcionamiento de nuestra BBDD, permitiéndole autogestionarse y adaptarse a los cambios. Existen multitud de herramientas de la propia BBDD que se basan en estas tablas para realizar sus tareas de ajustes, recomendaciones o parametrización de la propia BBDD. Esta información queda almacenada en un tablespace llamado “SYSAUX” y se purga automáticamente al cabo de cierto tiempo.

Autonomous Database: La última novedad de Oracle es la BBDD automática, se gestiona, tunea, configura, repara, parchea, actualiza, etc… sola sin intervención del DBA, ni los sysadmins, todo esto desde el punto de vista comercial. A nivel técnico podríamos decir que se trata de coger el mejor hardware de que dispone Oracle (Exadata), instalar la última versión de BBDD (12c,18c) con todas las funcionalidades estrella de la casa activas (RAC, Particionado, Tuning Advisors, etc..) y funcionando a destajo y poner a un ejército de técnicos especialistas a administrar actualizar y ajustar el conjunto. Todo esto se vende como un servicio al cliente que solo puede cargar datos y usar la BBDD sin tocar nada, eso sí el hardware si es necesario te lo instalan en casa (pero sigues sin poder tocar nada).

B

Background Processes: Son procesos internos (o de fondo) de la BBDD, existen gran cantidad de ellos cada uno dedicado a ciertas tareas (en cada versión de BBDD aparecen procesos nuevos que dan soporte a las nuevas funcionalidades). Algunos de ellos son imprescindibles para el funcionamiento de la BBDD y otros son opcionales en función de las funcionalidades que usemos o del tipo de instalación. Los podemos distinguir porque en la tabla interna GV$PROCESS en el campo BACKGROUND está informado a “1”.

Backups: Esta palabra es muy genérica y designa las copias que realizamos de nuestra BBDD para evitar pérdidas de datos en caso de problemas o poder volver a el estado que tenía la BBDD en un punto anterior en el tiempo caso que sea necesario. A grandes trazos hay dos tipos, los realizados en caliente (con la BBDD funcionando y que requieren que la BBDD este en modo “archivelog”) y los realizados en frío en los que se copian los ficheros de la BBDD con esta parada. De la misma manera los backups pueden ser completos o incrementales (guardando solo las modificaciones desde el último backup). Los backups completos se pueden realizar copiando los ficheros mediante herramientas de sistema operativo, pero es mucho más común y practico usar una herramienta de backup y recuperación llamada RMAN que la misma BBDD nos proporciona.

Backupset: Es un tipo de fichero de copia. Dentro de un fichero de tipo backupset podemos encontrar los datos de varios ficheros de la BBDD en formato “optimizado”, esto es por ejemplo sin los bloques “vacios” ya que no tiene sentido copiarlos. Es posible también que si el fichero de datos original es muy grande el backupset solo contenga una parte de este. La herramienta de backup RMAN es capaz de crear y leer backupsets y estos pueden estar comprimidos y/o cifrados.

Bind variables: Lo ideal en una BBDD Oracle es reaprovechar las sentencias SQL, esto es que se repitan, ya que la tarea de decidir el plan de ejecución es costosa. Si ejecutamos múltiples veces una misma sentencia solo tenemos que calcular el plan la primera vez, esto es lo ideal. El problema viene con sentencias que son idénticas a excepción de algún parámetro o parámetros. Por ejemplo imaginemos que buscamos clientes y vamos lanzando una select con un identificador de cliente diferente en cada ejecución, Oracle tratará todas las sentencias como diferentes y calculará el plan de ejecución para cada una de ellas. Imaginemos que modificamos la sentencia y en lugar del identificador de cliente usamos una variable “client_id:”, pasamos a Oracle la sentencia en primer lugar y luego el valor con el que vamos a sustituir la variable, en este caso Oracle podrá reaprovechar las sentencias y solo tendrá que calcular el plan la primera vez con un ahorro de recursos de CPU y memoria importante.

Bitmap Indexes: Son un tipo de índices usados en casos en que los campos a indexar tengan muy pocos valores diferentes y no cambien mucho (no se hagan muchos updates a los datos). Con este tipo de índices es muy rápido localizar todos los registros de una tabla que tengan un determinado valor (para mostrarlos o hacer una unión con datos de otra tabla).

Block: El bloque de datos o “data block” es la mínima unidad de datos en Oracle, todas las peticiones de acceso a disco serán de como mínimo de un bloque. Al crear la BBDD decidiremos que tamaño de bloque tendrá y este se usará por defecto para almacenar toda la información que contiene. Los bloques contienen los datos pero empiezan con una cabecera  en la que se indica su dirección, el segmento al que pertenecen, el tipo de segmento, las transacciones que afectan al bloque, el SCN del bloque,… entre muchas otras cosas.  El tamaño “por defecto” actualmente es de 8Kb, y puede variar de 2Kb a 32Kb, es posible tener diferentes tipos de bloque en una misma BBDD especificando el tipo de bloque “diferente” a nivel de tablespace. En el caso de tablas un tamaño de bloque grande es contraproducente si queremos acceder solo a una fila o ventajoso si queremos acceder a todas las filas que contienen (por esta causa en entorno OLTP se acostumbra a usar el tamaño “por defecto” y en entornos DWH tamaños un poco mayores).

Booleano: Es un tipo de datos que puede tener los valores cierto o falso (o no estar inicializado que no es ninguno de los anteriores) y es un tipo de datos que Oracle no tiene de manera nativa en SQL (no existen tablas en oracle con columnas de tipo “booleano”). En las tablas se acostumbra a usar un campo carácter de longitud uno, (que almacena una  “S”/”N” o “Y”/”N”), o un numero de longitud uno (como un uno o un cero), pero no hay una regla “fija”. Por el contrario en el lenguaje de programación nativo de Oracle PL/SQL sí que existe este tipo de datos. En otras palabras en código lo podemos usar y para almacenarlos en las tablas tendremos que decidir cómo queremos hacerlo.

“B-Tree” Index : El índice B-tree es el tipo de índice por defecto de Oracle,  se describe siempre con la imagen de lo que vendría a ser un árbol invertido (una especie de pirámide) con un bloque en la parte superior del que cuelgan otros y de los del segundo nivel cuelgan a su vez otros… etc. Los bloques que formarían lo que son las “ramas” del árbol se llaman “branch blocks” (bloques rama), los que están al final de cada rama (correspondiendo a las hojas) se llaman “leaf blocks” (bloques hoja). En los bloques “branch” hay un índice que indica que rangos de valores hay en los bloques “branch” o “leaf” que cuelgan de ellos. Cuando un bloque “leaf” está lleno y tenemos que insertar un registro entre los datos que ya contiene se produce un “split” y el bloque se divide en dos (dos “leaf” o un “branch” y dos “leaf”).  Los bloques de tipo “leaf” están enlazados entre ellos, cada uno tiene un puntero al anterior y al siguiente de manera que si queremos  recorrer un rango de valores en un índice “B-Tree” podamos “saltar” de un bloque “leaf” a otro sin tener que recorrer de nuevo todos los “branch blocks” superiores. En otras palabras que cada “hoja” tiene la dirección de la anterior y la siguiente, un “Index Range Scan” consiste en recorrer todo un grupo de hojas siguiendo esas indicaciones y saltando de hoja en hoja desde la primera que encontramos hasta la última que contenga datos que nos interesen.

Buffer Cache: Oracle almacena la información en disco, pero el disco es lento por lo que los bloques de datos se suben a memoria antes de trabajar con ellos, la zona de memoria en que se almacenan es la “buffer cache”.  Esto permite además “compartir” los bloques de datos entre diferentes usuarios, ya que el acceso a los bloques en la “buffer cache” es compartido entre todos los usuarios que usan la misma instancia. Oracle gestiona que bloques se quedan en la “buffer cache” y que bloques se eliminan de ella en función de si se accede mucho a ellos o no (los menos solicitados se sustituyen por otros nuevos si no queda espacio libre), ya que por lo general tenemos una “buffer cache” mucho menor que la cantidad de datos a la que accedemos. Simplificando mucho, a mayor “buffer cache” mejor rendimiento, ya que se tendrá que acceder menos a disco (a partir de cierto punto, no obstante, puede no presentar ventaja alguno o incluso ser contraproducente). Mediante parametrización podemos definir o influenciar en el tamaño de la “buffer cache”.

C

Cache fusion: Las instancias de BBDD tienen  zonas de memoria destinadas a almacenar los bloques de datos para evitar tener que buscarlos a disco (que es mucho más lento). Si usamos Real Application Clusters de Oracle, con el que tenemos varias instancias en diferentes maquinas accediendo a la misma base de datos, estas diferentes instancias se pueden pedir unas a otras bloques de datos en lugar de ir a disco a por ellos. Esto se hace a causa de que la transmisión de los datos entre maquinas por red sigue siendo más rápida que acceder a la misma en disco, y es posible que una de las instancias tenga bloques modificados que aún no se han copiado de nuevo a disco (por lo que la imagen de disco es “vieja”).

Cardinality: La cardinalidad nos indica el número de valores que tiene un conjunto, esta palabra se usa normalmente en los planes de ejecución de las selects. Oracle estima las cardinalidades de las condiciones de las selects para decidir cómo accede a los datos (leyendo toda la tabla o mediante índices por ejemplo).

Cartesian Joins: Los llamados productos cartesianos son uniones de tablas en que se unen todas las filas de una tabla con todas las de la otra sin ningún tipo de filtro.  No acostumbra a usarse normalmente ya que la cantidad de registros resultante aumenta de manera exponencial con el tamaño de las tablas.

catalog.sql: Es uno de los scripts que se lanzan durante la creación de las BBDD, y es el encargado de crear las tablas internas que usa la BBDD para su propio funcionamiento. Actualmente es poco común lanzarlo manualmente, ya que se encarga de ello la herramienta DBCA “Database Creator Assistant”.

Chaining Rows: Los bloques de Oracle tienen un determinado tamaño (8Kb por defecto), que pasa si insertamos filas de ocupan más espacio que el disponible en el bloque? Se producen filas encadenadas, en las que una fila ocupa varios bloques. Cada bloque tiene una parte de los datos y un puntero al siguiente bloque con más datos de la misma fila. La presencia de filas encadenadas es problemática para el rendimiento ya que obliga a realizar muchos más accesos a disco.

Character Sets: El juego de caracteres es otra de las opciones que deberemos escoger al crear la BBDD, nos definirá que caracteres puede almacenar la BBDD. Un juego de caracteres es una tabla en que asignamos a cada glifo (símbolo o imagen) de un lenguaje un número que será lo que la BBDD va a almacenar, puede cubrir todos los glifos existentes en el lenguaje o no. Por ejemplo el juego de caracteres US7ASCII permite almacenar las letras latinas no acentuadas, los números y algunos símbolos (comas, puntos, ..). El ISO8859P1, incluye los del US7ASCII mas letras acentuadas y algunos símbolos extra como como las dobles comillas “bonitas” del Word, pero por ejemplo no el símbolo de euro, el UTF8 (del que hay múltiples versiones, ya que se va ampliando) permite multitud de caracteres en diferentes alfabetos (Latino, Cirílico, Arábico, Hebreo,…). El US7ASCII y el ISO8859P1 son de “longitud fija”, cada carácter ocupa siempre el mismo número de “bytes”, el UTF8 según la versión puede ser de longitud fija o variable. El uso de UTF8 tiene contrapartidas a nivel de espacio ocupado, programación y compatibilidad con programas antiguos, si bien por su flexibilidad es el usado “por defecto” en Oracle (en concreto el AL32UTF8).

Checkpoint: Es una operación que se realiza en la BBDD cada cierto tiempo consistente en escribir en las cabeceras de todos los ficheros de datos y ficheros de control el SCN actual en el que se encuentra la BBDD así como bajar a disco todos los bloques de datos de la cache que hayan sido modificado. La realización periódica de checkpoints permite que en caso de caída la recuperación de la BBDD sea más rápida y libera espacio en la cache de buffers (un bloque modificado no puede ser sobre escrito hasta que no se almacena en disco). Durante la parada “ordenada” de la BBDD se realiza un checkpoint y también cada vez que cambiamos de fichero de “redo log online”.

Columns: Las tablas de BBDD están formadas por una o varias columnas (en la versión 12c podemos llegar a 1000 (pero más de 200 ya empieza a ser mala idea, por ejemplo por el tema de las filas encadenadas / migradas entre otros). Cada columna tiene un tipo de datos y una longitud que definirá la información que podrá almacenar.

Commit: Las transacciones en Oracle deben terminarse con la confirmación de los cambios (commit) o su rechazo (rollback). La confirmación puede ser explicita lanzando el comando “commit” o implícita realizando alguna operación de DDL que provoca la confirmación de la transacción en curso.

Compression: En Oracle es posible usar compresión en los datos almacenados en disco (y en algunos entornos en memoria) para poder ubicar más información en menos espacio (a cambio de algo más de consumo de CPU cuando los descomprimimos al acceder a ellos).

Concurrency: Oracle es una BBDD multiusuario, de manera que todos pueden acceder de manera simultánea a los datos disponibles.

Consistency: Oracle permite tener lecturas “consistentes” de los datos, y esta consistencia puede ser de diferentes “niveles” (llamados niveles de aislamiento). Por defecto un usuario vera la versión “original” de una tabla incluso si alguien modifica sus datos y hace commit mientras la lee. Este nivel de “aislamiento” es el llamado “Read Commited”, no obstante sería posible leer una tabla, que otra sesión la modificara hiciera commit, y al volver a leerla nosotros viéramos que han cambiado los datos. Podemos modificar el nivel de aislamiento y subirlo al máximo (llamado “serializable”) en la que los datos de todas las tablas serán siempre los existentes al iniciar la transacción independientemente de que otras transacciones cambien sus datos.

Constraints, Integrity: Las constraints con condicionantes, relacionados con los valores que pueden tener los datos en las tablas. Podemos forzar que una determinada columna no sea nula, o sea única, o sea mayor o menor que un cierto valor o que tenga un valor “aparejado” en una fila de otra tabla. En función de que hagan las constraints son de tipo  “NOT NULL”, “UNIQUE”,”PRIMARY”, “CHECK” o “FOREIGN”.

Container Database (CDB): Hace unos años Oracle nos sorprendio cambiando radicalmente la “arquitectura” de las BBDD con la técnologia “Multitenant”. En esta arquitectura existe una BBDD “contenedor” llamada CDB a la que se conectan otras BBDD de tipo “pluggable”. Permite un nivel de consolidación mucho mayor al del anterior modelo ya que las PDB’s de un determinado CDB comparte mucha de la infraestructura necesaria para su funcionamiento. Teóricamente Oracle ya no recomienda usar BBDD que no sean “Multitenant”, habiendo “deprecado” el modelo anterior.

Contention: En las BBDD existen multitud de recursos que solo pueden ser accedidos por un número limitado de personas/procesos a la vez, en caso que varios quieran acceder de manera simultánea se produce contención. Podemos ver contención por los recursos, al acceder a disco, a CPU o a las diferentes zonas de memoria o por acceso a los objetos de la BBDD (bloqueos de filas o tablas).

Control Files: Los ficheros de control son partes cruciales de la estructura de la BBDD, para intentar evitar su perdida normalmente existen varias copias idénticas en diferentes ubicaciones. En ellos se almacenan entre otras cosas la localización y estado de cada uno de los ficheros de datos, o la localización y estado de los ficheros de redo así como el estado general de la propia BBDD y localización de los últimos ficheros de backup. Son unos de los primeros ficheros que se leen al arrancar la BBDD.

Cost Based Optimizer: El optimizador basado en costes es una “caja negra” que decide cómo se van a ejecutar las sentencias SQL. Toma en consideración las estadísticas existentes de las tablas y el propio sistema, estadísticas tomadas al vuelo, estado de la memoria, “apuntes” tomados en ejecuciones anteriores, etc. En cada nueva versión de la BBDD mejora para que los planes de ejecución sean lo más óptimos posibles.

Cursors: Cuando hemos ejecutado una sentencia el cursor es el elemento de memoria que nos “apunta” a los registros seleccionados. Nos podemos ir moviendo a través de el para ir accediendo a los diferentes registros uno tras otro. En una transacción podemos tener múltiples cursores abiertos e irnos moviendo por ellos según nos convenga.

D

Database: Esta es quizás una de las entradas más difíciles de definir, hasta la fecha venía diciendo que eran todos los elementos almacenados en disco que pertenecían a una misma unidad de almacenamiento de datos. Si esta definición ya no era muy ajustada, con la tecnología “Multitenant” lo es menos. A grandes trazos, en una instalación de Oracle tenemos unos binarios de BBDD que se usan para crear y ejecutar un o varias bases de datos (estructuras en disco) y para poder trabajar en cada una de esas esas estructuras en disco se “levantan” una o varias “instancias” que son un grupos de procesos y zonas de memoria.

Database Creator Assistant: Antiguamente para crear una BBDD (a grandes trazos) se generaba un fichero de inicialización (mediante un editor de texto) se lanzaba el comando de creación de la BBDD y posteriormente una serie de scripts para crear las tablas internas de gestión de la propia BBDD. Finalmente podíamos crear nuestros tablespaces, usuarios y cargar nuestros datos. A fecha de hoy esto ya ha pasado a la historia y disponemos de un asistente grafico (o en modo línea de comandos) que realiza estas tareas por nosotros, el DBA o Database Creator Assistant.

Database Links: Los Database Links nos permiten acceder a tablas de BBDD remotas  de manera “transparente” (como si de tablas de la misma BBDD local se tratara). Básicamente una BBDD actúa como si fuera una “aplicación cliente oracle” para poder acceder mediante conexiones de red a datos de otra BBDD que puede estar a miles de kilómetros.

Data Dictionary: El diccionario de datos son multitud de tablas que se encuentra ubicadas principalmente en el tablespace SYSTEM y contienen toda la información de definición de la BBDD. En estas tablas se almacenan los usuarios, permisos, objetos existentes, etc. Podemos usar las tablas del diccionario de datos para consultar información de la BBDD, existen multitud de vistas que nos informan de múltiples aspectos de la BBDD (DBA_TABLES, DBA_USERS , DBA_OBJECTS…). Las tablas que empiezan por DBA_% nos dan datos de toda la BBDD, las que empiezan por ALL_% de los objetos sobre los que tenemos permisos y las que empiezan por USER_% de nuestros objetos. Con la nueva arquitectura “multitenant” ha aparecido un  nuevo tipo el CDB_% que se encuentra por encima de la DBA_%, la CBD_% nos da información a nivel de todas las BBDD conectadas al mismo CDB y del propio CDB. Las CBD_% y DBA_% solo son accesibles a usuarios con privilegios. Por ejemplo para ver las tablas que hay, y en función de nuestros permisos y de que “alcance queramos ver” podemos consultar {USER|ALL|DBA|CDB}_TABLES.

Data Files: Toda la información que almacenemos en una BBDD Oracle finalmente se acabará ubicando en ficheros de datos, estos pueden estar en un sistema de ficheros standard (ext4, NTFS, NFS, ZFS, …) o en un sistema de ficheros especifico de Oracle como (ASM/ACFS). Antiguamente se podían almacenar también en particiones de disco crudas (raw) si bien este tipo de almacenamiento ya no se permite.

Data Manipulation Language (DML): Son las sentencias que permiten manipular la información almacenada dentro de los objetos de la BBDD (tablas), los ejemplos típicos son las sentencias INSERT, UPDATE, DELETE.

Data Warehouses (DWH): Son BBDD preparadas específicamente para análisis de datos, en ellas prima la velocidad al tratar grandes cantidades de información más que la concurrencia de usuarios.

Data Definition Language (DDL): Son las sentencias que permiten manipular (crear, modificar, borrar) elementos  de la BBDD (tablas, vistas, índices). Los ejemplos típicos son el CREATE, DROP o ALTER.

Deadlocks: Un deadlock es una situación en que dos o más sesiones se bloquean entre ellas sin posibilidad de solución. Un ejemplo “simple” seria el siguiente:

Imaginemos la sesión “S1” boqueando un objeto “O1” y continuando su trabajo. Al cabo de un rato la sesión “S2” bloquea el objeto “O2” y continua su trabajo. Un rato más tarde “S1” quiere bloquear “O2” pero no puede (lo tiene “S2” en exclusiva) y se queda parada. Finalmente es “S2” que quiere bloquear “O1” y también se queda parada.

Oracle detecta este tipo de incidentes y los soluciona desconectando las sesiones implicadas con un error “ORA-00060”. Este tipo de errores no tienen nada que ver con la propia BBDD sino con cómo han sido programadas las aplicaciones que se conectan a ella.

Dependences: Los objetos de la BBDD en muchos casos pueden tener dependencias entre ellos. Esto es por ejemplo un índice que “depende” de la tabla a la que pertenece, o un paquete de PL/SQL que depende de todos los objetos a los que hace referencia (si alguno cambia o desaparece podría dejar de funcionar).

Deprecated: Esta es la palabra que usa Oracle para hablar de funcionalidades que ya no considera “actuales”, que recomienda no usar y que deberíamos cambiar por sus versiones actuales o sus sustitutivas. Si una funcionalidad aparece como “deprecated” en una determinada versión, veremos que sigue funcionando como se espera de ella, pero Oracle no la va a mejorar y en siguientes versiones de la BBDD podría ya no estar disponible.

Direct Path: Es un tipo de acceso a los datos en disco, para lectura o escritura que se salta el paso por el buffer de bloques en memoria. Permite leer o escribir los datos de una manera mucho más rápida pero tiene algunos inconvenientes (en el caso de las lecturas es que no nos quedan los datos en cache por lo que si volemos a acceder a ellos se tendrán que leer de nuevo).

Distributed Transactions: Es posible tener transacciones que incluyan objetos en diferentes entornos (incluso entre entornos Oracle y no Oracle). Si hacemos modificaciones queremos que, o se haga el cambio en todos ellos o en ninguno. Para ello se utilizan las transacciones distribuidas que realizan el commit en varias fases para intentar asegurar al máximo posible que la operación se ha realizado correctamente en todos los entornos.

Dual table: Es una tabla que encontraremos en todos los gestores de BBDD Oracle, hace ya muchas versiones que es “virtual” (no existe realmente en disco). Tiene una columna con una solo fila con el valor “X” y no es posible modificarla (es parte del diccionario de datos). Se puede usar cuando queremos hacer llamadas a funciones para retornar un valor, por ejemplo “select systdate from dual”. Si queréis saber más detalles de esta curiosa tabla “dual” os paso el link a la wikipedia – DUAL Table.

E

Enterprise Edition: Es la versión estrella de la BBDD (y por tanto la más costosa en licencias) dispone de funcionalidades avanzadas como paralelismo, reorganización online, auditoría fina, BBDD virtual, etc y permite activar las funcionalidades y packs de pago como RAC, particionado, asistentes de diagnósticos y Tuning. Está pensada para entornos críticos, muy grandes, 24×7 (o todo lo anterior junto).

Enterprise Manager, EM Express: Son las consolas de administración gráfica que acompañan a la BBDD, la primera se ejecuta mediante un proceso java de sistema operativo que deberemos arrancar por separado de la BBDD, la segunda más ligera y simple que la primera apareció con la versión 12.x de la BBDD y se ejecuta dentro de la propia BBDD.

Execution Plans: La BBDD debe decidir cómo acceder a las tablas (por índice, por acceso directo), en qué orden, con que método unir las filas, con que alegorismo de ordenación o agrupación tratar los resultados, todo esto lo decide el optimizador cuando crea el plan de ejecución de las sentencias. Crear planes de ejecución es costoso por lo que la BBDD los almacena durante un tiempo en la “shared pool” para permitir que se reutilicen en caso que se ejecute de nuevo la misma sentencia.

Extents: Los extens son parte de la estructura lógica de la BBDD, la estructura lógica más pequeña son los bloques, un conjunto de bloques es un extent. Las tablas y otros objetos de la BBDD “crecen” agregando a ellas uno o varios extents cada vez.

External Tables: Oracle permite acceder en modo lectura a ficheros de datos externos, que pueden tener formato texto o binario (de tipo datapump). El acceso a estas tablas se realiza como si de tablas normales se tratara permitiendo hacer selects y uniones sobre ellas y se usan de manera frecuente para carga de datos.

Extraction, transformation and loading (ETL): De denomina así al conjunto de procesos usados para enviar información hacia entornos de análisis de datos, existen en el mercado multitud de herramientas usadas para este fin.

F

Fast Full Index Scans: Es uno de los métodos de acceso a datos de que dispone Oracle.  Se usa cuando los datos a los que queremos acceder están contenidos completamente en el índice y no hay posibilidad de que haya nulos. Consiste en acceder a todos los bloques que forman el índice sin ningún orden particular.

Fast Recovery Area: Hasta la versión 9.x de la BBDD la gestión de ciertos tipos de ficheros como “redo logs archivados” o backups se realizaba manualmente, nosotros debíamos borrar los que considerábamos obsoletos y vigilar que no ocuparan demasiado espacio. Esto era especialmente problemático en máquinas con múltiples BBDD en las que si una se descontrolaba podía causar problemas al resto al llenar el disco. A partir de la versión 10.x aparece la Fast Recovery Area que consisten en una ubicación de disco y un tamaño que debemos definir. Una vez hecho si enviamos los “redo logs  archivados” y los backups  a esta zona, la propia BBDD se encargará de llevar una contabilidad del espacio ocupado, evitando que lo sobrepasemos y purgando ficheros “viejos” en caso que nuestra política de bakcup así lo permita. En caso que la BBDD empiece a generar más redo del previsto no llegará a llenar el disco, si no que se “parará” cuando haya ocupado todo el espacio asignado a su FRA (evitando problemas en el resto de BBDD). Además no tendremos que programar un “borrado” de los ficheros obsoletos, la propia BBDD realizará esa tarea.

Fine Grained Auditing FGA: Es un tipo de auditoría avanzada que podemos usar en la versión “Enterprise Edition” de la BBB. Permite auditar accesos en función de la columna o los valores de los datos accedidos permitiendo un nivel de auditoria mucho más detallado.

Flashback: Son diferentes tipos de operaciones en la BBDD que permiten “rebobinar” o ver los datos como estaban en un tiempo anterior. Podemos hacer “Flashback Query” para ver ciertos datos como estaban en momentos anteriores en el tiempo, podemos hacer “Flashback Transaction”, para poder ver los cambios que ha realizado una determinada transacción, “Flashback Table” para “rebobinar” en el tiempo una tabla, “Flasback Drop” (que básicamente es recuperar una tabla de la papelera de reciclaje) y finalmente “Flashback Database” que permite “rebobinar” en el tiempo toda la BBDD. Algunas de estas operaciones solo están disponibles en versión Enterprise Edition.

Foreign Keys: Es un tipo de “constraint” que se puede crear en las tablas y que vincula una o varias columnas con las correspondientes de otra tabla. La tabla con la constraint “Foreign Key” se acostumbra a llamar tabla “hija” y la que tienen los registros que referenciamos “padre”. Esto evita que se creen registros en la tabla “hija” que no dispongan de registros relacionados en el “padre” o que se eliminen los registros en la tabla “padre” si quedan registros en la “hija” relacionados.

Full Index Scan: Es uno de los métodos de acceso a datos de que dispone Oracle.  Se usa cuando los datos a los que queremos acceder están contenidos completamente en el índice y no hay posibilidad de que haya nulos. Consiste en acceder a todos los bloques que forman el índice en el propio orden del índice, de manera que los registros se retornen ordenados.

Full Table Scans: Es uno de los métodos de acceso a datos de que dispone Oracle.  Se usa cuando se requiere acceder a un porcentaje elevado de los datos de la tabla (o a todos ellos). Se acostumbra a pensar que los “Full Table Scans” son malos para el rendimiento de la BBDD, no obstante en ocasiones puede ser el sistema de acceso más óptimo ya que lee los bloques de la tabla en grandes grupos en lugar de uno a uno.

Function Based Indexes: En Oracle podemos crear índices en las columnas de las tablas que accedemos con más frecuencia. Si el acceso a ciertos datos se realiza tratando estos datos con algún tipo de función (pasando los datos a mayúsculas, realizando algún tipo de operación matemática o de normalización) los índices sobre las columnas pueden resultar inútiles. En estos casos podemos crear índices sobre los resultados de una función en lugar de sobre la propia columna.

G

Global Database Name: Es el nombre que tiene la BBDD añadiendo el dominio de red en el que se encuentra (por ejemplo orcl.dominio.com), este nombre tiene que ser único en la red en la que se encuentra la BBDD.

Global Indexes: Oracle permite crear índices sobre tablas particionadas, estos índices pueden ser globables o locales. En el caso de los globales el índice cubre los datos de todas las particiones que forman la tabla. Este tipo de índices queda invalidado al realizar operativa sobre cualquiera de las particiones.

Grid Computing: Hace ya unos años, con la versión 10g de la BBDD apareció un nuevo modelo de BBDD el Grid Computing. Con este modelo el escalado de rendimiento se produce agregando nodos de computación en una red “Grid” en lugar de adquiriendo servidores de mayor capacidad. A nivel de BBDD la funcionalidad de Grid la obtenemos con la versión RAC (Real Application Clusters) en que varios nodos acceden a un solo conjunto de datos como si fuera una unidad (desde el punto de vista de los clientes).

H

Hash Partitioning: Es un tipo de particionado en que cada fila se envía a una u otra partición en función de que resultado de aplicar una función de hash a un valor clave. Permite repartir equitativamente los datos entre las particiones aún que estos estén muy sesgados.

Hints: Son una especie de “códigos” que podemos incluir en las sentencias SQL que influyen o directamente indican a Oracle cómo queremos que las ejecute. Acostumbran a ser un “último recurso” ya que estamos forzando al optimizado a hacer cosas que no considera óptimas, y puede impedir que si actualizamos el gestor se aprovechen nuevas funcionalidades, o en un futuro ante cambios de la estructura de datos o del volumen de datos provoquen efectos negativos.

Hybrid Columnar Compression: Es un tipo de compresión de los datos disponible en algunos de los dispositivos de ingeniería de Oracle. Ofrece un nivel de compresión mucho más elevado del normal mediante reorganización de la información, segmenta la tabla y almacena juntos los datos por campos, con lo cual la posibilidad de tener datos “repetidos” de lado es muy elevada y permite unos ratios de compresión óptimos.

I

Image Copies: Es un tipo de fichero de copia de la BBDD, en que cada fichero de backup corresponde exactamente a un fichero de la BBDD. Se pueden crear mediante la herramienta de copia RMAN o mediante herramientas de sistema operativo.

Incarnations: Cuando se realiza una recuperación parcial de la BBDD esta se “abre” mediante un comando llamado “resetlogs”, este comando cambia la BBDD convirtiéndola en una nueva BBDD, lo que llamamos una nueva encarnación. Los backups realizados con anterioridad ya no serán válidos y los contadores de redo logs y los propios redo logs se reinicializan ya que es como si realmente fuera una nueva BBDD.

Index: Para acceder a determinados datos de una tabla podemos leer toda la tabla hasta encontrarlos o tener una especie de registro que en función de unos campos clave no indique dónde están las filas que buscamos, eso sería un índice. Los hay de mucho tipos, B-tree, B-tree invertido, Bitmap, Domain cada tipo dispone de diferentes ventajas e inconvenientes y los escogeremos en función del uso que queramos darle y de los datos que vamos a indexar. Existe la creencia de que el acceder a los datos de una tabla mediante índice es siempre la mejor opción, pero no es cierto, en función de los datos y el volumen de estos respecto al total de la tabla un acceso por índice puede variar de óptimo a pésimo. Notar que cada índice que tiene una tabla tiene que ser actualizado para cada insert/update/delete que hagamos en la tabla, por tanto a mas índices más trabajo a hacer.

Index Organized Tables (IOT): Hay casos extremos en que queremos tener ordenados casi todos los campos de la tabla, en ese caso quizás sea mejor idea ordenar la propia tabla (en las BBDD relacionarles los datos de las tablas no tienen por qué estar en ningún orden concreto), a estas tablas “ordenadas” las llamaremos Index Organized Table.

Index Unique Scans: Es la manera más óptima de acceder a una fila de datos dentro de una tabla grande o muy grande, por acceso mediante índice único (si no contamos el acceso por rowid, que acostumbra a tener una utilidad limitada).

Inicialitzation Parameter File (INIT.ORA): Cuando arranca la BBDD esta debe saber qué y cuántos procesos arrancar, con que parametrización, cuanta memoria ocupar, donde están los ficheros de control, etc. Toda esta información la encontraba en un fichero de texto llamado init.ora (o init<SID>.ora). Este fichero tenía el inconveniente que para cualquier cambio era necesario reiniciar la BBDD y a partir de la versión 9i de la BBDD fue sustituido por una versión binaria llamada SPFILE.

Inicialitzation Parameters: Son todos los parámetros que podemos incluir en el fichero SPFILE o INIT.ORA y que van a influenciar como ópera nuestra BBDD. Existen centenares de ellos, algunos se definen al crear la BBDD y no pueden ser modificados otros los podremos modificar dinámicamente o mediante un reinicio del gestor.

In Memory Column Store: En la version 12c de la BBDD ha aparecido una nueva funcionalidad que permite agrupar los datos de una tabla por columnas (en lugar de por filas) y tenerlos almacenados en memoria. Todo esto al mismo tiempo que los tenemos almacenados de manera tradicional en disco y cualquier cambio que realicemos queda reflejado al momento en los dos sitios. Para cierto tipo de BBDD y sentencias (que aprovechan la organización en columnas) esto implica una mejora en el rendimiento espectacular.

Instances: Cada conjunto de procesos y estructura de memoria que accede a los ficheros de una BBDD es una instancia. Se puede dar el caso que una única BBDD sea accedido por múltiples instancias (RAC) o a partir de la 12c, que una instancia acceda a los ficheros de varias BBDD (en el caso de las pluggable databases). Cada instancia que accede a una BBDD debe tener un identificador único que llamaremos SID. De la misma manera dentro de una misma máquina todas las instancias deben tener diferentes SID. En la versión más simple (BBDD monoinstancia) la instancia acostumbra a llamarse igual que la BBDD pero no es obligatorio, de hecho por esto último mucha gente confunde BBDD e instancia.

Invisible indexes: En ocasiones necesitamos realizar pruebas agregando y/o eliminando índices, esto puede llegar a causar problemas especialmente si nos vemos obligados a hacerlo en entornos con usuarios trabajando. En estos casos podemos usar índices “invisibles” o hacer invisible algunos de los existentes de manera que los usuarios dejen de usarlos (pero Oracle los seguirá manteniendo, no los habremos borrado). Solo en las sesiones en que modifiquemos el parámetro de uso de índices invisibles estos se usarán permitiendo hacer fácilmente pruebas o modificar temporalmente el comportamiento de las sentencias en ellas.

J

Java: Es un lenguaje de programación ubicuo y que también podremos usar de manera “nativa” en la BBDD, se ejecutará dentro de una JVM que viene incluida con la BBDD. Esto le permite acceder a los datos de la propia BBDD de manera tan eficiente como lo hace el lenguaje nativo de Oracle PL/SQL.

JDBC: El “Java Database Conectivity” es un driver que permite a los programas escritos en Java acceder a BBDD relacionales, cada BBDD dispondrá de sus propios driver JDBC y Oracle no es la excepción. Existen diferentes versiones del driver para las diferentes versiones de BBDD y java de manera que se puedan aprovechar las nuevas funcionalidades incluidas en cada versión de ambos.

Jobs: Son tareas que se programan para su ejecución dentro (o incluso fuera en el caso de scheduler) de la BBDD. En Oracle existen dos programadores de tareas, el que controlamos mediante el paquete DBMS_JOB y el “SCHEDULER”. El segundo ha sustituido el primero a partir de la versión 10g de la BBDD es mucho más avanzado y dispone de muchas más funcionalidades. Siguen existiendo ambos por lo que hoy en dia no es extraño encontrar “jobs” de DBMS_JOB especialmente relacionados con aplicaciones “legacy”.

Joins (cartesian, inner join, outher, join): Son maneras de unir filas de dos tablas o de dos conjuntos de resultados durante la ejecución de una sentencia SQL. En función de si unimos todos con todos, solo los coincidentes de ambos grupos o todos los de un grupo más los coincidentes del otro los llamamos de una manera u otra.

K

Keys: Son columnas o conjuntos de columnas que se usan como “claves” en una tabla, permitiendo asegurar que las filas son únicas (Primary Key o Unique Key) o filas relacionadas con otras de otras tablas (Foreign Key).

L

Library Cache: Es una zona de memoria dentro de la llamada Shared Pool accesible a todos los procesos de usuario que se ejecutan en una instancia. En ella se almacenan los planes de ejecución de las sentencias así como código PL/SQL de procedimientos funciones y paquetes de manera que puedan ser aprovechadas parcial o totalmente en caso que se ejecuten de manera repetida. La idea es evitar tener que gastar recursos de CPU y disco en calcular planes de ejecución siempre que sea posible.

Listener: Es uno o varios procesos que actúan como la puerta de entrada a las instancias de BBDD en el caso de conexiones remotas (también podemos conectar mediante lis tener en local si queremos). Cuando conectamos a una instancia (y si no se usa una cosa llamada “shared servers”) tendremos a nuestra disposición en exclusiva un proceso en el servidor que ejecutará nuestras sentencias. Para llegar a este punto inicialmente conectamos al “listener” que arranca el proceso en el servidor de BBDD, nos enlaza con él y se desentiende quedando a la espera de nuevas peticiones de otros clientes. Si no arrancamos el listener no podremos conectar remotamente a la BBDD por mucho que esté en marcha. A partir de la versión 12c y si usamos “pluggable databases” las conexiones a este tipo de BBDD siempre tendrán que ser mediante listener incluso desde dentro del servidor en el que se ejecuta la BBDD. Para la BBDD “container” seguimos pudiendo conectar sin listener en local.

Local Indexes: Son índices que cubren los datos de una tabla partición a partición, esto es, que un índice local en realidad son múltiples índices, cada uno solo con los datos existentes en una partición. Son buenos si realizamos “reorganizaciones” ya que solo las partes del índice correspondientes a particiones modificadas se tendrán que reorganizar (esto es importante cuanto más grande es la tabla) pero normalmente solo los podremos aprovechar si el optimizador tiene claro en que partición están los datos a buscar.

Localy Managed Tablespaces: Son tablespaces en que la gestión del espacio ocupado por los segmentos, o en otras palabras los bloques en que se encuentran ubicadas las tablas y índices se gestiona dentro de los mismos ficheros que forman el tablespace. Para los que no son de tipo “Localy Managed” toda esta información se almacena en tablas del tablespace SYSTEM. El tipo Localy Managed ofrece menos “contención” y es la opción por defecto en las últimas versiones del gestor.

Locks: Los bloqueos se producen cuando uno o varias transacciones compiten por los mismos recursos, por ejemplo si dos transacciones intentan modificar una misma fila, la segunda deberá esperar a que la primera finalice la transacción (con commit o rollback) antes de poder continuar quedando “parada” (en lo que se llama un bloqueo). Hay sistemas de BBDD que mantienen una “lista de filas bloqueadas”, lo que es un grave problema de caras a la escalabilidad, Oracle por su parte tienen una manera muy particular de gestionar los bloqueos, lo hace mediante “apuntes” en los bloques de datos que contienen las filas bloqueadas. El sistema de Oracle permite que en una misma instancia miles de usuarios tengan bloqueadas millones de filas sin afectar el rendimiento (a diferencia de las BBDD que usan listas), pero la contrapartida es que es extremadamente difícil saber que filas tiene bloqueadas que transacción. Notar no obstante que mediante vistas internas (como la GV$LOCK) es relativamente fácil saber en qué tablas hay filas bloqueadas por que transacciones (pero no que filas).

Log Switch: Los ficheros de “Redo Log Online” almacenan todos y cada uno de los cambios acontecidos en la BBDD (siempre y cuando no usemos la técnica del “nologging”), cuando estos ficheros están llenos o cada cierto tiempo en función de la parametrización se produce un “cambio de log” en que el log actual se cierra y se abre el siguiente. Recordemos que tenemos varios “Redo Log Online” y se escribe en ellos de manera cíclica. Durante el “Log Switch” se bajan a disco todos los bloques de datos que están en memoria y han sido modificados por transacciones ya finalizadas se crea un registro en el fichero de control y se escribe en todos los ficheros de la BBDD el “SCN” actual.

M

Maintenance Window: Se llama así a al grupo de horas en que la BBDD realiza tareas de mantenimiento internas (por ejemplo el paso de estadísticas automático). En días laborables por defecto va de las 22:00h a las 02:00h del día siguiente, y en fin de semana cubre la mayor parte del día. Este tipo de “ventanas” (o franjas de tiempo) de ejecución son usadas por las tareas programadas mediante DBMS_SCHEDULER. Básicamente indican en que momentos del tiempo pueden estar estas ejecutándose (si una tarea no ha finalizado al acabar la “ventana” que tiene asignada se suspende hasta la siguiente “ventana”).

Materialized Views: Son tal como su nombre indica resultados de vistas que se han guardado en forma de tabla. Por ejemplo si tenemos una vista muy pesada (que tarda en ejecutarse) podemos guardar sus resultados permitiendo consultarlos sin necesidad de tener que ejecutar nuevamente la vista. Esto tiene un inconveniente, si cambian los datos en la tabla o tablas “base” de la vista no vamos a tener resultados actualizados. Las Vistas Materializadas” permiten ser “refrescadas” de manera que los resultados se actualicen, estos  “refrescos” se pueden lanzar bajo demanda, de manera programada o (en algunos casos) se pueden realizar automáticamente cada vez que se modifican las tablas “base”. En ocasiones el refresco implica recrear al completo la vista materializada, en otras solo actualizar ciertos datos (a estos últimos refrescos los llaman “fast”) y usan unas tablas llamadas “materizalized view logs” que mantienen un registro de los cambios en las tablas “base”.

Media Recovery: Al restaurar una BBDD Oracle (o alguno de los ficheros que la componen) de un backup es muy posible que tengamos que realizar “media recovery”. Si la copia de la BBDD se ha realizado en frio la BBDD se puede abrir directamente pero si se ha copiado en caliente (con la BBDD en marcha) deberemos aplicar los cambios necesarios al fichero o ficheros para que quede sincronizado en el tiempo con el resto, esto es el “media recovery”. En otras palabras consisten en aplicar cambios almacenados en los “redo logs archivados” y “online” a un fichero para que “avance” en el tiempo.

Memory Management: La BBDD Oracle requiere que se le asignen ciertas áreas de memoria para su funcionamiento (cache de bloques, zona de ordenación de resultados, zona de almacenamiento de sentencias….). La cantidad de memoria necesaria en cada zona varía en función de cada BBDD (e incluso en una misma BBDD en función del momento del día). En las versiones más antiguas de la BBDD era necesario asignar a mano la memoria a cada zona y para cambiarla se tenía que reiniciar. Con el paso del tiempo la BBDD empezó a gestionar diferentes zonas de la memoria (nos deja darle un valor máximo y en ocasiones un mínimo) y ella automáticamente la reparte en función de las necesidades. A partir de la versión 11g ya existe el parámetro “MEMORY_TARGET” que cubre todas las zonas de memoria. Nosotros indicamos una cantidad de memoria del sistema operativo y la BBDD la gestiona automáticamente y la va moviendo de una zona a otra en función de la necesidad.

Metrics: Una de las tareas necesarias (cada vez menos?) en las BBDD Oracle son los ajustes de rendimiento, que intentan que la BBDD funcione de la manera más optima posible. Para realizar esta tarea la BBDD nos ofrece “métricas”, que son estadísticas del funcionamiento. Podemos acceder a multitud de valores estadísticos (frecuencia y velocidad del acceso a disco, aciertos al acceder a bloques en cache, reaprovechamiento de sentencias sql, …) con los que podemos hacernos una idea de cómo está funcionando la BBDD y permite ayudarnos a la hora de decidir que parámetros / configuraciones modificar. Tenemos métricas accesibles en tablas dinámicas (que desaparecen al cerrar la BBDD) que nos dan datos instantáneos o acumulados desde el arranque de la BBDD y otras que mantienen métricas históricas (el llamado repositori AWR). El acceso a estas tablas de AWR  requiere disponer de una licencia que se paga por separado (la llamada Diagnostics Pack).

Multiplexing: Es una técnica consistente en replicar las partes más críticas de la BBDD de manera que la posibilidad de perder esos elementos sea mínima. Encontramos ejemplos en los ficheros de control (de los que acostumbran a existir dos o tres copias) o los ficheros de redo log online de los que acostumbran a existir un mínimo de dos copias en lo que llamamos un “redo log group”, todos los “redo logs online” de un grupo son idénticos.

Multitenant Architecture: Es una nueva arquitectura de la BBDD, consisten en tener una BBDD llamada CDB (Container Database) que hace de “receptaculo” para otras BBDD llamadas PDB (Plugable Database). Esto se ha pensado para entornos con muchas BBDD ya que permite ahorrar en cada una de las PDB una serie de elementos “comunes” de los que tenemos una sola copia en la CDB que es compartida por todas las PDB.  Además de facilitar la gestión ya que se pueden realizar tareas sobre múltiples PDB’s simultáneamente actuando sobre la CDB. Finalmente esta arquitectura sigue manteniendo las diferentes PDB’s aisladas como si de BBDD normales (o “monotenan”) se tratara. Notar que desde la versión 12c la arquitectura “monotenant” esta “deprecada”, si bien sigue disponible como mínimo hasta la 18c.

N

Nulls: En Oracle nulo indica “valor no inicializado”, no es cero, ni vacío y no lo debemos usar en operaciones aritméticas (igual, menor, mayor, diferente) ya que nunca va a retornar ningún resultado, ni en caso de “null = null”. Existen varias funciones en Oracle que nos permiten “tratar” con los nulos como por ejemplo la NLV o DECODE.

O

OLAP: Olap es un conjunto de funcionalidades y herramientas que permiten hacer análisis multidimensional dentro de la BBDD Oracle. Permite crear “cubos de datos en memoria” y realizar consultas contra ellos con lenguaje SQL.

OLTP: Son las siglas de “Online Transaction Processing” que se usan para identificar las BBDD en las que existe una cantidad elevada de usuarios, realizando transacciones relativamente cortas y con tiempos de respuesta prácticamente inmediatos.

Online Redo Log (“redo logs online”): Son un conjunto de ficheros en los que Oracle almacena (normalmente) todos los cambios realizados en la BBDD de manera secuencial. Son los responsables de asegurar que no se pierden datos ante caídas inesperadas de la BBDD. De hecho cuando hacemos “commit” y confirmamos unos cambios la única certeza que tenemos es que nuestras modificaciones se han almacenado en los “online redo logs”, ya que no necesariamente se hayan gravado aun en los ficheros de datos.

Oracle ASM: Es un tipo especial de instancia especializada en gestionar discos. Entre otras ventajas si usamos ASM podemos modificar la configuración de los discos que usan las BBDD en caliente. La instancia ASM no dispone de ficheros de datos ni de control, solo un fichero de inicialización. Finalmente incidir que la instancia ASM solo accede a disco en caso de reorganización de datos, para la entrada/salida “normal” (lectura de datos de tablas o índices) ASM solo indica la ubicación en la que están los datos, son las propias BBDD quienes se encargan de acceder a ellos.

Oracle Call Interface (OCI): Es un conjunto de librerías escritas en C que permiten acceder a la BBDD Oracle. La mayoría de aplicaciones (que no sean Java) usan OCI para acceder a la BBDD entre ellas muchas de las herramientas cliente de Oracle (SQL*Pus, SQL*Loader, exp, imp, expdp, impdp…).

Oracle Data Pump: Es una herramienta que permite extraer y cargar datos de la BBDD en un formato propietario de Oracle. Viene a sustituir las anteriores “exp” y “imp” ampliando de manera notable las funcionalidades y rendimiento de estas. Cabe notar que es una tarea de servidor (mientras que la “exp” / “imp” era de tipo cliente).

Oracle Enterprise Manager Cloud Control: Es una herramienta de gestión de sistemas informáticos, permite tener control y gestionar hardware (Oracle) y software (tanto Oracle como no Oracle). Es un conjunto de aplicaciones desplegadas sobre Weblogic y con un repositorio en una BBDD Oracle. Para el control y gestión de software Oracle (BBDD, Weblogic, etc) es posiblemente la mejor herramienta existente. La versión “base” es gratuita pero el uso de muchas de las funcionalidades está ligada a disponer de las licencias.

Oracle Text, Multimedia, Locator: Son diferentes funcionalidades que incluye la BBDD y que nos permiten aumentar los tipos de datos que sabe “tratar”. Algunas requieren licencia separada otras vienen incluidas con la propia licencia de la BBDD. Si usamos Oracle Text podremos crear índices de tipo texto (y preguntar a la BBDD por registros de un determinado “tema”), si usamos Oracle Multimedia podremos almacenar videos o imágenes (y buscar imágenes similares a otras), o si usamos Oracle Locator (o su versión gratuita “Spatial”) podremos buscar puntos en un mapa cercanos a otros.

P

Packages, procedures, functions: Son objetos típicos de lenguajes de programación y que en Oracle también podemos encontrar para ser usados con su lenguaje de programación “nativo” el PL/SQL. Su utilidad y funcionamiento es idéntico al que podemos esperar en cualquier otro lenguaje de programación, de manera que en la BBDD no solo podemos almacenar datos sino también el código que opera con esos datos.

Parallel Execution: Una de las funcionalidades de la BBDD Oracle en su versión “Enterprise Edition” es la ejecución en paralelo de las tareas. Básicamente consiste en dividir una tarea en diferentes partes que pueden ser ejecutadas al mismo tiempo por diferentes cores de la máquina, permitiendo que finalice en mucho menos tiempo. En Oracle solo tenemos que indicar que “paralelismo” permitimos en las tablas e índices y el propio “optimizador” decidirá si las sentencias que ejecutemos se pueden beneficiar de la ejecución en paralelo, no es obligatorio prepararlas en modo alguno para aprovechar esa funcionalidad.

Parsing: Es una de las primeras las fases de ejecución de una sentencia SQL, consiste entre otros pasos en revisar que es correcta sintácticamente, que tenemos permisos para acceder a todos los objetos implicados y en decidir qué plan de ejecución (como y en qué orden) accedemos a los objetos (tablas e índices) para obtener el resultado. El “parseo” puede ser “hard” esto es realizar todos los pasos desde cero o “soft” en el caso que Oracle encuentre una sentencia idéntica ya “parseada” en memoria y aprovechemos algunos de los pasos realizados anteriormente.

Partitioning: Es una opción de la versión “Enterprise” (de las que se pagan por separado). El particionado consiste en “dividir” las tablas e índices en trozos para facilitar el acceso a los datos. Por ejemplo si tenemos una tabla de gran volumen y sabemos que normalmente accedemos a ella filtrando por fechas podemos particionar la tabla por el campo de la fecha. A nivel físico la tabla será realmente un conjunto de tablas cada una con los datos de un determinado rango de fechas (por ejemplo un mes, o un día), pero a nivel lógico la veremos como una sola tabla. No tendremos que modificar nuestras sentencias SQL para usar el particionado, será Oracle que realizará una tarea llamada “partition prunning” consistente en solo acceder a las particiones del rango de fechas que nos interesa (evitando tener que acceder a los datos de todas las demás) y acelerando de manera notable nuestras sentencias.

PDB$SEED: En las BBDD de tipo “multitenant” existe siempre una BBDD llamada PDB$SEED, es el conjunto de ficheros usados como base para crear el resto de BBDD de tipo PDB. Las BBDD de tipo PDB se crean “copiando” e “instanciando” estos ficheros, esta BBDD a priori no pueden ser ni eliminada ni modificada.

Pluggable Database (PDB): A partir de la versión 12c de la BBDD se modificó la arquitectura de la BBDD Oracle con la introducción de las “Container Database” o “CBD” y las “Plugable Database” o “PDB”. Esta nueva arquitectura permite disponer de una BBDD contenedor (o CDB) en la que conectamos varias BBDD de tipo “PDB”. Esto nos permite administrar todas las “PDB” de manera conjunta, ahorrando recursos en el servidor y manteniendo un nivel de aislamiento muy elevado entre ellas. Esta nueva arquitectura facilita en gran medida la consolidación de las BBDD. Actualmente podemos elegir usar la arquitectura tradicional, llamada “single-tenant” o la nueva llamada “multi-tenant”, si bien ha indicado que la tradicional esta “Deprecada” des de la versión 12.1.0.1.

PGA: No, no se trata de golf ;-). La PGA o “Program Global Area” son zonas de memoria privadas que usan los procesos Oracle para almacenar los datos de sus propias sesiones y realizar ordenaciones de los datos con los que trabajan (entre otras cosas). Es una de las zonas de memoria que en versiones antiguas teníamos que fijar de antemano (mediante varios parámetros) y que en las últimas versiones ha empezado a gestionar de manera automática la propia BBDD.

PL/SQL: Es el lenguaje de programación nativo de Oracle, su gran ventaja frente a otros lenguajes de programación es que se ejecuta dentro de la misma BBDD y tiene por tanto un acceso optimo a los datos.

Public Synonyms: Los sinónimos son “alias” o “links” a objetos y en concreto los sinónimos públicos son visibles por todos los usuarios de la BBDD en que se encuentren. No soy muy partidario de ellos ya que pueden causar problemas especialmente si consolidamos diferentes aplicaciones en una misma BBDD (por problemas de colisiones entre ellos, los nombres de sinónimos públicos no se pueden repetir). Permiten acceder a objetos de la misma BBDD o de BBDD remotas (mediante dblinks). Finalmente notar que un sinónimo público no da “acceso” al objeto, es solo un puntero, deberemos dar el acceso al objeto “apuntado” por separado.

Q

Query: Una query es una sentencia SQL que nos permite recuperar datos de nuestra BBDD.

R

Real Application Clusters (RAC): Es una tecnología de la BBDD en que podemos tener varias instancias (grupos de procesos y zonas de memoria) en diferentes servidores accediendo a la misma BBDD (ficheros en disco), todos los servidores de un RAC están conectados por una red privada de baja latencia y alta capacidad. Esta configuración nos da alta disponibilidad (si se cae un nodo podemos continuar trabajando con el resto) y permite crecer añadiendo nodos (no incrementando los recursos de un solo nodo). Realmente es una sola BBDD, las modificaciones que se realizan por un usuario en una instancia son visibles inmediatamente por el resto de usuarios de otras instancias y en caso de querer un dato que ya esté en memoria en una instancia remota se pide ese bloque por red (que sigue siendo más rápido que acceder al disco).

Recovery: Es el proceso en el que aplicamos los cambios almacenados en los ficheros de “redo log archivado” o “redo log online” a los ficheros de datos que han  sido restaurados. Esto nos permite hacer “avanzar” los ficheros en el tiempo (aplicando los cambios realizados desde que se copiaron). Recuperar una BBDD consiste en el “restore” (restauración de los ficheros desde la copia) y el “recovery” (aplicar todos los cambios posibles/necesarios) en los ficheros para avanzar la BBDD hasta el punto en el tiempo que queramos.

Recovery Catalog: La BBDD almacena los datos de las copias de RMAN en los ficheros de control, esto presenta dos problemas, el primero y más obvio es que pasa si perdemos junto con el resto de BBDD los ficheros de control y el segundo es que estos ficheros van a incrementar mucho su tamaño en función del tiempo que queramos que “recuerden” todas las copias realizadas. Para solucionar esto se recomienda tener una BBDD separada en otro servidor en la que crearemos unas tablas especiales mediante comandos de RMAN. Estas tablas van a almacenar los detalles de las copias a largo plazo, de manera que en el fichero de control dejaremos solo los datos de los últimos días. Mediante comandos RMAN podemos realizar el mantenimiento del catálogo (registrar nuevas copias, eliminar los registros de las antiguas) y este catálogo también soluciona el problema de “perder” todos los ficheros de la BBDD (incluido el fichero de control).

Recovery Manager (RMAN): Es la herramienta usada para hacer copias/recuperaciones de Oracle en la gran mayoría de los casos, si bien también es posible hacer copias/recuperaciones mediante algunos comandos SQL y herramientas de sistema operativo o mediante snapshots de disco (poco recomendable). Y no, un export (exp/expdp) no es una copia. Permite almacenar los datos en formato backupset (agregando datos de diferentes ficheros y comprimiendo el espacio no usado), o en formato “datafilecopy” (imágenes exactas de los ficheros en disco), a la vez que se integra con programas de backup permitiendo enviar las copias directamente a cinta. Permite comprimir y cifrar las copias y mantener un catálogo de todas las copias realizadas. Esta misma herramienta será la que usaremos para realizar las recuperaciones de la BBDD, facilitando en gran medida esta tarea.  Además permite revisar las copias, simular recuperaciones, validar los ficheros y clonar las BBDD entre otras cosas. Viene incluido en los binarios de todas las BBDD.

Redo Log Files: La BBDD puede trabajar en dos modos “arhivelog” o “no archivelog”, en el primer modo le obligamos a guardar histórico de todos los cambios realizados, en el segundo los cambios ya confirmados (y que ya tenemos almacenados permanentemente en los ficheros de datos) no es necesario guardarlos y se descartan. Los cambios realizados se almacenan independientemente del modo en que estemos en unos ficheros llamados “online redo logs” o “redo log files”, de los que cada BBDD tiene un número determinado, si estamos en modo “no archivelog” los datos en estos ficheros se sobrescriben al cabo de un tiempo (son circulares, al llenarse el ultimo sobrescribe el primero), en modo “archivelog” se hace una copia del fichero (llamada “archived redo log” antes de que se sobrescriba). Al ser ficheros muy críticos para la BBDD se acostumbra a tener como mínimo dos copias idénticas de cada uno. Cada conjunto de copias idénticas forman un “grupo de redo log” y deberemos tener al menos dos grupos en cada BBDD (y recomendable algunos más).  El tamaño de los “redo log files” lo decidimos nosotros y puede variar de varias decenas de Mb a Gb en función de la cantidad de cambios que genere la BBDD por segundo.

Roles: En la BBDD cada usuario puede tener “permisos” para realizar ciertas cosas (crear o modificar objetos, acceder a tablas de otros esquemas,..). En muchas ocasiones queremos dar o quitar un grupo de permisos a una cantidad grande de usuarios, para facilitar esta tarea podemos crear roles, a los que asignaremos/quitaremos una serie de permisos y al dar el “rol” a un usuario este automáticamente recibe todos los permisos asociados al “rol”.

Rollback: Es el comando usado para “desahacer” los cambios que hayamos realizado en la transacción actual dejando todos los datos como estaban antes de empezar la transacción. En otras palabras es el contrario del “commit”. Notar que se hace “rollback” por defecto en caso de detectar un error o desconectar la sesión de forma abrupta.

Row Chaining: El encadenamiento de filas es un efecto que se produce al tener una fila tan grande que no cabe en un bloque y se tiene que repartir entre varios.  Es un problema de caras al rendimiento ya que cuando realizamos accesos por “full scan” a las tablas y encontramos una cadena encadenada tenemos que detener las lecturas “multibloque”, ir a buscar la fila díscola y seguir donde estábamos.

Row Migration: Ocurre cuando una fila que esta cómodamente en su bloque se actualiza añadiendo más datos a las columnas y deja de caber en ese bloque (al estar ya muy lleno), de manera que se tiene que “mover” a otro bloque con espacio libre. Es un problema ya que cuando realizamos accesos por “full scan” a las tablas y encontramos una cadena migrada tenemos que detener las lecturas “multibloque”, ir a buscar la fila díscola y seguir donde estábamos.

ROWID: Es una columna “virtual” que contiene la “matricula” o “puntero” de cada fila de la BBDD, en otras palabras cada fila tiene un ROWID diferente.  Usar el ROWID de una fina es la manera más rápida de acceder a ella. Ojo que no es un valor estático, si reorganizamos una tabla los ROWID de todas sus filas van a cambiar (ya que dependen de su ubicación física).

Rule Based Optimizer: En las versiones antiguas de la BBDD para decidir cómo ejecutar una sentencia (como y en qué orden acceder a los objetos) se usaba una serie de reglas predefinidas, al software que aplicaba estas reglas se le llamaba Rule Based Optimizer. Actualmente se ha sustituido por el Optimizador Basado en Costes (o en sus siglas inglesas CBO).

S

Sample schemas: En la BBDD antiguamente se cargaban una serie de esquemas “por defecto” en los que podíamos encontrar tablas para realizar nuestros primeros “pinitos” con SQL, el usuario SCOTT (con password “tigger”), las tablas EMP de empleados o DEP de departamentos… Actualmente estos esquemas se han sustituido por otros de más elaborados y si los queremos los tendremos que cargar por separado una vez creada la BBDD.

Savepoints: Al empezar a realizar cambios en una BBDD Oracle se crea una transacción, al final deberemos decidir si confirmar “commit” o descartar “rollback” nuestros cambios, pero y si quisiéramos descartar solo hasta un “cierto punto”? Para eso tenemos los “savepoints” (una funcionalidad muy poco usada) que permite crear puntos de control dentro de una transacción y “deshacer” solo hasta ese punto.

Schemas: A grandes trazos en Oracle vienen a ser lo mismo que un usuario, un esquema es un contenedor de objetos, pero para crear un esquema tenemos que crear su usuario correspondiente (existe el comando “CREATE SCHEMA” pero es para otros menesteres). Dentro del esquema/usuario tenemos sus tablas, vistas, índices, procedimientos….

SCN: Sequence Change Number, es un contador que se va incrementando en cada operación (interna o de usuario) que se realiza en la BBDD. Es muy importante y queda almacenado en múltiples sitios (ficheros de control, cabecera de ficheros, bloques de datos) para asegurar la consistencia de los datos de la propia BBDD.

Secure Files: Es la solución que ha aparecido en las últimas versiones de BBDD para almacenar contenido no estructurado (ficheros binarios o de texto) dentro de la BBDD. Permiten cifrar, comprimir, deduplicar entre otros y mejoran de manera importante el rendimiento de los campos de tipo BLOB y CLOB usados hasta la fecha a tal efecto.

Segments: Un segmento es un conjunto de bloques en uno o varios ficheros de datos que pertenecen al mismo objeto, por ejemplo una tabla o un índice son segmentos. Hay segmentos de uso “interno” sobre los que tenemos poco control (segmentos temporales o de undo) y otros que creamos nosotros (tablas, índices, vistas materializadas…).

Sequences: Vienen a ser las máquinas de turnos que podemos encontrar en algunas tiendas en versión Oracle. Al crear una secuencia debemos decidir el numero inicial, valor de incremento / decremento, el límite, si puede dar la vuelta (y algunas cosas más) y ya podemos empezar a “pedir números”. No es posible “devolver” números a una secuencia, es nuestra responsabilidad si no usamos los que cogemos (si bien podemos alterar o recrear la secuencia caso que sea necesario). Se usaba frecuentemente junto con un trigger “on insert” para generar campos de tipo “autoincremento” ya que en Oracle no existía el tipo de datos “autoincremento” hasta la llegada de la versión 12c.

Server Parameter File (SPFILE): Es la versión binaria del fichero de parámetros que lee la BBDD justo al arrancar. Esta versión “binaria” apareció con la versión 9i de la BBDD para sustituir el “init.ora” y empezó a permitir cambiar parámetros de configuración de manera “dinámica”, esto es, sin tener que reiniciar la BBDD.

Services: Para conectar a una BBDD normalmente usamos una IP, un puerto y un “SID” (System Identifier), pero en lugar del SID posiblemente deberíamos usar un “servicio” (en especial a partir de 10g). Los servicios se crean, eliminan, arrancan y paran mediante el paquete DMB_SERVICES y nos permiten crear diferentes “puertas de entrada” a la BBDD. Cada usuario que entre mediante un servicio queda “etiquetado” de manera que podemos aplicar restricciones, recoger estadísticas o incluso denegar la entrada filtrando por servicio. Un pequeño ejemplo, en una BBDD tenemos una aplicación de nóminas y otra de facturación y cada una se conecta a un servicio específico. Tenemos que hacer mantenimiento de la aplicación de nóminas, por lo que detenemos el servicio de nóminas (ya no entraran más usuarios de nóminas), echamos (con un solo comando) a todos los que hayan entrado mediante el servicio de nóminas y empezar con el mantenimiento de la aplicación… todo sin afectar para nada a los usuarios de facturación, al terminar lo activamos de nuevo ese servicio y listos.

Sessions: Una sesión es una conexión de un programa cliente a una BBDD Oracle, dentro de una sesión podemos ir ejecutando transacciones y en un momento determinado podemos tener varias en marcha. Existe un parámetro de inicialización que indica el número máximo de sesiones en la BBDD de manera concurrente, para definir este número deberemos tener en cuenta el máximo de usuarios que vamos a tener más un cierto porcentaje ya que los procesos internos de Oracle también consumen sesiones.

SGA: La System Global Area es una de las zonas de memoria más importantes en las instancias de BBDD Oracle y juntamente con la PGA acostumbran a ser la de mayor tamaño. Su principal característica es que todos los procesos de Oracle tanto internos como de usuario tienen acceso a ella (es compartida). Dentro de ella encontramos los bloques de disco cacheados (buffer cache), la zona en que se almacena el redo antes de ser escrito a los redo logs (redo buffer), la zona en que se cachean los datos de estructura de la BBDD y las últimas sentencias ejecutadas junto con sus planes de ejecución (shared pool) entre muchas otras cosas. En versiones antiguas de Oracle era necesario dar un tamaño estático a cada una de esas zonas, actualmente podemos dejar que Oracle decida y modifique los tamaños dentro de unos límites que nosotros marcamos adaptándose en cada momento a las necesidades de carga del gestor.

Shared Pool: Esta zona de memoria compartida (que forma parte de la SGA) “cachea” datos de la estructura de los objetos de la BBDD y sus propiedades (que tablas hay, que permisos tiene, que índices, etc.) de manera que sea rápido acceder a estos datos cuando queramos decidir cómo ejecutar una sentencia. También almacena las sentencias y planes de ejecución ya calculados (como mínimo de las ultimas ejecutadas) para su posible reaprovechamiento. Es una de las zonas de memoria que más conflictos daba en el pasado cuando se tenía que decidir su tamaño de antemano (una búsqueda del error “ORA-04031” os dará una idea de la magnitud de la tragedia). En las últimas versiones la gestión automática de memoria ha hecho disminuir mucho (que no desaparecer) estos errores, que todo sea dicho en muchos casos son causados por mala praxis al usar la BBDD (por ejemplo al no usar “bin variables” en las selects).

Shutdown: Es el comando usado para parar la BBDD, hay varios “sabores”, por ejemplo “shutdown” o “shutdown normal” sirve para quedarnos esperando una hora hasta que se cancela por “timeout” sin parar la BBDD.  Bromas aparte, este comando espera a que todos los usuarios se desconecten antes de parar la BBDD lo que es casi una utopía. Otro seria el “shutdown transactional” que espera que se acaben todas las transacciones (y no deja empezar de nuevas) el problema es el usuario que no ha confirmado unos cambios antes de irse a casa… os he dicho que el “timeout” del shutdown es de una hora no? Otro más serio seria el “shutdown immediate” (el que se usa normalmente), con este se cancelan las transacciones en marcha y se hace rollback de ellas (se siente por quien no haya guardado sus cambios) se echa a todos los usuarios y se para la BBDD. El “immediate” funciona en la mayoría de casos, pero en los que no (por la razón que sea algún proceso se niega a morir) tenemos el “shutdown abort” que es lo más parecido a matar directamente y desde sistema operativo el ejecutable de Oracle (o alguno de sus procesos background “críticos). Este último no cierra correctamente la BBDD que va a necesitar recovery en el siguiente arranque, solo lo deberíamos usar como último recurso (y dicho sea de paso mejor un “abort”  que apagada eléctrica del servidor).

SQL: Es el lenguaje usado para gestionar datos en BBDD relacionales como por ejemplo Oracle. Es un lenguaje de tipo “4GL”, o en otras palabras con un alto nivel de abstracción en que nosotros indicamos “que queremos” no “como se tienen que hacer”. Un ejemplo seria ejecutar la sentencia “SELECT * FROM EMP WHERE NAME=’SCOTT'”, donde estaríamos pidiendo a la BBDD que nos retorne todos los registro de la tabla EMP en que el campo nombre sea “SCOTT”, no le indicamos si tiene que acceder por índice o “full scan” ni con que método filtrar los datos.

SQL*Loader: Es una herramienta usada para cargar datos en las BBDD Oracle, viene con todos los binarios de BBDD. Permite cargar ficheros de formato texto, lo hace mediante un fichero de control en el que definimos el formato del fichero a cargar (longitud fija o campos separados por algún tipo de carácter) así como otras condiciones (si queremos cargar todos los registros o filtrar algunos, que hacer si detectamos errores etc). Está muy optimizado (usa cargas directas “saltándose” la cache) y permite cargar datos mucho más rápido que mediante otras opciones (mediante programación o inserts de SQL por ejemplo).

SQL*Plus: Es una herramienta de línea de comandos (que quiere ser sustituida en un futuro por otra llamada SQLC mas versátil) en la que podemos ejecutar comandos SQL para administrar y consultar los datos así como para gestionar la propia BBDD. Viene por defecto con todos los binarios de BBDD y es la herramienta principal de muchos administradores para ejecutar scripts en los gestores de BBDD.

Standard Edition: Es la versión de entrada de la BBDD Oracle, a nivel de licencias es mucho más asequible, tanto por el precio de cada licencia como por que se licencia por “sockets” y no por cores. Por contrapartida tiene varias limitaciones, con una BBDD Standard Edition no podemos usar ninguna de las funcionalidades avanzadas (paralelismo, Multitenant con más de una PBD) ni ninguno de los packs opcionales (Particionado, Diagnostics, Tunning). A partir de la versión 12c no permite más de 16 tareas concurrentes ni se puede instalar sobre más de 2 “sockets” (esto es un solo servidor con dos “sockets” o en modo RAC dos servidores de un solo “socket”).

Startup: Es el comando usado para arrancar la instancia (y nos permite acceder a la BBDD). Este comando ejecutado mediante SQL*Plus, RMAN (o algún otro ejecutable) inicia los procesos de background y las zonas de memoria que conforman la instancia. Existe una opción “FORCE” que nos permite arrancar la BBDD sin fichero de parámetros (usando valores mínimos de estos) en operaciones de recover con RMAN.

Statistics: En la BBDD Oracle se pasan estadísticas a los objetos que conforman la BBDD para poder decidir de la manera más acertada posible los planes de ejecución (siempre y cuando usemos optimizador basado en costes “CBO”). Podemos lanzar las estadísticas manualmente o dejar que lo haga la propia BBDD como parte de sus tareas de optimización nocturnas y de fin de semana.

Synonyms: Los sinónimos son “alias” o “links” a objetos, los podemos crear para tener accesos más cortos o fáciles de recordar a objetos locales (de nuestro esquema) o remotos (de otros esquemas o BBDD si usamos DBLINKS).

SYSTEM Tablespace: Es un tablespace que tendremos obligatoriamente en todas las BBDD, en el se encuentran todas las tablas internas de gestión de la BBDD. No lo debemos usar para almacenar nuestros datos dejando su uso en exclusiva a la propia BBDD.

SYS, SYSTEM Users: Son dos usuarios que tendremos obligatoriamente en todas las BBDD, el usuario SYS es superadministrador que tiene permisos para arrancar y parar la BBDD, además es el esquema en el que residen las tablas internas de la BBDD (ubicadas en el tablespace SYSTEM). El usuario SYSTEM tiene algo menos de permisos que SYS (no puede arrancar/parar la BBDD por ejemplo) y es el usuario usado normalmente para gestionar la BBDD.

T

Table: Las tablas son un conjunto de datos estructurados, están formadas por una serie de columnas (que pueden ser de varios tipos) y filas (en caso que contenga datos). En Oracle podemos tener múltiples tablas en cada esquema y los nombres de tabla se pueden repetir en diferentes esquemas ( de manera que SCOTT.EMP y MARY.EMP serian dos tablas diferentes).

Tablespace: Vendría a ser un “contenedor” dentro del que crearemos tablas, índices y otros tipos de objetos. Es una estructura lógica, ya que realmente está formado por uno o más ficheros de datos y nos permite ver la suma del espacio de los ficheros como una unidad. Sirven para tener los datos relacionados agrupados y poderlos tratar como una unidad (por ejemplo un tablespace para cada usuario, aplicación, o tipo de datos).

Tablespace Point in Time Recovery: Consiste en recuperar un tablespace en un momento del tiempo diferente al del resto de la BBDD. Por ejemplo si se han producido cambios en unos ciertos datos y debemos recuperar la versión antigua, pero el resto de aplicaciones de la BBDD no se pueden modificar podemos hacer “Point In Time Recovery” del tablespace que contiene los datos afectados (por lo que es buena idea tener los datos de diferentes aplicaciones separados en diferentes tablespaces).

Transactions: Una transacción es un conjunto de operaciones que realizamos en la BBDD que tratamos como una unidad y que queremos que se realicen todas a la vez o ninguna. Si tenemos una conexión abierta y ejecutamos alguna operación que conlleve cambios en la BBDD acabamos de iniciar una transacción que deberemos finalizar con un “commit” o un “rollback” (de manera voluntaria o involuntaria siempre haremos  lo uno o lo otro, por ejemplo salir de un SQL*Plus con “exit” implica que hacemos “commit”).

Triggers: Los triggers o disparadores son piezas de código que se ejecutan cuando se da cierta condición. Podemos crear triggers que se ejecuten al realizar un insert, al actualizar un campo de una tabla, al conectar un usuario, al iniciar la BBDD. El código que ejecuta el trigger lo definimos nosotros y si se da el caso el código se ejecuta en la misma “transacción” que lo ha originado. Por ejemplo un trigger “on insert” que tenga un código que provoque un fallo evitará también que se haga el insert. El uso de triggers debe hacerse con cautela ya que pueden acabar provocando problemas de rendimiento y/o funcionamiento si no se usan correctamente. Si tenéis pensado usarlos para temas de auditoria os recomiendo que reviséis las funcionalidades de auditoria del propio Oracle, que igual os solucionan el requerimiento con un impacto mucho menor.

U

Undo Tablespace: Automatic Undo Management: Tras esperar varias horas a que termine nuestra select/update/delete nos aparece el error “ORA-15555 snapshot too old”, esta era una situación común en versiones antiguas de la BBDD en que los segmentos de UNDO (anteriormente llamados ROLLBACK) se tenían que gestionar a mano. En las versiones más modernas la gestión (tamaño y cantidad) de estos segmentos se realiza de manera automática y este error es mucho menos frecuente.  El tablespace de undo y los segmentos de undo que hay en su interior almacenan la información necesaria para deshacer nuestros cambios, o para dar una visión consistente a los datos que accedemos (y que otros están cambiando). Es un tablespace que vamos a encontrar casi obligatoriamente en todas las BBDD (junto al SYSTEM).

Users: En oracle un usuario viene a ser un login con su correspondiente password (si autenticamos mediante BBDD). A los usuarios les podemos dar permisos y en función de estos podrá realizar diferentes tareas en la BBDD y crear/modificar/borrar objetos y datos. En el momento que creemos algún objeto de su propiedad además de ser un usuario pasaran a ser “esquemas”.

V

Views: Una vista es en el fondo una “select” que guardamos y a la que ponemos un nombre. Nos permite crear subconjuntos de columnas o filas de una tabla (seleccionando solo unas columnas o usando filtros en el WHERE), ver datos de varias tablas unidas o agrupadas, o formatear los datos de una tabla. Realmente cada vez que accedemos a la select estamos ejecutando la sentencia que la define (los datos no se almacenan como en las vistas materializadas). Es posible hacer inserts/updates/deletes a traves de vistas si son suficientemente simples (por ejemplo en una vista en que tenemos agregados no se podría).

Virtual Columns: En las últimas versiones de BBDD es posible crear columnas virtuales en las tablas, estas columnas realmente no ocupan espacio ya que se calculan al vuelo al acceder a ellas mediante la función que las define.

V$, GV$ views: Oracle nos proporciona multitud de datos de las instancias con estas vistas. Nos indican el nombre de la instancia, usuarios conectados, bloqueos activos, sentencias SQL ejecutadas, información estadística… son las llamadas “vistas dinámicas” o “fixed views”. Son básicas para controlar el estado y funcionamiento de la instancia. Estas vistas existen solo en memoria y al cerrar la instancia toda la información que contienen se elimina. Los nombres de todas ellas empiezan por V$ para vistas con información de la instancia local y GV$ (global views) para las que dan información de todas las instancias (en caso de RAC).

  1. DBosch
    mayo 10, 2018 en 11:34

    Muy completo y entendedor. Gran trabajo. Felicidades.

    • Rafael Planella
      mayo 10, 2018 en 18:46

      Muchas gracias!

  1. No trackbacks yet.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

w

Conectando a %s

A %d blogueros les gusta esto: