UNIVERSIDAD MAYOR DE SAN ANDRÉS

FACULTAD DE CIENCIAS PURAS Y NATURALES

CARRERA DE INFORMÁTICA

PROYECTO DE GRADO
METODO DE AFINAMIENTO DEL SISTEMA GESTOR DE
BASE DE DATOS ORACLE 11G PARA LA AGENCIA
NACIONAL DE HIDROCARBUROS (ANH)
Proyecto de Grado para obtener el Título de Licenciatura en Informática
Mención Ingeniería de Sistemas Informáticos

POR: GABRIEL ALFREDO ZAMORANO RODRIGUEZ

TUTOR METODOLÓGICO: M. SC. FRANZ CUEVAS QUIROZ
ASESOR: ING. CÉSAR BELTRÁN VILLALTA

LA PAZ – BOLIVIA
2020
 HOJA DE CALIFICACIONES
UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

PROYECTO DE GRADO:
METODO DE AFINAMIENTO DEL SISTEMA GESTOR DE BASE DE DATOS
ORACLE 11G PARA LA AGENCIA NACIONAL DE HIDROCARBUROS (ANH)

POSTULANTE: Gabriel Alfredo Zamorano Rodríguez

PARA OPTAR EL TÍTULO DE: Licenciatura en Informática

MENCIÓN: Ingeniería de Sistemas Informáticos

NOTA NUMERAL: …………………………………………….......

NOTA LITERAL: ………………………………………………...

HA SIDO: …………………………………………………

DIRECTOR DE LA CARRERA DE INFORMÁTICA: Ph. D. José María Tapia Baltazar

TUTOR METODOLÓGICO: M. Sc. Franz Cuevas Quiroz

ASESOR: Ing. César Beltrán Villalta

TRIBUNAL: ………………………………….

TRIBUNAL: ………………………………….

TRIBUNAL: ………………………………….
 UNIVERSIDAD MAYOR DE SAN ANDRÉS
FACULTAD DE CIENCIAS PURAS Y NATURALES
CARRERA DE INFORMÁTICA

LA CARRERA DE INFORMÁTICA DE LA FACULTAD DE CIENCIAS PURAS Y

NATURALES PERTENECIENTE A LA UNIVERSIDAD MAYOR DE SAN ANDRÉS
AUTORIZA EL USO DE LA INFORMACIÓN CONTENIDA EN ESTE DOCUMENTO SI
LOS PROPÓSITOS SON ESTRICAMENTE ACADÉMICOS.

LICENCIA DE USO

El usuario está autorizado a:

a) Visualizar el documento mediante el uso de un ordenador o dispositivo móvil.
b) Copia, almacenar o imprimir si ha de ser uso exclusivamente personal y privado.
c) Copiar textualmente parte(s) de su contenido mencionando la fuente y/o haciendo la
referencia correspondiente respetando normas de redacción e investigación.
El usuario no puede publicar, distribuir o realizar emisión o exhibición alguna de este
material, sin la autorización correspondiente.

TODOS LOS DERECHOS RESERVADOS, EL USO NO AUTORIZADO DE LOS

CONTENIDOS PUBLICADOS EN ESTE SITIO DERIVARÁ EN EL INICIO DE ACCIONES
LEGALES CONTEMPLADOS EN LA LEY DE DERECHOS DE AUTOR.
 A Dios por darme la vida y por estar junto a mí,
A mi Mamá y mi Papá (†) por su confianza,
A mi amada esposa Roxana por su amor y comprensión.
 AGRADECIMIENTOS

A Dios, por brindarme cada día el regalo de la vida, por enseñarme sus principios,
sentir su amor y fidelidad, que de los tropiezos se aprende yo no se debe renunciar a lograr
las metas trazadas en la vida.

Un sincero agradecimiento a los docentes de la Universidad Mayor de San Andrés de

la Carrera de Informática, a la Dirección de Tecnologías de Información y Comunicación
(DTIC) de la Agencia Nacional de Hidrocarburos, a mi familia y amigos. De forma especial:

Al Licenciado M. Sc. Franz Cuevas Quiroz, por darnos a conocer sus experiencias y
conocimientos que motivaron a los alumnos del Taller a concluir sus proyectos y de forma
particular a mi persona.

Al Ingeniero César Beltrán Villalta, por todas sus sugerencias y observaciones en la

realización de este proyecto.

Al Ingeniero Rene David Chávez Ortiz, por todos sus consejos, por su amistad, jefe
e impulsor para la realización de este proyecto de grado.

A mi amada esposa Roxana por su paciencia, comprensión y colaboración para llevar

adelante este proyecto de grado.

A mis hermanos por su colaboración y comprensión.

De todo corazón se los agradezco a todos, la culminación del presente proyecto de

grado es gracias a cada uno de ustedes.

GRACIAS

zamoranogabo@gmail.com
 RESUMEN
El proyecto de grado denominado “MÉTODO DE AFINAMIENTO DEL SISTEMA
GESTOR DE BASE DE DATOS ORACLE 11G PARA LA AGENCIA NACIONAL DE
HIDROCARBUROS (ANH)” se presenta como solución para optimizar el rendimiento del
Motor 11g. El Sistema Gestor de Base de Datos Oracle 11g lanzado por primera vez en
septiembre de 2008; sucedió a Oracle 10g. Cada nueva versión tiene versiones de conjuntos
de parches más recientes, las más importantes de las cuales se conoce como versión. Un
objetivo principal de cada versión actualizada es aumentar el rendimiento y escalabilidad
sobre la versión anterior. Por lo tanto, hay muchas características nuevas en 11g.
La Agencia Nacional de Hidrocarburos cuenta con dos servidores de datos, los cuales
se encuentran con el Motor 11g, los servidores son HP Proliant BL620cG7 con sistema
operativo Red Hat 6.4, que fue una distribución Linux.
Para el desarrollo del método, se consideran las buenas prácticas de afinamiento, una
buena práctica de afinamiento es un procedimiento para afinar un determinado motor
(perteneciente a Oracle) de acuerdo a un entorno (recursos de hardware y software). El
método es aplicable solo para el entorno de producción de la Agencia Nacional de
Hidrocarburos, pero para futuros estudios también podría ser considerada una buena práctica
de afinamiento. El método propuesto, aportará a la Agencia Nacional de Hidrocarburos una
forma de obtener información de cómo se encuentra actualmente el rendimiento de su
Sistema Gestor de Base de datos (monitorización del rendimiento), saber interpretar esta
monitorización y proceder a ajustar lo que se requiera, ya sea el ajuste en las estructuras de
memoria o en las estructuras físicas.
Las herramientas utilizadas en el método (Oracle Enterprise Manager y SQL*) vienen
incluidas a la hora de instalar el Sistema Gestor de Base de Datos Oracle 11g, entonces no se
pagan licencias por el uso de estas herramientas.

Palabras clave: Oracle, método de afinamiento 11g, Red Hat, motor de Oracle, gestor de
base de datos Oracle 11g
 RESUME

The degree project called “TUNING METHOD OF THE ORACLE 11G

DATABASE MANAGEMENT SYSTEM FOR THE NATIONAL HYDROCARBON
AGENCY (ANH)” is presented as a solution to optimize the performance of the 11g Engine.
The Oracle 11g Database Management System first released in September 2008; succeeded
Oracle 10g. Each new version has newer patch set versions, the most important of which is
known as a version. A primary goal of each updated version is to increase performance and
scalability over the previous version. So there are a lot of new features in 11g.

The National Hydrocarbons Agency has two data servers, which are with the 11g Engine, the
servers are HP Proliant BL620cG7 with Red Hat 6.4 operating system, which was a Linux
distribution.

For the development of the method, good tuning practices are considered, a good
tuning practice is a procedure to tune a certain engine (belonging to Oracle) according to an
environment (hardware and software resources). The method is applicable only for the
production environment of the National Hydrocarbons Agency, but for future studies it could
also be considered a good fine-tuning practice. The proposed method will provide the
National Hydrocarbons Agency with a way to obtain information on how the performance of
its Database Management System is currently being performed (performance monitoring), to
know how to interpret this monitoring and to proceed to adjust what is required, either the
adjustment in memory structures or in physical structures.

The tools used in the method (Oracle Enterprise Manager and SQL *) are included
when installing the Oracle 11g Database Management System, so no licenses are paid for the
use of these tools.
 INDICE
CAPITULO I ..................................................................................................................................... 1
INTRODUCCION............................................................................................................................. 1
1.1 ANTECEDENTES ................................................................................................................ 3
1.1.1 Antecedentes Institucionales ................................................................................................... 3
1.1.2 Antecedentes de proyectos similares ...................................................................................... 6
1.2 PLANTEAMIENTO DEL PROBLEMA .................................................................................. 7
1.3 DEFINICION DE OBJETIVOS ...................................................................................... 8
1.3.1 Objetivo General .............................................................................................................. 9
1.3.2 Objetivos Específicos................................................................................................. 9
1.4 JUSTIFICACIÓN ....................................................................................................................... 9
1.5 ALCANCES Y LÍMITES ......................................................................................................... 10
1.5.1 Alcances ........................................................................................................................... 10
1.5.2 Límites ............................................................................................................................. 11
1.6 APORTES .................................................................................................................................. 11
1.6.1 Aporte Práctico............................................................................................................... 11
1.6.2 Aporte Teórico ................................................................................................................ 11
CAPITULO II.................................................................................................................................. 12
MARCO TEORICO ....................................................................................................................... 12
2.1 ORACLE 11G WINDOWS Y LINUX .................................................................................... 14
2.1.1 Arquitectura de un Servidor Oracle 11g ...................................................................... 16
2.2 ANÁLISIS ACTUAL DEL SISTEMA GESTOR DE BASE DE DATOS ORACLE 11G
DE LA AGENCIA NACIONAL DE HIDROCARBUROS ......................................................... 24
2.2.1 Monitorización del rendimiento actual del Sistema Gestor de Base de Datos Oracle
11g ............................................................................................................................................. 25
2.3 INTERPRETACIÓN DE LA MONITORIZACIÓN ............................................................. 34
2.3.1 Interpretación de la primera sección ............................................................................ 35
2.3.2 Interpretación de la segunda sección ............................................................................ 35
2.3.3 Interpretación de la tercera sección.............................................................................. 36
2.3.4 Interpretación de la cuarta sección ............................................................................... 36
2.4 FASES DE LA METODOLOGÍA ................................................................................. 37
2.4.1 Administración de rendimiento .................................................................................... 37
2.4.2 Ajuste de aplicación ....................................................................................................... 39
2.4.3 PRIMERA ETAPA: Recolección y Análisis de Información ..................................... 41
 2.4.4 SEGUNDA ETAPA: Afinamiento de las Estructuras de Memoria ........................... 42
2.4.5 TERCERA ETAPA: Afinamiento de las Estructuras Físicas .................................... 43
2.5 JUSTIFICACIÓN DEL USO DE METODOLOGÍA ............................................................ 44
2.6 ANÁLISIS DE COSTOS Y BENEFICIOS ............................................................................. 45
CAPITULO III ................................................................................................................................ 47
EVOLUCIÓN Y PUESTA EN MARCHA.................................................................................... 47
3.1 PLANIFICACIÓN Y ESTRATÉGIA ..................................................................................... 47
3.2 ANÁLISIS Y AFINAMIENTO ................................................................................................ 49
3.2.1 Primera Etapa: Recolección y Análisis de Información ............................................. 52
3.2.2 Segunda Etapa: Afinamiento de las Estructuras de Memoria ................................... 61
3.2.3 TERCERA ETAPA: Afinamiento de las Estructuras Físicas .................................... 65
3.3 MEDICIÓN DEL RENDIMIENTO DEL SISTEMA GESTOR DE BASE DE DATOS
ORACLE 11G.................................................................................................................................. 68
3.4 ESTUDIO DE FACTIBILIDAD ECONÓMICA ................................................................... 72
3.4.1 Costos fijos del proyecto ................................................................................................ 73
3.5 EVALUACIÓN DEL CUMPLIMIENTO.............................................................................. 74
CAPITULO IV ................................................................................................................................ 76
CONCLUSIONES Y RECOMENDACIONES ............................................................................ 76
4.1 CONCLUSIONES ..................................................................................................................... 76
4.2 RECOMENDACIONES ........................................................................................................... 77
BIBLIOGRAFÍA ............................................................................................................................. 79
ANEXOS .......................................................................................................................................... 80
INDICE DE FIGURAS
Figura 2. 1 Arquitectura Oracle 11g ........................................................................................... 16
Figura 2. 2 Arquitectura de una sola instancia............................................................................. 17
Figura 2. 3 Estructuras de memoria ............................................................................................ 20
Figura 2. 4 Verificación de la instalación de Statspack ............................................................... 26
Figura 2. 5 Instalación de Statspack .............................................................................................. 26
Figura 2. 6 Comprobación de la existencia de Statspack ............................................................ 27
Figura 2. 7 Tomar Snapshots ......................................................................................................... 28
Figura 2. 8 Reporte diferencial ...................................................................................................... 30

Figura 3. 1 Metodología propuesta ................................................................................................ 51

Figura 3. 2 Instantánea creada....................................................................................................... 55
Figura 3. 3 Página de la utilización de memoria .......................................................................... 56
Figura 3. 4 Página detalles de disco ............................................................................................... 58
Figura 3. 5 Sección top disk devices............................................................................................... 59
Figura 3. 6 Recopilación de estadísticas ........................................................................................ 68
Figura 3. 7 Menú del reporte generado por ADDM. ................................................................... 70

INDICE DE TABLAS
Tabla 1. Acciones importantes dentro del perfil de carga .......................................................... 35
Tabla 2. Porcentajes de aciertos importantes de la instancia ...................................................... 36
Tabla 3. Hits por monitorización antes de implementar la metodología ................................... 71
Tabla 4. Hits por monitorización después de aplicar la metodología ......................................... 72
Tabla 5. Costo de material de escritorio ....................................................................................... 73
Tabla 6. Costos de recolección y producción de información ..................................................... 73
Tabla 7. Costos de la aplicación de la metodología ...................................................................... 74

INDICE DE ANEXOS
ANEXO A ........................................................................................................................................ 80
ANEXO B ......................................................................................................................................... 81
ANEXO C ........................................................................................................................................ 94
 1

CAPITULO I

INTRODUCCION

Para procesar información se necesita de infraestructura tecnológica de hardware y

software, que interactúan entre sí formando sistemas de acuerdo a las necesidades del usuario,
a partir de esto el rendimiento de los servidores es intrusivo respecto al servicio
correspondiente.

Los servicios residen en servidores que nos permiten realizar nuestras labores con
mayor rapidez y eficacia. Para el rendimiento de los servidores es necesario desarrollar
procedimientos o procesos que permitan la optimización1 del recurso utilizado,
independientemente del hardware o software.

Los sistemas gestores de base de datos no son la excepción, ya que el motor de base
de datos requiere de una plataforma o sistema operativo, siendo ambos lógicamente
desarrollados.

En el presente, se ve con mayor necesidad procesar información debido al incremento

de su volumen y almacenarlos en repositorios haciendo que se haga más lento un proceso o
una actividad sobre la base de datos, esto conlleva que las entidades tanto públicas como
privadas tengan la necesidad de ofrecer un servicio eficiente y para responder a esta
necesidad exige que se optimicen los sistemas.

1
Buscar la mejor manera de realizar una actividad.
 2

Desde el punto de vista del rendimiento o características técnicas de una máquina

llamada comúnmente prestaciones es asegurarse de que las limitaciones físicas de las
aplicaciones como ser, tasas de transferencia de Entrada/Salida (E/S), tamaños de memoria,
velocidad de las consultas entre otros no afecten al funcionamiento de la organización. Si
estas limitan los procesos de la organización, será necesario optimizar las aplicaciones. En
el proceso de diseño, los límites del entorno de aplicación que incluyen el hardware y el
diseño de la aplicación como base de datos deben ser evaluados. Ningún entorno proporciona
una capacidad de procesamiento infinita, así que todos ellos están diseñados para fallar una
vez que se alcance un cierto punto en el nivel de prestaciones. En el proceso de diseño de
la aplicación, el objetivo debe ser que las necesidades guarden relación de acuerdo a las
prestaciones que el entorno sea capaz de proporcionar.

La optimización del rendimiento forma parte del ciclo de vida de todas las
aplicaciones de base de datos, pudiendo ser esta tarea de forma secuencial o predefiniendo
un orden de acuerdo a la necesidad de la base de datos. Y cuanto antes se contemplen las
cuestiones relacionadas al rendimiento o características técnicas de una máquina será más
probable resolver con éxito los problemas.

El afinado2 (tunning) es el paso final en un proceso de cuatro pasos: planificación,

implementación y monitorización deben proceder a este paso final. Si realizamos el
afinamiento simplemente por realizarlo, no estaremos contemplando adecuadamente el ciclo
completo de actividad y lo más probable es que nunca seamos capaces de resolver los fallos
subyacentes que son los auténticamente responsables de los problemas de rendimiento.
[LONEY, 2006]

2
Modismo usado para referirse al acto de mejorar el rendimiento de la base de datos.
 3

Para optimizar el rendimiento del sistema gestor de base de datos Oracle 11g de la
Agencia Nacional de Hidrocarburos, es necesario: conocer la arquitectura, el rendimiento
actual y administración del Motor3 Oracle 11g, esto para poder desarrollar un método que se
adecue a los requerimientos específicos.

Una vez obtenido este conocimiento, se podrá desarrollar un método que sea apta
para el Motor Oracle 11g de la Agencia Nacional de Hidrocarburos, la cual podrá aplicarse
para lograr optimizar el rendimiento del mismo.

1.1 ANTECEDENTES

1.1.1 Antecedentes Institucionales

El Decreto Supremo N° 29894 del 7 de febrero de 2009, determinó la estructura

organizativa del órgano ejecutivo del Estado Plurinacional, en su Art. 138 el cambio de
nombre de la Superintendencia de Hidrocarburos a Agencia Nacional de Hidrocarburos.

Conforme al Art. 365 de la Constitución Política del Estado, la Agencia Nacional de

Hidrocarburos, “es una institución autárquica de derecho público, con autonomía de gestión
administrativa, técnica y económica, bajo la tuición del Ministerio de Hidrocarburos, será
responsable de regular, controlar, supervisar y fiscalizar las actividades de toda la cadena
productiva hasta la industrialización, en el marco de la política estatal de hidrocarburos
conforme a ley.

En base a las responsabilidades señaladas la Agencia Nacional de Hidrocarburos genera

los siguientes productos:

3
Modismo que hace referencia al Sistema Gestor de Base de Datos.
 4

 Proponer, procedimentar y aplicar la normativa regulatoria.

 Generar, sistematizar y publicar la información del sector hidrocarburífero.
 Otorgar, modificar y renovar concesiones, licencias, autorizaciones y registros.
 Supervisar, controlar y fiscalizar el desempeño de los operadores.
 Atender y resolver denuncias y reclamaciones.
 Sancionar las contravenciones al ordenamiento regulatorio.

Siendo uno de sus productos de generar, sistematizar y publicar la información del sector
hidrocarburífero, a finales del 2012, la Dirección de Tecnologías de Información y
Comunicación, velando por niveles adecuados en el procesamiento, custodio y seguridad de
la información de la Agencia Nacional de Hidrocarburos encaro la centralización de todos
sus servicios informáticos. Citada transformación fue posible mediante la adquisición de
Infraestructura tecnológica de hardware y software.

Para el servidor de datos como infraestructura de software se ha contemplado un sistema

gestor de base de datos Oracle 11g sobre una plataforma s.o. Red Hat 6.4 ambos soportados
por un servidor HP Proliant BL620c G7.

La Agencia Nacional de Hidrocarburos para el funcionamiento de sus servicios ha

dispuesto dos servidores de Datos, los entornos de preproducción y producción. Los
Administradores de Base de Datos realizan sus trabajos en estos servidores debiendo realizar
el afinamiento en el entorno de producción.

Para el afinamiento del sistema gestor base de datos se debe considerar las nuevas
estructuras de la arquitectura existente en Oracle 11g.
 5

La administración del sistema gestor de base de datos de la Agencia Nacional de

Hidrocarburos se encuentra a cargo del Centro de Procesamiento de Datos que es parte de la
Unidad de Administración de Operaciones y Comunicaciones el cual pertenece a la Dirección
de Tecnologías de Información y Comunicación de la Agencia Nacional de Hidrocarburos.
La Dirección de Tecnologías de Información y Comunicación tiene como objetivo coadyuvar
la gestión técnica, operativa y administrativa de las direcciones y unidades de la Agencia
Nacional de Hidrocarburos, mediante el uso de tecnologías de información y comunicación,
garantizando la disponibilidad y seguridad de las Bases de Datos, información, servicios
informáticos e infraestructura tecnológica.

Entre los objetivos institucionales de la Agencia Nacional de Hidrocarburos es el de:

“Brindar seguridad a los usuarios a través de la confidencialidad, impidiendo la

divulgación de información a personas o sistemas no autorizados, integridad, manteniendo
los datos libres de modificaciones no autorizadas, integridad referencial, garantizando que
una entidad se relacione con otras entidades válidas, implicando que en todo momento dichos
datos son correctos y disponibilidad, haciendo que el acceso a la información y a los sistemas
por personas autorizadas en el momento que así lo requieran, así como también el
rendimiento y la disponibilidad de los sistemas en todo tiempo”.

“Asegurar la continuidad del abastecimiento, la calidad de los servicios y productos

hidrocarburíferos y precautelar los intereses del Estado respecto de la exploración,
producción, transporte, comercialización e industrialización de los hidrocarburos, a través de
una oportuna y efectiva regulación, supervisión, control y fiscalización”.
 6

“Implementar sistemas integrales compuesto por subsistemas y herramientas

tecnológicas ágiles, oportunas para optimizar los procedimientos técnicos y administrativos
que faciliten una gestión por resultados transparente, que coadyuve En este sentido, contar
con un rendimiento óptimo en el Sistema de Gestor de Base de Datos ayudaría a lograr este
cometido con eficiencia a la supervisión, control y fiscalización en toda la cadena
hidrocarburifera”.

1.1.2 Antecedentes de proyectos similares

A continuación, se hace mención de trabajos relacionados con Base de Datos en la carrera

de Informática de la Universidad Mayor de San Andrés:

“Diseño Automático de Base de Datos Relacionales” el propósito de esta tesis es que

a través de los conceptos de las bases de datos, utilizar diseño de algoritmos básicos para
obtener una técnica que realice el diseño automático de bases de datos relacionales.
[ESPINOZA, 1990].

“Mejora Semántica de Consultas en Base de Datos Relacionales”, semántica de

consultas en una base de datos se entiende por la interpretación y procesar los datos en una
base de datos relacional. El fin concreto de esta tesis es el de proporcionar un método que
permita al usuario realizar una consulta de manera mejorada, mediante el análisis semántico
de los símbolos en torno a un lenguaje de consulta de base de datos relacionales, este método
se aplica a casos generales en los cuales se tiene que realizar una interpretación semántica
correcta. [DELGADO, 1997].

“Evaluación del rendimiento del Diseño de una Base de Datos”, orientado a medir el
rendimiento del diseño de una Base de Datos Relacional, para lo cual requiere de un modelo,
 7

un conjunto de métricas (métricas de control, métricas de pronosticación y métricas de código

fuente) y una herramienta (CASE4). [BARRIOS, 2000].

Los trabajos mencionados no contemplan la evolución de las Bases de Datos el cual con
el tiempo se incorporaron nuevos componentes en estructura y en arquitectura y estos no
trabajan directamente con los mismos, ni tampoco una metodología que se adecue a los
requerimientos específicos. Sin duda alguna no plantean una optimización para el
rendimiento de sistemas gestores de base de datos.

1.2 PLANTEAMIENTO DEL PROBLEMA

La Agencia Nacional de Hidrocarburos cuenta con servidores de datos que utilizan el

sistema gestor de base de datos Oracle 11g, las bases de datos son un elemento imprescindible
para el almacenamiento constante de los parámetros, las estructuras y la configuración de las
mismas.

En base a los estudios y artículos realizados que se menciona a continuación sobre la falta
de afinamiento a un sistema gestor de base de datos y los problemas que puede ocasionar:

“Alta disponibilidad con Oracle Database 11g versión 2” el cual menciona que para
obtener una alta disponibilidad de una base de datos se debe realizar el afinamiento para el
aprovechamiento de la protección de datos optimizada para Oracle, alta disponibilidad
integrada en las aplicaciones y una arquitectura integrada y abierta. Lo que si no se procede
a realizar esta tarea conlleva a un bajo rendimiento y la falta de disponibilidad de la base de
datos. [DOCUMENTO TÉCNICO DE ORACLE, 2010]

4
Las herramientas CASE son diversas aplicaciones informáticas destinadas a aumentar el balance en el
desarrollo de software reduciendo el costo en términos de tiempo y de dinero.
 8

“Base de Datos” el siguiente artículo menciona que la falta de afinación puede provocar
desde un bajo rendimiento hasta la pérdida de datos importantes, sobre todo en base de datos
grandes como Oracle. El afinamiento de las bases de datos es un elemento fundamental para
la gestión de las empresas, por eso es necesario asegurar su consistencia. [ICUALITY, 2014]

Por lo que podemos mencionar los siguientes problemas secundarios a los que nos lleva
la falta de afinamiento:

 Se desconoce el rendimiento del Sistema Gestor de Base de Datos Oracle 11g. por lo
que puede ocasionar la falta de disponibilidad de la base de datos.
 No existe procedimientos para optimizar el rendimiento de los nuevos elementos en
la estructura de memoria del sistema gestor de base de datos 11g, lo que conlleva a
que los administradores de base de datos apliquen diferentes formas de afinamiento.
 Se descuida la tarea de afinamiento como preventiva, siendo esta actualmente
correctiva, esta forma de actuar pueden ser causante de mayores conflictos como
ocasionar la falta de disponibilidad de la base de datos.

Debido a las acciones correctivas para el afinamiento al sistema gestor de base de datos
se tiene el siguiente problema central:

¿Cómo se puede optimizar el rendimiento de memoria y del motor del sistema gestor de
base de datos Oracle 11g de la Agencia Nacional de Hidrocarburos?

1.3 DEFINICION DE OBJETIVOS

Ante los problemas identificados, se plantean los siguientes objetivos para la elaboración
del presente proyecto. (Ver ANEXO A).
 9

1.3.1 Objetivo General

Desarrollar un método para optimizar el rendimiento de la memoria y el motor del

sistema gestor de base de datos Oracle 11g para la Agencia Nacional de Hidrocarburos
basándose en las buenas prácticas de afinamiento que sugiere la corporación Oracle.

1.3.2 Objetivos Específicos

 Obtener métricas del rendimiento del sistema gestor de base de datos Oracle 11g antes
y después del afinado.
 Determinar una estructura de pasos para el afinamiento del sistema gestor de base de
datos Oracle de acuerdo a la arquitectura 11g, considerando el entorno de producción
de la Agencia Nacional de Hidrocarburos.
 Aplicar métodos y técnicas de afinamiento para optimizar el rendimiento de las
estructuras de memoria del sistema gestor de base de datos Oracle 11g.
 Aplicar métodos y técnicas de afinamiento para optimizar el rendimiento de las
