Oracle Critical Patch Update for April 2025

April 15, 2025

Oracle Critical Patch Update for April 2025

Dear Oracle Customer,

Critical Patch Update for April 2025 was released on April 15, 2025.

Oracle strongly recommends applying the patches as soon as possible.

If you are new to this process, please review Oracle's Security Fixing Policies and the Critical Patch Update Advisory. After reviewing these resources, if you are unable to determine if you require a software update, or how to apply it, please contact Oracle Support.

The Critical Patch Update Advisory is the starting point for relevant information. It includes the list of products affected, pointers to obtain the patches, a summary of the security vulnerabilities for each product suite, and links to other important documents. Supported products that are not listed in the "Affected Products and Components" section of the advisory do not require new patches to be applied.

Also, it is essential to review the Critical Patch Update supporting documentation referenced in the Advisory before applying patches, as this is where you can find important pertinent information.

Critical Patch Update Advisories are available at the following location:

Oracle Technical Resources:

https://www.oracle.com/security-alerts/

Oracle Cloud Customers should review:

https://www.oracle.com/security-alerts/#cloud

The Critical Patch Update Advisory for April 2025 is available at the following location:

Oracle Technical Resources:

https://www.oracle.com/security-alerts/cpuapr2025.html

Important information can also be found at:

https://blogs.oracle.com/security/

Oracle's Security Fixing Policies are available at the following location:

https://www.oracle.com/corporate/security-practices/assurance/vulnerability/security-fixing.html

The next four dates for Critical Patch Updates are:

• July 15, 2025
• October 21, 2025
• January 20, 2026
• April 21, 2026

Thank you,

Customer Support of Oracle Corporation

https://www.oracle.com/support/contact/index.html

"¡Santas omisiones en parches, Batman!"

Hola gente buen inicio de semana para todos y todas.

Mike Dietrich publicó temprano el día de hoy, que mañana se tendrá una actualización trimestral de la versión de base de datos Oracle 23ai con la denominación 23.8.0.

Sin embargo, existe un omisión importante en esta liberación: "Falta el parche de zona horaria DST en la actualización".

Mike menciona, que en enero del 2023, había publicado en su blog, la inclusión de parches para zonas horarias. Sin embargo, más tarde descubró que esto sólo se aplicaba a Oracle Database 19c, no a la 21c o versiones superiores. El mismo hace el comentario que no tiene explicación alguna para esto. Posteriormente se le indicó que se incluiría solo en las versiones con soporte a largo término, pero al parecer no fue así.

La inclusión de correcciones de horario de verano en las RU tuvo un efecto secundario no deseado. El DBCA (Asistente de Configuración de Bases de Datos) no cuenta con un interruptor para seleccionar la versión de zona horaria deseada al crear una nueva base de datos o CDB. Se puede modificar con una variable de entorno. Sin embargo, esto no es ideal y, a veces, simplemente impracticable, menciona Mike en su post del día de hoy.

Cuál es la mala noticia.?

Al menos hasta Oracle Database 23.8, la versión DST debe actualizarse por separado. Oracle Database 23ai, de facto incluye DST versión 43, sin embargo, si estás en alguna de las zonas horarias que tuvo cambios el pasado 22 de marzo, no incluye dichos cambios, como por ejemplo en Paraguay. De igual manera, si estás en versión Oracle Linux 7.x te tengo malas noticias (ver_nota_actualizada), la actualización del paquete TZDATA, no esta disponible para el cambio de horario de verano para el Paraguay. Así que, aunque apliques el parche en la base de datos y tienes OL V7.x, no te sirve de nada. Tendrás que forzar la zona en el sistema operativo. Recuerda que OL V7.x quedó sin soporte en diciembre del año pasado y solo podrás recibir las actualizaciones, si tienes un contrato de soporte extendido.

Para aquellos con Oracle Linux V8.10, si existe la actualización del paquete a 2025b-1.0.1.el8 que contiene dicho cambio.

Así que una recomendación immediata, es migrar su sistema operativo, si tienes una base de datos Oracle 12c o superior.

El fin de Docker ??? Oracle Cloud Infrastructure Resource Manager - Oracle Resource Manager Transitioning from Docker to Podman

Oracle Cloud Infrastructure Resource Manager - Oracle Resource Manager Transitioning from Docker to Podman

Oracle Cloud Infrastructure Customer,

Starting May 8, 2025, Oracle Resource Manager will transition its Terraform job execution environment from Oracle Linux 7 to Oracle Linux 8. 

As part of this transition:

Docker commands will no longer be supported after May 8, 2025.

