Errores Heap size XX exceeds notification threshold

Hoy vamos a volver con las entradas para dummies

Uno de las alertas con las que podemos encontrarnos en el fichero de log es :

2019-08-25T21:51:19.646997+01:00
PDB$SEED(2):Memory Notification: Library Cache Object loaded into SGA
Heap size 52942K exceeds notification threshold (51200K)
Details in trace file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_32087.trc
2019-08-25T21:51:19.647135+01:00
PDB$SEED(2):KGL object name :grant read on ku$_m_view_piot_view to public
2019-08-25T21:51:33.513723+01:00
PDB$SEED(2):Memory Notification: Library Cache Object loaded into SGA
Heap size 52903K exceeds notification threshold (51200K)
Details in trace file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_32087.trc
2019-08-25T21:51:33.513818+01:00
PDB$SEED(2):KGL object name :grant read on ku$_zm_view_piot_view to public

A pesar del susto que nos puede dar esta alerta , no se trata de un error, sino de un warning. A partir de la version 10g oracle introdujo un umbral a partir del cual nos avisa cuando superamos ese umbral en la carga de objetos en el shared pool .
Este umbral viene definido por el parametro oculto _kgl_large_heap_warning_threshold

Si queremos saber el valor actual de este valor podemos ejecutar la consulta

[code lang=»sql»]
select
nam.ksppinm NAME,
nam.ksppdesc DESCRIPTION,
val.KSPPSTVL
from
x$ksppi nam,
x$ksppsv val
where nam.indx = val.indx and nam.ksppinm like ‘%kgl_large_heap_%_threshold%’;
[/code]

En caso de que quieresemos que dejasen de apareer alertas (especialmente por que vienen asociadas a una traza ) podemos modificar el parametro con :

 alter system set "_kgl_large_heap_warning_threshold"=XXXXXX   comment='motivo aqui ' scope=spfile;

Como podeis ver, hemos de acutalizar en el spfile por lo que habra que reiniciar la base de datos si quremos que haga efecto

Como siempre podemos tener mas informacion en la nota de soporte KGL-heap-size-exceeded] (Doc ID 330239.1)

Creando una base de datos en modo silent

Hoy vamos a ver otra de estas entradas para dummies que nos ahorraran mucho trabajo.
Vamos a cer el contenido de un sell scritp . En nuestro caso la queremos en ASM y los nombres de los diskgroups no son los estabdares de DATA,REDO y FRA, sino que llevan el nombre del HOSTNAME delante.

Asi pues, nuestro script sera algo similar a

[bash]

#!/bin/bash
export ORACLE_SID=$1
HOST=`hostname -a`
export ORACLE_HOSTNAME=${HOST^^}
export ORA_INVENTORY=`cat /etc/oraInst.loc |grep inventory_loc |tr "=" " " |awk ‘{print $2}’`

dbca -silent -createDatabase \
-templateName General_Purpose.dbc \
-gdbname ${ORACLE_SID} -sid ${ORACLE_SID} -responseFile NO_VALUE \
-sysPassword SysPassword1 \
-systemPassword SysPassword1 \
-characterSet WE8ISO8859P1 \
-nationalCharacterSet AL16UTF16 \
-createAsContainerDatabase false \
-automaticMemoryManagement false \
-databaseType MULTIPURPOSE \
-automaticMemoryManagement false \
-storageType ASM \
-datafileDestination +${ORACLE_HOSTNAME}_DATA \
-totalMemory 2048 \
-redoLogFileSize 521 \
-emConfiguration NONE \
-initParams "control_file_record_keep_time=30, control_files=+${ORACLE_HOSTNAME}_DATA’, control_files=+${ORACLE_HOSTNAME}_FRA, db_create_file_dest=+${ORACLE_HOSTNAME}_DATA, db_create_online_log_dest_1=+${ORACLE_HOSTNAME}_REDO1,db_create_online_log_dest_2=+${ORACLE_HOSTNAME}_REDO2,db_recovery_file_dest=+${ORACLE_HOSTNAME}_FRA, db_recovery_file_dest_size=90G , recyclebin=’OFF’ ,sessions=300,proceses=150" \
-ignorePreReqs
[/bash]

DIA-49803: Purge not possible due to incompatible schema version.

Hoy vamos a ver una sencilla entrada que tiene que ver con el adrci ( Interprete de comandos ADR ).
El otro dia me encontre con que algunos de los automatismos de limpieza de logs fallaban con el eror DIA-49803: Purge not possible due to incompatible schema version

[oracle@testserver ~]$ adrci
ADRCI: Release 12.1.0.2.0 - Production on Thu Mar 16 09:34:45 2019
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
ADR base = "/u01/app/oracle/admin"
adrci> show homes
ADR Homes: 
diag/rdbms/test1/TEST1
diag/rdbms/test2/TEST2
adrci> purge -age 180 -type alert   
DIA-49803: Purge not possible due to incompatible schema version.

A que puede deberse esto ?
Si miramos en la documentacion de soporte de Oracle nos encontramos con algunos poibles bugs , como el bug Bug 27718599 o un efecto secundario del bug 28375106.
Pero, antes de meterse en berenjenales, lo mas sencillo es intentar migrar la version de los logs.

Como lo hacemos?

Algo tan sencillo como

adrci> migrate schema
Schema migrated.

Tras la ejecucion de este sencillo comando, veremos como nuestros comandos vuelven a funcionar correctamente

Comprobar el estado de una operacion rman

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 :

Sqltunning desde sqlplus

Vamos a volver a la entradas para dummies con un error muy comun.

Uno de los errores mas frecuentes que tenemos desde el enterprise manager es cuando intentamos lanzar el SQL Tuning Advisor sobre una consuta pesada y obtenemos el error

ORA-01555 caused by SQL statement below (SQL ID: g5wg4kxu9m4g3, Query Duration=14163 sec, SCN: 0x09a1.42a95c42):

Este error no nos lo esta dando el advisor en si, sino que es un error del enterprise manager, para poder obtener este advice lo haremos de la siguiente manera

Supongamos que buscamos llevarlo a cabo sobre la SQLID g5wg4kxu9m4g3 y que tenemos identificada esta consulta entre dos snapshots, los 73485 & 73486

Los pasos que debemos de seguir son :

Definimos la tarea


begin_snap  => 73485,
end_snap    =>73486,
sqlidf => g5wg4kxu9m4g3

--create task 
DECLARE
l_sql_tune_task_id  VARCHAR2(100);
BEGIN
l_sql_tune_task_id := DBMS_SQLTUNE.create_tuning_task (
sql_id=> 'g5wg4kxu9m4g3',
time_limit=> 1500,
task_name=> 'g5wg4kxu9m4g3_tuning_task',
description=> 'Tuning task for statement g5wg4kxu9m4g3',
scope    => DBMS_SQLTUNE.scope_comprehensive
);
   
  DBMS_OUTPUT.put_line('l_sql_tune_task_id: ' || l_sql_tune_task_id);
END;
/

Ejecutamos la tarea

EXEC DBMS_SQLTUNE.execute_tuning_task(task_name => 'g5wg4kxu9m4g3_tuning_task');

Obtenemos el resultado

set pagesize 999
set long 65536
set longchunksize 65536
set linesize 200
select dbms_sqltune.report_tuning_task('g5wg4kxu9m4g3_tuning_task') from dual;

Como podemos ver, el uso basico del paquete DBMS_SQLTUNE es extremadamente sencillo