estructuras físicas del sistema gestor de base de datos Oracle 11g.

1.4 JUSTIFICACIÓN

Optimizar el rendimiento del motor o sistema gestor de base de datos Oracle 11g para
la Agencia Nacional de Hidrocarburos, reducirá la suerte de ejercicio de ensayo, error que se
realiza en la mayor parte del afinamiento Oracle, esto hace que incida en la disminución de
horas extras de trabajo y el consiguiente costo que esto significa.
También evita la compra de recursos de hardware innecesarios debido a un mal rendimiento
en el motor, así como también el recurso humano que interactúa con la administración del
sistema gestor de base de datos.
 10

Al obtener un eficiente rendimiento en el sistema gestor de base de datos Oracle 11g,

producto del afinamiento, beneficiando tanto al personal de la unidad de desarrollo, haciendo
que se eviten quejas del funcionamiento del mismo como también se benefician los clientes
de la Agencia Nacional de Hidrocarburos, los usuarios consumidores haciendo que se les
brinde información fidedigna y completa a sus requerimientos; los operadores brindándoles
un marco normativo apropiado como las condiciones físicas, para asegurar sus operaciones
y el Ministerio de Hidrocarburos atendiendo de forma oportna y fidedignamente sus
requerimientos específicos dentro el ámbito de acción de la Agencia Nacional de
Hidrocarburos.

Para evitar caer en problemas correctivos de modo permanente, se debe tener un

entendimiento definido de cómo van a utilizar las aplicaciones en la Base de Datos, la Base
de Datos debe estar bien estructurada, debe contemplar un conjunto de medidas que calibren
la salud de la Base de Datos y un método sistemático de realizar dichas medidas y determinar
tendencias de ajuste.

1.5 ALCANCES Y LÍMITES

1.5.1 Alcances

Dentro de los alcances del proyecto se define la metodología está compuesta en tres
etapas:
 Recolectar información, etapa principal para determinar cómo se encuentra el
rendimiento del sistema gestor de base de datos 11g para así realizar la interpretación.
 Indicar los procedimientos que se deben seguir para optimizar el rendimiento de las
estructuras de memoria.
 11

 Indicar como optimizar las E/S a disco y optimizar el rendimiento de las estructuras
físicas de almacenamiento, como ser archivos de datos, archivos redo log y archivos
de control.

1.5.2 Límites

 No contempla un nuevo versionamiento, debido a que en el futuro la Agencia

Nacional de Hidrocarburos podría migrar a una nueva versión como ser Oracle 12g.
 No contempla afinación de consultas en la base de datos ya que el afinamiento o
tunning se refiere al diseño de archivos de la base de datos, selección del DBMS
(Database Management System) o gestor de base de datos, sistema operativo y el
CPU que utilizará el DBMS.

1.6 APORTES

1.6.1 Aporte Práctico

Desarrollar un método, para optimizar el rendimiento del sistema gestor de base de datos
Oracle 11g de la Agencia Nacional de Hidrocarburos.

1.6.2 Aporte Teórico

La Agencia Nacional de Hidrocarburos se beneficiará al contar con un procedimiento

para el afinamiento del sistema gestor de base de datos Oracle 11g.

Brindar una fuente de investigación como base para posteriores proyectos relacionados
con el afinamiento de sistemas gestor de base de datos Oracle.

Así como también de un método de afinamiento apta para el sistema gestor de base de
datos Oracle 11g.
 12

CAPITULO II

MARCO TEORICO

Una base de datos es un conjunto de datos interrelacionados entre sí. La implementación

de este concepto a nivel de sistema, ha llevado a la necesidad de implementar diferentes
aplicativos que permiten la creación y manipulación de dichas bases en un computador,
generando de esta forma grandes repositorios de datos que permiten obtener información
oportuna, segura y confiable.

Dado que la administración y el mantenimiento de estos grandes repositorios de

información son temas muy especializados, la operación y manipulación de la base de datos
resulta ser todo un misterio para muchos profesionales del área de tecnología de la
información con perfil más de gestión que técnico, quienes se conforman con tener sistemas
administradores de base de datos con tiempos de respuestas decentes, pero no óptimos.

Para un correcto funcionamiento de los grandes repositorios de datos que residen en el

disco de un computador, se necesita de un técnico con los conocimientos apropiados. El
Administrador de Base de Datos (DBA, por sus siglas en inglés) es aquel profesional del área
de tecnología de la información llamado a liderar el área de base de datos en una organización
y tiene a su cargo entre otras cosas, las siguientes funciones:

 Realizar el diseño de una base de datos.

 Establecer las restricciones de los datos.
 Establecer las políticas de respaldos de los datos.
 13

 Implementar una base de datos.

 Mantener operativa una base de datos.
El 3 de septiembre de 2007, Oracle anunció el nuevo sistema de administración de base
de datos, Oracle Database 11g. De acuerdo con la visión de brindar calidad incomparable,
facilidad de uso al usuario y eficacia en la administración de datos, Oracle Database 11g fue
desarrollada con la máxima capacidad de recursos de ingeniería para un solo producto. Oracle
Database 11g es el resultado de un proceso de desarrollo para brindar un mejor desempeño,
seguridad y administración automatizada. El producto presenta las siguientes características:

a) SecureFiles, permite que la gran cantidad de información de objetos no estructurados,

como las imágenes de rayos X para atención médica y los gráficos de ingeniería que
en el pasado eran ejecutados en el sistema de archivos, sean directamente
almacenados y administrados dentro de la base de datos para resolver los cuellos de
botella que se presentan durante el desempeño.

b) Real Aplication Testing, es probablemente la opción más innovadora de la última

edición empresarial de Oracle Database 11g. La función puede capturar cargas de
trabajo de base de datos en tiempo real y repartirlas en un entorno de prueba. Esto
ayuda a los usuarios a probar y personalizar sus sistemas para alcanzar un óptimo
desempeño.

c) Total Recall, permite a los usuarios rastrear y mantener los cambios de datos de
manera fácil y económica, a través del archivo continuo de datos. En el ambiente
mundial, donde el cumplimiento ha pasado a primera plana, la capacidad de recuperar
datos rápidamente cuando se lo solicita se considera muy valiosa. En otras versiones
era extremadamente costoso, aunque necesario, almacenar cantidades masivas de
 14

datos en sistemas de almacenamiento. Con Total Recall, ahora es mucho más fácil y
más económico rastrear y recopilar los datos del pasado.

d) Advanced Compression, es una tecnología versátil que comprime efectivamente

tablas masivas y datos no estructurados. Reduce las capacidades de almacenamiento
y obtiene una gran cantidad de otros beneficios como cargas reducidas de red y mejor
eficacia de backup. La función permite a los usuarios ahorrar costos en sistemas,
capacidad y espacio.

La base de datos Oracle 11g es una solución optimizada de base de datos para aquellas
implementaciones que requieren escalabilidad, confiabilidad y alto desempeño, se integra
por completo con las características del sistema operativo Windows y el hardware
subyacente. Oracle 11g ofrece también desempeño de primer nivel a través del soporte de
memorias extendidas, archivos binarios y de gran volumen.

El objetivo de Oracle ha sido el de brindar la base de datos más integrada y de máximo

desempeño en Windows y, como resultado, Oracle ha invertido en el traspaso de su
tecnología de base de datos Unix. En 1993, Oracle fue la primera empresa en brindar una
base de datos relacional para Windows NT.

2.1 ORACLE 11G WINDOWS Y LINUX

Oracle Database 11g es un Sistema de Gestión de Base de Datos Relacionales (SGDBR)

disponible para plataformas (Unix, Linux, Windows). Desde un punto de vista de
administración, las diferencias entre estas plataformas son mínimas.

Cuando se ejecuta en Windows, Oracle Database 11g presenta las mismas características
y la misma funcionalidad que las distintas plataformas Linux y UNIX soportadas por Oracle.
No obstante, la interface entre la base de datos y el sistema operativo ha sido sustancialmente
 15

modificada para aprovechar los servicios exclusivos brindado por Windows. Como resultado,
Oracle Database 11g en Windows no es un puerto directo de la base de código UNIX.

La diferencia principal es que en UNIX el sistema operativo controla las operaciones,

mientras que en Windows la base de datos Oracle controla las operaciones.

Oracle 11g se comercializa de tres maneras diferentes:

 Edición empresa (Enterprise Edition), disponible en servidores únicos y en clústers

sin limitación de sockets. Proporciona una administración de datos eficaz, confiable
y segura para aplicaciones transaccionales esenciales, almacenes de datos con
intensidad de consultas y cargas de trabajo mixtas.
 Edición estándar (Standard Edition), disponible en servidores únicos o en clústers
con una capacidad máxima total de cuatro sockets. Incluye Oracle Real Application
Clusters como función estándar.
 Edición estándar uno (Standard Edition One), Proporcionando facilidad de uso,
potencia y relación precio/rendimiento para aplicaciones web, en grupo de trabajo o
departamento, en servidores únicos con un máximo de dos sockets.

Para una mejor comprensión un socket es un punto final de un enlace de comunicación

bidireccional entre un programa servidor y uno o más programas cliente. Un socket asocia el
programa del servidor con un número de puerto de hardware específico en la máquina donde
se ejecuta, por lo que cualquier programa cliente en cualquier parte de la red con un socket
asociado con ese mismo puerto puede comunicarse con el programa del servidor.

Mientras que un clúster está formados por dos o más servidores independientes pero
interconectados. Algunos clúster están configurados de modo tal que puedan proveer alta
disponibilidad permitiendo que la carga de trabajo sea transferida a un nodo secundario si el
 16

nodo principal deja de funcionar. Otros clúster están diseñados para proveer escalabilidad
permitiendo que los usuarios o carga se distribuya entre los nodos. Ambas configuraciones
son consideradas clúster. Una característica importante que tienen los clúster es que se
presentan a las aplicaciones como si fuera un solo servidor. En resumen, un clúster es un
grupo de servidores independientes que cooperan comportándose como si fueran un solo
sistema.

2.1.1 Arquitectura de un Servidor Oracle 11g

Figura 2. 1 Arquitectura Oracle 11g

Fuente: Heurtel, 2009

Un servidor Oracle tiene dos elementos distintos, la instancia y la base de datos

como muestra la Figura 2.1.
La instancia está formada por:

 La estructura de memoria.
 17

 Y los procesos que permiten que Oracle funcione.

La base de datos se refiere a los ficheros en disco que almacenan los datos.
Cuando iniciamos Oracle primero se inicia la instancia y luego se abre la base de datos.
Una instancia de Oracle siempre se corresponde con una sola base de datos. Aunque existen
muchas posibilidades de crear entornos distribuidos.

 La Instancia

Figura 2. 2 Arquitectura de una sola instancia

Fuente: Soler, 2013

Como se puede observar en la Figura 2.2, la situación más común de funcionamiento

de Oracle es de una instancia en un servidor contra una base de datos que también está en los
discos locales.
 18

Se debe tener en cuenta que también existen arquitecturas distribuidas, de múltiples

instancias y de múltiples bases de datos.

Funciona en la RAM del ordenador. Cuando apagamos los servicios de Oracle,

también desaparece de la RAM.

Esta memoria se llama System Global Area (SGA). El DBA (Administrador de Base
de Datos) puede dimensionar cuánto ocupará el SGA.

Los procesos (background processes) están presentes mientras la instancia está en

memoria y controlan el funcionamiento de Oracle.
La estructura física de Oracle está formada por:

a) Los ficheros de datos, no se corresponden con las tablas de nuestro diseño. Las tablas
son diseño lógico y los ficheros diseño físico. Los procesos de Oracle se encargan de
relacionar las estructuras físicas y las lógicas.
Cambios sobre los datafiles, como cambiar su ubicación o su nombre, puede hacer
que Oracle falle.
b) Los redo log, registro secuencial de los cambios aplicados a los datos (operaciones
DML).
Suelen ser, al menos, dos ficheros físicos.
Protegen al sistema de pérdidas de datos. Son útiles, en caso de error, para recuperar
el estado anterior de los datos.
c) El fichero de control (controlfile), almacena cuál es la ubicación de las estructuras
físicas de Oracle. La instancia necesita leer primero el controlfile para poder iniciarse.

Estructura de memoria
La SGA, como mínimo, debe contener estas tres estructuras de memoria:
 19

a) La database buffer cache, la función de esta cache es mantener bloques de datos

leídos directamente de los datafiles. De esta forma, al procesar una consulta, se busca
primero la información en cache. Si la información buscada se encuentra ya en la
cache, es leída directamente. En caso contrario, la información es leída del archivo
de datos y almacenada en la cache para su empleo por consultas posteriores.

El Database Buffer Cache está organizado en dos listas:

 La lista objetos modificados mantiene aquellos bloques de datos que han sido
modificados y que aún no han sido escritos en el disco.
 La lista de objetos menos usados recientemente mantiene los bloques libres,
los bloques a los que se está accediendo actualmente y los bloques sucios que
aún no han sido remitidos a la lista de sucios.

b) El Redo Log buffer, zona de la SGA en la que se almacenan los cambios que se
hacen sobre los datos.

Los procesos de servidor que hacen cambios en los datos de la database buffer cache
también lo apuntan en el log buffer.

Estos cambios, se acaban almacenando en los redo logs, en disco.

Existen un background process encargado de escribir a redo log: el log writer

(LGWR).

c) El shared pool, es la estructura de memoria más compleja de la SGA, está formada

por muchas subestructuras, pero las más importantes son:
 20

 Library cache, almacena código ejecutado recientemente ya parseado. Esto

quiere decir que Oracle se ahorra el tiempo de comprobar si la sentencia es
correcta o no e interpretarla.
 Data dictionary cache, almacena la definición de objetos que se han accedido
