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

Actualizar bases de datos antiguas antes de Junio de 2019

Hoy vamos a ver una entrada de la que no me puedo atribuir ningun merito, ya que , practiccamente es una traduccion + recopilacion de las URL’s en ingles que os adjunto al final como documentacion adicional.

Tal y como indica Mike Dietrich DEBEMOS parchear las bases de datos que tengamos en version 12.1.0.1, 11.2.0.3 y anteriores antes del 23 de Junio de 2019 .

¿Por que ?

En la nota de oracle MOS Note: 2335265.1 nos explican que, estas versiones de bases de datos están afectadas por un especie de Efecto 2000 en la manera en la que la base de datos calcula el SCN.
Un problema que incrementa la criticada del parcheado es que, este bug afecta a los DBlinks , por lo que no solamente puede causar problemas en nuestras bases de de datos afectadas, sino que, si esta esta conectada a una nueva aunque no este afectada provocara que nuestra obtención de datos falle.

Como indicaba al principio, podemos encontrar este caso muy bien explicado en el blog de Job Oprel, pero, en cualquier caso , es muy conveniente el llevar a cabo la comprobación de hasta que punto estamos afectados en todas las bases de datos que tengamos dentro de las versiones mencionadas.

La consulta a ejecutar es

set pagesize 200;
set linesize 200;
column  OWNER format a30;
column  USERNAME format a30;
column DB_LINK format a20;
col HOST format a40;
col created format a20;

select * from DBA_DB_LINKS;

SELECT NAME,  
   (current_scn/281474976710656)*100 as PCT_OF_SCN_KEYSPACE_USED,  
   ROUND(SYSDATE-CREATED) as DAYS_SINCE_DB_CREATION, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)) 
        AS EST_DAYS_BEFORE_SCN_EXHAUSTED, 
   ROUND(1/(current_scn/281474976710656)*(SYSDATE-CREATED)/365) 
        AS EST_YEARS_BEFORE_SCN_EXHAUSTED  
FROM v$database;

La fuente de esta informacion donde se pude ver el analisis completo es

Usando los bloques logicos en ASM

Hoy vamos a ver una entrada que nos puede causar grandes dolores de cabeza .

Uno de los problemas con los que nos podemos encontrar cuando se modifica la tecnología de los discos físicos utilizados en el ASM es el cambio del tamaño de bloque lógico.

Supongamos que nos ofrecen un nuevo disco /dev/xvdz

Nosotros intentamos añadirlo al ASM, pero recibimos un error ORA-01378

Errors in file /u01/app/oracle/diag/rdbms/test/TEST/trace/TEST_ora_40862.trc:
ORA-01378: The logical block size (512) of file +REDO is not compatible with the disk sector size 
(media sector size is 4096 and host sector size is 4096)

Veamos las características de este disco

sudo fdisk -l /dev/xvdz
Disk /dev/xvdd: 21.5 GB, 21474836480 bytes
255 heads, 63 sectors/track, 2610 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

Y veamos ahora otro de los discos que tenemos

The other disks  have sector size 512
Disk /dev/xvdp: 2147.5 GB, 2147483648000 bytes
255 heads, 63 sectors/track, 261083 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Si nos fijamos, el problema que tenemos es que el sector size de nuestro nuevo disco es 8 veces mayor que el del disco viejo (521 / 4096) .

Como solucionamos ahora nuestro problema?

Tal y como indican el el blog flashdba ASM tiene un parámetro en el fichero de configuración llamado ORACLEASM_USE_LOGICAL_BLOCK_SIZE que por defecto esta a false, que era el parámetro por defecto de oracleasm-support-2.1.8.
Podemos ver su valor en el fichero /etc/sysconfig/oracleasm

# ORACLEASM_USE_LOGICAL_BLOCK_SIZE: 'true' means use the logical block size
# reported by the underlying disk instead of the physical. The default
# is 'false'
ORACLEASM_USE_LOGICAL_BLOCK_SIZE=false

Lo que vamos ha hacer es modificarlo a TRUE, de manera que el ASM sea capaz de usar los bloques de manera lógica y no se aferre a la configuración física de los mismos, esto lo hacemos con el script
oracleasm-configure.sh

  • -b|—logical-blocks sets logical blocksize usage
  • -p|—physical-blocks set physical blocksize usage

Veamos ahora cual es la información que nos dará nuestro ASM

[oracle@testserver ~]$ sysasm
 SQL> select NAME,SECTOR_SIZE,BLOCK_SIZE,DATABASE_COMPATIBILITY,COMPATIBILITY,((TOTAL_MB-FREE_MB)*100/TOTAL_MB) PERCENT_USED from v$asm_diskgroup;

NAME         SECTOR_SIZE BLOCK_SIZE DATABASE_COMPATIBILI COMPATIBILITY        PERCENT_USED
-------------------- --------- ---------- -------------------- -------------------- ------------
REDO               4096       4096 10.1.0.0.0           10.1.0.0.0             .249023438
FRA                 512       4096 10.1.0.0.0           12.1.0.0.0             44.1858724
DATA                512       4096 11.2.0.0.0           11.2.0.0.0             90.4637587

Como podeis ver, es un problema que se nos puede dar en bases de datos con ASM antiguos en los que llevemos a cabo un cambio de tecnología física.

Mas informacion en

Oracle ASMLib: Physical and Logical Blocksize

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

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: