<![CDATA[DBA en la SOMBRA]]>https://dbaenlasombra.comRSS for NodeSat, 11 Apr 2026 14:24:56 GMT60<![CDATA[[26ai] Hybrid Read-Only Mode PDB]]>https://dbaenlasombra.com/26ai-hybrid-read-only-mode-pdbhttps://dbaenlasombra.com/26ai-hybrid-read-only-mode-pdbThu, 09 Apr 2026 23:18:40 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy, vamos a ver el nuevo open-mode introducido en 26ai denominado Hybrid Read-Only .

Cuando usamos este modo, el common user seguirá teniendo acceso read-write, mientras que el local user solo tendrá acceso read-only.

Sin más, vamos a ello.

El primer paso es definir una nueva PDB.

SQL> CREATE PLUGGABLE DATABASE PDB_HYBRID ADMIN USER admin IDENTIFIED BY admin keystore identified by external store;

Pluggable database created.

SQL> ALTER PLUGGABLE DATABASE  PDB_HYBRID OPEN;
Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE  PDB_HYBRID SAVE STATE;
Pluggable database altered.

Definimos los diferentes usuarios:

SQL> CREATE USER c##hybrid IDENTIFIED BY "XXXXXXX";
User created.
SQL> GRANT DBA TO c##hybrid CONTAINER=ALL;
Grant succeeded.

SQL> alter session set container=pdb_hybrid;
SQL> create smallfile tablespace tb1 
      datafile size 1m autoextend on maxsize 10m;

Tablespace created.

SQL> CREATE USER hybrid IDENTIFIED BY "XXXXXXX"
  DEFAULT TABLESPACE tb1
  TEMPORARY TABLESPACE temp
  QUOTA UNLIMITED ON tb1;  

User created.

SQL> GRANT DBA TO hybrid;

Grant succeeded.

Perfecto, ya tenemos definidos tanto el common user (c##hybrid) como el local user (hybrid).

Antes de abrir la PDB con el nuevo estado, vamos a conectarnos con el usuario hybrid para definir un tabla con algo de información:

SQL> conn hybrid/"XXXXX"@X.X.X.X:1521/pdb_hybrid.XXXX.XXXX.XXXX.com
Connected.
SQL>      
SQL> 
 Create table T_TEST AS 
  SELECT OBJECT_NAME FROM ALL_OBJECTS;

Table created.

Nos conectamos a CDB$Root para poner en modo hybrid read-only la PDB.

SQL> alter pluggable database PDB_HYBRID close;

Pluggable database altered.

SQL> alter pluggable database PDB_HYBRID open hybrid read only;

Pluggable database altered.

SQL> r
    select con_name,
           open_mode,
           is_hybrid_read_only
    from   v$container_topology

CON_NAME             OPEN_MODE  IS_HYBRID_READ_ONLY
-------------------- ---------- --------------------
CDB$ROOT             READ WRITE NO
PDB$SEED             READ ONLY  NO
PDB_HYBRID           READ WRITE YES

Nos conectamos con el local user a la PDB e intentamos realizar operaciones DML (delete) y DDL (truncate).

SQL>  conn hybrid/"XXXXX"@X.X.X.X:1521/pdb_hybrid.XXXX.XXXX.XXXX.com
Connected.
SQL> set linesize 1000
SQL> col name format a20
SQL> select name, open_mode from v$pdbs;

NAME                 OPEN_MODE
-------------------- ----------
PDB_HYBRID           READ ONLY

SQL> delete T_TEST;
delete T_TEST
       *
ERROR at line 1:
ORA-16000: Attempting to modify database or pluggable database that is open for read-only access.
Help: https://docs.oracle.com/error-help/db/ora-16000/


SQL> truncate table T_TEST;
truncate table T_TEST
*
ERROR at line 1:
ORA-16000: Attempting to modify database or pluggable database that is open for read-only access.
Help: https://docs.oracle.com/error-help/db/ora-16000/

Han fallado ambas operaciones con el siguiente mensaje "ORA-16000: Attempting to modify database or pluggable database that is open for read-only access".

Ahora, nos conectamos con el common user y repetimos ambas operaciones.

SQL>  conn c##hybrid/"FJA_2026_Oracle19c" 
Connected.

SQL>  alter session set container=PDB_HYBRID;
Session altered.

SQL>  select name, open_mode from v$pdbs;

NAME                 OPEN_MODE
-------------------- ----------
PDB_HYBRID           READ WRITE

SQL> delete hybrid.T_TEST;

52165 rows deleted.

SQL> truncate table hybrid.T_TEST;

Table truncated.

Hemos podido hacer ambas operaciones.

Otro punto que hay que mirar es la v$pdbs, cuando estamos conectados con el local user el OPEN_MODE viene READ ONLY, en cambio, para el common user el valor es READ WRITE.

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] ALERT_LOG_MAX_SIZE]]>https://dbaenlasombra.com/26ai-alert-log-max-sizehttps://dbaenlasombra.com/26ai-alert-log-max-sizeFri, 03 Apr 2026 14:55:11 GMTEl artículo también se encuentra publicado en Ingles English version.

El artículo veremos un nuevo parámetro introducido en 26ai para poder gestionar de manera fácil y eficiente el tamaño del alert log, es alert_log_max_size.

El valor por defecto del nuevo parámetro es 1000Mb:

SQL>
SQL> show parameter alert_log_max_size

NAME               TYPE        VALUE
------------------ ----------- -------
alert_log_max_size big integer 1000M

SQL>

Oracle internamente gestiona el alert log en bloques de 50Mb, es decir, nunca vamos a ver un alert log con un tamaño de 1000M, sino que veremos 20 ficheros de 50Mb cada uno.

Este parámetro solo se puede modificar a nivel de CDB$Root,no a nivel de PDB:

SQL> ALTER SYSTEM SET ALERT_LOG_MAX_SIZE = 150M; 

ALTER SYSTEM SET ALERT_LOG_MAX_SIZE = 150M 
* 
ERROR at line 1: ORA-65040: Operation is not allowed from within a pluggable database.

Vamos añadir información en el alert log para ver cómo se comporta Oracle:

[oracle@~]cat save_inf.sql
begin 
declare 
 i number := 0; 
 begin 
  loop i := i + 1; 
  sys.dbms_system.ksdwrt(2, 'string(''L'',?)= ' || dbms_random.string('L',trunc(dbms_random.value(10,21)))); 
 exit when i >= 10000000; 
end loop; 
end; 
end; 
/
[oracle@~] 
 watch -n 10 "sqlplus -s / as sysdba @save_inf.sql"
[oracle@l23ai alert]$ ls -lash *xml 
51M -rw-r----- 1 oracle asmdba 51M Apr 2 18:11 log_1.xml 
51M -rw-r----- 1 oracle asmdba 51M Apr 2 18:11 log_2.xml 
46M -rw-r----- 1 oracle asmdba 46M Apr 2 18:11 log.xml

Como podemos observar el alert log se ha dividido en ficheros de 50Mb!.

Una pequeña puntualizacion del nuevo parámetro, si está seteado con valor 0, el alert log tendrá un crecimiento ilimitado del alert log.

Pero ¿Podemos cambiar el valor 50Mb a otro valor? La respuesta es sí. Con el parámetro oculto "_alert_segment_size" podremos controlar el tamaño.

SQL> ALTER SYSTEM SET "_alert_segment_size" = 30;
System altered.

SQL> show parameter "_alert_segment_size"

NAME               TYPE        VALUE
------------------ ----------- -------
_alert_segment_size integer     30

[oracle@l23ai ~]$ 
 watch -n 10 "sqlplus -s / as sysdba @save_inf.sql"
[oracle@l23ai alert]$ ls -lash *xml 
51M -rw-r----- 1 oracle asmdba 51M Apr 2 18:11 log_1.xml 
51M -rw-r----- 1 oracle asmdba 51M Apr 2 18:11 log_2.xml 
46M -rw-r----- 1 oracle asmdba 46M Apr 2 22:10 log_3.xml 
31M -rw-r----- 1 oracle asmdba 31M Apr 3 09:11 log_4.xml 
31M -rw-r----- 1 oracle asmdba 31M Apr 3 09:11 log_5.xml 
4.9M -rw-r----- 1 oracle asmdba 4.9M Apr 3 09:11 log.xml

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] ConnStr Tool]]>https://dbaenlasombra.com/26ai-connstr-toolhttps://dbaenlasombra.com/26ai-connstr-toolWed, 25 Mar 2026 18:41:01 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy, vamos a ver la nueva herramienta que se ha introducido en la 26ai ConnStr .

Es una herramienta command-line que sirve para mostrar las conexiones por cada servicio definido en nuestra base de datos en formatos Easy Connect, JDBC y Python, dándonos la posibilidad de incluir esa información dentro del tnsnames.

Otro punto que hay que tener en cuenta es que el listener debe estar levantado, sino nos dará error.

Sin más, vamos al lío.

Revisamos cómo se encuentra el listener:

[oracle@~]$ lsnrctl status
LSNRCTL for Linux: Version 23.26.0.0.0 - for Oracle Cloud and Engineered Systems on 25-MAR-2026 14:28:21

Alias LISTENER 
Version TNSLSNR for Linux: Version 23.26.1.0.0 - Production 
Start Date 09-MAR-2026 17:13:58 
Uptime 15 days 21 hr. 14 min. 23 sec 
Trace Level off 
Security ON: Local OS Authentication 
SNMP OFF 
Listener Parameter File /u01/app/23.0.0.0/grid/network/admin/listener.ora
Listener Log File /u01/app/grid/diag/tnslsnr/l23ai/listener/alert/log.xml
Listening Endpoints Summary... 
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER))) 
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=X.X.X.X)(PORT=1521)))

Services Summary... 
 Service "+APX" has 1 instance(s). 
Instance "+APX1", status READY, has 1 handler(s) for this service...
 Service "+ASM" has 1 instance(s). 
Instance "+ASM1", status READY, has 1 handler(s) for this service...
 Service "+ASM_DATA" has 1 instance(s). 
Instance "+ASM1", status READY, has 1 handler(s) for this service...
 Service "+ASM_RECO" has 1 instance(s). 
Instance "+ASM1", status READY, has 1 handler(s) for this service...
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s).
Instance "DB23ai", status READY, has 2 handler(s) for this service...
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service...  
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 1 handler(s) for this service...  
 Service "XXXXX.paas.oracle.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.paas.oracle.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.paas.oracle.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
 Service "XXXXX.XXXXX.XXXXX.oraclevcn.com" has 1 instance(s). 
Instance "DB23ai", status READY, has 2 handler(s) for this service... 
The command completed successfully

Perfecto, el listener esta arriba.

Vamos a ejecutar ConnStr y veamos que información nos da:

[oracle@ ~]$ connstr 
Using Listener: LISTENER with Oracle Home: /u01/app/oracle/product/23.0.0.0/dbhome_1

Service Name: XXXXXXXXX.paas.oracle.com 
Connection String: X.X.X.X:1521/XXXXXXXXX.paas.oracle.com

Service Name: XXXXXXX.XXXXXX.vcn23ai.oraclevcn.com 
Connection String: X.X.X.X:1521/XXXXXX.XXXXXXXX.vcn23ai.oraclevcn.com

...
...

Connection strings can be used to connect to the specified service name.

For SQL*Plus you can use: 
SQL> connect username@X.X.X.X:1521/XXXXX.paas.oracle.com

For Python you can use: 
connection = oracledb.connect(user="username", password="password", dsn="X.X.X.X:1521/XXXXXX.paas.oracle.com")

For JDBC Thin you can use: OracleDataSource ods = new OracleDataSource();
ods.setURL("jdbc:oracle:thin:@X.X.X.X:1521/XXXXXX.paas.oracle.com");
ods.setUser("username"); ods.setPassword("password");
Connection conn = ods.getConnection();

Write connect strings to tnsnames.ora (Y/N)? (Default: N):

Que maravilla de output no? Oracle nos facilita de manera muy sencilla las cadenas de conexión para Easy Connect, JDBC y Python.

Y como nota final, nos da la opción de incluir las cadenas en el tnsnames.ora!

En este caso, hemos ejecutado directamente el comando porque tenemos un único listener. Si tuviéramos más de un listener, podríamos especificar la opción -L junto con el nombre del listener.

Otras utilidades del comando son las siguientes:

  • Listar los listener disponibles.
[oracle@~]$ connstr -e 
PROTOCOL PORT HOST 
tcp      1521 X.X.X.X
  • Listar los servicios disponibles:
[oracle@~]$ connstr -s 
XXXXXXXX.paas.oracle.com 
XXXXXXXX.paas.oracle.com 
XXXXXXXX.XXXXXXXX.vcn23ai.oraclevcn.com 
pdb_david.XXXXXXXX.vcn23ai.oraclevcn.com 
+APX 
+ASM 
+ASM_DATA 
+ASM_RECO 
XXXXXXXX.XXXXXXXX.vcn23ai.oraclevcn.com 
XXXXXXXX.paas.oracle.com 
XXXXXXXX.XXXXXXXX.vcn23ai.oraclevcn.com 
XXXXXXXX.XXXXXXXX.vcn23ai.oraclevcn.com
  • Obtener la conexión JDBC de un servicio
[oracle@ ~]$ connstr -j pdb_david jdbc:oracle:thin:@X.X.X.X:1521/XXXXXXXX.paas.oracle.com
  • Obtener la cadena de conexión de un servicio
[oracle@~]$ connstr -d pdb_david
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=X.X.X.X)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=XXXXXXXX.paas.oracle.com)))
  • Obtener la cadena de conexión de un servicio en formato Easy Connect.
[oracle@~]$ connstr -z pdb_david 
 X.X.X.X:1521/XXXXXXXX.paas.oracle.com

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] Instalación de Oracle26ai en Linux 9]]>https://dbaenlasombra.com/26ai-instalaci-n-de-oracle26ai-en-linux-9https://dbaenlasombra.com/26ai-instalaci-n-de-oracle26ai-en-linux-9Sat, 14 Mar 2026 16:57:44 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy vamos a ver como podemos instalar Oracle 26ai en Linux 9.

[root@~]# grep PRETTY /etc/os-release
PRETTY_NAME="Oracle Linux Server 9.7"

El primer paso es descarga Oracle 26ai pre-installation desde aquí.

Procedemos a instalar el rpm una vez que lo tengamos descargado.

root@~]# ls -lac oracle-ai-database-preinstall-26ai-1.0-1.el9.x86_64.rpm
-rw-r--r--. 1 root root 35302 mar  8 11:39 oracle-ai-database-preinstall-26ai-1.0-1.el9.x86_64.rpm
[root@~]# dnf -y install oracle-ai-database-preinstall-26ai-1.0-1.el9.x86_64.rpm
   
...
...
¡Listo!

Listo, revisamos que se ha creado el usuario oracle para proceder a crear los directorios de ORACLE_HOME.

[root@~]# id oracle
uid=54321(oracle) gid=54321(oinstall) grupos=54321(oinstall),54322(dba),54323(oper),54324(backupdba),54325(dgdba),54326(kmdba),54330(racdba)
[root@~]# 
[root@~]# mkdir -p /u01/app/oracle/product/23.26.1/dbhome_1
[root@~]# chown -R oracle:oinstall /u01 && chown -R oracle:oinstall /u01
[root@~]# su - oracle
[oracle@~]$ cd /u01/app/oracle/product/23.26.1/dbhome_1/

Adaptamos los ficheros .bashrc y bash_profile, para definir las siguientes variables:

[oracle@~]$ tail -8 .bashrc
# User specific aliases and functions
ORACLE_BASE=/u01/app/oracle/
ORACLE_HOME=/u01/app/oracle/product/23.26.1/dbhome_1; export ORACLE_HOME
PATH=\(PATH:\){ORACLE_HOME}/bin; export PATH
LD_LIBRARY_PATH={ORACLE_HOME}/lib; export LD_LIBRARY_PATH

Descargamos Oracle AI Database 26ai (23.26.1) for Linux x86-64 desde aquí.

Una vez descargado lo copiamos en /u01/app/oracle/product/23.26.1/dbhome_1.

[oracle@]$ pwd && ls -lash
/u01/app/oracle/product/23.26.1/dbhome_1
total 2,3G
   0 drwxr-xr-x. 2 oracle oinstall   43 mar 14 12:12 .
   0 drwxr-xr-x. 3 oracle oinstall   22 mar  9 22:54 ..
2,3G -rwxr-x---. 1 oracle oinstall 2,3G mar 14 12:18 LINUX.X64_2326100_db_home.zip
[oracle@]$ unzip LINUX.X64_2326100_db_home.zip

Antes de realizar la instalación, vamos a adaptar el fichero response a nuestra instalación ya que usaremos el modo silent como método de instalación.

[oracle@]$ vi install/response/db_install.rsp
[oracle@]\( grep -v "#" install/response/db_install.rsp | grep -v '^\)'
oracle.install.responseFileVersion=/oracle/install/rspfmt_dbinstall_response_schema_v23.0.0
installOption=INSTALL_DB_SWONLY
UNIX_GROUP_NAME=oinstall
INVENTORY_LOCATION=${ORA_INVENTORY}
ORACLE_HOME=/u01/app/oracle/product/23.26.1/dbhome_1
ORACLE_BASE=/u01/app/oracle/
installEdition=EE
OSDBA=dba
OSBACKUPDBA=dba
OSDGDBA=dba
OSKMDBA=dba
OSRACDBA=dba
[oracle@]$ ./runInstaller -silent -responsefile install/response/db_install.rsp

Con usuario root, ejecutamos los dos últimos scripts

[root@~]# .  /u01/app/oraInventory/orainstRoot.sh
...
[root@~]# .  /u01/app/oracle/product/23.26.1/dbhome_1/root.sh
...

Verificamos la instalación:

[oracle@~]$ sqlplus /nolog

SQL*Plus: Release 23.26.1.0.0 - Production on Sat Mar 14 17:49:10 2026
Version 23.26.1.0.0

Copyright (c) 1982, 2025, Oracle.  All rights reserved.

SQL>

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[OCI] Montaje de un Bucket como un FS]]>https://dbaenlasombra.com/oci-montaje-de-un-bucket-como-un-fshttps://dbaenlasombra.com/oci-montaje-de-un-bucket-como-un-fsMon, 09 Mar 2026 18:55:24 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy vamos a ver como montar un Bucket como un filesystem en un DB System de OCI, ya que puede ser algo muy útil poder administrar nuestro Bucket con si fuera un directorio más en nuestras máquinas.

El DB System de OCI tiene Oracle Linux Server 8.

[root@~]$ grep ORACLE_* /etc/os-release
ORACLE_BUGZILLA_PRODUCT="Oracle Linux 8"
ORACLE_BUGZILLA_PRODUCT_VERSION=8.8
ORACLE_SUPPORT_PRODUCT="Oracle Linux"
ORACLE_SUPPORT_PRODUCT_VERSION=8.8

Para Oracle Linux 8 o superior, debemos utilizar OCIFS.

Antes de meternos en faena, tenemos que tener los siguientes puntos realizados:

  • Tener un Bucket en nuestra tenancy.

  • Tener suficiente espacio en nuestra máquina, ya que OCIFS usa espacio en disco para cachear los objectos de nuestro Bucket .

  • OCI Cli configurado, ya que por defecto OCIFS usa API key-based authentication para autenticarse. Dejo por aquí, donde hablamos para configurarlo de manera sencilla.

[OCI] OCI-cli y su configuración

Así que que vamos a instalar OCIFS como usuario root en nuestra máquina:

[root@~]$ dnf install ocifs -y
...
Last metadata expiration check: 2:19:05 ago on Sun 08 Mar 2026 12:38:39 PM UTC.
Dependencies resolved.
...
Installed:
  fuse-2.9.7-19.0.1.el8.x86_64                               
  fuse-common-3.3.0-19.0.1.el8.x86_64                               
  ocifs-1.2.0-6.el8.x86_64                              
...
...
Complete!

Perfecto, ahora vamos a mirar donde podríamos crear el directorio que actúe como cache para OCIFS.

[root@~]$ 
df -h --output=source,size,used,avail,pcent,target | (read -r h; echo "$h"; sort -k2,2hr) | head -4
Filesystem                      Size  Used Avail Use% Mounted on
/dev/sdg                        196G   26G  161G  14% /u01
/dev/mapper/vg00-opt             33G  6.0G   26G  19% /opt
devtmpfs                         16G     0   16G   0% /dev

Donde más sitio tenemos es en /u01, así que crearemos ahí el directorio:

[root@~]$ mkdir /u01/tmp

Consultamos el nombre del Bucket que queremos que sea un FS en nuestra máquina

Una vez copiado el nombre del Bucket, lo montamos con el comando ocifs:

[root@~]$ mkdir /mybucket 
[root@~]$ ocifs --cache=/u01/tmp <name_bucket> /mybucket
[root@~]$ df -h /mybucket
Filesystem            Size  Used Avail Use% Mounted on
<name_bucket>          0     0     0    - /mybucket
[root@l23ai ~]# grep mybucket /proc/mounts
<name_bucket> /mybucket fuse.ocifs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions 0 0

Perfecto, hemos montado nuestro Bucket y además vemos que se ha creado correctamente la entrada en /proc/mounts.

Vamos a crear un fichero con algo de información de manera local:

[root@~]$ 
 touch /mybucket/passwd.bck && cat /etc/passwd > /mybucket/passwd.bck

Abajo, podéis ver que el fichero está correctamente en nuestro Bucket :

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] DBMS_CLOUD — Capitulo Dos]]>https://dbaenlasombra.com/26ai-dbms-cloud-capitulo-doshttps://dbaenlasombra.com/26ai-dbms-cloud-capitulo-dosTue, 24 Feb 2026 16:28:46 GMTEl artículo también se encuentra publicado en Ingles English version.

Continuando con el artículo de la semana pasada, donde vimos la configuración y unos primeros usos de DBMS_CLOUD en el día a día, hoy continuaremos con la parte de Data Pump.

Dejo por aquí el enlace del primer capitulo:

[26ai] DBMS_CLOUD — Capitulo Uno

La idea del laboratorio es la siguiente:

  • Export una tabla a nuestro Bucket.

  • Importar la tabla que hemos exportado en el punto anterior

Así que sin más, vamos ha realizar cada punto:

Export a un Bucket

Vamos a definir un tabla que utilizaremos para exportar e importar:

SQL> 
  Create Table My_Grants As  
   Select TABLE_SCHEMA,TABLE_NAME,PRIVILEGE  
     From All_Tab_Privs;

 Table created.

SQL> set linesize 1000 pages 1000
SQL> col TABLE_SCHEMA format a20
SQL> col table_name format a20
SQL> col privilege format a20
SQL> r
  1* Select * From My_Grants FETCH FIRST 10  ROWS ONLY

TABLE_SCHEMA         TABLE_NAME                     PRIVILEGE
-------------------- ------------------------------ --------------------
SYS                  DUAL                           SELECT
SYS                  SYSTEM_PRIVILEGE_MAP           READ
SYS                  TABLE_PRIVILEGE_MAP            READ
SYS                  USER_PRIVILEGE_MAP             READ
SYS                  STMT_AUDIT_OPTION_MAP          READ
SYS                  FINALHIST$                     INSERT
SYS                  DM$EXPIMP_ID_SEQ               SELECT
SYS                  MODELGTTRAW$                   SELECT
SYS                  MODELGTTRAW$                   INSERT
SYS                  PMAPGTT$                       SELECT

Utilizaremos la propiedad DEFAULT_CREDENTIAL para setear nuestra credencial por defecto y así no tener que indicarla dentro del parfile del export.

SQL> 
ALTER DATABASE PROPERTY SET DEFAULT_CREDENTIAL = 'TEST.DBA_IN_THE_SHADOW';

Database altered.

SQL> 
Select PROPERTY_NAME,PROPERTY_VALUE 
  From database_properties  
 Where PROPERTY_NAME= 'DEFAULT_CREDENTIAL';

PROPERTY_NAME        PROPERTY_VALUE                           
-------------------- ---------------------------------------- 
DEFAULT_CREDENTIAL   TEST.DBA_IN_THE_SHADOW

Definimos el parfile:

SQL> ! vi export_to_bucket.par
SQL> ! cat export_to_bucket.par
DUMPFILE=<location_uri>/<TABLE>.dmp
LOGFILE=<TABLE>.log
TABLES=<SCHEMA>.<TABLE>
CONTENT=DATA_ONLY
LOGTIME=ALL
METRICS=YES
FLASHBACK_TIME=SYSTIMESTAMP
encryption_password=hari

Esto es lo que hemos definido:

  • DUMPILE: La ruta donde se va guardar el dmp, en nuestro caso es el Bucket más un nombre descriptivo.

  • LOGFILE: Nombre del log.

  • TABLES: Ahí indicamos la tabla que hemos creado previamente.

  • CONTENT=DATA_ONLY: Solo exportamos los datos

  • LOGTIME/METRICS: Métricas de tiempo de nuestro export.

  • FLASHBACK_TIME: Que sea un export consistente.

  • ENCRYPTION_PASSWORD: Encrypt de nuestro dmp.

Ejecutamos el export:

Consultamos que el dmp se ha generado correctamente en el Bucket:

SQL> 
Select object_name, trunc(bytes / (1024*1024),2) MB
  From 
   dbms_cloud.list_objects('DBA_IN_THE_SHADOW', '<location_uri>'); 

OBJECT_NAME                                      MB
---------------------------------------- ----------
ORA7445pf_20260205085710_COM_1.zip            57.35
Wallet_OF2BAP.zip                               .02
Wallet_OF2BCE.zip                               .02
grant.dmp                                         0
grant.dmp_segments/aaaaaa                         2
grant.dmp_segments/aaaaab                       .86

6 rows selected.

Fijémonos una cosa sobre el dmp que tenemos en nuestro Bucket. Tenemos tres archivos, cuando hemos indicado uno único archivo sin comodines, es decir, sin %L, %l, %U o %u. El tamaño de nuestro dmp es 0Mb y los fragmentos son los que tiene el peso, esto es porque Data Pump divide cada parte del archivo en fragmentos más pequeños para una carga más rápida.

Import desde Bucket

Ejecutamos el import creando una tabla previa para almacenar ahí la información:

SQL> CREATE TABLE MY_GRANTS_BCK AS SELECT * FROM MY_GRANTS WHERE 2 = 1;

Table created.
SQL> ! vi import_to_bucket.par
SQL> ! cat import_to_bucket.par
DUMPFILE=<location_uri>/<TABLE>.dmp
LOGFILE=MY_GRANTS.log
LOGTIME=ALL
METRICS=YES
REMAP_TABLE = TEST.MY_GRANTS:MY_GRANTS_BCK
encryption_password=yes

Esto es lo que hemos definido:

  • DUMPILE: La ruta donde se encuentra el dmp.

  • LOGFILE: Nombre del log.

  • LOGTIME/METRICS: Métricas de tiempo de nuestro export.

  • REMAP_TABLE: Queremos que la información del dmp se albergue en otra tabla

  • ENCRYPTION_PASSWORD= Encrypt de nuestro dmp.

Ejecutamos el import:

Perfecto, hemos podido exportar e importar un dmp desde el Bucket.

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] DBMS_CLOUD — Capitulo Uno]]>https://dbaenlasombra.com/26ai-dbms-cloud-capitulo-unohttps://dbaenlasombra.com/26ai-dbms-cloud-capitulo-unoFri, 20 Feb 2026 00:40:29 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy vamos a ver algunos beneficios que podemos tener en el día a día al utilizar DBMS_CLOUD en 26ai para nuestras tareas diarias, como puede ser tareas de respaldo de un datapump o guardar informes, ya que se conecta a un Object Storage de OCI.

Por defecto, no viene configurado en nuestra 26ai, con lo que el primer paso que debemos hacer es configurarlo para un usuario válido de nuestra tenancy.

Antes de meternos en faena, debemos asegurarnos que nuestra base de datos tiene DBMS_CLOUD configurado y listo para usarse. Dejo por aquí la nota de Oracle para la instalación en caso que no tengamos configurado ese punto:

How To Setup And Use DBMS_CLOUD Package (Doc ID 2748362.1)

A nivel de OCI, debemos configurar para nuestro usuario un token o API Key ya que necesitamos definir una credencial porque nuestro Bucket es privado. No sería necesario definir la credencial si nuestro Bucket es público*.*

Token

El primer paso que vamos a realizar es generar el token de nuestro usuario en OCI. Para ello, tendremos que ir a la parte de configuración de nuestro usuario, justo en la parte superior derecha:

Una vez dentro, vamos a la pestaña Tokens and keys:

Ahí vamos a ver tres secciones: API Keys, Auth Tokens y Customer Secrets Keys.

Bien, la que nos interesa es la de Auth Tokens:

Ahí pulsamos en Generate token. Nos pedirá un nombre y pulsamos en Generate token:

La siguiente ventana no la debemos cerrar sin antes copiar el token.

Una vez que hayamos copiado el token, definimos la credential en nuestra base de datos usando el token que hemos generado en el punto anterior.

Configuración de la Credencial

Para generarlo, debemos usar DBMS_CLOUD.CREATE_CREDENTIAL.

Este procedimiento recibe los siguientes parámetros:

  • CREDENTIAL_NAME: Nombre de la credencial que vamos a crear.

  • USERNAME: Nombre del nuestro usuario, siempre debe seguir la estructura de “/”.

  • Password: Valor del que hemos generado antes

SQL>EXEC  dbms_cloud.create_credential(
    credential_name => 'DBA_IN_THE_SHADOW',
    username        => '<IdentityDomain>/<usuario_tenancy>',
    password        => '<token>');

SQL> R
  1  select credential_name,
  2         username,
  3         enabled
  4  from   DBA_credentials
  5* order by credential_name

CREDENTIAL_NAME           USERNAME                                           ENABLED
------------------------- -------------------------------------------------- --------------------
DBA_IN_THE_SHADOW         <IdentityDomain>/<usuario_tenancy>       TRUE

Una manera rápida de verificar que funciona correctamente es listando el contenido que tenemos en nuestra Bucket. Para ello nos apoyaremos en la función DBMS_CLOUD.LIST_OBJECTS.

Esta función recibe dos parámetros, el primero sería el nombre de la credencial que hemos generado en el punto anterior, y el segundo sería la URL para acceder a nuestro Bucket.

La manera más fácil de obtener la url, es ir a un objecto de nuestro Bucket e ir a los detalles del mismo:

Ahí copiamos el valor de “URL path (URI)”.

Una vez que lo tenemos copiado, listamos vía SQL el contenido del Bucket:

SQL> 
Select object_name
  From Dbms_cloud.list_objects('DBA_IN_THE_SHADOW','<location_uri>'); 

