martes, 25 de noviembre de 2025

My Oracle Support Site Alert: Planned Maintenance to My Oracle Support Portal on Friday December 5, 2025

 

My Oracle Support will be unavailable due to planned maintenance during the following period: 

Friday, December 5, 2025, 3:00 PM PT to 7:00 PM PT 

Additionally, My Oracle Support will transition to the new experience on Sunday, December 7, 2025, at 10:00 AM PT. Please ensure you save your work before this time. 

During the maintenance period, you will not be able to create, view, or update service requests through our customer support portals. Oracle Support services will continue to be available, and you can reach us via telephone for any critical issues. The Oracle Support telephone numbers for your location are available in the Oracle Support Center. 

In addition, access to Oracle Knowledge Base will be available from https://support-lite.oracle.com and MOS Communities are available at https://community.oracle.com. 

If you are using Oracle monitoring services like ASR and Platinum, these will continue to monitor your systems. Creation and update of Service Requests will occur after Sunday, December 7, 2025, 10:00AM PT, if required. 

Thank you in advance for your patience. 

The My Oracle Support Team 


miércoles, 12 de noviembre de 2025

Explicación técnica del error ORA-06590: PL/SQL Native mode con la versión de Oracle Linux

A pesar que aún no se documenta como un BUG en MOS, efectivamente estamos ante uno de ellos.

Les doy una pista: la diferencia no es del sistema operativo, sino de un cambio interno en Oracle Database introducido a partir del RU 19.28

Vamos por partes !!!

Definitivamente existen algunas diferencias importantes entre las versiones de Oracle Linux V7 y V8 y una de ellas es como se gestiona el sistema de archivos /dev/shm y otros sistemas de archivos virtuales.

En un contexto general, /dev/shm es un sistema de archivos de tipo tmpfs que proporcina memoria compartida de POSIX.

POSIX (Portable Operating System Interface for Unix) es un conjunto de estándares que definen como se debe comportar los sistemas operativos tipo UNIX para ser compatibles y portables entre sí. Me siento como en los 90's cuando inicié a estudiar DG/UX. :-)

La memoria compartida es un mecanismo mediante el cual dos o más procesos pueden acceder al mismo segmento de memoria física para intercambiar información sin pasar por el disco ni usar llamadas al sistema de E/S.

Esto la hace extremadamente rápida, ideal para bases de datos, servidores de aplicaciones y sistemas de tiempo real. La memoria compartida POSIX es una implementación estandarizada por POSIX de ese concepto, permitiendo que los procesos, creen, abran, lean, escriban y sincronicen segmentos de memoria compartida.

Estos sistemas utilizan nombres simbólicos que el kernel gestiona dentro de un sistema de archivos virtual, como por ejemplo /dev/shm. En Linux entonces, /dev/shm es la representación en disco de la memoria compartida POSIX.

La gestión de montaje de /dev/shm es distinta en las versiones OL7x y OL8x. En el caso de OL7x, se monta automáticamente por el kernel del sistema operativo y no necesariamente aparece en el archivo /etc/fstab. Mientras que en OL8x, es gestionado por "systemd" mediante la unidad tmp.mount y aparece explícitamente como un sistema montado al listarlo con el comando "mount".

SYSTEMD es el gestor de sistemas y servicios utilizado por OL que reemplaza a los antiguos scripts de inicio en los SYSTEM V. El primer proceso que se inicia en el arranque del sistema es el PID 1 y el último que se ejecutado durante el apagado.

Para la implementación en memoria, en OL7x el funcionamiento de /dev/shm es un enlace simbólico a /run/shm en algunos casos, heredando el comportamiento de "glibc" y del kernel.

Mientras en OL8x, /dev/shm es un montaje directo de tmpfs, no es simbólico.

Debido a lo indicado anteriormente, para OL7x la compilación NATIVA en Oracle Database funciona sin intervención manual, pero en OL8x, el montaje de /dev/shm al hacerse bajo el control del gestor SYSTEMD y por políticas de seguridad que incluye "noexec" rompe la compatibilidad con procesos que ejecutan código temporal como lo hace PL/SQL NATIVE.

Bajo esta primicia, las versiones de Oracle Database 19c/21c/26ai, al compilar código en modo nativo, se van a ver afectadas en OL8x.

Ahora, porque funcionaba bien la compilación con el R.U. 19.27 y ya no en R.U. 19,28 en adelante.?

El comportamiento de la compilación NATIVE en Oracle Database 19c cambió a partir del Release Update (RU) 19.28, y eso explica por qué antes funcionaba aunque /dev/shm estuviera montado con noexec, mientras que desde 19.28 (y en 19.29) empieza a fallar.

