Check this week's agenda with upcoming events from Oracle and the DBA Community!

 By GREPORA EXPERTISE

What's up this week? Check this week's agenda with upcoming events from Oracle and the DBA Community!

15/02 RMOUG Training Days 2023 #Community #online #InPerson We’re excited to announce our Training Days 2023 Conference Agendas are packed with over 130 Technical Sessions, and 11 Workshops covering a wide range of topics, including Analytics, Big Data, Application Development, Cloud, Database Administration, and more. See more! Migrate Oracle Databases to on-premises and cloud with a Safety Net using Migration Workbench #Community #AIOUG #online Join this live demo session and Learn how to migrate databases to Exadata on-premises, to Exadata Database Service (Shared, Dedicated, or Cloud@Customer), to Autonomous, and to Base Database Service (SI, RAC, BM, or VM). Find out how SQL queries of migrated databases are automatically validated for high performance along with recommendations leveraging integrated SQL Performance Analyzer (SPA), thus ensuring your business applications continue to perform as per your requirements. See more! 16/02 Next Level Oracle Monitoring | Options, Features, Deep-Dive #community #UKOUG #online Performance and availability, and moreover, Oracle observability, are the hot topics for the next decade. Get a guided tour on advanced Oracle monitoring based on Microsoft System Center Operations Manager, run by the NiCE Product Experts. The NiCE Oracle Management Pack, in conjunction with one of the big players in IT Operations Management, easily enables end-to-end Oracle observability and thus helps reduce risk and downtime. See more! 17/02 Oracle Analytics Cloud and the No Code Predictive Analytics #Community #AIOUG #online Are you naive when it comes to making predictions using Machine learning models? Well, Oracle Analytics, with its robust Machine Learning capabilities, is here to your rescue. Without a single line of code written, here is your chance to experience OAC’s power to predict valuable results to derive meaningful insights that are critical to business. See more! OATUG TECH SIG TALK: PATCHING TIPS AND TRICKS PANEL #Community #OATUG #online Online patching has changed many things in the life of an EBS DBA. Please join our panel as we pass on some of the things we do to as part of using online patching on our EBS environments. After sharing tips and tricks, the panel will answer questions from the attendees. See more!

Planned Maintenance to My Oracle Support Portal on Friday February 10, 2023

Planned Maintenance to My Oracle Support Portal on Friday February 10, 2023

My Oracle Support Portal (MOS) will be undergoing maintenance from Friday Feb 10, 2023, 7:00 PM PST to Saturday Feb 11, 2023, 7:30 AM PST.

During the maintenance period you will not be able to create, view, or update SRs through our Customer Support portals. Oracle Support Services will continue to be available and can be reached via telephone for any critical issues that need immediate attention. In addition, access to Oracle Knowledge Base will be available from https://support-lite.oracle.com and you will be able to use MOS Communities at https://community.oracle.com. If you are using Oracle monitoring services like ASR and Platinum, these will continue to monitor your systems. However, the creation and update of Service Requests will occur after the planned maintenance if required.

You can find the telephone numbers for your location at Oracle Support Center.

Historial de acciones sobre los PDBs de un Contenedor de Base de Datos

Cada acción que se realiza sobre un PDB en un contenedor de base de datos, deja huella registrada.

Con la siguiente consulta en el contenedor de la base de datos, puedes obtener el historial de dichas acciones.

SQL> @fecha_pdbs.sql

DB_NAME    CON_ID PDB_NAME        OPERATION        OP_TIMESTA CLONED_FROM_PDB

---------- ------ --------------- ---------------- ---------- ---------------

G6486           3 PDB$SEED        UNPLUG           09-JAN-20

G6486           4 PDB$SEED        UNPLUG           09-JAN-20

G6486           5 PDB$SEED        UNPLUG           09-JAN-20

G6486           6 PDB$SEED        UNPLUG           09-JAN-20

G6486           7 PDB$SEED        UNPLUG           09-JAN-20

DBMIGRA         3 PDB$SEED        PLUG             04-FEB-21  PDB$SEED

DBMIGRA         4 PDB$SEED        PLUG             04-FEB-21  PDB$SEED

DBMIGRA         5 PDB$SEED        PLUG             04-FEB-21  PDB$SEED

DBMIGRA         6 PDB$SEED        PLUG             04-FEB-21  PDB$SEED

DBMIGRA         7 PDB$SEED        PLUG             04-FEB-21  PDB$SEED

DBMIGRA         3 PDB1            CREATE           04-FEB-21  PDB$SEED

DBMIGRA         4 FCUBSUAT        CREATE           14-DEC-22  PDB$SEED

DBMIGRA         5 OBDXUAT         CREATE           14-DEC-22  PDB$SEED

DBMIGRA         6 OBBRNUAT        CREATE           14-DEC-22  PDB$SEED

DBMIGRA         7 FISERESUAT      CREATE           14-DEC-22  PDB$SEED

15 rows selected.

SQL> host more fecha_pdbs.sql
set pagesize 20
COLUMN DB_NAME FORMAT A10
COLUMN CON_ID FORMAT 999
COLUMN PDB_NAME FORMAT A15
COLUMN OPERATION FORMAT A16
COLUMN OP_TIMESTAMP FORMAT A10
COLUMN CLONED_FROM_PDB_NAME FORMAT A15

SELECT DB_NAME, CON_ID, PDB_NAME, OPERATION, OP_TIMESTAMP, CLONED_FROM_PDB_NAME
FROM CDB_PDB_HISTORY
WHERE CON_ID > 2
ORDER BY OP_TIMESTAMP,CON_ID

/

OCI Oracle Linux: SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptable' ...

He notado en algunos de mis servicios con Oracle Linux en la nube un error particular en el estado del servicio del FIREWALL.

