ADRCI: Limpieza de directorios de diagnóstico

E-mail Imprimir PDF

En versiones anteriores a la 11g, los archivos de traza que solíamos encontrar directorios udump,cdump,dbdump había que borrarlos a mano. En Oracle 11g se puede seguir haciendo esta limpieza a mano aunque es mejor realizarla con la herramienta que nos proporciona ADRCI

Repasamos alguna de las características de esta nueva estructura de diagnóstico que nos presenta oracle con la versión 11g:

  • Los archivos de traza por defecto los encontramos ahora en $ORACLE_BASE/diag
  • Sigue existiendo un alert.log que registra los errores de base de datos.
  • Los archivos de alerta ahora tienen formato xml
Ejemplo:
$ORACLE_BASE/diag/rdbms/orcl/orcl/alert/log.xml
  • Tenemos la herramienta adrci con la que podemos ver y gestionar estos archivos
Ejemplo
adrci> show alert -tail

Uno de los problemas que siempre se nos plantea es el mantenimiento de los logs es por ello por lo que nos vamos a centrar en la opción PURGE de ADRCI

Con el usuario oracle de nuestra máquina tecleamos el comando adrci

[ora11g@prueba ~]$ adrci
ADRCI: Release 11.2.0.1.0 - Production on Mon Apr 7 10:54:51 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
ADR base = "/oracle11g"
adrci> 

La opción purge sería la que usaríamos para realizar esta limpieza. Para ver las opciones que nos ofrece purge, escribimos en la línea de comandos adrci help purge

adrci> help purge                
  Usage: PURGE [[-i <id1> | <id1> <id2>] | 
               [-age <mins> [-type ALERT|INCIDENT|TRACE|CDUMP|HM|UTSCDMP]]]: 
  Purpose: Purge the diagnostic data in the current ADR home. If no
           option is specified, the default purging policy will be used.
  Options:
    [-i id1 | id1 id2]: Users can input a single incident ID, or a 
    range of incidents to purge.
    [-age <mins>]: Users can specify the purging policy either to all
    the diagnostic data or the specified type. The data older than <mins>
    ago will be purged
    [-type ALERT|INCIDENT|TRACE|CDUMP|HM|UTSCDMP]: Users can specify what type of 

   data to be purged.
  Examples:  
    purge 
    purge -i 123 456
    purge -age 60 -type incident

Antes de lanzar el comando purge, tenemos que especificar el home en el cual tenemos nuestras trazas sobre todo si en nuestra máquina tenemos más de un home

Cuando escribimos el comando adrci nos muestra nuestro ADR base. Tenemos que establecer la ruta donde se encuentran nuestros directorios de traza. Esto lo hacemos con un set home

[ora11g@sella ~]$ adrci
ADRCI: Release 11.2.0.1.0 - Production on Mon Apr 7 11:02:00 2014
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
ADR base = "/oracle11g"
adrci> set home diag/rdbms/dba11g/dba11g/               
adrci>

Como vemos, establecemos la ruta a partir de la base que ya la tenemos seteada

una vez establecido nuestro ADR home, entonces podremos lanzar el comando purge.

Mostramos algunos ejemplos para limpiar las trazas

Para limpiar todos los ficheros de trazas más antiguos a un día (1440 minutos)

adrci> purge -age 1440

Nota:incluye los core files: cdmp*

Limpieza de core files mayores a 6 días

  adrci> purge -age 8640 -type CDUMP

Puede que para limpiar completamente sea necesario lanzar el siguiente comando

adrci> purge -age 8640 -type UTSCDMP

Para limpiar las alertas  (ficheros xml) más antiguos que una hora

adrci> purge -age 60 -type ALERT
Última actualización el Lunes, 07 de Abril de 2014 13:39
 

ORA-32018: parameter cannot be modified in memory on another instance

E-mail Imprimir PDF

 

Al intentar realizar un alter system en una de mis instancias de base de datos obtenemos el siguiente error:

SQL> alter system set streams_pool_size=48m;
ERROR at line 1:
ORA-32018: parameter cannot be modified in memory on another instance