hace poco.
 SQL query results, es una nueva característica de Oracle 11g, una misma
consulta puede ser ejecutada varias veces y obtener los mismos resultados.
En esta zona de memoria, se almacenan los resultados para una consulta, de
manera que no es necesario volverla a hacer.
El mecanismo es lo suficientemente inteligente como para invalidar los
resultados si los datos han sufrido cambios.

Los procesos de servidor a los que se conectan los clientes, también necesitan
memoria, pero no es compartida, así que se almacena en el PGA. Además, cada proceso de
servidor tiene su propia zona de PGA.

Opcionalmente, la SGA puede contener: Un large pool, un pool de Java, un pool de

streams (Figura 2.3).

Figura 2. 3 Estructuras de memoria

Fuente: Soler, 2013
 21

Estructuras de procesos
Los procesos de background se inician con la instancia y están trabajando hasta que la
instancia se apaga.

Existen cinco procesos que siempre han coexistido con Oracle:

a) System Monitor (SMOM), tiene asignada la tarea de abrir la base de datos, valida
que los datos que se dan que se dan en el controlfile sean correctos, se encarga de
localizar espacio libre en los datafile para guardar más datos.
b) Process Monitor (PMON), se encarga de localizar problemas con los procesos de
servidor. Si alguno de estos procesos falla, el PMON se encarga de destruir el proceso
de servidor y liberar la memoria que ocupa.
c) Database writer (DBWn), los procesos de servidor no escriben directamente sobre
los ficheros de datos, sino en la database buffer cache.
El database writer es el encargado de escribir a disco estos datos.
Una instancia puede tener más de un DBWn funcionando. A cada uno se les llama:
DBW0, DBW1, etc.
Con DBWn nos referimos a todos los Database Writer que haya.
El número de DBWn que suelen haber es uno por cada 8 CPUs aproximadamente.
d) Log writer (LGWR), este proceso es el encargado de escribir los cambios que hay
en el log buffer a los log files de disco.
Como los procesos de servidor escriben los cambios en el log buffer de memoria y la
memoria puede borrarse, el objetivo es que el LGWR escriba estos datos en los log
files lo antes posible.
Es uno de los cuellos de botella de la arquitectura de Oracle.
e) Checkpoint Process (CKPT), va asignando checkpoints dentro de los buffers de
cambio, para poder recuperar la base de datos en caso de fallo.
 22

Otros procesos vienen de versiones más recientes:

f) Manageability Monitor (MMON), MMON se dedica a capturar estadísticas del

funcionamiento de la base de datos y las almacena en el diccionario de datos.
Con esta información, la herramienta ADDM (Automatic Database Diagnostic
Monitor) da recomendaciones sobre cómo manejar el rendimiento de Oracle.
Manageability Monitor Light (MMNL), es un proceso que sirve de ayuda al
MMON.
g) Memory Manager (MMAN), gestiona la memoria de la SGA y la PGA, permite que
se puedan hacer redimensionamientos de memoria con la base de datos en marcha.
Estructuras de almacenamiento
Entre las estructuras de almacenamiento están las estructuras físicas de la base de datos,
las estructuras lógicas de la base de datos y el diccionario de datos.

 Estructuras físicas de la base de datos, dentro de las estructuras físicas de la base de

datos, se encuentran:

a) Controlfile, una instancia de Oracle tiene un único controlfile. Por seguridad es

aconsejable hacer varias copias de este fichero por si se daña.
b) Online Redo Log Files, almacenan los cambios que se van haciendo en la base de
datos, por si hubiera que volver a un estado anterior.
c) Datafiles, desde la versión 10g, se necesitan dos datafiles como mínimo. Uno
almacena el diccionario de datos y el otro para el resto.

 Estructuras lógicas de la base de datos, los programadores trabajan con las estructuras
lógicas, como por ejemplo tablas, toda esta información se guarda en segmentos.
Una tabla tiene asociado:
 23

 Filas con la información.

 Índices, que son un mecanismo para acceder más rápidamente a la información.
 Información de undo, por si queremos que la tabla vuelva a un estado anterior.

 Diccionario de datos

Se almacena en el conjunto de segmentos que forman los tablespaces de SYSTEM y

SYSAUX.

Los datos que almacena son una descripción de los contenidos físicos y lógicos que tiene
la base de datos:
 Definición de usuarios.
 Información de seguridad.
 Restricciones de integridad.
No podemos acceder al diccionario de datos directamente, a no ser que nos conectemos
como usuario DBA.

Si hacemos modificaciones directamente sobre el diccionario de datos, podremos dañar

de forma irreparable la base de datos.

 La base de datos

Fichero de control

El fichero de control contiene la información de control de la base de datos:

 el nombre de la base de datos;

 la fecha/hora de creación de la base de datos;
 24

 la ubicación de otros ficheros de la base de datos (ficheros de datos y ficheros de

actualización);
 el número de secuencia actual de los ficheros de actualización;
 la información de los puntos de comprobación (checkpoint), etc.

Oracle actualiza el fichero de control automáticamente cada vez que se produce una
modificación de la estructura de la base de datos (adición o cambio de ubicación de un
fichero, por ejemplo). Oracle determina el tamaño del fichero de control.

En el mismo momento en que se ejecuta una instancia para abrir una base de datos, el
fichero de control es el primero en abrirse. Permite a la instancia localizar y abrir el resto
ficheros de la base de datos. Si no se puede encontrar el fichero de control (o está dañado),
la base de datos no se puede abrir, aunque el resto de ficheros de la base de datos esté
presente (la instancia permanece en el estado NOMOUNT).

2.2 ANÁLISIS ACTUAL DEL SISTEMA GESTOR DE BASE DE DATOS ORACLE

11G DE LA AGENCIA NACIONAL DE HIDROCARBUROS

La Dirección de Tecnologías de Información y Comunicación de la Agencia Nacional de

Hidrocarburos (ANH), encaro la centralización de todos sus servicios informáticos. Citada
transformación fue posible mediante la adquisición de Infraestructura tecnológica de
hardware y software.

Para el servidor de datos como infraestructura de software se ha contemplado un sistema

gestor de base de datos Oracle 11g sobre una plataforma Red Hat 6.4 ambos soportados por
un servidor HP Proliant BL620c G7.

La Agencia Nacional de Hidrocarburos para el funcionamiento de sus servicios ha

dispuesto los siguientes servidores de Datos, los entornos de test, desarrollo, preproducción
 25

y producción. El Administrador de Base de Datos realiza su trabajo en estos servidores

debiendo realizar el afinamiento en el entorno de producción.

2.2.1 Monitorización del rendimiento actual del Sistema Gestor de Base de Datos
Oracle 11g

Al ajustar una base de datos, es importante tener una línea de base establecida para una
comparación posterior cuando el sistema esté funcionando mal. Un punto de datos de
referencia ayuda a identificar los factores que se deben verificar al diagnosticar nuevos
problemas de rendimiento. Algunos factores a verificar son:

 Aumento del volumen de transacciones en el sistema.

 Cambio del perfil de transacción o la aplicación.
 Incremento de número de usuarios.

El paquete Statspack es un conjunto de scripts SQL, PL/SQL y SQL * Plus que permiten
la recopilación, automatización, almacenamiento y visualización de datos de rendimiento.
Statspack almacena las estadísticas de rendimiento de forma permanente en tablas de Oracle,
que luego se pueden utilizar para informes y análisis. Los datos recopilados se pueden
analizar mediante informes de Statspack, que incluyen una página de resumen de carga y
estado de la instancia, declaraciones SQL de recursos elevados y los parámetros de
inicialización y eventos de espera.

Para comenzar se debe verificar si el paquete Statspack está instalado, se verifica si la

vista statas$waitstat existe, esta vista contiene información sobre las snapshots tomadas por
Statspack. La Figura 2.4 muestra la línea de comandos que sirve para verificar si Statspack
está instalado en el servidor, como se puede observar el paquete no está instalado, muestra el
error ora-04043 nos indica que el objeto stats$waitstat no existe.
 26

Figura 2. 4 Verificación de la instalación de Statspack

Fuente: Elaboración propia

Como el paquete Statspack no está instalado se procede a instalarlo. La Figura 2.5

muestra la línea de comandos para la instalación de Statspack.

Figura 2. 5 Instalación de Statspack

Fuente: Elaboración propia

Una vez terminada la instalación Oracle notifica que la instalación concluyó

satisfactoriamente.

Como se observa en la Figura 2.6 se vuelve a verificar la existencia de la vista

stats$waitstat y muestra las columnas que componen esta vista.
 27

Figura 2. 6 Comprobación de la existencia de Statspack

Fuente: Elaboración propia

Ahora se debe tomar snapshots para ver el rendimiento del Sistema Gestor de Base
de Datos Oracle 11g, para ello se debe conectar a la base de datos con el usuario y password
que se crearon en el momento de instalar Statspack (el usuario dueño de los objetos de
Statspack es PERSTAT). La Figura 2.7 muestra la línea de comandos para tomar un snapshot
a las 09:30 a.m. y otra a las 15:30 p.m.
 28

Figura 2. 7 Tomar Snapshots

Fuente: Elaboración propia

Por último se debe generar reportes diferenciales, esto se logra teniendo un snapshot
inicial (09:30 a.m.) y otro snapshot final (15:30 p.m.), así lograr un reporte por día.
 29

La información que se encuentra en el reporte es:

 Nombre de la instancia y de la base de datos.

 Hora a la que se tomaron las instancias.
 Tamaños actuales de las cachés.
 Perfil de carga.
 Porcentajes de eficacia de la instancia.
 Cinco principales de eventos de espera.
 Lista completa de los eventos de espera.
 Información sobre las sentencias SQL que actualmente están en conjunto.
 Estadísticas de actividad de la instancia.
 Tablespace y E/S de archivo.
 Estadísticas de conjunto de buffer.
 Estadísticas de segmento de rollback o de segmento de deshacer.
 Actividad de bloqueos internos.
 Estadísticas de caché de diccionario.
 Estadísticas de caché de biblioteca.
 Estadísticas de la SGA.
 Valores de inicio para los parámetros de inicialización.

Esta información es general sobre el estado del rendimiento del Sistema Gestor de Base
de Datos Oracle 11g, la información que se requiere para el caso es aquella sobre la SGA,
sus áreas de memoria (Shared Pool, DB Bufer Caché y Redo Log Buffer Caché), la E/S a
disco y los valores de algunos parámetros de inicialización.

En la Figura 2.8 se puede observar la línea de comandos para realizar un reporte

diferencial. Donde:
 30

 Begin_snap es la snapshot inicial (para el día 1, día 2, día 3 y día 4 serán 1, 7, 9 y 11

respectivamente.
 End_snap es la snapshot final (para el día 1, día 2, día 3 y día 4 serán 2, 8, 10 y 12
respectivamente).
 Report_name es el nombre que se le asigna al reporte.

Figura 2. 8 Reporte diferencial

Fuente: Elaboración propia

Se toman snapshots durante cuatro días (lunes, martes, miércoles y jueves) lo cual
significa contar con ocho snapshots y de ellos generar cuatro reportes diferenciales.
A continuación se muestra el primer reporte generado:

Día 1 (lunes 09/11/2020)

Primera sección
La primera sección muestra información sobre el Sistema Gestor de Base de Datos,
como ser el nombre de la instancia, el host desde el cual se conectó a la base de datos, la
fecha en la que se tomó el snapshot, el tamaño de las estructuras de la memoria data buffer,
shared pool, redo log buffer cache y el tamaño del bloque de datos Oracle. Al final de la
sección se muestra el perfil de carga, el cual ayuda a identificar el tipo de actividad que se
 31

está realizando, como ser lecturas lógicas, lecturas físicas, operaciones de ordenación,
escrituras físicas por segundo, número de transacciones por segundo.

Segunda Sección
La segunda sección muestra los porcentajes de eficiencia de la instancia, como ser la
tasa de aciertos de buffer y la tasa de aciertos de la caché de biblioteca, la tasa de no espera
del buffer, la tasa de no espera del redo log buffer, en si son indicadores que tiene el fin de
identificar si existe algún cuello de botella. También nos muestra las estadísticas del conjunto
 32

compartido. Estas estadísticas del conjunto compartido muestran el porcentaje utilizado de

esta área y el porcentaje de instrucciones SQL que se han ejecutado múltiples veces (que es
lo que se desea).

Tercera Sección
La tercera sección muestra la E/S a los tablespaces, como también la dirección de los
archivos, número de lecturas por segundo, número de bloques leídos por segundo, número
de escrituras y esperas en el buffer.
 33

Cuarta Sección
La cuarta sección nos muestra información respecto a la información procesada solo
en memoria, área actual de trabajo de mejoría del objetivo, porcentaje de PGA asignada al
área de trabajo.
 34

Los reportes de las estadísticas de los días 2, 3 y 4 con sus respectivas secciones se
encuentran en el ANEXO B.

2.3 INTERPRETACIÓN DE LA MONITORIZACIÓN

Una vez realizada la monitorización se deben interpretar los resultados para entender
a cabalidad como se encuentra el rendimiento del motor.
 35

La interpretación se la realizará por secciones, cada sección tendrá el contenido de

los reportes de los cuatro días.
2.3.1 Interpretación de la primera sección

Para el presente proyecto de grado, no toda la información mostrada en la sección es

importante para saber qué hacer para mejorar el rendimiento, en la Tabla 1 se muestran
aquellas acciones que son importantes a la hora de tomar una decisión para optimizar el
rendimiento del Sistema Gestor de Base de Datos Oracle 11g, mostramos las acciones de los
cuatro días en los que se hizo la monitorización.

Las lecturas lógicas, lecturas físicas, escrituras físicas y transacciones realizadas se

muestran en una cantidad / segundo.

Tabla 1. Acciones importantes dentro del perfil de carga

Días Día 1 Día 2 Día 3 Día 4

(Cantidad / (Cantidad / (Cantidad / (Cantidad /
Carga Segundo) Segundo) Segundo) Segundo)
Logical reads 3150.69 3150.55 3166.41 3150.90
Physical reads 0 0 5.02 0
Physical writes 0.51 0.49 0.53 0.51
Transactions 13.57 13.58 13.58 13.58
Fuente: Informe Statspack

2.3.2 Interpretación de la segunda sección

Al igual que la interpretación de la primera sección, se toma en cuenta solo aquellos

elementos importantes para tomar decisiones a la hora de realizar el ajuste. Ver Tabla 2.
 36

Los elementos importantes son las no esperas en el buffer, acceder a memoria (hit) y
no a disco (miss) para el data buffer cache, utilizar una misma consulta y la no espera del
redo log buffer cache.

Tabla 2. Porcentajes de aciertos importantes de la instancia

Días Día 1 Día 2 Día 3 Día 4

Elemento (Aciertos en (Aciertos en (Aciertos en (Aciertos en
porcentaje) porcentaje) porcentaje) porcentaje)
Buffer nowait 98.79 98.81 97.80 98.80
Buffer hit 98.06 98.14 97.84 98.21
Library hit 99.17 99.17 99.14 99.14
Redo nowait 100 100 100 100
Fuente: Informe Statspack

2.3.3 Interpretación de la tercera sección

Los reportes de los cuatro días muestran que los tablespace a los que más se accede
en escritura es el UNDOTBS1 y lectura el SYSTEM, esto se debe a que el tablespace
UNDOTBS1 almacena los cambios realizados a la información contenida en la base de datos
y no se hizo un commit (no se confirmó el cambio) y el tablespace SYSTEM por el hecho de
contener información administrativa de la base de datos y al diccionario de datos.

2.3.4 Interpretación de la cuarta sección

Como se puede observar en los reportes, la PGA tiene un 100% de aciertos en memoria,
esto quiere decir que no falló a la hora de asignar un proceso de servidor cuando un usuario
estableció una sesión.
 37

2.4 FASES DE LA METODOLOGÍA

2.4.1 Administración de rendimiento

Tradicionalmente, la administración de rendimiento ha constituido un gran desafío para los

administradores de base de datos. Gracias a la base de datos de autoadministración Oracle
Database 11g, la administración de rendimiento de bases de datos resulta más fácil que nunca.
Oracle Database 11g expande sus capacidades de autoadministración a todas las áreas, que
incluyen las dos áreas principales de la administración de rendimiento de bases de datos:
diagnóstico de rendimiento y ajuste de aplicación.

a) Diagnóstico de rendimiento

Los pasos para lograr un buen rendimiento son los siguientes: recopilación de datos,
realización de un análisis adecuado y la posterior puesta en práctica de un plan de acción
efectivo.

El marco de autoadministración de Oracle Database 11g lleva a cabo estas tareas por
el DBA, lo cual se traduce en un diagnóstico de rendimiento simple y rutinario. El Automatic
Workload Repository (repositorio de carga de trabajo automático) recopila los datos
necesarios y el Automatic Database Diagnostics Monitor (monitor de diagnóstico automático
de base de datos) analiza los datos y brinda recomendaciones estratégicas, concretas y útiles.

 Automatic Workload Repository

El Automatic Workload Repository (AWR, por su sigla) es un repositorio
incorporado en cada base de datos Oracle 11g que contiene estadísticas operacionales sobre
esa base de datos en particular.
 38

Los reportes de Automatic Workload Repository (AWR), son sin duda una de las
mayores armas para realizar “troubleshooting5” en un ambiente de base de datos Oracle.

A intervalos regulares, Oracle Database 11g hace un panorama de todas sus

estadísticas importantes e información de cargas de trabajo y las almacena en AWR. Por
defecto, hacen los panoramas cada 60 minutos y se almacenan en el AWR por un período de
ocho días, tras lo cual se purgan automáticamente. El administrador puede cambiar estas
predeterminaciones fácilmente. El AWR está diseñado para ser ligero y autoadministrarse
completamente, para garantizar que no se impongan tareas administrativas extra en los
administradores.

 Automatic Database Diagnostics Monitor

A partir de los datos capturados en AWR, Oracle Database 11g incluye un motor de
autodiagnóstico llamado Automatic Database Diagnostics Monitor (ADDM, por sus siglas).
ADDM posibilita que Oracle Database 11g diagnostique su propio rendimiento y determine
de qué manera se pueden resolver los problemas detectados. ADDM se ejecuta
automáticamente luego de cada captura de estadística AWR y posibilita que los datos del
diagnóstico de rendimiento estén disponibles inmediatamente.

ADDM examina los datos depurados en AWR y realiza análisis para determinar los
problemas fundamentales del sistema desde una base proactiva, recomienda soluciones y
cuantifica los beneficios esperados. El objetivo del ADDM es identificar aquellas áreas del
sistema que consumen la mayor cantidad de tiempo. ADDM permite profundizar e identificar
las causas raíz de los problemas en vez de sólo señalar los síntomas, e informa el impacto de
dicho problema sobre todo el sistema. En el caso de hacer una recomendación informa acerca
de los beneficios que pueden esperarse en términos de tiempo.

5
Troubleshooting, es una búsqueda lógica y sistemática del origen del problema para que pueda ser
resuelto y así el equipo o proceso pueda ser puesto en funcionamiento otra vez.
 39

ADDM comienza su análisis centrándose en las actividades en las que la base de datos
emplea la mayor parte del tiempo y luego profundiza mediante la realización de un
sofisticado árbol de clasificación de problemas.

Al desarrollar el árbol de clasificación, la intención principal fue enfrentar los problemas

más comunes y profundizar en sus causas raíz en vez de sólo informar acerca de los síntomas.
Algunos de los problemas más comunes que detecta ADDM incluyen:

 Cuellos de botellas de CPU

 Administración de conexión poco eficaz.

 Análisis excesivos.

 Contención de bloqueo.

 Capacidad ES.

 Resolución del tamaño de las estructuras de memoria de Oracle, por ejemplo PGA,
caché de bufer, búfer de archivos.

 Sentencias SQL de carga pesada.

 Mucho tiempo PL/SQL y Java.

 Carga pesada de puntos de control y causa, por ejemplo, archivos pequeños.

 Problemas específicos de RAC.

2.4.2 Ajuste de aplicación

Los problemas de diseño de aplicación constituyen la causa principal de problemas de

rendimiento. Ni los desarrolladores, con toda su habilidad en materia de ajustes, ni los DBA
ni los administradores de sistemas, pueden compensar la realización provocada por las
 40

deficiencias de estructura y diseño de la aplicación. Por lo tanto, una parte fundamental del
ajuste de rendimiento del sistema de la base de datos es el ajuste de las sentencias SQL.

Dado que el optimizador de consultas toma decisiones cruciales que ejercen un gran
impacto en el rendimiento de una consulta, como por ejemplo, si es conveniente utilizar un
índice o no, qué técnicas de unión utilizar si la consulta tiene que ver con la unión de tablas
múltiples, etc.

Si bien Oracle Database proporciona la mejor tecnología de optimización de consultas

posibles, la cual maximiza el rendimiento aplicación / consulta sin requerir la intervención
de un administrador en la mayoría de los casos, todavía pueden llegar a existir algunos casos
en los cuales la naturaleza de la aplicación o la distribución de los datos pueda provocar que
algunas sentencias SQL consuman un porcentaje inusualmente alto de los recursos totales
del sistema. En este tipo de situación, el proceso de ajuste SQL consta de tres pasos
principales:

 Analizar la historia de las ejecuciones SQL pasadas disponibles en el sistema (por

ejemplo las estadísticas del caché de cursor almacenadas en V$SQL) para identificar
cargas pesadas o las principales sentencias SQL que sean responsables de la carga de
trabajo de las aplicaciones y los recursos del sistema.
 Verificar los planes de ejecución producidos por el optimizador de consultas para
estas sentencias funcionen razonablemente bien.
 Tomar todas las medidas correctivas posibles a fin de generar planes de ejecución
mejores para las sentencias SQL de bajo rendimiento.

Con la ayuda de estas herramientas de la administración del rendimiento (AWR y

ADDM), así para lograr un buen rendimiento y ajuste de aplicación en el Sistema Gestor de
Base de Datos. La metodología propuesta está compuesta por etapas y cada etapa por fases:
 41

2.4.3 PRIMERA ETAPA: Recolección y Análisis de Información

Etapa en la que se recolectará información en un determinado tiempo, de una fecha a

otra del estado del Sistema Gestor de Base de Datos, para su posterior interpretación de las
áreas que ocasiona un bajo rendimiento.

Esta etapa contiene las siguientes fases:

Fase 1.1 Configurar el Monitor de Diagnóstico de Base de Datos Automático (ADDM)

En esta fase para empezar se debe configurar el parámetro STATISTICS_LEVEL,
luego se configura el parámetro DBIO_EXPECTED y por último se debe gestionar las
instantáneas (snapshots).

STATISTICS_LEVEL. Especifica el nivel de recopilación de estadísticas de la base de

datos y del sistema operativo. Oracle recopila estas estadísticas para diferentes propósitos,
incluía la toma de decisiones de autogestión.

DBIO_EXPECTED. El análisis ADDM del rendimiento de E/S depende parcialmente de

un solo argumento DBIO_EXPECTED, que describe el rendimiento esperado del subsistema
de E/S. El valor de argumento DBIO_EXPECTED es tiempo promedio que se tarda en leer
un solo bloque de base de datos, en microsegundos. Oracle Database usa el valor
predeterminado de 10 milisegundos, que es un valor apropiado para la mayoría de los discos
duros.

GESTIONAR LAS INSTANTÁNEAS (SNAPSHOTS). Los datos de intervalo de la

instantánea es analizada por ADDM y AWR compara la diferencia entre las instantáneas de
SQL para determinar que estados de la captura basada en el efecto de la carga del sistema.
 42

Fase 1.2 Monitorización del uso de memoria

Fase para monitorizar la utilización de memoria, de ser así optimizar el uso de
recursos y la latencia de las consultas y administrar las estructuras de memoria de Oracle para
proporcionar estadísticas de PGA y SGA en las últimas 24 horas.
Fase 1.3 Monitorización de E/S a disco
Fase de monitorización de la utilización actual de E/S a disco, alertas, tiempo de
servicio más larga, durante la última hora y de las últimas 24 horas.

Fase 1.4 Interpretación de los resultados del Monitor de Diagnóstico de Base de Datos
Automático (ADDM).
Última fase de la etapa 1, donde serán representados como un conjunto de
conclusiones y pertenece a uno de estos tres tipos:
 Problema. Resultados que describen la causa de un problema de rendimiento
de bases de datos.
 Síntoma. Resultados que contienen información que a menudo conducen a
encontrar uno a más problemas.
 Información. Resultados que se usan para reportar las áreas del sistema que
no tienen un impacto en el rendimiento.
2.4.4 SEGUNDA ETAPA: Afinamiento de las Estructuras de Memoria

Etapa donde se tomará en cuenta para hacer la optimización son:

 Conjunto compartido (Shared Pool).

 Cache de Buffer de Base de Datos (Data Buffer Cache).
 Cache de Buffer de Redo Log (Redo Log Buffer Cache).
 43

Fase 2.1 Ajuste del conjunto compartido (Shared Pool)

En el Shared Pool mantiene el diccionario de datos y las áreas compartidas de las
órdenes SQL que solicitan para su procesamiento. Para mejorar el rendimiento de esta
estructura es definir el uso compartido de cursores.

Fase 2.2 Ajuste del Caché de Buffer de Base de Datos (Data Buffer Cache)
Data buffer caché, donde mantiene los datos traídos por las órdenes SQL de los
usuarios conectados a la base de datos. Está definido por su parámetro de inicialización.

Fase 2.3 Ajuste del Caché de Buffer de Redo Log (Redo Log Buffer Cache)
Redo log buffer, aquí se registran los cambios hechos a la base de datos. Aquí se
necesita del espacio que necesitan los procesos del servidor en el buffer de redo log sea
suficiente.

2.4.5 TERCERA ETAPA: Afinamiento de las Estructuras Físicas

En esta etapa se debe reducir la actividad de un disco sobrecargado, mover los

archivos más utilizados a un disco menos activo. También utilizar el método OFA
(Arquitectura Flexible Óptima) para aprovechar la capacidad del sistema operativo.

Fase 3.1 Ajuste de los Archivos de Datos (Data Files)

Estos archivos sirven para el almacenamiento físico de las tablas, índices o
agrupamientos (clusters) y procedimientos. Estos archivos, son los únicos que contienen los
datos de los usuarios de la base de datos. En esta fase se deben separar en diferentes discos
para evitar demoras en E/S.

Fase 3.2 Ajuste de los archivos Redo Log (Redo Log Files)
 44

La estructura más crucial para las operaciones de recuperación es el Redo Log que
consta de dos o más archivos pre asignados que almacenan todos los cambios realizados en
la base de datos a medida que ocurren. Cada instancia de una base de datos Oracle tiene
asociado un redo log para proteger la base de datos en caso de falla de la instancia. En esta
fase, al igual que los archivos de datos, los redo log deben ser ubicados en diferentes discos.

Fase 3.3 Ajuste de los archivos de Control (Control Files)

Cada base de datos Oracle tiene un Control File, que es un pequeño archivo binario que
registra la estructura física de la base de datos. El Control File incluye:

 Nombre de la base de datos

 Nombres y ubicaciones de archivos de datos y Redo Logs.
 El timestamp de la creación de la base de datos.
 El número de secuencia de registro actual.
 Información del checkpoint (Punto de control).