Podman will be available starting May 8, 2025 as the supported alternative to Docker.

What does this mean for you?

Until May 8, 2025, you can continue to use Docker commands (such as docker build, docker run, or docker buildx) in your Terraform configurations.

Podman is not available before May 8, so no changes are required until then.

After May 8, you must update your Terraform configurations to use Podman instead of Docker for any local-exec or custom scripts.

Learn more about Podman: Getting Started with Podman

Do you need to take any action?

Yes, if you plan to continue using Oracle Resource Manager after May 8, update your configurations to replace Docker commands with Podman equivalents.

No, if you no longer use Oracle Resource Manager or do not rely on Docker in your automation.

Oracle Linux V7.x actualizando paquete tzdata-2025b-1 con cambios zonas horarias Paraguay y Chile.

Imagen: leonardo.ai

Hace unos días atrás publiqué una nota en mi perfil de Linkedin, sobre el tema de las zonas horarias, sobre todo llamando la atención al cambio de horario en #Paraguay y #Chile America/Coyhaique, a partir del 22 de marzo de este año.

Les comenté que el paquete tzdata-2025b-1.el7 no esta disponible para descargar de los repositorios de Oracle Linux 7 y que había realizado la revisión en la ruta https://lnkd.in/euuhDb-E en donde sólo estaba el paquete tzdata-2025a-1.el7 en formato origen, que no contempla el cambio.

Esto porque Oracle Linux V7 ya no tiene soporte desde diciembre 2024.

Hoy revisando les tengo una buena noticia a todos aquellos que tienen Oracle Linux 7. !!!!

El paquete tzdata-2025b-1.el7.src.rpm para se compilado en su servidor, ya esta disponible. !!!

Recuerden este es un paquete que de origen que debe ser compilado.

Es requerido que tengas instalados los siguientes grupos de paquetes para poder compilar:

-groupinstall "Development Tools"

-rpm-build rpmdevtools

-java-devel

Bajamos el código que debemos compilar del paquete y recuerda hacerlo con el usuario "root".

wget https://oss.oracle.com/ol7/SRPMS-updates/tzdata-2025b-1.el7.src.rpm

Instalamos los paquetes prerequisto:

yum groupinstall "Development Tools" -y

yum install rpm-build rpmdevtools -y

yum install java-devel -y

Luego vamos a ejecutar:

rpmdev-setuptree

Esto genera la siguiente estructura de directorios en el lugar en donde estas ejecutando el proceso.

~/rpmbuild/

├── BUILD

├── RPMS

├── SOURCES

├── SPECS

└── SRPMS

Luego ejecutas:

rpm -ivh tzdata-2025b-1.el7.src.rpm

Esto colocará:

El archivo .spec en ~/rpmbuild/SPECS/

El código fuente en ~/rpmbuild/SOURCES/

Para compilar:

cd ~/rpmbuild/SPECS

rpmbuild -ba tzdata.spec

Esto generará los binarios en ~/rpmbuild/RPMS/.

Parte de la compilación del paquete:

-                        12:00  -       +12

+                        12:00  -       %z

 # Kiribati (except Gilbert Is)

 # See Pacific/Tarawa for the Gilbert Is.

 # Zone NAME            STDOFF  RULES   FORMAT  [UNTIL]

 Zone Pacific/Kanton      0     -       -00     1937 Aug 31

-                       -12:00  -       -12     1979 Oct

-                       -11:00  -       -11     1994 Dec 31

-....

+ exit 0

Provides: tzdata = 2025b-1.el7

Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1

Conflicts: glibc-common <= 2.3.2-63

Processing files: tzdata-java-2025b-1.el7.noarch

Provides: tzdata-java = 2025b-1.el7

Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1

Checking for unpackaged file(s): /usr/lib/rpm/check-files /root/rpmbuild/BUILDROOT/tzdata-2025b-1.el7.x86_64

Wrote: /root/rpmbuild/SRPMS/tzdata-2025b-1.el7.src.rpm

Wrote: /root/rpmbuild/RPMS/noarch/tzdata-2025b-1.el7.noarch.rpm

Wrote: /root/rpmbuild/RPMS/noarch/tzdata-java-2025b-1.el7.noarch.rpm

Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.q0FDYz

+ umask 022

+ cd /root/rpmbuild/BUILD

+ cd tzdata-2025b

+ /usr/bin/rm -rf /root/rpmbuild/BUILDROOT/tzdata-2025b-1.el7.x86_64

+ exit 0

[root@lab-ol7-timezone SPECS]# cd ..

[root@lab-ol7-timezone rpmbuild]# ls -la

total 12

drwxr-xr-x. 8 root root 4096 Apr 15 16:50 .

dr-xr-x---. 7 root root 4096 Apr 15 16:49 ..

drwxr-xr-x. 3 root root   34 Apr 15 16:51 BUILD

drwxr-xr-x. 2 root root   10 Apr 15 16:51 BUILDROOT

drwxr-xr-x. 3 root root   28 Apr 15 16:51 RPMS

drwxr-xr-x. 2 root root 4096 Apr 15 16:50 SOURCES

drwxr-xr-x. 2 root root   33 Apr 15 16:50 SPECS

drwxr-xr-x. 2 root root   48 Apr 15 16:51 SRPMS

[root@lab-ol7-timezone rpmbuild]# cd RPMS

[root@lab-ol7-timezone RPMS]# ls -lat

total 4

drwxr-xr-x. 2 root root   97 Apr 15 16:51 noarch

drwxr-xr-x. 3 root root   28 Apr 15 16:51 .

drwxr-xr-x. 8 root root 4096 Apr 15 16:50 ..

[root@lab-ol7-timezone RPMS]# cd noarch/

[root@lab-ol7-timezone noarch]# ls -lat

total 692

drwxr-xr-x. 2 root root     97 Apr 15 16:51 .

-rw-r--r--. 1 root root 189376 Apr 15 16:51 tzdata-java-2025b-1.el7.noarch.rpm

-rw-r--r--. 1 root root 513552 Apr 15 16:51 tzdata-2025b-1.el7.noarch.rpm

drwxr-xr-x. 3 root root     28 Apr 15 16:51 ..

Ahora vamos a instalar el binario creado.

[root@lab-ol7-timezone noarch]# yum localinstall tzdata-2025b-1.el7.noarch.rpm

Loaded plugins: langpacks, ulninfo

Examining tzdata-2025b-1.el7.noarch.rpm: tzdata-2025b-1.el7.noarch

Marking tzdata-2025b-1.el7.noarch.rpm as an update to tzdata-2024b-2.el7.noarch

Resolving Dependencies

--> Running transaction check

---> Package tzdata.noarch 0:2024b-2.el7 will be updated

---> Package tzdata.noarch 0:2025b-1.el7 will be an update

--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================

 Package               Arch        Version        Repository                      Size

=======================================================================================

Updating:

 tzdata                noarch      2025b-1.el7    /tzdata-2025b-1.el7.noarch     1.8 M

Transaction Summary

=======================================================================================

Upgrade  1 Package

Total size: 1.8 M

Is this ok [y/d/N]: y

Downloading packages:

Running transaction check

Running transaction test

Transaction test succeeded

Running transaction

  Updating   : tzdata-2025b-1.el7.noarch                                                                              1/2

  Cleanup    : tzdata-2024b-2.el7.noarch                                                                              2/2

  Verifying  : tzdata-2025b-1.el7.noarch                                                                              1/2

  Verifying  : tzdata-2024b-2.el7.noarch                                                                              2/2

Updated:

  tzdata.noarch 0:2025b-1.el7

Complete!

Cuando termine la instalación, validan la existencia de la clásula de cambio en la zona horaria respectiva.

[root@lab-ol7-timezone noarch]# rpm -q --changelog tzdata | head -20

* Mon Mar 24 2025 Patsy Griffin <patsy@redhat.com> - 2025b-1

- Update to tzdata-2025b (RHEL-84741)

- Chile's Aysén Region moves from -04/-03

to -03 year-round, diverging from America/Santiago and

creating a new zone America/Coyhaique.

* Tue Jan 21 2025 Patsy Griffin <patsy@redhat.com> - 2025a-1

Update to tzdata-2025a (RHEL-74308)

- Paraguay is now permanently at -03. This impacts timestamps

starting on 2025-03-22.

- Includes improvements to pre-1991 data for the Philippines.

- Etc/Unknown is now reserved.

* Fri Sep 27 2024 Patsy Griffin <patsy@redhat.com> - 2024b-2

- Harden against links to removed zones (RHEL-60063)

* Wed Sep 11 2024 Patsy Griffin <patsy@redhat.com> - 2024b-1

- Update to tzdata-2024b

- Improve historical data for Mexico, Mongolia, and Portugal.

- System V names are now obsolescent.

[root@lab-ol7-timezone noarch]# uname -a

Linux lab-ol7-timezone 5.4.17-2136.327.2.el7uek.x86_64 #2 SMP Fri Jan 5 14:53:41 PST 2024 x86_64 x86_64 x86_64 GNU/Linux

[root@lab-ol7-timezone noarch]#

