• [OCI] Oracle Grid Infrastructure 19c (Oracle Restart + ASM).

• [OCI] 19c DBCA - Silent mode.

Hoy toca subir la base de datos de 19c a 26ai. Para lograr dicho objetivo, vamos a utilizar autoupgrade, el uso del mismo, está maravillosamente explicado por Daniel Overby en su blog dohdatabase.

Upgrade Oracle Database 19c CDB to Oracle AI Database 26ai

Debo reconocer que tenía muchas ganas de usarlo, así, que sin más, vamos a ello.

Primer paso, descargar el autoupgrade.jar desde la página oficial de Oracle.

[oracle@]$ wget https://download.oracle.com/otn-pub/otn_software/autoupgrade.jar

En este punto, podemos verificar si el jar tiene errores con java -jar autoupgrade.jar -version.

El proceso de autoupgrade puede hacerse:

• Source y target en el mismo server

• Source y target en diferente server.

En este laboratorio, tanto el source como el target, estarán en el mismo server.

Config Files

Definir el fichero de configuración es un paso obligatorio para realizar con éxito nuestro autoupgrade.

Este fichero, contiene toda la configuración necesaria para realizar el upgrade de nuestra base de datos. Así que este será nuestro primer paso.

Aquí voy a definir las siguientes variables, no van a ser las mismas cuando realice el analyze respecto al display. En el analyze, voy a indicar target_version para que el proceso de autoupgrade sepa contra que versión se debe hacer los pre-checks. Pero para la fase de display debo indicar target_home.

• global.autoupg_log_dir: directorio log.

• dba.source_home: nuestro actual $ORACLE_HOME

• dba.target_version: especificamos la versión a la que queremos realizar el upgrade.

• dba.target_home: $ORACLE_HOME para el target. Ahí deben estar los binarios de nuestra 26ai.

• dba.sid: sid de nuestra base de datos.

Mi prefijo para el proceso es dba, pero podemos usar el que queramos.

[oracle@~]$ cat > upgrade19to26.cfg <<EOF
global.autoupg_log_dir=${HOME}/logs
dba.source_home=${ORACLE_HOME}
dba.target_version=23.0.0
dba.sid=${ORACLE_SID}
EOF

Analyze

Ejecutamos la primera fase.

¿Que hace el analyze? Verifica si nuestra base de datos está lista para el upgrade, haciendo un checkeo y generando un informe. Este informe nos indica posibles errores para corregir antes de la siguiente fase o advertencias que deberíamos prestar atención.

La ejecución de esta fase sería java -jar autoupgrade.jar -config <name_cfg>.cfg -mode analyze.

[oracle@~]$ java -jar autoupgrade.jar -config upgrade19to26.cfg -mode analyze

AutoUpgrade 26.5.260807 launched with default internal options
Processing config file ...
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
1 CDB(s) plus 1 PDB(s) will be analyzed
Type 'help' to list console commands
upg> Job 102 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]

Please check the summary report at:
/home/oracle/logs/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/logs/cfgtoollogs/upgrade/auto/status/status.log

Revisamos el informe generado para ver si ha encontrado errores o advertencias antes de continuar.

Adjunto el informe generado:

cdb1_preupgrade.html

Leyendo el informe, no indica errores ni componentes inválidos. Solo voy a solucionar la advertencia del sga_target antes de pasar a la siguiente fase. El resto de advertencias, como el unified auditing, ordim o las indicaciones a nivel de tablespaces, etc. las revisaremos al finalizar el upgrade.

Ejecuto la siguiente sentencia desde CDB$Root para solucionar la advertencia del sga_target.

SQL> ALTER SYSTEM SET sga_target=4672M SCOPE=BOTH;

Lanzamos de nuevo el analyze para verificar que la advertencia del sga_target ha desaparecido.

Dejo aquí el nuevo informe.

cdb1_preupgrade_v2.html

Deploy

Fase donde se va realizar el upgrade de nuestra base de datos.

Como comentamos previamente, vamos a generar de nuevo el fichero de configuración (tenemos que usar el parámetro target_home, en vez de target_version), y con este parámetro de que es necesario tener instalado tanto Oracle Database Home como Grid Infrastructure.

Ambos los podemos descargar desde aquí.

Vamos primero para la parte de Oracle Database Home:

• Definimos el directorio que albergara los binarios.

[oracle@~]$ mkdir -p /u01/app/oracle/product/26.0.0/dbhome_1
[oracle@~]$ cd /u01/app/oracle/product/26.0.0/dbhome_1
[oracle@dbhome_1]$ unzip /tmp/LINUX.X64_2326100_db_home.zip 
...
...

• Una vez que tenemos ahí los binarios, ejecutamos la instalación en dos fases, primer verificamos que estamos listo con -executePrereqs y después instalamos.

[oracle@dbhome_1]$ ./runInstaller -silent -setupDBHome -OSDBA dba -OSBACKUPDBA dba -OSDGDBA dba -OSKMDBA dba -OSRACDBA dba -ORACLE_BASE /u01/app/oracle -installEdition EE -INVENTORY_LOCATION /u01/app/oraInventory -executePrereqs

