Archivo de la categoría: 12c

Datafiles UNAMED en dataguard

Posted on por
Responder

Hoy vamos a ver un a pequeña entrada de un error bastante común en dataguard.

El problema se da cuando la base de datos standby deja de aplicar 

DGMGRL> show configuration verbose
Configuration - test
  Protection Mode: MaxPerformance
  Members:
  DBTEST        - Primary database
    DBTEST_STBY   - Physical standby database
      Error: ORA-16810: multiple errors or warnings detected for the database

Ante un error tan genérico como este, lo primero que hemos de hacer es buscar en el alert.log de la base de datos del standby.
En este alert.log ya vemos un error mas claro 

Errors in file /u01/app/oracle/diag/rdbms/dbtest_stby/dbtest/trace/dbtest_mrp0_3972.trc:
ORA-01111: name for data file 21 is unknown - rename to correct file
ORA-01110: data file 21: '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'
ORA-01157: cannot identify/lock data file 21 - see DBWR trace file
ORA-01111: name for data file 21 is unknown - rename to correct file
ORA-01110: data file 21: '/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'

Que es ese datafile que aparece en el $ORACLE_HOME/dbs llamado UNNAMED?

La respuesta nos la da oracle en la nota ID 739618.1..
Estos ficheros aparecen en el equipo de standby cuando se ha creado un datafile en el primario y el secundario no ha podido crearlo (por falta de espacio, error de configuración …. )

Como lo solucionamos ?

Lo primero que tenemos que hacer es cambiar el STANDBY_FILE_MANAGEMENT a MANUAL ya que vamos a modificar manualmente la ubicación de ficheros.

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

Tras esto, identificaremos en la base de datos primary cual es la ubicación correcta del fichero, si miramos en el extracto anterior del alert.log, veremos que se trata del datafile 21, así pues, iremos a la base de datos primary y veremos donde esta ubicado .

SQL>   select file_name,tablespace_name,bytes/1024/1024/1024 Gb
  from dba_data_files where file_id=21;

FILE_NAME  		                      TABLESPACE_NAME      GB 
----------------------------------------------------------------
+DATA_01/DBTEST/DATAFILE/testdf.791.968123327   TESTDF           5

Ahora tenemos que ir al standby y mover el fichero UNNAMED a su lugar correcto, para ello no usaremos el MOVE sino el comando CREATE DATAFILE AS 

alter database create datafile 
'/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'
 as '+DATA_01' ;

Como podéis ver, no ha indicado el nombre que debe de tener el datafile, solamente la ruta, esto es por que tenemos definido el parametro db_recovery_file_dest que nos lo dejara con el nombre correcto.

Posible errores

Efectivamente, con el comando anterior no va a funcionar, ya que nos dara el error 

ERROR at line 1:
ORA-01136: specified size of file 204 (80 blocks) is less than original size of
655360 blocks
ORA-01111: name for data file 204 is unknown - rename to correct file
ORA-01110: data file 204:
'/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021'

Que hemos echo mal ?

No hemos echo nada mal, lo que ocurre es que cuando la ubicación de destino es dentro el ASM tendremos que indicarle el tamaño exacto del fichero .
En el alert nos ha indicado que el tamaño es de 655360 blocks
Si miramos el tamaño de bloque que tenemos :

SQL> show parameter block_size
NAME               TYPE        VALUE
------ --------------------------------------
db_block_size     integer       8192

Llevando a cabo una pequeña operacion aritmética 655360 *8192=5368709120

Ya podemos ejecutar el comando completo 

alter database create datafile 
'/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/UNNAMED0021' 
as '+DATA_01'size 5368709120;

Con esto tenemos el problema solucionado.

Volvemos a poner el standby en modo management auto 

ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

Y activamos el broker de nuevo desde el primario. 

DGMGRL> show configuration verbose
Configuration - test
  Protection Mode: MaxPerformance
  Members:
  DBTEST        - Primary database
    DBTEST_STBY   - Physical standby database
      Error: ORA-16810: multiple errors or warnings detected for the database