Creando un dblink en Oracle 19c ORA-03150: end-of-file de 19.22 a 19.10 o inferior.

 

Un pequeño detalle que me he encontrado cuando he parchado al Release Update 22 y he querido hacer un DBLINK a una base de datos con un R.U. inferior a 18, que es donde he encontrado que algunas cosas cambian.

[oracle@bd-dev-server admin]$ sqlplus /nolog
SQL*Plus: Release 19.0.0.0.0 - Production on Mon Apr 14 17:05:29 2025
Version 19.22.0.0.0
Copyright (c) 1982, 2023, Oracle. All rights reserved.

idle> connect / as sysdba
Connected.

CDB$ROOT@CDB2> create database link PRODUCCION connect to C##CLONE_USER identified by "E2**************UiRO2" using 'CDBPRODUCCION';

Database link created.

Observen que he utilizado el nombre del usuario C##CLONE_USER sin colocar comillas dobles al inicio y final del usuario.

Cuando hago la prueba del DBLINK el mismo falla con error de comunicación.

CDB$ROOT@CDB2> select 1 from dual@produccion;

select 1 from dual@produccion

*

ERROR at line 1:
ORA-03150: end-of-file on communication channel for database link
ORA-02063: preceding line from PRODUCCION

Borramos el DBLINK y vamos a volverlo a crear.

CDB$ROOT@CDB2> drop database link produccion;
Database link dropped.

Esta vez vamos a crear el DBLINK utilizando el usuario entre comillas dobles.

CDB$ROOT@CDB2> create database link PRODUCCION connect to "C##CLONE_USER" identified by "E27**********iRO" using 'CDBPRODUCCION';

Database link created.

Probamos el DBLINK y ahora si funciona.

CDB$ROOT@CDB2> select 1 from dual@produccion;
1
---------
1

No se que exactamente ha pasado después del RU 19.18, lo cierto es que he tenido un comportamiento extraño en varios temas.

Desde una base de datos en versión E.E. que no permitió crear más de 3 PDBs cuando si lo lograba hacerlo antes del parcheo con indicación que la opción de Multitenant no estaba disponible, hasta estos pequeños detalles.

Sin embargo, no hay mucho por hacer, hay que seguir parchando para evitar quedarnos atrás con el soporte.

Oracle Hot Topics: Apr 03,2025

Knowledge Articles
Knowledge Article    Product Area    Last Updated
ORA-00600 [17287] After Restore / Recovery
Oracle Database - Standard Edition Oracle Cloud Infrastructure - Database Service Oracle Database - Enterprise Edition     Thu, 3 Apr 2025 05:46 GMT-06:00

"This message contains information according to the preferences you set in My Oracle Support. To modify your settings or to turn off this automated message, login to My Oracle Support (http://support.oracle.com) and click on 'More' -> 'Settings' -> 'Hot Topics E-mail'" My Oracle Support

Oracle Hot Topics: Marzo 12, 2025

Bugs
Bug Product Area Bug ID Last Updated
SELECT STATEMENT FAILS WITH [KKPAPDAFKK_INT+816] [SIGSEGV] [ADDR:0XE9] [PC:0X3CAFD40] [ADDRESS NOT MAPPED TO OBJECT]

Oracle Database - Enterprise Edition 31076540 Wed, 12 Mar 2025 04:18 GMT-06:00

"This message contains information according to the preferences you set in My Oracle Support. To modify your settings or to turn off this automated message, login to My Oracle Support (http://support.oracle.com) and click on 'More' -> 'Settings' -> 'Hot Topics E-mail'" My Oracle Support

MOS: Activation Two-Factor authentication (2FA)

 

My Oracle Support Launch of Two-Factor authentication (2FA)

As part of our commitment to enhance the security of your support account, we’ll soon require users to use Two-Factor Authentication (2FA) for My Oracle Support and My Oracle Cloud Support accounts. 2FA adds an extra layer of security by requiring a second verification step when signing into your account. How will this affect you? Once enabled, you will be prompted to enroll in 2FA upon your first login. Follow the instructions on the screen to set up 2FA. We will support Mobile SMS or email ID-based One-Time Password (OTP). For users of the DOD Support Portal or CIO VOX, you will need to re-enroll in 2FA. Note: Additional multi-factor authentication (MFA) options will be made available in the future. If you no longer have access to the email account used to access your support account, you will need to update your profile email by following the instructions outlined in the articles below: My Oracle Support My Oracle Cloud Support Where can I get additional information or help? If you need additional assistance or have any questions, please contact Oracle Support.