Launching Oracle AI Database Setup Wizard...

Prerequisite checks ran successfully.

[oracle@dbhome_1]$ ./runInstaller -silent -setupDBHome -OSDBA dba -OSBACKUPDBA dba -OSDGDBA dba -OSKMDBA dba -OSRACDBA dba -ORACLE_BASE /u01/app/oracle -installEdition EE -INVENTORY_LOCATION /u01/app/oraInventory
...
...

Respecto a Grid Infrastructure:

• Definimos el directorio que albergara los binarios y paramos la base de datos

[grid@~]$ mkdir -p /u01/app/26.0.0/grid
[grid@~]$ cd /u01/app/26.0.0/grid
[grid@grid]$ unzip /tmp/LINUX.X64_2326100_grid_home.zip

• Paramos la base de datos

[grid@grid]$ srvctl stop database -db cdb1
[grid@grid]$ srvctl status database -db cdb1

• Una vez que tenemos ahí los binarios, ejecutamos la instalación en dos fases, primer verificamos que estamos listo con -executePrereqs y después instalamos.

[grid@intheshadow grid]$ ./gridSetup.sh -silent -upgrade -ORACLE_BASE $ORACLE_BASE -executePrereqs
...
...
[grid@intheshadow grid]$ ./gridSetup.sh -silent -upgrade -ORACLE_BASE $ORACLE_BASE
...
...

• Arrancamos de nuevo la base de datos.

[grid@grid]$ srvctl start database -db cdb1
[grid@grid]$ srvctl status database -db cdb1

Ahora que tenemos listo, tanto Oracle Database Home como Grid Infrastructure, generamos nuestro nuevo fichero de configuración.

[oracle@~]$ cat > upgrade19to26.cfg <<EOF
global.autoupg_log_dir=${HOME}/logs
dba.source_home=${ORACLE_HOME}
dba.target_home=$(echo "${ORACLE_HOME}" | sed 's/19\.0\.0/26.0.0/')
dba.sid=${ORACLE_SID}
EOF

Lanzamos el deploy:

[oracle@ ~]$ java -jar autoupgrade.jar -config upgrade19to26.cfg -mode deploy

Previous execution found loading latest data
Total jobs recovered: 1
+--------------------------------+
| Starting AutoUpgrade execution |
+--------------------------------+
Type 'help' to list console commands
upg> Job 106 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs restored                  [0]
Jobs pending                   [0]

---- Drop GRP at your convenience once you consider it is no longer needed ----
Drop GRP from CDB1: drop restore point AUTOUPGRADE_9212_CDB11932000


Please check the summary report at:
/home/oracle/logs/cfgtoollogs/upgrade/auto/status/status.html
/home/oracle/logs/cfgtoollogs/upgrade/auto/status/status.log

Listo, ha terminado correctamente, aunque no a la primera "Total jobs recovered: 1". En el próximo artículo hablare en detalle de los errores que he tenido en el autoupgrade por si os puede ayudar.

[oracle@~]$ sqlplus / as sysdba

SQL*Plus: Release 23.26.1.0.0 - Production on Thu Sep 10 18:09:25 2026
Version 23.26.1.0.0

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


Connected to:
Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0 - Production
Version 23.26.1.0.0

SQL> select banner_full from v$version;

BANNER_FULL
------------------------------------------------------------------
Oracle AI Database 26ai Enterprise Edition Release 23.26.1.0.0 - Production
Version 23.26.1.0.0

El siguiente paso y último en esta aventura, sera usar la última versión de ZDM con el objetivo de familiarizarnos con está nueva versión, tengo muchas ganas de probar el nuevo "instant deploy" y así migramos una PDB a esta base de datos.

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

La creación de la misma será usando DBCA en modo silent con un template configurado para lograr el objetivo.

Dejo aquí el enlace del response utilizado:

shadow.rsp

En el fichero response que hemos configurado contiene los siguientes parámetros:

Una vez configurado el response, ejecutamos DBCA bajo el usuario oracle haciendole referencia al mismo.

[oracle@~]$ $ORACLE_HOME/bin/dbca -silent -createDatabase -responseFile /home/oracle/shadow.rsp 
Prepare for db operation
10% complete
Registering database with Oracle Restart
14% complete
Copying database files
43% complete
Creating and starting Oracle instance
45% complete
49% complete
54% complete
58% complete
62% complete
Completing Database Creation
68% complete
70% complete
71% complete
Executing Post Configuration Actions
100% complete
Database creation complete. For details check the logfiles at:
 /u01/app/oracle/cfgtoollogs/dbca/cdb1.
Database Information:
Global Database Name:cdb1
System Identifier(SID):CDB1
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/cdb1/cdb10.log" for further details.

Perfecto, nos conectamos a la base de datos para configurar el modo archivelog.

SQL>
shu immediate
startup mount;
alter database archivelog;
alter database open;

