En la versión Oracle 8i se introdujo la capacidad de almacenar datos desestructurados con datos de tipo LOB (Large Object Binary). A partir de la versión 11gR1 introduce un nuevo mecanismo para almacenar este tipo de objetos llamado SecureFiles y en contrapartida los tipo LOB son llamados BasicFiles.
Es una nueva implementación para manejar los LOBs que mejora la performance entre 3 y 6 veces con respecto a los BasicFiles.
No se requieren realizar cambios en la aplicación para acceder a los datos, pero para poder utilizar este tipo de dato, es necesario realizar una migración. Sí se permite el uso combinado de los dos tipos, es decir, se puede utilizar una partición con BasicFiles y las nuevas particiones con SecureFiles.
Requerimientos
· El parámetro compatible debe estar seteado en 11.1.0.0.0 o superior.
· El tablespace donde resida la columna/partición/subpartición con SecureFiles debe ser de tipo ASSM.
· Si se desea usar Advance Compression, se requiere disponer de la opción Advance Compression o Advance Encription.
Especificación de SecureFiles
Para utilizar que el tipo de dato LOB se almacene como SecureFiles, hay que especificar SECUREFILES en la cláusula LOB.
Ejemplos:
LOB: LOB (c_lob) STORE AS SECUREFILES myclob
CLOB: XMLTYPE myxmltype STORE AS SECUREFILES CLOB
BLOB: XMLTYPE myxmltype STORE AS SECUREFILES BINARY XML
Parámetros de inicio
| Value | Effect |
| PERMITTED | The default value. The value indicates that SecureFile LOBs can be created in the database. |
| ALWAYS | Now that you see how the SecureFiles are so useful, you may want to make sure all LOBs from then onward should only be SecureFiles instead of the default BasicFiles, even if the user does not specify securefile. This parameter value ensures all the LOBs are created as SecureFiles by default. Remember, SecureFiles require ASSM tablespaces (which is default in 11g anyway), so if you are trying to create the LOB in a non-ASSM tablespace, you will get an error. |
| NEVER | Well, it’s just the opposite of always. You don’t like SecureFiles for some reason and do not want to allow its creation in the database. This parameter value will make the LOB created as a BasicFile when though a SecureFile clause is mentioned. The user does not get an error when the SecureFile clause is used but the LOB is silently created as BasicFile. |
| IGNORE | The securefile clause, along with all storage clauses is ignored. |
Técnicas de migración
1. Redefinir la tabla entera
2. Redefinir de a una partición por vez
3. Migrar sin migrar
Cabe aclarar que el método recomendado por Oracle para migrar Basicfiles o LONG a Securefiles es a través de la Redefinición (1 y 2).
1. Reorganización de la Tabla:
Ventajas:
a. La migración no requiere downtime, pues es online y se puede utilizar la tabla mientras se la migra.
b. Apenas se finaliza con la migración de los LOB, se puede usar las ventajas de SecureFiles.
Desventajas:
Online Redefinition requiere que haya disponible el mismo espacio que ocupa los LOBS/LONG a ser migrados, aunque si migramos partición por partición, se puede reducir la necesidad de espacio.
1.2 Pasos para realizar la migración de la tabla entera:
1. Relevar los campos de la tabla origen
2. Creación de la tabla destino
3. Comenzar la redefinición
4. Copiar los objetos dependientes de la tabla
5. Finalizar la redefinición (intercambia los nombres de las tablas)
6. Opcionalmente se puede borrar la tabla destino (que tiene la definición original)
3. Comenzar la redefinición
4. Copiar los objetos dependientes de la tabla
5. Finalizar la redefinición (intercambia los nombres de las tablas)
6. Opcionalmente se puede borrar la tabla destino (que tiene la definición original)
1.3 Compresión avanzada
Si se dispone de la opción Advance Compression y/o Advance Encryption se puede utilizar para comprimir, deduplicar y encriptar los datos almacenados como SecureFiles.
Por ejemplo:
Create table tabla_aux (
C_id number primary key
C_lob clob )
Lob(c_lob) store as SecureFiles (
Tablespace tbs_sb1 Compress low encrypt deduplicate)
Esto hay que hacerlo previo a la migración, no luego.C_id number primary key
C_lob clob )
Lob(c_lob) store as SecureFiles (
Tablespace tbs_sb1 Compress low encrypt deduplicate)
2. Migración de una tabla particionada de a una partición por vez.
Este método se utiliza cuando no se dispone del espacio necesario de antemano para migrar toda las particiones. Los pasos serían los siguientes:
1. Creación de una tabla destino con las mismas columnas pero no particionada y que tenga la columna LOB con SecureFiles
2. Para cada partición
i. Comenzar la redefinición de la partición contra la tabla (start_redef)
ii. Finalizar la redefinición (intercambia el nombre de la tabla y la partición)
Es importante notar que la definición de la tabla no cambia, sigue diciendo LOB Basicfiles como default storage. Esto podemos verlo cuando extraemos la metadata de la creación de la tabla. Por esto, cuando creemos una nueva partición HAY QUE ESPECIFICAR SECUREFILES, si no lo va a crear como BasicFiles.
Este método también permite usar encripción y compresión durante la migración, agregando las cláusulas correspondientes.
3. Migrar sin migrar
Tablas particionadas
Otro método es utilizar SecureFiles para las nuevas particiones, dejando los datos en el viejo formato como estaban.
Ventaja:
o Es más simple y más rápido, y permite postergar la migración de los datos si se desea a futuro.
Desventaja:
o No se obtienen las mejoras en performance de los datos que no están migrados.
o Como la definición de la tabla no cambia, cada vez que se agreguen particiones nuevas, hay que especificar SECUREFILES.
Ejemplo:
ALTER TABLE TABLA1 ADD PARTITION TB1_PART5 VALUES LESS THAN (500000)
LOB (colu4) STORE AS SECURE FILES (TABESPACE TBS_SB1)
LOB (colu4) STORE AS SECURE FILES (TABESPACE TBS_SB1)
Tablas no particionadas
Si no está particionada se puede crear una clave ficticia y particionar por esa clave. Este método si bien es técnicamente viable, no es el más recomendado.
En resumen, la migración de basicfiles a securefiles se puede llevar a cabo de diferentes maneras, y habrá que analizar para cada caso, cual es el método mas adecuado. Además puede requerir de un downtime según el método que se utilice.
En otra sección del blog, les mostraré unos casos de prueba con tablas de contenido real, en donde analizaremos la reducción de espacio a través del uso de deduplicación y compresión.
·
Nota
Metalink: SecureFiles Migration and
Accessing securefile metadata information
[ID 1170351.1]
·
Paper
Oracle: SecureFiles Migration an Oracle
White Paper – August 2008
