29 noviembre 2017

Oracle 12C, ¿Que es Multitenant?

Introducción a las bases de datos de contenedores (CDB) y bases de datos conectables (PDB)

Este artículo se va a centrar en repasar los conceptos básicos de as novedades que Oracle 12c ha introducido desde su liberación de la release 1. Oracle 12c R1 (12.1) introdujo la opción Multitenant. Este artículo proporciona una descripción general básica de la opción multiusuario, con enlaces a otros artículos más detallados sobre dicha funcionalidad, que serán elaborados más adelante.

Introducción

La opción Multitenant representa uno de los mayores cambios arquitectónicos en la historia de la base de datos Oracle. Con esta novedad se  presentaron los conceptos de la base de datos de contenedores (CDB) y la base de datos conectable (PDB).

¿Que entendemos por CDB?

CDB  es el acrónimo de Base de Datos de Contenedores, en apariencia esto parece muy similar a una base de datos Oracle convencional, ya que contiene la mayoría de las partes funcionales con las que ya estará familiarizado (archivos de control, archivos de datos, deshacer, archivos temporales, registros de rehacer, etc.) esto es:
  • Controlfiles
  • Datafiles
  • Undo files
  • Tempfiles

También alberga el diccionario de datos para aquellos objetos que son propiedad del contenedor raíz y aquellos que son visibles para todos los PDB.

¿Que entendemos por CDB?


PDB es el acrónimo de Base de datos conectable, dado que el CDB contiene la mayoría de las partes que funcionan para la base de datos, el PDB solo necesita contener información específica para sí misma. No necesita preocuparse por los archivos de control, rehacer registros y deshacer, etc. En su lugar, está compuesto de archivos de datos y archivos temporales para manejar sus propios objetos. Esto incluye su propio diccionario de datos, que contiene información sobre solo aquellos objetos que son específicos del PDB. Desde Oracle 12.2 en adelante, un PDB debería, tener un tablespace undo local.

Esta división del diccionario de datos entre objetos comunes, en el contenedor raíz, y objetos específicos de PDB, en el diccionario de datos del PDB, es muy importante, porque esta separación es lo que le da a la opción multiusuario su flexibilidad. Desde la perspectiva del PDB, el diccionario de datos es la unión de los diccionarios de datos raíz y PDB, por lo que internamente el PDB se parece mucho a una base de datos Oracle normal. Por ejemplo, las vistas DBA_% y ALL_% dentro del PDB aparecen igual que cualquier base de datos que no sea CDB.

Oracle Managed Files (OMF) y Multitenant

Oracle recomienda el uso de Oracle Managed Files (OMF) cuando se usa la arquitectura Multitenant, ya que simplifica varias funciones. Parece que el uso de OMF es obligatorio para algunas funcionalidades, como la funcionalidad de Contenedores de aplicaciones en Oracle 12.2.

Creación de bases de datos conectables (PDB)

Dado que la mayor parte de las piezas de trabajo ya están presentes en el contenedor raíz, la creación de un nuevo PDB es una tarea comparativamente rápida y sencilla. Al crear un PDP completamente nuevo, el PDB se crea como una copia de un PDB inicial, por lo que solo toma el tiempo que los archivos tarden en copiarse.

Creación

En lugar de crear un nuevo PDB desde la semilla, puede clonar desde un PDB ya existente.

Clonación
También es posible crear clones en un CDB remoto.

Clonación remota


Esto no solo permite que las bases de datos se muevan fácilmente, sino que también proporciona una forma alternativa de parchear y actualizar a versiones futuras. Aquí puede encontrar un ejemplo del uso de desenchufar / complemento para realizar un parche. Aquí se describe una discusión general del mecanismo de desconexión / complemento.
La conversión de una base de datos que no es de CDB a una base de datos conectable implica obtener una descripción de la base de datos que no es de CDB y usarla para conectarla a un CDB como un nuevo PDB. Este método se describe aquí.

Reubicar una base de datos conectable (PDB)

Desde Oracle 12.2 en adelante, es posible reubicar un AP, moviéndolo de un CDB a otro. Esto es significativamente más simple que hacer un unplug / plugin convencional.


Actualizar una base de datos conectable (PDB)