SQL> archive log list;
Database log mode	       Archive Mode
Automatic archival	       Enabled
Archive destination	       USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     14
Next log sequence to archive   16
Current log sequence	       16

SQL>

En el próximos capítulo abordaremos el upgrade de 19c a 26ai.

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

¿Porque 19c y no 26ai? Porque queremos utilizar el autograde para pasar de 19c a 26ai, y una vez se encuentre en 26ai, utilizar la última versión de ZDM para probar el "instant deploy".

Más o menos, nuestro laboratorio va ser el siguiente:

Así que sin más, vamos al lío.

Preparación ASM

El IaaS he adjuntado dos block volumenes a mayores para la parte de DATA y RECO, de 50Gb cada uno.

Para montar ambos block volumenes en linux tenemos que copiar el valor iqn de cada volumen para saber quien es quien.

En OCI para obtenerlo tenemos que ir a los detalles de cada volumen:

Y en la ventana que se abre, copiamos el siguiente valor:

Buscamos la equivalencia en linux:

[root@~]# ls -l /dev/disk/by-path/ | grep iscsi
[root@~]# iscsiadm -m session -P 3 | grep -E 'Target:|Attached scsi disk'

Con la información que hemos obtenido, sabemos que:

• /sdb es ASM_DATA_BOOT

• /sdc es ASM_RECO_DATA.

Con esta información, ya podemos preparar los discos ASM.

1. Definimos las particiones:

[root@~]# parted -s /dev/sdb mklabel gpt
[root@~]# parted -s /dev/sdb mkpart primary 1MiB 100%
[root@~]# parted -s /dev/sdc mklabel gpt
[root@~]# parted -s /dev/sdc mkpart primary 1MiB 100%

Verificamos:

[root@~]# lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME                SIZE TYPE FSTYPE      MOUNTPOINTS
sda                 100G disk             
├─sda1              100M part vfat        /boot/efi
├─sda2                2G part xfs         /boot
└─sda3             44.5G part LVM2_member 
  ├─ocivolume-root 29.5G lvm  xfs         /
  └─ocivolume-oled   15G lvm  xfs         /var/oled
sdb                  50G disk             
└─sdb1               50G part             
sdc                  50G disk             
└─sdc1               50G part    

1. Instalamos ASMLib:

[root@~]# dnf config-manager --enable ol9_addons
[root@~]# dnf install -y oracleasm-support
[root@~]# dnf install ./oracleasmlib-3.1.3-1.el9.x86_64.rpm

Una vez instalado, configuramos oracleasm con el comando "oracleasm configure -i" y reiniciamos el servicio "systemctl restart oracleasm".

1. Definimos las etiquetas a nivel ASM

[root@~]# oracleasm createdisk DATA01 /dev/sdb1
[root@~]# oracleasm createdisk RECO01 /dev/sdc1

Y verificamos con "oracleasm listdisks".

Instalación Grid Infrastructure 19.32

Después de preparar toda la estructura de directorios junto con la definición de los usuarios oracle y grid, así como los grupos, comenzamos a instalar la parte de Grid Infrastructure.

La fase de preparación se resumiría como:

[root@~]# groupadd -f oinstall
[root@~]# groupadd -f dba
[root@~]# groupadd -f asmadmin
[root@~]# groupadd -f asmdba
[root@~]# groupadd -f asmoper

[root@~]# useradd -g oinstall -G asmadmin,asmdba,asmoper,dba grid
[root@~]# useradd -g oinstall -G dba,asmdba oracle

[root@~]# mkdir -p /u01/app/oracle/product/19.0.0/db_1
[root@~]# mkdir -p /u01/app/grid 
[root@~]# mkdir -p /u01/app/19.0.0/grid
[root@~]# mkdir -p /u01/app/oraInventory
[root@~]# mkdir -p /u01/software
[root@~]# chown -R grid:oinstall /u01
[root@~]# chown -R oracle:oinstall /u01/app/oracle
[root@~]# chmod -R 775 /u01

El siguiente punto sería:

• Definir el fichero response, dejo por aquí el enlace para descargar del que hemos usado.

Fichero response

• Descargar el parche Patch 39467003: GI RELEASE UPDATE 19.32.0.0.0.

• Descargar Oracle Database 19c desde aquí, tanto grid como home.

Después de descomprimir el zip de Oracle Grid en /u01/app/19.0.0/grid, procedemos a su instalación:

[grid@~]# cd $ORACLE_HOME
[grid@~]# ./gridSetup.sh -silent -responseFile /home/grid/grid.rsp -applyRU /u01/software/39467003 -waitforcompletion -ignorePrereqFailure

Una vez completado, bajo el usuario root lanzamos los scripts orainstRoot.sh y root.sh.

[root@~]# sh /u01/app/oraInventory/orainstRoot.sh
[root@~]# sh /u01/app/19.0.0/grid/root.sh

Volvemos a conectar con el usuario grid, y verificamos con "crsctl stat res -t" lo tenemos todo correcto.

