Archivo de la categoría: 12c

Cambios en el passwd file en la 12c

Posted on por
Responder

Hoy vamos a ver algunos cambios sobre el fichero de contraseñas en la nueva versión 12c

Cifrado ( ORA-28017 )

Uno de los cambios que ha llevado a cabo Oracle en la versión 12c es el de haber mejorado los hashes del cifrado de sus contraseñas usando un algoritmo SHA512 basado en PBKDF2 para generar los hases en ved del SHA1 que utilizaba antes.
Este cambio no nos afecta solamente a las estructuras de almacenamiento interno de la base de datos, sino que provoca que el fichero en el que se almacenan las contraseñas en el disco (passwd file) tenga una estructura distinta, pasándose a llamar el fichero antiguo como «LEGACY».
Si intentamos cambiar una contraseña de uno de los usuarios de sistema (sys) y el fichero de passwd es «antiguo» tendremos el error

ORA-28017: El archivo de contrase±as estß en el formato heredado.

Cuyo equivalente en inglés es

ORA-28017:The password file is in the legacy format.

Para comprobar el tipo de fichero de passwd que tenemos Oracle nos ofrece la funcionalidad del orapasswd que es «describe»

orapwd describe file=SPFILEDESA.ora
Password file Description : format=LEGACY ignorecase=N

Para solucionar este problema simplemente tenemos que borrarlo y crearlo de nuevo, o bien regenerarlo con el nuevo orapasswd o bien recrearlo con el comando 

orapwd file=< fname > entries=< users>  force=< y/n> password=< SYS password> force=y format=12 input_file=< input-fname>

Depreciación de IGNORECASE

Otro de los puntos importantes de la 12c es que se ha quitado la línea de compatibilidad con las versiones 10g y anteriores en lo que a passwords se refiere.
Si recordamos la entrada Contraseñas case sensitive y Oracle 11g había un parámetro que permitía esa compatibilidad, en esta nueva versión 12c esa opción ha sido eliminada.

Ubicación del fichero en ASM

En la versión 12c ya es posible tener el fichero de password dentro del ASM.

Nuevos usuarios en el fichero de passwd

Con la segregación de funciones introducida por Oracle en la 12c tenemos nuevos usuarios/roles pare segregar algunas funciones como backup,dataguard o TDE (Transparent Data Encryption)

Estos usuarios son:

  • SYS
  • SYSBACKUP Es el usuario que se usará para llevar a cabo las operaciones de backup/recovery bien sea desde rman o sqlplus.
  • SYSDG Creado para separar las actividades relaccionadas con dataGuard
  • SYSKM Creado para las acciones administrativas de Transparent Data Encryptiony Data Vault

Como siempre, tenemos mas información en la web de soporte oracle

  • ORA-28017: The password file is in the legacy format (Doc ID 2112456.1)
  • Depreciación de IGNORECASE and SEC_CASE_SENSITIVE http://docs.oracle.com/cd/E16655_01/server.121/e17642/deprecated.htm#UPGRD60022
  • Depreaciación de IGNORECASE en ORAPWD ://docs.oracle.com/cd/E16655_01/network.121/e17607/release_changes.htm#DBSEG420

ORA-28221 REPLACE not specified cambiando la passwd de un usuario

Posted on por
Responder

Hoy vamos a ver una entrada muy muy básica.

En nuestro trabajo diario estamos acostumbrados a poder cambiar las contraseñas con el comando

ALTER USER usuario IDENTIFIED BY contraseña

Si le pedimos a un usuario que se cambie su contraseña, podemos encontrarnos con el error 

 ORA-28221 REPLACE not specified

Que ha ocurrido?

La solucion es muy muy sencilla, simplemente ha de indicar cual es el password actual.
El código que debe de ejecutar un usuario para cambiar su contraseña es

ALTER USER usuario IDENTIFIED BY nuevacontraseña REPLACE antigua_contraseña ;

Como decíamos al principio , tremendamente sencillo, pero puede hacernos perder tiempo si no lo sabemos

Como siempre, mas informacion en la web de soporte en la noca OERR: ORA-28221 «REPLACE not specified» Reference Note (Doc ID 194726.1)

ORA-28040: No matching authentication protocol al subir a 12c

Posted on por
Responder

Hoy vamos a ver un error que podemos tener con determinadas conexiones JDBC desde clientes 10g.

El principal problema es que el cliente de JDBC thin de la 10g usa el protocolo de autenticación SHA-1, este protocolo no está permitido en la 12c, por lo que da el error.

ORA-28040: No matching authentication protocol

La solución debería de ser el uso de clientes 12c, ya que, hemos de tener en cuenta que JDBC 10.1 drivers no están certificados con bases de datos 12c

Existe un workarround para salir del paso, y es el configurar en el SQLNET.ORA del servidor el parámetro.

 SQLNET.ALLOWED_LOGON_VERSION_SERVER=10
 SQLNET.ALLOWED_LOGON_VERSION_CLIENT=10

De esta manera conseguiremos que clientes antiguos funcionen, pero no debemos de perder de vista que esto solo debe de ser un workarround y la suma importancia de mantener todos los componentes de la base de datos certificados.

Aunque la manera correcta de solucionarlo es desde el cliente