Planned Maintenance to My Oracle Cloud Support on Friday, March 14, 2025

Applies To: Customers

Summary
Planned Maintenance to My Oracle Cloud Support on Friday, March 14, 2025

Details

My Oracle Cloud Support will be unavailable because of maintenance during the following period:

• Friday, March 14, 2025, 7:00 PM PT to Friday, March 14, 2025, 9:00 PM PT

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. You will be able to use Communities at https://community.oracle.com/customerconnect/.

Thank you in advance for your patience.

My Oracle Cloud Support Team

Sobre la reciente publicación de Mike Dietrich en su blog: Final blog post about datapatch cleanup and purge

 

El último día del mes de febrero, Mike nos comparte un post, sobre un tema que es poco conocido, pero puede tener un impacto grande, tanto a nivel de estructuras de la base de datos, como en espacio local de almacenamiento en el servidor.

En esta profesión de DBA, a quienes tienen la costumbre de aplicar todos los RU (Release Update) a una base de datos de forma consecutiva, aún cuando no sea necesario hacerlo.

Si yo he instalado la versión base de 19c 19.3.0.0, no necesito instalar ningún RU intermedio para actualizar mi base de datos a 19.25.0.0, pero si es necesario actualizar la herramienta de OPatch, ya que esta si cambia en prerequisitos específicos para cada cierto grupo de RU.

En la práctica, personalmente he visto algunas diferencias importantes en 19.10 y 19.11, que de alguna manera, me lleva como práctica propia a actualizar primero de 19.3 a 19.10 y luego de ahí a 19.18 que es el otro RU que noto diferencias significativs y posteriormente a cualquier RU reciente.

Por ejemplo, he visto cambios importantes en el rendimiento a favor, a la hora de instalar 19.10. Lueg en 19.18 se incluye algunas validaciones adicionales que tienen que ver con el número máximo de PDBs a nivel de contenedor para la versión SE2 y E.E.

A la hora de hacer un parcheo en la versión 19.18 a 19.19 a una base de datos 19c desplegada como IaaS, en una instancia de Oracle Linux en el OCI, se me hizo imposible crear más de 3 PDBs en un contenedor con Oracle Database Enterprise Edition. A pesar que subí un par de casos con el área de PM's del producto, no tuve respuesta al inconveniente sufrido. Después de reinstalar un ambiente nuevo y pasar directamente a 19.15 desde 19.3 no tuve inconvenientes como los descritos anteriormente.

El tema aquí de fondo, es que cada vez que aplicamos un RU, en el proceso previo de aplicación, la herramienta OPatch, hace un backup de aquellos archivos de la versión actualmente instalada, para poder realizar un "rollback" a nivel de la aplicación del parche.

Adicionalmente al OPatch a través del comando "DATAPATCH", guarda en la base de datos, la colección completa de scripts SQL y PL/SQL en un archivo ZIP para poder realizar "ROLLBACK" en el tablespace SYSTEM. Esto como lo afirma Mike provoca inevitablemente que el tablespace SYSTEM crezca con cada aplicación de RU.

Aquí el punto es que no es necesario mantener la copia de los scripts anteriores de cada RU, porque cada aplicación, contiene la información necesaria para disolver los cambios anteriores. Por decirlo de alguna manera, es un respaldo acumulativo.

Si aplico en orden cada RU que fue siendo liberado para una versión base en el software de la base de datos, vamos a ir aumentando acumulativamente el espacio ocupado.

Y esta acumulación no sólo se da a nivel de la metadata del CDB$ROOT o sea en el container database, sino también, se hace en cada metadata para cada pluggable database que tengamos en el contenedor.

Mike nos indica que han logrado crear un parche para poder hacer esta limpieza. El número del parche es el 

• 37352486

Actualmente el parche sólo esta disponible en One-off patches para las versiones 19.25.0, 19.26.0 y 23.7.0.

Una vez aplicado este parche agrega un nuevo parámetro al comando DATAPATCH de la herramienta OPatch:

• ./datapatch -purge_old_metadata

Se espera, que para la liberación del RU del mes de Julio de este 2025, -RU 19.28- ya sea incluido como parte de la herramienta OPatch, on en el mismo RU.

Ya he realizado el proceso de aplicación de la limpieza y la verdad que fue bastante rápido, comparado con el tiempo que tardaba aplicando el proceso anterior.

Existen varias publicaciones sobre este mismo tema en el blog de Mike:

https://mikedietrichde.com/2024/09/30/more-about-cleaning-up-datapatch-patching-files/

https://mikedietrichde.com/2024/09/23/cleanup-datapatch-patching-files-in-your-database/

