log_archive_dest_1

Posted on por
Responder

Hoy vamos a ver una entrada un tanto extraña que me ha ocurrido en alguna base de datos.

A la hora de configurar el archivado, el parametro que tenia era 


alter system set log_archive_dest_1=
'LOCATION=USE_DB_RECOVERY_FILE_DEST,valid_for=(ALL_LOGFILES, ALL_ROLES)';

Sin embargo,  esto fallaba no dejando los archivers en a ubicacion correcta. 

¿como lo solcione?

Algo tan extraño como cambiandolo por una de estas dos maneras 


alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES, ALL_ROLES)'

alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST','VALID_FOR=(ALL_LOGFILES, ALL_ROLES)'

Como podeis ver , la diferencia es muy sutil, pero , igual puede servirle a alguien mas

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

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

ORA-38870: cannot backup a control file that may have incorrect data file structure.

Posted on por
Responder

Hoy vamos a volver con una entrada rapida de un problema muy facil de solucionar.

A veces, podemos encnontrarnos en el alert.log con el error 

ORA-38870:cannot backup a control file that may have incorrect data file structure

Si miramos las trazas asustan bastante 

2018-10-23T16:08:43.542081+02:00
Errors in file /u01/app/oracle/diag/rdbms/test_stby/test/trace/test_m000_425.trc:
ORA-38870: cannot backup a control file that may have incorrect data file structure.
2018-10-23T16:13:43.189251+02:00
Starting control autobackup
********************  WARNING ***************************
The errors during Server autobackup are not fatal, as it
is attempted after sucessful completion of the command.
However, it is recomended to take an RMAN control file
backup as soon as possible because the Autobackup failed
with the following error:
ORA-38870: cannot backup a control file that may have incorrect data file structure.
********************  END OF WARNING *******************

Pero, buscando en la documentacion de Oracle, nos contraremos que

Error code: ORA-38870

Description: cannot backup a control file that may have incorrect data file structure.
This control file was created or converted based on a control file from a time different from the time of the database.
Action: Open database read-only to synchronize the control file with the database dictionary to fix the control file

Cualquier cosa relaccionada con una estructura invalida de un controlfile puede asustar bastante, pero , este alarmante problema se soluciona de manera muy rapida y sencilla, simplemente haciendo eso, abriendo la base de datos en modo lectura.
Y ya no volveremos a ver mas el problema

Comprobando del OEM 13: alertas Data Failure Detected

Posted on por
Responder

Hoy vamos a ver otra entrada sobre las comprobaciones del OEM .

Una de los incidentes que hay que limpiar a mano en el enterprise manager es el de la comprobacion de la integridad dela base de datos.
El check de la metrica Data Failure Detected se basa en las comprobaciones de los Health monitor de Oracle.

Como saber a que problema se refiere

Mediante la libreria DBMS_HM podemos acceder a los checks llevados a cabo por Oracle.
Si ejecutamos la consulta

SET LONG 100000;
SET LONGCHUNKSIZE 1000
SET PAGESIZE 1000
SET LINESIZE 512
column name format a20;
column STATUS format a10;
column START_TIME format a20;
column END_TIME format a20;
column name format a20;
column STATUS format a10;
column START_TIME format a30;
column END_TIME format a30;
column CHECK_NAME format a40;

 select run_id,name,check_name,start_time,end_time,status 
   from v$hm_run order by START_TIME asc;

Obtendremos el listado de los checks ejecutados 

    RUN_ID NAME                 CHECK_NAME                   START_TIME
---------- ---------------- -------------------- ------------------------------
   1 HM_RUN_1       DB Structure Integrity Check   25-JUL-18 05.18.01.337628 PM
  21 HM_RUN_21      DB Structure Integrity Check   25-JUL-18 05.19.35.157614 PM
  41 HM_RUN_41      DB Structure Integrity Check   25-JUL-18 05.20.51.496617 PM
  61 HM_RUN_61      DB Structure Integrity Check   25-JUL-18 05.52.24.630598 PM
9621 HM_RUN_9621    DB Structure Integrity Check   15-SEP-18 05.51.52.339032 PM
9641 HM_RUN_9641    DB Structure Integrity Check   15-SEP-18 05.53.25.135027 PM
 6 rows selected.

En el caso del ejemplo, preguntaremos por la ultima ejecucion, que es la HM_RUN_9641

DBMS_HM.GET_RUN_REPORT('HM_RUN_9641')
-----------------------------------------------------------------------------------------
Basic Run Information
 Run Name                     : HM_RUN_9641
 Run Id                       : 9641
 Check Name                   : DB Structure Integrity Check
 Mode                         : REACTIVE
 Status                       : COMPLETED
 Start Time                   : 2018-09-15 17:53:25.135027 +02:00
 End Time                     : 2018-09-15 17:53:28.473273 +02:00
 Error Encountered            : 0
 Source Incident Id           : 0
 Number of Incidents Created  : 0

Input Paramters for the Run
Run Findings And Recommendations
 Finding
 Finding Name  : Inaccessible CF
 Finding ID    : 9642
 Type          : FAILURE
 Status        : CLOSED
 Priority      : CRITICAL
 Message       : Control file
               +DATA/test/controlfile/current.599.982430265
               cannot be accessed because of an ASM Failure
 Message       : Database cannot be mounted

Aqui podemos ver como el error es referente a un controlfile inaccesbile , lo que parece ser un error antiguo.

¿Como asegurarnos de que todo esta correcto?

La respuesta mas obia es, lanzar nosotros mismos este check de manera manual para ver el resultado.
Para ello usaremos el procedure DBMS_HM.RUN_CHECK

SQL> SELECT DBMS_HM.GET_RUN_REPORT('Clear_OEM') FROM DUAL;

DBMS_HM.GET_RUN_REPORT('CLEAR_OEM')
-----------------------------------------------------------------------------------
Basic Run Information
 Run Name                     : Clear_OEM
 Run Id                       : 10581
 Check Name                   : DB Structure Integrity Check
 Mode                         : MANUAL
 Status                       : COMPLETED
 Start Time                   : 2018-09-18 20:58:12.283769 +02:00
 End Time                     : 2018-09-18 20:58:12.476010 +02:00
 Error Encountered            : 0
 Source Incident Id           : 0
 Number of Incidents Created  : 0

Input Paramters for the Run
Run Findings And Recommendations

Donde podemos ver como ya no tenemos errores

Como siempre, mas informacion en: