Archivo de la etiqueta: ORA-

Usando los bloques logicos en ASM

Posted on por
Responder

Hoy vamos a ver una entrada que nos puede causar grandes dolores de cabeza .

Uno de los problemas con los que nos podemos encontrar cuando se modifica la tecnología de los discos físicos utilizados en el ASM es el cambio del tamaño de bloque lógico.

Supongamos que nos ofrecen un nuevo disco /dev/xvdz

Nosotros intentamos añadirlo al ASM, pero recibimos un error ORA-01378

Errors in file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_40862.trc:
ORA-01378: The logical block size (512) of file +REDO is not compatible with the disk sector size 
(media sector size is 4096 and host sector size is 4096)

Veamos las características de este disco 

sudo fdisk -l /dev/xvdz
Disk /dev/xvdd: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Y veamos ahora otro de los discos que tenemos 

The other disks  have sector size 512
Disk /dev/xvdp: 2147.5 GB, 2147483648000 bytes
255 heads, 63 sectors/track, 261083 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Si nos fijamos, el problema que tenemos es que el sector size de nuestro nuevo disco es 8 veces mayor que el del disco viejo (521 / 4096) .

Como solucionamos ahora nuestro problema?

Tal y como indican el el blog flashdba ASM tiene un parámetro en el fichero de configuración llamado ORACLEASM_USE_LOGICAL_BLOCK_SIZE que por defecto esta a false, que era el parámetro por defecto de oracleasm-support-2.1.8.
Podemos ver su valor en el fichero /etc/sysconfig/oracleasm 

# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false

Lo que vamos ha hacer es modificarlo a TRUE, de manera que el ASM sea capaz de usar los bloques de manera lógica y no se aferre a la configuración física de los mismos, esto lo hacemos con el script
oracleasm-configure.sh

  • -b|—logical-blocks sets logical blocksize usage
  • -p|—physical-blocks set physical blocksize usage

Veamos ahora cual es la información que nos dará nuestro ASM 

[oracle@testserver ~]$ sysasm
 SQL> select NAME,SECTOR_SIZE,BLOCK_SIZE,DATABASE_COMPATIBILITY,COMPATIBILITY,((TOTAL_MB-FREE_MB)*100/TOTAL_MB) PERCENT_USED from v$asm_diskgroup;

NAME         SECTOR_SIZE BLOCK_SIZE DATABASE_COMPATIBILI COMPATIBILITY        PERCENT_USED
-------------------- --------- ---------- -------------------- -------------------- ------------
REDO               4096       4096 10.1.0.0.0           10.1.0.0.0             .249023438
FRA                 512       4096 10.1.0.0.0           12.1.0.0.0             44.1858724
DATA                512       4096 11.2.0.0.0           11.2.0.0.0             90.4637587

Como podeis ver, es un problema que se nos puede dar en bases de datos con ASM antiguos en los que llevemos a cabo un cambio de tecnología física.

Mas informacion en

Oracle ASMLib: Physical and Logical Blocksize

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

ORA-24247 con el paquete STMP

Posted on por

Hoy vamos a ver como resolver errores ORA-24247 en la version 11g . Aunque desde aquí siempre hemos mantenido (y mantendremos) que la base de datos no debería ser la responsable de enviar correos o conectarse a «vete a saber donde» hay entornos en los que nos vemos obligados a ello.

¿Que ocurre si nos encontramos con un error de este tipo ?

error-ora-ORA-24247.jpg

ERROR at line 1:
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 "XXX", line 36
ORA-06512: at line 1

Este error es debido a que no contamos con una ACl para el servicio de red, las ACLs son un elemento nuevo de Oracle 11g (11.1.0.6) que establece un filtrado mas detallado (fine-grained access) y que controla el acceso a algunos paquetes como el UTL_SMTP o el UTL_HTTP.

¿como lo solicionamos?

Sencillamente tenemos que crear una ACL que nos permita acceder al puerto 25 de nuestro servidor de correo.
En este caso lo haremos para

  • SMTP Server 127.0.0.1 (localhost de la BBDD)
  • Puerto 25 ( puerto estandard de correo)
  • usuarios Usuario1 y usuario2

Así pues , ejecutaremos :

begin
--creamos la ACL
DBMS_NETWORK_ACL_ADMIN.CREATE_ACL
   (acl => 'send_mail.xml',
   description => '
   send_mail ACL',
   principal => 'USUARIO1',
   is_grant => true, 
   privilege => 'connect');
-- Asignamos privilegios  al usuario elegido 
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
   acl => 'send_mail.xml',
   principal => 'USUARIO1',
   is_grant  => true,
   privilege => 'connect');
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
   acl => 'send_mail.xml',
   principal => 'USUARIO1',
   is_grant  => true,
   privilege => 'resolve');
-- Asignamos provilegios  al usuario elegido 
DBMS_NETWORK_ACL_ADMIN.ADD_PRIVILEGE(
   acl => 'send_mail.xml',
   principal => 'USUARIO2',
   is_grant  => true,
   privilege => 'connect');
--Asignamos recursos 
 dbms_network_acl_admin.assign_acl (
   acl => 'send_mail.xm',
   host => '127.0.0.1',
   lower_port => 25,
  upper_port => 25);
END;
/
COMMIT;

Si queremos ver las ACL creadas 

SELECT * FROM dba_network_acls;

Y los privilegios de cada una de ellas 

SELECT acl
      ,principal
      ,privilege
      ,is_grant
      ,invert
      ,start_date
      ,end_date
  FROM dba_network_acl_privileges;