Cuando reviso el estado, el mismo me arroja una serie de mensajes incómodos de "WARNINGS" como se muestra a continuación:

[root@SRV-AUDIT yum.repos.d]# systemctl status firewalld

? firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-11-01 08:16:42 CST; 4s ago
Docs: man:firewalld(1)
Main PID: 29173 (firewalld)
Tasks: 2
CGroup: /system.slice/firewalld.service
+-29173 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid


Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --destination 192.168.122.0/24 --o...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --source 192.168.122.0/24 --in-int...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --in-interface virbr0 --out-interf...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --out-interface virbr0 --jump REJE... that name.

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --in-interface virbr0 --jump REJEC... that name.

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete OUTPUT --out-interface virbr0 --protocol u...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp...at chain?).

Hint: Some lines were ellipsized, use -l to show in full.

Investigando un poco encontre que deshabilitando el "libvirtd" se soluciona el problema. Como pueden comprobar a continuación, una vez deshabilitado y reiniciado el servicio del FIREWALL, ya no tenemos el mensaje de precaución.

[root@SRV-AUDIT yum.repos.d]# systemctl stop libvirtd
[root@SRV-AUDIT yum.repos.d]# systemctl disable libvirtd

Removed symlink /etc/systemd/system/multi-user.target.wants/libvirtd.service.
Removed symlink /etc/systemd/system/sockets.target.wants/virtlogd.socket.
Removed symlink /etc/systemd/system/sockets.target.wants/virtlockd.socket.

[root@SRV-AUDIT yum.repos.d]# systemctl status firewalld
? firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-11-01 08:16:42 CST; 2min 48s ago
Docs: man:firewalld(1)
Main PID: 29173 (firewalld)
CGroup: /system.slice/firewalld.service

+-29173 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid


Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --destination 192.168.122.0/24 --o...at chain?).
Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --source 192.168.122.0/24 --in-int...at chain?).
Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --in-interface virbr0 --out-interf...at chain?).
Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete FORWARD --out-interface virbr0 --jump REJE... that name.
....
Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete INPUT --in-interface virbr0 --protocol udp...at chain?).

Nov 01 08:16:43 SRV-AUDIT firewalld[29173]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -w --table filter --delete INPUT --in-interface virbr0 --protocol tcp...at chain?).

Hint: Some lines were ellipsized, use -l to show in full.

[root@SRV-AUDIT yum.repos.d]# systemctl restart firewalld

[root@SRV-AUDIT yum.repos.d]# systemctl status firewalld
? firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)

Active: active (running) since Tue 2022-11-01 08:20:02 CST; 4s ago
Docs: man:firewalld(1)
Main PID: 5063 (firewalld)
Tasks: 2
CGroup: /system.slice/firewalld.service
+-5063 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid

Nov 01 08:20:02 SRV-AUDIT systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 01 08:20:02 SRV-AUDIT systemd[1]: Started firewalld - dynamic firewall daemon.
[root@SRV-AUDIT yum.repos.d]# systemctl status firewalld

? firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: active (running) since Tue 2022-11-01 08:20:02 CST; 12s ago
Docs: man:firewalld(1)
Main PID: 5063 (firewalld)
Tasks: 2
CGroup: /system.slice/firewalld.service
+-5063 /usr/bin/python2 -Es /usr/sbin/firewalld --nofork --nopid

Nov 01 08:20:02 SRV-AUDIT systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 01 08:20:02 SRV-AUDIT systemd[1]: Started firewalld - dynamic firewall daemon.
[root@SRV-AUDIT yum.repos.d]#

El programa libvirtd es el componente daemon del lado del servidor del sistema de administración de virtualización libvirt. 

Este demonio se ejecuta en servidores host y realiza las tareas de administración requeridas para invitados virtualizados. Esto incluye actividades como iniciar, detener y migrar invitados entre servidores host, configurar y manipular redes y administrar el almacenamiento para uso de los invitados. 

Las bibliotecas y utilidades del cliente libvirt se conectan a este daemon para ejecutar tareas y recopilar información sobre la configuración y los recursos del sistema host y los invitados.

Según la documentación, el LIBVIRT Daemon, se ejecuta como un servicio SYSTEMD monolítico en Oracle Linux 7 y Oracle Linux 8.  Mientras que en Oracle Linux 9, el servicio se divide en múltiples sockets de servicios funcionales para un mayor control atómico y registro de cada componenente de virtualización.

En Oracle Linux 9

Los componentes o controladores funcionales individuales se modularizan en demonios separados que se exponen mediante tres sockets systemd para cada controlador.

Los siguientes demonios systemd están definidos para controladores individuales libvirt específicamente para KVM:

• virtqemud: es el demonio de gestión de QEMU, para ejecutar máquinas virtuales en KVM.
• virtnetworkd: es el demonio de gestión de red virtual.
• virtnodedevd: es el daemon de administración de dispositivos físicos del host.
• virtnwfilterd: es el demonio de gestión del cortafuegos del host.
• virtsecretd: es el demonio de gestión de secretos del host.
• virtstoraged: es el demonio de administración de almacenamiento del host.
• virtinterfaced: es el demonio de administración de la tarjeta de interfaz de red (NIC) del host.

Todos los demonios de virtualización deben estar ejecutándose para exponer la funcionalidad de virtualización completa disponible en libvirt.

Oracle ADRCI: DIA-49803: Purge not possible due to incompatible schema version

Un error que he encontrado últimamente en repetidas ocasiones en algunas instancias de base de datos y que esta ligado al momento de querer purgar el contenido de las bitácoras gestionadas a través de la utilidad ADRCI -Automatic Diagnostic Repository Command Interpreter-, es el DIA-49803.

