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

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

Eliminar un DR del Dataguard

Hoy vamos a ver un a entrada rápida de como eliminamos un DR de una configuración de dataguard.

Tenemos un entorno donde tenemos 2 Physycal standby y queremos eliminar la primera de ellas TEST_STBY1

Comprobemos la configuración de nuestro entorno, nos conectamos a la primaria y ejecutamos:

-bash-4.2$ . oraenv
ORACLE_SID = [oracle] ? TEST
The Oracle base has been set to /opt/app/oracle
-bash-4.2$ export ORACLE_SID=TEST
-bash-4.2$ dgmgrl /

DGMGRL> show configuration verbose;
Configuration - DR_TWO_STANDBY
  Protection Mode: MaxPerformance
  Databases:
    TEST      - Primary database
    TEST_STBY1    - Physical standby database
    TEST_STBY2 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> show database  'TEST_STBY1';
Database - TEST_STBY1
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   14 hours 4 minutes 14 seconds
  Apply Lag:       14 hours 4 minutes 14 seconds
  Real Time Query: OFF
  Instance(s):
    TEST
Database Status:
SUCCESS

Tenemos claro que es la que queremos eliminar , de echo, podemos ver como lleva 14 horas. de retraso .
Para eliminarla ejecutaremos el comando Remove Database , si vemos el ejemplo, poderes ver como siempre ponemos el nombre de la base de datos entre comillas simples, en caso de no hacerlo, el dataguard lo tomará como minúsculas


DGMGRL> disable database 'TEST_STBY1';
Disabled.

DGMGRL> remove database 'TEST_STBY1';
Removed database "TEST_STBY1" from the configuration

DGMGRL> show configuration verbose;

Configuration - MyTEST_STBY1
  Protection Mode: MaxPerformance
  Databases:
    TEST      - Primary database
    TEST_STBY2 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> quit

Ya lo hemos eliminado, pero , deberemos de comprobar en nuestra base de datos primaria que no hemos dejado restos, para ello, buscaremos que los servicios y los destinos de archivado estén limpios de nuestra configuración anterior.

-bash-4.2$ sqlplus "/as sysdba"

SQL> set linesize 800;
SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE

log_archive_dest_1                   string      location=USE_DB_RECOVERY_FILE_
                                                 DEST, valid_for=(ALL_LOGFILES,
                                                  ALL_ROLES)
log_archive_dest_2                   string      service="TEST_STBY1", LGWR ASYNC NOAFFIRM
                                             
log_archive_dest_3                   string      service="TEST_STBY2", LGWR ASYNC NOAFFIRM 
												
SQL>   show parameter log_archive_config;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(TEST,TEST_STBY1,TEST_STBY2)

Podemos ver como el broker no ha limpiado la configuración, por lo que lo haremos nosotros a mano

SQL> alter system set log_archive_dest_2='' scope=both;
SQL> alter system set log_archive_config='dg_config=(TEST,TEST_STBY2)' scope=both;



SQL> show parameter log_archive_config;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(TEST,TEST_STBY)
SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      location=USE_DB_RECOVERY_FILE_
                                                 DEST, valid_for=(ALL_LOGFILES,
                                                  ALL_ROLES)
log_archive_dest_2                   string
log_archive_dest_3                   string      service="TEST_STBY2", LGWR ASYNC NOAFFIRM
SQL>

Con esto, podremos afirmar que nuestra configuración está limpia

Version del parcheado de la base de datos

Hoy vamos a ver otra de estas entradas para dummies utiles en el dia a dia.
Como sabemos en que version de parcheado nos encontramos?

La primera opcion y mas sencilla es la del uso del binario del sistema operativo opatch, pero , como podemos estar seguros de que el parche/psu se ha ejecutado correctamente y se ha aplicado tambien la parte SQL

Oracle 11g

Si estamos en la version 11g deberemos de hacerlo consultando la tabla del diccionario sys.registry$history

SET LINESIZE 180 PAGESIZE 90 
COLUMN FECHA FORMAT A18
COLUMN action FORMAT A20
COLUMN version FORMAT A10
COLUMN comments FORMAT A30
COLUMN bundle_series FORMAT A10
SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI') AS FECHA,
       action,
       namespace,
       version,
       comments,
       bundle_series
FROM   sys.registry$history
ORDER by action_time;

Lo que nos devolvera algo similar a :

FECHA              ACTION               NAMESPACE            VERSION    COMMENTS                       BUNDLE_SER
------------------ -------------------- -------------------- ---------- ------------------------------ ----------
07-JAN-2017 15:21  APPLY                SERVER               11.2.0.3   PSU 11.2.0.3.15                PSU
01-DEC-2017 18:59  UPGRADE              SERVER               11.2.0.4.0 Upgraded from 11.2.0.3.0
01-DEC-2017 19:00  APPLY                SERVER               11.2.0.4   PSU 11.2.0.4.171017            PSU

Oracle 12c

Cuando estamos en la version 12c, tendremos dos maneras de encontrar esta informacion:

Preguntando a DBA_REGISTRY_SQLPATCH

