Archivo de la categoría: dummie

entradas searadas por comas en el tnsnames.ora

Posted on por
Responder

Hoy vamos a ver una funcionalidad sencillísima del tnsnames.ora, pero que nos permitirá tener nuestros ficheros mucho mas reducidos y ordenados.
Supongamos tenemos un fichero con las entradas:

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)
     )
  )

Como veis, tenemos 3 entradas totalmente idénticas que nos aumentan el fichero y puede dar a errores en el momento de cambiarlos.
Pues, hay una forma de simplificar mucho esto, y esta forma es ponerlos en una única entrada separada por comas

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

Haciendo pruebas esto funciona (amenos desde las versiones 9i hasta la 12c) .
Una configuración muy sencilla que nos facilita mucho el mantenimiento del fichero

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)

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

Detectar trabajos suspendidos

Posted on por
Responder

Vamso a ver una entrada rápida y sencilla.

¿Como sabemos cuando y por que se nos ah quedado parado un impdp?

La respuesta es muy sencilla, y es chequeando la table DBA_RESUMABLE


SELECT NAME,STATUS, TIMEOUT, ERROR_NUMBER, ERROR_MSG FROM DBA_RESUMABLE;

Esto nos dará una salida del estilo :

NAME                                STATUS            TIMEOUT, ERROR_NUMBER, ERROR_MSG
SYSTEM.IMPORT_REGENERACION2	NORMAL	       7200	0
SYSTEM.IMPORT_REGENERACION2.1	SUSPENDED	7200	1652	ORA-01652:      no se ha podido ampliar el segmento temporal con 1024 en el tablespace USERS

Donde podemos ver claramente que estamos parados por un ORA-01652 por culpa de espacio en un tabelspace

Errores Private strand flush not complete en el alert.log

Posted on por
Responder

Vamos a echar un vistazo rápido a un error bastante común en los alert.log

Una alerta bastante común que vemos en los alertlog es 

Thread 1 cannot allocate new log, sequence 6180
Private strand flush not complete

Esta línea nos indica que, no hemos completado la operación de guardar todo el REDO cuando hacemos el switch.
El término strand es la palabra que utiliza Oracle para referrse a los latches de los redo log, lo que tenemos en este caso es un caso de este tipo, y lo que nos está indicando es qeu en ved de bajar el redo en tiempo real, lo «bajará» con el commit.

Este tipo de mensajes no es alarmante a no ser que haya mas mensajes del tipo «cannot allocate new log» o «advanced to log sequence»

En cualquier caso, pueden indicarnos que hay problemas con la velocidad de IO del almacenamiento donde se encuentran o en caso de ser logs remotos con la red