Vuelta tras de una base de datos a una fecha con rman

Posted on 24 febrero, 2015 por admin

Revisando las entradas de RMAN veo que nos falta una entrada para el caso mas común y mas sencillo de todos, volver la base de datos a una determinada fecha.
La manera mas cómoda de hacer esto desde la versión 11g es hacerlo con un flashback database pero, por si no pudiese hacerse, vamos a explicar la recuperación mas sencilla que hay.

Supuesto

Nos encontramos en el caso en el que no hemos perdido nada en la base de datos pero debemos de hacer una marcha atrás en el tiempo de la base de datos a un momento anterior a 7 días(o la etencion del backup del controlfile).
En este caso disponemos en el servidor de todos los elementos de la base de datos ( passwd,spfile,controlfile….) pero los datos no no son válidos.

Pasos previos

En este caso y para garantizar que si fallamos en el proceso podemos repetirlo guardaremos el controlfile.
Este paso es de suma importancia ya que, al no tener base de datos de catálogo de RMAN si perdiésemos el controlfile perderíamos toda la información del RMAN
Para ello haremos dos acciones:

Copia del controlfile a texto

alter database backup controlfile to  trace as ‘….\CONTROLFILE.TXT’;

Copia física del controlfile

Como decíamos anteriormente, el controlfile el único elemento de la base de datos en el que mantenemos la información de donde esta el catálogo de rman, así que, pararemos la base de datos y copiaremos los 3 controlfiles desde su ubicación en los discos a un directorio dedicado creado para esta copia
El contenido de los 3 controlfiles es exactamente el mismo, con lo que, al copiar los 3 estamos haciendo 3 backups

Recuperacion

Una vez hemos guardado nuestros controlfiles para tener las espaldas cubiertas, procederemos a recuperar la base de datos a el momento en que queremos.
Para ello, crearemos un script de rman llamado recuperacion.cmd con el contenido :

startup mount;
RUN {
SET until time="TO_DATE('23/02/15 21:00:00','DD/MM/YY hh24:mi:ss')";
allocate channel DEV0 type SBT_TAPE PARMS 'ENV=(XXXXXXXXXXXXXXX)';
restore database;
recover database;
 }

Donde ENV=(XXXXXXXXXXXXXXXXXX) dependerá de la integración de backup que se use.
Y lo ejecutaremos con el comando

ORACLE_SID=XXX
rman cmdfile restauracion.cmd log=estado_restauracion.log

Apertura

Al estar haciendo una recuperación de la base de datos incompleta deberemos de abrir la base de datos en modo resetlogs, para ello, desde la línea de comandos

 ORACLE_SID=XXX
Sqlplus “/as sysdba”
ALTER DATABASE OPEN RESETLOGS;

Y con esto tendremos la base de datos recuperada a la fecha que buscábamos.
Como veis, al no tener que conocer DBIDs, ni recuperar controlfiles u spfiles, el

Funcionamiento del Redo en el RAC

Posted on 22 febrero, 2015 por admin

Hoy vamos con otra de las entradas para dummies, viendo un poco el funcionamiento del redo en el RAC.
Cada instancia dentro del RAC debe de tener su propio espacio de redo (que se corresponderá con un número único de thread para toda la instancia) y undo.

Pero que ocurre si muere un nodo?
¿Que pasa con los datos que están en esos redos?

En un entorno de RAC, todas las instancias de la base de datos tienen acceso a todos los redo logs de todos los nodos, de esta manera, si uno de los nodos muere, uno de los nodos vivos accederá a el redo de la instancia caída y aplicará de manera automática los cambios de la misma manera que se haría un instance recovery a la hora de arrancar la base de datos. Con lo que los datos en disco siempre estarán consistentes.

¿Que ocurre si caen todos a la vez?
Si todas las instancias cayeran el instance recovery sería llevado a cabo por la primera de las instancias que se levantara, esta sería la encargad de hacer el instance recovery de todos los redos de todas las instancias del rac.

Como veis, a pesar de la complejidad del RAC, el funcionamiento no deja de ser muy sencillo, al menos, visto desde arriba 😉

Purgando diag con adrci

Posted on 19 febrero, 2015 por admin

Hoy vamos a ver una entrada sencillita en la que haremos un bash-script que nos limpie de manera ordenada el contenido del diag

El comando ADRCi permite la ejecución de comandos batch bien sea mediante la cláusula exec o bien contenidos en un fichero de texto separados por punto y coma.
Lo que vamos ha hacer es ejecutar para cada uno de los homes del la base de datos, asm y listener, el comando purge para cada uno de los tipos de elementos que guarda el diagnostics_dest

En nuestro caso, usaremos el modo script pero podíamos haber puesto todos los comandos en una línea separada por puntos y coma y el funcionamiento sería el mismo.

El script que vacia el diagnostics_dest para todo lo anterior a X días es:

#!/bin/bash
#
# Script que purga del ADRCLI  para  $1 DIAS
#
#
#
#
export ORAENV_ASK=NO
. oraenv  1>/dev/null
# Salida de debug
DEBUG=0

 #Comprobamos que se ha llamado de manera correcta
