Vamos a ver una entrada de esas para guardar en el bookmark
Vamos a volver a las entradas recopilatorias para dummies.
Hoy vamos a ver unas consultas realmente utiles en el uso diario de rman , con ellas, podremos saber cual es el estado de nuestra recuperacion y pode restimar el tiempo que queda.
Lo que vamos ha hacer es comprobar el tiemo que nos indica la propia base de datos en v$session_longops, para ello podemos usar estas dos consultas
-- Tiempo que le queda al rman para recuperar col OPNAME for a30 select OPNAME,SOFAR/TOTALWORK*100 PCT, trunc(TIME_REMAINING/60) MIN_RESTANTES, trunc(ELAPSED_SECONDS/60) MIN_ATEAGORA from v$session_longops where TOTALWORK>0 and OPNAME like '%RMAN%';
O afinar un poco mas si lo que buscamos son los restores
--estimacion de los restores select OPNAME,SOFAR/TOTALWORK*100 PCT, trunc(TIME_REMAINING/60) MIN_RESTANTES, trunc(ELAPSED_SECONDS/60) MIN_ATEAGORA from v$session_longops where TOTALWORK>0 and OPNAME like '%RMAN: full datafile restore%';
Otra consulta que nos puede resultar muy util es el saber cuales de nuestros ficheros necesitan recuperacion
-- Info mas detallada de los ficheros y tablespaces de v$recover_file COL DF# FORMAT 999 COL DF_NAME FORMAT A70 COL TBSP_NAME FORMAT A15 COL STATUS FORMAT A7 COL ERROR FORMAT A20 COL CHANGE# FORMAT 999999999999999999 SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, d.STATUS, r.ERROR, r.CHANGE#, r.TIME FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t WHERE t.TS# = d.TS# AND d.FILE# = r.FILE# ;
Como siempre, podemos encontrar mas informacion en :
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
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
Cuando estamos en la version 12c, tendremos dos maneras de encontrar esta informacion:
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)
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:
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
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