Estos archivos también deben ser distribuidos en diferentes discos.

2.5 JUSTIFICACIÓN DEL USO DE METODOLOGÍA

Como el propósito del método es la necesidad de obtener a través de la monitorización

de una medición de un antes y después del rendimiento del Sistema Gestor de Base de Datos
Oracle 11g y después de haber realizado el tuneo, interpretar los resultados obtenidos en
ambos tiempos y comparar los mismos para determinar la mejora del Sistema Gestor de Base
de Datos.
 45

2.6 ANÁLISIS DE COSTOS Y BENEFICIOS

Costos

Uno de los costos más grandes de implementación y el afinamiento de Oracle es el costo

de capacitación para que los usuarios mantengan un entorno Oracle adecuado. Oracle
recomienda que se tenga cuando menos un administrador de base de datos. La capacitación
consiste en un curso de:

 Identificación de problemas de sentencias SQL

 SQL Server Management
 Uso de métrica y alertas
 Uso de las herramientas AWR, ADDM
 Ajuste del buffer caché
 Tuning PGA y espacio temporal
 Gestión automática de memoria
 Tuning de E/S
 Tuning de rendimiento
 Utilización statspack
Como ser también, ajustes de red, pruebas y respaldos.

Beneficios

Si en un año ocurren varios cambios en el crecimiento de la base de datos y si se

realizaría la contratación de personal externo para realizar el afinamiento (tunning),
conllevaría a generar gastos excesivos y constantes a la institución. Por lo que teniendo un
personal capacitado y con las herramientas adecuadas se evita estos gastos constantes.
 46

El monitoreo de los procesos de la base de datos será realizado 24x7 a través de las
herramientas.
Al disponer de un monitoreo 24/7 es posible detectar rápidamente los diversos cuellos
de botellas de la base de datos que pudieran llegarse a presentar

Las herramientas de afinamiento ofrecidas son de última generación cuenta con

experiencia en el mercado y soporte reconocido internacionalmente.

Se ha comprobado que con herramientas de monitoreo, diagnóstico y afinamiento de

la base de datos Oracle es posible llevar a cabo dichos trabajos en forma más rápida y
eficiente versus el mismo trabajo realizado en forma manual, representando un significativo
ahorro de horas hombre así como de precisión en los resultados.
 47

CAPITULO III

EVOLUCIÓN Y PUESTA EN MARCHA

La integridad de este capítulo está orientado a resolver problemas con relación al

afinamiento de la base de datos Oracle 11g de la Agencia Nacional de Hidrocarburos,
aplicando la metodología descrita en el anterior capítulo.

La realización de la planeación estratégica representa el sistema actual. La realización

del análisis representa la identificación de los elementos necesarios para poder implementar
el afinamiento.

Según la metodología aplicada no hace uso particular de ciertas características para

el análisis costo y beneficio.

Para iniciar la resolución de los problemas, es definir síntomas primero. Los síntomas
más comunes de fallas en el desempeño del SQL son CPU, memoria, red, cuellos de botella
I/O y consultas lentas.

3.1 PLANIFICACIÓN Y ESTRATÉGIA

Una vez realizada la monitorización se deben interpretar los resultados para entender a
cabalidad como se encuentra el rendimiento del motor.
 48

La interpretación se la realizará por secciones, cada sección tendrá el contenido en los

reportes de los cuatro días, de acuerdo a las etapas y fases aplicadas en el anterior capítulo:

 Interpretación de la primera sección

La primera sección consta de las lecturas lógicas, lecturas físicas y transacciones
realizadas que se mostrarán en (cantidad / segundo).
 Interpretación de la segunda sección
Los elementos importantes son las no esperas en el buffer, acceder a la memoria (hit)
y no a disco (miss) para el data buffer cache, utilizar una misma consulta y la no
espera del redo log buffer cache.
 Interpretación de la tercera sección
Se mostrarán en los cuatro días a los tablespace que más se acceden en escritura es el
UNDOTBS y lectura el SYSTEM. Siendo que un tablespace es un almacén lógico de
los ficheros de la base de datos. Cada tablespace posee uno o varios ficheros
(datafiles) donde almacena toda la información.

Cuando se crea una base de datos, hay que crear al menos un tablespace, que por
defecto es SYSTEM. Igualmente, cuando se crea un tablespace, se debe indicar al
menos un datafile que formará parte de este datafile (posteriormente se pueden añadir
más datafiles al tablespace). El datafile es un fichero físico al que tendremos que
asignar un directorio, un nombre y un tamaño inicial que posteriormente se podrá
ampliar según las necesidades.

Este tablespace es el que contendrá información de los usuarios SYS y SYSTEM que
son los usuarios que tienen la información necesaria para que funcione la base de
datos.
 49

Por tanto, el tablespace SYSTEM es una pieza clave para el buen funcionamiento de
nuestra base de datos, por lo que es una buena práctica crear al menos otro tablespace
donde almacenar el resto de usuarios que vayamos creando. Podría ahorrarnos de:

- Un bloque completo de la base de datos si ocurre algo grave al tablespace

SYSTEM.
- Llenar el tablespace SYSTEM pudiendo provocar la parálisis de toda la base
de datos.
 Interpretación de la cuarta sección
En esta sección se debe observar el comportamiento del PGA de aciertos en memoria.

3.2 ANÁLISIS Y AFINAMIENTO

La metodología propuesta está compuesta por tres etapas, donde la principal etapa es
recolectar información sobre cómo se encuentra el rendimiento del Sistema Gestor de Base
de Datos 11g, una vez obtenida esta información se debe realizar la interpretación.

La segunda etapa indica los procedimientos que se deben seguir para optimizar el
rendimiento de las estructuras de memoria.

La tercera etapa indica como optimizar las E/S a disco y optimizar el rendimiento de las
estructuras físicas (de almacenamiento), como ser los Archivos de Datos, Archivos Redo Log
y Archivos de Control.

Una vez aplicada la metodología y transcurrido un tiempo de uso del Sistema Gestor de
Base de Datos Oracle 11g, la metodología podría volver a ser aplicada pero no
necesariamente siguiendo un orden secuencial, ya que la estructura que necesite ser afinada
dependerá de la monitorización.
 50

En la Figura 3.1 se puede observar la estructura de la metodología, la cual está compuesta

por etapas y cada etapa por fases.
 51

Figura 3. 1 Metodología propuesta

Fuente: Elaboración propia
 52

3.2.1 Primera Etapa: Recolección y Análisis de Información

En esta etapa se debe recolectar información del estado en el que se encuentra el

rendimiento del Sistema Gestor de Base de Datos, la información debe ser recopilada en un
determinado tiempo (de una fecha a otra, ese tiempo puede ser cuando el Sistema Gestor de
Base de Datos es exigido por muchas actividades realizadas sobre el).

La información obtenida del estado del rendimiento del Sistema Gestor de Base de
Datos debe ser interpretada, interpretar cuál es el problema, cuales son los síntomas, en si
cuales son las áreas del SGBD que tiene mayor exigencia lo que ocasiona un bajo
rendimiento.

Fase 1.1 Configurar el Monitor de Diagnóstico de Base de Datos Automático (ADDM)

Esta fase describe como configurar el monitor de diagnóstico de base de datos

automático (ADDM).

Para empezar se debe configurar el parámetro STATISTICS_LEVEL, luego se

configura el parámetro DBIO_EXPECTED.

STATISTICS_LEVEL. Especifica el nivel de recopilación de estadísticas de la base de

datos y del sistema operativo. Oracle recopila estas estadísticas para diferentes propósitos,
incluía la toma de decisiones de autogestión.

DBIO_EXPECTED. El análisis ADDM del rendimiento de E/S depende parcialmente de

un solo argumento DBIO_EXPECTED, que describe el rendimiento esperado del subsistema
de E/S. El valor de argumento DBIO_EXPECTED es tiempo promedio que se tarda en leer
un solo bloque de base de datos, en microsegundos. Oracle Database usa el valor
 53

predeterminado de 10 milisegundos, que es un valor apropiado para la mayoría de los discos

duros.
Y por último se debe gestionar las instantáneas (snapshots).

A) Configurar el nivel de colección de instantáneas

El Monitor de Diagnóstico de Base de Datos Automático está activado por defecto y
es controlado por el parámetro STATISTICS_LEVEL el cual específica el nivel de
colección de las instantáneas. El parámetro se encuentra configurado por defecto en
TYPICAL, esto asegura a la mayoría de las estadísticas requeridas para la
administración y funcionamiento de la base de datos, también provee mejor
rendimiento. El valor por defecto es adecuado para el ambiente de producción de la
Agencia Nacional de Hidrocarburos, si se tomara el valor ALL se tendría mucha
contención a la base de datos.

A continuación se muestra como configurar este parámetro (esto conectado como

usuario SYS con el rol DBA).

ALTER SYSTEM SET STATISTICS_LEVEL=TYPICAL;

Para verificar la información sobre la situación de las estadísticas o la consola de

control del parámetro STATISTICS_LEVEL vea la vista dinámica
V$STATISTICS_LEVEL.

B) Configurar el Desempeño de E/S del Subsistema

DBIO_EXPECTED describe el desempeño esperado de la E/S del subsistema, el
valor que tenga este parámetro es el tiempo medio que se tarda en leer un bloque de
base de datos única, en microsegundos. La base de datos Oracle utiliza el valor por
defecto de 10 milisegundos, que es un valor adecuado para la mayoría de los discos
 54

duros. Si el hardware es significativamente diferente, se debe considerar utilizar un

valor diferente.

Para determinar el ajuste correcto del parámetro DBIO_EXPECTED se debe:

Paso 1. Medir el tiempo promedio de lectura de un único bloque de base de datos
para su hardware. Esta medida debe ser tomada de las E/S al azar, se debe verificar
si utiliza discos duros estándar. Los valores típicos para unidades de disco duro son
entre 5000 y 20000 microsegundos.

Paso 2. Establecer el valor de una sola vez para todas las ejecuciones del Monitor de
Diagnóstico de Base de Datos Automático. Por ejemplo, si el valor medio en
microsegundos es 8000, se debe ejecutar el siguiente comando como usuario SYS.

EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER (‘ADDM’,

‘DBIO_EXPECTED’, 8000);

C) Gestión de las instantáneas

Por defecto el repositorio de Carga de Trabajo Automática (AWR) genera
instantáneas de datos de rendimiento una vez cada hora y mantiene las estadísticas de
trabajo en el depósito de 7 días. Es posible cambiar los valores predeterminados para
el intervalo de imagen y el período de retención. Los datos de intervalo de la
instantánea es analizada por ADDM. AWR compara la diferencia entre las
instantáneas de SQL para determinar qué estados de la captura, basada en el efecto
sobre la carga del sistema. Esto reduce el número de sentencias SQL que deben ser
capturados en el tiempo. La gestión de instantáneas involucra:

Crear las instantáneas. Es posible crear manualmente las instantáneas, pero esto
normalmente no es necesario porque el AWR genera imágenes de los datos de
 55

rendimiento de una vez cada hora por defecto. En algunos casos, sin embargo, puede
ser necesario crear manualmente para capturar instantáneas en diferentes tiempos,
como cuando se quiere comparar datos de rendimiento a través de un período de
tiempo más breve que el intervalo de la instantánea.

En la Figura 3.2 observamos la creación de la instancia, donde el ID de la imagen

que se creó es 2284.

Figura 3. 2 Instantánea creada

Fuente: Elaboración propia

Por defecto, el repositorio de carga de trabajo automático genera imágenes de los

datos de rendimiento una vez cada hora. Si se prefiere, se puede modificar los
valores por defecto de ambos, el intervalo entre instantáneas y su período de
retención. En este caso está generando instantáneas cada 15 minutos.
 56

Fase 1.2 Monitorización del uso de memoria

Esta fase describe la manera de monitorizar la utilización de memoria. Para

monitorizar la memoria:

Paso 1. Se debe comprobar la utilización de la memoria actual con el gráfico utilización de

memoria. El gráfico muestra la cantidad de memoria que se está utilizando actualmente.
Durante horas normales de trabajo, el valor no debe superar el umbral de alerta.

En la Figura 3.3 contiene las estadísticas de utilización de memoria y las alertas

generadas en las últimas 24 horas. La utilización de memoria está cerca, pero no supera el
valor umbral de alerta (99 por ciento) de 16:00 pm a 23:00 pm, por lo que el aviso no se
creará. Si se nota un aumento inesperado en este valor que se mantiene a través de horas
normales de trabajo, es muy probable que un problema de rendimiento de memoria pueda
existir.

Figura 3. 3 Página de la utilización de memoria

Fuente: ORACLE
 57

Paso 2. Verificar la utilización actual de intercambio para determinar cuánto espacio de

intercambio se está utilizando actualmente. Durante horas normales de trabajo, el valor no
debe superar el umbral.

Si la utilización de intercambio está por debajo del umbral de alerta, el aviso no se

creará. Si se nota un aumento inesperado en este valor que se mantiene a través de horas
normales de trabajo, es muy probable que tenga un problema de rendimiento de memoria.

Paso 3. Así como también se debe verificar los procesos de rendimiento en la sección de los
Procesos Top 10. Si un proceso está tomando demasiada memoria, entonces este proceso
debe ser investigado.

Paso 4. Si un problema de rendimiento de la memoria se identifica, se puede tratar de resolver

la cuestión por:

 Uso de Gestión Automática de Memoria Compartida para la gestión de la SGA.

 Uso de Gestión Automática de PGA para la gestión de la ejecución de memoria de
SQL.
 Evitar correr muchos procesos que utilizan mucha memoria.
 Reducir paginación o intercambio.
 Reducir el número de cursores abiertos y el fuerte análisis sintáctico con el cursor
compartido.

Fase 1.3 Monitorización de E/S a disco

Esta fase describe como monitorizar la utilización de E/S a disco. Para monitorizar la
utilización de E/S a disco:
 58

Paso 1. En el Resumen del Rendimiento, se debe verificar Detalles de Disco. Donde se

tendrá información de la vista de Detalles de Disco.

La Figura 3.4 Página detalles de disco contiene el uso de E/S a disco y el tiempo de
servicio de las estadísticas recogidas durante la última hora y la parte superior de disco de
dispositivos ordenados por porcentaje ocupado.

Figura 3. 4 Página detalles de disco

Fuente: ORACLE

Paso 2. Se debe verificar la utilización actual de E/S. El gráfico anterior muestra el número
de E/S a disco que se realiza por segundo.

Paso 3. Se debe verificar también las estadísticas de las últimas 24 horas de E/S a disco.
 59

Las estadísticas contienen la utilización de disco y las alertas generadas en las últimas
24 horas. Si se nota un aumento inesperado en este valor que se mantiene normal a través de
horas de trabajo, puede existir un problema de desempeño de E/S a disco y debe ser
investigado.

Paso 4. Verificar también el tiempo de servicio actual de E/S, el cual muestra el tiempo de
servicio más largo para E/S a disco.

Las estadísticas relacionadas con alertas generadas en las últimas 24 horas contienen
el tiempo de servicio de E/S. Si se nota un aumento inesperado en este valor que se mantiene
normal a través de horas de trabajo, puede existir un problema de desempeño de E/S a disco
y debe ser investigado.

Paso 5. En los Detalles del Disco, se debe comprobar si en un alto porcentaje de las veces, si
es así, este disco debe ser investigado.

En la Figura 3.5 Sección top disk devices se puede ver la unidad que aloja la Base
de Datos Oracle (unidad u07), es ocupada sólo alrededor de 1,3 por ciento del tiempo y no
parece ser un problema de rendimiento de disco.

Figura 3. 5 Sección top disk devices

Fuente: ORACLE
 60

Paso 6. Si un problema de E/S a disco es identificado se puede tratar de resolver el problema:

 Utilizando la Gestión Automática de Almacenamiento (ASM) para gestionar el
almacenamiento de la base de datos.
 Repartir la carga en cada disco para la distribución de E/S.
 Mover archivos, tales como Archive Logs y Redo Logs, a diferentes discos.
 Almacenando los datos necesarios en la memoria para reducir el número físico de
E/S.
Fase 1.4 Interpretación de los resultados del Monitor de Diagnóstico de Base de Datos
Automático (ADDM).

Los resultados del análisis del Monitor de Diagnóstico de Base de Datos Automático son
representados como un conjunto de conclusiones y pertenece a uno de estos tres tipos:

 Problema. Resultados que describen la causa de un problema de rendimiento de base

de datos.
 Síntoma. Resultados que contienen información que a menudo conducen a encontrar
uno a más problemas.
 Información. Resultados que se usan para reportar las áreas del sistema que no tienen
un impacto en el rendimiento.

Cada problema encontrado es cuantificado con un estimado de la porción del tiempo de

la base de datos que resulte del problema de rendimiento que se encontró.

Cuando un problema específico tiene múltiples causas, el Monitor de Diagnóstico de

Base de Datos Automático (ADDM) puede reportar múltiples hallazgos. En este caso, el
impacto de estos resultados puede contener la misma porción de tiempo de la Base de Datos.
Porque los problemas de rendimiento pueden solaparse, la recapitulación de todos los
reportes de los impactos encontrados puede ocupar más de 100 por ciento del tiempo de la
 61

Base de Datos. Por ejemplo, si un sistema realiza mucha lectura de actividades de E/S, el
Monitor de Diagnostico de Base de Datos Automático (ADDM) puede reportar una consulta
SQL de uso del 50 por ciento del tiempo de la base de datos a la actividad de E/S como un
hallazgo y una comprensión de que el buffer cache es responsable del uso del 75 por ciento
del uso del tiempo de la base de datos como otro hallazgo.

Un problema encontrado puede ser asociado con una lista de recomendaciones para la
reducción del impacto de un problema de rendimiento. Cada recomendación tiene un
beneficio que un estimado de una porción del tiempo de la base de datos puede ser grabado.
Cuando una recomendación múltiple es asociada con los hallazgos del Monitor de
Diagnóstico de Base de Datos Automático (ADDM), las recomendaciones pueden contener
alternativas para solucionar el mismo problema. En este caso, la recopilación de los
beneficios puede contener alternativas de solución al mismo problema. No es necesario
aplicar la recomendación para resolver el mismo problema.

Las recomendaciones están compuestas de acciones e ideas. Es necesario aplicar

todas las acciones de una recomendación para ganar el beneficio estimado de la
recomendación. Las ideas explican porque los conjuntos de acciones fueron recomendados
y provee la información adicional para la implementación de las recomendaciones sugeridas.
Una acción administrativa puede presentar múltiples soluciones para el entorno. Si este es el
caso, escoge la mejor solución para implementar.

3.2.2 Segunda Etapa: Afinamiento de las Estructuras de Memoria

En esta etapa las estructuras de memoria que se tomaran en cuenta para hacer la
optimización son:

 Conjunto compartido (Shared Pool).

 62

 Cache de Buffer de Base de Datos (Data Buffer Cache).

 Cache de Buffer de Redo Log (Redo Log Buffer Cache).

Estas estructuras de memoria son muy importantes a la hora de optimizar el rendimiento

del Sistema Gestor de Base de Datos Oracle 11g, ya que de ellas depende mucho si se tiene
que recurrir continuamente a disco (se debe mantener en un mínimo la E/S de disco).

Fase 2.1 Ajuste del conjunto compartido (Shared Pool)

Un fallo de búsqueda en la caché de diccionario de datos o en la caché de biblioteca suele

ser más costoso que un fallo en la mayoría de las otras estructuras de memoria SGA. Por lo
tanto, el ajuste del conjunto compartido (shared pool) es una prioridad.
Si el conjunto compartido es demasiado grande, el rendimiento puede disminuir porque:

 Hay menos memoria para otras estructuras de memoria (con lo que se reduce el
rendimiento).
 La existencia de muchas entradas puede hacer que encontrar contenido actual resulte
más lento que en un conjunto pequeño.

El tamaño del conjunto compartido se define con el parámetro de inicialización

SHARED_POOL_SIZE. Su valor por defecto es de 8388608 bytes (8 MB).

El SHARED_POOL_SIZE del Sistema Gestor de Base de Datos Oracle 11g de la

Agencia Nacional de Hidrocarburos es de 10485760000 bytes (10000 MB).

Para mejorar el rendimiento de esta estructura lo primero a realizar es definir el uso

compartido de cursores. El valor del parámetro CURSOR_SHARING determina el nivel en
que las sentencias SQL compartirán cursores. El valor por defecto y con el que se encuentra
es Exact (las sentencias SQL deben ser idénticas para compartir cursores), debemos
 63

modificar este parámetro al valor Similar (las sentencias SQL similares compartirán cursores,
siempre que sus planes de ejecución respectivos sean los mismos).

A continuación, se muestra como alterar este parámetro (esto como usuarios SYSTEM
con rol DBA en el prompt de SQL*):

ALTER SYSTEM SET CURSOR_SHARING=SIMILAR;

Lo segundo a realizar es asignarle más tamaño al conjunto compartido (para esto se debe
quitar espacio al conjunto grande, su tamaño es de 112 MB). A continuación se muestra como
alterar estos dos parámetros (LARGE_POOL_SIZE para el conjunto grande y
SHARED_POOL_SIZE para el conjunto compartido, siguiendo ese orden):

 ALTER SYSTEM SET LARGE_POOL_SIZE=52 M;

 ALTER SYSTEM SET SHARED_POOL_SIZE=10056 MB;

Si no se disminuyera el tamaño al conjunto grande nos saldría un error, en el cual nos

indicaría que el tamaño de SGA_MAX_SIZE no permite que se le pueda asignar más
memoria al conjunto compartido.

Fase 2.2 Ajuste del Caché de Buffer de Base de Datos (Data Buffer Cache)

La caché de buffers puede consistir en subcachés independientes para los conjuntos de

buffers y para varios tamaños de bloques.

El parámetro DB_BLOCK_SIZE determina el tamaño de bloque primario, que es el

utilizado para el tablespace system y las cachés de buffers primarias (RECYCLE, KEEP y
DEFAULT).
 64

El tamaño del del caché de buffer de base de datos está definido por el parámetro de
inicialización DB_CACHE_SIZE.

El Sistema Gestor de Base de Datos Oracle 11g de la Agencia Nacional de Hidrocarburos

maneja un DB_CACHE_SIZE de 24125636608 bytes (24008 MB), los conjuntos de buffer
KKEP, RECYCLE y DEFAULT tienen como valor 0, lo cual indica que están deshabilitados.

Para ajustar esta estructura se debe habilitar el cojunto de buffer KEEP (contiene datos
que se mantienen en la caché de buffers el máximo tiempo posible), que está definido por el
parámetro de inicialiación DB_KEEP_CACHE_SIZE, asignándole un tamaño de
8388608000 bytes (8000 MB), esto significa que el tamaño del data buffer cache será de
15737028608 (15008 MB).

A continuación se muestra como alterar los dos parámetros (esta alteración tiene un
orden, primero se debe disminuir el tamaño de DB_CACHE SIZE y luego recién se debe
asignar el tamaño a DB_KEEP_CACHE_SIZE).
 ALTER SYSTEM SET DB_CACHE_SIZE=15008 MB;
 ALTER SYSTEM SET DB_KEEP_CACHE_SIZE=8000 MB;

Si primero se asignara tamaño a DB_KEEP_CACHE_SIZE saldría un error, el cual

indica que el tamaño de SGA_MAX_SIZE no alcanza para poder asignar un valor al conjunto
de buffer KEEP.

Fase 2.3 Ajuste del Caché de Buffer de Redo Log (Redo Log Buffer Cache)

Los procesos de Oracle Server copian los registros de redo del espacio de memoria
del usuario en el buffer de redo log para cada sentencia DML o DDL. Los registros de redo
 65

contienen la información necesaria para reconstruir o rehacer los cambios realizados en la

base de datos y ocupan un espacio continuo y secuencial en el buffer.

Ajustar el buffer de redo log significa asegurarse de que el espacio que necesitan los
procesos del servidor en el buffer de redo log sea suficiente. Sin embargo, un espacio
excesivo reducirá la cantidad de memoria que se puede asignar a otras áreas.

El tamaño de redo log buffer viene definido por el parámetro LOG_BUFFER, tiene
un valor por defecto de 512 K o 128 K * el valor de CPU_COUNT (número de procesadores
con los que cuenta la instancia Oracle). El tamaño del LOG_BUFFER del Sistema Gestor de
Base de Datos Oracle 11g de la Agencia Nacional de Hidrocarburos es de 5242880 bytes (5
MB) lo que indica que la instancia cuenta con diez procesadores.

Entonces, si se quiere ajustar el tamaño de LOG_BUFFER se debe aumentar o

disminuir la cantidad de procesadores o bien realizar sentencias COMMIT frecuentes para
limpiar el buffer.

3.2.3 TERCERA ETAPA: Afinamiento de las Estructuras Físicas

Para afinar estas estructuras se debe reducir la actividad en un disco sobrecargado, se

debe mover a un disco menos activo uno o varios de los archivos a los que se accede más
intensamente.

También se debe utilizar OFA (Arquitectura Flexible Óptima). OFA es un método para
configurar la base de datos Oracle. Esta arquitectura aprovecha las capacidades del Sistema
Operativo y de los subsistemas de disco para crear una configuración fácil de administrar que
permita una flexibilidad máxima para bases de datos de alto rendimiento y en crecimiento.
Sus características son:
 66

 Separa archivos por tipo y uso

 Separa archivos en diferentes discos
 Brinda punto de inicio para un alto rendimiento

La sintaxis es la siguiente:

/PM/H/U/PRODUCT/V/

Donde:

 PM es el punto de montaje
 H es el propósito del software.
 U es el usuario de Sistema Operativo dueño de la instalación.
 PRODUCT es una constante.
 V es la versión del software.

Fase 3.1 Ajuste de los Archivos de Datos (Data Files)

Como los archivos de datos se encuentran dentro de los tablespaces entonces se deben
separar en diferentes discos, también se deben separar a aquellos a los cuales el acceso es
intenso, esto para evitar demoras en la E/S a disco.

Se deben colocar en un disco D01 los tablespaces SYSTEM y SYSAUX, en el disco

D02 los tablespaces UNDOTBS y USERS, en el disco D03 los tablespaces TEMP y
EXAMPLE (si se tiene esquemas de ejemplo), en el disco D04 el tablespace DATA (son
datos que se encuentran en tablas, de diferentes usuarios) y en el disco D05 el tablespace
INDEX (son los índices para las columnas de tablas). Los tablespaces DATA e INDEX van
en diferentes discos ya que son a los que más se acceden (con consultas o DML o DDL).
 67

Todo esto se lo realiza a la hora de instalar la Base de Datos Oracle 11g.

Fase 3.2 Ajuste de los archivos Redo Log (Redo Log Files)

Al igual que los archivos de datos, los archivos redo log deben ser ubicados en
diferentes discos. Los archivos redo log pueden ser multiplexados, existen tres grupos de
redo logs, los cuales a su vez cuentan con tres miembros.

Los primeros miembros de los grupos deben ir en el disco D01, los segundos
miembros de los grupos deben ir en disco D02 y los últimos miembros de los grupos deben
ir en el disco D03.