Como siempre , mas información en oracle en las notas:

ORA-29786 eliminando un Diskgroup

Posted on por

Hoy vamos a ver un error que puede ser bastante común si creamos las cosas a mano » a la antigua usanza».

Veamos algo que puede ocurrirnos cuando intentamos eliminar un diskgroup en nuestro ASM 

[oracle@test]$ sqlplus "/as sysasm"
SQL*Plus: Release 11.2.0.3.0 Production on Fri Apr 09 21:10:38 2015
Copyright (c) 1982, 2011, Oracle.  All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Automatic Storage Management option
SQL> DROP DISKGROUP TEMP INCLUDING CONTENTS;
DROP DISKGROUP TEMP INCLUDING CONTENTS
*ERROR at line 1:
ORA-15039: diskgroup not dropped
ORA-29786: SIHA attribute GET failed with error [Attribute 'SPFILE' sts[200]lsts[0]]

Este error nos va a dar tanto si está montado, desmontado, tiene ficheros, o está vacío, y , el problema es el modo de creacion.

Desde la versión 11gr2 el ASM es un recurso mas del CRS, por lo cual, para poder llevar a cabo determinadas operaciones como create/drop diskgroup, create pfile/spfile es necesario que el ASM esté registrado como un recurso del cluster.

La solucion para poder llevar a cabo estas acciones es añadir el ASM al repositorio del cluster 

srvctl add asm -h
Adds an ASM configuration to be managed by Oracle Restart.
Usage: srvctl add asm [-l ] [-p ] [-d ]
    -l            Listener name
    -p               Server parameter file path
    -d       ASM diskgroup discovery string
    -h                       Print usage


srvctl add asm  -p $GRID_HOME/dbs/init+ASM.ora 
srvctl status asm

Más informacion como siempre en metalink en la nota

Capturar errores de usuario en la base de datos

Posted on por

Hoy vamos a ver como facilitarnos un poco el control del código de aplicación de la base de datos.

En muchas ocasiones, los desarrolladores no llevan a cabo correctamente la captura de errores , lo que produce una serie quejas «no me va y no me da error».
Para lidiar con estas situaciones podemos crear un pequeño trigger que registre en la base de datos que y quien genera errores en la base de datos, para poder seguirlos y depurar estos errores.

Vamos a suponer que:

  • Tenemos un tablespace específico llamado CONTROL donde guardaremos nuestros datos
  • Tenemos un usuario llamado CONTROL que será el propietario del código

Primero crearemos la tabla que contendrán los errores:

-- Creamos la tabla 
create table CONTROL.oraerror (
identificador   NUMBER,
FECHA           DATE,
ESQUEMA         VARCHAR2(30),
USUARIO         VARCHAR2(50),
SQL_ID          VARCHAR2 (13) DEFAULT NULL,
SQL_HASH_VALUE  NUMBER DEFAULT NULL,
err_nr          NUMBER(10),
err_msg         VARCHAR2(4000),
stmt            CLOB
) TABLESPACE CONTROL;

--
-- Creamos una secuencia para el oraerror
create sequence CONTROL.oraerror_seq
start with 1
increment by 1
minvalue 1
nomaxvalue
nocache
nocycle;

Y después crearemos nuestro trigguer

CREATE OR REPLACE TRIGGER CONTROL.after_error
 AFTER SERVERERROR ON DATABASE
 DECLARE
 id             NUMBER;
 vSerial        NUMBER DEFAULT NULL;
 ESQUEMA        VARCHAR2(30);
USUARIO         VARCHAR2(50);
 SQL_ID         VARCHAR2 (13) DEFAULT NULL;
 SQL_HASH_VALUE NUMBER DEFAULT NULL;
  sql_text      ORA_NAME_LIST_T;
 v_stmt         CLOB;
 n              NUMBER;
 vsid           NUMBER DEFAULT NULL;
BEGIN
 -- BUscamos ID 
SELECT dbms_debug_jdwp.current_session_serial serial# INTO vSerial 
      FROM DUAL;
SELECT oraerror_seq.nextval,SYS_CONTEXT ('USERENV', 'sid') INTO  id, vsid
     FROM dual;
SELECT  SQL_ID, SQL_HASH_VALUE,USERNAME,OSUSER INTO SQL_ID, SQL_HASH_VALUE,ESQUEMA,USUARIO
   FROM sys.v_$session   WHERE sid = vsid AND serial# = vSerial;
n:= ora_sql_txt(sql_text);

IF n >= 1
 THEN
 FOR i IN 1..n LOOP
 v_stmt := v_stmt || sql_text(i);
 END LOOP;
END IF;
--
 FOR n IN 1..ora_server_error_depth LOOP
      INSERT  /*+ APPEND */ 
      INTO CONTROL.oraerror VALUES(id, sysdate, ESQUEMA, USUARIO, SQL_ID,SQL_HASH_VALUE,  ora_server_error(n), ora_server_error_msg(n), v_stmt);
  END LOOP;
 --
END ;

Con esto tendrémos en nuestra tabla todos los errores que dela base de datos.
Hay que tener en cuenta que, muchos de los errores pueden ser correctos, como los errores :

  • ORA-01017: nombre de usuario/contraseña no válidos; conexión denegada
  • ORA-00001: unique constraint (XXXX) violated (error asumible en cargas masivas)
  • ORA-03113: end-of-file on communication channel ORA-03113: end-of-file on communication channel

Con lo que habrá que seguirlos con cuidado y ver en que caso son reprochables o asumibles