Básicamente, esto sucede cuando se hace una actualización manual de la base de datos.

Veamos el error.

oracle@lab1 alert]$ adrci
ADRCI: Release 19.0.0.0.0 - Production on Sun Jan 8 15:35:51 2023
Copyright (c) 1982, 2020, Oracle and/or its affiliates. All rights reserved.

ADR base = "/home/app/oracle"
adrci> show homes
ADR Homes:
diag/tnslsnr/lab1/listener
adrci> show alert

ADR Home = /home/app/oracle/diag/tnslsnr/lab1/listener:

*********************************************************************

Output the results to file: /tmp/alert_94014_1401_listener_1.ado

adrci> purge -age 360
DIA-49803: Purge not possible due to incompatible schema version.

adrci> purge -age 60
DIA-49803: Purge not possible due to incompatible schema version.

A la hora de validar la versión del esquema, nos damos que la misma es distinta.

adrci> show version schema
Schema version (on-disk): 80
Schema version (library): 110

Para solucionar el error, es suficiente correr el comando "migrate schema" y listo, ya podemos nuevamente darle mantenimiento a los históricos retenidos en el repositorio de carga.

adrci> migrate schema
Schema migrated.

adrci> show version schema
Schema version (on-disk): 110
Schema version (library): 110

adrci> purge -age 360

Planned Maintenance to My Oracle Support Portal on Friday February 10, 2023

My Oracle Support Portal (MOS) will be undergoing maintenance from Friday Feb 10, 2023, 7:00 PM PST to Saturday Feb 11, 2023, 7:30 AM PST.

During the maintenance period you will not be able to create, view, or update SRs through our Customer Support portals. Oracle Support Services will continue to be available and can be reached via telephone for any critical issues that need immediate attention. In addition, access to Oracle Knowledge Base will be available from https://support-lite.oracle.com and you will be able to use MOS Communities at https://community.oracle.com. If you are using Oracle monitoring services like ASR and Platinum, these will continue to monitor your systems. However, the creation and update of Service Requests will occur after the planned maintenance if required.

You can find the telephone numbers for your location at Oracle Support Center.

Detalle en la instalación de Oracle Golden Gate 21.3: Base de datos 19c 19.11 igual a 21c.?

Una curiosidad que me encontré en el log de instalación de OGG 21c.

Mi laboratorio lo configuré con Oracle Database 19c 19.11. No le instalé el PSU 19.17, porque el fin de semana, había problemas con las descargas en el MOS.

Al instalar la versión 21.3 de OGG y revisar el log, me encuentro que el tipo de instalación y la opción, hace mención a 21c.

Me pregunto, si esto será parte del problema que tengo con la definición de un extractor.?

Ya les contaré más adelante.

INFO: Start Oracle GoldenGate Manager process. : 0.1
INFO: ---------------------------------------
INFO: Starting to setup OGGInstall
INFO: Initializing setup OGGInstall
INFO: Session Details :

INFO: Setting property oracle.installer.ignoreCheckpoint to value : true

INFO: setting ORACLE_HOME_NAME=OraHome1. A default value was calculated as per oraparam.ini

INFO: Reading shiphome metadata from /opt/instaladores/ogg_install/fbo_ggs_Linux_x64_Oracle_shiphome/Disk1/install/../stage/shiphomeproperties.xml

INFO: Loading beanstore from file:/opt/instaladores/ogg_install/fbo_ggs_Linux_x64_Oracle_shiphome/Disk1/install/../stage/shiphomeproperties.xml

INFO: Translating external format into raw format

INFO: Restoring class oracle.install.driver.oui.OUIMetadata from file:/opt/instaladores/ogg_install/fbo_ggs_Linux_x64_Oracle_shiphome/Disk1/install/../stage/shiphomeproperties.x

ml

INFO: Loading beans from Xml Bean Store. [BeanStoreName:oui-metadata]

INFO: Setting value for the property:properties in the bean:oui-metadata