OBJECT_NAME
--------------------------------------------------------------------------------
XXXXXXXX.zip
XXXXXXXX.zip
XXXXXXXX.zip

Perfecto, tenemos acceso.

Subida de ficheros

Generamos un fichero csv y lo subimos a nuestro Bucket.

Utilizaremos DBMS_CLOUD.PUT_OBJECTS para subir el fichero generado. Para utilizarlo, definiremos el directory apuntando al path donde se encuentra nuestro fichero.

SQL> ! cat generate.sql
set heading off
set feedback off
set echo off
set verify off
set termout off
set markup csv on
spool myfile.csv
Select trunc(dbms_random.value(1, 1000)), dbms_random.string('x', 10)     
 From dual  
connect by level <= 10000;
spool off

SQL> @generate.sql
SQL> ! ls -lac *csv
-rw-r--r-- 1 oracle oinstall 168924 Feb 18 12:42 myfile.csv

SQL> CREATE DIRECTORY OCI_HOME as '/home/oracle';
SQL> GRANT READ, WRITE ON DIRECTORY OCI_HOME TO PUBLIC;
SQL> begin
  dbms_cloud.put_object (
    credential_name => 'DBA_IN_THE_SHADOW',
    object_uri      => '<location_uri>/myfile.csv',
    directory_name  => 'OCI_HOME',
    file_name       => 'myfile.csv');
end;
/ 
SQL>
SQL> Select object_name
  From 
   dbms_cloud.list_objects('DBA_IN_THE_SHADOW','<location_uri>');  

OBJECT_NAME
--------------------------------------------------------------------------------
XXXXXXXX.zip
XXXXXXXX.zip
XXXXXXXX.zip
myfile.csv

Listo, ya tenemos el fichero en nuestro Bucket.

Una vez subido, podemos generar una tabla externa que lee ese fichero. Una manera rápida de definir este punto, es usando DBMS_CLOUD.CREATE_EXTERNAL_TABLE, que genera una tabla en nuestro schema que lee el fichero que le pasemos por parámetro.

SQL> 
BEGIN
  DBMS_CLOUD.CREATE_EXTERNAL_TABLE(
    table_name      => 'EXT_MYFILE_CSV',
    credential_name => 'DBA_IN_THE_SHADOW',
    file_uri_list   => '<location_uri>/myfile.csv',
    format          => JSON_OBJECT(
                         'type' VALUE 'csv',
                         'delimiter' VALUE ',',
                         'quote' VALUE '"',
                         'skipheaders' VALUE '0'
                       ),
    column_list     => '
        id   NUMBER,
        code VARCHAR2(50)
    '
  );
END;
/

SQL> SELECT COUNT(*) FROM EXT_MYFILE_CSV;
1000
SQL>
 SELECT * FROM EXT_MYFILE_CSV FETCH FIRST 25 ROWS ONLY
        ID CODE
---------- --------------------------------------------------
       224 3LU82RWW27
       654 LASYRZWUUE
        17 UW34WB3O4Y
       764 5Z2I01ITAX
       132 V4XCFDS9GA
       131 6PRK6G0VTC
       650 NST09S6RY9
       133 R8IIPLJZ95
       477 WK8Y1XC5XK
       930 O574M5RJK2
       371 P8G6PF91A9
       214 WRUYMY4BWY
       273 YD5NG441MV
       706 DQYEBYNF5H
       699 J3T3RHNHU0
       744 VVXATGVW0N
       945 U55X9EATLH
       371 RHW44MZ1DQ
       595 B1RU6VN33B
       864 P02I2A9Z8S
       218 R02XSI9MLY
       980 M0CSWHE4G7
       396 UZYFEL7UKI
       619 DYKCFI912X
       881 2TZ0GEQ6MM

25 rows selected.

También podemos exportar la información de una consulta válida a nuestro Bucket usando DBMS_CLOUD.EXPORT_DATA.

Este procedimiento recibe los siguientes parámetros:

  • CREDENTIAL_NAME: Nombre de la credencial que vamos a crear.

  • URL: “URL path (URI)” más el nombre del fichero, no es necesario indicar la extensión, ya que eso lo indicamos en el parámetro Format.

  • Format: Formato en que queremos guardar el spool de nuestra consulta, en nuestra caso es json.

  • Query: SQL válida que queremos exportar.

SQL> 
BEGIN
      DBMS_CLOUD.EXPORT_DATA(  
        credential_name =>'DBA_IN_THE_SHADOW',
        file_uri_list =>'<location_uri>/config_system_parameter',
        format => json_object(  'type' VALUE 'json' ),
        query => 'SELECT NAME, VALUE FROM V$SYSTEM_PARAMETER'
      );
   END;
  / 

SQL> Select object_name
  From 
   dbms_cloud.list_objects('DBA_IN_THE_SHADOW','<location_uri>');  

OBJECT_NAME
--------------------------------------------------------------------------------
XXXXXXXX.zip
XXXXXXXX.zip
XXXXXXXX.zip
config_system_parameter_1_1_1.json
myfile.csv

Y si necesitamos descargar ese fichero en una tabla, podríamos usar el procedimiento DBMS_CLOUD.COPY_DATA.

SQL> 
  Create table BACK_SYSTEM_PARAMETER ( 
    INFO_PARAMETER CLOB  CONSTRAINT INFO_PARAMETER_JSON CHECK ( INFO_PARAMETER IS JSON )
      );

Table created.

SQL>
begin
  DBMS_CLOUD.COPY_DATA (
    table_name      => 'BACK_SYSTEM_PARAMETER',
    credential_name => 'DBA_IN_THE_SHADOW',
    file_uri_list   => '<location_uri>/config_system_parameter_1_1_1.json'
     );
end;
/
PL/SQL procedure successfully completed.

Ahí he definido una tabla BACK_SYSTEM_PARAMETER con una única columna con el objecto de inyectar ahí el contenido del JSON. Una vez definida, ejecuto el procedimiento para descargar la información.

Si consultamos la tabla, vemos que se ha cargado correctamente la información:

SQL>
 select 
    JSON_VALUE(INFO_PARAMETER, '$.NAME') AS NAME, 
    JSON_VALUE(INFO_PARAMETER, '$.VALUE') AS VALUE 
   from BACK_SYSTEM_PARAMETER
 Where INSTR(UPPER(JSON_VALUE(INFO_PARAMETER, '$.NAME')),'OPTIMIZER') != 0
  FETCH FIRST 5 ROWS ONLY;

NAME                                     VALUE
---------------------------------------- ----------------------------------------
optimizer_ignore_hints                   FALSE
optimizer_secure_view_merging            TRUE
optimizer_use_pending_statistics         FALSE
optimizer_capture_sql_plan_baselines     FALSE
optimizer_use_sql_plan_baselines         TRUE

10 rows selected.

En el próximo artículo abordaremos el uso del Data Pump junto con el DBMS_CLOUD

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] Blockchain & Immutable table]]>https://dbaenlasombra.com/26ai-blockchain-and-immutable-tablehttps://dbaenlasombra.com/26ai-blockchain-and-immutable-tableThu, 12 Feb 2026 14:25:08 GMTEl artículo también se encuentra publicado en Ingles English version.

En este pequeño artículo vamos a ver las Blockchain table y Immutable table.

Este tipo de tablas fueron introducidas en Oracle, con el objetivo de protegernos contra la modificación de datos no autorizados por personal externo o accidentalmente, únicamente se pueden realizar inserciones. Además, las Blockchain table a diferencia de las Immutable table, incluyen una capa extra de seguridad incluyendo cryptographic hash a nivel de fila enlazado con la fila anterior, formando una cadena que permite detectar cualquier intento de manipulación.

Aunque no es una novedad en 26ai, sino que fueron incluidas en la 21c, si que han incluido importantes mejoras muy interesantes para potenciar este tipo de tablas:

  • Poder añadir y eliminar columnas tanto en Blockchain como en Immutable table, especificando VERSION v2. Veamos un ejemplo, porque creo que es un matiz importante:

      SQL> 
  CREATE IMMUTABLE TABLE T_TEST_VRS_1 (
    TC_ID NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY
  )
  no drop until 2 days idle
  no delete until 16 days after insert
  VERSION "v1";

  Table created.
  SQL>  ALTER TABLE T_TEST_VRS_1 ADD (FECHA DATE);
  ERROR at line 1:
  ORA-05715: operation not allowed on the blockchain or immutable table
  Help: https://docs.oracle.com/error-help/db/ora-05715/

  SQL> 
  CREATE IMMUTABLE TABLE T_TEST_VRS_2 (
    TC_ID NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY
  )
  no drop until 2 days idle
  no delete until 16 days after insert
  VERSION "v2";

  SQL> ALTER TABLE T_TEST_VRS_2 ADD (FECHA DATE);
  Table altered.

  • BLOCKCHAIN_TABLE_MAX_NO_DROP, nuevo parámetro para especificar el tiempo máximo de inactividad cuando definimos este tipo de tablas. Cuando el parámetro esta seteado a un valor y el usuario crea una tabla con la cláusula NO DROP UNTIL n DAYS IDLE, el valor de n debe ser igual a ese valor o inferior. Si el parámetro esta nulo, es decir, no seteado, podemos definir cualquier valor en n DAYS IDLE.

Tanto las filas nuevas como las antiguas, o el borrado de la tabla, están sujetas a un periodo de retención que el usuario especifica al crear la tabla, y cuando ese periodo de retención expira, pueden eliminarse las filas o directamente la tabla.

Periodo de Retención

En el modelo que vemos a continuación, podemos ver como podemos especificar el periodo de retención a nivel de tabla y fila:

A nivel de tabla:

  • NO DROP: La tabla no puede ser eliminada, a no ser que este vacía.

  • NO DROP UNTIL n DAYS IDLE: Si aún quedan filas con un periodo de antigüedad menor, la tabla no puede ser eliminada. Por defecto, el valor es 0, aunque para garantizar la seguridad se recomienda un valor mínimo de 16.

A nivel de fila:

  • NO DELETE [locked]: Las filas no pueden ser eliminadas. La clausula [locked] especifica que no se puede modificar la retención.

  • NO DELETE UNTIL n DAYS AFTER INSERT [locked]: Cada fila no puede ser eliminada, es decir, esta protegida de la eliminación tantos días como especifiquemos en la cláusula n DAYS. Valor mínimo es 16 días. La clausula [locked] especifica que no se puede modificar la retención.

Restricciones

Las restricciones a nivel de tabla son las siguientes:

  • Los siguientes tipo de datos no pueden ser soportados: ROWID, UROWID, LONG, OBJECT TYPE, REF, VARRAY, NESTED TABLE, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, BFILE y XMLType.

  • A nivel de tabla, no pueden ser INDEX-ORGANIZED, ORGANIZATION CUBE, ORGANIZATION EXTERNAL o HIBRYD PARTITIONED.

Sin más vamos a definir un ejemplo de cada.

Inmutable Table

SQL> 
CREATE IMMUTABLE TABLE T_CLIENTES (
  TC_ID NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  TC_name   VARCHAR2(100) NOT NULL,
  TC_email       VARCHAR2(200),
  TC_created_at  DATE DEFAULT SYSDATE
)
no drop until 2 days idle
no delete until 16 days after insert
VERSION "v2";

Table created.

Si necesitamos modificar los periodos de retención:

SQL> ALTER TABLE T_CLIENTES  NO DROP UNTIL 5 DAYS IDLE;
Table altered.
SQL> ALTER TABLE T_CLIENTES  NO DELETE UNTIL 32 DAYS AFTER INSERT;
Table altered.

Como hemos incluido VERSION v2, podemos añadir columnas:

SQL> ALTER TABLE T_CLIENTES ADD (TC_PROVINCIA VARCHAR2(100));

Insertamos información e intentamos modificar algún dato:

SQL> r
  1* Select * From t_Clientes

     TC_ID TC_NAME              TC_EMAIL             TC_CREATE TC_PROVINCIA
---------- -------------------- -------------------- --------- ----------------------------------------------------------------------------------------------------
         1 Iker San             San@demo.local       11-FEB-26
         2 Juan Perro           Perro@demo.local     11-FEB-26
         3 Carla Marq           Marq@demo.local      11-FEB-26

SQL> Update t_Clientes Set Tc_Provincia='VALLADOLID' where tc_id = 3;
Update t_Clientes Set Tc_Provincia='VALLADOLID' where tc_id = 3
       *
ERROR at line 1:
ORA-05715: operation not allowed on the blockchain or immutable table
Help: https://docs.oracle.com/error-help/db/ora-05715/

Como podemos observar, no podemos modificar información. Únicamente insertar nuevos registros.

Blockchain Table

SQL> 
CREATE BLOCKCHAIN TABLE T_PRODUCTOSTIENDA (
  TP_id       NUMBER,
  TP_NOMBRE   VARCHAR2(100),
  TP_PRICE    FLOAT
)
NO DROP UNTIL 14 DAYS IDLE
NO DELETE UNTIL 30 DAYS AFTER INSERT
HASHING USING "SHA2_512"
WITH ROW VERSION AND USER CHAIN T_PRODUCTOS_VALIDATION (TP_id)
VERSION "v2";  

Table created.

Si necesitamos modificar los periodos de retención:

SQL> ALTER TABLE T_PRODUCTOSTIENDA  NO DROP UNTIL 16 DAYS IDLE;
Table altered.
SQL> ALTER TABLE T_PRODUCTOSTIENDA  NO DELETE UNTIL 32 DAYS AFTER INSERT;
Table altered.

Como hemos incluido VERSION v2, podemos añadir columnas:

SQL> ALTER TABLE T_PRODUCTOSTIENDA ADD (TC_CANTIDAD INTEGER);

Insertamos información e intentamos modificar algún dato:

SQL> Select * From T_PRODUCTOSTIENDA;

     TP_ID TP_NOMBRE              TP_PRICE TC_CANTIDAD
---------- -------------------- ---------- -----------
         1 PERAS
         1 PERAS JULIANAS
         2 NARANJAS
         3 MANGOS

SQL> UPDATE T_PRODUCTOSTIENDA SET TP_PRICE = 9;
UPDATE T_PRODUCTOSTIENDA SET TP_PRICE = 9
       *
ERROR at line 1:
ORA-05715: operation not allowed on the blockchain or immutable table
Help: https://docs.oracle.com/error-help/db/ora-05715/

Como podemos observar, tampoco podemos modificar registros. Si nos fijamos en la información introducida, hay dos productos con el mismo identificador, pero…¿Cuál fue el último insertado? En las tablas BLOCKCHAIN, Oracle crea automáticamente una vista <TABLE_NAME>_LAST$ para mostrar la última versión de cada fila.

SQL> Select * From T_PRODUCTOSTIENDA_LAST$;

     TP_ID TP_NOMBRE              TP_PRICE
---------- -------------------- ----------
         1 PERAS JULIANAS
         2 NARANJAS
         3 MANGOS

En próximos artículos, abordaremos el tema del borrado sobre estos ejemplos que hemos utilizado.

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] Mandatory Profile]]>https://dbaenlasombra.com/26ai-mandatory-profilehttps://dbaenlasombra.com/26ai-mandatory-profileThu, 29 Jan 2026 14:32:37 GMTEl artículo también se encuentra publicado en Ingles English version.

En este pequeño artículo vamos a ver los Mandatory Profile.

Aunque no es una novedad en 26ai, sino que fue en la 21c, vamos a proceder a configurarlo en la última release de Oracle.

