lunes, 2 de noviembre de 2009

ALTA DISPONIBILIDAD EN ORACLE

Oracle Real Application Clusters (Oracle RAC)

RAC Oracle es un producto opcional de la Base de Datos Oracle, puede ejecutar aplicaciones personalizadas o globales sin realizar cambios en un cluster de servidores de bajo costo. Oracle RAC ejecuta aplicaciones de manera más rápida que el mainframe más veloz. Y si un servidor falla, el mainframe se detiene mientras que Oracle RAC continúa funcionando.

Oracle RAC permite que múltiples computadoras ejecuten el software de SGBD de Oracle simultaneamente mientras acceden a una base de datos individual. Esto se llama una base de datos en cluster(clustered).

En una base de datos de Oracle no-RAC, una base de datos individual es accedida por una instancia individual. La base de datos se considera la colección de ficheros de datos, ficheros de control, y ficheros redo log localizados en disco. La instancia se considera la colección de procesos del sistema operativo y memoria relacionada de Oracle que están ejecutándose en el computador.

En Oracle RAC, dos o más computadoras (cada una con una instancia) acceden concurrentemente a una base de datos individual. Esto permite que una aplicación o usuario se conecte a alguno de los computadores y tenga aceso a los mismos datos.

Dado que todas las computadoras/instancias acceden a los mismos datos, el software de Oracle debe garantizar que los datos cambian en computadores diferentes de forma coordinada y que cuando un computador consulta datos recibe la versión actual incluso si los datos fueron modificados recientemente por otro computador. Esta funcionalidad de Oracle RAC se llama Cache Fusion. Cache Fusion es el nombre dado a la habilidad de Oracle RAC para tratar las caches de datos In-memory en cada computador en una cache individual global. Cache Fusion esencialmente funde las caches separadas en una cache global.

Beneficios de RAC Oracle:
Cache Fusion transfiere los bloques de datos (la unidad de transferencia más pequeña en la base de datos) usando la red de interconexión de alta velocidad de la infraestructura. Antes de la fusión de cache, el disco se usa como un medio de transferencia de datos y que tiene desventajas evidentes. Dado que Oracle RAC permite a varias computadoras acceder a una base de datos individual, puede ser usado para dirigir varias áreas de gestión de base de datos. Estas áreas incluyen: Alta disponibilidad, Escalabilidad, Crecimiento Incremental, y Consolidación de Base de datos.


ORACLE DATAGUARD

Un Data Guard de Oracle, mejora la Calidad de Servicio al descargar las actividades con muchos recursos desde una base de datos de producción hacia una o más bases de datos standby sincronizadas. Oracle Active Data Guard permite el acceso de solo lectura a una base de datos standby física para consultas, clasificaciones, informes, acceso basado en la web, etc., mientras continuamente se aplican los cambios recibidos desde la base de datos de producción. Oracle Active Data Guard también mejora el uso de backups rápidos cuando se descargan backups en una base de datos standby, y puede ofrecer beneficios adicionales de alta disponibilidad y protección ante desastres en caso de cortes de servicio planificados o no planificados en el sitio de producción.

Beneficios:
  • Aumente el desempeñoDescarga el volumen de trabajo en una réplica actualizada de la base de datos de producción
  • Simplifique las operacionesElimina la complejidad de administración que se asocia a las soluciones de replicación tradicional
  • Elimine el compromisoLa réplica de informes está actualizada y online en todo momento - no es posible con la tecnología tradicional para el espejamiento de almacenamiento
  • Reduzca los costosUna base de datos standby física Active Data Guard también puede brindar recuperación ante desastres y/o servir como base de datos de prueba - no se requieren servidores ni almacenamiento adicional

TECNOLOGÍA FLASHBACK DE ORACLE

Oracle Database 11g brinda una tecnología para la corrección de errores humanos denominada Flashback. Flashback que revoluciona la recuperación de datos. En el pasado, dañar una base de datos podría tardar minutos, pero varias horas en recuperarla. Con Flashback, el tiempo para corregir los errores es igual al tiempo que llevó cometer el error. También es extremadamente fácil de utilizar, y se puede utilizar un solo comando breve para recuperar toda la base de datos en lugar de seguir algún procedimiento complejo. Flashback ofrece una interface SQL para analizar y reparar rápidamente los errores humanos. Flashback brinda reparación y análisis de grano fino para el daño localizado – como cuando se elimina el pedido erróneo de un cliente. Flashback también permite la corrección de daños más generalizados, y lo hace con rapidez para evitar un largo tiempo de baja – como cuando se eliminan todas las órdenes del mes de un cliente. Flashback es exclusivo para Oracle Database y soporta la recuperación en todos los niveles, incluso las filas, transacciones, tablas, espacios de tabla y base de datos.