OGG-03542 Failed to connect to the database / OCI Error ORA (status = 12154-ORA-12154: TNS

Quieres conectarte al contenedor de base de datos o a un PDB con la consola de Oracle GoldenGate y recibes el mensaje del título de este posteo.?

Existen varias razones, pero si verificas que tu salida en el error muestra de forma adecuada el seteo de la variable "TNS_ADMIN" y no esta en blanco; lo más posible es que tu cadena de conexión definida en el "TNSNAMES", no corresponde con el nombre que estás utilizando a la hora de conectarte con el comando dblogin.

Para efectos de configuración de OGG, la variable TNS_ADMIN debe ser seteada como parte del ambiente del usuario "ORACLE".

Me explico: en este ejemplo, me quiero conectar a la instancia de base datos acoplada con el nombre pdb1 y como ven tengo da error la conexión.

GGSCI (oraclerdbms-origen) 1> dblogin userid c##ggadmin@pdb1 password oracle

2023-01-21 20:47:39  INFO    OGG-03542  Failed to connect to the database. Verify that the connection string and following environment variables are correct:

TNS_ADMIN = /opt/app/oracle/product/19c/network/admin

LD_LIBRARY_PATH = /opt/app/oracle/product/19c/lib.

Error: OCI Error ORA (status = 12154-ORA-12154: TNS:could not resolve the connect identifier specified)

Al revisar la definición de la conexión en el TNSNAMES.ORA, me dí cuenta que había llamado a la cadena de conexión con el nombre "ORIGEN".

De ahí el error.

GGSCI (oraclerdbms-origen) 2> dblogin userid c##ggadmin@origen password oracle

Successfully logged into database.

Creando alias a cuentas de conexión en Oracle GoldenGate 21.3 en ambiente Multitenant

Si ya se que es bastante incómodo conectarse a la consola del interpretador de comandos de Oracle GoldenGate.

Pero se puede facilitar bastante esto, creando alías de conexión.

Veamos como hacemos esto en un ambiente Multitenant en donde tenemos que conectarnos tanto al CDB como a un PDB.

Primero que todo, he creado un simple alias a nivel de sistema operativo, para cambiarme al directorio casa de GoldenGate y ejecutar el llamado a la consola.

[oracle@oraclerdbms-origen ~]$ more .bash_profile

# .bash_profile

PATH=$PATH:$HOME/.local/bin:$HOME/bin

export PATH

ORACLE_SID=cdb

ORACLE_BASE=/opt/app/oracle

ORACLE_HOME=/opt/app/oracle/product/19c

OGG_HOME=/opt/app/oracle/product/ogg

TNS_ADMIN=$ORACLE_HOME/network/admin

export ORACLE_SID ORACLE_BASE ORACLE_HOME OGG_HOME TNS_ADMIN

PATH=$ORACLE_HOME/bin:$OGG_HOME:$PATH

export PATH

alias ogg='cd $OGG_HOME; ./ggsci'

[oracle@oraclerdbms-destino ogg]$ ogg

Oracle GoldenGate Command Interpreter for Oracle

Version 21.3.0.0.0 OGGCORE_21.3.0.0.0_PLATFORMS_210728.1047_FBO

Oracle Linux 7, x64, 64bit (optimized), Oracle Database 21c and lower supported versions on Jul 29 2021 03:59:23

Operating system character set identified as UTF-8.

Copyright (C) 1995, 2021, Oracle and/or its affiliates. All rights reserved.

En mi caso, ya tengo un usuario configurado en el CDB para los temas de OGG con el nombre de "c##ggadmin" con el password "oracle"

Vamos a conectarnos.

GSCI (oraclerdbms-origen) 2> dblogin userid c##ggadmin@cdb password oracle

Successfully logged into database CDB$ROOT.

Una vez conectados, vamos a agregar un almácen de credenciales, con la instrucción a continuación.

GGSCI (oraclerdbms-origen as c##ggadmin@cdb/CDB$ROOT) 3> add credentialstore

Credential store created.

Creado el almácen de credenciales, con el comando "ALTER CREDENTIALSTORE" vamos a agregar un alias para la conexión al CDB de mi base de datos.

Cuando se ejecuta el comando, el mismo va a solicitar la clave del usuario en la base de datos.

GGSCI (oraclerdbms-origen as c##ggadmin@cdb/CDB$ROOT) 4> alter credentialstore add user c##ggadmin@cdb alias ogg_root

Password:
Credential store altered.

En este caso, para la conexión al CDB hemos definido el alias de "ogg_root".

Nota: Cuidado OGG es sensitivo, cuiden las mayúsculas y minúsculas.

Vamos también a agregar un alias para la conexión a mi pluggable database.

En la definición del usuario para Oracle GoldenGate, el usuario se hace a nivel del contenedor de base de datos y aplicable para todos los PDBs.

GGSCI (oraclerdbms-origen as c##ggadmin@cdb/CDB$ROOT) 5> alter credentialstore add user c##ggadmin@origen alias ogg_pdb

Password:
Credential store altered.

Con el comando "INFO CREDENTIALSTORE", podemos validar los alias almacenados en el almácen de credenciales.

GGSCI (oraclerdbms-origen as c##ggadmin@cdb/CDB$ROOT) 6> INFO CREDENTIALSTORE

Reading from credential store:
Default domain: OracleGoldenGate
Alias: ogg_root
Userid: c##ggadmin@cdb

Alias: ogg_pdb
Userid: c##ggadmin@origen

Ahora si, para conectarnos al contenedor o a un PDB, podemos simplicar la conexión utilizando la instrucción "DBLOGIN USERIDALIAS" + "ALIAS".

Para el contenedor:

GGSCI (oraclerdbms-origen as c##ggadmin@cdb/CDB$ROOT) 7> dblogin useridalias ogg_root
Successfully logged into database CDB$ROOT.

Para el PDB:

GGSCI (oraclerdbms-origen as c##ggadmin@cdb/CDB$ROOT) 8> dblogin useridalias ogg_pdb

Successfully logged into database.

Oracle Critical Patch Update for January 2023

 January 17, 2023

Oracle Critical Patch Update for January 2023

The Critical Patch Update for January 2023 was released on January 17, 2023.
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 January 2023 is available at the following location:

Oracle Technical Resources:
https://www.oracle.com/security-alerts/cpujan2023.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:

April 18, 2023
July 18, 2023
October 17, 2023
January 16, 2024

Los 3 scripts que deberías tener a mano para descargar los últimos PSU de Oracle Database 19c a Enero de 2023

Saludos gente

Me imagino que como me ha pasado, en ocasiones estás de carreras y necesitas bajar rápidamente un PSU para hacer un parche a una base de datos.

Cuando ingresas a MOS para ir a la zona de parches y descargas generalmente lo haces desde tu máquina de trabajo y no desde el servidor.

Esto implica, que debes luego trasladar el archivo descargado al servidor en donde vas a ejecutar la actualización.

Bueno, puedes ahorrar parte de ese tiempo si tu servidor tiene navegación a internet. Antes de darle descargar a un archivo del MOS, al lado izquierdo abajo, encontrarás la opcion "wget Options"

Al hacer click en dicho enlace se despliega la siguiente pantalla. En la opción de "Download.sh", puedes obtener los scripts necesarios, para descargar directamente a través del comando "WGET" el archivo a tu servidor.

Nada más apuntar el siguiente detalle por ahí. Vas a necesitar tu cuenta de acceso MOS y que la misma tenga permisos para descarga de parches. Si tu cuenta no tiene asociado un CSI, no será posible que puedas hacer esta acción.

Cuando bajes el script, lo puedes abrir en un editor de texto y copiarlo en un archivo dentro de tu servidor de Linux o Unix.

Debes cambiar los permisos del archivo a 700 ( todo para el dueño y nada para los demás )

Luego al ejecutarlo, te va solicitar la cuenta de SSO de acceso al MOS.

Una vez ingresada la cuenta se queda en blanco y debes digitar tu contraseña y presionar la tecla de ENTER. De lo contrario, "esperarás la inmortalidad del cangrejo" y no pasará nada.

Si deseas, puedes tener abierta otra venta de tu emulador de terminal favorito - yo por lo general utilizo PUTTY - y así podrás confirmar el avance de la descarga.

Estos son los scripts que puedes utilizar, para descargar los últimos 3 PSU para Oracle Database 19c.

download_1915.sh

#!/bin/sh

#

# Generated 1/11/23 3:23 PM

# Start of user configurable variables

#

LANG=C

export LANG

# Trap to cleanup cookie file in case of unexpected exits.

trap 'rm -f $COOKIE_FILE; exit 1' 1 2 3 6

# SSO username

printf 'SSO UserName:'

read SSO_USERNAME

# Path to wget command

WGET=/usr/bin/wget

# Log directory and file

LOGDIR=.

LOGFILE=$LOGDIR/wgetlog-$(date +%m-%d-%y-%H:%M).log

# Print wget version info

echo "Wget version info:

------------------------------

$($WGET -V)

------------------------------" > "$LOGFILE" 2>&1

# Location of cookie file

COOKIE_FILE=$(mktemp -t wget_sh_XXXXXX) >> "$LOGFILE" 2>&1

if [ $? -ne 0 ] || [ -z "$COOKIE_FILE" ]

then

 echo "Temporary cookie file creation failed. See $LOGFILE for more details." |  tee -a "$LOGFILE"

 exit 1

fi

echo "Created temporary cookie file $COOKIE_FILE" >> "$LOGFILE"

# Output directory and file

OUTPUT_DIR=.

#

# End of user configurable variable

#

# The following command to authenticate uses HTTPS. This will work only if the wget in the environment

# where this script will be executed was compiled with OpenSSL. 

#

 $WGET  --secure-protocol=auto --save-cookies="$COOKIE_FILE" --keep-session-cookies  --http-user "$SSO_USERNAME" --ask-password  "https://updates.oracle.com/Orion/Services/download" -O /dev/null 2>> "$LOGFILE"

# Verify if authentication is successful

if [ $? -ne 0 ]

then

 echo "Authentication failed with the given credentials." | tee -a "$LOGFILE"

 echo "Please check logfile: $LOGFILE for more details."

else

 echo "Authentication is successful. Proceeding with downloads..." >> "$LOGFILE"

 $WGET  --load-cookies="$COOKIE_FILE" "https://updates.oracle.com/Orion/Services/download/p33806152_190000_Linux-x86-64.zip?aru=24713297&patch_file=p33806152_190000_Linux-x86-64.zip" -O "$OUTPUT_DIR/p33806152_190000_Linux-x86-64.zip"   >> "$LOGFILE" 2>&1 

fi

# Cleanup

rm -f "$COOKIE_FILE"

echo "Removed temporary cookie file $COOKIE_FILE" >> "$LOGFILE"

download_1916.sh

#!/bin/sh

#

# Generated 1/11/23 3:23 PM

# Start of user configurable variables

#

LANG=C

export LANG

# Trap to cleanup cookie file in case of unexpected exits.

trap 'rm -f $COOKIE_FILE; exit 1' 1 2 3 6

# SSO username

printf 'SSO UserName:'

read SSO_USERNAME

# Path to wget command

WGET=/usr/bin/wget

# Log directory and file

LOGDIR=.

LOGFILE=$LOGDIR/wgetlog-$(date +%m-%d-%y-%H:%M).log

# Print wget version info

echo "Wget version info:

------------------------------

$($WGET -V)

------------------------------" > "$LOGFILE" 2>&1

# Location of cookie file

COOKIE_FILE=$(mktemp -t wget_sh_XXXXXX) >> "$LOGFILE" 2>&1

if [ $? -ne 0 ] || [ -z "$COOKIE_FILE" ]

then

 echo "Temporary cookie file creation failed. See $LOGFILE for more details." |  tee -a "$LOGFILE"

 exit 1

fi

echo "Created temporary cookie file $COOKIE_FILE" >> "$LOGFILE"

# Output directory and file

OUTPUT_DIR=.

#

# End of user configurable variable

#

# The following command to authenticate uses HTTPS. This will work only if the wget in the environment

# where this script will be executed was compiled with OpenSSL. 

#

 $WGET  --secure-protocol=auto --save-cookies="$COOKIE_FILE" --keep-session-cookies  --http-user "$SSO_USERNAME" --ask-password  "https://updates.oracle.com/Orion/Services/download" -O /dev/null 2>> "$LOGFILE"

# Verify if authentication is successful

if [ $? -ne 0 ]

then

 echo "Authentication failed with the given credentials." | tee -a "$LOGFILE"

 echo "Please check logfile: $LOGFILE for more details."

else

 echo "Authentication is successful. Proceeding with downloads..." >> "$LOGFILE"

 $WGET  --load-cookies="$COOKIE_FILE" "https://updates.oracle.com/Orion/Services/download/p34133642_190000_Linux-x86-64.zip?aru=24865470&patch_file=p34133642_190000_Linux-x86-64.zip" -O "$OUTPUT_DIR/p34133642_190000_Linux-x86-64.zip"   >> "$LOGFILE" 2>&1 

fi

# Cleanup

rm -f "$COOKIE_FILE"

echo "Removed temporary cookie file $COOKIE_FILE" >> "$LOGFILE"

download_917.sh

#!/bin/sh

#

# Generated 1/14/23 3:16 PM

# Start of user configurable variables

#

LANG=C

export LANG

# Trap to cleanup cookie file in case of unexpected exits.

trap 'rm -f $COOKIE_FILE; exit 1' 1 2 3 6

# SSO username

printf 'SSO UserName:'

read SSO_USERNAME

# Path to wget command

WGET=/usr/bin/wget

# Log directory and file

LOGDIR=.

LOGFILE=$LOGDIR/wgetlog-$(date +%m-%d-%y-%H:%M).log

# Print wget version info

echo "Wget version info:

------------------------------

$($WGET -V)

------------------------------" > "$LOGFILE" 2>&1

# Location of cookie file

COOKIE_FILE=$(mktemp -t wget_sh_XXXXXX) >> "$LOGFILE" 2>&1

if [ $? -ne 0 ] || [ -z "$COOKIE_FILE" ]

then

 echo "Temporary cookie file creation failed. See $LOGFILE for more details." |  tee -a "$LOGFILE"

 exit 1

fi

echo "Created temporary cookie file $COOKIE_FILE" >> "$LOGFILE"

# Output directory and file

OUTPUT_DIR=.

#

# End of user configurable variable

#

# The following command to authenticate uses HTTPS. This will work only if the wget in the environment

# where this script will be executed was compiled with OpenSSL. 

#

 $WGET  --secure-protocol=auto --save-cookies="$COOKIE_FILE" --keep-session-cookies  --http-user "$SSO_USERNAME" --ask-password  "https://updates.oracle.com/Orion/Services/download" -O /dev/null 2>> "$LOGFILE"

# Verify if authentication is successful

if [ $? -ne 0 ]

then

 echo "Authentication failed with the given credentials." | tee -a "$LOGFILE"

 echo "Please check logfile: $LOGFILE for more details."

else

 echo "Authentication is successful. Proceeding with downloads..." >> "$LOGFILE"

 $WGET  --load-cookies="$COOKIE_FILE" "https://updates.oracle.com/Orion/Services/download/p34419443_190000_LINUX.zip?aru=24996127&patch_file=p34419443_190000_LINUX.zip" -O "$OUTPUT_DIR/p34419443_190000_LINUX.zip"   >> "$LOGFILE" 2>&1 

fi

# Cleanup

rm -f "$COOKIE_FILE"

echo "Removed temporary cookie file $COOKIE_FILE" >> "$LOGFILE"

Oracle Database: Mantenimiento espacio para el tablespace AUX

 

Aún cuando consideremos triviales y sin importancia, tenemos que continuar brindando mantenimiento a algunas estructuras de la base de datos.

En ambiente de base de datos como servicio en el OCI, he observado que el tablespace SYSAUX aumenta considerablemente de tamaño, provocado en gran medida por las tablas de seguimiento de colas de trabajos (Jobs).

Veamos como podemos recuperar espacio del tablespace SYSAUX, purgando los históricos de los registros de estas tablas.

login as: opc

Authenticating with public key "rsa-key-20200507"

Passphrase for key "rsa-key-20200507":

Last login: Fri Dec 30 15:00:23 2022 from 10.100.128.176

[opc@serverdb_01_uat ~]$ sudo su - oracle

Last login: Fri Dec 30 15:00:26 CST 2022 on pts/2

Primero que todo vamos conectarnos a una base de datos acomplada de mi contenedor. 

SQL> connect / as sysdba

Connected.

SQL> alter session set container=***************;

Utilizando un script casero, valido la ocupación de cada uno de mis tablespaces. 

SQL> @espacio

Tablespace Name             KBytes         Used         Free   Used      Largest

--------------------- ------------ ------------ ------------ ------ ------------

FCUBSLIVE               42,053,616   21,048,944   21,004,672   50.1    4,063,232

FCUBSPILOT              18,874,368       20,224   18,854,144     .1    4,063,232

UNDOTBS1                 5,268,480      846,976    4,421,504   16.1    2,001,920

USERS                    3,408,640      746,944    2,661,696   21.9    1,870,592

SYSAUX                  11,315,200   10,772,416      542,784   95.2      515,072

TBS_AUDIT_FGA_DATA         409,600        5,184      404,416    1.3      101,376

OAS_IAS_UMS                102,400        8,320       94,080    8.1       94,080

OAS_MDS                    102,400        9,216       93,184    9.0       93,184

TBS_DATA_ETL               614,400      547,840       66,560   89.2       66,560

OAS_IAU                     61,440        1,152       60,288    1.9       60,288

OAS_WLS                     61,440        1,280       60,160    2.1       60,160

OAS_BIPLATFORM             196,608      156,864       39,744   79.8       39,744

OAS_STB                     10,240        1,920        8,320   18.8        8,320

OAS_IAS_OPSS                63,488       56,832        6,656   89.5        6,656

SYSTEM                   8,284,160    8,278,400        5,760   99.9        3,072

                      ------------ ------------ ------------

sum                     90,826,480   42,502,512   48,323,968

15 rows selected.

Como observan, el tablespace de SYSAUX, tiene un poco más de 10GB de almacenamiento ocupado.

Voy a utilizar otro script casero, para ver cuál es el top de los objetos en dicho tablespaces. 

SQL> host ls -la *rank*

-rw-r--r--. 1 oracle oinstall 445 Aug 11 15:51 ranking20_tabla.sql

-rw-r--r--. 1 oracle oinstall 447 Aug 11 15:51 ranking_index.sql

-rw-r--r--. 1 oracle oinstall 506 Aug 11 15:51 ranking_index_sys.sql

-rw-r--r--. 1 oracle oinstall 467 Aug 11 15:51 ranking_schema_index.sql

-rw-r--r--. 1 oracle oinstall 498 Aug 11 15:51 ranking_schema.sql

-rw-r--r--. 1 oracle oinstall 446 Aug 11 15:51 ranking_tabla.sql

-rw-r--r--. 1 oracle oinstall 480 Aug 11 15:51 ranking_tablespace.sql

-rw-r--r--. 1 oracle oinstall 295 Aug 11 15:51 tablas_ranking.sql

SQL> @ranking_tablespace.sql

Enter value for tablespace: SYSAUX

old   3: from dba_segments where segment_type='TABLE' and tablespace_name='&TABLESPACE')

new   3: from dba_segments where segment_type='TABLE' and tablespace_name='SYSAUX')

             Ranking Tablas grandes en la base de datos

OWNER       SEGMENT_NAME                         MBYTES    RANKING

----------- ------------------------------- ----------- ----------

SYS         SCHEDULER$_JOB_RUN_DETAILS         2,615.00          1

SYS         SCHEDULER$_EVENT_LOG               1,408.00          2

SYS         SCHEDULER$_JOB_OUTPUT              1,280.00          3

SYS         PLSCOPE_ACTION$                       10.00          4

MDSYS       SDO_CS_SRS                             9.00          5

SYS         WRI$_OPTSTAT_OPR_TASKS                 5.00          6

SYS         AQ$_KUPC$DATAPUMP_QUETAB_1_P           4.00          7

SYS         EXP_HEAD$                              3.00          8

SYS         STATS_TARGET$                          3.00          9

SYS         PLSCOPE_IDENTIFIER$                    2.00         10

Como observan en el reporte, tenemos 3 objetos bastantes grandes para ser unas simples tablas de registro de colas de procesos.

El siguiente es el procedimiento para limpiar los registros de dichas tablas.

SQL> SCHEDULER$_JOB_RUN_DETAILSexec dbms_scheduler.purge_log(0, 'JOB_AND_WINDOW_LOG');^C

SQL> exec dbms_scheduler.purge_log(0, 'JOB_AND_WINDOW_LOG');

PL/SQL procedure successfully completed.

Una vez ejecutado el proceso, no se sientan defraudados si vuelven a consultar las tablas y el espacio aún no ha sido liberado.

SQL> @ranking_tablespace.sql

Enter value for tablespace: SYSAUX

old   3: from dba_segments where segment_type='TABLE' and tablespace_name='&TABLESPACE')

new   3: from dba_segments where segment_type='TABLE' and tablespace_name='SYSAUX')

              Ranking Tablas grandes en la base de datos

OWNER        SEGMENT_NAME                         MBYTES    RANKING

------------ ------------------------------- ----------- ----------

SYS          SCHEDULER$_JOB_RUN_DETAILS         2,615.00          1

SYS          SCHEDULER$_EVENT_LOG               1,408.00          2

SYS          SCHEDULER$_JOB_OUTPUT              1,280.00          3

SYS          PLSCOPE_ACTION$                       10.00          4

MDSYS        SDO_CS_SRS                             9.00          5

SYS          WRI$_OPTSTAT_OPR_TASKS                 5.00          6

SYS          AQ$_KUPC$DATAPUMP_QUETAB_1_P           4.00          7

SYS          EXP_HEAD$                              3.00          8

SYS          STATS_TARGET$                          3.00          9

SYS          PLSCOPE_IDENTIFIER$                    2.00         10

10 rows selected.

Es necesario que ahora hagamos un "TRUNCATE" sobre las siguientes tablas para liberar el espacio.

SQL> truncate table scheduler$_job_output;

Table truncated.

Volvemos a validar el top de uso de espacio en el tablespace y ahora si ya hemos logrado recuperar parte de la ocupación que tenían estos objetos.

SQL> @ranking_tablespace.sql

Enter value for tablespace: SYSAUX

old   3: from dba_segments where segment_type='TABLE' and tablespace_name='&TABLESPACE')

new   3: from dba_segments where segment_type='TABLE' and tablespace_name='SYSAUX')

         Ranking Tablas grandes en la base de datos

OWNER    SEGMENT_NAME                               MBYTES    RANKING

-------- --------------------------------- --------------- ----------

SYS      SCHEDULER$_JOB_RUN_DETAILS               2,615.00          1

SYS      SCHEDULER$_EVENT_LOG                     1,408.00          2

SYS      PLSCOPE_ACTION$                             10.00          3

MDSYS    SDO_CS_SRS                                   9.00          4

SYS      WRI$_OPTSTAT_OPR_TASKS                       5.00          5

SYS      AQ$_KUPC$DATAPUMP_QUETAB_1_P                 4.00          6

SYS      EXP_HEAD$                                    3.00          7

SYS      STATS_TARGET$                                3.00          8

SYS      PLSCOPE_IDENTIFIER$                          2.00          9

SYS      WRI$_OPTSTAT_IND_HISTORY                     2.00         10

Ahora vamos con las siguientes tablas. Hay un objeto de la base de datos, que guarda estadisticas históricas. Si llegaste a esta publicación, quizás ya antes haz visto publicaciones en juniororacledba.wordpress.com y muchos otros más, en donde sus autores, tratan la misma bronca. El espacio de más utilizado en el tablespace SYSAUX y el incremento en el tamaño del Datapump de tu base de datos.

Es posible disminuir el tamaño de información retenida, aplicando el siguiente procedimiento. Primero puedes obtener, la fecha de referencia desde cuando tienens estadísticas acumuladas en la base de datos.

SQL> select dbms_stats.get_stats_history_availability from dual;

GET_STATS_HISTORY_AVAILABILITY

---------------------------------------------------------------------------

29-NOV-22 10.46.00.871479000 AM -06:00

Bien ahora, puedes con el siguiente procedimiento, borrar las estadísticas acumuladas de los días 11 al 30 de antiguedad, con el siguiente bloque anónimo.

SQL> begin

for i in reverse 10..30

loop

dbms_stats.purge_stats(sysdate-i);

end loop;

end;

/

PL/SQL procedure successfully completed.

Verificas nuevamente la fecha de historial y ya puedes darte cuenta que la fecha ha avanzado hasta los últimos 10 días.

SQL> select dbms_stats.get_stats_history_availability from dual;

GET_STATS_HISTORY_AVAILABILITY

---------------------------------------------------------------------------

20-DEC-22 05.25.19.000000000 PM -06:00

Seguimos revisando los objetos con espacio en el tablespace de SYSAUX y ahora toca las tablas de SCHEDULER.

SQL> @ranking_tablespace.sql

Enter value for tablespace: SYSAUX

old   3: from dba_segments where segment_type='TABLE' and tablespace_name='&TABLESPACE')