Hasta las versiones de Oracle 11g y 12c Oracle Database utilizaba un directorio específico para el compilador cuando se utilizaba la opción NATIVE de PL/SQL.En alguna documentación se encuentra referencias a $ORACLE_HOME/plsql/native, sin embargo, era ajustado según la necesidad específica a través del parámetro PLSQL_NATIVE_LIBRARY_DIR. Durante el proceso, Oracle generaba archivos C y librerías objeto (.so) que luego son enlazadas dentro del $ORACLE_HOME, sin necesidad de ejecutarse directamente desde /dev/shm.

Aunque el runtime de Oracle usaba /dev/shm para ciertas estructuras internas, la ejecución de código binario nativo no ocurría directamente dentro de /dev/shm — solo se almacenaban allí buffers de memoria y estructuras compartidas.

Por tanto, aunque /dev/shm tuviera noexec, no había conflicto con la ejecución del código nativo.

En las versiones 18c en adelante, los parámetros:
  • PLSQL_NATIVE_LIBRARY_DIR
  • PLSQL_NATIVE_LIBRARY_SUBDIR_COUNT
  • PLSQL_NATIVE_C_COMPILER
  • PLSQL_NATIVE_LINKER, fueron declarados depreciados y retirados.
En las versiones 19c, el motor de PL/SQL ahora realiza la compilación completamente dentro del motor de Oracle — sin generar archivos C ni invocar al compilador externo.
Es decir, ya no se generan archivos .c ni .so en el sistema operativo.

El código se traduce internamente a un formato nativo binario, almacenado dentro de los mismos segmentos del diccionario de datos, bajo la administración del motor PL/SQL.

Que pasa a partir de RU 19.28?

El cambio llega con mejoras de seguridad y aislamiento del proceso de compilación nativa, introducidas por Oracle para alinearse con las políticas de seguridad del runtime compartido y el manejo de compilación JIT (Just-In-Time) interna, según alguna documentación de referencia.

En concreto:
A partir del RU 19.28, Oracle modificó la estrategia de carga dinámica del compilador NATIVE para utilizar áreas temporales en memoria compartida — principalmente en /dev/shm — antes de mapear las librerías objeto generadas.

Esto busca mayor velocidad y aislamiento en entornos multitenant (CDB/PDB), especialmente cuando hay compilaciones concurrentes. Esto hace que a partir de RU 19.28 exista una dependencia total sobre /dev/shm.

Por tanto, la diferencia no es del sistema operativo, sino de un cambio interno en Oracle Database introducido a partir del RU 19.28, que mueve parte de la compilación nativa al espacio de memoria compartida ejecutable (/dev/shm), lo cual exige que esté montado con exec.

Por eso, la compilación NATIVE deja de funcionar a partir de RU 19.28 si /dev/shm está con noexec.


ORA-06590: PL/SQL: Native mode requires execute privileges on the shared memory object directory después de aplicar RU 19.28 en Oracle Linux 8.x


Si tienes "Oracle Database 19c Release 19.0.0.0.0 - Production Version 19.28.0.0.0 y quieres compilar en modo NATIVE una unidad de programación, vas a recibir el error: "ORA-06590: PL/SQL: Native mode requires execute privileges on the shared memory object directory". 

El error también se reproduce en RU 19.29, si haz aplicado desde otro parcheo distinto a RU 19.27.

El mismo ambiente que con 19.27 no genera error. Funciona correctamente sin inconvenientes, hasta la aplicación del parche.

Recuerden la idea de compilar funciones, procedimientos o paquetes en modo NATIVE es que en lugar de generar bytecode, se genere código C que luego se traduce a una biblioteca compartida compilada. El código fuente de PL/SQL se compila directamente a código máquina, dando como resultado una ejecución más rápida.

El problema es con /dev/shm la carpeta especial en Linux que representa una porción de memoria RAM utilizada como sistema de archivos temporal. El sistema /dev/shm sirve para que distintos procesos puedan intercambiar información rápidamente sin pasar por el disco, utilizando la memoria compartida del kernel.

En Oracle Linux 8 de facto se monta /dev/shm con el atributo "noexec" que es la opción de montaje del sistema que impide la ejecución de cualquier binario o script almacenado en esa ubicación.

Lo que se debe hacer es remontar /dev/shm con: mount -o remount,exec /dev/shm y luego cambiar la línea en el archivo /etc/fstab como se ve a continuación, para evitar que en el siguiente reinicio, vuelva a la configuración original.

# Error en compilacion de objetos NATIVE en Oracle Database
# ORA-06590: PL/SQL: Native mode requires execute privileges on the shared memory object directory
# tmpfs          /dev/shm        tmpfs  defaults,nodev,nosuid,noexec   0 0
tmpfs          /dev/shm            tmpfs  defaults,nodev,nosuid   0 0


Esto se reproduce a partir de la aplicación del Release Update 19.28 en el motor de la base de datos Oracle 19c.

La solución fue prevista por el MOS en atención al SR 3-42843259511 : Error when compiling an object in NATIVE code Oracle Database 19c RU 19.28, por tanto, se encuentra documentado.