La consulta sera muy similar a la anterior, pero en ved de preguntar a el dicionario sys.registry$history, lo haremos a la tabla DBA_REGISTRY_SQLPATCH



SET LINESIZE 180 PAGESIZE 90 
COLUMN FECHA FORMAT A20
COLUMN action FORMAT A10
COLUMN status FORMAT A20
COLUMN description FORMAT A90
COLUMN version FORMAT A10
COLUMN bundle_series FORMAT A10
SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI:SS') AS action_time,
       action,
       status,
       description,
       version,
       patch_id,
       bundle_series
FROM   sys.dba_registry_sqlpatch
ORDER by action_time;

Lo que nos devolvera algo similar a

ACTION_TIME          ACTION     STATUS     DESCRIPTION                              VERSION      PATCH_ID BUNDLE_SER
-------------------- ---------- ---------- ---------------------------------------- ---------- ---------- ----------
07-MAR-2018 21:37:51 APPLY      SUCCESS    Database Patch Set Update : 12.1.0.2.4  12.1.0.2     20831110 PSU
                                         (20831110)

Mediante el package dbms_qopatch

En la version 12c tenemos el nuevo datapatch en los parcheados, la informacion de los parches de la base de datos esta tambien accesible con el package dbms_qopatch.
Esto ya lo vimos en la entrada Obtener los parches instalados en la base de datos CDB que venia a decir :

 
 set serverout on
exec dbms_qopatch.get_sqlpatch_status;

Lo que nos devuelve

Patch Id : 25171037
        Action : APPLY
        Action Time : 14-JUN-2017 23:09:33
        Description : DATABASE PATCH SET UPDATE 12.1.0.2.170418
        Logfile :
/u01/app/oracle/cfgtoollogs/sqlpatch/25171037/21099266/25171037_apply_SID_2017Jun14_23_09_20.log
        Status : SUCCESS
PL/SQL procedure successfully completed.

Sobre el uso de dbms_qopatch tenemos la URL hay una URL Como saber si un parche esta aplicado en la BBDD que tiene consultas muy utiles para obtener informacion de la base de datos (inventario,paches…)

Esta informacion ha sido obtenido en su totalidad de las URLS:

kernel.panic_on_oops : Nuevo parametro de la 12c

Hoy vamos a ver otra de estas pequeñas sorpresas de Oracle en las nuevas versiones
En los requisitos de la instalacion de la version 12c de Oracle nos encontramos con la siguiente nota

Note: 
The below Kernel Parameter "panic_on_oops=1" is being Introduced and required
 from 12.1.0.2.0 onwards.
kernel.panic_on_oops=1

Que es lo que hace este parametro del Kernel?
Este parametro simplemente controla el comportamiento del kernec cuando un oops or bug es detectado.

Los valores que puede tomar es:

  • 0: INtenta continuar la operacion
  • 1: Entra en panic , ademas de este panica, si el sysctl es distnto de cero, entonces el servidor se reiniciara

Como veis, un parametro bastante inocuo… hasta que buscamos la causa de por que el servidor se ha reiniciado

Problemas con optachauto y resolucion de nombres (error code 238)

Hoy vamos a ver una entrada rápida

Recientemente me he encontrado con el error code 238 intentando llevar a cabo la aplicación de un parche con el optachauto.

Al intentar llevar a cabo el parcheado me devolvía el siguiente error:

root:$GRID_HOME/OPatch/opatchauto apply $PARCHES/26610308 
OPatchauto session is initiated at Sun Nov 18 15:56:14 2017 

Patch version not found


OPatchauto session completed atSun Nov 18 15:56:20 2017 
Time taken to complete the session 0 minute, 7 seconds 

opatchauto bootstrapping failed with error code 238. 

La primera conclusion que debemos de sacar de esto. siempre hay que hacer el analize antes de la aplicacion, ya que de esa manera habríamos comprobado el error .

Tras mucho buscar en la web de soporte y abrir un caso con Oracle, encontramos el problema.

El fichero /etc/hosts de mi servidor tenia mas de dos entradas, supongamos que fuese algo similar a:


10.0.0.1  SERVER server server.dominio  server-vip.dominio 

Si desde el sistema operativo preguntábamos por cualquiera de las 4 entradas, el servidor funcionaba correctamente.

Sin embargo, al cambiar esa linea por


10.0.0.1  server server.dominio
10.0.0.1  SERVER  SERVER.dominio 
10.0.0.1  serve-vip  server-vip.dominio 

Todo volvió a funcionar a la perfeccion.

Un expediente X que nos sirve para recordar que no todo vale a la hora de solcitar las instalaciones a los equipos responsables de los sistemas operativos, las nuevas herramientas de gestion de los componentes de oracle (opatchauto,datapatch …) son muy potentes, pero no dejan de ser componentes externos a la base de datos que requieren de configuraciones correctas que, desgraciadamente no suelen estar tan documentadas como los prerrequisitos del GRID, RAC o Base de datos, por lo que siempre deberemos de velar por que los sistemas operativos donde se encuentran nuestros motores esten prefectametne configurados