Este tipo de Profile pueden ser creados dentro de CDB$Root para luego asignarse a las distintas PDBs. Otro punto a tener en cuenta, es que si necesitamos modificarlos, debemos realizarlo a nivel de CDB$ROOT, no de PDB, usando common users, no local users.

Además, las políticas definidas en el Profile se aplicarán a todos los usuarios de la PDB.

¿Qué parámetros puedo usar? A diferencia de un Profile, donde tenemos multitud de parámetros para configurar, aquí solo podemos definir dos, son:

  • Password_verify_function para forzar la complejidad de la contraseña por medio de la función que tenga asignada. Valor por defecto es null.

  • Password_grace_time permite especificar un periodo de gracia para aquellas cuentas que violen la complejidad de las contraseñas. Valor por defecto es 0.

Lo primero que vamos hacer es definir la función que asignaremos al parámetro password_verify_function.

SQL> 
CREATE OR REPLACE FUNCTION VALIDATION_BUSINESS(username     varchar2,
                                               password     varchar2,
                                               old_password varchar2)
  return boolean IS
BEGIN
  if not ora_complexity_check(password, chars => 8, digit => 4) then
    return(false);
  end if;
  return(true);
END;
/
Function created.

Cómo podemos ver, estoy definiendo la función VALIDATION_BUSINESS dentro de CDB$Root con el objetivo de que todas las contraseñas de los usuarios tengan al menos una longitud de 8 caracteres “chars => 8” y 4 dígitos “digit=>4“.

Definimos el Mandatory Profile usando los siguientes parámetros:

  • PASSWORD_VERIFY_FUNCTION para asignarle la función que hemos creado en el punto anterior.

  • PASSWORD_GRACE_TIME para dar al usuario un periodo de gracia de 5 días para cambiar la contraseña.

SQL> 
  CREATE MANDATORY PROFILE C##VALIDATION_BUSINESS 
   LIMIT 
     PASSWORD_VERIFY_FUNCTION VALIDATION_BUSINESS 
     PASSWORD_GRACE_TIME 5 
   CONTAINER = ALL; 

Profile created.

Como último paso sería modificar el parámetro MANDATORY_USER_PROFILE.

Aquí podemos hacer dos cosas, si queremos que el cambio afecte a todas las PDB, debemos ajustar ese parámetro a nivel de CDB$ROOT; pero si queremos que solo se aplique a una PDB específica, entonces debemos modificarlo directamente dentro de esa PDB.

SQL> show parameter MANDATORY_USER_PROFILE
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
mandatory_user_profile               string

SQL> ALTER SYSTEM SET MANDATORY_USER_PROFILE=C##VALIDATION_BUSINESS;
System altered.

SQL> show parameter MANDATORY_USER_PROFILE

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
mandatory_user_profile               string      C##VALIDATION_BUSINESS

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[26ai] Oracle Temporary Tablespace Groups]]>https://dbaenlasombra.com/26ai-oracle-temporary-tablespace-groupshttps://dbaenlasombra.com/26ai-oracle-temporary-tablespace-groupsWed, 21 Jan 2026 07:12:40 GMTEl artículo también se encuentra publicado en Ingles English version.

En este pequeño artículo vamos a ver la creación de Temporary Tablespace Groups, pero antes de meternos en faena, vamos a dar una pequeña pincelada de que se trata esta opción.

Aunque no es una novedad en 26ai, vamos a proceder a configurarla en nuestra base de datos..

Este tipo de tablespaces, permite al usuario que cuando realizar operaciones que requieren mucha área temporal, como por ejemplo ordenaciones, el fuljo de trabajo se reparta entre múltiples tablespaces temporales. De este modo evitamos que tengamos saturación en el tablespace en caso que tengamos un único tablespace al realizar este tipo de operaciones.

Para poder llevar a cabo este laboratorio, vamos a definir una máquina virtual con la última versión de Oracle en OCI.

Las máquina que hemos definido es la siguientes:

  • Source: 26ai VM DB System Oracle Cloud (test).

1º: Definiremos una nueva PDB llamada TEST en source y comprobaremos cuál es el tablespace temporal que tiene asignado por defecto:

SQL> ! hostname
source
SQL> SHOW PDBS

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         3 TEST                           READ WRITE NO

SQL> Select Property_Name, Property_Value 
     From database_properties 
     Where property_name = 'DEFAULT_TEMP_TABLESPACE';

PROPERTY_NAME                                      PROPERTY_VALUE
-------------------------------------------------- ----------------------------------------------------------------------------------------------------
DEFAULT_TEMP_TABLESPACE                            TEMP

2º: Vamos a definir un nuevo grupo tablespace temporal que incluirá dos tablespaces asociados. Como Oracle no ofrece una sintaxis especifica para crear directamente un grupo de tablespaces, debemos indicarlo durante el proceso de creación del propio tablespace.

 SQL> 
 CREATE TEMPORARY TABLESPACE GRP_TMP_TAB_1 TEMPFILE  SIZE 50M TABLESPACE GROUP GRP_TMP;
  Tablespace created.
SQL> 
 CREATE TEMPORARY TABLESPACE GRP_TMP_TAB_2 TEMPFILE  SIZE 50M TABLESPACE GROUP GRP_TMP;
  Tablespace created.

Para consultar el nuevo grupo tablespace temporal podemos usar la vista DBA_TABLESPACE_GROUPS:

SQL> Select * From DBA_TABLESPACE_GROUPS ;

GROUP_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
GRP_TMP                        GRP_TMP_TAB_1
GRP_TMP                        GRP_TMP_TAB_2

Si ya tenemos algún tablespace temporal creado o hemos generado uno nuevo pero aún no lo hemos asignado el grupo, podemos mover el tablespace al grupo haciendo lo siguiente:

SQL> CREATE TEMPORARY TABLESPACE GRP_TMP_TAB_3 TEMPFILE  SIZE 50M ;

Tablespace created.

SQL> ALTER TABLESPACE GRP_TMP_TAB_3 TABLESPACE GROUP GRP_TMP;

Tablespace altered.

SQL>  Select * From DBA_TABLESPACE_GROUPS ;

GROUP_NAME                     TABLESPACE_NAME
------------------------------ ------------------------------
GRP_TMP                        GRP_TMP_TAB_1
GRP_TMP                        GRP_TMP_TAB_2
GRP_TMP                        GRP_TMP_TAB_3

3º: Cómo último paso, configuramos el grupo de tablespaces temporales GRP_TMP como el default temporary tablespace de la base de datos.

SQL>  ALTER DATABASE DEFAULT TEMPORARY TABLESPACE GRP_TMP;

Database altered.

SQL> 
   Select Property_Name, Property_Value 
   From database_properties where property_name = 'DEFAULT_TEMP_TABLESPACE';

PROPERTY_NAME                                      PROPERTY_VALUE
-------------------------------------------------- ----------------------------------------------------------------------------------------------------
DEFAULT_TEMP_TABLESPACE                            GRP_TMP

Cuando marcamos un grupo como default tablespace temporal, ninguno de los tablespaces que lo integran puede eliminarse. Para poder borrarlo, antes debemos asignar otro tablespace temporal como predeterminado.

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[OCI] Proxy PDB]]>https://dbaenlasombra.com/oci-proxy-pdbhttps://dbaenlasombra.com/oci-proxy-pdbTue, 13 Jan 2026 19:52:27 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy, vamos a ver las Proxy PDB.

Pero, ¿Qué es un proxy PDB? Es hacer referencia a otra PDB pero de manera remota o en mismo CDB. Podríamos decir que es algo similar a los clásicos DB Links cuando hacemos referencia a una tabla, pero en este caso no se trata de una tabla, sino de una PDB.

Algunas notas que debemos tener en cuenta:

  • El usuario que utilicemos debe tener el permiso de CREATE PLUGGABLE DATABASE.

  • La PDB debe estar en local undo mode.

  • La PDB debe estar en modo ARCHIVELOG.

  • La PDB que hacemos referencia debe estar OPEN READ WRITE cuando el proxy PDB es creado. Una vez creada, puede ser cambiada.

  • Debemos crear un DB Link que hace referencia tanto a la CDB como a la PDB.

Para poder llevar a cabo este laboratorio, vamos a definir dos máquinas virtuales, ambas con la última versión de Oracle en OCI.

Las máquinas que hemos definido son las siguientes:

  • Source: 26ai VM DB System Oracle Cloud (test_ORI).

  • Target: 26ai VM DB System Oracle Cloud (test_TARGET).

¡Vamos a ello!

1º: Definir la PDB PDB_DAVID en TEST_ORI:

SQL> 
CREATE PLUGGABLE DATABASE PDB_DAVID ADMIN USER ADMIN 
  IDENTIFIED BY ADMIN keystore identified by external store;
Pluggable database created.
SQL> ALTER PLUGGABLE DATABASE PDB_DAVID OPEN;
Pluggable database altered.
SQL> ALTER PLUGGABLE DATABASE PDB_DAVID SAVE STATE;
Pluggable database altered.
SQL> show pdbs
    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         4 PDB_DAVID                      READ WRITE NO
SQL> ! hostname
source

2º: Definir un usuario común. El rol DBA ya incluye tanto CREATE SESSION como CREATE PLUGGABLE DATABASE. Haremos lo mismo en target.

SQL> CREATE USER C##MANAGER IDENTIFIED BY "XXXXXXX";
User created.
SQL> GRANT RESOURCE, DBA, UNLIMITED TABLESPACE TO C##MANAGER CONTAINER=ALL;
Grant succeeded.

3º: Revisamos que la PDB en origen se encuentra local undo mode. En caso que no se encuentre, debemos configurarlo.

SQL> r
  1* Select property_name, property_value 
       From database_properties 
      Where property_name='LOCAL_UNDO_ENABLED'

PROPERTY_NAME        PROPERTY_VALUE
-------------------- ----------------------------------------
LOCAL_UNDO_ENABLED   TRUE

4º: Definimos el DB Links en destino. Para hacerlo diferente, vamos a utilizar easy connect en vez de local naming:

SQL> 
CREATE DATABASE LINK SOURCE_PROXY CONNECT TO C##MANAGER 
  IDENTIFIED BY "XXXXX" 
    USING 'source:1521/pdb_david.XXXXXXXXXXXXXXXX';

Database link created.

SQL> 
SQL>  SELECT * FROM DUAL@SOURCE_PROXY;

D
-
X

5º: Definimos nuestra PDB incluyendo AS PROXY para indicar que vamos a crear una proxy PDB y FROM para especificar la PDB a la que vamos hacer referencia.

SQL> 
CREATE PLUGGABLE DATABASE PDB_DAVID AS PROXY 
  FROM PDB_DAVID@SOURCE_PROXY keystore identified by external store;
Pluggable database created.
SQL> alter pluggable database pdb_david open;
Pluggable database altered.
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB_DAVID                      READ WRITE NO

SQL> r
  1  SELECT pdb_name, is_proxy_pdb
  2* FROM   cdb_pdbs

PDB_NAME                       IS_PROXY_PDB
------------------------------ ----------------------------------------
PDB$SEED                       NO
PDB_DAVID                      YES

Cosas a tener en cuenta:

  • V$PROXY_PDB_TARGETS: Muestra información sobre los detalles de conexión sobre la PDB a la que hace referencia nuestra Proxy PDB.
SQL> r
  1* select * from v$proxy_pdb_targets

    CON_ID TARGET_PORT TARGET_HOST          TARGET_SERVICE                                                                   TARGET_USER
---------- ----------- -------------------- -------------------------------------------------------------------------------- --------------------
         3        1521 source               4843e8f3860c707be063cfdf680abf32.XXXXXXX.XXXXXXX.XXXXXXX.com

  • Los tablespace de SYSTEM y SYSAUX serán copiados y sincronizador con el origen.

  • Solo admite password authentication, no permite OS authentication. Si nos fijamos en el ejemplo de abajo, vemos como funcionan ambos métodos de autenticación y que ocurre al consultar una tabla en nuestra Proxy PDB.

[oracle@target ~]$ sqlplus / as sysdba
Connected to:
Oracle AI Database 26ai EE High Perf Release 23.26.0.0.0 - for Oracle Cloud and Engineered Systems
Version 23.26.0.0.0
SQL> alter session set container= PDB_DAVID;
Session altered.
SQL>  Select * From C##MANAGER.CODIGO_POSTAL;
 Select * From C##MANAGER.CODIGO_POSTAL
                          *
ERROR at line 1:
ORA-00942: table or view "C##MANAGER"."CODIGO_POSTAL" does not exist
Help: https://docs.oracle.com/error-help/db/ora-00942/

SQL> conn C##MANAGER/"XXXXXXXX"@'target:1521/pdb_david.XXXXXXXX.XXXXXXXX.XXXXXXXX.com'
Connected.
SQL>  Select * From C##MANAGER.CODIGO_POSTAL;

ID    POBLACION                                                                                            PAIS
----- ---------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------
46000 Valencia                                                                                             Espa??a
08000 Barcelona                                                                                            Espa??a
28000 Madrid                                                                                               Espa??a
55500 Wisconsin                                                                                            U.S.A.

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[OCI-26ai] Refreshable Clone PDBs]]>https://dbaenlasombra.com/oci-26ai-refreshable-clone-pdbshttps://dbaenlasombra.com/oci-26ai-refreshable-clone-pdbsTue, 23 Dec 2025 15:27:06 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy, vamos a ver como podemos realizar una copia de una PDB y mantenerla actualizada con el origen.

Este tipo de migración, la podemos realizar de manera local (dentro de la misma CDB) o de manera remota (otra CDB). En este artículo nos vamos a centrar en como hacerlo remotamente.

Otro punto que tenemos que tener en cuenta es que debemos tener configurado SEPS ya que vamos a definir las distintas PDB usando external store. En próximos artículos, os explicare como configurar este punto fácilmente.

Para poder llevar a cabo este laboratorio, vamos a definir dos máquinas virtuales, ambas con la última versión de Oracle en OCI.

Las máquinas que hemos definido son las siguientes:

  • Source: 26ai VM DB System Oracle Cloud (test_ORI).

  • Target: 26ai VM DB System Oracle Cloud (test_TARGET).

Y el modelo que vamos a seguir es el siguiente:

  • 1º: Definir la PDB REFRESH_PDB en TEST_ORI:
SQL> CREATE PLUGGABLE DATABASE REFRESH_PDB ADMIN USER admin IDENTIFIED BY admin;
Pluggable database created.
SQL> ALTER PLUGGABLE DATABASE REFRESH_PDB OPEN;
Pluggable database altered.
SQL> ALTER PLUGGABLE DATABASE REFRESH_PDB SAVE STATE;
Pluggable database altered.
SQL> SHOW PDBS

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         4 REFRESH_PDB                    READ WRITE NO
SQL> ! hostname
source
  • 2º: Comprobamos que no hay otra PDB, solo está la PDB$SEED.
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
SQL> ! hostname
target
  • 3º: Definir un common user, no local user. El usuario debe llamarse igual y debe tener la misma contraseña en origen como destino.
SQL> CREATE USER C##MANAGER IDENTIFIED BY "XXXXXX";
User created.
SQL> GRANT CREATE SESSION, RESOURCE, CREATE ANY TABLE, UNLIMITED TABLESPACE TO C##MANAGER CONTAINER=ALL;
Grant succeeded.
SQL> GRANT CREATE PLUGGABLE DATABASE TO C##MANAGER CONTAINER=ALL;
Grant succeeded.
SQL> GRANT SYSOPER TO C##MANAGER CONTAINER=ALL;
Grant succeeded.
  • 4º: Definir los DB Links. Antes de definirlo, debemos modificar el tnsnames para incluir ambas cadenas de conexión.