Para el evento del LAOUC 2025, he subido una propuesta con el nombre de: Tablespace SYSTEM en Peligro: La Trampa del Crecimiento de Datapatch en donde estaré explicando a profundida el procedimiento y mostrando el impacto a nivel de almacenamiento, en el servidor de la base de datos y en el tablespace SYSTEM del contenedor y de cada pluggable database.

En caso de no se admitido para el evento, estaría compartiendo a través de un video con ustedes todo el proceso en un par de meses.

Por el momento, si deseas avanzar por tu cuenta con el tema, puedes consultar el post: https://mikedietrichde.com/2025/02/28/final-blog-post-about-datapatch-cleanup-and-purge/ para comprender el proceso que debe ser ejecutado.

Oracle Hot Topics: Febrero 28, 2025

Bugs

Bug Product Area Bug ID Last Updated
ORA-600 [KDSGRP1] IN ADG AFTER FAILOVER
Oracle Database - Enterprise Edition 22241601 Fri, 28 Feb 2025 03:53 GMT-06:00


Knowledge Articles
Knowledge Article Product Area Last Updated
Support Position for Oracle Products Running on Supported Guest OS under Oracle Linux KVM

Oracle Database Cloud Exadata Service Oracle Database - Enterprise Edition Oracle Cloud Infrastructure - Exadata Cloud Service Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) Gen 2 Exadata Cloud at Customer Wed, 26 Feb 2025 09:08 GMT-06:00

Oracle Base Database Service (BaseDB) - Clone PDB API Deprecation on Base Database Service (Base DB)

 

Action Required

Oracle Cloud Infrastructure Customer, Effective November 01, 2025, theClone PDB APIs listed below are being deprecated and replaced with new APIs. localClonePluggableDatabase RemoteClonePluggableDatabase Additionally the following FIELD will also be deprecated. dbSystemShape Action Required: Please review MOS Note KA311 - API (Clone PDB) Deprecation on Base Database Service (BaseDB for all details of the deprecation as well as learn how to perform equivalent operations. Note: If you have custom or Terraform scripts that reference the APIs and / or the FIELD mentioned above, they should be amended to reflect the changes. If you havce any queries or concerns related to this upcoming chnage, please contact Oracle Support by creating a Service Request(SR) and provide the Reference Number included in this notification. Reference Number bd581112 Action Required By November 1, 2025 00:00 UTC   Service(s) Oracle Base Database Service (BaseDB)

Oracle Hot Topics: Jan 07, 2025

Bugs
Bug Product Area Bug ID Last Updated

VARIOUS ORA-600 OR ORA-7445 IN QUERY WITH LISTAGG AND OTHER AGGREGATIONS IN 19.25

Oracle Database - Enterprise Edition 37334244 Fri, 7 Feb 2025 05:34 GMT-06:00

Knowledge Articles
Knowledge Article Product Area Last Updated

purgeLogs: Archive & Cleanup traces, logs in one command

Exadata Database Machine V2 Oracle Database Appliance Oracle Database Cloud Exadata Service Oracle Database - Enterprise Edition Real Application Clusters Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) Gen 2 Exadata Cloud at Customer Fri, 7 Feb 2025 02:06 GMT-06:0


"This message contains information according to the preferences you set in My Oracle Support. To modify your settings or to turn off this automated message, login to My Oracle Support (http://support.oracle.com) and click on 'More' -> 'Settings' -> 'Hot Topics E-mail'" My Oracle Support

En verdad desaparece la tabla DUAL en la versión de Oracle Database 23ai?

Una de las características más comentadas de la versión 23ai de Oracle Database, es que ahora no es necesario utilizar la famosa tabla "Dummy", que todos conocemos como "DUAL", que nos acompañó desde la versión Oracle 7 !!!.

Pero no te engañes, si activas el plan de ejecución de la sentencia, verás que la ruta de recuperación de valores, realiza un "FAST DUAL"

En versiones antiguas de Oracle (antes de 10g), la tabla DUAL era una tabla física con una única fila y columna. Sin embargo, a partir de Oracle 10g, se reemplazó con una implementación interna basada en una vista sobre X$DUAL, lo que evita accesos innecesarios a segmentos de datos.

Por eso, un plan de ejecución en Oracle 10g o versiones posteriores, mostraran un acceso "FAST DUAL", que indica que Oracle ha optimizado la consulta evitando el acceso a una tabla real y, en su lugar, genera el resultado de manera interna en la memoria, sin necesidad de realizar una operación I/O en disco.

La miniserie de charlas sobre Ethical Hacking, tercer episodio