new   3: from dba_segments where segment_type='TABLE' and tablespace_name='SYSAUX')

Fri Dec 30                                           page    1

       Ranking Tablas grandes en la base de datos

OWNER      SEGMENT_NAME                      MBYTES    RANKING

---------- ---------------------------------------- ----------

SYS        SCHEDULER$_JOB_RUN_DETAILS      2,615.00          1

SYS        SCHEDULER$_EVENT_LOG            1,408.00          2

SYS        PLSCOPE_ACTION$                    10.00          3

MDSYS      SDO_CS_SRS                          9.00          4

SYS        WRI$_OPTSTAT_OPR_TASKS              5.00          5

SYS        AQ$_KUPC$DATAPUMP_QUETAB_1_P        4.00          6

SYS        EXP_HEAD$                           3.00          7

SYS        STATS_TARGET$                       3.00          8

SYS        PLSCOPE_IDENTIFIER$                 2.00          9

SYS        WRI$_OPTSTAT_IND_HISTORY            2.00         10

************************************************************************

10 rows selected.

Para limpiar estas tablas, vamos a ejecutar el siguiente procedimiento y luego procedemos a TRUNCAR las tablas respectivas.

SQL> exec DBMS_SCHEDULER.PURGE_LOG();

PL/SQL procedure successfully completed.