Lo que nos indica este error es que estamos en una instancia de una base de datos RAC y para que pueda realizarse con éxito habrá que indicarle en cual de las instancias queremos modificar ese parámetro.

Esto lo podemos hacer añadiendo a la sentencia la claúsula SID

Por ejemplo, si nuestra base de datos se llama prueba y tenemos dos instancias (prueba1 y prueba2), tendremos que hacer el cambio de la siguiente forma:

En la instancia1 lanzamos la siguiente sentencia

SQL> alter system set streams_pool_size=48m sid='prueba1';
System altered.

En la instancia2 lanzamos la siguiente sentencia

SQL> alter system set streams_pool_size=48m sid='prueba2';
System altered.
 

Guía de optimización de SQL para Oracle

E-mail Imprimir PDF

Hoy os traemos la reseña de un libro que consideramos que todos los desarrolladores o DBA que usen Oracle deberían tener.

Es una completa, sencilla y práctica guía para optimizar tu código SQL. Todo el código de los ejemplos del libro pueden descargarse gratuitamente en http://www.optimizacionsqlenoracle.com

Domina el Bind Variable Peeking, analiza el plan de ejecución, el uso de índices, vistas materializadas, particiones, paralelismo, SQL PRofiles, DBMS_STATS, DBMS_SPM, hints SQL. Son trucos que optimizarán tus consultas y mejorarán el rendimiento general de tu base de datos Oracle en todas sus versiones (10g, 11g, 12c, ...).

Tiene una lectura muy ligera y didáctica por lo que se lee muy fácil. A su vez es muy potente y práctico.

Sólo por el diccionario de hints que trae merece la pena. Por menos de 40€ nos parece una buena compra.

 

Optimización SQL en Oracle: Una guía práctica, detallada y completa sobre cómo implementar y explotar bases de datos Oracle de forma eficiente

 

Tablespace UNDOTB - Reducir tamaño

E-mail Imprimir PDF
En ocasiones, vemos que el tablespace UNDOTB ha crecido mucho y lo queremos hacer más pequeño para reclamar ese espacio.
La forma más sencilla de hacerlo es borrándolo y creándolo de nuevo.Para ver qué tablespace UNDO estamos usando en nuestra base de datos y cuánto ocupa, podemos realizar la siguiente consulta:
SQL> SELECT file_name, tablespace_name, bytes/1024/1024 UNDO_SIZE_MB, SUM(bytes/1024/1024) OVER() TOTAL_UNDO_SIZE_MB
FROM dba_data_files d WHERE EXISTS
(SELECT 1 FROM v$parameter p WHERE LOWER (p.name)='undo_tablespace' AND p.value=d.tablespace_name);
FILE_NAME                      TABLESPACE_NAME UNDO_SIZE_MB       TOTAL_UNDO_SIZE_MB
------------------------------ --------------- ------------ ------------------
/database/dba11g/undotbs01.dbf UNDOTBS1 600 600
Antes de borrar el tablespace UNDO, deberemos crear el nuevo. La forma de crearlo es la siguiente:
CREATE UNDO TABLESPACE undotbs2 DATAFILE '/database/dba11g/undotbs02.dbf' SIZE 300M AUTOEXTEND ON NEXT 1M;
En este caso hemos creado un nuevo tablespace de 300M
Una vez creado, establecemos este tablespace para la base de datos.
ALTER SYSTEM SET UNDO_TABLESPACE=undotbs2;
Una vez realizado esto, podemos comprobar si lo hemos realizado bien, lanzando de nuevo la select
SQL> SELECT file_name, tablespace_name, bytes/1024/1024 UNDO_SIZE_MB, SUM(bytes/1024/1024) OVER() TOTAL_UNDO_SIZE_MB
FROM dba_data_files d
WHERE EXISTS (SELECT 1 FROM v$parameter p WHERE LOWER (p.name)='undo_tablespace' AND p.value=d.tablespace_name);
FILE_NAME                      TABLESPACE_NAME UNDO_SIZE_MB       TOTAL_UNDO_SIZE_MB
------------------------------ --------------- ------------ ------------------
/database/dba11g/undotbs02.dbf UNDOTBS2 300 300
Ahora, ya podemos borrar el tablespace UNDO antiguo. Lo hacemos de la siguiente forma:
SQL> DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES;
Nota: Las operaciones fashbackup necesitan tener establecida la variable UNDO_RETENTION para poder funcionar correctamente. En este caso podriamos establecerlo de la siguiente forma
Si queremos modificar el parámetro de UNDO_RETENTION, lo podemos hacer con la siguiente sentencia. En este caso, lo modificamos a 900
ALTER SYSTEM SET UNDO_RETENTION = 900 scope=both;
SQL> show parameter undo
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 900
undo_tablespace string UNDOTBS2
Última actualización el Miércoles, 12 de Marzo de 2014 13:28
 

¿QUÉ DISCOS DE ASM ESTAMOS UTILIZANDO Y A QUÉ DISPOSITIVO ESTÁN ASOCIADOS?

E-mail Imprimir PDF

Cuando usamos ASM para la administración de nuestros discos oracle, algunas veces, podemos perder la visión de qué discos se están utilizando en nuestro servidor y a qué dispositivos se corresponden.

ASMCMD es un comando que podemos utilizar para manipular los archivos y directorios que se encuentran dentro de un grupo de discos ASM. Una de las opciones que nos da es obtener un listado de los discos que actualmente tenemos

Para ver los discos, con el usuario root, lanzamos el siguiente comando

$ oracleasm listdisks
VOLUMEN1

Si queremos ver con qué dispositivo físico está mapeado, una vez que sabemos el nombre del volumen, podemos lanzar la siguiente consulta:

$oracleasm querydisk -d VOLUMEN1
Disk "VOLUMEN1" is a valid ASM disk on device /dev/dm-3[253,3]

 

Si no nos diera el nombre del dispositivo, con el major y minor (en el caso anterior 253 y 3) podemos editar el fichero /proc/partitions y verificar el nombre del dispositivo

cat /proc/partitions 
major minor  #blocks  name
 253     3  518488064 dm-3

 

 

CÓMO MODIFICAR LA POLÍTICA DE RETENCIÓN DE CLOUD CONTROL 12c

E-mail Imprimir PDF

Cloud Control tiene por defecto una política que borra todos los "logs" de los jobs que se ejecutaron y que tenían más de 30 días de antigüedad.

Para ver las políticas que tenemos actualmente en nuestro Cloud Control realizamos la siguiente consulta con el usuario sysman

1. Nos conectamos con el usuario Sysman

SQL> Connect sysman/*******

2. Lanzamos la siguiente consulta:

SQL> select * from mgmt_job_purge_policies;

Obtenemos el siguiente resultado:

POLICY_NAME                      TIME_FRAME
-------------------------------- ----------
SYSPURGE_SYSTEM_JOB_POLICY                3
ECMCOMPARISONPURGEPOLICY                184
SYSPURGE_POLICY                          30
OPATCHPATCHUPDATE_PAPURGEPOLICY           7
REFRESHFROMMETALINKPURGEPOLICY            7
CERTEOL_PLATCH_JOBPURGEPOLICY             7
CERTEOL_CERT_MD_JOBPURGEPOLICY            7
CERTEOL_EOL_MD_JOBPURGEPOLICY             7
DOWNLOADCVU_PURGEPOLICY                   7
9 filas seleccionadas.

Como podemos observar nuestra SYSPURGE_POLICY está por defecto, con 30 días.

 

Para modificar esta política seguimos los siguientes pasos:

 

1. Nos conectamos con el usuario sysman

SQL> Connect sysman/*******

 

2. Borramos la política con la siguiente sentencia:

SQL> execute MGMT_JOBS.drop_purge_policy('SYSPURGE_POLICY');
Procedimiento PL/SQL terminado correctamente.

Verificamos que se ha borrado correctamente lanzando de nueva la select

SQL> select * from mgmt_job_purge_policies;

 

POLICY_NAME                      TIME_FRAME
-------------------------------- ----------
SYSPURGE_SYSTEM_JOB_POLICY                3
OPATCHPATCHUPDATE_PAPURGEPOLICY           7
REFRESHFROMMETALINKPURGEPOLICY            7
CERTEOL_PLATCH_JOBPURGEPOLICY             7
CERTEOL_CERT_MD_JOBPURGEPOLICY            7
CERTEOL_EOL_MD_JOBPURGEPOLICY             7
DOWNLOADCVU_PURGEPOLICY                   7
8 filas seleccionadas.

 

Como podemos observar al realizar la select ya no la tenemos configurada esta política por lo tanto la podemos volver a recrear con nuestra nueva política de retención.

 

3. La volvemos a crear con el periodo de días que queramos guardar (En el ejemplo son 15 días).

SQL>  execute MGMT_JOBS.register_purge_policy('SYSPURGE_POLICY', 15, null);
Procedimiento PL/SQL terminado correctamente.

 

4. Volvemos a ejecutar la consulta para comprobar que se ha creado correctamente.

SQL> select * from mgmt_job_purge_policies;

POLICY_NAME                      TIME_FRAME
-------------------------------- ----------
SYSPURGE_POLICY                          15
SYSPURGE_SYSTEM_JOB_POLICY                3
ECMCOMPARISONPURGEPOLICY                184
OPATCHPATCHUPDATE_PAPURGEPOLICY           7
REFRESHFROMMETALINKPURGEPOLICY            7
CERTEOL_PLATCH_JOBPURGEPOLICY             7
CERTEOL_CERT_MD_JOBPURGEPOLICY            7
CERTEOL_EOL_MD_JOBPURGEPOLICY             7
DOWNLOADCVU_PURGEPOLICY                   7 9 filas seleccionadas.

Ahora nuestra SYSPURGE_POLICY está a 15 días.

 

OPERACIONES CON UN TABLESPACE TEMPORAL EN ORACLE 11G

E-mail Imprimir PDF

 

COMO CREAR UN TABLESPACE TEMPORAL

La creación del tablespace temporal la podemos realizar de la siguiente forma:

CREATE TEMPORARY TABLESPACE TEMP TEMPFILE  ‘/database/prueba/temp01.dbf′' SIZE 2000M; 

siendo  en este caso concreto ‘/database/prueba/temp01.dbf′' nuestra ruta para crear el tablespace y TEMP el nombre del tablespace;

CAMBIAR EL TABLESPACE TEMPORAL POR DEFECTO

Si tenemos varios tablespaces temporales en la base de datos podemos decidir cual queremos que sea el tablespace por defecto en caso de no indicarlo.

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP;

VERIFICAR SI LAS SESIONES ACTUALES ESTÁN USANDO LOS TABLESPACE TEMPORALES

Lo podemos hacer con las siguientes consultas:

SELECT * FROM V$SORT_USAGE;

COMO BORRAR UN TABLESPACE TEMPORAL

Lo podemos hacer con la siguiente sentencia. En este caso borraría el datafile físico del sistema operativo.

DROP TABLESPACE temp INCLUDING CONTENTS AND DATAFILES;

Nota: Cuando se realiza la operación de borrado o creación de un nuevo tablespace temporal no es necesario reiniciar la base de datos para que coja los cambios.

 

ORA-24247: network access denied by access control list (ACL)

E-mail Imprimir PDF

En la versión 11g tanto en la R1 como en la R2 de Oracle tenemos que tener en cuanto que para usar los paquetes UTL's se necesitan unos permisos especiales. Estos permisos se llaman ACL's.

En caso de que no tengamos definidos estos permisos podemos encontrarnos el siguiente error:

ORA-24247: network access denied by access control list (ACL)

Una de las situaciones donde nos podemos encontrar con este problema es en el envío de correos.

Como prueba, podemos ejecutar el siguiente código en el usuario con el que queramos enviar correos. Si no tenemos permisos nos dará el siguiente error.

DECLARE
v_mailsever_host VARCHAR2(30) := 'mail.xxxx.es';
v_mailsever_port PLS_INTEGER  := 25;
l_mail_conn  UTL_SMTP.CONNECTION;
BEGIN
l_mail_conn := UTL_SMTP.OPEN_CONNECTION( v_mailsever_host, v_mailsever_port);
 END;
 /

Error obtenido:

ORA-24247: network access denied by access control list (ACL)
ORA-06512: at "SYS.UTL_TCP", line 17
ORA-06512: at "SYS.UTL_TCP", line 246
ORA-06512: at "SYS.UTL_SMTP", line 115
ORA-06512: at "SYS.UTL_SMTP", line 138
ORA-06512: at line 6

 

¿Cómo podemos crear la ACL y dar permisos al usuario para poder enviar correos?

Pues bien, lo podemos hacer de la siguiente forma. Con el usuario SYS creamos la ACL

BEGIN
  DBMS_NETWORK_ACL_ADMIN.create_acl (
    acl          => 'envio_correos.xml', 
    description  => 'Envio de correos',
    principal    => 'USUARIO',
    is_grant     => TRUE, 
    privilege    => 'connect',
    start_date   => SYSTIMESTAMP,
    end_date     => NULL);
  COMMIT;
END;
/

Con esto hemos creado una lista para envio de correo y hemos dado permisos al usuario 'USUARIO' para poder usarla.

Ahora hay que definir el servidor de correo y puerto utilizado sobre la lista que anteriormente hemos creado

 

BEGIN
  DBMS_NETWORK_ACL_ADMIN.assign_acl (
    acl => 'envio_correos.xml',
    host => 'mail.xxxxxx.es', 
    lower_port => 80,
    upper_port => NULL); 
END;
/

Si quisieramos añadir otro puerto, volveríamos a ejecutar el mismo código con otro puerto distinto

BEGIN
  DBMS_NETWORK_ACL_ADMIN.assign_acl (
    acl => 'envio_correos.xml',
    host => 'mail.xxxxx.es', 
    lower_port => 25,
    upper_port => NULL); 
END;
/

Si quisieramos que otro usuario tuviera permisos para poder enviar correos, simplemente ejecutariamos este código con el usuario al que queramos dar permisos

BEGIN
  DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
    acl => 'envio_correos.xml', 
    principal => 'USUARIO2', 
    is_grant => TRUE, 
    privilege => 'connect');
END;
/

En caso de que queramos ver qué permisos tenemos dados y qué listas hay creadas en nuestra base de datos, usaremos las siguiente consultas:

 

SELECT * from dba_network_acls;
SELECT *  FROM   dba_network_acl_privileges;

 

 

ORA-28001: la contraseña ha expirado

E-mail Imprimir PDF

Por defecto, en ORACLE 11g, si los usuarios se crean bajo el ROLE Default, estarán sujetos a una política en la cual la contraseña caducará a los 180 días.

Esto es bueno puesto que te obliga a cambiar la contraseña. El problema es cuando uno desconoce esta política o se le olvida cambiar la contraseña en ese tiempo y el usuario, pasado ese periodo, se bloquea con sus correspondientes consecuencias para la aplicación que lo usa.

Para poder ver si en nuestra base de datos tenemos activa esta política ejecutamos la siguiente consulta:

SQL> select * from dba_profiles;

El resultado que obtenemos en este caso el siguiente:

DEFAULT;COMPOSITE_LIMIT;KERNEL;UNLIMITED
DEFAULT;SESSIONS_PER_USER;KERNEL;UNLIMITED
DEFAULT;CPU_PER_SESSION;KERNEL;UNLIMITED
DEFAULT;CPU_PER_CALL;KERNEL;UNLIMITED
DEFAULT;LOGICAL_READS_PER_SESSION;KERNEL;UNLIMITED
DEFAULT;LOGICAL_READS_PER_CALL;KERNEL;UNLIMITED
DEFAULT;IDLE_TIME;KERNEL;UNLIMITED
DEFAULT;CONNECT_TIME;KERNEL;UNLIMITED
DEFAULT;PRIVATE_SGA;KERNEL;UNLIMITED
DEFAULT;FAILED_LOGIN_ATTEMPTS;PASSWORD;10
DEFAULT;PASSWORD_LIFE_TIME;PASSWORD;180
DEFAULT;PASSWORD_REUSE_TIME;PASSWORD;UNLIMITED
DEFAULT;PASSWORD_REUSE_MAX;PASSWORD;UNLIMITED
DEFAULT;PASSWORD_VERIFY_FUNCTION;PASSWORD;NULL
DEFAULT;PASSWORD_LOCK_TIME;PASSWORD;1
DEFAULT;PASSWORD_GRACE_TIME;PASSWORD;7

Como podemos observa vemos que para el ROLE Defaut la política de expiración de password está puesta a 180 días. Si nuestros usuarios tienen este ROLE asociado, están sujetos a esta política.

Si queremos verificar a qué profile está asociado nuestro usuario, lo podemos hacer con la siguiente consulta:

select username ,profile from dba_users;

Para cambiar esta política en el ROLE DEFAULT y establecerla a indefinida permitiéndonos así a nosotros cambiar la contraseña del usuario cuando creamos conveniente ejecutaremos la siguiente consulta:

ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

En caso de que nuestro usuario haya sido bloqueado debido a que ya pasaron los 180 días desde su creación o cambio de contraseña, podremos desbloquearlo y cambiar la contraseña de la siguiente forma

SQL> alter user usuario identified by 'password';
SQL> alter user usuario account unlock;
Última actualización el Miércoles, 05 de Marzo de 2014 09:24
 

COMO BORRAR/ELIMINAR UN AGENTE DE ENTERPRISE MANAGER 12C (CLOUD CONTROL)

E-mail Imprimir PDF

 

Antes de desinstalar un agente, sería conveniente para nuestro agente con el siguiente comando

$ emctl stop agent

y esperamos a que en nuestro Enterprise Manager actualice el estado de nuestro agente en la consola.

 

Una vez realizado esto podremos eliminar de nuestro EM o Cloud Control el agente de la siguiente forma

1. Hacemos login en nuestro cloud control / EM

2. Menu Configurar => Gestionar Cloud Control => Agentes

3. Hacemos click sobre el agente que queremos eliminar. Esto nos lleva a su página principal con los datos de este agente.

4. Extendemos el menu "agente" (arriba a izquierda)

5. Seleccionamos "configuración de destinos"

6. Una vez extendido ese menu seleccionamos "Eliminar Destino"

 

Si el agente tiene destinos asociados saldrá un mensaje que nos indicará que antes tendremos que eliminar los destinos asociados.

 


Página 1 de 8

Haz login con tu cuenta orasite

Haz login con tu cuenta de:

Errores Oracle más comunes

Sitios Relacionados


Últimos posts del foro

Por Gresh hace 1 mes, 1 semana
Solucionado
Por NoeDePaz hace 1 mes, 3 semanas
Todo lo que necesitas simplemente eliminar el error de sus archivos DBF y después de hacer esto usted puede acceder a los archivos corruptos. Los dato
Por Borland hace 1 mes, 4 semanas
Hola! Usted puede emplear indice unico? Si no, solo trigger.
Por Borland hace 1 mes, 4 semanas
Hola! Pordesgracias, yo puedo dar solo referencia a documentacion ingles...:(
Por evelyn hace 2 meses, 1 semana
Hola, gracias darme acceso. Por favor me gustaría saber si alguien ha implantado alguna vez en Oracle Ebs en portugal para poder emitir los docume

Ver más...

Últimos comentarios

    RE: ORA-27506
    24.06.16 18:19 Por Lazaro
    alguien que me pueda ayudar a solucionar este problema Más...
    RE: ORA-27506
    24.06.16 17:47 Por Lazaro
    alguien que me pueda ayudar a solucionar este problema Más...
    EXPORT ORACLE 10G/11G
    17.06.16 00:11 Por Pedro Octavio Vera
    El error esta esta en tu corazón Más...
    RE: ORA-00913
    02.05.16 01:34 Por Leoncio Guerra Gonzales
    ORA-02291: integrity constraint (SYSTEM.SYS_C008527) violated - parent key not
    found
    ...
    Más...
    RE: ORA-00913
    02.05.16 01:29 Por Leoncio Guerra Gonzales
    por fa me podar ayudar le envie el mensaje Más...

Encuesta

¿Qué versión de Oracle tienes actualmente en producción?