Desde Oracle 12.2 en adelante, es posible actualizar un PDB clonado desde el PDB de origen, siempre que solo se haya abierto en modo de solo lectura.



Base de datos proxy conectable (PDB)

Desde Oracle 12.2 en adelante, es posible crear un servidor proxy PDB, que es un esqueleto PDB que envía SQL a un PDB remoto para ser procesado. Esto le permite tener un punto final local para una base de datos remota.


Contenedores de aplicaciones

Oracle 12.2 presenta el concepto de contenedores de aplicaciones, que actúan como un contenedor mini-raíz. Se pueden usar para centralizar la configuración y las aplicaciones compartidas, que son utilizadas por sus PDB de aplicaciones dependientes.


Novedades en las vistas del diccionario de datos

La introducción de la opción multiusuario trae consigo una capa adicional de vistas de diccionario de datos, lo que permite generar informes a través del contenedor raíz y las bases de datos conectables (PDB). Ignorando las ediciones por el momento, las versiones anteriores tenían la siguiente jerarquía.

DBA_: todos los objetos en la base de datos.
|
--ALL_: Objetos accesibles para el usuario actual, incluidos los que posee el usuario actual.
  |
  --USER_: objetos propiedad del usuario actual.


Con Oracle 12c, se agrega una capa adicional a la jerarquía.

CDB_: todos los objetos en todos los contenedores * (root y todos los PDB).
|
--DBA_: todos los objetos en el contenedor actual (root o PDB).
  |
  --ALL_: objetos accesibles por el usuario actual en el contenedor actual (root o PDB), incluidos los que posee el usuario actual.
    |
    --USER_: objetos propiedad del usuario actual en el contenedor actual (root o PDB).


El resultado de las vistas CDB_ depende del contenedor desde el que se accede. Cuando se accede desde el contenedor raíz, de hecho presentan toda la información de todos los contenedores. Cuando se accede desde un AP, actúan efectivamente como las vistas DBA desde dentro del contenedor. Esto puede ser un poco confuso al principio.


27 noviembre 2017

Mejoras de auditoría (DBMS_AUDIT_MGMT) en Oracle Database 12c

La introducción de políticas de auditoría y la pista de auditoría unificada son las dos novedades, que aparecen en esta entrega de nuestra base de datos favorita. Que simplifican la configuración de la auditoría de bases de datos en Oracle 12c.  La nueva funcionalidad de auditoría también se puede usar para crear políticas de auditoría de muy sencillas a muy complicadas, pero no creo que sea la forma en que la mayoría de la gente querrá abordarla,  Una vez que hayas aprendido a andar, puedes empezar a correr y complicar tus políticas de auditoria, eso sí, bajo tu responsabilidad.

Si quieres saber más en profundidad acerca de la auditoria unificada en Oracle 12c, te recomiendo que sigas lo artículos de Joel Perez, Aman Sharma, Karan Dodwal y Sebastián D'Alessandro, en la technetwork de Oracle:

  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte I
  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte II
  • Oracle Database 12c: "Auditoria en 12c: Auditoría Unificada Parte III

Creando Políticas de Auditoría

Al igual que la auditoría estándar anterior, que mencionamos en mi anterior artículo, la auditoría unificada se puede utilizar para crear reglas de auditoría extremadamente complejas. Como la documentación de Oracle para administrar las políticas de auditoría es muy buena, en lugar de tratar repetirla aquí, solo mostraré algunos ejemplos sencillos para despertar la curiosidad del lector.

Es mejor crear una política de auditoría que contenga todas las auditorías necesarias para una sesión, en lugar de usar varias políticas pequeñas. El uso de múltiples políticas genera una mayor sobrecarga de inicio de sesión, un mayor consumo de UGA y una funcionalidad de verificación de auditoría interna menos eficiente.


Una política de auditoría se compone de varias cláusulas distintas, algunas de las cuales son opcionales.

Los ejemplos de los usos se dan en las secciones a continuación, pero aquí hay un resumen rápido de ellos.


  • privilege_audit_clause: se usa para especificar una lista de privilegios del sistema para auditar.
  • action_audit_clause: define las acciones que necesitan ser auditadas. Estas pueden ser standard_actions, como DELETE, o específicas del objeto, como DELETE ON schema.table. También pueden ser componentes_actividades que se dirigen a funciones específicas como Data Pump o SQL * Loader.
  • role_audit_clause: especifica una lista de roles. Todos los privilegios del sistema otorgados a través de esos roles son auditados.
  • When ... Evaluate per: permite definir una condición de auditoría para determinar cuándo se realizará esta. La condición se puede evaluar para cada sentencia SQL, sesión en a base de datos o instancia de base de datos, según el nivel de granularidad que requiera la condición.
  • CONTAINER: determina si una política de auditoría es específica para un PDB individual (CURRENT) o común a todos los AP (ALL).
Esto puede sonar un poco confuso, pero si alguna vez ha utilizado la auditoría de bases de datos en versiones anteriores, rápidamente se verá bastante familiar. Lo más importante que debe recordar es que en lugar de emitir los comandos AUDIT / NOAUDIT directamente, usted crea una política de auditoría que contiene las piezas relevantes, luego la habilita y deshabilita usando los comandos AUDIT / NOAUDIT.

Algunos de los siguientes ejemplos requieren estos tres usuarios de prueba.


En algunos casos, el contenido de la pista de auditoría unificada se ha purgado entre las pruebas para mantener el resultado simple y específico para la funcionalidad que se prueba.

Auditoría de privilegios


Como su nombre lo indica, la auditoría de privilegios le permite auditar el uso de los privilegios del sistema. La vista SYSTEM_PRIVILEGE_MAP identifica los privilegios del sistema que se pueden auditar.





Si queremos auditar la creación de tablas y secuencias por parte del usuario de ARTOS, podríamos hacer algo como lo siguiente.














Muestra la configuración de la política.










Conéctese con el usuario de ARTOS y cree algunos objetos.









Verifique la pista de auditoría. Si está en modo de escritura diferida (delayed-write), es posible que necesite vaciar la pista de auditoría antes de poder ver los registros de auditoría.

Deshabilitar la política y eliminarla.







Componente de Auditoría de Acciones

En lugar de auditar acciones en objetos específicos, en su lugar puede auditar acciones relevantes para funcionalidades o utilidades específicas, tales como Oracle Label Security (OLS), Real Application Security, Database Vault, Data Pump o SQL * Loader. Hay dos ejemplos de auditoría de componente_acción vinculados a continuación.

  • Auditoría de Operaciones de Data Pump
  • Auditoría de las cargas de ruta directa de SQL * Loader


Administración Unificada de la Pista de Auditoría

La administración de la auditoría unificada puede parecer un poco complicada al principio, pero hay algunas cosas que se deben tener en cuenta.

  • La auditoría unificada funciona de manera predeterminada, por lo que no necesita hacer nada para comenzar.
  • La configuración predeterminada es correcta. Probablemente solo deba centrarse en sus políticas de auditoría específicas.
  • Configurar un proceso de archivado y depuración necesitará algo de reflexión, pero probablemente solo lo haga una vez en la vida de su base de datos, así que no se asuste por este aspecto de la auditoría.

En los artículos referenciados más arriba encontrareis información en profundidad acerca de esta materia. 

Seguridad de las pistas de auditoria

El mantenimiento del seguimiento de auditoría y las políticas de auditoría se limita a aquellos usuarios a los que se les haya otorgado el rol AUDIT_ADMIN.

La función AUDIT_VIEWER se puede otorgar a los usuarios que necesitan ver la información de auditoría, pero no administrar el seguimiento de auditoría o las políticas de auditoría.


Bajo la auditoría unificada, los usuarios ya no pueden crear políticas de auditoría contra sus propios objetos. Para la compatibilidad con versiones anteriores, esto aún es posible para la auditoría tradicional. Esta es posiblemente una razón para alejarse de la auditoría en modo mixto.


Actualizaciones en 12.2


Una de las principales críticas de la auditoría unificada en 12.1 fue el rendimiento. En 12.2, la pista de auditoría unificada ahora reside en una tabla convencional llamada AUDSYS.AUD_$_UNIFIED. Cuando actualiza una base de datos, puede optar por migrar la información de auditoría existente a esta tabla utilizando TRANSFER_UNIDED_RECORDS en el DBMS_AUDIT_MGMT, que debería proporcionar un mejor rendimiento.