DGMGRL> enable database 'DBTEST_STBY'
Disabled.
DGMGRL> enable database 'DBTEST_STBY'
Enabled.
DGMGRL> show configuration verbose
Configuration - test
  Protection Mode: MaxPerformance
  Members:
  DBTEST        - Primary database
    DBTEST_STBY   - Physical standby database
.
.

Configuration Status:
SUCCESS

Como siempre , mas información en las notas de soporte

  • How to resolve ORA-01111 ORA-01110 ORA-01157 in a physical standby database (Doc ID 1416554.1)
  • Background Media Recovery terminated with ORA-1274 after adding a Datafile (Doc ID 739618.1)

Apagando instancias

Posted on por
Responder

Hoy vamos aver un pequeño script que nos facilitara el apagar todas las bases de datos de un servidor aunque no esten incluidas en el rac

Si nos fijamos un poco en el script, podemos ver como las funciones de apagado estan comentadas, esto es una mera medida de seguridad para evitar posibles errrores de «copy & paste »

[cc lang=»shell»]
#!/bin/bash
#
#
# Name: stop_oratab_alone.sh
# Desc: Stops all oratab databases (not RAC)

function estado
{
echo » The status of $ORACLE_SID is:»
sqlplus -s «/as sysdba» << EOF 2>>/dev/null
set linesize 400;
column host_name format a30;
column instance_name format a20;
column Started format a25;
column uptime format a60;
select
host_name,
instance_name,
to_char(startup_time,’DD-MON-YYYY HH24:MI:SS’) Started,
‘Uptime : ‘ || floor(sysdate – startup_time) || ‘ days(s) ‘ ||
trunc( 24*((sysdate-startup_time) –
trunc(sysdate-startup_time))) || ‘ hour(s) ‘ ||
mod(trunc(1440*((sysdate-startup_time) –
trunc(sysdate-startup_time))), 60) ||’ minute(s) ‘ ||
mod(trunc(86400*((sysdate-startup_time) –
trunc(sysdate-startup_time))), 60) ||’ seconds’ uptime
from
sys.v_\$instance;
EOF

}

function apagar
{
#srvctl stop database -d ${ORACLE_DB} ${ORACLE_SID} -stopoption IMMEDIATE

}