En mi caso, después de revisar el output del comando y revisar el log para ver si ha habido errores, vi que la parte de asm algo erróneo, y después de ejecutar "srvctl status asm", se confirmaron mis sospechas, asm no existía, así que lo tuve que configurar después.

Dejo por aquí como lo configure, por si os ocurre lo mismo:

[grid@intheshadow ~]$ asmca -silent -configureASM \
  -sysAsmPassword 'XXXXXX' \
  -asmsnmpPassword 'XXXXXX' \
  -diskString 'ORCL:*' \
  -diskGroupName DATA \
  -diskList 'ORCL:DATA01' \
  -redundancy EXTERNAL \
  -au_size 4

[grid@intheshadow ~]$ srvctl status asm
 ASM is running on intheshadow

Como último paso, antes de crear el diskgroup de RECO, revisamos de nuevo los recursos con crsctl stat res -t.

Listo, ya podemos crear el diskgroup de RECO. Aquí podemos tomar dos caminos para hacerlo, o bien vía instrucción DDL o usando asmca.

En mi caso opte por usar asmca:

[grid@~]# asmca -silent -createDiskGroup \ 
-diskString 'ORCL:*' \
-diskGroupName RECO \ 
-diskList 'ORCL:RECO01' \ 
-redundancy EXTERNAL \ 
-au_size 4 \ 
-sysAsmPassword 'XXXXXX'

Instalación Oracle Database 19.32

El primer paso, además de configurar el .bash_profile de Oracle, debemos descomprimir el zip de Oracle en /u01/app/oracle/product/19.0.0/dbhome_1.

Una vez hecho y antes de lanzar el runinstaller, verificamos en el fichero /etc/oraInst.loc que está todo correcto.

El fichero response que he utilizado, lo podemos descargar desde aquí.

Lanzamos la instalación:

[oracle@~]# cd $ORACLE_HOME
[oracle@~]# ./runInstaller -silent -waitforcompletion -applyRU /u01/software/39467003 -responseFile /home/oracle/oracle.rsp

Una vez completado, bajo el usuario root lanzamos el script root.sh.

[root@~]# . /u01/app/oracle/product/19.0.0/dbhome_1/root.sh

Tenemos la instalación lista, pero sin base de datos aún.

En próximos capítulos continuaremos con nuestro laboratorio.

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

Estás extensiones formar parte de SFA Initiative (Select for Analysis), diseñadas para alinear más el Oracle SQL a los estándares.

A continuación puedes ver un gráfico ilustrativo de algunas de las distintas funciones que se han incorporado.

¿Cuándo debemos usarlas?

• Cuando necesitamos agrupar en consultas analíticas por algún tipo de calendario descrito en el punto anterior.

• Series temporales entre un rango de fechas.

• Conversión del dato a nivel de columna.

• Operaciones a nivel de un calendario, como agregar días o semanas.

Antes de empezar este laboratorio, debemos estar con la última versión de Oracle 23.26.2.

SQL> Select banner from v$version;

BANNER
--------------------------------------------------------------
Oracle AI Database 26ai Enterprise Edition Release 23.26.2.0.0 - Production

Para tener algo de información en nuestra PDB, vamos a cargar el schema de HR. Los scripts de este schema se encuentran en el github de Oracle Sample Projects.

Dejo aquí el enlace:

Github Oracle Sample Projects

El modelo ER es el siguiente:

CALENDAR

%_Year

Vamos a ver como interpreta cada una de estas funciones usando la misma columna de tipo date sin necesidad de restructurar nada.

SQL> 
select EMPLOYEE_ID,
       calendar_year(START_DATE) calendar,
       fiscal_year(START_DATE)   fiscal,
       retail_year(START_DATE)   retail,
       START_DATE,END_DATE,JOB_TITLE,MIN_SALARY,MAX_SALARY
from HR.JOB_HISTORY NATURAL JOIN (Hr.JOBS)
  fetch first 10 rows only

También pueden ser usadas para filtrar el resultado:

SQL> 
Select    EMPLOYEE_ID,START_DATE,END_DATE,JOB_TITLE,MIN_SALARY,MAX_SALARY
from HR.JOB_HISTORY NATURAL JOIN (Hr.JOBS)
where calendar_year(START_DATE) = 2011
  fetch first 10 rows only

En este caso podíamos usar un Extract(Year from START_DATE) y el resultado hubiera sido idéntico ¿verdad?

Pero mirando el explain plan de uno y otro, vemos alguna diferencia:

Internamente el extract se resuelve con INTERNAL_FUNCTION , mientras que el uso de la nueva función, el acceso es distinto. Curioso, en próximos artículos tendremos que profundizar este punto.

En el próximo artículo, veremos las funciones RETAIL y FISCAL.

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

sys@> alter pluggable database PDB$SEED open read only;
alter pluggable database PDB$SEED open read only
*
ERROR en lÝnea 1:
ORA-01173: el diccionario de datos indica que falta un archivo datos del tablespace SYSTEM