26 noviembre 2017

Mejoras de auditoría (DBMS_AUDIT_MGMT) en Oracle Database 11g Release 2

Oracle, para la release 11g R1 activó la auditoría por defecto por primera vez. Oracle 11g Release 2 ahora permite una mejor administración de la pista de auditoría utilizando el paquete DBMS_AUDIT_MGMT.

Mover la pista de auditoría de base de datos a un espacio de tabla diferente

El procedimiento SET_AUDIT_TRAIL_LOCATION te permite modificar la ubicación de la pista de auditoría de base de datos (normal / detallada). Aunque no permite la alteración de la pista de auditoría del sistema operativo,  la documentación sugiere que esto puede suceder en el futuro. 
Este procedimiento acepta dos parámetros.

  • AUDIT_TRAIL_TYPE: tipo de pista de auditoría que se va a mover.
  • AUDIT_TRAIL_LOCATION_VALUE: el espacio de tabla al que deben moverse las tablas de seguimiento de auditoría.

El parámetro AUDIT_TRAIL_TYPE se especifica utilizando una de estas constantes.

  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: pista de auditoría estándar (AUD $).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: pista de auditoría detallada (FGA_LOG $).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: pistas de auditoría estándar y de grano fino.


Primero vemos la ubicación actual de las tablas de seguimiento de auditoría.

A continuación, creamos un nuevo tablespace para contener el seguimiento de auditoría.
Luego movemos la pista de auditoría estándar al nuevo espacio de tabla.
A continuación, movemos la pista de auditoría detallada.

Controlar el tamaño y la antigüedad de la pista de auditoría del sistema operativo

El procedimiento SET_AUDIT_TRAIL_PROPERTY le permite establecer el tamaño máximo y / o la edad de los archivos del registro de auditoría del sistema operativo. El procedimiento puede establecer parámetros para varios propósitos, pero restringiré la discusión solo a aquellos relevantes para esta sección. Se puede encontrar una lista completa de las constantes disponibles aquí.

El procedimiento acepta tres parámetros.
  • AUDIT_TRAIL_TYPE: el tipo de pista de auditoría a modificar (AUDIT_TRAIL_OS, AUDIT_TRAIL_XML o AUDIT_TRAIL_FILES).
  • AUDIT_TRAIL_PROPERTY: el nombre de la propiedad que se establecerá (OS_FILE_MAX_SIZE o OS_FILE_MAX_AGE).
  • AUDIT_TRAIL_PROPERTY_VALUE: el valor requerido para la propiedad.
Para verificar la configuración actual, consulte la vista DBA_AUDIT_MGMT_CONFIG_PARAMS.

Para estableder  el tamaño máximo de los archivos de auditoría del sistema operativo en 15,000 Kb, ejecuta el siguiente script:
Para establecer la edad máxima de los archivos de auditoría XML en 30 días, ejecuta el siguiente script.
El procedimiento CLEAR_AUDIT_TRAIL_PROPERTY se puede utilizar para eliminar las restricciones de tamaño y edad o restablecerlas a los valores predeterminados. Establecer el valor del parámetro USE_DEFAULT_VALUES en FALSE elimina las restricciones, mientras que establecerlo en TRUE devuelve la restricción al valor predeterminado.

Purga de registros de seguimiento de auditoría

Al igual que en versiones anteriores, puede eliminar manualmente registros de las tablas AUD $ y FGA_LOG $ y eliminar manualmente los archivos de auditoría del sistema de archivos, pero el paquete DBMS_AUDIT_MGMT le brinda algunos mecanismos nuevos y más seguros para mantener la pista de auditoría.

Inicializando la infraestructura de gestión

Para poder purgar la pista de auditoría de la base de datos, se debe realizar una inicialización única de la infraestructura de administración de auditoría. Esto se hace usando el procedimiento INIT_CLEANUP. El procedimiento acepta dos parámetros.
  • AUDIT_TRAIL_TYPE: la pista de auditoría a inicializar (constantes).
  • DEFAULT_CLEANUP_INTERVAL: El intervalo predeterminado en horas, después del cual el procedimiento de limpieza se debe volver a llamar (1-999).