Origen:

SQL> ! hostname
source

SQL> ! tail -8  $ORACLE_HOME/network/admin/tnsnames.ora
TARGET =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = XXXXXXXXXXXXXXXXXXXX)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XXXXXXXXXXXXXXXXXXXX)
    )
  )

Destino:

SQL> ! hostname
target
SQL> ! tail -8  $ORACLE_HOME/network/admin/tnsnames.ora
SOURCE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = XXXXXXXXXXXXXXXXXXXX)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = XXXXXXXXXXXXXXXXXXXX)
    )
  )

Una vez que tenemos modificado el tnsnames, podemos definir el DB Link en target y en source.

SQL> CREATE DATABASE LINK DB_Source CONNECT TO C##MANAGER IDENTIFIED BY "XXXXXXXXX" USING 'SOURCE';
Database link created.
SQL> Select * From Dual@DB_Source;
D
-
X

Una vez que hemos comprobado que el DB funciona correctamente, ya podemos definir nuestra PDB.

La PDB en origen no contiene nada de información ahora mismo, así que vamos a definir algo en ella antes de clonarla.

SQL> alter session set container=REFRESH_PDB;
Session altered.
SQL> CREATE TABLE C##MANAGER.COPY_NUMERICOS AS 
     SELECT ROWNUM NUM 
       FROM DUAL 
    CONNECT BY ROWNUM <= 1000000;
Table created.
  • 5º: Procedemos a clonar nuestra PDB usando external store:
SQL> CREATE PLUGGABLE DATABASE REFRESH_PDB FROM REFRESH_PDB@DB_Source REFRESH MODE MANUAL keystore identified by external store;

Pluggable database created.

Si nos fijamos en la sentencia que hemos ejecutado, hemos indicado REFRESH MODE MANUAL.

Cuando definimos la PDB como REFRESH MODE MANUAL, la PDB no se actualiza de manera automática, en cambio si la definimos REFRESH MODE EVERY <min>, la PDB sí se actualiza de manera automática.

El estado de la PDB que nos marca DBA_PDBs es REFRESHING.

SQL> select con_id, pdb_name, status, refresh_mode, refresh_interval from dba_pdbs where pdb_name='REFRESH_PDB';

    CON_ID PDB_NAME             STATUS               REFRESH_MODE         REFRESH_INTERVAL
---------- -------------------- -------------------- -------------------- ----------------
         3 REFRESH_PDB          REFRESHING           MANUAL

Abrimos las PDB en modo lectura y consultamos si la tabla se encuentra en la PDB

SQL> ALTER SESSION SET CONTAINER=REFRESH_PDB;
Session altered.
SQL> ALTER PLUGGABLE DATABASE OPEN READ ONLY;
Pluggable database altered.
SQL> SELECT COUNT(*) FROM C##MANAGER.COPY_NUMERICOS;

  COUNT(*)
----------
   1000000

Volvemos a insertar registros en la tabla y refrescamos de nuevo la PDB.

 SQL> ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE REFRESH;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE OPEN READ ONLY;

Pluggable database altered.

SQL>  SELECT COUNT(*) FROM C##MANAGER.COPY_NUMERICOS;

  COUNT(*)
----------
   2000000

Perfecto, tenemos ambas PDBs sincronizadas.

Como último paso, podemos hacer dos cosas:

  • Finalizar, es decir, que pase de refreshable clone a regular PDB:
SQL> ALTER PLUGGABLE DATABASE CLOSE IMMEDIATE;
Pluggable database altered.
SQL>  alter pluggable database refresh mode none;
Pluggable database altered.
SQL> ALTER PLUGGABLE DATABASE OPEN;
Pluggable database altered.

SQL> select con_id, pdb_name, status, refresh_mode, refresh_interval 
     from dba_pdbs where pdb_name='REFRESH_PDB';

    CON_ID PDB_NAME             STATUS               REFRESH_MODE         REFRESH_INTERVAL
---------- -------------------- -------------------- -------------------- ----------------
         3 REFRESH_PDB          NORMAL               NONE

  • Switch the roles: Nuestra PDB de source pasará de NORMAL a REFRESHING y la PDB de target de REFRESHING a NORMAL:

    Origen:

      SQL> col pdb_name format a15
  SQL>  set linesize 1000
  SQL> select con_id, pdb_name, status, refresh_mode, refresh_interval from dba_pdbs where pdb_name='REFRESH_PDB';

      CON_ID PDB_NAME        STATUS     REFRES REFRESH_INTERVAL
  ---------- --------------- ---------- ------ ----------------
           4 REFRESH_PDB     NORMAL     NONE

  SQL> ALTER SESSION SET CONTAINER = REFRESH_PDB;                                                                 

  Session altered.

  SQL>  ALTER PLUGGABLE DATABASE REFRESH MODE MANUAL FROM REFRESH_PDB@DB_Target SWITCHOVER;

  Pluggable database altered.

  SQL> alter pluggable database open read only;

  Pluggable database altered.

  SQL> select con_id, pdb_name, status, refresh_mode, refresh_interval from dba_pdbs where pdb_name='REFRESH_PDB';

      CON_ID PDB_NAME        STATUS     REFRES REFRESH_INTERVAL
  ---------- --------------- ---------- ------ ----------------
           4 REFRESH_PDB     REFRESHING MANUAL

    Destino:

      SQL> r
    1* select con_id, pdb_name, status, refresh_mode, refresh_interval from dba_pdbs where pdb_name='REFRESH_PDB'

      CON_ID PDB_NAME        STATUS     REFRES REFRESH_INTERVAL
  ---------- --------------- ---------- ------ ----------------
           3 REFRESH_PDB     REFRESHING MANUAL

  SQL> alter pluggable database refresh_pdb open read only;

  Pluggable database altered.

  SQL> select con_id, pdb_name, status, refresh_mode, refresh_interval from dba_pdbs where pdb_name='REFRESH_PDB';

      CON_ID PDB_NAME        STATUS     REFRES REFRESH_INTERVAL
  ---------- --------------- ---------- ------ ----------------
           3 REFRESH_PDB     NORMAL     NONE

    Así de sencillo podemos cambiar los roles.

Espero que os guste. ¡Nos vemos en el próximo artículo!

]]><![CDATA[[OCI] Resource Scheduler]]>https://dbaenlasombra.com/oci-resource-schedulerhttps://dbaenlasombra.com/oci-resource-schedulerSat, 25 Oct 2025 12:16:13 GMTEl artículo también se encuentra publicado en Ingles English version.

Uno de los puntos que hay que tener en cuenta a la hora de crear nuevos entornos en OCI es la gestión de apagado/encendido de los entornos para reducir los costes dentro de la tenancy de nuestros clientes.

Desde Mayo del 2024, OCI lanzo el servicio de “OCI resource scheduler“ para facilitarnos esta tarea. Antes de esa fecha, podríamos controlarlo con alguno de estos métodos:

  • Crontab. Normalmente, en el entorno de producción se configuraba dentro del usuario opc un shell script con el listado de nodos que se deberían apagar/arrancar.

    Ese sh se ejecutaba dentro de una tarea planificada:

[opc ~]$ crontab -l
 30 7 * * 1,2,3,4,5 /home/opc/dbsystem/start_dbsystem.sh >> /home/opc/dbsystem/start_dbsystem.log
[opc ~]$ cat /home/opc/dbsystem/start_dbsystem.sh
#!/bin/bash
cd /home/opc/dbsystem 

NODE_SWITCH=<OCID>

. ./oci-curl.sh

oci-curl <END_POINT> POST ./empty.json /20160918/dbNodes/${NODE_SWITCH}?action=start

  • Auto Scaling para OCI. el gran Richard Garsthagen tiene publicado en su github un repositorio denominado OCI-AutoScale (link repositorio) para gestionar este tipo de operaciones por medio de tags.

    Cuando realizas la instalación de OCI-AutoScale en una instancia, uno de los pasos es definir en la etiqueta Schedule:

    Asociaríamos esas etiquetas a las instancias que queremos aplicarlo:

    En este ejemplo, tendríamos dos etiquetas aplicadas, son:

    • Weekend: Apagado el fin de semana.

    • WeekDay: Encendido ciertas horas. La traducción de “0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0” sería la tabla de la izquierda.

OCI resource scheduler

Estos son los pasos que vamos a seguir para utilizar Resource Scheduler:

Antes de ver como trabaja este servicio en OCI, debemos de asegurarnos que:

  • El usuario que utilicemos tiene permisos para crear schedules.

      Allow any-user to manage resource-schedule-family in tenancy

  • Debemos asegurarnos que a nivel schedule se le han dado permisos para administrar recursos en nuestro tenancy.

      Allow any-user to manage all-resources in compartment '<compartment>' where all{request.principal.type='resourceschedule'}

  • Definimos una instancia para testear el nuevo servicio:

Después de asegurarnos que tenemos todos esos puntos, ya podríamos configurar nuestro servicio, ¡vamos a ello!

Vamos a la sección “Governance & Administration” y “Schedules”

Una vez dentro, veremos la siguiente ventana. Aquí solo debemos pulsar en “Create a schedule”:

En la primera parte tendremos que cumplimentar la información básica, como es un nombre y la acción a realizar, en nuestro caso es start.

En la siguiente ventana, debemos seleccionar el recurso de nuestra tenancy que queremos aplicar este servicio:

Si nos fijamos bien, tenemos un filtro con dos valores: Static o Dynamic. La diferencia entre ambos, es que Static, sería aplicarlo de manera individual, es decir, a un único recurso (este sería nuestro caso) o Dynamic, que sería aplicarlo a un conjunto de recursos que cumplan el siguiente criterio:

  • Tag: Aplica a todos los recursos que lleven ese tag.

  • Resource Type: Los tipos de recurso a los que se puede aplicar son: Instance, InstancePool, AutonomousDatabase, Function o DBSystem.

  • Compartment: Podemos seleccionar un compartment especifico o que aplique a todos.

  • Status: Los estados son Available, Running, Stopped o que aplique a todos

Seleccionamos Static y seleccionamos la instancia en el que queremos aplicarlo:

En la siguiente ventana sería para agregar parámetros a nuestro recurso que hemos seleccionado en el paso anterior. En nuestro caso no aplica.

La siguiente ventana es la más importante, porque vamos a definir la hora de arranque.

La primera opción es, como quieres definir la información referente al schedule, si bien desde la propia interface “Form Interface“ o bien desde “Cron expression”. Como vamos ha definir dos, uno de arranque y otro de parada, probaremos los dos.

En nuestro caso, para el arranque vamos a seleccionar “Cron expression”

Las opciones que vemos son:

  • Recurrence details: Una pequeña descripción, es opcional. Cuidado con este punto, porque en caso de que seleccionemos vía cron, debemos informar ahí la Cron expression.

    De no hacerlo, no salta un error interno a la hora de crearlo:

    Nuestra Cron expression es: “30 12 \ * *“*.

  • Time: En formato de 24h-UTC, sería la hora en la que se ejecuta.

  • Start date: Que día empieza a estar vigente. Podemos introducir la fecha a mano o por medio del calendario.

  • End date: Si queremos marcar una fecha fin, es opcional.

La última ventana sería como un resumen del schedule que vamos a definir .

Para el apagado será exactamente igual salvo la información referente al schedule, donde la vamos a definir como From interface:

Con esto ya tenemos definidos el arranque/parada de nuestra instancia.

Si volvemos a la ventana del principio, podemos ver que nuestros schedules se están ejecutando correctamente:

Listo, de esta manera tan sencilla podemos controlar el arranque/apagado de nuestros recursos.

Espero que os sirva :)

]]><![CDATA[[23ai] Shadow Tablespaces]]>https://dbaenlasombra.com/23ai-shadow-tablespaceshttps://dbaenlasombra.com/23ai-shadow-tablespacesSat, 04 Oct 2025 17:22:33 GMTEl artículo también se encuentra publicado en Ingles English version.

En el artículo de hoy vamos hablar sobre un tipo de tablespace que se “encuentran” nunca mejor dicho, en la sombra de la página oficial de Oracle, son los Shadow Tablespaces.

Este tipo de tablespace no es un feature de la 23ai, sino que existen desde la 18c en adelante.

Antes de entrar en detalle, no tiene ningún tipo de relación con el parámetro DB_LOST_WRITE_PROTECT, podríamos decir que tiene un propósito parecido pero van por caminos diferentes.

Propósito

Shadow Tablespace es un tablespace, en 23ai de tipo bigfile, destinado a protegernos rápidamente cuando se producen pérdidas de escritura en tablespaces o datafiles, minimizando el tiempo requerido para reparar una base de datos.

¿Cómo trabaja?

Para poder usar esta funcionalidad, necesitamos un shadow tablespace y un no-shadow tablespace.

Vamos a ver un pequeño modelo de como funciona:

Aquí podemos ver un shadow tablespace “*STTab001*” rastreando dos tablespaces muy distintos entre si, uno es de tipo bigfile “*Tab002*”, y el otro es de tipo smallfile “*SmallTab001*”.

Esta pequeña diferencia es que quiero que veamos como podemos ligarlos a un tablespace o un datafile, y la manera de tener en 23ai varios datafiles en un tablespace, es definiéndolo de tipo smallfile (bigfile solo puede tener un datafile).

Vamos a configurarlo en nuestra PDB.

Lo primero que debemos crear es definir el tablespace “shadow tablespace“ antes de activarlo, porque si lo hacemos al revés, primero activar y después crear, recibiremos el siguiente error:

SQL> ALTER PLUGGABLE DATABASE ENABLE LOST WRITE PROTECTION;
ALTER PLUGGABLE DATABASE ENABLE LOST WRITE PROTECTION
*
ERROR at line 1:
ORA-65491: A lost write bigfile tablespace must exist before attempting to enable lost write.
Help: https://docs.oracle.com/error-help/db/ora-65491/

Vamos a crear primero STTab001:

SQL> CREATE BIGFILE TABLESPACE STTab001 DATAFILE SIZE 10M LOST WRITE PROTECTION;

Tablespace created.

Una vez creado, procedemos activarlo en nuestra PDB:

SQL> r
  1* select PROPERTY_NAME, PROPERTY_VALUE from database_properties where PROPERTY_NAME='NEW_LOST_WRITE'

no rows selected

SQL>  ALTER PLUGGABLE DATABASE ENABLE LOST WRITE PROTECTION;

Pluggable database altered.

SQL> r
  1* select PROPERTY_NAME, PROPERTY_VALUE from database_properties where PROPERTY_NAME='NEW_LOST_WRITE'

PROPERTY_NAME        PROPERTY_VALUE
-------------------- --------------------
NEW_LOST_WRITE       TRUE

Si nosotros lo hubiéramos intentado habilitar desde CDB$Root para que aplique a todas las PDB, hubiéramos recibido el siguiente error:

SQL> alter session set container=cdb$root;

Session altered.

SQL> CREATE BIGFILE TABLESPACE STTab001 DATAFILE SIZE 10M LOST WRITE PROTECTION;

Tablespace created.

SQL> ALTER PLUGGABLE DATABASE ENABLE LOST WRITE PROTECTION;
ALTER PLUGGABLE DATABASE ENABLE LOST WRITE PROTECTION
*
ERROR at line 1:
ORA-65046: operation not allowed from outside a pluggable database
Help: https://docs.oracle.com/error-help/db/ora-65046/

Definimos ambos tablespaces:

SQL> CREATE BIGFILE   TABLESPACE Tab002 DATAFILE SIZE 10M;
Tablespace created.

SQL> CREATE SMALLFILE TABLESPACE SmallTab001 DATAFILE SIZE 1M ;
Tablespace created.

SQL> ALTER TABLESPACE SmallTab001 ADD DATAFILE SIZE 1M: 
Tablespace altered.

Verificamos el paso previo:

SQL> r
  Select tablespace_name, contents, lost_write_protect from dba_tablespaces

TABLESPACE_NAME                CONTENTS              LOST_WR
------------------------------ --------------------- -------
SYSTEM                         PERMANENT             OFF
SYSAUX                         PERMANENT             OFF
UNDOTBS1                       UNDO                  OFF
TEMP                           TEMPORARY             OFF
USERS                          PERMANENT             OFF
STTAB001                       LOST WRITE PROTECTION OFF
TAB002                         PERMANENT             OFF
SMALLTAB001                    PERMANENT             OFF

SQL> r
  1   Select Tablespace_Name,LOST_WRITE_PROTECT ,File_Name, File_Id
  2     From Dba_Data_Files
  3    Where Tablespace_Name in ('STTAB001','TAB002','SMALLTAB001')
  4*  order by file_id

TABLESPACE_NAME                LOST_WR FILE_NAME                                                                                               FILE_ID
------------------------------ ------- ---------------------------------------------------------------------------------------------------- ----------
STTAB001                       OFF     +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/sttab001.280.1213616675                       13
TAB002                         OFF     +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/tab002.281.1213625663                         14
SMALLTAB001                    OFF     +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/smalltab001.282.1213625677                    15
SMALLTAB001                    OFF     +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/smalltab001.283.1213625699                    16

Habilitamos la protección de datos a dos niveles:

  • A nivel de tablespace TAB002

  • A nivel de datafiles de SMALLTAB001.

SQL> ALTER TABLESPACE TAB002 ENABLE LOST WRITE PROTECTION;

Tablespace altered.

SQL> ALTER DATABASE DATAFILE '+DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/smalltab001.283.1213625699' ENABLE LOST WRITE PROTECTION;

Database altered.

Verificamos de nuevo que la protección la tenemos activa en ambos tablespace:

SQL> Select tablespace_name, contents, lost_write_protect from dba_tablespaces;

TABLESPACE_NAME                CONTENTS              LOST_WR
------------------------------ --------------------- -------
SYSTEM                         PERMANENT             OFF
SYSAUX                         PERMANENT             OFF
UNDOTBS1                       UNDO                  OFF
TEMP                           TEMPORARY             OFF
USERS                          PERMANENT             OFF
STTAB001                       LOST WRITE PROTECTION OFF
TAB002                         PERMANENT             ENABLED
SMALLTAB001                    PERMANENT             OFF

8 rows selected.

SQL> r
  1   Select Tablespace_Name,LOST_WRITE_PROTECT ,File_Name, File_Id
  2     From Dba_Data_Files
  3    Where Tablespace_Name in ('STTAB001','TAB002','SMALLTAB001')
  4*  order by file_id

TABLESPACE_NAME                LOST_WR FILE_NAME                                                                                               FILE_ID
------------------------------ ------- ---------------------------------------------------------------------------------------------------- ----------
STTAB001                       OFF     +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/sttab001.280.1213616675                       13
TAB002                         ENABLED +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/tab002.281.1213625663                         14
SMALLTAB001                    OFF     +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/smalltab001.282.1213625677                    15
SMALLTAB001                    ENABLED +DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/smalltab001.283.1213625699                    16

Como veis es muy sencillo activarlo.

Para desactivarlo, sería de la siguiente manera:

SQL> ALTER TABLESPACE TAB002 REMOVE LOST WRITE PROTECTION;

Tablespace altered.

SQL> ALTER PLUGGABLE DATABASE DATAFILE '+DATA/DB23AI_FWX_MAD/4004456EB4523134E0634C00000AA230/DATAFILE/smalltab001.283.1213625699' SUSPEND LOST WRITE PROTECTION;

Pluggable database altered.

SQL> ALTER PLUGGABLE DATABASE DISABLE LOST WRITE PROTECTION;

Pluggable database altered.

SQL> DROP TABLESPACE STTAB001 INCLUDING CONTENTS AND DATAFILES;

Tablespace dropped.

Espero que os sirva :)

]]><![CDATA[[OGG] Lentitud de replicat]]> info all Prog...]]>https://dbaenlasombra.com/ogg-lentitud-de-replicathttps://dbaenlasombra.com/ogg-lentitud-de-replicatSun, 28 Sep 2025 15:53:21 GMTEl artículo también se encuentra publicado en Ingles English version.

Hoy vamos a ver un caso sencillo de un proceso de replicat en OGG que corre demasiado lento.

La situación del OGG cuando me pidieron ayuda era la siguiente:

GGSCI 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXXX        00:00:06      00:00:09
REPLICAT    RUNNING     Rxxx        53:14:49      00:00:03

El proceso de replicat RXXX llevaba una semana donde el lag siempre estaba en constante crecimiento, nunca disminuyendo.

Antes de entra en faena, hay que decir que la versión del ogg es una 19.1.0.0.4.

Lo primero que vamos a ver son las estadísticas del proceso con la tasa de procesamiento en minutos a ver si nos da alguna pista:

GGSCI 4> stats replicat Rxxx, totalsonly *.*, reportrate min

Sending STATS request to REPLICAT Rxxx...

Start of Statistics at 2025-09-28 00:23:05.

DDL replication statistics:

*** Total statistics since replicat started     ***
        Operations                                       104.00
        Mapped operations                                  0.00
        Unmapped operations                              104.00
        Other operations                                   0.00
        Excluded operations                                0.00
        Errors                                             0.00
        Retried errors                                     0.00
        Discarded errors                                   0.00
        Ignored errors                                     0.00

Cumulative totals for specified table(s):

*** Total statistics since 2025-09-27 23:19:02 ***
        Total inserts/minute                       0.00
        Total updates/minute                       0.00
        Total deletes/minute                       0.00
        Total upserts/minute                       0.00
        Total discards/minute                  13497.48
        Total operations/minute                    0.00

*** Daily statistics since 2025-09-28 00:00:00 ***

        No database operations have been performed.

*** Hourly statistics since 2025-09-28 00:00:00 ***

        No database operations have been performed.

*** Latest statistics since 2025-09-27 23:19:02 ***
        Total inserts/minute                       0.00
        Total updates/minute                       0.00
        Total deletes/minute                       0.00
        Total upserts/minute                       0.00
        Total discards/minute                 864456.00
        Total operations/minute                    0.00

End of Statistics.

Ahí ya podemos ver algún problema de performance ya que el nº de operations es muy bajo al igual que apenas hay estadísticas en las operaciones dml.

Miramos las definición del proceso:

REPLICAT Rxxx

useridalias ogg_xxxx
assumetargetdefs

DDL INCLUDE ALL
DDLERROR DEFAULT IGNORE

discardfile ./dirrpt/Rxxx.dsc, Append,megabytes 4000
REPERROR (0001,discard)
REPERROR (1403,discard)

TABLE SCHEMA.TABLE , TARGET PDB.SCHEMA.TABLE;

Ahí podemos ver que el origen es un single instance y el destino es multitenant, esto no tiene que tener percance en el performance, pero si es un dato que hay que tener en cuenta.

Mirando las distintas propiedades, hecho en falta el HANDLECOLLISIONS, este parámetro es muy útil para ayudar a resolver conflictos a la hora de replicar la información, estos conflictos son llamados colisiones.

Este parámetro ayuda a OGG a resolver esas colisiones más eficientemente como son:

  • Insert: Se intenta realizar un insert cuando la fila ya existe en el destino.

  • Update: Se intenta realiza una operación de update en el destino cuándo la fila aún no existe

  • Delete: Se intentan hacer el borrado de un registro cuando la fila no existe en el destino.

Modificamos nuestro proceso para incluir el parámetro quedando de la siguiente manera:

REPLICAT Rxxx

useridalias ogg_xxxx
assumetargetdefs

DDL INCLUDE ALL
DDLERROR DEFAULT IGNORE
HANDLECOLLISIONS

discardfile ./dirrpt/Rxxx.dsc, Append,megabytes 4000
REPERROR (0001,discard)
REPERROR (1403,discard)

TABLE SCHEMA.TABLE , TARGET PDB.SCHEMA.TABLE;

Activamos y esperamos unas horas para ver si ya va mejor.

Efectivamente, el proceso de replicat va mucho mejor, cada vez el lag está más cerca del valor cero.

GGSCI 1> info all

Program     Status      Group       Lag at Chkpt  Time Since Chkpt

MANAGER     RUNNING
EXTRACT     RUNNING     EXXX        00:00:02      00:00:07
REPLICAT    RUNNING     Rxxx        26:38:41      00:00:00

Vamos a ver de nuevo las estadísticas del proceso:

GGSCI 3>   stats replicat Rxxx, totalsonly *.*, reportrate min

Sending STATS request to REPLICAT Rxxx...

Start of Statistics at 2025-09-28 12:19:43.

DDL replication statistics:

*** Total statistics since replicat started     ***
        Operations                                      4804.00
        Mapped operations                                  5.00
        Unmapped operations                             4799.00
        Other operations                                   0.00
        Excluded operations                                0.00
        Errors                                             7.00
        Retried errors                                     0.00
        Discarded errors                                   0.00
        Ignored errors                                     6.00

Cumulative totals for specified table(s):

*** Total statistics since 2025-09-28 00:26:27 ***
        Total inserts/minute                   63670.08
        Total updates/minute                       0.00
        Total deletes/minute                   54358.40
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute               118028.47
        Total insert collisions/minute         63670.08
        Total delete collisions/minute         31318.92

*** Daily statistics since 2025-09-28 00:26:27 ***
        Total inserts/minute                   63670.08
        Total updates/minute                       0.00
        Total deletes/minute                   54358.40
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute               118028.47
        Total insert collisions/minute         63670.08
        Total delete collisions/minute         31318.92

*** Hourly statistics since 2025-09-28 12:00:00 ***
        Total inserts/minute                    7272.71
        Total updates/minute                       0.00
        Total deletes/minute                  421092.52
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute               428365.24
        Total insert collisions/minute          7272.71
        Total delete collisions/minute        421092.52

*** Latest statistics since 2025-09-28 00:26:27 ***
        Total inserts/minute                45413289.00
        Total updates/minute                       0.00
        Total deletes/minute                38771646.00
        Total upserts/minute                       0.00
        Total discards/minute                      0.00
        Total operations/minute             84184935.00
        Total insert collisions/minute      45413289.00
        Total delete collisions/minute      22338520.00

End of Statistics.

El nº de operations ha pasado de 104, a tener más de 4000 con un flujo de operaciones dml correcto.

El problema de performance se ha resuelto.

Caso Cerrado Telemundo GIF by Universo (imagen GIF)

Espero que os sirva :)

]]><![CDATA[[23ai] Instalación de Oracle23ai en OraLinux9]]>https://dbaenlasombra.com/23ai-instalacion-de-oracle23ai-en-oralinux9https://dbaenlasombra.com/23ai-instalacion-de-oracle23ai-en-oralinux9Fri, 05 Sep 2025 09:25:37 GMTEl artículo también se encuentra publicado en Ingles English version.

En este pequeño artículo, vamos a ver a definir una base de datos 23ai con Oracle Database Configuration Assistant (DBCA).

Para poder hacer este laboratorio me he creado un IaaS en OCI con Oracle Linux 9. Es un entorno nuevo con lo que el primer paso que vamos a realizar es la instalación de Oracle 23ai, así que vamos a ello.

[root@~]# grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Oracle Linux Server 9.6"

Para poder realizar la instalación de esta versión, nos vamos apoyar en los siguientes rpm:

[root@test1 tmp]# ls -lac *rpm
-rw-r--r--. 1 root root 1412957372 Sep  2 09:47 oracle-database-free-23ai-23.9-1.el9.x86_64.rpm
-rw-r--r--. 1 root root      30688 Sep  2 09:30 oracle-database-preinstall-23c-1.0-0.5.el8.x86_64.rpm

Dejo a continuación donde podemos descargar cada uno de ellos:

  • oracle-database-preinstall-23c-1.0-0.5.el8.x86_64.rpm, lo podemos descargar desde aquí.

  • oracle-database-free-23ai-23.9-1.el9.x86_64.rpm. Este rpm lo podemos descargar desde aquí.

Instalación y Configuración

  • Instalación del RPM oracle-database-preinstall-23c-1.0-0.5.el8.x86_64.rpm:
[root@tmp]# dnf install oracle-database-preinstall-23c-1.0-0.5.el8.x86_64.rpm -y
Last metadata expiration check: 1:54:40 ago on Tue 02 Sep 2025 07:46:07 AM GMT.
Dependencies resolved.
....
....
Complete!
  • Instalación del RPM oracle-database-free-23ai-23.9-1.el9.x86_64.rpm:
[root@test1 tmp]# wget https://objectstorage.....
[root@test1 tmp]# dnf install oracle-database-free-23ai-23.9-1.el9.x86_64.rpm -y
Last metadata expiration check: 2:06:18 ago on Tue 02 Sep 2025 07:46:07 AM GMT.
Dependencies resolved.
....
....                                                                                                                                     3/3
Installed:
  oracle-database-free-23ai-23.9-1.x86_64                                                         oracle-database-preinstall-23ai-1.0-3.el9.x86_64
Complete!

Gracias a la instalación de ambos rpm, tendremos el siguiente script oracle-free-23ai en /etc/init.d para poder crear nuestra bbdd 23ai. Antes de ejecutar el script, debemos setear la variable DB_PASSWORD.

[root@test1 tmp]#  export DB_PASSWORD=oracle
[root@test1 tmp]# (echo "${DB_PASSWORD}"; echo "${DB_PASSWORD}";) | /etc/init.d/oracle-free-23ai configure
Specify a password to be used for database accounts. Oracle recommends that the password entered should be at least 8 characters in length, contain at least 1 uppercase character, 1 lower case character and 1 digit [0-9]. Note that the same password will be used for SYS, SYSTEM and PDBADMIN accounts:
Confirm the password:
Configuring Oracle Listener.
Listener configuration succeeded.
Configuring Oracle Database FREE.
Enter SYS user password:
*****
Enter SYSTEM user password:
********
Enter PDBADMIN User Password:
*********
Prepare for db operation
7% complete
Copying database files
29% complete
Creating and starting Oracle instance
30% complete
33% complete
36% complete
39% complete
43% complete
Completing Database Creation
47% complete
49% complete
50% complete
Creating Pluggable Databases
54% complete
71% complete
Executing Post Configuration Actions
93% complete
Running Custom Scripts
100% complete
Database creation complete. For details check the logfiles at:
 /opt/oracle/cfgtoollogs/dbca/FREE.
Database Information:
Global Database Name:FREE
System Identifier(SID):FREE
Look at the log file "/opt/oracle/cfgtoollogs/dbca/FREE/FREE.log" for further details.

Connect to Oracle Database using one of the connect strings:
     Pluggable database: test1/FREEPDB1
     Multitenant container database: test1

Listo, en este punto tendríamos una 23ai lista para poder trabajar. Vamos a configurar los ficheros .bashrc y .bash_profile para que sea más sencillo interactuar con los binarios de Oracle, como por ejemplo sqlplus, dbca, o tkproff.