Los pasos que vamos a realizar para re-crearla son los siguientes:

• Eliminar la PDB$Seed.

• Crear una PDB vacía en otro CDB$Root para clonarla.

• Crear PDB$Seed en base al punto anterior.

Sin más, vamos a ello.

1.- Eliminar PDB$Seed

Recibiremos un error en caso de que intentamos borrarla directamente:

sys@OSIALEPR>  drop pluggable database "pdb$seed" including datafiles;
 drop pluggable database "pdb$seed" including datafiles
                         *
ERROR en lÝnea 1:
ORA-65017: la base de datos de conexi¾n inicial no se puede borrar ni modificar

Para poder borrarla con éxito, debemos jugar con el parámetro "_oracle_script".

sys@> alter session set "_oracle_script"=true;
sys@> alter pluggable database "pdb$seed" close;
sys@> drop pluggable database "pdb$seed" including datafiles;
sys@> show pdbs

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

SQL> alter session set "_oracle_script"=false;  

Ahí podéis ver la secuencia que he seguido, entre medias verifico que la PDB$Seed ha desaparecido.

2.- Pasos previos antes de la clonación de la PDB

Vamos a preparar en otro entorno la PDB que va servir como base a nuestra PDB$Seed.

Como vamos a tener dos máquinas, para diferenciarlo, vamos a llamar origen a donde tenemos que recrear la PDB$Seed y clonado donde vamos a definir la PDB que va servir para re-crearla.

Este seria el modelo que vamos a seguir:

Primero, definimos el usuario común C##CLONE en origen.

SQL> CREATE USER C##CLONE IDENTIFIED BY "XXXXX";
SQL> GRANT CONNECT, RESOURCE, DBA, SYSOPER, CREATE PLUGGABLE DATABASE TO C##CLONE CONTAINER=ALL;

Defino la pdb TEST en clonado.

SQL> create pluggable database TEST admin user pdb_admin identified by oracle;
SQL> alter pluggable database TEST open;
SQL> alter pluggable database TEST close;
SQL> alter pluggable database TEST open read only;

Creamos el DBLink en origen, habiendo incluido previamente la cadena de conexión en nuestro tnsnames.

SQL> CREATE DATABASE LINK REMOTE_SEED_LINK CONNECT TO C##CLONE IDENTIFIED BY "XXXXXX" using 'CLONADO';

Hasta aquí, ya tendríamos todo listo para crear de nuevo, nuestra PDB$Seed

Crear PDB$Seed

Una vez definido el DBLink, ya podremos clonar TEST con nombre de PDB$Seed.

SQL> CREATE PLUGGABLE DATABASE "PDB$SEED" FROM TEST@REMOTE_SEED_LINK;

Una vez finalizado, veifico que vemos ya PDB$Seed en origen.

sys@> show pdbs

    CON_ID CON_NAME    OPEN MODE  RESTRICTED
---------- ----------- ---------- ----------
         2 PDB$SEED    MOUNTED
         3 PDB1        READ WRITE NO

Perfecto, ya la vemos en origen. En este punto ya solo faltaría abrirla en READ ONLY.

SQL> alter session set "_oracle_script"=true;
Session altered.

SQL> alter pluggable database PDB$SEED open read write;
Pluggable database altered.

SQL> alter pluggable database PDB$SEED close;
Pluggable database altered.

SQL> alter pluggable database PDB$SEED open read only;
Pluggable database altered.

SQL> alter session set "_oracle_script"=false;
Session altered.

Volvemos a verificar:

sys@> show pdbs

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

Vaya, nuestra PDB$Seed tiene algún problemilla, tenemos que revisar PDB_PLUG_IN_VIOLATIONS para ver que sucede:

sys@> 
 Select Name, Cause, Type, Message, Status From Pdb_Plug_In_Violations Where  Status != 'RESOLVED' And Type='ERROR' Order By Name;

El error es claro, así que debemos ejecutar el datapatch para solucionarlo

[oracle@~]$ $ORACLE_HOME/OPatch/datapatch -verbose

Una vez finalizado, verificamos que el problema se ha solucionado:

SQL> 
select type, cause, message,CON_ID
from PDB_PLUG_IN_VIOLATIONS
where status != 'RESOLVED';

no rows selected

Ya no tenemos errores, así que ya solo faltaria dejar nuestra PDB$Seed en modo READ ONLY,

SQL> alter session set container=PDB$SEED;

Session altered.

SQL> alter session set "_oracle_script"=TRUE;

Session altered.

SQL> alter pluggable database PDB$SEED  close immediate instances=all;

Pluggable database altered.

SQL>  alter pluggable database  PDB$SEED OPEN READ ONLY;

Pluggable database altered.

SQL>  alter session set "_oracle_script"=false;

Session altered.

Verificamos de nuevo:

sys@> show pdbs

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

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

En el artículo de hoy vamos a ver como podemos clonar una PDB usando RMAN Active Duplicate o bien usando una instrucción DDL entre diferentes CDB$Root.

DDL

Para el primer caso tengo un script para automatizar este paso. Este script se debe ejecutar con el usuario oracle y en la máquina de destino.

Link a github:

https://github.com/dbaenlasombra/OCI/blob/main/remote_clonning.sh

¿Qué hace el script?

• Define un usuario común en origen con los permisos necesarios. El nombre es una cadena random no es estático, generada en unix "tr -dc 'A-Za-z' </dev/urandom | head -c 5 | tr '[:lower:]' '[:upper:]'" , así como la password , generada y cumpliendo los requisitos mínimos de seguridad de Oracle.

• Define el DB Link en destino. Igual que el paso previo, se genera el nombre de manera aleatoria.

• Creación de la PDB.

Una vez que se ha creado la PDB, el script eliminará el usuario común así como el DB Link.

Todos los nombres se generan random para no interferir con otros trabajos que haya en ese momento en nuestra PDB.

Como pasos previos antes de ejecutar el script, necesitamos hacer lo siguiente:

• Configurar una clave rsa para el usuario oracle en destino con nombre id_rsa y configurar esa clave en origen para permitir la comunicación entre ambas máquinas.

• Configurar el local naming "SOURCE" en el tnsnames de destino con la cadena de conexión de nuestro origen.

• Configurar en destino el parámetro one_step_plugin_for_pdb_with_tde a true.

Este script espera los siguientes parámetros en este orden:

• IP del origen. El motivo, es que abre una conexión ssh con el usuario oracle para entrar como sysdba y ejecutar las instrucciones necesarias para definir el usuario común.

• Nombre de la PDB que vamos a clonar.

• Password de la TDE.

Lanzamos el sh en modo nohup:

[oracle@~]$ 
nohup ./remote_clonning.sh \(1 \)2 $3 > /tmp/remote_clonning.log 2>&1 &

Y esto sería la salida del sh:

El script también nos informaría en caso de fallo:

RMAN ACTIVE DUPLICATE

En este laboratio, también hay un script como en el paso anterior.

Link a github:

https://github.com/dbaenlasombra/OCI/blob/main/rman_clone_pdb.sh

Como pasos previos necesitamos hacer lo siguiente

• Incluir las cadenas de conexión de origen como destino en ambas máquinas.

• Exportar la wallet en origen para importarla en destino.

• Modificar el parámetro remote_recovery_file_dest en destino:

SQL> alter system set remote_recovery_file_dest = '+RECO' scope = both sid = '*';

Este script espera los siguientes parámetros en este orden:

• Connector para la base de datos que hace de auxiliar.

• Connector para la base de datos que hace de target.

• Nombre de la PDB que vamos a clonar.

• Nombre de la DB.

Lanzamos el sh en modo nohup:

[oracle@ ~]\( nohup ./rman_clone_pdb.sh "user\)/\(pass@\)local_name" "user\(/\)pass@\(local_name" \)pdb $db > /tmp/rman_clone_pdb.log 2>&1 &

Y esto sería la salida del sh:

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

En el artículo de hoy voy a compartir un sh que utilizo para ver de una manera rápida los jobs que se ejecutan desde Oracle Database Cloud.

A continuación, te muestro lo que podemos ver cuando ejecutamos el sh:

¿Qué podemos ver? En la parte superior, veremos una entrada inicial dándonos algo de información de la máquina, como el host y la IP, el shape y su timezone.

A continuación, veremos una tabla resumen con el número de total de jobs que se han ejecutado dentro de nuestra máquina, incluyendo los correctos "Success", erróneos "Failure" y de estado desconocido "Others".

En caso que se encuentren jobs erróneos, nos vendrá un detalle de cada job . La estructura que sigue es:

• Nombre del job ejecutado, junto el progreso y el número de hilos dentro del job cuyo estado es erróneo.

• Código y descripción del error.

• Lista de hilos erróneos.

El código del sh es el siguiente:

#!/bin/bash

JOB_NUM=`dbcli list-jobs -j | jq 'length'`
JOB_OK=`dbcli list-jobs -j | jq '[.[] | select(.status=="Success")] | length'`
JOB_KO=`dbcli list-jobs -j | jq '[.[] | select(.status=="Failure")] | length'`
JOB_UNKOWN=$((JOB_NUM - JOB_OK - JOB_KO))

get_Info(){
 curl -s -H "Authorization: Bearer Oracle" http://169.254.169.254/opc/v2/instance/metadata/$1
}

get_Extracc_Info_Job(){
 dbcli describe-job -i "\(1" -l Verbose | grep "\)2" | sed "s/.*$2:[[:space:]]*//"
}