The solution is to take out the "-Doracle.jdbc.thinLogonCapability=o3" java parameter from the application execution.
For example, if the next java command was used to execute the application:
java -Doracle.jdbc.thinLogonCapability=o3 -cp .:ojdbc8.jar Application
Then, it is necessary to take the "-Doracle.jdbc.thinLogonCapability=o3" parameter off from the command as follows:
java -cp .:ojdbc8.jar Application

Más información como siempre en metalink en :

  • «ORA-28040: No Matching Authentication Protocol» After Database Upgrade To 19c (Doc ID 2748273.1)
  • Client / Server Interoperability Support Matrix for Different Oracle Versions (Doc ID 207303.1)
  • 12c Database Alert.log File Shows The Message: Using Deprecated SQLNET.ALLOWED_LOGON_VERSION Parameter (Doc ID 2111876.1)
  • 11g and Older: How To Use the Parameter SQLNET.ALLOWED_LOGON_VERSION Correctly (Doc ID 1304142.1)
  • 11g and Older: How To Use the Parameter SQLNET.ALLOWED_LOGON_VERSION Correctly (Doc ID 1304142.1)
  • Error «ORA-28040: No matching authentication protocol» When Using SQLNET.ALLOWED_LOGON_VERSION (Doc ID 755605.1)

Rman DUPLICATE en 12c y Windows

Posted on por
Responder

Hoy vamos a ver una sencilla entrada en la que indicaremos como duplicar una base de datos en windows mediante RMAN DUPLICATE.
Este método está muy documentado en un montón de webs, pero , en entornos windows suele tener la pega ( como todo lo de Oracle+Windows) del servicio de windows.

Supongamos que tenemos una base de datos llanada PROD y que queremos clonarla para su uso en desarrollo en otra llamada DESA.
Además de esto, queremos modificar el path de los ficheros de la base de datos, ya que,en la máquina de desarrollo queremos que todo lo que esté en D: y E: pase a estar en Z:

Así pues, los pasos serán:

1- Creamos el init.ora de la instancia a partir de la clonada

Aunque hay documentos que te explican como crear un init mínimo, lo mejor y mas cómodo segun mi opinion es crear un sencillo pfile en texto dsde el spfile del origen

create pfile='initDESA.ora' from spfile;

2- Editamos el initSID.ora y cambiamos TARGET por SID en todas las lineas

Abriremos con cualquier editor el fichero que acabamos de generar y substituiremos la cadena PROD por DESA

3- Creamos el fichero de passwd

Tendremos que ir al $ORACLE_HOME/database crear nuestro fichero de password.

orapwd file=PWDDESA.ora password=mipasswd entries=6 force=y

4- Cramos el servicio de windows

Este es el paso que podemos evitarnos en unix, pero que es inevitable en windows

oradim -NEW -SID DESA -SYSPWD mipasswd -SRVC OracleServiceDESA -STARTMODE auto -SRVCSTART system -SPFILE

5- paramos y arrancamos en modo nomount

El proceso de creacion de servicio habrá arrancado la base de datos , pro lo que tendremos que entrar , pararla y dejarla arrancada en modo nomount.

6- añadimos las líneas de cambio de path en el nuevo INIT.ora

Este es el punto mas extraño ya que, las opciones de cambio de nombre del path del fichero no están en el fichero de comandos de rman, sino en el init.ora de la nueva base de datos.

Con estos comandos movemos tanto los logfiles como los datafiles normales a su nuevo path


LOG_FILE_NAME_CONVERT =('D:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA','E:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA')
DB_FILE_NAME_CONVERT = ('D:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA','E:\oracle\ORADATA\PROD','Z:\oracle\ORADATA\DESA')

7- Creamos el fichero de comandos rman


connect target sys/XXXX.@PROD;
connect catalog user/pass@CATALOG;
connect auxiliary /

CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE';
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 4;
CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE parms 'ENV=(NSR_SERVER=backupserver, NSR_DATA_VOLUME_POOL=pollduplicados)';

RUN{
DUPLICATE TARGET DATABASE TO "DESA" ;

}

8-Lanzamos el duplicado

Ahora solamente queda lanzar el rman


rman cmdfile=comandos.crv logfile=duplicacion.log

Y un un tiempo record tendréis duplicada vuestra base de datos PROD renombrada a DESA y en el nuevo path Z:\oracle\ORADATA\DESA

Errores ORA-16179 al intentar cambiar el LOG_ARCHIVE_DEST_1

Posted on por
Responder

Hoy vamos a ver una entrada tan absurda que roza casi lo idiota.

Supongamos que queramos modificar o añadir el destino de nuestros archivers,e intentándolo tenemos el error ORA-16179

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION = D:\oracle\FRA\QA';
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'LOCATION = D:\oracle\FRA\QA''
ERROR en lφnea 1:
ORA-32017: fallo al actualizar SPFILE
ORA-16179: cambios incrementales en "log_archive_dest_1" no permitidos con SPFILE

La primera accion a temar en cuenta, es buscar blancos en el entrecomillado

Una vez eliminados los blancos, funcionará correctamente 🙂

Pueden haber otros problemas que den este ORA-, todos ellos mas serios que el de esta entrada, su solucion la podéis busar en:

  • Soporte en la Nota OERR: ORA-16179 «incremental changes to %s not allowed with SPFILE» Reference Note (Doc ID 194494.1)
  • Blog de Juan Andres Mercado