function test_status
{
srvctl status database -d ${ORACLE_DB} ${ORACLE_SID} RED=’\033[0;31m’
GREEN=’\033[0;32m’
NC=’\033[0m’
COUNT=` ps -ef |grep smon |grep -v grep | grep $ORACLE_SID|wc -l `
if [ ${COUNT} -ne 0 ]; then
printf «${RED}FAIL${NC} There are ${COUNT} smon_${ORACLE_SID} processes\n»
else
printf «${GREEN} OK ${NC} There is not any smon_${ORACLE_SID} process\n»
fi
}

export ORAENV_ASK=NO
export NODO=`hostname -a`
for i in `cat /etc/oratab |tr ‘:’ ‘ ‘ |awk ‘{ print ($1)’}|grep -v «#»|grep -v «+»|grep -v «-» |grep -v [1-9]`
do
clear
ORACLE_DB=$i
ORACLE_SID=$i
. oraenv 2>/dev/null
export ORACLE_SID=`ps -ef|grep pmon|grep $i |tr ‘_’ ‘ ‘|awk ‘{ print ($10)’}`
echo «New oracle SID=$ORACLE_SID»
estado;
#apagar
test_status;

read
echo «[press any key]»
done

[/cc]

Este script tiene una particularidad, y es que no esta pensado para usarse en RAC, para usarse en un RAC solamente habra que modificar la sintaxsis de apagado incluyendo el instance name y el nodo

Exportando las tablas de auditoria

Posted on por
Responder

Hoy vamos a volver a las entradas rapidas para dummies.

Una de las tareas que podemos tener que hacer es el respaldar las tablas de auditoria para eliminarlas posteriormente. La primera opción que nos viene a la cabeza es hacer un export (expdp), pero si lo intentamos recibiremos el error:

ORA-39166: Object SYS.AUD$ was not found.
ORA-31655: no data or metadata objects selected for job

¿Que estamos haciendo mal?
Realmente no estamos haciendo nada mal , el problema es que el nuevo expdp no nos va a dejar exportar estas tablas (asi como objetos de los esquemas SYS,SYSTEM … )

¿Como los solucionamos ?

Con un CTAS ( create table as select)

Esta es la opcion mas extendida en los foros de soporte de oracle, los pasos serian

  • CREATE TABLE MIAUDIT AS SELECT * FROM SYS.AUD$
  • TRUNCATE SYS.AUD$
  • EXPDP xxxxx table=MIAUDIT
  • DROP TABLE MIAUDIT

¿Cual es el problema de esta opcion ?
Seguramente, si neceistamos exportar y truncar la tabla de auditoria es por que ya esta ocupando demasiado espacio, por lo que la opción de duplicar este espacio en la base de datos no siempre es viable.

Usar el export clasico

Cuando la opción del CTAS no es valida, nos queda siempre el uso del exp clásico.
La herraienta antigua de exportación no tiene estas limitaciones respecto a os objetos del sistema y si que nos permitira exportar los datos

Mas información como siempre en los foros de soporte de oracle o en la nota :

  • How to Export the AUD$ Table (Doc ID 745540.1)

Borrando y añadiendo binarios al inventario

Posted on por
Responder

Hoy vamos a ver una entrada sencillisima que nos servira para mantener el oracle inventory actualizado.
En ocasiones tenemos que copiar / duplicar instalaciones de Oracle, o no tenemos mas remedio que eliminarlas «por las malas»

Estas acciones nos dejan el inventory desactualizado, para actualizarlo deberemos de desinstalar el HOME que queramos quitar, y añadir el nuevo conla utilidad $ORACLE_HOME/clone/bin/clone.pl

Borrar una instalacion del inventory 

$ORACLE_HOME/oui/bin/runInstaller -silent -detachHome ORACLE_HOME=$ORACLE_HOME

Añadirr una instalacion del inventory 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/clone/bin/clone.pl \
ORACLE_BASE=$ORACLE_BASE \
ORACLE_HOME=$ORACLE_HOME \
OSDBA_GROUP=dba  \
OSOPER_GROUP=oinstall \
-defaultHomeName

Esto nos hara todos los pasos, incluido el relincar los binarios 

Starting Oracle Universal Installer...
Checking Temp space: must be greater than 500 MB.   Actual 3247 MB    Passed
Checking swap space: must be greater than 500 MB.   Actual 1509 MB    Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2018-03-05_06-00-56AM. Please wait ...
You can find the log of this install session at:
 /u01/app/oraInventory/logs/cloneActions2017-01-13_21-00-56PM.log
..................................................   5% Done.
..................................................   10% Done.
..................................................   15% Done.
..................................................   20% Done.
..................................................   25% Done.
..................................................   30% Done.
..................................................   35% Done.
..................................................   40% Done.
..................................................   45% Done.
..................................................   50% Done.
..................................................   55% Done.
..................................................   60% Done.
..................................................   65% Done.
..................................................   70% Done.
..................................................   75% Done.
..................................................   80% Done.
..................................................   85% Done.
..........
Copy files in progress.

Copy files successful.

Link binaries in progress.

Link binaries successful.

Setup files in progress.

Setup files successful.

Setup Inventory in progress.

Setup Inventory successful.

Finish Setup successful.
The cloning of OraHome4 was successful.
Please check '/u01/app/oraInventory/logs/cloneActions2018-03-05_06-00-56AM' for more details.
Setup Oracle Base in progress.
Setup Oracle Base successful.
..................................................   95% Done.

As a root user, execute the following script(s):
        1. /u01/app/oracle/product/12.1.0.2/root.sh
..................................................   100% Done.

Mas informacion como siempre
Master Note For Cloning Oracle Database Server ORACLE_HOME’s Using the Oracle Universal Installer (OUI) (Doc ID 1154613.1)

Bloques coruptos en una base de datos

Posted on por
Responder

Uno de los problemas a los que tenemos que enfrentarnos dia a dia es el de lidiar con bloques corruptos en la base de datos.

Vayamos al supuesto en el que alguna de nuestras herramientas (RMNA,EMC,dbvf, el propio motor en algun acceso) ha detectado que tenemos estos bloques corruptos. La manera de encontarlos es mediante la vista V$DATABASE_BLOCK_CORRUPTION 

SQL> select * from V$DATABASE_BLOCK_CORRUPTION;
	 FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO
---------- ---------- ---------- ------------------ ---------
	 2      88231          1            6821577 NOLOGGING
	 2      58442          1            6821577 NOLOGGING

Recuperacion de bloques corruptos

La manera de recuperarlos es tan sencillo como decirle al RMAN que lo haga, para esto ejecutaremos el comando de rman RECOVER CORRUPTION LIST;: 
RMAN> RECOVER CORRUPTION LIST;
Starting recover at 14-JAN-18
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=206 device type=DISK
starting media recovery
media recovery complete, elapsed time: 00:00:01
Finished recover at 14-JAN-18

Comprobacion de que han sido recuperados

Aunque rman nos haya dicho OK, deberemos revisar que los bloques estan correctos, para ello usaremos la opcion VALIDATE DATAFILE de RMAN aplicado al FILE# que nos indicaba la vista de bloques corruptos 
RMAN>  validate datafile 2;

Starting validate at 14-JAN-18
using channel ORA_DISK_1
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=2 name=/u01/app/oracle/ORASID/sysaux01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01

List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    OK     0              21603        336384          41455048 

Finished validate at  14-JAN-18

Y si no lo ha solucionado?

Que ocurre si RMAN no ha podido recuperar el bloque corrupto?
En este caso el comando validate nos devolveria algo similar a 

RMAN> validate datafile 2;
Starting validate at 14-JAN-18
using channel ORA_DISK_1
channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation
input datafile file number=2 name=/u01/app/oracle/ORASID/sysaux01.dbf
channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles
=================
File Status Marked Corrupt Empty Blocks Blocks Examined High SCN
---- ------ -------------- ------------ --------------- ----------
2    OK     2              20225        99863           49937565
File Name: /u01/app/oracle/ORASID/sysaux01.dbf
Block Type Blocks Failing Blocks Processed
---------- -------------- ----------------
Data       0              26483
Index      0              24051
Other      0              29081
Finished validate at 14-JAN-18

Por que puede ser esto?
En el caso en que no resolvamos el problema, echaremos un vistazo al alert.log, 


ORA-01578: ORACLE data block corrupted (file # ORA-01578: ORACLE data block corrupted (file # 2, block # 58442)
ORA-01110: data file 2: '/u01/app/oracle/ORASID/sysaux01.dbf'
ORA-26040: Data block was loaded using the NOLOGGING option

Lo que nos esta indicando este error es que el objeto se creo en modo nologging por lo que la base de datos no tiene informacion de como recuperarla, si queremos recuperar esta informacion deberemos de recrear el objeto ( y cruzar los dedos para que este objeto sea un indice y no datos de negocio)

COmo siempre podemos encontrar mas informacion al respecto en soporte Oracle en las notas:

  • How to identify the corrupt Object reported by ORA-1578 / RMAN / DBVERIFY (Doc ID 819533.1)
  • ORA-1578 / ORA-26040 Corrupt blocks by NOLOGGING - Error explanation and solution (Doc ID 794505.1)
  • How to identify all the Corrupted Objects in the Database with RMAN (Doc ID 472231.1)