A veces es necesario conectar Oracle con una BD NonOracle, porque los sistemas de nuestros clientes tienen o están desplegados en toda una variedad de motores de BD dado que los proveedores de aplicación a veces no manejan la excelencia de Motor de BD Como es Oracle DB.
En este articulo, vamos a configurar la conexión con una BD Non Oracle
Lo primero que en la VM o maquina asignada debemos instalar los paquetes para ODBC y driver para conectarse la BD Non Oracle en este caso usaremos Postgres para nuestro ejemplo:
yum install postgresql
yum search libnsl
yum install libnsl.x86_64
yum install unixODBC*
yum install postgresql-odbc.x86_64
Luego debemos configurar el archivo /etc/odbc.ini con la informacion del destino donde la BD NonOracle se ejecuta, debemos asegurarnos de tener permisos en la red, acceso al puerto, credenciales validas etc.
[pg]
Description = pg
Driver =/usr/lib64/psqlodbc.so
ServerName = HOSTREMOTO
Username = USUARIO
Password = password
Port = puerto
Database = DB
Trace = no
Debemos haber instalado el software de Oracle Database gateway for ODBC para la conectividad genérica.
lsnrctl status
LSNRCTL for Linux: Version 19.0.0.0.0 – Production on 31-MAY-2026 23:31:06
Copyright (c) 1991, 2019, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=10.0.0.96)(PORT=1521)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 19.0.0.0.0 – Production
El Despliegue de Software Oracle RDBMS en un cluster en Exadata es un tanto diferente, no significa que no se pueda hacer de la forma tradicional, pero la documentación indica el método con despliegue de software controlado,.
Existe un Software de despliegue llamado OEDACLI, cada cierto tiempo se actualiza la versión como ocurre con el orachk ( ahora AHF), o para sistemas de Ingenieroa EXACHK.
La nota de la herramienta es: Engineered Systems : Exadata Onecommand Releases (Doc ID 2257907.1)
También conocido en la documentación como OneCommand Tool.
Hay que conocer la estructura de los clusters que forman parte de mi exadata, si es BM o VM, etc, etc, esta información está en un manifiesto en XML usualmente en la ruta del OneCommand con que se desplegó orginalmente el exadata( Usualmente /EXAVMIMAGES/joc/linux).
Para mi ejemplo:
Vamos a suponer que tenemos un cluster con nombre cluster1, que ya tiene un DBHOME desplegado.
Listamos los DB OracleHomes que ya tenemos desplegados:
oedacli> list databasehomes version : “CloneInstall” cluster : id : “Cluster-c1eda23c2-b409-8043-d268-2ef6a753cf91_id” databaseHomeName : “DbHome_4” databaseSwOwner : “33c3048e-f429-08a4-c88c-86087ced123c” databaseVersion : “12.2.0.1.191015” databaseHomeLoc : “/u01/app/oracle/product/12.2.0.1/dbhome_1” inventoryLocation : “/u01/app/oraInventory” installType : “rac_database” language : “all_langs” machines : machine : domainGroup : machine : id : “exa00compute01_Cluster-c1eda23c2-b409-8043-d268-2ef6a753cf91_vm01_id” domainGroup : machine : id : “exa00compute02_Cluster-c1eda23c2-b409-8043-d268-2ef6a753cf91_vm01_id” patches : patch : patchNumber : “30116802” basedir : “/u01/app/oracle” id : “DbHome_9b5a5b28-4934-4c5a-2d72-c0f5a0171ae3_id”
Ahora agregamos, 4 comandos componen toda tarea en OEDACLI, el comando en si,
save action, merge actions y deploy actons
oedacli> ADD DATABASEHOME OWNER=oracle DBVERSION=19.3.0.0.190416 DBHOMELOC=/u01/app/oracle/product/19.0.0.0/dbhome_1 where CLUSTERNAME=cluster1 oedacli> save acation ERROR >——-^ Command did not Parse OK BAD : acation oedacli> save action oedacli> merge actions processMerge processMergeActions Merging Action : ADD DATABASEHOME OWNER=oracle DBVERSION=19.3.0.0.190416 DBHOMELOC=/u01/app/oracle/product/19.0.0.0/dbhome_1 where CLUSTERNAME=cluster1 Merging ADD DATABASEHOME Action Validated and Merged OK oedacli> deploy actions Deploying Action ID : 1 ADD DATABASEHOME OWNER=oracle DBVERSION=19.3.0.0.190416 DBHOMELOC=/u01/app/oracle/product/19.0.0.0/dbhome_1 where CLUSTERNAME=cluster1 Deploying ADD DATABASEHOME Validating Oracle Home.. Checking to see if /u01/app/oracle/product/19.0.0.0/dbhome_1 is already mounted Validating kvmutils rpm.. Validating required files… Extracting files.. Copying files… SUCCESS: Target Database Home /u01/app/oracle/product/19.0.0.0/dbhome_1 is not already mounted. SUCCESS: Local file db-klone-Linux-x86-64-19000190416.zip is successfully copied to celda01.promnet.com.sv as user root to /EXAVMIMAGES/ as db-klone-Linux-x86-64-19000190416.zip SUCCESS: Local file db-klone-Linux-x86-64-19000190416.zip is successfully copied to celda02.promnet.com.sv as user root to /EXAVMIMAGES/ as db-klone-Linux-x86-64-19000190416.zip Validations completed successfully. Creating new disk image file.. Attaching disk image to Virtual Machine exa0001nodo2.promnet.com.sv Attaching disk image to Virtual Machine exa0002nodo2.promnet.com.sv Completed setting up additional Oracle Home on Cluster cluster1 Configuring database home software, database home CliDbHome_0 Relinking database software.. Completed configuration of database home software [/u01/app/oracle/product/19.0.0.0/dbhome_1] on Cluster cluster1 Done… Done oedacli> oedacli> oedacli>
Después de esta operación el OH RDBMS habría sido desplegado en los clusters de BD que para el caso son KVM Guest en el Exadata DAtabase Machine en todos los nodos que componente el cluster.
Una operación muy valorada en casos de emergencia que Dataguard nos brinda es el Failover.
Primero refresquemos las actividades y operaciones de cambio de ROL que permite Oracle Dataguard, (A veces usan la palabra Conmutación)
Switchover y Failover
En el Switchover, el cambio o transición de rol es de forma controlada, no hay perdida de datos y puede ser reversible mas fácil que en el Failover.
No hay perdida de datos porque el motor espera hacer permanente la ultima transacción posible y luego desencadena la acción.
Como la imagen muestra el estado antes
El estado después, de forma controlada, esto permite ventajas en caso de mantenimientos de sitio sin impactar aplicaciones 0 o nada, de forma transparente, obvio depende como se hayan configurado las capas de aplicación, por lo cual se sugiere usar la Guia de Oracle para configuración de FailOver Client Connectivity.( https://www.oracle.com/technetwork/database/availability/client-failover-2280805.pdf).
Para el caso del Failover, el cambio o transición de sitio no es controlado, o casi nunca es por un evento controlado.
En este caso puede desencadenarse automáticamente usando Fast Start Failover o de forma manual.
De forma manual , puede realizarse con la BD Primaria encendida y funcionando (lo cual no es nada recomendable, pero en este escenario es el que demostraremos en este articulo), o con el sitio primario sin poder operar.
Vamos a usar el Dataguard Broker, uno de los tools mas usados y que mas me gusta después del SQLPLUS obviamente.
La documentación del broker esta disponible públicamente en:
Como sabemos después de un failover, la EX BD primaria queda inoperante o por lo menos no quedara con la versión mas fresca o reciente de los datos, porque en la lógica de operación las Apps se conectaran al sitio remoto con la EX Standby ahora Primaria.; esto significa que se debería volver a hacer un backup de la nueva primaria, trasladarse al sitio remoto y realizar todos los pasos que el dataguard exige.
Pero el enfoque del articulo es una forma de que la Ex primaria pueda “re” incorporarse
Validamos que cumplimos el primer y quiza único requisito para facilitar el “Re”ensamblaje de la Base de Datos primaria( esto en la documentacion le llaman REINSTATE).
Tener activado el Flashback Database en ambos sitios.
Valga el comercial, recuerden pueden montar todo tipo de laboratorios en OCI Always FREE, los primeros 30 días se poseen 300 USD de saldo para utilizarse.
La Nota de MOS indica el paso tambien para reinstanciar la Ex Primaria como Nueva replica.
Step by Step Guide on How To Reinstate Failed Primary Database into Physical Standby (Doc ID 738642.1)
Primer paso validamos la configuración, para nuestro escenario la primaria se encuentra ejecutándose con normalidad.
Validamos el GAP y es 0
Verificamos la replica si se encuentra lista para Switchover y failover y nos informa que si, inclusive nos avisa que el failover se puede, pero que la primaria esta ejecutandose.
Realizamos el failover manual de forma satisfactoria, para nuestro caso la Nueva Ex primaria no se apaga, debemos apagarla manual, yo hice un shut abort.
La nueva Primaria esta lista para brindar servicio y admitir conexiones.
El broker nos indica que la ex primaria necesita ser reinstanciada.
y es deshabilitada de la configuración, en este momento estamos des protegidos ante la perdida de la primaria.
Validamos que la Ex primaria se encuentra ya montada para proceder con el ensamblaje.
Siempre con el broker lanzamos el comando para el reinstatement.
Una vez se completa con exito, procedemos a validar la configuracion
De esta manera reconstruimos la configuración de dataguard fácilmente y recuperamos la protección que la característica de Base de Datos Oracle nos permite.
A veces, es necesario saber el valor de un parámetro oculto, especialmente cuando no se ha establecido un valor especifico,.
NOTA: esto no quiere decir que debemos andar estableciendo parámetros ocultos sin previa autorización o un ámbito de experiencia alta para dicho tipo de parámetros.
Establecemos una serie de opciones de sqlplus para pintar correctamente los datos, lo mas correcto.
Debemos hacerlo en sqlplus porque las vistas solo SYS las conoce .
Vamos a iniciar con una consulta de parámetro mediante la forma tradicional con show parameter
Como pudimos observar el parámetro oculto, _undo_debug_mode, no aparece.
Ahora vamos a consultar el valor del parámetro default, que muy probablemente esta en valor default, al solicitar el parámetro ingresamos:_undo_debug_mode
ahora aparece su valor, indica si es default , en sesión, ajustable dinámicamente
Aparece varias veces la salida porque en la DB que ejecute la prueba es una CDB con 3 PDBS( 3 de usuario incluyendo la seed).
Ahora establezco el de forma normal y veamos
ya se puede consultar mediante la forma estandar:
También al consultarlo mediante el query de vista de SYS aparece su valor.
Otra forma de consultar el valor de parámetros ocultos ya establecidos o utilizados en una instancia, es generando un pfile y consultando su valor con more/notepad o vi.
En algunas situaciones necesitamos que no se nos llene el buzón de Correo con alertas de destinos del OEM, especialmente cuando ya sabemos que habría una desconexión por algún mantenimiento, esto se logra con una interrupción, o blackout.
Las alertas de las que hablo son como estas:
Vamos a configurar una interrupción,
Para acceder a las interrupciones se logra mediante el menu Enterprise.
Agregamos o modificamos una regla existente, para el caso agregaremos una regla nueva que indica que los destinos a los cuales se les aplica, no seran informados (mas si monitoreados) si hay un cambio de estado que el mas común es Iniciado a Detenido (Stop)
También podemos decir si la regla de interrupción se aplicara una vez o de forma programada N veces al dia o N dias a la semana de forma mas periódica.
Ciando la regla se ha terminado los destinos que seran ignorados en el alertado se observan con un icono de una llavecita inglesa indicando que tiene un monitoreo con interrupción activo.
Vamos a validar que tenemos una regla de incidente que enviara una alerta.
Apagamos la BD para validar el estado:
Apagando…
En el OEM: puede observarse que el icono de estado cambio, y en lugar de ser una flecha roja con sentido de arriba hacia abajo es la llave con flecha roja.
Al encender la Instancia y la BD estar accesible,
El OEM detecta rápidamente el cambio de estado y lo informa en su dash board.
Esta opción del OEM (que nunca deja de sorprendernos con sus fabulosas opciones), es genial para eventos en los que sacaremos destinos del estado UP o correcto por mantenimientos programados y evitar que generen listas de correo innecesarias o indeseadas.
Configuring the sqlnet.ora File for a Software Keystore Location
Use the sqlnet.ora file to configure the keystore location for a regular file system, for multiple database access, and for use with Oracle Automatic Storage Management (ASM).
To create a software keystore on a regular file system, use the following format when you edit the sqlnet.ora file:
Procedemos a crear el wallet para usarlo como keystore con su respectivo password.el wallet puede crearse con autologin.
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/backup/wallet' IDENTIFIED BY password;
OR
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/backup/wallet/' IDENTIFIED BY password;
También debe crearse la clave maestra:
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY password WITH BACKUP USING 'backup' ;
Debe asegurarse tener el compatible en 12.1, recuerde que el compatible no tiene nada que ver con el performance de query, trata de la activación de características de la edición de la BD, un parámetro estático e irreversible.
compatible >=12.1
Para evitar olvidar abrir el wallet cada vez que la bd se reinicia, se puede configurar el autologin.
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE '/backup/wallet' IDENTIFIED BY password;
Vamos crear un tablespace y una tabla para la demostración, que permitirá examinar el contenido de un tablespace/datafile y comprobar el beneficio de la característica.
CREATE TABLESPACE encrypt_ts DATAFILE '/backup/oradata/encrypt_df.dbf' SIZE 1M ENCRYPTION USING 'AES256'
emrep:oracle@emcc:/bkp/oradata> strings nonencrypt_df.dbf | more
SQL> create table dba_copia3 tablespace users as select * from dba_objects;
Table created.
SQL>
SQL> set linesize 200
1* select tablespace_name,segment_name from dba_segments where segment_name in ('DBA_COPIA1','DBA_COPIA2','DBA_COPIA3') group by tablespace_name,segment_name
SQL>
alter table DBA_COPIA3 move tablespace ENCRYPT_TS;
Table altered.
SQL>
SQL> select tablespace_name,segment_name from dba_segments where segment_name in ('DBA_COPIA1','DBA_COPIA2','DBA_COPIA3') group by tablespace_name,segment_name;
Podemos ver los archivos que componen el wallet, que son el propio wallet y el archivo del autologin, p12 y sso.
emrep:oracle@emcc:/bkp/wallet> ls -lrt
total 12
-rw-r–r–. 1 oracle oinstall 2400 Jun 27 16:20 ewallet_2024062716205812_bckupkey.p12
-rw-r–r–. 1 oracle oinstall 3848 Jun 27 16:20 ewallet.p12
-rw-r–r–. 1 oracle oinstall 3893 Jun 27 16:30 cwallet.sso
En este ejercicio vamos a ver los pasos para convertir una BD Noncdb de cualquier version hacia PDB , para el caso, si la DB es 12c y la CDB destino es 19c, obvio yo sugiero que hay hacer el upgrade primero.
Primero validamos todos los componentes se encuentran en estado valido y mas importante, esta cantidad de componentes debe ser igual a los componentes que la CDB tiene instalados y funcionando.
— Si es RAC asegurarse de tener solo una instancia encendida, asegurarse de que el OMF el db_create_file_dest este definido apuntando al diskgroup.
Procedimiento
Existen varias formas de pegar una NonCDB a PDB,
Copia , el método de copia se asegura de dejar la BD original intacta pero es mas tardado. El Reuso, método de reuso no tiene punto de retorno, pues utiliza los datafiles actuales.
Para realizar el procedimiento de reuso de archivos.
Procedimiento de clonación en bd01
1 Apagamos la BD y la ponemos en Read ONLY para que el SCN en la cabecera de todos los datafiles este sincronizado al mismo valor con el control file.
export ORACLE_SID=bd01
sqlplus / as sysdba
SHUTDOWN IMMEDIATE;
STARTUP OPEN READ ONLY;
2 crear manifiesto el archivo que contiene el descriptivo de la bd sus datafiles, objetos, SCN , etc etc.
BEGIN DBMS_PDB.DESCRIBE( pdb_descr_file => ‘/tmp/bd01.xml’); END; /
En este caso activamos el modo archive, y creamos los redolog de 4g porque estaban de menos tamaño.
3 shutdown bd01
export ORACLE_SID=db12c sqlplus / as sysdba SHUTDOWN IMMEDIATE;
4 en cdb destino
Observar la respuesta de YES en el plsql anónimo siguiente:
SET SERVEROUTPUT ON;
DECLARE
compatible CONSTANT VARCHAR2(3) := CASE DBMS_PDB.CHECK_PLUG_COMPATIBILITY(pdb_descr_file => '/tmp/bd01.xml')
WHEN TRUE THEN 'YES'
ELSE 'NO'
END;
BEGIN
DBMS_OUTPUT.PUT_LINE(compatible);
END;
/
SQL> SQL> 2 3 4 5 6 7 8 9 YES
5. Para chequear imcompatibilidad de PDB a pegar
SQL> select message from PDB_PLUG_IN_VIOLATIONS where type='ERROR' and status ='PENDING';
no rows selected
6. Revisar los dbfiles de la cdb destino para que pueda albergar los datafiles que vienen de la NONCDB.
show parameter db_file, si no es suficiente aumentar valor
NOTA CREATE PLUGGABLE DATABASE pbd01 USING ‘/tmp/bd01.xml’ nocopy;
LEER ADENDA AL FINAL
Cuando se ocupa nocopy en la sentencia de create plugable database, los tempfile si estan en asm u OMF daran error
1>CREATE PLUGGABLE DATABASE pbd01 USING '/tmp/bd01.xml' nocopy;
CREATE PLUGGABLE DATABASE pbd01 USING '/tmp/bd01.xml' nocopy
*
ERROR at line 1:
ORA-27038: created file already exists
ORA-01119: error in creating database file
'
Solucion ver documento: “Failure In Creating PDB With Temp Files Stored In ASM / OMF Format From Non-CDB Using NOCOPY Option (Doc ID 2778041.1)” Below bug was opened with our development team:
BUG 26621022 – NEW TEMPFILES ARE CREATED NOT REUSED USING CREATE PLUGGABLE ..TEMPFILE REUSE Above bug was closed by our development team stating it as expected behavior. In order to resolve this issue, we can use either of below solutions: Make sure sufficient free space available in the desired ASM disk group or filesystem (in case of OMF). or Delete the TEMP tablespace temp files from source Non-CDB database environment after generating the XML file and then shutting down the Non-CDB database.
Hay que borrar los tempfiles de la bd origen en el FS datastore después de generar el xml, después de apagar la instancia y antes de pegarla en la cdb
Query para monitorear avance de copia en CDB
select opname, sid, serial#, sofar, totalwork, time_remaining,time_remaining/60 fm,time_remaining/60/60 fh, message from v$session_longops where time_remaining > 0;
7. Cuando termine, se abre la PDB recién pegada
alter pluggable database pbd01 open;
alter session set container=pbd01 ;
8.Validar violación al pegar pdb
No debe devolver filas, si hay filas debe analizarse cada situación contra MOS.
column message format a50 column status format a9 column type format a9 column con_id format 9 select con_id, type, message, status from PDB_PLUG_IN_VIOLATIONS where status='PENDING' and type='ERROR' and con_id=3 order by time;
SQL> SQL> SQL> SQL> 2 3 4 no rows selected
9.Script de no marcha atrás: finalización de paso a PDB.
Este script se asegura de crear el diccionario de datos de los objetos permisos, etc que vienen de la NONCDB a PDB.
Yo no se pero en mi experiencia aun hay cositas que le faltan pulir a la PDB , aun en 19c.
@?/rdbms/admin/noncdb_to_pdb.sql
——- el TEMPFILE debe tener espacio suficient een la pdb. mas de 5g. 64GB en PDB y 32Gb en CDB y 20GB al tempo. –para ejemplo:
alter database tempfile '+dg/tempfile.2.1106479113' resize 31g;
10.Validar fallas en pegado y script final
No debe devolver filas
Observese que hay restricciones de OPEN MODE
2 PDB$SEED READ ONLY NO
3 pbd01 MIGRATE YES
SQL> column message format a50 column status format a9 column type format a9 column con_id format 9 select con_id, type, message, status from PDB_PLUG_IN_VIOLATIONS where status='PENDING' and type='ERROR' and con_id=3 order by time;SQL> SQL> SQL> SQL> 2 3 4
no rows selected
SQL> alter session set container=pbd01;
Session altered.
SQL> column message format a50 column status format a9 column type format a9 column con_id format 9 select con_id, type, message, status from PDB_PLUG_IN_VIOLATIONS where status=’PENDING’ and type=’ERROR’ and con_id=3 order by time;SQL> SQL> SQL> SQL> 2 3 4
no rows selected
11. validar open mode y que este RW sin restricciones
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production Version 19.12.0.0.0
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
2 PDB$SEED READ ONLY NO
3 pbd01 READ WRITE NO
SQL> alter session set container=pbd01;
Session altered.
PASO MIL.
Abrir la PDB en RW en todos los nodos en todas las instancias si fuera RAC y guardar el estatus.
alter pluggable database pbd01 open instances=all; alter pluggable database pbd01 save state instances=all; Pluggable database altered.
SQL> show pdbs;
CON_ID CON_NAME OPEN MODE RESTRICTED
2 PDB$SEED READ ONLY NO
3 pbd01 READ WRITE NO
Espero les sea de utilidad
ADENDA
Puede usarse la instrucción de pegado que pega copiando los datafiles, dejando los originales intactos, esto facilita un método de reversa sin restaurar de backup.
Siguiendo con la serie de artículos de seguridad en la Base de Datos Oracle, vamos a tratar el tema de la seguridad de los datos en el trafico de red.
En un entorno natural en el que se ve involucrada una Base de Datos Oracle, la comunicación es siempre establecida usando el protocolo OracleNet que no es mas que el trafico basado en TCP, por lo cual dicho trafico puede interceptarse por un agente externo no autorizado y descifrar el contenido y hacerlo legible con el objetivo de extraer informacion de forma no autorizada.
Existen mas de un método para cifrar el trafico que se consume de una base de datos Oracle, pero nos centraremos en el ofrecido de forma nativa por Oracle Database: Native Network Encryption.
Al aplicar dicha configuración el flujo de trafico se denota porque no puede leerse dado que ya no viaja plano si no cifrado.
Vamos a validar, me conecto a una BD remota en la Nube de Oracle, no precisamente el funciona solo a dicho tipo de plataformas, pero todavía es una mejor prueba dado que el trafico va por internet.
Ejecuto un SQL a una tabla y observamos sus filas devueltas.
Durante reejecute los statements, previamente active el sniffer para capturar paquetes TCP, mi ambiente es OSX y use tcpdump, para linux funcionaria, para Solaris SNOOP, esta herramienta necesita activar el modo promiscuo de la interfaz y necesita privilegios elevados.
Aquí envíe el trafico capturado al archivo channel-11
El contenido del archivo de trafico se observa así, lo cual personal de redes puede entenderlo mejor, pero aun así no cumple el objetivo en el entendimiento de las tramas para mi Demostración.
Para nuestro caso, utilice una herramienta un poco mas avanzada llamada WireShark ( Un compañero de Redes me enseño a usarla).
Resultado de las filas
Como puede observarse abajo del lado derecho en la imagen de arriba, puede observase el resultado de las filas, de la misma forma puede observarse las encabezados de columnas, el statement o instrucción enviada al motor y de la misma forma, usuarios y passwords.
Para configurar la opción del lado del motor, es tan simple como agregar un parametro en el sqlnet.ora en el $OH del RDBMS.
Encryption_server y types_server para controlas el algoritmo.
Del lado del cliente también debe configurarse la opción:
Hay que denotar las palabras clave required y requested.
Requerido del lado del motor obligara que todas las conexiones obliguen al cifrado en el ingreso de la sesión; solicitado, permitirá aceptar conexiones cifradas y no cifradas.
Al activar la característica, y volver a examinar el trafico de red, ya no logramos leer los paquetes ya muestra texto ilegible.
Algo Importante la característica Native Network Encryption es gratis desde 11.2, ya no forma parte de la opción Advanced Security Option (ASO).
Puede leerse del sitio de información de licenciamiento.
Es una característica de Base de Datos que permite colocar un lente ( así lo llamo yo) enfrente de los datos, dicho lente permite que se observen los datos reales o no, dependiendo el origen de la conexión, el usuario que consulta, etc etc, siendo las propiedades de la sesión las posibles variables que permiten consultar los datos al natural redactados.
Usuarios autorizados de consulta podrán observar los datos de forma normal , mientras los que no, observaran patrones generados con informacion totalmente transformada , parcial, etc, dependiendo del patron.
Existen diferentes tipos de patrones para la transformación ( porque eso es la redacción).
PERO HAY QUE HACER MENCION: LA REDACCION ES PURAMENTE VISUAL, TOTALMENTE ONLINE.
De la pagina de la documentación oficial:
Beneficios
Preparación de la DEMO:
Creamos 2 usuarios
--drop user testuser1 cascade;
create user testuser1 identified by testuser1 quota unlimited on users;
grant create session, create table to testuser1;
--drop user testuser2 cascade;
create user testuser2 identified by testuser2 quota unlimited on users;
SQL*Plus: Release 19.0.0.0.0 – Production on Thu Jun 27 23:43:37 2024
Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Last Successful login time: Thu Jun 27 2024 23:42:59 +00:00
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 – 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options
alter session set nls_date_format=’dd-mon-yyyy’;
column card_no format 9999999999999999
set linesize 200
select *
from payment_details
order by id;
Desde el propio servidor de base de Datos
alter session set nls_date_format=’dd-mon-yyyy’;
column card_no format 9999999999999999
set linesize 200
select *
from payment_details
order by id;
I
Como pudo observarse la redacción es una característica bastante util, transparente a las aplicaciones sin implicaciones de cambio de código y sin implicaciones de no poder alterar los datos, forma parte de la opción Advanced Security Option, de pago extra sobre Licencia de EE.
Este articulo se centra en la activación de una de las características de seguridad de la base de datos Oracle Enterprise Edition, Transparent Data Encryption, de la documentación Oficial:
Como mucha característica EE, de paga extra por la metrica de licenciamiento x el # de licencias adquiridas, y replicable a Contingencia, ambientes de desarrollo previos si se utilizan copias de RMAN.
Como primer paso hay que configurar el wallet, en versiones anteriores se usaba solo el sqlnet.ora pero pude percatarme según la guía que ahora se ocupa un parámetro de BD.
De la documentación, el wallet nos sirve para almacenar las claves de encriptación maestras y puede almacenarse en varios lados,
La encriptación puede hacerse a nivel de Columna o tablespace, se recomienda de tablespace porque es menos impactante en la operación que la de columnas.
La de columna encripta y decripta al momento de DMLs, la de tablespace no.
El funcionamiento de la encriptación de tablespaces con la llave maestra y su interacción con el wallet.
El wallet por defecto es un keystore que almacenara la información que permitirá encriptar y desencriptar los datos de la BD.
Solicitado por Luis Caballero, asegurese que el Keystore es autologin y no Local autologin , porque dicho WALLET agrega una validacion de HOST que no permite usarse en diferente maquina, ni siquiera en un Oracle RAC.
These keystores are as follows:
Auto-login TDE wallets: Auto-login TDE wallets are protected by a system-generated password, and do not need to be explicitly opened by a security administrator. Auto-login TDE wallets are automatically opened when accessed at database startup. Auto-login TDE wallets can be used across different systems. If your environment does not require the extra security provided by a keystore that must be explicitly opened for use, then you can use an auto-login TDE wallet. Auto-login TDE wallets are ideal for unattended scenarios (for example, Oracle Data Guard standby databases).
Local auto-login TDE wallets: Local auto-login TDE wallets are auto-login TDE wallets that are local to the computer on which they are created. Local auto-login keystores cannot be opened on any computer other than the one on which they are created. This type of keystore is typically used for scenarios where additional security is required (that is, to limit the use of the auto-login for that computer) while supporting an unattended operation. You cannot use local auto-open wallets in Oracle RAC-enabled databases, because only shared wallets (in ACFS or ASM) are supported.
Password-protected TDE wallets: Password-protected TDE wallets are protected by using a password that you create. You must open this type of keystore before the keys can be retrieved or used and use a password to open this type of keystore.
ALTER SYSTEM SET WALLET_ROOT = '/bkp/wallet' SCOPE = SPFILE SID = '*';
ALTER SYSTEM SET TDE_CONFIGURATION="KEYSTORE_CONFIGURATION=FILE" SCOPE = BOTH SID = '*';
Luego de esto debemos configurar el password del keystore donde guardaremos la clave de encriptación maestra:
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE IDENTIFIED BY password;
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE IDENTIFIED BY password;
Una vez configurado, se debe abrir el wallet para permitir operaciones de encriptación de columnas o tablespaces.
OJO o NOTA:DEBE CUIDARSE LA LLAVE MAESTRA PORQUE PUEDE SIGNIFICAR LA PERDIDA DE LA BD.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY password;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN
FORCE KEYSTORE
IDENTIFIED BY EXTERNAL STORE;
Una vez se ha creado el wallet y aperturado, este puede consultarse su estado en esta vista:
select * from V$ENCRYPTION_WALLET;
Una vez tenemos abierto el Wallet y clave maestra asignada, podemos encriptar ya sea columnas o tablespaces, mi ejemplo en este articulo es para tablesapaces completos.
Ejecutamos la encriptación Online, lo cual requiere tanto espacio para la creación temporal de o los archivos ya cifrados.
ALTER TABLESPACE users ENCRYPTION ONLINE ENCRYPT ;
Con una exploración en el Sistema Operativo podemos ver que el contenido del datafile del tablespace se vuelve ilegible y sin posibilidad de realizar ingeniería inversa.
Pero dirán, es un efecto simulado, vamos a probar algo para demostrar la característica,
create tablespace demo datafile '/bkp/oradata/orclcdb/demo01.dbf' size 10m autoextend on next 50m;
alter tablespace demo add datafile '/bkp/oradata/orclcdb/demo02.dbf' size 10m autoextend on next 50m;
create table dba_copia8 tablespace demo as select * from dba_objects;
SQL> select ENCRYPTED,tablespace_name from dba_tablespaces;
ENC TABLESPACE_NAME
— ——————————
YES SYSTEM
YES SYSAUX
YES UNDOTBS1
NO TEMP
YES USERS
YES NEW_UNDO_TS
YES ENCRYPT_TS
NO DEMO
8 rows selected.
SQL>
Antes
Quiero resaltar el hecho que en el listado de resultado del select anterior, el datafile single del tablespace DEMO indica aun no esta encriptado.
Al consultar el contenido del datafile, de forma no autorizada con un tool del Sistema operativo, puede consultarse el contenido bastante legible en Humano.
Despues
ALTER TABLESPACE demo ENCRYPTION ONLINE ENCRYPT ;
Ya al volver a consultar el contenido del datafile ya aparece encriptado.
Y una vez un tablespace ha sido encriptado, todo datafile que se agregue o crezca no pierde dicha propiedad y contenido protegido.
alter tablespace demo add datafile ‘/bkp/oradata/orclcdb/demo03.dbf’ size 10m autoextend on next 50m;
insert into dba_copia8 select * from dba_objects;
Por ultimo, la propiedad de encriptado o cifrado puede revertirse en caso de ser necesario de la misma forma
