Está en la página 1de 8

MANEJO ORACLE TUNING

Una de las mayores responsabilidades de un DBA es garantizar que la base de datos de Oracle se sintoniza
correctamente. El RDBMS de Oracle es altamente tuneable y permite que la base de datos para ser monitoreados y
regulados para optimizar y aumentar su rendimiento.

¿QUE GANAMOS AL TUNEAR?

 Mejorar el tiempo de respuesta de la base de datos.


 Disponibilidad de servicio de la base de datos.
 Mejorar el uso de la memoria.
 Mejorar de porcentaje de hits.
 Pocas esperas de los recursos (waits).

¿QUÉ PODEMOS OPTIMIZAR?

 Sentencias SQL y PL/SQL.


 Diseño lógico de la base de datos.
 Diseño físico de la base de datos.
 Parámetros de la base de datos.
 Sistema operativo y hardware.

¿QUÉ MECANISMOS PODEMOS REALIZAR PARA HACER UN : AUTOMATIC SQL TUNING ?.

Se puede realizar AUTOMATIC SQL TUNING usando:

 SQL TUNING ADVISOR


 SQL ACCESS ADVISOR

DUMMY #1:

En esta oportunidad mostrare el manejo del: SQL TUNING ADVISOR, desde la creación de las tablas hasta el de
los QUERYs y DECLARE que brindan el soporte al Tuning respectivo.

-- ================================================= --
-- CREAR TABLAS, INSERTs Y CONSTRAINTs PARA EL DUMMY --
-- ================================================= --

CREATE TABLE TB_OS(


COD_OS INTEGER NOT NULL,
COD_SIST_ORI VARCHAR2(4),
COD_EST_OS VARCHAR2(2),
COD_PED VARCHAR2(10),
FEC_INI_OS DATE,
FEC_FIN_OS DATE,
FEC_EJEC_OS DATE,
FEC_LIQUI_OS DATE
);

CREATE TABLE TB_OT(


COD_OT INTEGER NOT NULL,
COD_SIST_ORI VARCHAR2(4),
FEC_INI_OT DATE,
FEC_LIQUI_OT DATE,
FEC_EJEC_OT DATE,
COD_OS INTEGER NOT NULL
);

CREATE TABLE TB_OR(


COD_OR INTEGER NOT NULL,
COD_EST_OR VARCHAR2(2),
FEC_INI_OR DATE,
FEC_EJEC_OR DATE,
FEC_LIQUI_OR DATE,
COD_FLU INTEGER NOT NULL,
COD_OT INTEGER NOT NULL
);

ALTER TABLE TB_OS


ADD CONSTRAINT PK_OS PRIMARY KEY( COD_OS );

ALTER TABLE TB_OT


ADD CONSTRAINT PK_OT PRIMARY KEY( COD_OT );

ALTER TABLE TB_OR


ADD CONSTRAINT PK_OR PRIMARY KEY( COD_OR );

ALTER TABLE TB_OT


ADD CONSTRAINT FK_OT_OS FOREIGN KEY( COD_OS )
REFERENCES TB_OS( COD_OS );

ALTER TABLE TB_OR


ADD CONSTRAINT FK_OR_OT FOREIGN KEY( COD_OT )
REFERENCES TB_OT( COD_OT );