El siguiente script SQL verifica la configuración de parámetros actual, inicializa la infraestructura de administración de auditoría para todas las pistas de auditoría con un intervalo predeterminado de 12 horas y vuelve a verificar la configuración.
Observa que el 'DB AUDIT TABLESPACE' para las pistas de auditoría de la base de datos no ha cambiado y que se ha establecido el 'INTERVALO DE LIMPIEZA POR DEFECTO' para las cuatro pistas de auditoría. El estado de inicialización actual de una pista de auditoría específica se puede verificar utilizando IS_CLEANUP_INITIALIZED.

Para desconfigurar la infraestructura de gestión de auditoría, ejecute el procedimiento DEINIT_CLEANUP.

Gestión de marca de tiempo

Lo siguiente a considerar antes de purgar la pista de auditoría es la cantidad de datos que desea depurar. El paquete DBMS_AUDIT_MGMT nos permite purgar todos los registros, o todos los registros anteriores a una marca de tiempo específica. La marca de tiempo en cuestión se especifica individualmente para cada pista de auditoría utilizando el procedimiento SET_LAST_ARCHIVE_TIMESTAMP, que acepta tres parámetros.
  • AUDIT_TRAIL_TYPE: el seguimiento de auditoría cuya marca de tiempo debe establecerse (constantes). Solo son válidos los registros de auditoría individuales, no las constantes que especifican los múltiplos.
  • LAST_ARCHIVE_TIME: se borrarán los registros o archivos anteriores a esta hora.
  • RAC_INSTANCE_NUMBER: opcionalmente especifique el nodo RAC para las pistas de auditoría del sistema operativo. Si no está configurado, asume la instancia actual.

Purga manual

El procedimiento CLEAN_AUDIT_TRAIL es el mecanismo básico para purgar manualmente el seguimiento de auditoría. Acepta dos parámetros.
  • AUDIT_TRAIL_TYPE: la pista de auditoría a purgar (constantes).
  • USE_LAST_ARCH_TIMESTAMP: establézcalo en FALSE para purgar todos los registros / archivos, o TRUE solo purgue los registros / archivos anteriores a la marca de tiempo especificada para la pista de auditoría.

Purga automatizada

El procedimiento CREATE_PURGE_JOB le permite programar un trabajo para llamar al procedimiento CLEAN_AUDIT_TRAIL. Al crear un trabajo de purga, puede especificar 4 parámetros.
  • AUDIT_TRAIL_TYPE: la pista de auditoría a purgar por el trabajo programado (constantes).
  • AUDIT_TRAIL_PURGE_INTERVAL: intervalo en horas entre purgas.
  • AUDIT_TRAIL_PURGE_NAME: un nombre para el trabajo de depuración.
  • USE_LAST_ARCH_TIMESTAMP: establézcalo en FALSE para purgar todos los registros / archivos, o TRUE solo purgue los registros / archivos anteriores a la marca de tiempo especificada para la pista de auditoría.



.




24 noviembre 2017

Monitorización de índices en base de datos Oracle: El mal necesario


Para aquellos que no están familiarizados con él, monitorizar índices es la forma de la base de datos Oracle de rastrear si se está usando un índice, lo que le permite saber si es necesario o no. O sea, como vengo a decir normalmete si "el índice se ha ido a Parla"

Dos cosas para tener en cuenta:
  • No siempre marca un índice como se usa, incluso si se usa. Si no se utiliza en un plan de ejecución, pero se utiliza para aplicar una clave externa o una restricción única, no se marcará como se usa.
  • La vista utilizada para ver el uso del índice es específica del esquema. Es posible que esté supervisando índices, pero los índices no se mostrarán en v$object_usage a menos que inicie sesión como propietario del esquema. Es mejor ir directamente a la consulta subyacente para ver todos los índices supervisados (consultar más abajo).
Dado que la monitorización de un índice tiene un costo muy bajo, tiene sentido activarlo para todos los índices candidatos. Los índices de FK e índices únicos funcionan, incluso si no se utilizan en los planes de ejecución, por lo que no son candidatos para descartar. Aquí está la consulta para obtener todos los índices non-unique, non-FK, se asume que no hay PK concatenadas, (Por Tutatis!) si eso ocurre, la consulta se vuelve más complicada:

SELECT 'ALTER INDEX '||ic.index_name||' MONITORING USAGE;'
  FROM all_ind_columns ic, all_indexes i
 WHERE i.uniqueness = 'NONUNIQUE' --no monitoriza índices únicos
   AND i.table_owner = 'NOMBRE_ESQUEMA'
   AND ic.index_owner = i.owner
   AND ic.index_name = i.index_name
   AND ic.position = 1
   AND NOT EXISTS (SELECT 'x' --No monitoriza índices en FK 
                     FROM all_cons_columns cc, all_constraints c
                    WHERE ic.table_name = cc.table_name
                      AND ic.column_name = cc.column_name
                      AND c.constraint_name = cc.constraint_name
                      AND c.constraint_type IN ('R'));

Aquí está la consulta para ver los objetos monitoreados si no se ha iniciado sesión como propietario del esquema:

select d.username, io.name, t.name,
       decode(bitand(i.flags, 65536), 0, 'NO', 'YES'),
       decode(bitand(ou.flags, 1), 0, 'NO', 'YES'),
       ou.start_monitoring,
       ou.end_monitoring 
from sys.obj$ io, sys.obj$ t, sys.ind$ i, sys.object_usage ou,
     dba_users d
where io.owner# = d.user_id
  AND d.username = 'SCHEMA_OWNER_HERE'
  and i.obj# = ou.obj#
  and io.obj# = ou.obj#
  and t.obj# = i.bo#;



Y aquí hay un ejemplo de monitorización de índice en acción, incluido el uso del índice exclusivo que no se marca:

CREATE TABLE test_monitoring AS SELECT level id, dbms_random.value(1,1000) value FROM dual CONNECT BY LEVEL <= 5000;

Table created.

CREATE UNIQUE INDEX test_monitoring_idx ON test_monitoring(id);

Index created.

ALTER INDEX test_monitoring_idx MONITORING USAGE;

Index altered.

Forzamos el índice para la aplicación de PK, este no marca el índice como usado:

INSERT INTO test_monitoring VALUES (100,0);
INSERT INTO test_monitoring VALUES (100,0)
*
ERROR at line 1:
ORA-00001: unique constraint (RAFA.TEST_MONITORING_IDX) violated 

SELECT index_name, used FROM v$object_usage WHERE index_name = UPPER('test_monitoring_idx');

INDEX_NAME                     USE                                              
------------------------------ ---                                              
TEST_MONITORING_IDX            NO                                               

Pero ejecutamos una sentencia "Select" que usará el índice

SELECT * FROM test_monitoring WHERE id = 100;

        ID      VALUE                                                           
---------- ----------                                                           
       100   255.5571                                                           
Y ahora el índice aparece como usado:

SELECT index_name, used FROM v$object_usage WHERE index_name = 'TEST_MONITORING_IDX';

INDEX_NAME                     USE                                              
------------------------------ ---                                              

TEST_MONITORING_IDX            YES 

Tener índices sin usar en la base de datos puede quitarnos espacio necesario y reducir el rendimiento en las sentencias  de borrado o actualización, por eso es importante eliminar aquellos que no son utilizados.



Dimensionamiento de la base de datos.

Toca crear una base de datos para un nuevo proyecto y llegan las ¡Vaya preguntas!  como por ejemplo: ¿Cuánto disco necesito para mi nueva base de datos Oracle? Suponemos que nuestra instalación no tiene ASM instalado, de ser esto cierto, no necesitas seguir leyendo mas este artículo, bueno tendrás que leer algo si quieres tener en cuenta los demás componentes de tu instalación.

ASM es un administrador de volúmenes y un sistema de archivos para bases de datos Oracle que admite configuraciones de base de datos Oracle de una sola instancia y Oracle Real Application Clusters (Oracle RAC). ASM es la solución de administración de almacenamiento recomendada de Oracle que proporciona una alternativa a los administradores de volúmenes convencionales, sistemas de archivos y dispositivos sin formato.

Pasemos a mi receta:

  • 8-10 veces el volumen de datos en bruto para un sistema OLTP
  • 2-4 veces el volumen de datos en bruto para un Almacén de datos.
  • Cuanto más grande sea la base de datos, más cerca estará de los factores de multiplicación inferiores.

