Archivo de la categoría: 12c

Actualizar bases de datos antiguas antes de Junio de 2019

Posted on por
Responder

Hoy vamos a ver una entrada de la que no me puedo atribuir ningun merito, ya que , practiccamente es una traduccion + recopilacion de las URL’s en ingles que os adjunto al final como documentacion adicional.

Tal y como indica Mike Dietrich DEBEMOS parchear las bases de datos que tengamos en version 12.1.0.1, 11.2.0.3 y anteriores antes del 23 de Junio de 2019 .

¿Por que ?

En la nota de oracle MOS Note: 2335265.1 nos explican que, estas versiones de bases de datos están afectadas por un especie de Efecto 2000 en la manera en la que la base de datos calcula el SCN.
Un problema que incrementa la criticada del parcheado es que, este bug afecta a los DBlinks , por lo que no solamente puede causar problemas en nuestras bases de de datos afectadas, sino que, si esta esta conectada a una nueva aunque no este afectada provocara que nuestra obtención de datos falle.

Como indicaba al principio, podemos encontrar este caso muy bien explicado en el blog de Job Oprel, pero, en cualquier caso , es muy conveniente el llevar a cabo la comprobación de hasta que punto estamos afectados en todas las bases de datos que tengamos dentro de las versiones mencionadas.

La consulta a ejecutar es 

set pagesize 200;
set linesize 200;
column  OWNER format a30;
column  USERNAME format a30;
column DB_LINK format a20;
col HOST format a40;
col created format a20;

select * from DBA_DB_LINKS;

SELECT NAME,  
   (current_scn/281474976710656)*100 as PCT_OF_SCN_KEYSPACE_USED,  
   ROUND(SYSDATE-CREATED) as DAYS_SINCE_DB_CREATION, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)) 
        AS EST_DAYS_BEFORE_SCN_EXHAUSTED, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)/365) 
        AS EST_YEARS_BEFORE_SCN_EXHAUSTED  
FROM v$database;

La fuente de esta informacion donde se pude ver el analisis completo es

Configurar el CRS de la 12.2 sin tener ASM

Posted on por
Responder

Hoy vamos a ver una entrada sencilla que puede habernos traido dolores de cabeza.

Con los nuevos cambios en la instalacion en la version 12.2 al instalar el crs ( que no deja de ser un «unzip») nos encontramos que el binario crsctl no esta lincado.

Cuando intentamos usar el configuratdor del CRS ($GI_HOME/gridSetup.sh ), nos encontramos que nos exige el ASM para poder continuar, asi que
¿Como podemos configurar nuestro CRS sin ASM ?
La solucion es muy sencilla, y pasa por ejecutar el comando roothas.pl
Como usuario root ejecutaremos 

export GI_HOME=/u01/app/oracle/product/12.2.0.1/grid
 $GI_HOME/perl/bin/perl -I $GI_HOME/perl/lib -I $GI_HOME/crs/install
 $GI_HOME/crs/install/roothas.pl

Con esto conseguiremos el ultimo proceso de lincado , que es el que crea los binarios crscrl y la configuracion de nuestro grid a nivel de sistema operativo.

Hemos de tener en cuenta que , este proceso no crea el listener, asi que, como usuario oracle y con las variables de entorno del grid cargado deberemos de ejecutar despues 

srvctl add listener -oraclehome $ORACLE_HOME -listener LISTENER

comma separated alias in tnsnames.ora

Posted on por
Responder

Today we are gonna see a easy way to maintain clear the tnsnames.ora

Lets see our file:

PROD=
  (DESCRIPTION=
     (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1521))
     (CONNECT_DATA=
        (SERVICE_NAME=factura)
     )
  )
PRODUCCION=
  (DESCRIPTION=
     (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1521))
     (CONNECT_DATA=
        (SERVICE_NAME=factura)
     )
  )
FACTURACION=
  (DESCRIPTION=
     (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1521))
     (CONNECT_DATA=
        (SERVICE_NAME=factura)
     )
  )

As you can see, we have three identical entries for the same database. This makes our file bigger and more difficult to maintain.
How can we solve it?
Easy, You can specify multiple net_service_name separated by command in a single entry.

This will be :

PROD,PRODUCCION,FACTURACION=
  (DESCRIPTION=
     (ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1521))
     (CONNECT_DATA=
        (SERVICE_NAME=factura)
     )
  )

As you can see, easy and clear

ORA-29279 Errors using UTL_SMTP

Posted on por
Responder

One of the most common error using Fine Grained Acess and UTL_SMTP is the ORA-2927SMTP permanent error
This aren’t databae errors, this error are a generic authentication issue with the configuration of the SMTP server and fortunately, Oracle has a solution about it.


Contact your SMTP administrator for additional assistance as this solution may require your e-mail administrator to make the necessary changes.

More information :

  • ORA-29279 SMTP: 554 Using Utl_smtp To Send Email (Doc)
  • Document 604763.1 – Check SMTP Server Availability for ORA-29278 or ORA-29279 errors using UTL_SMTP to Send Email
  • ORA-2427 con el paquete SMTP