Gracias a la ayuda de Sakthivel Subramanian, Oracle Support

Veamos el caso en detalle, tengo el siguiente código en la base de datos correspondiente a un procedimiento almacenado del esquema HR.


Con el R.U. 19.27 puedo cambiar los valores del parámetro PLSQL_CODE_TYPE de INTERPRETED a NATIVE y compilar sin problemas.


Ahora procedemos a parchar la base de datos con el R.U. 19.28


Al recompilar el procedimiento con el valor del parámetro PLSQL_CODE_TYPE en NATIVE, se reproduce el error.

Pueden observar más claramente el error de compilación en la vista DBA_ERRORS


Todos los componentes de la base de datos, están en estado VALIDO


Después de hacer los ajustes en el remontaje del sistema de archivos, el error desaparece









 

sábado, 8 de noviembre de 2025

Oracle Ai Database 26ai: Tablas con atributo STAGING

Una de las nuevas características de Oracle 26ai en Autonomous Database, son las tablas con atributo de STAGING.

Oracle indica que esta nueva versión admite este tipo de tablas de almacenamiento provisional, optimizadas para carga de datos en un servidor de tipo LAKEHOUSE.

Hasta la versión 23ai de Autonomous, teníamos de 4 tipos de bases de datos según su carga de trabajo:
        1. ADW ( Data Warehouse)
        2. ATP (Transaction Processing), DEFAULT
        3. JSON ( Utilización de datos tipos JSON
        4. APEX Service
En la versión 26ai, se le agrega el 5 tipo: LAKEHOUSE y es el nuevo tipo DEFAULT de despliegue de Autonomous Database 26ai.

El concepto de Lakehouse lo podemos simplificar diciendo que  es una plataforma que combina lo mejor de un Data Lake y un Data Warehouse en un mismo entorno.

Lakehouse, te va permitir almacenar grandes volúmenes de datos sin estructura como en un Data Lake, pero con capacidades de análisis, seguridad y gobernanza de un Data Warehouse. Así los datos pueden ser almacenados en bruto, transformados y consultados con el lenguaje SQL o incluso con la utilización de IA desde el mismo lugar.

Un dato importante, es que esta tecnología permite usar transacciones ACID sobre los datos en el Datalake, utilizando Apache Iceberg.

Ahora volviendo sobre como iniciamos esta conversación, las tablas de atributo STAGING tiene ciertas características interesantes que describe la documentación de Oracle textualmente:
  • Se ha desactivado explícitamente cualquier tipo de compresión en la tabla de almacenamiento provisional para cualquier carga de datos. El comando ALTER TABLE COMPRESS no está permitido.
  • Modificar el atributo de STAGING en una tabla existente no afecta al almacenamiento de los datos existentes, pero sí a las futuras cargas de datos.
  • La base de datos de IA autónoma utiliza un muestreo dinámico para las estadísticas de las tablas con la propiedad de almacenamiento provisional establecida, y no recopila estadísticas sobre las tablas de almacenamiento provisional.
  • Al eliminar las tablas provisionales las borra inmediatamente, sin pasar por la papelera de reciclaje. Establecer el parámetro de recyclebin de inicialización en el valor ON, no habilita la papelera de reciclaje.
  • Cualquier forma de compresión está explícitamente desactivada y prohibida en todas las particiones y subparticiones de la tabla.
  • No se pueden cambiar los atributos predeterminados de la tabla para usar la compresión con ALTER TABLE MODIFY DEFAULT ATTRIBUTES.
  • No se pueden realizar operaciones de mantenimiento de particiones que muevan y compriman datos. Por ejemplo, al intentar aplicar compresión, no se permiten las siguientes opciones: ALTER TABLEcon MOVE PARTITION, MERGE PARTITIONS, SPLIT PARTITION, o SPLIT SUBPARTITION.
  • No se puede volver a particionar una tabla ALTER TABLE MODIFY PARTITION y especificar que alguna partición resultante se vaya a comprimir.
Realicé un pequeño testing inicial, para validar si realmente existe beneficio en el uso de tablas con el atributo de STAGING y obtuve como resultado lo siguiente:
  1. Efectivamente al crear la tabla con el atributo y borrarla, no paso por la papelera de reciclaje, podemos poner check a este punto.
  2. En carga de 2 millones de registros a través de una ciclo con la generación de data aleatoria, no existió variación importante entre la carga de la tabla con STAGING y una normal. No check para este punto.
  3. Al actualizar datos directamente sobre la tabla STAGING, registre una mejoría del 12% en el tiempo empleado contra una tabla normal. Aquí también podemos poner check.
  4. Al realizar consultas sobre la tabla con el atributo STAGING y la normal, la base de datos Oracle AI Database 26ai, si coloca de una los datos en RESULT CACHE, como lo indica la documentación inicial. Check aquí también.
En resumen, al parecer si existen mejoras importantes con operaciones simples tipo DML sobre las tablas con el atributo STAGING. Tenemos que seguir investigando un poco más sobre el empledo de IA como fuente de repositorio de datos para entrenamiento de modelos de entrenamiento, pero sobre esto les brindará más informacion más adelante.

Pueden ver el contenido de lo utilizado en el laboratorio, a continuación.
select * from v$version;
Oracle AI Database 26ai Enterprise Edition Release 23.26.0.1.0 - for 
Oracle Cloud and Engineered Systems


CREATE TABLE part_staging_table_normal (col1 number, col2 varchar2(100))
    PARTITION BY RANGE (col1)
          (PARTITION p1 VALUES LESS THAN (100), 
           PARTITION pmax VALUES LESS THAN (MAXVALUE));
           
CREATE TABLE part_staging_table (col1 number, col2 varchar2(100))
    PARTITION BY RANGE (col1)
          (PARTITION p1 VALUES LESS THAN (100), 
           PARTITION pmax VALUES LESS THAN (MAXVALUE)) FOR STAGING; 
           
begin
for i in 1 .. 1000000 loop
insert into part_staging_table
values (DBMS_RANDOM.VALUE(1, 100), dbms_random.string('P',trunc(dbms_random.value(50,99))));
end loop;
for i in 1 .. 1000000 loop
insert into part_staging_table
values (DBMS_RANDOM.VALUE(50,200), dbms_random.string('P',trunc(dbms_random.value(50,99))));
end loop;
commit;
end;
/

begin
for i in 1 .. 1000000 loop
insert into part_staging_table_normal
values (DBMS_RANDOM.VALUE(1, 100), dbms_random.string('P',trunc(dbms_random.value(50,99))));
end loop;
for i in 1 .. 1000000 loop
insert into part_staging_table_normal
values (DBMS_RANDOM.VALUE(50,200), dbms_random.string('P',trunc(dbms_random.value(50,99))));
end loop;
commit;
end;
/
select count(*) from PART_STAGING_TABLE
where col1 < 100;




drop table PART_STAGING_TABLE_NORMAL select count(*) from PART_STAGING_TABLE_NORMAL where col1 < 100;
drop table PART_STAGING_TABLE
show recyclebin;
create table part_tx_table (col1 number, col2 varchar2(100)) PARTITION BY RANGE (col1) (PARTITION p1 VALUES LESS THAN (100), PARTITION pmax VALUES LESS THAN (MAXVALUE)); create table part_tx_table2 (col1 number, col2 varchar2(100)) PARTITION BY RANGE (col1) (PARTITION p1 VALUES LESS THAN (100), PARTITION pmax VALUES LESS THAN (MAXVALUE)); ## Actualización en tabla sin claúsula STAGING
update part_staging_table_normal
set col2=dbms_random.string('P',trunc(dbms_random.value(20,99)))
where col1 < 50;

494,143 rows updated.

Elapsed: 00:00:18.287

## Actualización en tabla con claúsula STAGING
update part_staging_table set col2=dbms_random.string('P',trunc(dbms_random.value(20,99))) where col1 < 50; 494,637 rows updated. Elapsed: 00:00:16.220 insert into part_tx_table select * from part_staging_table; 2,000,000 rows inserted. Elapsed: 00:00:02.720 insert into part_tx_table2 select * from part_staging_table_normal; 2,000,000 rows inserted. Elapsed: 00:00:02.673

miércoles, 5 de noviembre de 2025

Oracle Hot topics: Nov 5, 2025

 

Bugs

Bug Product Area Bug ID Last Updated

ORA-600 [KTATMKREF-RS] ERRORS IN THE ALERT LOG POST-PATCH 37260974

Oracle Database - Enterprise Edition 37690446 Wed, 5 Nov 2025 09:43 GMT-06:00

Knowledge Articles

Knowledge Article Product Area Last Updated

AHF Fleet Insights

Oracle Database Cloud Exadata Service Generation 1 - Exadata Cloud at Customer (First Generation Cloud Machine) Oracle Database Cloud Service Oracle Database Exadata Express Cloud Service Oracle Cloud Infrastructure - Database Service Oracle Exadata Storage Server Software Oracle Database - Enterprise Edition Oracle Database Cloud Schema Service Oracle Database Backup Service Oracle Cloud Infrastructure - Exadata Cloud Service Wed, 5 Nov 2025 10:52 GMT-06:00

PLSQL Procedure Causing ORA-04030: (pga heap,control file i/o buffer) And ORA-04030: (koh-kghu sessi,pmuccst: adt/record) or ORA-04030: (koh-kghucall ,pmucalm coll) Errors

Oracle Database Exadata Express Cloud Service Oracle Database Cloud Exadata Service Oracle Database Cloud Service Generation 1 - Exadata Cloud at Customer (First Generation Cloud Machine) Oracle Database - Standard Edition Oracle Cloud Infrastructure - Database Service Oracle Database - Enterprise Edition Oracle Database Cloud Schema Service Oracle Database Backup Service Wed, 5 Nov 2025 03:21 GMT-06:00


martes, 4 de noviembre de 2025

Error en WRAPPED de objetos en la base de datos con ediciones habilitadas a nivel de esquema

 

Imagina que tu base de datos es una biblioteca y tus programas (procedimientos, paquetes, vistas, etc.) son los libros que se usan para trabajar con los datos.

Cuando quieres hacer una actualización a esos programas (como mejorar un paquete PL/SQL), normalmente tendrías que reemplazar el “libro viejo” por uno nuevo. Si alguien está usando el libro viejo en ese momento, podría haber problemas o peor aún que tal si la nueva versión no funciona como debería hacerlo.?

Editioning en Oracle permite que podamos habilitar la posibilidad de manejar varias copias de una misma unidad de programación.

La versión actual se podría mantener en la base de datos mientras que otros usuarios están probando las nuevas funcionalidades en la nueva versión.

Pero en este post no hablaré de las ediciones, sino de un pequeño inconveniente que me he encontrado a la hora de intentar hacer un WRAP (ofuscación) sobre el código fuente PL/SQL dentro de la base de datos.

Si utilizas el programa "wrap" a nivel del servidor de la base de datos, es realmente sencillo poder ofuscar el código fuente antes de crearlo en la base de datos.

Tenemos el siguiente contenido en un archivo que queremos ofuscar:

[oracle@srvdb-val scripts]$ cat sql1.sql
create procedure signo as
begin
DBMS_OUTPUT.PUT_LINE('Signo: '||chr(36));
end;
/
[oracle@srvdb-val scripts]$ wrap iname=sql.sql oname=sql1_wrap.sql

[oracle@srvdb-val scripts]$ cat sql1_wrap.sql
create procedure signo wrapped
a000000
369
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
abcd
7
48 81
99jW3DVEca9cb1YulwPEPlgnuZkwg5nnm7+fMr2ywFwW/1ly2eq4dIvAwDL+0obAUpuySv4o
sr3nsrMdBjAsriTqsoFwyGbVRIHsqxfQyrILgi4u9tHqJB/2Oaa1eY6r

/
Lo anterior no presenta ningún inconveniente, pero cuando se tienen habilitadas las ediciones a nivel del esquema y exportamos el código fuente para luego  hacer UNWRAP y modificar el código fuente para agregar una nueva funcionalidad o hacer un pequeño cambio, en el encabezado del código encontraremos que el SQLDeveloper agrega la palabra EDITIONABLE al encabezado de definición del objeto.

[oracle@srvdb-val scripts]$ cat sql1a.sql
create EDITIONABLE procedure signo as
begin
DBMS_OUTPUT.PUT_LINE('Signo: '||chr(36));
end;
/

[oracle@srvdb-val scripts]$ wrap iname=sql1a.sql oname=sql1a_wrap.sql
[oracle@srvdb-val scripts]$ cat sql1a_wrap.sql create EDITIONABLE procedure signo as begin DBMS_OUTPUT.PUT_LINE('Signo: '||chr(36)); end; / [oracle@srvdb-val scripts]$

Como resultado al ofuscar el código con la utilidad WRAP el archivo con la salida del código protegido no es correcto.

De facto, cuando un esquema ha sido modificado para soportar EDICIONES el agregará en el proceso de creación de un objeto el atributo EDITIONABLE de facto, por tanto, se puede quitar el atributo del encabezado del archivo que necesitamos ofuscar y no habrá ningún problema.

Este inconveniente se ha validado en 19.29, con el mismo comportamiento.

viernes, 17 de octubre de 2025

Oracle Hot Topics October 17,2025

 

Bugs

Bug Product Area Bug ID Last Updated

ORA-2072 AND ORA-2063 ON QUERY VIA DBLINK

Oracle Database - Enterprise Edition 17890099 Fri, 17 Oct 2025 06:19 GMT-06:00

Knowledge Articles

Knowledge Article Product Area Last Updated

Bug 37926045 - 23ai -Add support for OL9.6 RHCK, RHEL9.6 KERNEL UPDATES

Oracle Database - Enterprise Edition Thu, 16 Oct 2025 07:26 GMT-06:00


miércoles, 15 de octubre de 2025

En este 2025, Halloween cae en viernes "13" -31 de octubre-.

 

En tecnología tenemos ciertos mitos con ciertas fechas y días.

Por ejemplo, "nunca" se debe hacer un pase en un día jueves.

Cada 5, 6 o 11 años, el 31 de Octubre- Halloween- cae en un viernes 31.

Que ha pasado en los años más recientes cuando el 31 de Octubre fue un viernes en la celebración de Halloween:

🎩 1902
📰 Hecho importante: Se funda la empresa Real Madrid C.F. en España.
💡 Además, el presidente estadounidense Theodore Roosevelt impulsa la política del “Big Stick”, consolidando el poder de EE.UU. en América Latina.

🚂 1908
📰 Hecho: Ocurre el Evento de Tunguska en Siberia (explosión masiva atribuida a un meteorito).
💡 Marca un punto de interés científico en el estudio de impactos astronómicos.

🌍 1913
📰 Hecho: Se inaugura el Canal de Panamá, una de las mayores obras de ingeniería del siglo XX.
💡 Conecta los océanos Atlántico y Pacífico, transformando el comercio mundial.

⚔️ 1919
📰 Hecho: Firma del Tratado de Versalles, que pone fin oficialmente a la Primera Guerra Mundial.
💡 Redibuja el mapa político de Europa.

📈 1924
📰 Hecho: Se funda la URSS formalmente con su nueva Constitución.
💡 Consolidación del poder comunista bajo Lenin (murió ese mismo año).

📻 1930
📰 Hecho: Descubrimiento del planeta Plutón por Clyde Tombaugh.
💡 Marca un avance astronómico (aunque posteriormente fue reclasificado).

🌍 1941
📰 Hecho: Ataque a Pearl Harbor (diciembre), EE.UU. entra en la Segunda Guerra Mundial.
💡 Cambia el rumbo del conflicto global.

🕊️ 1947
📰 Hecho: Se independiza India del Reino Unido.
💡 Nace la mayor democracia del mundo moderno; también se crea Pakistán.

💣 1952
📰 Hecho: EE.UU. realiza la primera prueba de bomba de hidrógeno (“Ivy Mike”).
💡 Inicio de la era termonuclear.

🚀 1958
📰 Hecho: Se crea la NASA.
💡 Da inicio a la carrera espacial formalmente.

🌑 1969
📰 Hecho: Llegada del hombre a la Luna (Apolo 11).
💡 Uno de los hitos más grandes de la historia de la humanidad.

🎵 1975
📰 Hecho: Se lanza Microsoft (fundada oficialmente por Gates y Allen).
💡 Da inicio a la era moderna del software personal.

💾 1980
📰 Hecho: Se comercializa el primer IBM PC y comienza la expansión de la computación personal.
💡 También nace el estándar Ethernet.

🌎 1986
📰 Hecho: Desastre nuclear de Chernóbil en la URSS.
💡 El accidente nuclear más grave de la historia.

💻 1997
📰 Hecho: Se lanza el primer navegador de Apple (Safari precursor) y se funda Netflix.
💡 Internet empieza su gran expansión comercial.

🕋 2003
📰 Hecho: Invasión de Irak liderada por EE.UU.
💡 Marca el inicio de un largo conflicto en Medio Oriente.

📱 2008
📰 Hecho: Crisis financiera global y publicación del whitepaper de Bitcoin por Satoshi Nakamoto.
💡 Se transforma el sistema económico y nace la era de las criptomonedas.

🌐 2014
📰 Hecho: Crisis de Crimea (anexión rusa) y auge del Estado Islámico (ISIS).
💡 Se intensifican los conflictos geopolíticos modernos.

Después de leer esto, estarías dispuesto a hacer un pase a producción el 31 de octubre de este año.?

#JoelKallmanDay Parámetro oculto "_pdb_auto_save_state" en Oracle Container Database


Cuando implementamos una base de datos en Contenedor, es muy normal que vayamos aumentando la cantidad de bases de datos acopladas (pluggable database).

Cuando una PDB sea crea, de facto está queda en estado "MOUNT" y es necesario abrir la base de datos para poder trabajar con ella.

Sin embargo, si tenemos que reiniciar el contenedor las PDBs quedan en el estado original o en el último estado en la que la hemos guardado.

Hay una forma en como mantener el último estado registrado para todos los PDBs en el Contenedor, sin necesidad de preocuparnos de estar al tanto del estado de PDBs.

Esto se logra configurando el parámetro oculto "_pdb_auto_save_state" en el Contenedor de la base de datos, como se demuestra a continuación.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           MOUNTED
         5 PDB1_DR                        MOUNTED

SQL> alter pluggable database pdb2 open;

Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB1_DR                        MOUNTED
         
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area 7868511032 bytes
Fixed Size                  9196344 bytes
Variable Size            1509949440 bytes
Database Buffers         6341787648 bytes
Redo Buffers                7577600 bytes
Database mounted.
Database opened.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           MOUNTED
         5 PDB1_DR                        MOUNTED

SQL> alter system set "_pdb_auto_save_state"=TRUE scope=both;
System altered.

SQL> alter pluggable database PDB2 open;
Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB1_DR                        MOUNTED

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area 7868511032 bytes
Fixed Size                  9196344 bytes
Variable Size            1509949440 bytes
Database Buffers         6341787648 bytes
Redo Buffers                7577600 bytes
Database mounted.
Database opened.
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           MOUNTED
         4 PDB2                           READ WRITE NO
         5 PDB1_DR                        MOUNTED

SQL> alter pluggable database pdb1 open;
Pluggable database altered.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB1_DR                        MOUNTED

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup
ORACLE instance started.

Total System Global Area 7868511032 bytes
Fixed Size                  9196344 bytes
Variable Size            1509949440 bytes
Database Buffers         6341787648 bytes
Redo Buffers                7577600 bytes
Database mounted.
Database opened.

SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 PDB1                           READ WRITE NO
         4 PDB2                           READ WRITE NO
         5 PDB1_DR                        MOUNTED
SQL>

sábado, 11 de octubre de 2025

"Enshittification" (algo así como “degradificación”), para describir cómo las plataformas tecnológicas se deterioran a medida que priorizan los beneficios sobre los usuarios.




Esta semana he pasado algunas horas desmenuzando un artículo de New York Times del escritor Cory Doctorow sobre si la tecnología se esta utilizando como herramienta de empoderamiento o de represión. El autor, pretende en su nuevo libro "busca ofrecer consuelo y soluciones a la inevitable sensación de que las plataformas digitales han empeorado".

El autor quién ha escrito 15 novelas, docenas de cuentos y 6 libros de no ficción y apróximadamente 60 mil publicaciones en su blog y miles de ensayos, el galardonado autor y veterano activista de Internet ha acuñado la palabra "Enshittification" (algo así como “degradificación”), para describir cómo las plataformas tecnológicas se deterioran a medida que priorizan los beneficios sobre los usuarios.

El artículo en mención, hace incapié en la sensación general, de un sentimiento mucho mayor de frustración que TENEMOS, -si afirmo yo también-, sobre las plataformas actuales disponibles que están plagadas de SPAM. Y no sólo hablamos del contenido de INTERNET, sino también, de los videojuegos, televisión y la misma política de todos nuestros países.

Doctorow dice que es frustrante, desmoralizante e incluso aterrador.

“Estoy sumamente entusiasmado, esperanzado y lleno de energía por las posibilidades que la tecnología puede ofrecernos como personas que intentamos prosperar”, dijo Doctorow, “y a la vez aterrorizado por lo perjudicial que será para ese proyecto si nos equivocamos”.

Y es que no basta mucho tiempo, para darse cuenta, la errática dirección que muchas otroras buenas herramientas, han tomado en los últimos 2 años. X antes "Twitter" era una fuente de pasatiempo de conocimiento para mi. Hoy es una burda versión de un programa continuo de anuncios y mensajes directos sobre los intereses que más le conviene a la plataforma. Cada vez, veo menos necesario permanecer en ella. Aún haciendo pago de subscripción, no logró eliminar y entrenar al algoritmo para que muestre lo que me interesa, sin un porcentaje absurdo de anuncios. En mi opinión, es una plataforma fallida.

Recuerdo cuando Facebook ocupaba mucho de nuestro tiempo con aquellos juegos simples, como la "Granja" FarmVille. Un juego que fue emblemático en la era temprana de las redes sociales, desarrollado por Zynga y lanzado a mediados del 2009, con más de 83 millones de usuarios. Sin embargo, la explosión de los teléfonos "inteligentes" y el auge de sus aplicaciones, lo mató en poco tiempo. Los teléfonos moviles, cambio el modo de monetización de nuestro tiempo, ya fuesé para reclamar nuestro tiempo en el trabajo, bajó el constante SPAM de mensajes de cosas que podrían haber esperado para el día siguiente, o el aumento de la ansiedad por esperar ese mensaje que nos afirmaba o no algo que nos urge saber. Estamos en tiempos de "Urgencia" ya nada debe consumir mucho más de un pestañeo. Esto es lo que en mi parecer, ha convertido a la tecnología en una herramienta de represión, generando el efecto mariposa entre aquellos que interactúamos con ella.

jueves, 25 de septiembre de 2025

Oracle Hot Topics: 25/09/2025

Bugs

Bug Product Area Bug ID Last Updated

SQLLDR SHOULD ALLOW THE CONTROLFILE SCHEMA TO HAVE A DOT IN THE SCHEMA NAME

Oracle Database - Enterprise Edition 35940931 Thu, 25 Sep 2025 04:27 GMT-06:00

Knowledge Articles

Knowledge Article Product Area Last Updated

Bug 37926038 - 19c - [OL9, RHEL9] OL9.6 RHCK, RHEL9.6 Kernel Updates (5.14.0-570.el9_6 and Later RHEL 9.6 and OL9.6 RHCK Kernels)

Oracle Database - Enterprise Edition Tue, 23 Sep 2025 08:14 GMT-06:00

miércoles, 10 de septiembre de 2025

SPOUGAcademy; Como integrar la GenAI en la base de datos para ejecutar consultas con lenguaje natural

 


Ejecutando consultas sin escribir una sentencia completa de lenguaje de programación.
La combinación de modelos de lenguaje grande (LLM) de IA generativa con Oracle SQL le permite describir lo que desea ( intención declarativa ) y dejar que la base de datos genere la consulta SQL relevante para su esquema. Algunos LLM pueden ser buenos para generar SQL, pero poder ejecutar ese SQL en su base de datos es otra cuestión.
 Select AI permite generar SQL que es específico para la base de datos.
 
Obtendremos una primera impresión de las nuevas características incorporadas de GenAI en las bases de datos autónomas de Oracle en la Nube, el nuevo comando SELECT AI y la generación de información sintética.
 
¿Qué se va a aprender? GenAI en las bases de datos autónomas de Oracle en la Nube, el nuevo comando SELECT AI y la generación de información sintética.

📍 Virtual
👨🏻 Ronald Francisco Vargas Quesada
📅 23 de septiembre
⌚ 17h CET Time
✍️ Registro Miembro SPOUG ➡ https://lnkd.in/dxurGbV2
✍️ Registro NO Miembro SPOUG ➡ https://lnkd.in/dwDrqpps

martes, 9 de septiembre de 2025

Oracle ACE Program presenta ACE Live: una nueva serie de seminarios web para la comunidad de Oracle


9 de septiembre de 2025 | 



Nos complace anunciar el lanzamiento de ACE Live, una nueva serie de seminarios web externos que presenta a los mejores ponentes de Oracle ACE de todo el mundo. Diseñado para desarrolladores, arquitectos, administradores de bases de datos (DBA) y líderes de TI, ACE Live ofrece sesiones gratuitas, impartidas por expertos y detalladas sobre las últimas tecnologías y mejores prácticas de Oracle.

Organizado en la plataforma ASK TOM , ACE Live facilita más que nunca la conexión con los líderes de opinión de Oracle ACE. Además, es abierto y gratuito para todos. ¡Le animamos a unirse a las sesiones y compartir la invitación con su red!

Próximas sesiones

Comenzamos ACE Live con dos sesiones que no te puedes perder:

Oracle ACE Live: Descubra activos y fortalezas ocultos con los gráficos de conocimiento de 23ai

• Fecha: 24 de septiembre de 2024
• Hora: 8:00 a. m. (hora del Pacífico)
• Orador: Jim Czuprynski , director de Oracle ACE

¿Su organización acaba de realizar una importante adquisición? ¿De repente se ha encargado de descubrir activos y habilidades digitales en los nuevos equipos? Únase a Jim Czuprynski para demostrar cómo Oracle 23ai Knowledge Graphs puede revelar poderosamente conexiones ocultas dentro del portafolio en expansión de su empresa. Aprenderá a aprovechar los Knowledge Graphs de 23ai, la interfaz de usuario RDF y SQL Developer para identificar y utilizar nuevo hardware, software, personal y habilidades de forma rápida y eficiente. Esta sesión es imprescindible para cualquiera que se enfrente a los desafíos de una fusión o adquisición (M&A) o un cambio organizacional a gran escala.

Temas clave:
• Mapeo de activos y personal después de una fusión y adquisición
• Aplicación de análisis de gráficos para obtener inteligencia empresarial significativa
• Uso de las nuevas funciones de Oracle 23ai para descubrir valor en sus datos
 

Oracle ACE Live: TDE desmitificado: configuración, funcionamiento y buenas prácticas en Oracle

• Fecha: 12 de noviembre de 2024
• Hora: 7:00 a. m. (hora del Pacífico)
• Orador: Stefan Oehrli , Oracle ACE

¿Le preocupa la seguridad de sus bases de datos? El Cifrado Transparente de Datos (TDE) es esencial, pero configurarlo y usarlo correctamente requiere conocimientos prácticos. En esta sesión exhaustiva, Stefan Oehrli le explicará todo, desde la gestión de almacenes de claves y la configuración de WALLET_ROOT hasta las diferencias entre almacenes de claves de hardware y software. Recibirá información práctica y demostraciones en vivo para proteger sus bases de datos Oracle con confianza.

Temas clave:
• Configuración de TDE y mejores prácticas operativas
• Gestión y seguridad del almacén de claves
• Cifrado a nivel de columna y espacio de tabla con demostraciones prácticas

Cómo unirse

¡ Participar es fácil y gratis ! Solo usa los enlaces de arriba o inicia sesión en la plataforma ASK TOM , busca la serie ACE Live y regístrate en cualquiera de los eventos que te interesen. Sin cuotas de inscripción ni barreras: solo educación Oracle de primer nivel impartida por expertos de ACE . No pierdas esta oportunidad de profundizar tus conocimientos sobre Oracle y mantenerte a la vanguardia en un panorama tecnológico en constante evolución.

Manténganse al tanto de las próximas sesiones. ¡Esperamos verlos en ACE Live!

 

Gerente de la comunidad Oracle ACE

Todos los Sábados a las 8:00PM