Aclaración: Por supuesto, esta es solo mi opinión, basada en alguna que otra experiencia. Si usas las cifras anteriores para un proyecto real y no obtienes el espacio total en disco que necesitas, no me eches las culpas ;P. Si lo haces y está bien, entonces por supuesto, ahora me debes una cerveza :)

Muchos de nosotros probablemente hemos tenido que calcular el tamaño esperado de una base de datos antes (bajo la atenta mirada del manager, en el momento de hacer el pliego de una oferta), pero la base de datos real es solo un componente de todo lo que necesita para ejecutar Oracle en tu sistema. También debe dimensionar los demás componentes:

  • Registros de rehacer archivados (redo logs), 
  • Área de preparación de copias de seguridad, 
  • Área de transferencia de datos. 
  • Archivos externos, si los hubiera. 
  • El sistema operativo. 
  • Espacio de intercambio (swap), 
  • Espacio para los ficheros log, trace, dump
  • Los "benditos" binarios de Oracle (que generalmente aumentan cada año) etc ...


En primer lugar, debe saber la cantidad de "datos sin procesar" que tiene. Con esto me refiero a lo que se convertirá en la tabla de datos. Ya a principios de este siglo, este podía ser el tamaño total de los archivos planos que usaba el sistema anterior, incluso el tamaño de los datos tal como estaba en las hojas de cálculo. Un archivo de exportación de Oracle del sistema también da una idea bastante buena del volumen de datos en bruto. Al carecer de todo esto, entonces necesitas un tamaño aproximado de tus datos brutos. Haz un cálculo esta manera:

  • "numero_de_filas * Suma_de_columnas" para tus 10 tablas más grandes. Y no tengas la tentación de sobreestimar, mis multiplicadores te permiten el relleno.

Digamos que ya has hecho esto y son 60GB de datos sin formato para un sistema OLTP. Deja que los chicos de almacenamiento sepan que probablemente querrás 500GB de espacio. Luego mentalmente lo dejarán como "sin consecuencias", ya que probablemente tengan muchos terabytes de almacenamiento. Luego he de aclarar una cosa: No estoy considerando la redundancia en absoluto, en el espacio que se proporciona. 

Si obtienes 5TB de datos brutos para un sistema DW, necesitará alrededor de 12-15 TB de almacenamiento en disco.

Si obtienes más de un Terabyte de datos en bruto para un sistema OLTP o de 10 a 20 Terabytes para un DW, cuando le das cifras a los chicos de almacenamiento , entonces es posible que palidezcan y digan algo como " ¡tienes que estar bromeando!". Esto es parte de por qué el factor de multiplicación para Data Warehouses y sistemas más grandes en general es menor, ya que se lo fuerza a tener más cuidado con el espacio que asigna y cómo lo usa.

La sobrecarga del espacio total en el disco sobre los datos Raw se reduce a medida que la base de datos se agranda por varias razones:

  • El tamaño de los binarios de Oracle y el sistema operativo no cambia a medida que la base de datos crece.
  • El tamaño del espacio de intercambio no aumenta en línea con la base de datos ya que, en términos generales, si aumenta el tamaño de la base de datos de 100 GB a 1 TB, no puede darse el lujo de aumentar la memoria del sistema de su servidor. Probablemente se duplique.
  • Las bases de datos muy grandes tienden a tener algo que las hace grandes, como imágenes o documentos incrustados, que no están indexados. Por lo tanto, la relación de segmentos de tabla a segmentos de índice aumenta.
  • Si tienes una base de datos muy grande, empieza a eliminar índices (a menudo aquellos que soportan restricciones) para ayudar al rendimiento de la carga y administración de datos, nuevamente mejorando la proporción de segmentos de tabla a segmentos de índice.
  • Las copias de seguridad se vuelven parciales o incrementales para reducir el tamaño y la duración de la copia de seguridad.
  • Como se mencionó anteriormente, el tamaño del sistema es tal que se debe tener más cuidado al limpiar las áreas de trabajo, reducir las áreas archivadas de registro de rehacer (esos archivos se comprimen bien) y otras áreas.
  • Si las cosas se vuelven extremas usted comienza a alterar PCTFREE y verificando el tamaño de las extensiones, aunque estos problemas de dimensionamiento desaparecen con Oracle ASM.