Abajo podemos ver el .bashrc después de actualizarlo:

# .bashrc
# Source global definitions
if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi
# User specific environment
if ! [[ "$PATH" =~ "$HOME/.local/bin:$HOME/bin:" ]]
then
    PATH="$HOME/.local/bin:$HOME/bin:$PATH"
fi
export PATH
# Uncomment the following line if you don't like systemctl's auto-paging feature:
# export SYSTEMD_PAGER=
# User specific aliases and functions
if [ -d ~/.bashrc.d ]; then
        for rc in ~/.bashrc.d/*; do
                if [ -f "$rc" ]; then
                        . "$rc"
                fi
        done
fi
ORACLE_HOME=/opt/oracle/product/23ai/dbhomeFree; export ORACLE_HOME
PATH=/bin:/usr/bin:/usr/local/sbin:/usr/sbin:$ORACLE_HOME/bin:$ORACLE_HOME/lib:$ORACLE_HOME/OPatch/:$ORACLE_HOME/lib; export PATH
LD_LIBRARY_PATH=${ORACLE_HOME}/lib; export LD_LIBRARY_PATH

ORACLE_SID=FREE; export ORACLE_SID
PDB_NAME=FREEPDB1; export PDB_NAME

Nuestra idea inicial no es trabajar con esta versión, sino testear dbca para realizar lo siguiente:

  • Generar el template de la actual 23ai

  • Eliminar esta base de datos que hemos creado previamente.

  • Crear una nueva basa de datos usando el fichero response junto con el template.

Todo estos puntos se ejecutaran en modo -silent. Essta opción nos permitirá ejecutarr dbca en silent mode.

Generar el template

[oracle@test1 ~]$ dbca -silent \
-createTemplateFromDB \
-sourceDB FREE \
-templateName FREE.template \
-sysDBAUserName SYS \
-sysDBAPassword oracle
Prepare for db operation
33% complete
Creating a template from the database
37% complete
40% complete
43% complete
47% complete
50% complete
53% complete
57% complete
60% complete
63% complete
67% complete
Creating template
100% complete
The template "/opt/oracle/product/23ai/dbhomeFree/assistants/dbca/templates/FREE.template.dbt" creation completed.
Look at the log file "/opt/oracle/cfgtoollogs/dbca/silent.log_2025-09-02_12-09-54PM_170638" for further details.

Eliminar la BBDD

Eliminamos la BBDD previamente habiendo hecho un shutdown.

[oracle@test1 ~]$ dbca -silent \
-deleteDatabase \
-sourceDB FREE \
-sysDBAUserName sys \
-sysDBAPassword oracle
[WARNING] [DBT-11503] The instance (FREE) is not running on the local node. This may result in partial delete of Oracle database.
   CAUSE: A locally running instance is required for complete deletion of Oracle database instance and database files.
   ACTION: Specify a locally running database, or execute DBCA on a node where the database instance is running.
[WARNING] [DBT-19202] The Database Configuration Assistant will delete the Oracle instances and datafiles for your database. All information in the database will be destroyed.
Prepare for db operation
32% complete
Connecting to database
35% complete
39% complete
42% complete
45% complete
48% complete
52% complete
65% complete
Updating network configuration files
68% complete
Deleting instance and datafiles
84% complete
100% complete
Database deletion completed.
Look at the log file "/opt/oracle/cfgtoollogs/dbca/FREE/FREE0.log" for further details.

Creación de la BBDD

Para la creación de la BBDD vamos a trabajar con los siguientes ficheros:

[oracle@test1 ~]$ ls -lac config/
total 52
drwxr-xr-x. 2 oracle oinstall    49 Sep  3 06:35 .
drwx------. 3 oracle oinstall   127 Sep  2 15:47 ..
-rw-r-----. 1 oracle oinstall 20942 Sep  2 15:47 FREE.template.dbt
-rw-r-----. 1 oracle oinstall 25378 Sep  3 06:35 shadow.rsp
  • FREE.template.dbt, el template que hemos generado en el paso previo. Lo vamos a editar porque solo queremos que nos defina la seed. Para ello, procedemos a eliminar todas las referencias de FREEPDB1:

  • shadow.rsp. Es el fichero response para automatizar el dbca. Es una copia del fichero $ORACLE_HOME/assistants/dbca/dbca.rsp modificado para nuestro caso.

    Los valores que contiene el response son los siguientes:

      [oracle@test1 ~]$ more config/shadow.rsp | grep -v ^$ | grep -v ^#
  responseFileVersion=/oracle/assistants/rspfmt_dbca_response_schema_v23.0.0
  gdbName=FREE
  sid=FREE
  createAsContainerDatabase=true
  numberOfPDBs=0
  templateName=/home/oracle/config/FREE.template.dbt
  sysPassword=*********
  systemPassword=********

Una vez modificado ambos ficheros, lanzamos la creación de nuestra 23ai vía dbca en silent mode:

[oracle@test1 ~]$ dbca -createDatabase -silent -responseFile /home/oracle/config/shadow.rsp
Prepare for db operation
4% complete
Creating and starting Oracle instance
5% complete
6% complete
8% complete
Creating database files
12% complete
Creating data dictionary views
13% complete
16% complete
17% complete
18% complete
24% complete
Oracle JVM
30% complete
36% complete
42% complete
44% complete
Oracle Text
46% complete
48% complete
Oracle OLAP
52% complete
Oracle Spatial
53% complete
60% complete
Oracle Label Security
68% complete
Oracle Database Vault
76% complete
Creating cluster database views
77% complete
84% complete
Completing Database Creation
86% complete
88% complete
Executing Post Configuration Actions
100% complete
Database creation complete. For details check the logfiles at:
 /opt/oracle/cfgtoollogs/dbca/FREE.
Database Information:
Global Database Name:FREE
System Identifier(SID):FREE
Look at the log file "/opt/oracle/cfgtoollogs/dbca/FREE/FREE10.log" for further details

Nos conectamos a la base de datos como SYS:

[oracle@test1 ~]$ sqlplus /nolog

SQL*Plus: Release 23.0.0.0.0 - Production on Wed Sep 3 09:57:09 2025
Version 23.9.0.25.07

Copyright (c) 1982, 2025, Oracle.  All rights reserved.

SQL>
SQL> conn / as sysdba
Connected.
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO

La base de datos se encuentra levantada y solo nos ha creado la seed, tal y como habíamos configurado en nuestro template.

Vamos hacer una prueba más jugando con el parámetro numberOfPDBs. Este parámetro indica el número de PDBs que se deben crear. Si nos fijamos, el fichero response que hemos usado tenía especificado que el número de PDB es cero, acorde a nuestro template.

[oracle@test1 ~]$ grep numberOfPDBs  config/shadow.rsp
# Name          : numberOfPDBs
numberOfPDBs=0

Pero, ¿Qué sucede si usamos el template original? ¿Hará caso al parámetro del response o hará caso al template?

Vamos a probarlo:

  • Eliminamos la base de datos:

      [oracle@test1 ~]$ dbca -silent \
  -deleteDatabase \
  -sourceDB FREE \
  -sysDBAUserName sys \
  -sysDBAPassword ******
  [WARNING] [DBT-11503] The instance (FREE) is not running on the local node. This may result in partial delete of Oracle database.
     CAUSE: A locally running instance is required for complete deletion of Oracle database instance and database files.
     ACTION: Specify a locally running database, or execute DBCA on a node where the database instance is running.
  [WARNING] [DBT-19202] The Database Configuration Assistant will delete the Oracle instances and datafiles for your database. All information in the database will be destroyed.
  Prepare for db operation
  32% complete
  Connecting to database
  35% complete
  39% complete
  42% complete
  45% complete
  48% complete
  52% complete
  65% complete
  Updating network configuration files
  68% complete
  Deleting instance and datafiles
  84% complete
  100% complete
  Database deletion completed.
  Look at the log file "/opt/oracle/cfgtoollogs/dbca/FREE/FREE11.log" for further details.

  • Creamos la bbdd:

      [oracle@test1 ~]$ dbca -createDatabase -silent -responseFile /home/oracle/config/shadow.rsp
  Enter PDBADMIN User Password:

  Prepare for db operation
  4% complete
  Creating and starting Oracle instance
  5% complete
  6% complete
  8% complete
  Creating database files
  12% complete
  Creating data dictionary views
  13% complete
  16% complete
  17% complete
  18% complete
  24% complete
  Oracle JVM
  30% complete
  36% complete
  42% complete
  44% complete
  Oracle Text
  46% complete
  48% complete
  Oracle OLAP
  52% complete
  Oracle Spatial
  53% complete
  60% complete
  Oracle Label Security
  68% complete
  Oracle Database Vault
  76% complete
  Creating cluster database views
  77% complete
  84% complete
  Completing Database Creation
  86% complete
  88% complete
  Executing Post Configuration Actions
  100% complete
  Database creation complete. For details check the logfiles at:
   /opt/oracle/cfgtoollogs/dbca/FREE.
  Database Information:
  Global Database Name:FREE
  System Identifier(SID):FREE
  Look at the log file "/opt/oracle/cfgtoollogs/dbca/FREE/FREE13.log" for further details.

Nos conectamos a la base de datos como SYS:

[oracle@test1 ~]$ sqlplus /nolog

SQL*Plus: Release 23.0.0.0.0 - Production on Wed Sep 3 12:02:06 2025
Version 23.9.0.25.07

Copyright (c) 1982, 2025, Oracle.  All rights reserved.

SQL> conn / as sysdba
Connected.
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
SQL>! grep pdb_dbid /home/oracle/config/FREE.template.dbt
      <PluggableDatabase pdb_name="PDB$SEED" con_id="2" pdb_dbid="3172087764"/>
      <PluggableDatabase pdb_name="FREEPDB1" con_id="3" pdb_dbid="302716810"/>

No tenemos PDBs creadas, solo tenemos la seed.

Aunque nuestro template si que tiene definida la creación de una PDB "FREEPDB1", el fichero response indica a DBCA que el número de PDBs debe ser 0.

Podéis descargar tanto el template como el response que he usado desde aquí.

Espero que os sirva :)

]]><![CDATA[[OCI] Recuperación del acceso de un IaaS]]>https://dbaenlasombra.com/oci-recuperacion-del-acceso-de-un-iaashttps://dbaenlasombra.com/oci-recuperacion-del-acceso-de-un-iaasSun, 13 Jul 2025 16:42:03 GMTVamos a ver como podríamos recuperar de forma fácil el acceso a un IaaS al que se ha perdido el authorized_keys del usuario opc.

Antes de entrar en faena, vamos hacer un pequeño resumen de lo que es cada punto:

  • authorized_keys: fichero que contiene las claves públicas para poder acceder a un servidor sin contraseña.

  • opc “Oracle Public Cloud”: cuenta del administrador del sistema. Todos los recursos que tengamos en nuestra tenancy, a la hora de acceder lo haremos con este usuario.

Accedemos a nuestra máquina y listamos el contenido de /home/opc/.ssh.

[opc@zdm-host .ssh]$ ls -lac
total 16
drwx------. 2 opc opc   75 Jul 13 14:24 .
drwx------. 5 opc opc 4096 Oct 18  2023 ..
-rw-------. 1 opc opc  400 Oct 18  2023 authorized_keys
-rw-rw-r--. 1 opc opc  514 Oct 18  2023 authorized_keys.zip
-rw-r--r--. 1 opc opc  203 Oct 30  2023 known_hosts

Ahí podemos ver diferentes archivos, ninguna clave pública ni privada, solo el authorized_keys, un backup del mismo y el known_hosts. Procedemos a eliminar el authorized_keys e intentamos loguearnos de nuevo:

¡Upps! Efectivamente, hemos perdido el acceso a nuestra máquina.

Esto es algo que nos puede pasar en el día a día, alguien borro sin querer el authorized_keys o bien que se ha corrompido o simplemente que modificaron los permisos del fichero. En este caso hay un backup, pero en el caso que no lo tengamos, tendríamos que generar nosotros la clave.

Para ambos problemas, la manera de solucionarla es idéntica.

Para poder solucionarlo tendremos que hacer un detach de nuestro boot volumen para adjuntarlo en otro IaaS.

Así que… let's get down to business!

Primer paso es detener la instancia afectada:

Una vez detenida, procedemos a realizar el detach del boot volumen. Para ello vamos a la sección de “Storage” y ahí veremos nuestro boot volumen.

Una vez que la operación ha terminado, el estado del boot volumen pasará a “Detached”

Antes de pasar al siguiente punto, recomiendo copiar el OCID:

Vamos a la IaaS donde vamos a realizar la recuperación del mismo. El primer paso que tenemos que hacer es adjuntar ahí nuestro boot volume. Para hacerlo iríamos a la sección de “Storage” y de ahí a “Attach block Volume”

En esta nueva ventana que aparece nos pedirá una serie de información acerca del boot volume. Copiamos ahí el OCID que habíamos copiado previamente e indicamos que queremos tener acceso read/write

Una vez finalizada podremos ver nuestro boot volume se ha adjuntado de manera correcta.

Si accedemos a la máquina, podemos ver el volumen que hemos adjuntado (/dev/sdb3):

[root@test ~]# fdisk -l /dev/sdb
Disk /dev/sdb: 200 GiB, 214748364800 bytes, 419430400 sectors
Disk model: BlockVolume
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: AEAC51C9-5D28-48CB-82FF-1B7312827FEB

Device        Start       End   Sectors   Size Type
/dev/sdb1      2048    411647    409600   200M EFI System
/dev/sdb2    411648  17188863  16777216     8G Linux swap
/dev/sdb3  17188864 419430365 402241502 191.8G Microsoft basic data

El siguiente paso es marcar como disponible para el S.O nuevo boot volumen por medio del comando mount:

[root@test ~]# mount -o nouuid /dev/sdb3 /mnt
[root@test ~]# df -h
Filesystem                  Size  Used Avail Use% Mounted on
devtmpfs                    4.0M     0  4.0M   0% /dev
tmpfs                       7.6G     0  7.6G   0% /dev/shm
tmpfs                       3.1G  8.7M  3.1G   1% /run
efivarfs                    256K   17K  235K   7% /sys/firmware/efi/efivars
/dev/mapper/ocivolume-root   30G  9.4G   21G  32% /
/dev/sda2                   2.0G  412M  1.6G  21% /boot
/dev/mapper/ocivolume-oled   15G  178M   15G   2% /var/oled
/dev/sda1                   100M  6.3M   94M   7% /boot/efi
tmpfs                       1.6G     0  1.6G   0% /run/user/989
tmpfs                       1.6G     0  1.6G   0% /run/user/1000
/dev/sdb3                   192G   13G  179G   7% /mnt

Accedemos a /mnt/home/opc/.ssh para recuperar nuestro authorized_keys.

[root@test ~]# cd /mnt/home/opc/.ssh
[root@test .ssh]# unzip authorized_keys.zip && chown opc:opc authorized_keys
Archive:  authorized_keys.zip
[root@test .ssh]# ls -lac
total 16
drwx------. 2 opc opc   75 Jul 13 15:38 .
drwx------. 5 opc opc 4096 Oct 18  2023 ..
-rw-------. 1 opc opc  400 Jul 13 15:38 authorized_keys
-rw-rw-r--. 1 opc opc  514 Jul 13 14:24 authorized_keys.zip
-rw-r--r--. 1 opc opc  203 Oct 30  2023 known_hosts

Accedemos, realizamos unzip y cambiamos el propietario/grupo del fichero.

Desmontamos /mnt y comprobamos que ya no se encuentra accesible, para poder realizar detach de nuevo:

[root@test ~]# umount /mnt
[root@test ~]# df -h
Filesystem                  Size  Used Avail Use% Mounted on
devtmpfs                    4.0M     0  4.0M   0% /dev
tmpfs                       7.6G     0  7.6G   0% /dev/shm
tmpfs                       3.1G  8.7M  3.1G   1% /run
efivarfs                    256K   17K  235K   7% /sys/firmware/efi/efivars
/dev/mapper/ocivolume-root   30G  9.4G   21G  32% /
/dev/sda2                   2.0G  412M  1.6G  21% /boot
/dev/mapper/ocivolume-oled   15G  178M   15G   2% /var/oled
/dev/sda1                   100M  6.3M   94M   7% /boot/efi
tmpfs                       1.6G     0  1.6G   0% /run/user/989
tmpfs                       1.6G     0  1.6G   0% /run/user/1000

Perfecto, vamos adjuntar de nuevo el boot volumen en la IaaS que habíamos perdido acceso:

  • Realizamos detaching

  • Una vez que la operación ha terminado correctamente, realizamos attach de nuevo en el IaaS que habíamos perdido acceso

Una vez terminada la operación, arrancamos de nuevo el entorno de nuevo y verificamos que hemos recuperado el acceso:

Using username "opc".
Authenticating with public key "imported-openssh-key"
Last login: Sun Jul 13 14:06:47 2025 from 10.98.140.36
[opc@zdm-host ~]$

Perfecto, tenemos acceso de nuevo. ¡Espero que os sirva!

]]><![CDATA[[OCI] Monitorización Dataguard]]>https://dbaenlasombra.com/oci-monitorizacion-dataguardhttps://dbaenlasombra.com/oci-monitorizacion-dataguardThu, 03 Jul 2025 12:03:26 GMTOs paso un script sencillo para supervisar nuestro Oracle Data Guard, cuya función es enviarnos una alerta si se detectan errores o advertencias.

En caso que nuestro script haya detectado problemas, nos enviará un correo con la siguiente información:

  • Estado del Data Guard.

  • Posibles errores ORA a nivel de primary o standby.

  • Lag actual del dataguard.

La alerta que nos llegaría sería la siguiente:

Este sería el script:

#!/bin/bash

. /home/oracle/.bashrc

getInfo_dgmgrl(){
  while read -a line;
  do
    if [[ "${line[2]}" == *"Primary"* ]];
    then
      echo "${line[0]}"
    elif [[ "${line[2]}" == *"Physical"* ]];
    then
      echo "${line[0]}"
    fi
  done <<< $1
}

check_output=$(getInfo_dgmgrl "`dgmgrl -silent /  "show configuration"`")

set ${check_output}
PRY=$1
STB=$2

LAG=`dgmgrl -silent /  "show configuration lag" | grep -ie 'transport' -ie 'apply' | sed 's/^[[:space:]]*//'`
STATUS=`dgmgrl -silent /  "show configuration" | grep -i status | awk 'END{print}'  | sed 's/^[[:space:]]*//' | awk '{printf $1}'`

SUMMARY_DATAGUARD=`
   dgmgrl -silent /  "show database '${PRY}' 'StatusReport'" | grep ORA | awk -F"ERROR|WARNING" '{ print $2 }' | \
   awk -v primary="${PRY}" '
   {
            printf "Primary database: " primary "\n"
            printf "Errores encontrados:"
            if ( $0 != "") {
             printf $0
            } else {
             printf "sin errores"
            }
            printf "\n\n"
   }
' &&
   dgmgrl -silent /  "show database '${STB}' 'StatusReport'" | grep ORA | awk -F"ERROR|WARNING" '{ print $2 }' | \
   awk -v standby="${STB}" '
   {
            printf "Standby database: " standby "\n"
            printf "Errores encontrados:"
            if ( $0 != "") {
             printf $0
            } else {
             printf "sin errores"
            }

   }
'`

if [[ ! "${STATUS}" =~ "SUCCESS" ]]; then
printf "Resumen de errores Dataguard\n\nFecha de Inicio=$(date '+%d-%m-%Y %H:%M:%S')\n\nStatus=${STATUS}\n\n${SUMMARY_DATAGUARD}\n\n${LAG}" | mailx -s "[${ORACLE_UNQNAME}] Summary Dataguard" ${EMAIL}
fi

Descarga desde github:

https://github.com/dbaenlasombra/MonitoreDataguard/

Ahora solo faltaría planificarlo en cron. En mi caso es diario y cada media hora.

[root@ scripts]# crontab -l
*/30 * * * * /root/scripts/check_backups.sh

Listo. ¡Espero que os sirva!

]]><![CDATA[[23ai] SQL*Plus]]>https://dbaenlasombra.com/23ai-sqlplushttps://dbaenlasombra.com/23ai-sqlplusSun, 11 May 2025 21:38:04 GMTToday, we’re going to speak about SQL*Plus and it’s new features in 23ai such as config, argument, ping and so on. Everyone really know SQLPlus command-line tool remains the go-to for many DBA in order to iron out every issue in their environments.

So, let's get down to business!

ARGUMENT

Previous to 23ai, when we work with substitution variables in the command-line, these can be set explicitly in SQL*Plus, or passed as arguments our scripts. But from 23ai onwards, we can do it with the new command: argument.

The sintax is the following:

ARGUMENT <VALUE_NUMERIC> [PROMPT/DEFAULT] [HIDE]

Let’s doing a wee bit example in order to see the differences of every option.

  • prompt.
SQL> ! vi argument.sql
SQL> ! cat argument.sql
set verify off 
argument 1 prompt "Enter the acount status in order to check:"
Select Username From Dba_Users Where Account_Status='&1';
undefine 1
SQL> @argument.sql
Enter the acount status in order to check:LOCKED

USERNAME
--------------------------------------------------------------------------------
XS$NULL
LBACSYS
OUTLN
DBSNMP
APPQOSSYS
VECSYS
DBSFWUSER
GGSYS
ANONYMOUS
FLOWS_FILES

As we can see, our script is straightforward enough. The first line is in order to not display old and new values and next line is the new command. Here it sees the value that we’ve typed in the command-line.

  • default.
SQL> ! vi argument.sql
SQL> ! cat argument.sql
set verify off 
argument 1 default "OPEN"
Select Username From Dba_Users Where Account_Status='&1';
undefine 1

SQL> @argument.sql

USERNAME
--------------------------------------------------------------------------------
SYS
SYSTEM
APEX_PUBLIC_USER
APEX_PUBLIC_ROUTER
AV
PDBADMIN
HR
SYSRAC
ORDS_PUBLIC_USER
ORDS_METADATA

Here it doesn’t display any prompt because we’ve assigned a default value for our variable “argument 1 default "OPEN"“

  • hide.
SQL> ! vi argument.sql
SQL> ! cat argument.sql
set verify off 
argument 1 prompt "Enter the acount status in order to check:" hide
Select Username From Dba_Users Where Account_Status='&1';
undefine 1

SQL> @argument.sql
Enter the acount status in order to check:

USERNAME
--------------------------------------------------------------------------------
SYS
SYSTEM
APEX_PUBLIC_USER
APEX_PUBLIC_ROUTER
AV
PDBADMIN
HR
SYSRAC
ORDS_PUBLIC_USER
ORDS_METADATA
CO

As we can see, here it has had a prompt but no way in order to see the value typing. This would be the difference respect to prompt.

PING or -P

To check availability our database.

On one hand, from the command line, we can use -p in order to see quickly whether our database is up or down.

Let’s doing a wee bit example:

SQL> ! sqlplus -p localhost/FREEPDB1
Attempting to contact: (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=FREEPDB1))(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=1521)))
Ok (4704.178 msec)

On the other hand, we can use ping in order to check the current connection. Here it can use the comand with or without arguments.

Again, let’s doing a wee bit example:

SQL> SQL> conn hr/oracle
Connected.
SQL> ping
Ok (0.267 msec)
SQL> disconnect
Disconnected from Oracle Database 23ai Free Release 23.0.0.0.0 - Develop, Learn, and Run for Free
Version 23.6.0.24.10
SQL> ping
SP2-0640: Not connected

Also, we can use ping with the alias in order to do ping the network listener:


SQL> ping FREEPDB1
Local Net Naming configuration file: /opt/oracle/product/23ai/dbhomeFree/network/admin/tnsnames.ora
Attempting to contact: (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = FREEPDB1)))
Ok (7.032 msec)

In a nutshell, we can say the functionality is like tnsping, don’t you?

ERRORDETAILS

To displays us an url with information about the trouble. That page gives us information more detail about the mistake in order to try to iron out it.

The syntax is the following:

SET ERRORDETAILS [ ON / OFF / VERBOSE]

The default value is ON.

Below you can see a wee bit example:

SQL> Select * From pickle;
Select * From pickle
              *
ERROR at line 1:
ORA-00942: table or view "SYS"."PICKLE" does not exist
Help: https://docs.oracle.com/error-help/db/ora-00942/
SQL> set errordetails off
SQL> r
  1* Select * From pickle
Select * From pickle
              *
ERROR at line 1:
ORA-00942: table or view "SYS"."PICKLE" does not exist
SQL> set errordetails verbose 
SQL> r
  1* Select * From pickle
Select * From pickle
              *
ERROR at line 1:
ORA-00942: table or view "SYS"."PICKLE" does not exist
Help: https://docs.oracle.com/error-help/db/ora-00942/
Cause:       The specified table or view did not exist, or a synonym
       pointed to a table or view that did not exist.
       To find existing user tables and views, query the
       ALL_TABLES and ALL_VIEWS data dictionary views. Certain
       privileges may be required to access the table. If an
       application returned this message, then the table that the
       application tried to access did not exist in the database, or
       the application did not have access to it.
Action:    Check each of the following:
       - The spelling of the table or view name is correct.
       - The referenced table or view name does exist.
       - The synonym points to an existing table or view.

       If the table or view does exist, ensure that the correct access
       privileges are granted to the database user requiring access
       to the table. Otherwise, create the table.

       Also, if you are attempting to access a table or view in another
       schema, make sure that the correct schema is referenced and that
       access to the object is granted.
Params: 1) object_name: The table or view name specified as
            SCHEMA.OBJECT_NAME, if one is provided.
            Otherwise, it is blank.

We’re going to see the sequence that we’ve followed.

  • First: As we know, the value of default is on. For this reason, we can see in the prompt the tag help with the url in order to get information about ORA error.

  • Second: we apply off for our parameter. In this case, we don’t see the tag help, we only see the ORA error.

  • Third: we apply verbose for our parameter. In this case, it displays us helpful message information about error.

OERR

This command would display us helpful message information about error.

The syntax is the following:

OERR [ ERROR_CODE ]

Below you can see a wee bit example:

SQL> OERR ORA-01422
Message: "exact fetch returned more than the requested number of rows %s"
Help: https://docs.oracle.com/error-help/db/ora-01422/
Cause: The cause is one of the following:
    1. A SELECT statement was executed in the exact fetch
       mode and returned more rows than requested.
    2. In PL/SQL, a SELECT INTO statement returned more than one row.
    3. In PL/SQL, a DML RETURNING INTO statement
       returned more than one row.
Action: Choose the action corresponding to the cause as numbered:
    1. Increase the number of rows requested to accommodate the
       number of rows returned;
       or omit the exact fetch mode on the fetch call.
    2. In PL/SQL, use a FOR loop to process the rows.
    3. In PL/SQL, use BULK COLLECT to return values into a table.
Params: 1) requested_rows: The number of requested rows.

SHOW CONNECTION

This command would display us information about our tnsnames.ora.

The syntax is the following:

SHOW [ CONNECTION / CONN ] [ NETSERVICENAMES / NETS] SERVICE_NAME

Below you can see a wee bit example:

SQL>
SQL> show connection netservicenames FREEPDB1
Local Net Naming configuration file: /opt/oracle/product/23ai/dbhomeFree/network/admin/tnsnames.ora
FREEPDB1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = FREEPDB1)))
SQL> 
SQL> show conn nets FREEPDB1
Local Net Naming configuration file: /opt/oracle/product/23ai/dbhomeFree/network/admin/tnsnames.ora
FREEPDB1 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = FREEPDB1)))
SQL>

Looking forward to seeing you in the next article.

]]><![CDATA[Monitore High-Frequency Statistics]]>https://dbaenlasombra.com/monitore-high-frequency-statisticshttps://dbaenlasombra.com/monitore-high-frequency-statisticsWed, 16 Apr 2025 07:20:51 GMTToday, we’re going to see a little script in order to check in High-Frequency Statistics inside the database every day.

Before seeing the script, we’re going to talk about High-Frequency Statistics. This feature, who runs automatically in maintenance windows, was born in 19c. By default, the high-frequency statistics collection occurs every 15 minutes.

Somehow this feature doesn’t replace the standard statistics collection job inside is a complement.

How can we set it? We should set with the procedure DBMS_STATS.SET_GLOBAL_PREFS. in order to do such as switch on/switch off, change the execution interval or even maximum run time.

  • Switch on/ Switch off (By default).
EXEC DBMS_STATS.SET_GLOBAL_PREFS('AUTO_TASK_STATUS','ON');

EXEC DBMS_STATS.SET_GLOBAL_PREFS('AUTO_TASK_STATUS','OFF');
  • Maximum run time (By default, it’s 3600)
EXEC DBMS_STATS.SET_GLOBAL_PREFS('AUTO_TASK_MAX_RUN_TIME','3600');
  • Change the execution interval (By default, it’s 900)
EXEC DBMS_STATS.SET_GLOBAL_PREFS('AUTO_TASK_INTERVAL','900');

Below you can see the script together the email with the summary.

  • Script:
#!/bin/bash

. /home/oracle/.bashrc

getInfo() {
   sqlplus -s ${VUSER}/${VPASS}@${LOCAL_SID} <<EOF

   COL STATUS      FOR a11    HEAD 'STATUS'
   COL ORIGIN      FOR a20    HEAD 'ORIGIN'
   COL COMPLETED   FOR 99999  HEAD 'COMPLETED'
   COL FAILED      FOR 99999  HEAD 'FAILED'
   COL TIMEOUT     FOR 99999  HEAD 'TIMEOUT'
   COL INPROG      FOR 99999  HEAD 'INPROG'
   COL BEGIN_TIME  FOR a40    HEAD 'BEGIN_TIME'
   COL END_TIME    FOR a40    HEAD 'END_TIME'

   set pagesize 1000 linesize 1000 heading on feedback off echo off
   set space  1 colsep ' ' underline off

   break on ORIGIN
   compute sum of COMPLETED on ORIGIN
   compute sum of FAILED on ORIGIN
   compute sum of TIMEOUT on ORIGIN
   compute sum of INPROG on ORIGIN

   Select Origin,
          Status,
          Start_Time  As Begin_Time,
          End_Time    As End_Time,
          Completed,
          Failed,
          Timed_Out   As Timeout,
          In_Progress As Inprog
     From Dba_Auto_Stat_Executions
    Where Trunc(Start_Time) >= (Sysdate - 7)
    Order By Opid;
    spool off
    exit;
EOF
}

   (
   echo "To: ${EMAIL}"
   echo "Subject:Check high-frequency task"
   echo
   echo "$(getInfo)"
   ) | mailx -t
  • Email

Looking forward to seeing you in the next article.

]]>