La miniserie de charlas sobre Ethical Hacking, las podrán observar dentro del grupo del Club de Base de Datos Oracle.

En el tercer episodio ...

https://www.linkedin.com/groups/13164218/

La miniserie de charlas sobre Ethical Hacking, segundo episodio

La miniserie de charlas sobre Ethical Hacking, las podrán observar dentro del grupo del Club de Base de Datos Oracle.

En el segundo episodio ...

https://www.linkedin.com/groups/13164218/

La miniserie de charlas sobre Ethical Hacking- primer episodio.

 La miniserie de charlas sobre Ethical Hacking, las podrán observar dentro del grupo del Club de Base de Datos Oracle.

En el primer episodio ...
https://www.linkedin.com/groups/13164218/

Oracle Topics 30 de enero de 2025

Bugs
Bug Product Area Bug ID Last Updated
ORA-16000 IN ACTIVE DATAGUARD STANDBY DATABASE THROUGH A DATABASE LINK ON BI PUB
Oracle Database - Enterprise Edition 23314355 Thu, 30 Jan 2025 05:25 GMT-06:00

Knowledge Articles
Knowledge Article Product Area Last Updated
Exadata Database Machine and Exadata Storage Server Supported Versions

Oracle Exadata Hardware Oracle Platinum Services Oracle Database Cloud Exadata Service Exadata Database Machine X2-2 Hardware Oracle Database Cloud Service Oracle Database Exadata Express Cloud Service Oracle Cloud Infrastructure - Database Service Oracle Exadata Storage Server Software Oracle Database Cloud Schema Service Oracle Database - Enterprise Edition Oracle Database Backup Service Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) Oracle Cloud Infrastructure - Exadata Cloud Service Gen 2 Exadata Cloud at Customer Tue, 28 Jan 2025 18:48 GMT-06:00

Oracle Hot topics: 20 de enero 2025

Bugs

Bug Product Area Bug ID Last Updated

EXCESSIVE WAIT ON BLOCK CHANGE TRACKING BUFFER SPACE

Oracle Database - Enterprise Edition 30022623 Sat, 18 Jan 2025 03:41 GMT-06:00

Knowledge Articles

Knowledge Article Product Area Last Updated

Release Schedule of Current Database Releases

Oracle Database Cloud Exadata Service Oracle Database Cloud Service Oracle Database - Standard Edition Oracle Database - Enterprise Edition Autonomous Database Dedicated Autonomous Database Serverless Gen 2 Exadata Cloud at Customer Oracle Database - Personal Edition Thu, 16 Jan 2025 18:34 GMT-06:00

Oracle Database 23ai, creando un nuevo PDB from SEED en OCI: Error ORA-28361: Master key not yet set

Escenario:

Estas creando un nuevo PDB en un contenedor de base de datos Oracle en versión 23ai, en una base de datos desplegada como servicio en el OCI.

No tienes inconveniente a la hora de crear el nuevo PDB, pero cuando deseas agregar un "Tablespace" nuevo, te devuelve el error ORA-28361: Master key not yet set.

Esta es la forma en como resolver el problema, siempre y cuando recuerdes la frase que utilizaste para crear la llave de encriptación en el despliegue del servicio.

SQL> connect / as sysdba
Connected.

SQL> show pdbs

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

SQL> show parameter create

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
create_bitmap_area_size              integer     8388608
create_stored_outlines               string
db_create_file_dest                  string      /u02/app/oracle/oradata/cdb_x2
                                                 m_iad/
db_create_online_log_dest_1          string      /u03/app/oracle/redo/
db_create_online_log_dest_2          string
db_create_online_log_dest_3          string
db_create_online_log_dest_4          string
db_create_online_log_dest_5          string

SQL> create pluggable database lab2 admin user admin identified by MY$p*********$2025$;

Pluggable database created.

Elapsed: 00:00:13.68

SQL> alter pluggable database lab2 open;

Pluggable database altered.

Elapsed: 00:00:07.35
SQL> alter pluggable database lab2 save state;

Pluggable database altered.

Elapsed: 00:00:00.05
SQL> show pdbs

    CON_ID CON_NAME                       OPEN MODE  RESTRICTED
---------- ------------------------------ ---------- ----------
         2 PDB$SEED                       READ ONLY  NO
         3 LAB1                           READ WRITE NO
         4 LAB2                           READ WRITE NO
SQL> alter session set container=lab2;

Session altered.

Elapsed: 00:00:00.01
SQL> create user demo identified by MY***********$2025$;

User created.

Elapsed: 00:00:00.18
SQL> grant create session to demo;