get_Count_Task_Job(){
 dbcli describe-job -i \(1 -l Verbose | awk '/Task Name/{flag=1; next} flag' | awk '{print \)NF}' | grep \(2 | sort | uniq -c | awk '{print \)1}'
}

design_report(){
for ((i=0; i<$1; i++)); do
    printf $2
done
}

design_report 100 '+'
printf '\n'
printf '\n'
echo "Check Jobs in "`hostname`" ("\((get_Info privateIP0)") - Shape "\)(get_Info dbSystemShape)" - Timezone "$(get_Info timeZone)
printf '\n'
design_report 59 '-'
printf '\n'
echo "| ⏰ Jobs ("\({JOB_NUM}") ✅ Success "\){JOB_OK}" ❌ Failure "\({JOB_KO}" ◉  Others "\){JOB_UNKOWN}" |"
design_report 59 '-'
printf '\n'
printf '\n'


if [ "${JOB_KO}" -ne 0 ]; then
echo "Detail Jobs Failure"
design_report 25 '-'
printf '\n'
i=0;
dbcli list-jobs | grep Failure  | awk '{print $1}' | while read -r linea; do
 ((i++))
 percent=\((get_Extracc_Info_Job \){linea} "Progress")
 if [ "$percent" != "NA" ]; then
 percent_n=${percent%\%}
 if [ "\(percent_n" -ge 1 ] && [ "\)percent_n" -le 25 ]; then
  percent="◔ "${percent}
 fi
 if [ "\(percent_n" -ge 26 ] && [ "\)percent_n" -le 50 ]; then
  percent="◑ "${percent}
 fi
 if [ "\(percent_n" -ge 51 ] && [ "\)percent_n" -le 100 ]; then
  percent="◕ "${percent}
 fi
 design_report 3 '·' | sed "s/.*'·':[[:space:]]*//" | tr '·' ' '
 echo \({i}") "\)(get_Extracc_Info_Job \({linea} "Description")" ("\){percent}") ✖ Failure (" \((get_Count_Task_Job \){linea} "Failure") ")"
 design_report 5 '·' | sed "s/.*'·':[[:space:]]*//" | tr '·' ' '
 echo \((get_Extracc_Info_Job \){linea} "Message")
 design_report 5 '·' | sed "s/.*'·':[[:space:]]*//" | tr '·' ' '
 echo "List Task Failure"
 dbcli describe-job -i ${linea} -l Verbose | awk '/Task Name/{flag=1; next} flag' | grep "Failure" | cut -c1-60 | while read -r linea; do
  design_report 6 '·' | sed "s/.*'·':[[:space:]]*//" | tr '·' ' '
  echo "·"${linea}
 done
fi
done
``
fi

design_report 100 '+'
printf '\n'

Y aquí, el link para descargar:

https://github.com/dbaenlasombra/OCI/blob/main/oci_dbcli_info.sh

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

En el artículo de hoy vamos a ver la nueva sintaxis introducida para simplificar aún más los joins evitando errores comunes, haciendo cada sql más legible y explicita, este tipo de consultas son Row Widening Only Queries (RWOQs) garantizando que cada join solo añade columnas y no crea filas adicionales.

Este nuevo tipo de join esta disponible desde la última versión que ha lanzado Oracle, 23.26.2.

SQL> Select banner from v$version;

BANNER
--------------------------------------------------------------
Oracle AI Database 26ai Enterprise 
 Edition Release 23.26.2.0.0 - Production

Antes de meternos en faena con este laboratorio, además de estar con última versión de Oracle vamos a cargar en nuestra PDB el schema HR. Los scripts de este schema se encuentra en el github de Oracle Sample Projects.

Dejo aquí el enlace:

Github Oracle Sample Projects

Este el modelo que hemos cargado:

Fijémonos cual son las tablas principales y cual son las tablas hijas ya que Oracle va usar las propias FK para resolver este join.

El tipo de join que aplica por defecto es LEFT OUTER JOIN.

Algunos beneficios son:

• Simplicidad SQL para complejas consultas.

• Mantiene filtros explícitos a nivel de where o inner.

• Confirma en tiempo de ejecución la unicidad de los join en tiempo de ejecución.

Sin más, veamos algún ejemplo:

Consulta simple

SQL> 
select FIRST_NAME, LAST_NAME, EMAIL, JOB_TITLE  
  from hr.employees aa 
 inner join hr.jobs bb 
    on aa.job_id = bb.job_id
 fetch first 10 rows only

Veamos también el explain plan, para compararlo con el nuevo join:

Ahora realizamos la misma consulta pero usando la nueva sintaxis.

SQL>
select FIRST_NAME, LAST_NAME, EMAIL, JOB_TITLE  
  from hr.employees JOIN TO ONE ( hr.jobs )
 fetch first 10 rows only

El explain plan:

Pues los planes son diferentes, en el primer caso resuelve por NESTED LOOP pero el nuevo join resuelve por MERGE JOIN OUTER ¿motivo? Pues porque el nuevo JOIN resuelve por LEFT OUTER JOIN.

Si ejecutamos la misma query, pero por LEFT OUTER JOIN en vez de INNER, los planes son idénticos:

Consulta compleja

SQL> r
Select STREET_ADDRESS, 
       POSTAL_CODE, 
       CITY,  
       COUNTRY_NAME, 
       REGION_NAME
  from locations aa
 inner join countries cc
    on aa.country_id  = cc.country_id
 inner join regions dd
    on cc.region_id   = dd.region_id
fetch first 10 rows only
/

Ahora realizamos la misma consulta pero usando la nueva sintaxis.

SQL> 
Select STREET_ADDRESS, POSTAL_CODE, CITY,  COUNTRY_NAME, REGION_NAME
FROM
    locations aa
    JOIN TO ONE
        (INNER join countries cc
            on aa.country_id  = cc.country_id
         inner join regions dd
            on cc.region_id   = dd.region_id
)
fetch first 10 rows only

Si nos fijamos, en ambos ejemplos, siempre la tabla de la izquierda es la que hace de tabla principal, y la derecha la hija. Pero ¿Qué pasaría si la tabla principal no tiene FK directa con la tabla hija?.

SQL> 
    Select STREET_ADDRESS, POSTAL_CODE, CITY
          from locations JOIN TO ONE (departments)
      fetch first 10 rows only
      from locations JOIN TO ONE (departments)
                                  *
ERROR at line 2:
ORA-18641: No join key found for "DEPARTMENTS"
Help: https://docs.oracle.com/error-help/db/ora-18641/

Si nos fijamos en el modelo, la tabla LOCATIONS no tiene FK hacía DEPARTMENTS. La FK está definida en DEPARTMENTS, no en LOCATIONS.

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

En el artículo de hoy vamos a definir una auditoría con el objetivo de hacer limpieza de package/procedure/function en una base de datos que ya no se utilizan, con el objetivo de reducir el gran volumen que hay .

La sintaxis para definir la AUDIT será la siguiente:

Create audit policy "_name_" 
 Actions execute On "_owner_"."_name_";

Alter audit policy "_name_" 
  Add Actions execute on "_owner_"."_name_";

La primera sentencia sería la que define nuestra policy, mientras que la segunda sentencia sería para añadir más objetos.

La SQL ad hoc con la sentencia preparada sería la siguiente:

SQL> 
Select 
  ( Case When Rownum = 1 Then 'Create' Else 'Alter ' End )   
    || ' AUDIT POLICY CHECK_EXEC ' || 
  ( Case When Rownum = 1 Then ' ' Else ' ADD ' End ) 
    || ' Actions EXECUTE on '||OWNER||'.'||OBJECT_NAME||';' SDDL
  From Dba_Objects 
  where Owner = '&OWNER' 
    and Object_type  in ('PÀCKAGE','FUNCTION','PROCEDURE');

SDDL
---------------------------------------------------------------
Create AUDIT POLICY CHECK_EXEC   Actions EXECUTE on "_owner_"."_name_";
Alter  AUDIT POLICY CHECK_EXEC  ADD  Actions EXECUTE on "_owner_"."_name_";
Alter  AUDIT POLICY CHECK_EXEC  ADD  Actions EXECUTE on "_owner_"."_name_";
...

Como último paso , activamos la auditoría:

SQL> audit policy CHECK_EXEC;

Una vez que lo tenemos activa podemos ir vigilando la información que nos va auditando:

SQL> 
select *
from unified_audit_trail
where action_name = 'EXECUTE'
and object_schema = upper('&OWNER')
and object_name = upper('&OBJECT')
and return_code = 0
order by EVENT_TIMESTAMP desc
fetch first 10 rows only;

Una vez que hemos dejado el tiempo suficiente, procedemos a extraer la información con la siguiente consulta:

SQL>
With get_Object_bd As (
  Select /*+ MATERIALIZE */
        Owner, Object_Name, object_type
    From dba_Objects 
   Where Owner = '&OWNER' 
     and object_type  in ('PÀCKAGE','FUNCTION','PROCEDURE')
  ),  Audit_Objects as ( 
    Select  /*+ MATERIALIZE */
          object_schema, 
          object_name,
          min(event_timestamp) as first_exec_time,
          max(event_timestamp) as last_exec_time
    from  unified_audit_trail
    where action_name    = 'EXECUTE'
      and object_schema  = '&OWNER'
    group by object_schema, object_name      
)
Select *
From get_Object_bd a 
   left outer join Audit_Objects  b 
  on a.Owner = b.object_schema 
 and  a.object_name = b.object_name 

Esto mismo que hemos hecho con una audit, lo podemos hacer cambiando la profundidad del periodo de retención de ASH/AWR.

La consulta debería hacerse sobre la DBA_HIST_ACTIVE_SESS_HISTORY.

SQL> 
With get_Object_bd As (
  Select /*+ MATERIALIZE */
         object_id, object_name, object_type
    From dba_Objects 
   Where Owner = '&OWNER' 
     And object_type  in ('PÀCKAGE','FUNCTION','PROCEDURE')
)
select object_id, 
       object_name, 
       object_type,
       min(sample_time) first_seen, max(sample_time) last_seen
from get_Object_bd 
 left outer join dba_hist_active_sess_history 
    on object_id = plsql_entry_object_id
  group by object_id, object_name, object_type

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

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!

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!