SQL> truncate table sys.scheduler$_job_run_details;

Table truncated.

SQL> truncate table sys.SCHEDULER$_EVENT_LOG;

Table truncated.

Volvemos a validar y ahora sí, hemos recuperado cerca de 10GB de espacio con estos simples pasos.

SQL> @ranking_tablespace.sql

Enter value for tablespace: SYSAUX

old   3: from dba_segments where segment_type='TABLE' and tablespace_name='&TABLESPACE')

new   3: from dba_segments where segment_type='TABLE' and tablespace_name='SYSAUX')

          Ranking Tablas grandes en la base de datos

OWNER      SEGMENT_NAME                           MBYTES    RANKING

---------- ----------------------------------- --------- ----------

SYS        PLSCOPE_ACTION$                         10.00          1

MDSYS      SDO_CS_SRS                               9.00          2

SYS        WRI$_OPTSTAT_OPR_TASKS                   5.00          3

SYS        AQ$_KUPC$DATAPUMP_QUETAB_1_P             4.00          4

SYS        EXP_HEAD$                                3.00          5

SYS        STATS_TARGET$                            3.00          6

SYS        PLSCOPE_IDENTIFIER$                      2.00          7

MDSYS      EXT_TAB_REF_SYS_1                        2.00          8

XDB        XDB$ELEMENT                              2.00          9

SYS        WRI$_OPTSTAT_IND_HISTORY                 2.00         10

10 rows selected.

SQL>

Adjuntos 

ranking_tablespace.sql

col segment_name format a60

col owner format a20

set pagesize 20

col MBytes format 999,999,999.00

Ttitle ' Ranking Tablas grandes en la base de datos'

Btitle "************************************************************************"

set linesize 120

select * from

( select owner, segment_name, bytes/1024/1024 MBytes,row_number() over (order by bytes desc nulls last) ranking

from dba_segments where segment_type='TABLE' and tablespace_name='&TABLESPACE')

 where ranking <= 10

espacio.sql

column dummy noprint

set linesize 200

column pct_used format 999.9 heading "%|Used"

column name format a40 heading "Tablespace Name"

column Kbytes format 999,999,999 heading "KBytes"

column used format 999,999,999 heading "Used"

column free format 999,999,999 heading "Free"

column largest format 999,999,999 heading "Largest"

break on report

compute sum of kbytes on report

compute sum of free on report

compute sum of used on report

select nvl(b.tablespace_name,

nvl(a.tablespace_name,'UNKOWN')) name,

kbytes_alloc kbytes,

kbytes_alloc-nvl(kbytes_free,0) used,

nvl(kbytes_free,0) free,

((kbytes_alloc-nvl(kbytes_free,0))/

kbytes_alloc)*100 pct_used,

nvl(largest,0) largest

from ( select sum(bytes)/1024 Kbytes_free,

max(bytes)/1024 largest,

tablespace_name

from sys.dba_free_space

group by tablespace_name ) a,

( select sum(bytes)/1024 Kbytes_alloc,

tablespace_name

from sys.dba_data_files

group by tablespace_name )b

where a.tablespace_name (+) = b.tablespace_name

order by free desc,a.tablespace_name

/

/