Grant succeeded.

Elapsed: 00:00:00.01
SQL> grant dba to demo;

Grant succeeded.

Elapsed: 00:00:00.01
SQL> alter user demo default tablespace users;
alter user demo default tablespace users
*
ERROR at line 1:
ORA-00959: tablespace 'USERS' does not exist
Help: https://docs.oracle.com/error-help/db/ora-00959/


Elapsed: 00:00:00.00

SQL> create tablespace users;
create tablespace users
*
ERROR at line 1:
ORA-28361: Master key not yet set.
Help: https://docs.oracle.com/error-help/db/ora-28361/

Cuando realizas la siguiente consulta, encuentras que en la columna FULLY_BACKED_UP el valor es UNDEFINED.

SQL> SELECT * FROM v$encryption_wallet;
WRL_TYPE   WRL_PARAMETER        STATUS     WALLET_TYPE          WALLET_OR KEYSTORE FULLY_BAC     CON_ID
---------- -------------------- ---------- -------------------- --------- -------- --------- ----------
FILE                            OPEN       AUTOLOGIN            SINGLE    UNITED   UNDEFINED          4

Elapsed: 00:00:00.01

Solución al error:

SQL> ADMINISTER KEY MANAGEMENT SET KEY USING TAG 'rotate_key' FORCE
KEYSTORE IDENTIFIED BY "V4_dS#3LxZ4bdLxyZ2Y2yCj" WITH BACKUP USING 'backup_key';

keystore altered.

Donde el valor de KEYSTORE IDENTIFIED BY, es la frase que escogiste cuando hiciste el despliegue de la base de datos para el tema de encriptación

Elapsed: 00:00:00.21
SQL> create tablespace users;

Tablespace created.

Elapsed: 00:00:00.97

SQL> col WRL_PARAMETER format a20
SQL> SELECT * FROM v$encryption_wallet;

WRL_TYPE   WRL_PARAMETER        STATUS     WALLET_TYPE          WALLET_OR KEYSTORE FULLY_BAC     CON_ID
---------- -------------------- ---------- -------------------- --------- -------- --------- ----------
FILE                            OPEN       AUTOLOGIN            SINGLE    UNITED   NO                 4

Elapsed: 00:00:00.00
SQL>

Oracle Hot Topics: January 13, 2025

Bugs
Bug Product Area Bug ID Last Updated

SEQUENCE.NEXTVAL WITH NOCACHE ON 19C SLOWER THAN 12.1 DUE TO ROW CACHE LOCK
Oracle Database - Enterprise Edition 32043701 Mon, 13 Jan 2025 07:38 GMT-06:00

Knowledge Articles
Knowledge Article Product Area Last Updated
Troubleshooting Guide: ORA-00800 - [Set Priority Failed], [VKTM]

Oracle Database Cloud Exadata Service Oracle Database - Enterprise Edition Oracle Cloud Infrastructure - Exadata Cloud Service Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) Gen 2 Exadata Cloud at Customer Mon, 13 Jan 2025 01:16 GMT-06:00

𝗦𝗣𝗢𝗨𝗚 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆 - 𝙊𝘾𝙄- Zero Trust aplicado a OCI- ACED Rolando Carrasco

 

 𝗦𝗣𝗢𝗨𝗚 𝗖𝗼𝗺𝗺𝘂𝗻𝗶𝘁𝘆 - 𝙊𝘾𝙄

💼El próximo 14 de enero, a la vuelta de Navidades, tienes una nueva cita con SPOUG para este hashtag#webinar de hashtag#OCI

En este webinar, sobre hashtag#OCI, aprenderás sobre Zero Trust aplicado a OCI. La sesión utiliza un proyecto Opensource de nombre OpenZiti.io integrado en la infraestructura de OCI. Utilizaremos Oracle Autonomous, Oracle API Gateway, Oracle VCNs y Subnets y todo lo que implique el networking en OCI

Conoce todos los detalles en el link que te dejo abajo ⤵️

🎯Aplica los conceptos de Zero Trust a tus Cloud Services ejecutándose en OCI
🎙Rolando Carrasco
💼 SPOUG Community: OCI
📍 Virtual
📅 14 de enero
⌚ 11:00h CET Time
✍️ Registro Miembro SPOUG ➡ https://lnkd.in/dg_wqzWZ

🚨📣 Aún no eres miembro de la Comunidad SPOUG? Contacta con nosotros vía sonia.cuesta@spoug.es.


¡NO TE LO PUEDES PERDER!


hashtag#SPOUG hashtag#Oracle hashtag#OCI hashtag#SPOUGCommunity