Todo esto es para que el proeso en segundo plano LGWR al escribir del log buffer
cache a el archivo redo log no tenga esperas, no se tenga que escribir en serie, con esto se
escribirá en paralelo a los diferentes discos.

El distribuir los miembros de los grupos en diferentes discos se realiza a la hora de

instalar la Base de Datos Oracle 11g.
Fase 3.3 Ajuste de los archivos de Control (Control Files)

Estos archivos al igual que los archivos de datos y los archivos redo log deben ser
distribuidos en diferentes discos. El primer archivo de control debe ir en el disco D03, el
segundo archivo de control debe ir en el disco D04 y el último archivo de control debe ir en
el disco D05.

La distribución de estos archivos se la realiza a la hora de la instalación de la Base de

Datos Oracle 11g.
 68

3.3 MEDICIÓN DEL RENDIMIENTO DEL SISTEMA GESTOR DE BASE DE

DATOS ORACLE 11G

Al igual que la monitorización inicial (antes de implementar la metodología), la medición

se realizará durante cuatro días (lunes 14, martes 15, miércoles 16 y jueves 17 de diciembre),
a las 09:30 y 15:30 (cada día). Para esto se utilizará el paquete SCHEDULER que automatiza
tareas, esto para automatizar la toma de fotografías las horas indicadas.

La Figura 3.6 Recopilación de estadísticas muestra como automatizar la toma de

fotografías a las 09:30 y 15:30 durante cuatro días.

Figura 3. 6 Recopilación de estadísticas

Fuente: Elaboración propia
 69

Una vez obtenidas las snapshots se procede a elaborar los reportes diferenciales por
días, estos reportes se los generan con ADDM. A diferencia de Statspack, ADDM genera el
reporte en HTML, lo cual hace más sencilla la forma en la cual se busca la sección que se
desea analizar.

A continuación se muestra parte del reporte, parte que es importante para verificar la
optimización del Sistema Gestor de Base de Datos Oracle 11g. Se muestra la monitorización
del primer día (lunes 14 de diciembre), el resto de los días se encuentra en el ANEXO C.

Día 1 (lunes 14/12/2020)

Cache Sizes

Instance Efficiency Percentages (Target 100%)

 70

En la Figura 3.7 Menú del reporte generado por ADDM se observa el menú que
genera ADDM a la hora de crear el reporte, esto para agilizar la búsqueda de la información
que se requiere analizar.

Figura 3. 7 Menú del reporte generado por ADDM.

Fuente: Informe ADDM.
 71

Los resultados de la aplicación de la metodología, se muestran en la medición del Buffer

Hit que indica los aciertos que se obtuvo en memoria al acceder a un bloque de datos Oracle
y no así el tener que acudir a disco para obtener la información requerida (esto acarrea el
problema de E/S a disco).

De acuerdo a nuestra monitorización realizamos la comparación con el porcentaje de

eficiencia del Buffer Hit obtenido antes y después de la implementación de la metodología.

En la Tabla 3 se muestra las monitorizaciones con sus respectivos Hits antes de

implementar la metodología.

Tabla 3. Hits por monitorización antes de implementar la metodología

Número de monitorización % de aciertos en memoria (Hits)

1 98.06
2 98.14
3 97.84
4 98.21

Fuente: Elaboración propia

En la Tabla 4 se puede observar las mediciones del rendimiento con sus respectivos Hits
después de haber aplicado la metodología.
 72

Tabla 4. Hits por monitorización después de aplicar la metodología

Número de monitorización % de aciertos en memoria (Hits)

1 99.10
2 99.38
3 99.24
4 99.4

Fuente: Elaboración propia

Por lo tanto la aplicación de la metodología basada en las buenas prácticas de afinamiento

de la corporación Oracle optimizó el rendimiento del Sistema Gestor de Base de Datos Oracle
11g de la Agencia Nacional de Hidrocarburos.

3.4 ESTUDIO DE FACTIBILIDAD ECONÓMICA

La factibilidad económica se refiere a los recursos económicos y financieros necesarios

para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos
básicos que deben considerarse son el costo del tiempo, el costo de la realización y el costo
de adquirir nuevos recursos.

Generalmente la factibilidad económica es el elemento más importante ya que a través

de él se solventan las demás carencias de otros recursos, es lo más difícil de conseguir y
requiere actividades adicionales cuando no se posee.

A continuación se detallan los costos del material de escritorio, costos de la recolección

y reproducción de información, costos de hardware, costos de licencias de software y el costo
de la implementación de la metodología.
 73

3.4.1 Costos fijos del proyecto

Los costos fijos son aquellos que no son sensibles a pequeños cambios en los niveles
de actividad (volumen de producción), sino que permanecen invariables ante esos cambios.

En la Tabla 5 se observa los costos del material de escritorio que han sido empleados
a lo largo del desarrollo del Proyecto de Grado.
Tabla 5. Costo de material de escritorio

DESCRIPCIÓN CANTIDAD COSTO COSTO TOTAL

UNITARIO
Paquetes de hojas 6 35 210
bond tamaño carta
Tinta negra 6 120 720
Tinta color cian 1 80 80
Tinta color magenta 1 80 80
Tinta color amarillo 1 80 80
TOTAL 1170

Fuente: Elaboración propia

En la Tabla 6 se encuentran los costos que implicaron la recolección y la

reproducción de información para la elaboración del Proyecto de Grado.

Tabla 6. Costos de recolección y producción de información

DESCRIPCIÓN COSTO
Internet 190
Fotocopias 200
Anillados 180
Transporte 60
TOTAL 630
 74

Fuente: Elaboración propia

En la Tabla 7 se muestra el costo de la implementación de la metodología, esto se

considera en horas consultorías de DBA junior.
Tabla 7. Costos de la aplicación de la metodología

DESCRIPCIÓN COSTO POR HORAS COSTO TOTAL

HORA EMPLEADAS
Implementación de 909.9 11 10008.9
la metodología

Fuente: PRETECO BOLIVIA

Por lo que el costo de la elaboración del Proyecto de Grado y su implementación

asciende a Bs. 1800 y Bs.10008.9 respectivamente

La factibilidad económica del presente Proyecto de Grado, se basa en la metodología de

investigación, Proyecto Factible, el cual permite la elaboración de una propuesta de un
modelo operativo viable, destinada a atender las necesidades específicas (rendimiento) que
tienen las bases de datos de la Agencia Nacional de Hidrocarburos a partir de un diagnóstico.

3.5 EVALUACIÓN DEL CUMPLIMIENTO

De acuerdo a los objetivos descritos en el punto 1.5.2:

a. Se recolectaron y se realizó el análisis de la información

 Se configuró el monitor de diagnóstico.
 Se monitorizó el uso de memoria.
 Se realizó la monitorización de E/S a disco.
 75

 Se realizó la interpretación de los resultados del Monitor de Diagnóstico de Base

de Datos Automático (ADDM).
b. Se realizó el afinamiento de las estructuras de memoria.
 Se realizó el ajuste del conjunto compartido (Shared Pool).
 Se realizó el ajuste del Cache de Buffer de Base de Datos (Data Buffer Cache).
 Se realizó el ajuste del Cache de Buffer de Redo Log (Redo Log Bufer Cache).
c. Se realizó el afinamiento de las estructuras físicas.
 Se realizó el ajuste de las E/S de los Arhivos de Datos (Data Files).
 Se realizó el ajuste de las E/S de los Archivos Redo Log (Redo Log Files).
 Se realizó el ajuste de las E/S de los Archivos Log Archivados (Archive Log
Files).
 76

CAPITULO IV

CONCLUSIONES Y RECOMENDACIONES

4.1 CONCLUSIONES

Una vez aplicada la metodología al Sistema Gestor de Base de Datos Oracle de la Agencia
Nacional de Hidrocarburos, se tiene las siguientes conclusiones:

 Se ha obtenido métricas del rendimiento del Sistema Gestor de Base de Datos que
ayudo a obtener información sobre cómo se encontraba antes y después del afinado.
 La estructura de pasos determinada como propuesta de solución para optimizar el
rendimiento del Sistema Gestor de Base de Datos Oracle 11g de la Agencia Nacional
de Hidrocarburos no sigue un orden secuencial estricto, la aplicación de las fases de
ajuste dependerán de los resultados de la monitorización (etapa de recolección y
análisis de información).
 La conjunción de varias técnicas y buenas prácticas de afinamiento para Base de
Datos Oracle, dio paso a la elaboración de una metodología para optimizar el
rendimiento del Sistema Gestor de Base de Datos Oracle 11g. La metodología es
adecuada para el entorno de producción del Motor de la Agencia Nacional de
Hidrocarburos (basado en sus recursos de hardware y software).
 Se aplicó en la metodología etapas y fases para la optimización del rendimiento del
Sistema Gestor de Base de Datos Oracle 11g basado en buenas prácticas de
afinamiento de la corporación Oracle.
 77

De acuerdo a nuestros resultados en las Tablas 3 y 4 del capítulo anterior podemos ver
una mejora del 1.04% el día 1, 1.24% el día 2, 1.4% el día 3 y 1.19% el día 4 haciendo un
total de un 5% de mejora en el rendimiento.

Es importante implementar un afinamiento que consiste en una serie de actividades

utilizadas para optimizar y maximizar los recursos del sistema, generando rapidez y
eficiencia, lo cual permite un mejor desempeño de la base de datos.

4.2 RECOMENDACIONES

Una vez aplicada la metodología al Sistema Gestor de Base de Datos Oracle 11g de la
Agencia Nacional de Hidrocarburos, se tienen las siguientes sugerencias:

 Se debe planificar la monitorización periódicamente para verificar el estado en el que

se encuentra el rendimiento del Motor.
 Otra forma de recopilar información de estadísticas de rendimiento del Sistema
Gestor de Base de Datos es utilizando las vistas dinámicas V$SYSSTAT,
V$SYSTEM_WAIT_CLASS, V$SGASTAT, V$EVENT_NAME y
V$SYSTEM_EVENT.
 Se considera prudente revisar otras buenas prácticas y adicionar otros métodos y
técnicas de ajuste de Base de Datos Oracle, a la metodología propuesta. De tal forma
que se consoliden más alternativas de solución.
 El Sistema Gestor de Base de Datos Oracle 11g al ser una evolución de Oracle
Database 10g se debe considerar actualizar al personal sobre las nuevas estructuras
de la arquitectura Oracle.
 Si en un futuro la PGA baja la tasa de aciertos, se recomienda revisar los diferentes
métodos y técnicas existentes y aplicar uno que se adecue a las exigencias del entorno
de producción de la Agencia Nacional de Hidrocarburos.
 78

El presente Proyecto de Grado está limitado a ajustar las estructuras físicas y de memoria,
se sugiere revisar el uso de CPU y tráfico de red, esto para obtener resultados positivos en el
rendimiento.

Este trabajo realizado contribuye una guía para optimizar en las versiones posteriores de
Oracle 11g como una buena práctica de afinamiento para un determinado motor
(perteneciente a Oracle) de acuerdo a un entorno (recursos de hardware y software).
 79

BIBLIOGRAFÍA

BRAVO. (2012). NUEVAS CARACTERÍSTICAS DE RENDIMIENTO EN ORACLE 11g.

GOMEZ. (2013). BASES DE DATOS
HEURTEL. (2009). ORACLE 11g ADMINISTRACIÓN.
LONEY. (2006). BASE DE DATOS Y GESTORES DE BASE DE DATOS.
MARTINEZ DE LLARDUIA. (2012). ADMINISTRACIÓN DE ORACLE 11g.
MARTINEZ ROLDAN, (2013). DOMINE ORACLE 11G
SOLER (2013). ARQUITECTURA DE ORACLE 11g r2

Sitios en Internet
ORACLE, DATABASE PERFORMANCE TUNNING GUIDE AND REFERENCE
https://docs.oracle.com/cd/B10501_01/server.920/a96533/tools.htm#29114
ORACLE, RECURSOS TÉCNICOS DE ORACLE
https://www.oracle.com/technetwork/es/database/enterprise-edition/documentation/tutorial-
real-application-testing-1705101-esa.pdf
SAWAKINOME, DIFERENCIA ENTRE ORACLE 10G Y 11G
https://es.sawakinome.com/articles/database/difference-between-oracle-10g-and-11g.html

Trabajos de Grado
BARRIOS. (1990). DISEÑO AUTOMÁTICO DE BASE DE DATOS RELACIONALES
DELGADO. (1997). MEJORA SEMÁNTICA DE CONSULTAS EN BASE DE DATOS
RELACIONALES
ESPINOZA. (1990). DISEÑO AUTOMÁTICO DE BASE DE DATOS RELACIONALES
 80

ANEXOS
ANEXO A
ARBOL DE OBJETIVOS
 81

ANEXO B
MONITORIZACIÓN INICIAL DE LOS DÍAS 2, 3 Y 4

Día 2 (martes 10/11/2020)

Primera Sección
 82

Segunda Sección

Tercera Sección
83
84
 85

Cuarta Sección
 86

Día 3 (miércoles 11/11/2020)

Primera Sección
 87

Segunda Sección

Tercera Sección
88
 89

Cuarta Sección
 90

Día 4 (jueves 12/11/2020)

Primera Sección
 91

Segunda Sección

Tercera Sección
92
 93

Cuarta Sección
 94

ANEXO C
MEDICIÓN DEL RENDIMIENTO DESPUÉS DE APLICAR LA
METODOLOGÍA DE LOS DÍAS 2, 3 Y 4

Día 2 (martes 15/12/2020)

Cache Sizes

Instance Efficiency Percentages (Target 100%)

 95

Día 3 (miércoles 16/12/2020)

Cache Sizes

Instance Efficiency Percentages (Target 100%)

 96

Día 4 (jueves 17/12/2020)

Cache Sizes

Instance Efficiency Percentages (Target 100%)