Flashback Query
Mediante el uso de Oracle Flashback Query, los administradores pueden consultar cualquier dato del pasado. Esta poderosa característica puede utilizarse para ver y reconstruir los datos corruptos que pueden haberse eliminando o cambiado involuntariamente.

SELECT *
FROM emp
AS OF TIMESTAMP
TO_TIMESTAMP(’01-APR-07’ 02:00:00 PM’,’DD-MON-YY HH:MI:SS PM’)
WHERE …


La consulta simple muestra filas de la tabla emp a partir de la fecha de registro especificada. Esta característica es una herramienta avanzada que los administradores pueden aprovechar para identificar y resolver rápidamente la corrupción de datos lógicos. Sin embargo, esta funcionalidad podría incorporarse fácilmente en una aplicación con el fin de ofrecer a los usuarios de aplicaciones un mecanismo fácil y rápido para eliminar o deshacer los cambios en los datos sin
contactarse con su administrador.

Flashback Versions Query
Flashback Versions Query, similar a Flashback Query, es una característica que permite que los administradores consulten cualquier dato del pasado. La diferencia y el poder detrás de Flashback Versions Query es su capacidad de recuperar diferentes versiones de una fila a través de un intervalo de tiempo especificado.

SELECT *
FROM emp
VERSIONS BETWEEN TIMESTAMP
TO_TIMESTAMP(’01-APR-07’ 02:00:00 PM’,’DD-MON-YY HH:MI:SS PM’)
AND
TO_TIMESTAMP(’01-APR-07’ 03:00:00 PM’,’DD-MON-YY HH:MI:SS PM’)
WHERE …

Esta consulta muestra cada versión de la fila entre las fechas de registro especificadas. El administrador podrá tener visibilidad de los valores a medida que fueron modificados por diferentes transacciones a lo largo de este período. Este mecanismo otorga al administrador la capacidad de detectar exactamente cuándo y cómo se han cambiado los datos, proporcionando un gran valor tanto en la depuración de aplicaciones como en la reparación de datos.
Flashback Transaction A menudo, es probable que haya una corrupción lógica en una transacción que puede cambiar los datos en múltiples filas o tablas. Flashback Transaction Query permite que un administrador vea todos los cambios realizados por una transacción específica.

SELECT *
FROM FLASHBACK_TRANSACTION_QUERY
WHERE XID = ‘000200030000002D

Flashback Data Archive
Las declaraciones de consultas Flashback mencionadas anteriormente dependen de la disponibilidad de los datos históricos en el espacio de tabla UNDO. La cantidad de tiempo durante el cual los datos históricos permanecen en el espacio de tabla UNDO depende del tamaño del espacio de tabla, el índice de cambios en los datos y los parámetros configurables de la base de datos. En general, los administradores configuran sus bases de datos para guardar los datos UNDO durante no más de días o semanas– definitivamente, no años ni décadas. Para superar este límite, Oracle Database 11g incorpora nuevas capacidades innovadoras disponibles mediante
Flashback Data Archive. Flashback Data Archive guarda versiones históricas de los datos como datos regulares dentro de la base de datos, los cuales pueden ser guardados todo el tiempo necesario por la empresa. Flashback Data Archive revoluciona las estrategias de retención de datos para ayudar a las empresas en el panorama regulatorio en continuo cambio, como Sarbanes-Oxley y HIPPA. Para garantizar la integridad de los datos retenidos– Flashback Data Archive permite el acceso de solo lectura a versiones históricas de los datos.


Flashback Database
Para restablecer toda una base de datos a un momento pasado, el método tradicional es restablecer la base de datos desde un backup RMAN y recuperar hasta el momento anterior al error. Como el tamaño de bases de datos está creciendo, puede tardar horas o incluso días restaurar toda una base de datos. Flashback Database es una nueva estrategia para restablecer toda una base de datos hasta un punto específico. Flashback Database utiliza registros flashback para retroceder la base de datos hasta un momento específico. Flashback Database, que utiliza registros flashback, es extremadamente rápido ya que solo restablece bloques que han cambiado. Fácil de utilizar y eficiente, Flashback Database puede literalmente restablecer una base de datos en cuestión de minutos, a diferencia de varias horas.

FLASHBACK DATABASE TO TIMESTAMP
TO_TIMESTAMP(’01-APR-07 02:00:00 PM’,’DD-MON-YY HH:MI:SS PM’)


Como se puede observar, no se necesitan procedimientos complicados de recuperación ni restaurar backups desde la cinta. Flashback Database reduce drásticamente la cantidad de tiempo de baja requerido para escenarios que necesitan un restablecimiento de base de datos.


Flashback Table
Con frecuencia, la corrupción lógica es puesta en cuarentena en una o más tablas, no requiriendo así un restablecimiento de toda la base de datos. Flashback Table es la característica que permite al administrador recuperar una tabla, o un grupo de tablas, hasta un momento específico, con rapidez y facilidad.

FLASHBACK TABLE orders, order_itmes TIMESTAMP
TO_TIMESTAMP(’01-APR-07 02:00:00 PM’,’DD-MON-YY HH:MI:SS PM’)

Esta consulta hará retroceder las órdenes y las tablas order_item, deshaciendo toda actualización realizada a estas tablas entre el horario actual y la fecha de registro especificada. En el caso de que una tabla sea dada de baja accidentalmente, los administradores pueden utilizar la característica Flashback Table para restablecer la tabla dada de baja, y todos sus índices, restricciones y activadores, desde la Papelera de Reciclaje. Los objetos inactivos permanecen en la Papelera de Reciclaje hasta que el administrador los depure explícitamente o hasta que el espacio de tabla del objeto se vea obligado a tener espacio libre.


Flashback Restore Points
En las descripciones y ejemplos anteriores de Flashback Database y Flashback Table, hemos utilizado el tiempo como criterio para nuestras operaciones de restablecimiento o flashback. En Oracle Database 10g versión 2, se ofrecían Flashback Restore Points (Puntos de Restauración Flashback) como medio para simplificar y acelerar la resolución de fallas en los datos. Un punto de restablecimiento es una etiqueta definida por el usuario que marca un momento específico en el que el administrador considera que la base de datos está en buen estado. Flashback Restore Points permite a los administradores remediar, más fácil y eficientemente, sus bases de datos en caso de actividades perjudiciales o inapropiadas.

Fuente: Oracle Info.

lunes, 26 de octubre de 2009

PRIVILEGIOS, ROLES Y PERFILES EN ORACLE

PRIVILEGIOS

Es la capacidad de un usuario dentro de la base de datos a realizar determinadas operaciones o acceder a determinados objetos de otros usuarios.

Privilegios sobre los objetos

Nos permite acceder y realizar cambios en los datos de otros usuairo. Ejemplo: El privilegio de consultar la tabla de otro usuario es un privilegio sobre objetos.

ON= Especifica el objeto sobre el que se dan los privilegios.
TO= Identifica a los usuarios o roles a los que se conceden los privilegios.
ALL= Concede todos los privilegios sobre el objeto especificado.
WITCH GRANT OPTION= Permite que el receptor del privilegio o rol se lo asigne a otros usuarios o roles.
PUBLIC= Asigna los privilegios a todos los usuarios actuales y futuros: El propósito principal del grupo PUBLIC es garantizar el acceso a determinados objetos a todos los usuarios de la base de datos.

Privilegios de sistema

Dan derecho a ejecutar un tipo de comando SQL o a realzar alguna acción sobre objetos de un tipo especificado. Por ejemplo, el privilegio para crear TABLESPACES es un privilegio de sistema. Formato:

WITH ADMIN OPTION= Permite que el receptor del privilegio o rol pueda conceder esos mismos privilegios a otros usuarios o roles.


ROLES

Conjunto de privilegios agrupados. Formato:

CREATE ROLE NOMBREROL [IFENTIFIED BY CONTRASEÑA];

Nota: Un rol puede decidir el acceso de un usuario a un objeto, pero no puede permitir la creación de objetos.

Supresión de privilegios en los roles

REVOKE NOMBREPRIVILEGIO ON NOMBRETABLA FROM NOMBREROL;

REVOKE NOMBREPRIVILEGIO FROM NOMBREROL;


Supresión de un rol

DROP ROLE NOMBREROL;

Establecer un rol por defecto

ALTER USER NOMBREUSUARIO
DEFAULT {[ROLE NOMBRE_ROL] | [NONE]};


NONE= Hace que el usuario no tenga rol por defecto.



PERFILES

Conjunto de límites a los recursos de la base de datos:

CREATE PROFILE NOMBREPERFIL LIMIT
{NOMBRE DE LOS LÍMITES}
{ENTERO [K | M] | UNLIMITED | DEFAULT };


UNLIMITED= No hay limites sobre un recurso en particular.
DEFAULT= Coge el limite del perfil default.

Borrado de un perfil:

DROP FILE NOMBREPERFIL [CASCADE];

lunes, 14 de septiembre de 2009

Tablespace UNDO


  • Podemos tener varios tablespaces de “undo”, pero sólo uno de ellos estará activo.
  • No se pueden crear objetos sobre un tablespace de “undo”.
  • Al cambiar de tablespace “undo” activo (con undo_tablespace), los segmentos de rollback que contiene el nuevo tablespace pasan a estar online, mientras que los del tablespace anterior se ponen offline.

Se crean de dos formas:
  • Mediante create database.
  • Mediante create tablespace:
Create undo tablespace undotbs02 datafile ‘c:\oraclexe\oradata\ex\undo02.dbf’ size 25M reuse autoextend on;

Para eliminarlo:
drop tablespace undotbs02;

Parámetros de inicialización de los espacios de tablas de deshacer:

  • Undo_Management (valores MANUAL/AUTO). Si auto se gestionará de forma automática el espacio de deshacer. No es dinámico, cuando se cambia de estado se debe rearrancar la instancia.
  • Undo_tablespace (MANUAL/AUTO). En entornos RAC (Real Application Clusters)

Indices B-Tree y Bitmap

Los árboles B mantienen los datos ordenados y las inserciones y eliminaciones se realizan en tiempo logarítmico amortizado.

La idea tras los árboles-B es que los nodos internos deben tener un número variable de nodos hijo dentro de un rango predefinido. Cuando se inserta o se elimina un dato de la estructura, la cantidad de nodos hijo varía dentro de un nodo. Para que siga manteniéndose el número de nodos dentro del rango predefinido, los nodos internos se juntan o se parten.

Un árbol-B se mantiene balanceado porque requiere que todos los nodos hoja se
encuentren a la misma altura.

Los indices B-Tree almacenan rowids en las hojas del arbol. Estos indices pueden llegar a utilizar grandes cantidades de espacio de almacenamiento. A diferencia de los indices B-Tree, los indices de tipo Bitmap utilizan una fraccion de espacio mucho menor representando los rowids como valores binarios (on/off).

Los indices Bitmap son aconsejables en situaciones en que los diferentes valores que puede tomar la columna son relativamente pocos. Ejemplos: sexo, estado civil, etc. Cuantos menos valores posibles, mejor. A medida que crece la cantidad de valores posibles, aumentara el tamaño del indice.

¿Que es un INDEX?

Los indices se usan para mejorar el rendimiento de las operaciones sobre una tabla.

En general mejoran el rendimiento las SELECT y empeoran (minimamente) el rendimiento de los INSERT y los DELETE.

Una vez creados no es necesario nada más, oracle los usa cuando es posible (ver EXPLAIN PLAN).

En oracle existen tres tipos de indices:

1)Table Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON [esquema.]table_name [tbl_alias]
(col [ASC | DESC]) index_clause index_attribs
2)Bitmap Join Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON [esquema.]table_name [tbl_alias]
(col_expression [ASC | DESC])
FROM [esquema.]table_name [tbl_alias]
WHERE condition [index_clause] index_attribs
3)Cluster Index:
CREATE [UNIQUE|BITMAP] INDEX [esquema.]index_name
ON CLUSTER [esquema.]cluster_name index_attribs
las index_clauses posibles son:
LOCAL STORE IN (tablespace)

LOCAL STORE IN (tablespace)
(PARTITION [partition
[LOGGING|NOLOGGING]
[TABLESPACE {tablespace|DEFAULT}]
[PCTFREE int]
[PCTUSED int]
[INITRANS int]
[MAXTRANS int]
[STORAGE storage_clause]
[STORE IN {tablespace_name|DEFAULT]
[SUBPARTITION [subpartition [TABLESPACE tablespace]]]])

LOCAL (PARTITION [partition
[LOGGING|NOLOGGING]
[TABLESPACE {tablespace|DEFAULT}]
[PCTFREE int]
[PCTUSED int]
[INITRANS int]
[MAXTRANS int]
[STORAGE storage_clause]
[STORE IN {tablespace_name|DEFAULT]
[SUBPARTITION [subpartition [TABLESPACE tablespace]]]])

GLOBAL PARTITION BY RANGE (col_list)
( PARTITION partition VALUES LESS THAN (value_list)
[LOGGING|NOLOGGING]
[TABLESPACE {tablespace|DEFAULT}]
[PCTFREE int]
[PCTUSED int]
[INITRANS int]
[MAXTRANS int]
[STORAGE storage_clause] )

INDEXTYPE IS indextype [PARALLEL int|NOPARALLEL] [PARAMETERS ('ODCI_Params')]
{Esto es solo para table index, no para bitmap join Index}
Y además index_attribs puede ser cualquier combinación de los siguientes:
NOSORT|SORT
REVERSE
COMPRESS int
NOCOMPRESS
COMPUTE STATISTICS
[NO]LOGGING
ONLINE
TABLESPACE {tablespace|DEFAULT}
PCTFREE int
PCTUSED int
INITRANS int
MAXTRANS int
STORAGE storage_clause
PARALLEL parallel_clause

Si usamos la opcion PARALLEL esta debe estar al final.

create index es una de las pocas sentencias que pueden usar nologging option.

create index requiere un segmento temporal si no hay espacio en memoria suficiente.

Crear indices basados en funciones require que query_rewrite_enabled este a true y query_rewrite_integrity este a trusted.

Un ejemplo de indices basados en funciones para busquedas en mayusculas:
CREATE INDEX idx_case_ins ON my_table(UPPER(empname));

SELECT * FROM my_table WHERE UPPER(empname) = 'KARL';

lunes, 7 de septiembre de 2009

Extensiones en ORACLE

Una extensión es una unidad lógica de almacenamiento que está formada por un número determinado de bloques de datos contiguos. La agrupación de una o varias extensiones forman un segmento que puede ser una tabla, un índice, un segmento de rollback o un segmento temporal. Por lo tanto, datos de una tabla, sabemos que están en un solo segmento de tipo tabla, que a su vez estará formado por una o varias extensiones y que, cada una de esas extensiones está formada por un número determinado de bloques de datos.

Cuando se crea un segmento nuevo, es decir, una tabla, un índice o un segmento de rollback, se crea obligatoriamente una extensión en dicho segmento (en el caso de los rollback se crean dos). El tamaño de esta extensión inicial viene dado por el valor parámetro "initial" que se indica en el momento de crear el segmento.

. Asignación de Extensiones

Al crear o, mejor dicho, asignar una nueva extensión al segmento, se está reservando espacio en el disco para almacenar los nuevos datos de dicho segmento. Por lo tanto, al crear la nueva extensión está totalmente vacía y todo su espacio está disponible para almacenar los datos del segmento y, además, en el disco debe haber espacio libre para que Oracle reserve todo el tamaño que necesita la extensión, y lo formatea de forma especial para poder utilizarlo. A partir de ese momento, en esa extensión solamente se podrán almacenar datos del segmento al que pertenece.

Cuando se llenan todos los bloques de datos de una extensión, el segmento solicita una nueva extensión al sistema para poder seguir almacenando información.

¿Cómo podemos determinar el número de extensiones y su tamaño de un segmento?.

Para establecer el tamaño de las futuras extensiones que irá solicitando un segmento se utilizan varios parámetros a los que hay que dar valor en el momento de la creación de la tabla, índice o segmento de rollback. Estos parámetros se indican en la claúsula STORAGE de la sentencia que crea el segmento y son los siguientes:

Initial:

Indica el tamaño en bytes de la primera extensión que tendrá el segmento. Se puede indicar después del valor una "K" o "M" para que el valor sea interpretado como Kilobytes o Megabytes en lugar de bytes. Si no se pone explícitamente este parámetro en la creación del segmento, se hereda por defecto el valor que tenga este parámetro en el tablespace en el que se está creando el segmento y que, si no se ha indicado tampoco, por defecto son 5 bytes. Cuando se crea una extensión oracle redondea el tamaño indicado al siguiente múltiplo superior a 5 bloques de datos. Por lo tanto, si nuestros bloques son de 8192 bytes y creamos un segmento con un inital de 256Kbytes, realmente estamos creando un segmento de 32 bloques y oracle lo redondea a 35 bloques que es el primer múltiplo superior a 5 de 32. Por lo tanto, nuestra initial extent será de 35 * 8192 = 280 Kbytes.

Para comprobar estos datos se puede consultar la tabla dba_segments en la que tenemos un registro por cada segmento distinto:

Select segment_name, initial_extent, next_extent, pct_increase, min_extent,
max_extent from dba_segments;

También se puede consultar la vista dba_extents que es un detalle de dba_segments ya que aquí se detalla por cada segmento todas sus extensiones, con su tamaño en concreto.

Select segment_name, extent_id, blocks, bytes from dba_extents;

A pesar de lo que aparece en la documentación de Oracle sobre los redondeos a múltiplos de 5 bloques, nos hemos encontrado con muchos casos en los que creamos segmentos con una sola extensión de 256 Kbytes con bloques de 8192 bytes (con el caso anterior), y en la vista dba_extents, al consultar el valor de initial_extent sigue siendo 256 Kbytes, y en dba_extents, que es donde debería redondearse realmente dicho valor a un múltiplo de 5, algunas extensiones aparecen con 256 Kbytes y otras con los 280 Kbytes que teóricamente deberían tener.

Next:

Indica el tamaño que tendrá la próxima extensión que se cree cuando no quede más sitio en las extensiones que ya tiene asignadas el segmento. De igual manera que en el caso del parámetro initial, Oracle redondea a un múltiplo de 5 bloques este valor, a la hora de crear la extensión nueva. Cada vez que se crea una nueva extensión, se recalcula el valor de este parámetro en función del valor de pctincrease y se actualiza la vista dba_segments.

Pctincrease:

En el momento que se asigna una nueva extensión al segmento, se recalcula el valor que va a tener la próxima que se le asigne y que será, el tamaño de la extensión recién creada (el next que tenía el segmento) aumentado en el porcentaje indicado por pctincrease. Por lo tanto, si qeremos que todas las extensiones de nuestro segmento tengan el mismo tamaño, habrá que asignarles el pctincrease a 0. Oracle recomienda establecer por norma el pctincrease a 0 para evitar que se descontrolen los tamaños de los segmentos, especialmente los temporales, aunque, curiosamente, su valor por defecto es de 50%. No se puede modificar el pctincrease de los segmentos de rollback que es siempre 0.

Mostremos un ejemplo: tenemos un segmento que en el campo next_extent tiene como valor 262144 y en pct_increase tiene 50 y los bloques son de 8192 bytes. Cuando crezca el segmento y solicite una nueva extensión, ésta se creará del tamaño indicado en next_extent redondeándola al primer múltiplo de 5 bloques superior o igual a dicho valor. En nuestro caso 262144 son 32 bloques así que creará una extensión de 35 que son 286720 bytes. Además, recalcula el valor del siguiente next_extent aumentando en un 50% el valor del antiguo next_extent, es decir 262144 * 1,5 = 393216 bytes.

Nota: el recálculo del siguiente extent (393216) se basa en el valor del anterior next_extent (262144) y no en el valor de la extensión creada al redondear a un múltiplo de 5 bloques (286720), ya que si no, nos habría salido un next_extent de 286720 * 1,5 = 430080. Por lo tanto, al consultar las tabla dba_segments veremos que next_extent es 393216 es decir 48 bloques, aunque, eso si, si se vuelve a llenar esta extensión, se creará realmente una extensión de 50 bloques que son los 430080 bytes.

Minextents:

Se indica el número de extensiones que se deben reservar a la vez para un determinado segmento en el momento de su creación. Por defecto es una excepto en los segmentos de rollback que son dos. Puede que las extensiones no estén contiguas. Por supuesto, si en la cláusula storage en la créación del objeto se indican valores para next y pctincrease, las extensiones iniciales que se crean se recalculan para cumplir lo indicado en estos parámetros.

Por ejemplo, creamos un segmento con minextents = 4, con un initial de 262144, next de también 262144, bytes y con un pctincrease del 50%, el resultado será la creación de 4 extensiones de tamaños, 286720, 286720, 409600, 614400 y de un next extent de 884736. Estos tamaños vienen de redondear 32, 48 y 72 a múltiplos de 5 y el next extent es 108 bloques que es el 50% de 72 bloques.

Maxextents:

Es el numero máximo de extensiones que se pueden crear en ese objeto, contando también la primera. Se puede especificar UNLIMITED con lo que pueden crecer indefinidamente. No se recomienda que a los segmentos de rollback se les asigne unlimited maxextents ya que con operaciones complejas podrían aumentar excesivamente de tamaño y llenarían el disco. Así que hay que tener cuidado a la hora de crear rollback segments, sobretodo porque heredan por defecto el valor del parámetro que tenga asignado el tablespace en el que se crean.

Vamos a poner un ejemplo de creación de una tabla en la que se indican valores para los parámetros de la cláusula storage que acabamos de explicar. Crearemos, por ejemplo, una tabla llamada empleado que contiene un solo campo, nombre, con un initial extent de 256 Kilobytes, con 512 Kilobytes de next extent, un pctincrease de 50, con 3 extensiones iniciales y con un máximo de 10 extensiones:

create table empleado (nombre varchar2(50))
storage (initial 256K next 512K pctincrease 50 minextents 3 maxextents 10)

Si consultamos la vista dba_extents nos mostrará que ha creado las 3 extensiones que le hemos indicado con los siguientes valores:

Select extent_id, bytes, blocks from dba_extents
where segment_name = 'EMPLEADO' order by extent_id;

0 286720 35
1 532480 65
2 819200 100

Y, al consultar la vista dba_segments o incluso la vista user_tables para este segmento en concreto, observamos el valor de next_extent:

Select next_extent from user_extents where segment_name = 'EMPLEADO';

1179648 que es el resultado de 512K * 1,5 * 1,5.

Cuando Oracle necesita asignar una nueva extensión a un segmento realiza el siguiente proceso para buscar bloques de datos contiguos en igual número o superior al solicitado por la extensión:

  • En primer lugar, busca un conjunto de bloques contiguos igual al solicitado por la extensión más uno, para evitar la fragmentación (excepto cuando la extensión es de 5 o menos bloques). Por lo tanto, si la extensión nueva es de 29 bloques oracle buscará un conjunto de justo 30 bloques libres consecutivos.
  • Si no encuentra ningún conjunto de exactamente ese número de bloques, empieza a buscar un conjunto de más bloques contiguos. Si el primer conjunto que encuentra tiene más de 5 bloques que los que busca, se queda solamente con los que busca, mientras que si la diferencia es de menos de 5 bloques, se coge todo el conjunto.

Por lo tanto, en nuestro caso, si el primer conjunto que encuentra fuera de 35 o más bloques, cogería solo los 30 primeros, mientras que si encuentra un conjunto de entre 31 y 34 se lo quedaría entero.

Nota: En este paso se puede comprobar que, aunque a un segmento le asignemos pctincrease 0, puede que luego nos encontremos en dba_extents algun extensión algo más grande que otras del mismo segmento.

Cuando no encuentra ningún conjunto de bloques de tamaño superior al que busca, realiza un coalesce del tablespace, que es un proceso mediante el cual se unen los distintos bloques que han ido quedándose fragmentados en el tablespace al irse creando y eliminando extensiones mediante este proceso. Una vez hecho el coalesce, Oracle vuelve a repetir los pasos anteriores.

Si, finalmente no encuentra ningún conjunto de bloques para crear la nueva extensión, intenta aumentar el tamaño de alguno de los datafiles del tablespace. Esto solamente lo conseguirá si tienen activado el autoexpand. En caso de no conseguirlo, devolverá un error.

. Desasignación de Extensiones

Las extensiones que han sido reservadas por un segmento no son devueltas a Oracle para que se las pueda signar a otro segmento del mismo tablespace hasta que se elimina el objeto mediante la instrucción DROP. Por lo tanto, cuando tenemos una tabla que nos ocupa varias extensiones, a pesar de que borremos todas sus filas, esa tabla seguirá teniendo reservadas las extensiones aunque eso si, estarán vacías.

Existen algunas excepciones. Se pueden devolver todas las extensiones de una tabla excepto las min_extents haciendo un truncate de la misma. Hay que ser muy cuidadoso con esta instrucción ya que se eliminan todos los datos de la tabla y, no hay rollback posible. En los segmentos de rollback, si tienen puesto el parámetro optimal, oracle periódicamente puede desasignarle las extensiones que no usa hasta que vuelve a tener el tamaño óptimo. Finalmente, existe una sentencia que también desasigna las extensiones que no se usan en una tabla:

Alter table nombre_de_table deallocate unused;

En cuanto se ha desasignado una extensión del segmento al que pertenecía, Oracle ya la puede volver a reclamar para que la puedan utilizar otros segmentos del mismo tablespace. Por lo tanto, cuando un nuevo objeto solicite una nueva extensión, si Oracle no encuentra espacio libre suficiente para crear una nueva, y entre las que ha ido desasignando tampoco encuentra ninguna suficientemente grande como para asignarla, puede unir varias de estas extensiones hasta conseguir una lo suficientemente grande como para poder asignársela al segmento. A esta operación se le llama COALESCE de extensiones.

Segmentos en ORACLE

Segmentos y Extensiones en ORACLE

Los datos en la BD son almacenados físicamente en bloques Oracle: la mínima unidad de espacio físico, y es un múltiplo del bloque del SO (2 Kb usualmente). El tamaño del bloque Oracle se fija por el parámetro DB_BLOCK_SIZE del fichero init.ora. Un tamaño grande de bloque mejora la eficiencia del cache de E/S, pero el tamaño de la SGA aumentará para contener los mismos DB_BLOCK_BUFFERS, lo que significa un problema de memoria.

Una serie de bloques contiguos es una extensión, que es una unidad lógica de almacenamiento. Una serie de extensiones es un segmento. Cuando un objeto es creado, se reserva una extensión en su segmento. Cuando el objeto crezca, necesitará más espacio y se reservarán más extensiones.

Cada segmento tiene un conjunto de parámetros de almacenamiento que controla su crecimiento:

  • initial: tamaño de la extensión inicial (10k).
  • next: tamaño de la siguiente extensión a asignar (10k).
  • minextents: número de extensiones asignadas en el momento de la creación del segmento (1).
  • maxextents: número máximo de extensiones (99).
  • pctincrease: Porcentaje en el que crecerá la siguiente extensión antes de que se asigne, en relación con la última extensión utilizada (50).
  • pctfree: porcentaje de espacio libre para actualizaciones de filas que se reserva dentro de cada bloque asignado al segmento (10).
  • pctused: porcentaje de utilización del bloque por debajo del cual Oracle considera que un bloque puede ser utilizado para insertar filas nuevas en él.
  • tablespace: nombre del espacio de tablas donde se creará el segmento.

Cuando se diseña una BD se ha de tener mucho cuidado a la hora de dimensionar la BD y prever el crecimiento de las tablas. A continuación se hacen algunas consideraciones sobre la gestión del espacio para los diferentes segmentos.

Segmentos de Datos

El espacio del diccionario de datos se suele mantener más o menos constante, aunque es crítico que tenga suficiente espacio para crecer en el espacio de tablas SYSTEM. Así, hay que tener cuidado de colocar las tablas de usuario, los índices, segmentos temporales y los segmentos de rollback en otros espacios de tablas. Además, es recomendable que el espacio de tablas SYSTEM esté al 50% o 75% de su espacio disponible. Finalmente, asegurarse que los usuarios no tienen privilegios de escritura en el espacio de tablas SYSTEM.

Las tablas crecen proporcionalmente con el número de filas, ya que se puede suponer que la longitud de las filas es constante.

Segmentos de Índice

Los índices crecen en tamaño en mayor proporción que las tablas asociadas si los datos en la tabla son modificados frecuentemente. La gestión del espacio es mejor si se mantienen los índices de tablas grandes en espacios de tablas separados.

Segmentos de Rollback

Los segmentos de rollback almacenan la imagen anterior a una modificación de un bloque. La información en el segmento de rollback se utiliza para asegurar la consistencia en lectura, el rollback (el valor en el segmento de rollback se copia en el bloque de datos) y la recuperación.

Es importante comprender cual es el contenido de un segmento de rollback. No almacenan el bloque de datos modificado entero, sólo la imagen previa de la fila o filas modificadas. La información del segmento de roolback consiste en varias entradas llamadas undo. Por ejemplo, si se inserta una fila en una tabla, el undo necesitará sólo el rowid de la fila insertada, ya que para volver atrás la insercion sólo hay que realizar un delete. En las operación de actualización, se almacenará el valor antiguo de las columnas modificadas. El segmento de rollback asegura que la información undo se guardan durante la vida de la transacción.

Un segmento de rollback como cualquier otro segmento consiste en una serie de extensiones. Sin embargo, la mayor diferencia entre un segmento de datos y otro rollback es que en este último las extensiones se utilizan de manera circular. Así, habrá que tener cuidado a la hora de fijar el tamaño del segmento de rollback para que la cabeza no pille a la cola.

Segmentos Temporales

Los segmentos temporales se crean cuando se efectuan las siguientes operaciones:

  • Create Index
  • Select con distinct, order by, union, intersect y minus.
  • uniones no indexadas.
  • Ciertas subconsultas correlacionadas.

Si las tablas a ordenar son pequeñas la ordenación se realiza en memoria principal, pero si la tabla es grande se realiza en disco. El parámetro SORT_AREA_SIZE determina el lugar donde se hace la ordenación. Incrementándole se reduce la creación de segmentos temporales.