if  [ $# -ne 1 ]; then
echo "Uso Purgar_logs DIAS "
exit 3;
fi

# Inicializamos valores para el script
export TEMPORAL=/var/tmp/purgar_temporal_$$.log
export DIAS=$(($1*1440))

## Comenzamos la ejecucion
if [ $DEBUG -eq 1 ]; then
        echo "DEBUG: ORACLE_BASE=$ORACLE_BASE"
        echo "DEBUG: TEMPORAL= ${TEMPORAL} "
        echo "DEBUG: Dias= $2   en min $DIAS"
fi
# Comenzamos las iteraciones
adrci_homes=( $(adrci exec="show homes" | grep -e rdbms -e asm -e tnslsnr))
   for adrci_home in ${adrci_homes[@]}
   do
          #Generamos el fichero de comandos
         echo "set home ${adrci_home} ;" > ${TEMPORAL}
         echo "echo \"Purgamos en  ${adrci_home} \""  >> ${TEMPORAL}
         echo "purge -age ${DIAS} -type ALERT ;" >> ${TEMPORAL}
         echo "purge -age ${DIAS} -type TRACE ;" >> ${TEMPORAL}
         echo "purge -age ${DIAS} -type INCIDENT ;" >> ${TEMPORAL}
         echo "purge -age ${DIAS} -type HM ;" >> ${TEMPORAL}
         echo "purge -age ${DIAS} -type  utscdmp;" >> ${TEMPORAL}
         echo "purge -age ${DIAS} -type  cdump;" >> ${TEMPORAL}
         echo "exit; " >> ${TEMPORAL}

       if [ $DEBUG -eq 1 ]; then
        echo "DEBUG: "
        echo "DEBUG:  adrci SCRIPT=${TEMPORAL}"
        echo "DEBUG: EL etemporal es "
        echo "DEBUG: -inicio temporal-"
         cat ${TEMPORAL}
         echo "DEBUG: -fin temporal-"
        fi
        adrci  SCRIPT=${TEMPORAL}
         rm ${TEMPORAL}
    done #Fin del bucle

Como véis, es extremadamente sencillo, y bastante mas limpio que hacer el borrado a mano

Limpiando kernels antiguos (vaciar /boot)

Posted on 17 febrero, 2015 por admin

Hoy vamos a ver una entrada muy rápida sobre como vaciar el /boot en Oracle Linux.

A medida que vamos actualizando nuestro servidor puede darse el caso de que tengamos varias versiones antiguas del kernel y se nos llene la particion dedicada /boot
Como solucionamos esto?
Con una utilidad muy sencilla llamada package-cleanup

Si queremos mantener 2 kernels en el /boot solo habremos de ejeutar

[root@server ~]#  package-cleanup --oldkernels --count=2
--> Running transaction check
---> Package kernel.x86_64 0:2.6.32-504.1.3.el6 will be erased
--> Finished Dependency Resolution

Dependencies Resolved
.
.

Remove        1 Package(s)

Installed size: 124 M
Is this ok [y/N]: Y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Erasing    : kernel-2.6.32-504.1.3.el6.x86_64                                                                                                                                                                                          1/1
  Verifying  : kernel-2.6.32-504.1.3.el6.x86_64                                                                                                                                                                                          1/1

Removed:
  kernel.x86_64 0:2.6.32-504.1.3.el6

Complete!

Como véis, rápido y sencillo

Indices sin uso en SQLserver

Posted on 2 febrero, 2015 por admin

Hoy vamos a ver una entrada referente a SQLserver.

Habitualmente cuando se habla de ajuste de índices todos tendemos a pensar en la creación de los mismos, sin embargo,la revisión del uso de los índices y la eliminación de los índices que no se usan es una tarea de administración muy recomendable, tanto por el aprovechamiento del espacio en disco como por la mejora que conlleva sobre la entrada salida (recordemos que cada inserción en una tabla indexada conlleva la actualización de los índices asociados).

SQLServer tiene desde la versión 2005 una tabla llamada SYS.DM_DB_INDEX_USAGE_STATS en la cual podemos hacer un seguimiento del uso de los indices de las bases de datos.

Los campos con los que nos quedaremos de esta tabla son

user_seeks: Número de consultas de búsqueda realizadas por el usuario.
user_scans: Número de consultas de recorrido realizadas por el usuario.
user_lookups: Número de búsquedas de marcadores realizadas por consultas de usuario.
user_updates: Número de consultas de actualización realizadas por el usuario.

Así pues, lo que debemos de buscar son índices sobre los que no hayamos hecho seeks,scans o lookups.
Esto lo podemos hacer con la consulta:

SELECT OBJECT_NAME(S.[OBJECT_ID]) AS [OBJECT NAME],
I.[NAME] AS [INDEX NAME],
USER_SEEKS,
USER_SCANS,
USER_LOOKUPS,
USER_UPDATES
FROM SYS.DM_DB_INDEX_USAGE_STATS AS S
INNER JOIN SYS.INDEXES AS I ON I.[OBJECT_ID] = S.[OBJECT_ID] AND I.INDEX_ID = S.INDEX_ID
WHERE OBJECTPROPERTY(S.[OBJECT_ID],’IsUserTable’) = 1
AND S.database_id = DB_ID()
AND user_seeks=0
AND user_scans=0
AND user_lookups=0
ORDER by user_updates DESC;
GO

Esta consulta nos devuelve algo similar a :

Donde podemos ver como hay índices que se encuentran sobre tablas muy actualizadas ( valor de user_updates muy alto) pero que no tienen uso en búsquedas, y otros que se encuentran sobre tablas que ni siquiera se actualizan.

Ahora nuestro trabajo es explorar esas tablas y ver si estos índices tienen sentido para, en caso de no tenerlo eliminarlos del sistema.

Dba stuff

Un cajon desastre para el día a día

Archivo por meses: febrero 2015