INSERT INTO TB_OS (COD_OS, COD_SIST_ORI, COD_EST_OS, COD_PED, FEC_INI_OS, FEC_FIN_OS,


FEC_EJEC_OS, FEC_LIQUI_OS)
VALUES (1, '1', '1', '1', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-
YYYY'), TO_DATE('12-03-2012', 'DD-MM-YYYY'), TO_DATE('13-03-2012', 'DD-MM-YYYY'));

INSERT INTO TB_OT (COD_OT, COD_SIST_ORI, FEC_INI_OT, FEC_LIQUI_OT, FEC_EJEC_OT, COD_OS)


VALUES (1, '4', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-YYYY'),
TO_DATE('12-03-2012', 'DD-MM-YYYY'), 1);
INSERT INTO TB_OT (COD_OT, COD_SIST_ORI, FEC_INI_OT, FEC_LIQUI_OT, FEC_EJEC_OT, COD_OS)
VALUES (2, '5', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-YYYY'),
TO_DATE('13-03-2012', 'DD-MM-YYYY'), 1);

INSERT INTO TB_OR (COD_OR, COD_EST_OR, FEC_INI_OR, FEC_EJEC_OR, FEC_LIQUI_OR, COD_FLU, COD_OT)
VALUES (1, '1', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-YYYY'),
TO_DATE('16-03-2012', 'DD-MM-YYYY'), 2, 1);
INSERT INTO TB_OR (COD_OR, COD_EST_OR, FEC_INI_OR, FEC_EJEC_OR, FEC_LIQUI_OR, COD_FLU, COD_OT)
VALUES (2, '1', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-YYYY'),
TO_DATE('16-03-2012', 'DD-MM-YYYY'), 2, 2);
INSERT INTO TB_OR (COD_OR, COD_EST_OR, FEC_INI_OR, FEC_EJEC_OR, FEC_LIQUI_OR, COD_FLU, COD_OT)
VALUES (3, '1', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-YYYY'),
TO_DATE('16-03-2012', 'DD-MM-YYYY'), 4, 1);
INSERT INTO TB_OR (COD_OR, COD_EST_OR, FEC_INI_OR, FEC_EJEC_OR, FEC_LIQUI_OR, COD_FLU, COD_OT)
VALUES (4, '1', TO_DATE('13-03-2012', 'DD-MM-YYYY'), TO_DATE('14-03-2012', 'DD-MM-YYYY'),
TO_DATE('16-03-2012', 'DD-MM-YYYY'), 3, 2);

-- ========================== --
-- CREAR LA [TAREA DE TUNING] --
-- ========================== --

DECLARE
TAREA_TUNING VARCHAR2( 30 );
SQL_QUERY CLOB;
BEGIN
SQL_QUERY := 'SELECT OS.COD_OS, OS.COD_SIST_ORI, OS.FEC_INI_OS,
OT.COD_OT,
OX.COD_OR, OX.COD_EST_OR, OX.COD_FLU
FROM RGUERRA.TB_OS OS,
RGUERRA.TB_OT OT,
RGUERRA.TB_OR OX
WHERE OS.COD_OS = OT.COD_OS
AND OT.COD_OT = OX.COD_OT';

/*
SQL_QUERY := 'SELECT OS.COD_OS, OS.COD_SIST_ORI, OS.FEC_INI_OS,
OT.COD_OT,
OX.COD_OR, OX.COD_EST_OR, OX.COD_FLU
FROM RGUERRA.TB_OS OS INNER JOIN RGUERRA.TB_OT OT
ON OS.COD_OS = OT.COD_OS INNER JOIN RGUERRA.TB_OR OX
ON OT.COD_OT = OX.COD_OT'; */

TAREA_TUNING := DBMS_SQLTUNE.CREATE_TUNING_TASK( SQL_TEXT => SQL_QUERY,


USER_NAME => USER,
SCOPE => 'COMPREHENSIVE', --[LIMITED o COMPREHENSIVE]
TIME_LIMIT => 60,
TASK_NAME => 'QUERY_01',
DESCRIPTION => 'DUMMY DE MANEJO DE [TAREA DE TUNING]' );
END;

-- ============================================== --
-- VERIFICAR QUE LA [TAREA DE TUNING] ESTE CREADA --
-- ============================================== --

SELECT X.TASK_NAME
FROM DBA_ADVISOR_LOG X
WHERE X.OWNER = USER;

-- ==================================== --
-- EJECUTAR LA [TAREA DE TUNING] CREADA --
-- ==================================== --

BEGIN
DBMS_SQLTUNE.EXECUTE_TUNING_TASK( TASK_NAME => 'QUERY_01' );
END;
-- =========================================== --
-- CONTROLAR EL ESTADO DE LA [TAREA DE TUNING] --
-- =========================================== --

SELECT X.TASK_ID, X.TASK_NAME, X.ADVISOR_NAME, X.CREATED, X.STATUS


FROM USER_ADVISOR_TASKS X
WHERE X.TASK_NAME = 'QUERY_01';

-- ============================================== --
-- CONTROLAR EL PROGRESO DEL [SQL TUNING ADVISOR] --
-- ============================================== --

SELECT X.SOFAR, X.TOTALWORK, X.ADVISOR_NAME, X.TASK_ID


FROM v$ADVISOR_PROGRESS X
WHERE X.TASK_ID = ( SELECT W.TASK_ID
FROM USER_ADVISOR_TASKS W
WHERE W.TASK_NAME = 'QUERY_01' );

-- ============================================= --
-- MOSTRAR EL RESULTADO DEL [SQL TUNING ADVISOR] --
-- ============================================= --

SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'QUERY_01') AS "REPORTE TUNING" FROM DUAL;

SELECT DBMS_ADVISOR.GET_TASK_REPORT( 'QUERY_01' ) AS "REPORTE TUNING" FROM DUAL;


-- ==================================== --
-- ELIMINAR LA [TAREA DE TUNING] CREADA --
-- ==================================== --

BEGIN
DBMS_SQLTUNE.DROP_TUNING_TASK( 'QUERY_01' );
END;

DUMMY #2:
En este DUMMY mostrare la diferencia al desarrollar QUERYs: CON y SIN INDICES, mediante un análisis por medio de: EXPLAIN PLAN
TOOL.

Creamos la TABLA y generamos los INSERTs respectivos (100000 registros):

--CREACION:
CREATE TABLE TB_DUMMY_TEST AS
SELECT (LEVEL) AS ID_TEST,
DECODE( MOD( LEVEL, 2 ),
0, 'A', --PAR
1, 'B', --IMPAR
'C'
) AS "ESTADO_TEST",
'DUMMY_' || LEVEL AS DESC_TEST
FROM DUAL
CONNECT BY LEVEL <= 100000

--ELIMINACION:
DROP TABLE TB_DUMMY_TEST;

--CONSULTA:
SELECT * FROM TB_DUMMY_TEST;
Mediante la herramienta PL/SQL DEVELOPER accedermos a la vista de EXPLAIN PLAN:

PRUEBA #1 (SIN APLICACIÓN DE INDICES): Ejecutaros un QUERY que lo FILTRAREMOS mediante 2 variables de tipo
BIND que representan a cualquier posible variable a reemplazar.

SELECT X.ID_TEST, X.ESTADO_TEST, X.DESC_TEST


FROM TB_DUMMY_TEST X
WHERE X.ESTADO_TEST = :BIND_01
AND X.DESC_TEST = :BIND_02;
ANALIZANDO EL RESULTADO OBTENIDO:

- DESCRIPTION: TABLE ACCES FULL


- OBJECT NAME: TB_DUMMY_TEST
- COST: 101 (MUCHO)
- CARDINALIDAD: 10
- BYSTES: 400 (MUCHO)

PRUEBA #2 (SIN APLICACIÓN DE INDICES): Ejecutaros un QUERY que lo FILTRAREMOS mediante 2 parámetros de
búsqueda.

SELECT X.ID_TEST, X.ESTADO_TEST, X.DESC_TEST


FROM TB_DUMMY_TEST X
WHERE X.ESTADO_TEST = 'A'
AND X.DESC_TEST = 'DUMMY_8000';

ANALIZANDO EL RESULTADO OBTENIDO:

- DESCRIPTION: TABLE ACCES FULL


- OBJECT NAME: TB_DUMMY_TEST
- COST: 101 (MUCHO)
- CARDINALIDAD: 10
- BYSTES: 400 (MUCHO)
IMPORTANTE: El RESULTADO al ejecutar el QUERY con PARAMETROS FIJOS y con VARIABLES BIND, NO siempre es el
mismo, así que uno NO DEBE CONFIAR.

Ahora PROBAREMOS los QUERYs anteriores pero antes le CREAMOS y asignaremos un INDEX para mejorar y optimizar los
FILTROS en base a los dos parámetros de tipo VARCHAR2.

--INDICES:
CREATE UNIQUE INDEX UQ_DUMMY ON TB_DUMMY_TEST( ESTADO_TEST, DESC_TEST );

PRUEBA #3 (CON APLICACIÓN DE INDICES): Ejecutaros el mismo QUERY de la PRUEBA #1, FILTRANDOLO mediante 2
variables de tipo BIND que representan a cualquier posible variable a reemplazar.

SELECT X.ID_TEST, X.ESTADO_TEST, X.DESC_TEST


FROM TB_DUMMY_TEST X
WHERE X.ESTADO_TEST = :BIND_01
AND X.DESC_TEST = :BIND_02;

ANALIZANDO EL RESULTADO OBTENIDO:

- DESCRIPTION: TABLE ACCES BY INDEX ROWID


- OBJECT NAME: UQ_DUMMY
- COST: 2 (OK)
- CARDINALIDAD: 1
- BYSTES: 40 (OK)

PRUEBA #4 (CON APLICACIÓN DE INDICES): Ejecutaros el mismo QUERY de la PRUEBA #2, FILTRANDOLO mediante 2
parámetros fijos.

SELECT X.ID_TEST, X.ESTADO_TEST, X.DESC_TEST


FROM TB_DUMMY_TEST X
WHERE X.ESTADO_TEST = 'A'
AND X.DESC_TEST = 'DUMMY_8000';

ANALIZANDO EL RESULTADO OBTENIDO:

- DESCRIPTION: TABLE ACCES BY INDEX ROWID


- OBJECT NAME: UQ_DUMMY
- COST: 2 (OK)
- CARDINALIDAD: 1
- BYSTES: 40 (OK)
CONCLUSIONES:
Es NOTORIO que al aplicar un correcto manejo de INDICES el rendimiento en la consulta SQL es mayor y optimizado, decrementando
considerablemente en recursos como: COST y en BYTES.

También podría gustarte