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
La integración de sistemas es una parte crucial para el correcto funcionamiento de los mismos, los sistemas no son islas que no tienen comunicación con otros sistemas internos y/o externos en nuestras empresas.
Esta integracion puede hacerse con capas de software sofisticadas como un BUS de Servicios etc, pero tambien puede hacerse desde dentro de la poderosisima Oracle Database.
Cuando el consumo esta en HTTP no es problema alguno, pero pongamosle una variable HTTPS, la cosa cambio.
Para solventar dicho impase, necesitamos 3 cosas
1)Un WALLET
2)El certificado de sitio del webservice.
3)Un Procedimiento de prueba para validar el funcionamiento.
Anotados los pasos
Definir el sitio o servicio web a consumir, para el caso usaremos https://www.oracle.com
0) Descarga del certificado para el laboratorio
Dirigirse al sitio, usar chrome de preferencia
Validar la información del sitio seguro
Validar la información del certificado
Cambiarse a la pestaña detalles, seleccionar ROOT arriba y abajo
Click en exportar y guardar con este nombre sitecertify.crt
Trasladar al servidor de base de datos donde se usara.
1) Creacion de un folder que contendra el wallet
El wallet no es nada más que eso , una cartera para guardar identidades.
2)Creacion del wallet con el tool orapki, existen mas tools para crear wallets, este está incluio varios productos Oracle.
[oracle@~]$ orapki wallet create -wallet /U01/app/oracle/admin/DB11G/wallet -pwd WalletPasswd123 -auto_login Oracle PKI Tool : Version 11.2.0.3.0 - Production Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
3) Importacion del certificado en base 64 (x509 ) del sitio web o del sitio que contiene el servicio en SSL usualmente se puede obtener del navegador cargando el sitio web, o con wget o CURL en un unix/linux
[oracle@~]$ orapki wallet add -wallet /U01/app/oracle/admin/DB11G/wallet -trusted_cert -cert "/home/oracle/sitecertify.crt" -pwd WalletPasswd123 Oracle PKI Tool : Version 11.2.0.3.0 - Production Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.
los datos que se usaran dentro del plsql o bloque anonimo, ruta del wallet y password.
Requested Certificates: User Certificates: Trusted Certificates: Subject: CN=DigiCert Global Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US
5)y así la forma de invocarlo con un select sin bloque anonimo ni plsql.
SIN USAR EL WALLET: SQL> select utl_http.request('https://www.oracle.com', null,NULL,NULL) from dual; select utl_http.request('https://www.oracle.com', null,NULL,NULL) from dual * ERROR at line 1: ORA-29273: HTTP request failed ORA-06512: at "SYS.UTL_HTTP", line 1530 ORA-29024: Certificate validation failure ORA-06512: at "SYS.UTL_HTTP", line 380 ORA-06512: at "SYS.UTL_HTTP", line 1470 ORA-06512: at line 1
usando el wallet
SQL> SET SERVEROUTPUT ON
select utl_http.request('https://www.oracle.com', null,'file:/U01/app/oracle/admin/DB11G/wallet','WalletPasswd123') from dual; SQL>
Instalación de Grid Infraestructure Oracle Restart en modo Silent 19c.
Esta guia complementa la serie de guias en modo no interactivo o silencioso como el caso del Clusterware 19c (https://www.linkedin.com/posts/ra%C3%BAl-antonio-molina-alvarenga-ocm-107b70b5_instalaci%C3%B3n-de-oracle-clusterware-y-oracle-activity-7096850034285006848-DsBD?utm_source=share&utm_medium=member_desktop).
Descargar el instalador que termina en grid_home.zip No usar el RPM
Para mi caso como estoy en una VM en la Nube de OCI , decsargue el ZIP usando wget, puede leerse de este otro articulo (https://www.linkedin.com/pulse/como-facilitar-la-descarga-de-instaladores-producto-ra%2525C3%2525BAl-antonio%3FtrackingId=gI%252BPQmIimPv0CIqefu0odA%253D%253D/?trackingId=gI%2BPQmIimPv0CIqefu0odA%3D%3D).
Podemos realizar la preparación con el modo automatico usando el rpm de pre rdbms o todos los pasos a mano, para el caso haremos todos los pasos a mano.
Este ultimo parametro (net.ipv4.ip_local_port_range = 9000 65500 ), puede o debe ser ajustado cuando hay instalaciones de Netbackup para respaldos de la vm o de la bd.
Moverse al directorio Desempacar software, yo puse el zip en /bkp, No olvidar cambiarse de usuario (su – grid) para las tareas del dueño del software , en mi caso es NUBE y no tengo forma de conectarme directamente, logeo con OPC con la PPK y luego salto a root y salto a grid.
cd /u01/app/19.0.0/grid/ unzip /bkp/gi19.zip
Guardar como grid.rsp en /home/grid
usaremos la forma silent con modo de solo instalación, configuraremos a manual el software para los componenes del oracle restart
[WARNING] [INS-32020] Installer has detected that the available disk space on the volume for the specified Oracle base location (/u01/app/grid) is less than the recommended value. ACTION: It is recommended that the volume for the Oracle base have at least 10 GB of available disk space. Choose a location that has sufficient available disk space or free up space on the existing volume. [WARNING] [INS-30100] Insufficient disk space on the selected location (/u01/app/19.0.0/grid). CAUSE: Specified location is on a volume without enough disk space on nodes: [instance-20231030-1410]. ACTION: Choose a location that has enough space (minimum of 6.9 GB) or free up space on the existing volume.
The response file for this session can be found at: /u01/app/19.0.0/grid/install/response/grid_2024-01-29_10-45-29PM.rsp
You can find the log of this install session at: /opt/oracle/oraInventory/logs/GridSetupActions2024-01-29_10-45-29PM/gridSetupActions2024-01-29_10-45-29PM.log
As a root user, execute the following script(s): 1. /u01/app/19.0.0/grid/root.sh
Execute /u01/app/19.0.0/grid/root.sh on the following nodes:
Successfully Setup Software with warning(s).
Ejecutar los scripts de root que indique el aviso.
[root@instance-20231030-1410 ~]# /u01/app/19.0.0/grid/root.sh Check /u01/app/19.0.0/grid/install/root_instance-20231030-1410_2024-01-29_22-49-03-943784137.log for the output of root script
Vamos a configurar los demonios del oracle restart con este script:
/u01/app/19.0.0/grid/crs/install/roothas.sh Using configuration parameter file: /u01/app/19.0.0/grid/crs/install/crsconfig_params The log of current session can be found at: /u01/app/grid/crsdata/instance-20231030-1410/crsconfig/roothas_2024-01-29_10-50-34PM.log
instance-20231030-1410 2024/01/29 22:51:16 /u01/app/grid/crsdata/instance-20231030-1410/olr/backup_20240129_225116.olr 724960844 2024/01/29 22:51:17 CLSRSC-327: Successfully configured Oracle Restart for a standalone server
Vamos a configurar las variables de ambiente para el Usuario dueño de la capa de software de GI.
vi .bash_profile export ORACLE_HOME=/u01/app/19.0.0/grid export PATH=$ORACLE_HOME/bin:$PATH export ORACLE_SID=+ASM
Cargar variables con . .bash_profile o iniciando sesion de nuevo
Consultar el estado de los componentes del oracle restart.
Nomenclatura permanente de los discos.
Se puede usar la guia para configuración de dispositivos con reglas permanentes (https://www.linkedin.com/pulse/reglas-de-udev-para-discos-asm-en-linux-aplica-rhel-y-ra%2525C3%2525BAl-antonio-%3FtrackingId=93UVkvP7bCQic0Q3efn4hA%253D%253D/?trackingId=93UVkvP7bCQic0Q3efn4hA%3D%3D)
Antes en versiones anteriores de RHEL o OEL, preferia usar el driver ASMLIB para el nombrado y permanencia de los dispositivos de Disco, pero en RHEL8.x ya no funciona y me quede esperando la version 3.x del driver, aun no me gusta usar AFD asi, que , prefiero usar Reglas de UDEV.
Consultar discos
fdisk -l | grep Disk | grep bytes
Disk /dev/sda: 50.0 GB, 50010783744 bytes, 97677312 sectors Disk /dev/sdb: 53.7 GB, 53687091200 bytes, 104857600 sectors Disk /dev/sdc: 53.7 GB, 53687091200 bytes, 104857600 sectors –> nuestro disco
vi /etc/udev/rules.d/96-asm.rules Grabamos y salimos
Recargamos la regla de udev para control de dispositivos de disco:
udevadm control –reload-rules udevadm trigger –type=devices –action=change
Encontramos el disco ya [root@instance-20231030-1410 ~]# ls -lL /dev/oracleasm/ total 0 brw-rw—-. 1 grid asmadmin 8, 32 Jan 30 01:21 ASM1 [root@instance-20231030-1410 ~]#
Como vimos ya tiene los permisos que todo device de asm debe tener desde 11.2, 660 y grid:asmadmin
Lo usamos:
establecemos la propiedad de discos para su descubrimiento en la ruta que la regla de udev lo dejo
Last login: Mon Jan 29 22:54:44 GMT 2024 on pts/0 [grid@instance-20231030-1410 ~]$ sqlplus / as sysasm
SQL*Plus: Release 19.0.0.0.0 – Production on Tue Jan 30 01:22:35 2024 Version 19.3.0.0.0
Copyright (c) 1982, 2019, Oracle. All rights reserved.
Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production Version 19.3.0.0.0
SQL> show parameter string
NAME TYPE VALUE
asm_diskstring string SQL> alter system set asm_diskstring=’/dev/oracleasm/*’;
System altered.
SQL> select path from v$asm_Disk;
PATH
/dev/oracleasm/ASM1
SQL>
Crear diskgroup
SQL> create diskgroup data external redundancy disk ‘/dev/oracleasm/ASM1’;
Un día de estos me cruce con una situación en la que obtuve corrupción de bloques en una BD productiva muy grande e importante, bastante preocupante la situación, no daré detalles, pero se estuvo bajo mucha presión (LOL).
Porque es importante tener todos los bloques de datos marcados como limpios y no como corruptos?, obvio el acceso a los datos y el uso de indices.
Pero porque es importante limpiar bloques vacios?, porque a pesar de ser bloques vacios, el diccionario los conoce como corruptos y no se puede tener un backup rman 100% fiable.
Dicho esto, Lo importante en la definición de la solución fue lo siguiente para solventar corrupción en:
Bloques de datos en tablas , poder prescindir de ellos, o restaurar de un backup la tabla
Bloques de datos en indices, reconstruir el indice
Bloques Vacíos, yo pensaba que era solo ignorarlos, pero no.
En este ultimo aspecto, necesitaba se limpiaran, para poder dar el OK del datafile o de los datafiles afectados.
Encontré una nota de MOS:
Use RMAN to format corrupt data block which is not part of any object (Doc ID 1459778.1)
Haciendo la revision se encontro que los bloques que aparecen marcados como corruptos, son bloques vacios.
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
—- —— ————– ———— ————— ———-
68 FAILED 0 129 4194293 10192968188924
File Name: /archives/datafile_archivo_datats_12
Block Type Blocks Failing Blocks Processed
———- ————– —————-
Data 1 3443658
Index 0 461648
Other 29 288837
validate found one or more corrupt blocks
See trace file /u01/app/oracle/diag/rdbms/bd/BD/trace/BD_ora_21367.trc for details
