Proyecto de Tesis Técnica Optimización BD Jose Alegre (Dic. 2014)

PONTIFICIA UNIVERSIDAD CATLICA DEL PER
FACULTAD DE CIENCIAS E INGENIERA

ESPECIALIDAD DE INGENIERA INFORMTICA
DEFINIR E IMPLEMENTAR UNA TCNICA PARA MEJORAR LOS

TIEMPOS DE RESPUESTAS DE LAS CONSULTAS A BASE DE DATOS
CON CANTIDADES CONSIDERABLES DE INFORMACIN
Tesis para optar por el Ttulo de Ingeniero Informtico
Jos Alegre Argomedo
Asesor: Ing. Javier Cullas
Lima, junio del 2017

Resumen
El propsito del presente proyecto de tesis es mostrar el desarrollo de una tcnica para
mejorar los tiempos de respuestas de las consultas a bases de datos (BD) con enormes
cantidades de informacin. Esta labor se bas de la experiencia obtenida durante seis aos
en una empresa de consultora y tecnologa dedicada a proveer soporte al procesamiento de
las transacciones bancarias y otros servicios financieros.
A travs del documento usted encontrar ejemplos de los casos ms crticos y usuales que
sucedan en la compaa. Por ejemplo, las dificultades con las entidades financieras las cuales
poseen sistemas transaccionales para manejar los pagos electrnicos, el comercio mvil y las
transacciones de procesamientos pagos por Internet. Aquellas interactan con diversas
entidades cuando procesan los pagos en los comercios. De modo que, estos sistemas no
pueden tener bajo tiempo de respuesta porque tienen un compromiso serio con su cartera de
clientes. Usualmente, aquellas aplicaciones presentaban problemas de lentitud cuando se
empezaba a poblar las tablas transaccionales de sus base de datos, un aproximado de diez
millones de transacciones en un da, y realizar una consulta a esta tabla resultaba frustrante.
Estas complicaciones generaba la necesidad de comprar servidores ms potentes para
mantener disponible la infraestructura y aliviar los problemas de rendimiento. O, la adquisicin
de otros dispositivos a su sistema de almacenamiento, tales como discos ms rpidos, los
cuales permiten lograr la disponibilidad de la informacin histrica de las aplicaciones.
Situaciones que elevaba los costos considerablemente.
En una BD, cuando la tabla crece demasiado, el acceso a ella se vuelve lento; entonces la
divisin de tablas gigantes en partes ms pequeas permite mejorar la administracin y
optimizacin de estas. Esta tcnica es conocida como la particin de tablas. Con esa tcnica
se puede evitar que las empresas gasten en comprar otro servidor ms potente para dar
soporte a las BD con tablas enormes. La particin de tablas brinda un enfoque simple, efectivo
y til para la administracin de TI de grandes entornos. Adems, permite a los diseadores y
administradores de BD solucionar algunos de los problemas ms difciles planteados por las
aplicaciones de vanguardia. Esta es una herramienta importante para sistemas que albergan
mucha informacin o para aquellos con requisitos de disponibilidad considerablemente altos.
El propsito de este proyecto permitir implementar una solucin econmica y fcil de usar,
que automatizar el proceso de particin de tablas y la consulta de las mismas basndose en
el alcance de este proyecto.
Modificado: 11/09/2017 04:52 p.m.

Agradecimiento especial a mi asesor, docente,
Ing. Javier Cullas, por el tiempo invertido de
asesora en el desarrollo de este proyecto. Y a
Nelly Navarro, directora de la compaa donde
labor, por darme las facilidades del caso.
Modificado: 11/09/2017 04:52 p.m.

Tabla de contenidos
INTRODUCCIN ............................................................................................................................ 1
CAPTULO UNO: GENERALIDADES ................................................................................................. 2
1.1 PROBLEMTICA........................................................................................................................ 2
CONTEXTOS ............................................................................................................................................ 2
DEFINICIN DEL PROBLEMA ....................................................................................................................... 4
SITUACIN ACTUAL DEL CASO DE ESTUDIO .................................................................................................... 4
SISTEMAS IMPACTADOS Y LA IDENTIFICACIN DEL PROBLEMA .......................................................................... 5
CONSECUENCIAS DE CONTINUAR CON LA SITUACIN ACTUAL ........................................................................... 6
1.2 OBJETIVOS Y RESULTADOS ESPERADOS DEL PROYECTO ....................................................................... 7

OBJETIVO GENERAL .................................................................................................................................. 8
OBJETIVO ESPECFICOS .............................................................................................................................. 8
RESULTADOS ESPERADOS .......................................................................................................................... 8
1.3 HERRAMIENTAS, PROCEDIMIENTOS Y METODOLOGAS ....................................................................... 9

HERRAMIENTAS ....................................................................................................................................... 9
PROCEDIMIENTOS .................................................................................................................................. 11
METODOLOGA ..................................................................................................................................... 13
1.4 ALCANCE, LIMITACIONES Y RIESGOS............................................................................................. 13

ALCANCE .............................................................................................................................................. 14
LIMITACIONES ....................................................................................................................................... 14
RIESGOS ............................................................................................................................................... 14
1.5 JUSTIFICATIVA Y VIABILIDAD ...................................................................................................... 15

JUSTIFICATIVA ....................................................................................................................................... 15
VIABILIDAD ........................................................................................................................................... 16
1.6 CORRELACIN DE LOS RESULTADOS ESPERADOS CON LAS SECCIONES DE ESTE INFORME ............................ 18
CAPTULO DOS: MARCO CONCEPTUAL ........................................................................................ 19
2.1 MARCO TERICO .................................................................................................................... 19

ESTRUCTURA LGICO Y FSICO EN UNA BASE DE DATOS ................................................................................. 20
ANSI ................................................................................................................................................... 21
ACERCA DE LAS VISTAS EN LA BD ORACLE .................................................................................................. 21
CLAVE DE PARTICIN .............................................................................................................................. 23
OPERACIONES O DECLARACIONES LLAMADOS <<DML>> ............................................................................. 23
OPERACIONES O DECLARACIONES LLAMADOS <<DDL>> .............................................................................. 23
ACERCA DE LOS TRIGGERS........................................................................................................................ 23
I
TIPOS DE TRIGGERS ................................................................................................................................ 23
<<INSTEAD OF TRIGGER>>................................................................................................................... 24
LEYENDO Y ENTENDIENDO EL PLAN DE EJECUCIN........................................................................................ 24
2.2 ESTADO DEL ARTE ................................................................................................................... 25

<<INFORMATICA DATA SUBSETS>> .......................................................................................................... 25
<<ORACLE PARTITIONING EN ORACLE DATABASE 12C>> ............................................................................. 26
CUADRO COMPARATIVO SOBRE EL ESTADO DEL ARTE ................................................................................... 27
CAPTULO TRES: ANLISIS ........................................................................................................... 28
3.1 PRELIMINARES ....................................................................................................................... 28

ABREVIATURAS Y DEFINICIONES ................................................................................................................ 29
OBSERVACIONES ENCONTRADAS AL DEFINIR LA SOLUCIN............................................................................. 29
3.2 VISTA PANORMICA DE LA SOLUCIN .......................................................................................... 29

3.3 ANLISIS DE LOS DATOS ........................................................................................................... 30
3.4 CREACIN DE LAS PARTICIONES .................................................................................................. 31
3.5 ENMASCARAMIENTO DE LAS PARTICIONES .................................................................................... 31
3.6 DESPLAZAMIENTO DE LOS DATOS................................................................................................ 31
3.7 MANIPULACIN DE LOS DATOS .................................................................................................. 32
3.8 RESUMEN DEL ANLISIS............................................................................................................ 32
CAPTULO CUATRO: DISEO........................................................................................................ 33
4.1 PRELIMINARES ....................................................................................................................... 33

ABREVIATURAS Y DEFINICIONES ................................................................................................................ 34
ACERCA DE LOS SCRIPTS QUE CONSTRUYE EL CE .......................................................................................... 34
ACERCA DE LOS SCRIPTS DE INSTALACIN ................................................................................................... 34
ACERCA DE LOS SCRIPTS DEL PROCESO ....................................................................................................... 34
PASOS PREVIOS A LA EJECUCIN DEL PROCESO DE OPTIMIZACIN ................................................................... 34
4.2 RESUMEN DE ALTO NIVEL DEL PROCESO DE OPTIMIZACIN ................................................................ 36

PARTE 1: LAS PANTALLAS DE INTERACCIN CON EL DBA............................................................................... 36
PARTE 2: LA EJECUCIN DE PROCESO DE FORMA AUTOMTICA ...................................................................... 36
4.3 DIAGRAMA DEL FLUJO DEL PROCESO DE OPTIMIZACIN .................................................................... 36

4.4 VISUALIZACIN DE LAS TABLAS DE MAYOR CRECIMIENTO .................................................................. 37
4.5 PANTALLAS INTERACTIVAS PARA EL DBA ...................................................................................... 37
4.6 TRANSPARENCIA PARA LA APLICACIN ......................................................................................... 42
CREACIN DE LAS PARTICIONES DE LA TABLA............................................................................................... 43
CREACIN DE LA VISTA DE PARTICIONES ..................................................................................................... 43
MIGRACIN DE LOS DATOS DE LA TABLA HACIA LAS PARTICIONES ................................................................... 44
CREACIN DE CONSTRAINTS..................................................................................................................... 44
Modificado: 11/09/2017 04:52 p.m.

II
CREACIN DEL TRIGGER SOBRE LA VISTA .................................................................................................... 45
4.7 RENDIMIENTO DE LAS CONSULTAS A LA TABLA ............................................................................... 45
CAPTULO 5: CONSTRUCCIN ...................................................................................................... 46
5.1 PRELIMINARES ....................................................................................................................... 46

DECLARACIN DE VARIABLES EN PL/SQL ................................................................................................... 46
BENEFICIOS DE USO EL ATRIBUTO %TYPE .................................................................................................. 47
CREACIN DE UN REGISTRO CON EL ATRIBUTO %ROWTYPE ........................................................................ 48
CREANDO UN <<INSTEAD OF TRIGGER>> ............................................................................................... 48
5.2 INSTALACIN DEL PRODUCTO .................................................................................................... 50

PARMETROS........................................................................................................................................ 50
CREACIN DE OBJETOS PARA LA IMPLEMENTACIN ...................................................................................... 51
VERIFICACIN DE OBJETOS DESPUS DE LA INSTALACIN ............................................................................... 53
5.3 PROCESO DE OPTIMIZACIN ...................................................................................................... 55

PARTE1: LAS PANTALLAS INTERACTIVAS Y MOTOR DE SENTENCIAS DDL........................................................... 55
PARTE2: LA EJECUCIN DE LAS DECLARACIONES DDL................................................................................... 62
CAPTULO 6: PRUEBAS DE RENDIMIENTO .................................................................................... 71
6.1 PRELIMINARES ....................................................................................................................... 71

CASO DE PRUEBA ................................................................................................................................... 71
FASES DE LAS PRUEBAS ........................................................................................................................... 72
PRUEBAS DE RENDIMIENTO ..................................................................................................................... 72
ENCONTRANDO EL COSTO DE UN QUERY .................................................................................................... 72
6.2 RECOPILACIN DE ESTADSTICAS PARA LAS PRUEBAS........................................................................ 72

EN LA FASE INICIAL ................................................................................................................................. 73
EN LA FASE FINAL ................................................................................................................................... 73
6.3 PRIMERA PRUEBA: COMPARACIN DE LOS PLANES .......................................................................... 73

PLAN USANDO LA FUNCIN DBMS_XPLAN.DISPLAY ................................................................................ 73
PLAN USANDO LA FUNCIN DBMS_XPLAN.DISPLAY_CURSOR ................................................................ 74
PLANES DE EJECUCIN EN LA FASE INICIAL .................................................................................................. 75
PLANES DE EJECUCIN EN LA FASE FINAL .................................................................................................... 75
CONCLUSIN DE LA PRIMERA PRUEBA ....................................................................................................... 77
6.4 SEGUNDA PRUEBA: COMPARACIN DE LOS TIEMPOS ....................................................................... 78

ESTADSTICOS DE MEDICIN DE TIEMPO EN LA FASE INICIAL ........................................................................... 78
ESTADSTICOS DE MEDICIN DE TIEMPO EN LA FASE FINAL ............................................................................. 79
CONCLUSIN DE LA SEGUNDA PRUEBA....................................................................................................... 80
Modificado: 11/09/2017 04:52 p.m.

III
RESTRICCIONES, CONCLUSIONES Y RECOMENDACIONES .............................................................. 81
RESTRICCIONES ..................................................................................................................................... 81
CONCLUSIONES ..................................................................................................................................... 82
LECCIN APRENDIDA .............................................................................................................................. 82
RECOMENDACIONES Y TRABAJO FUTURO ................................................................................................... 82
REFERENCIAS BIBLIOGRFICAS.................................................................................................... 84
ENLACES EN INTERNET ............................................................................................................................ 85
ANEXOS...................................................................................................................................... 86
ANEXO A: ABREVIATURAS Y DEFINICIONES ............................................................................................ 86

ANEXO B: MAGIC QUADRANT FOR STRUCTURED DATA ARCHIVING AND APPLICATION RETIREMENT ................... 87
Modificado: 11/09/2017 04:52 p.m.

IV
ndices de tablas
Tabla 1-1: Registros de los riesgos del proyecto. ................................................................. 15

Tabla 1-2: Correlacin de los RE con las secciones de este informe. .................................. 18
Tabla 2-1: Cuadro comparativo sobre el estado del arte. ..................................................... 27
Tabla 4-1: Distribucin de scripts. ........................................................................................ 35
Modificado: 11/09/2017 04:52 p.m.

V
ndices de figuras
Figura 1-1: Mdulo de la aplicacin que tiene problemas en el rendimiento. ......................... 5

Figura 1-2: Tabla JOURNALTX. ............................................................................................ 5
Figura 1-3: SQL, ejemplo (fuente de la imagen [ORA02, 46]). ............................................... 9
Figura 1-4: PL/SQL, definicin (fuente de la imagen [ORA03, 37]). ..................................... 10
Figura 1-5: PL/SQL, entorno (fuente de la imagen [ORA03, 39]). ........................................ 11
Figura 1-6: Actividades realizadas en la construccin del ambiente de trabajo. ................... 17
Figura 2-1: Tablespace y datafiles (fuente de la imagen [ORA04, 61]). ............................... 20
Figura 2-2: View, ejemplo (fuente de la imagen [ORA06, 103]). ........................................... 22
Figura 2-3: Cuadrante mgico de Gartner (fuente de la imagen [WEB04]). ......................... 26
Figura 3-1: Fases de la tcnica de optimizacin .................................................................. 30
Figura 4-1: Diagrama de flujo del proceso. .......................................................................... 37
Figura 4-2: Lista de tablas pesadas. .................................................................................... 38
Figura 4-3: Seleccin de la pantalla gigante. ....................................................................... 39
Figura 4-4: Seleccin de la columna pivote. ......................................................................... 39
Figura 4-5: Seleccin del tipo de particin. .......................................................................... 40
Figura 4-6: Lista de particiones que se crearn. .................................................................. 40
Figura 4-7: Pantalla para configurar una particin. ............................................................... 41
Figura 4-8: Modificando el nombre de la particin. ............................................................... 41
Figura 4-9: Actualizando informacin de las particiones. ..................................................... 41
Figura 4-10: Sentencia DDL de la particin. ......................................................................... 42
Figura 4-11: Autorizacin para la creacin de particiones. ................................................... 42
Figura 4-12: Creacin de las particiones. ............................................................................. 43
Figura 4-13: Creacin de la vista de particiones. ................................................................. 44
Figura 4-14: Migracin de los datos. .................................................................................... 44
Figura 5-1: Sintaxis declaracin de variables PL/SQL (fuente de la imagen [ORA03, 62]). .. 47
Figura 5-2: Ej. Declaracin de variables PL/SQL (fuente de la imagen [ORA03, 62])........... 47
Figura 5-3: Sintaxis %TYPE (fuente de la imagen [ORA03, 77]). ......................................... 48
Figura 5-4: Sintaxis %ROWTYPE (fuente de la imagen [ORA03, 188]). .............................. 48
Figura 6-1: Plan de ejecucin antes del proceso (DBMS_XPLAN.DISPLAY). ...................... 75
Figura 6-2: Plan de ejecucin antes del proceso (DBMS_XPLAN.DISPLAY_CURSOR). .... 76
Figura 6-3: Plan de ejecucin despus del proceso (DBMS_XPLAN.DISPLAY). ................. 76
Figura 6-4: Plan de ejecucin despus del proceso (DBMS_XPLAN.DISPLAY_CURSOR). 77
Figura 6-5: Periodo transcurrido en la ejecucin del bloque PL/SQL en el momento inicial. 79
Figura 6-6: Periodo transcurrido en la ejecucin del bloque PL/SQL en el momento final. ... 80
Modificado: 11/09/2017 04:52 p.m.

VI
INTRODUCCIN
Las empresas utilizan la tecnologa de la informacin (TI) para obtener una ventaja competitiva
sostenible a largo plazo, reducir los costos operativos y aumentar la facilidad para administrar
los procesos de negocio ms importantes. A medida que el uso de TI se vuelve ms necesario
en todos los aspectos de las operaciones de negocio, las empresas de hoy dependen cada
vez ms de ello para tener xito [PEI].
El problema de la falta de identificacin de oportunidades de negocio puede provocar prdidas

en las ventas o en la optimizacin de procesos operativos. Por lo tanto, se debe proporcionar
el soporte para la administracin de TI, permitiendo optimizar el almacenamiento de los
importantes procesos comerciales para ayudar a evitar ese problema.
La indisponibilidad de una aplicacin para leer un dato crtico puede generar un costo
representativo de prdida de productividad e ingresos, clientes insatisfechos y una mala
reputacin corporativa. Por lo tanto, un soporte de TI altamente disponible es un factor de
xito fundamental para que las empresas modernas se muevan con rapidez y estn siempre
activas.
Con bases de datos (BD) que aumentan su tamao cada vez ms rpido, los departamentos
de TI se enfrentan a desafos como mantener niveles adecuados de servicio al usuario; ellos
necesitan que la informacin llegue en el momento oportuno y contribuya en mejorar la toma
de decisiones.
En una BD, cuando la tabla crece demasiado, el acceso a ella se vuelve lento; entonces la
divisin de tablas gigantes en partes ms pequeas permite mejorar la administracin y
optimizacin de estas. Esta tcnica es conocida como la particin de tablas.
Con esa tcnica, se puede evitar que las empresas gasten en comprar otro servidor ms
potente para dar soporte a las BD con tablas enormes. Adems, se puede utilizar un enfoque
de archivo por niveles, lo cual significa mantener la informacin ms antigua disponible en
dispositivos de almacenamiento de bajo costo.
La particin de tablas brinda un enfoque simple, efectivo y til para la administracin de TI de

grandes entornos. Adems, permite a los diseadores y administradores de BD solucionar
algunos de los problemas ms difciles planteados por las aplicaciones de vanguardia. Esta
es una herramienta importante para sistemas que albergan mucha informacin o para
aquellos con requisitos de disponibilidad considerablemente altos.
El propsito de este proyecto permitir implementar una solucin econmica y fcil de usar,
que automatizar el proceso de particin de tablas y la consulta de las mismas basndose en
el alcance de este proyecto.
1
1
CAPTULO UNO: GENERALIDADES

Esta seccin cubre los siguientes temas:
Problemtica.
Objetivos y resultados esperados del proyecto.
Herramientas, procedimientos y metodologas.
Alcances, limitaciones y riesgos.
Justificativa y viabilidad.
Correlacin de los resultados esperados con las secciones de este informe.
1.1 Problemtica
En esta seccin se describe el contexto en donde se desarroll el problema y se identifica el

que abord este proyecto de tesis.
Contextos
A continuacin se describen diversas situaciones recogidas que servirn para contextualizar

el problema principal para este proyecto:
Modificado: 11/09/2017 04:52 p.m.

2
Enorme base de datos
Modernas empresas frecuentemente corren bases de datos de misin-critica que contienen

miles de gigabytes y a menudo terabytes de data. Estas empresas tienen el reto de dar soporte
y mantenimiento a los requerimientos de sus grandes bases de datos y deben idear mtodos
para resolver esos desafos [ORA01, 19].
Aplicaciones de vanguardia
<<Estudios acerca de distintas situaciones que afrontan las empresas despus de implantar
una solucin informtica de vanguardia, indican problemas de alto rendimiento cuando sus
bases de datos empiezan a crecer exponencialmente>>, explic Henry Ilizarbe, analista de
negocios en el rea de servicios transaccionales. (Entrevista personal, 22 agosto del 2014).
<<Esas empresas se ven en la necesidad de comprar servidores ms potentes para mantener

disponible la infraestructura y aliviar los problemas de rendimiento, situacin que eleva los
costos considerablemente>>, asegur.
Asimismo, <<ellas requieren adicionar otros dispositivos a su sistema de almacenamiento,

tales como discos fsicos ms rpidos, los cuales permiten lograr la disponibilidad de la
informacin histrica de esas aplicaciones>>, indic.
Casos relacionados con el rendimiento en una base de datos
Otro caso de estudio obtenido fue sobre las entidades bancarias, las que ofrecen una amplia
gama de productos y servicios financieros. Su cartera de clientes abarca desde personas
naturales, pequeas y medianas empresas hasta grandes corporaciones.
Las entidades financieras poseen sistemas transaccionales para manejar los pagos
electrnicos, el comercio mvil y las transacciones de procesamientos de pagos por Internet.
Adems, estas interactan con diversas entidades cuando se procesan los pagos en los
comercios.
<<Estos sistemas no pueden tener bajo tiempo de respuesta, pues tienen un compromiso
serio con su cartera de clientes. Usualmente se presentan problemas de lentitud cuando se
empiezan a poblar las tablas transaccionales de sus bases de datos>>, as lo manifiesta el
Analista de Sistemas Transaccionales de Core Bancario, Roger Chacn; en una entrevista
recogida en la implementacin de un tipo de estas soluciones en un banco importante en
Repblica Dominicana.
l mencion el siguiente caso usual: <<en una de las tablas del sistema de auditora, que
crece tan rpido, 10 millones de transacciones en un da, realizar una consulta a esta tabla
Modificado: 11/09/2017 04:52 p.m.

3
resulta frustrante, adems son otros los sistemas que tratan de obtener esa informacin
generando un cuello de botella importante si no hay un trabajo de ajustes de rendimiento
previo>>.
Otro ejemplo que proporcion Chacn fue cuando tuvo la experiencia de trabajar en la
optimizacin de los tiempos de respuesta de una base de datos, en una implementacin de
un sistema de consulta de recarga para puntos de ventas en una compaa que ofrece
servicios de telecomunicaciones.
l dijo: <<la compaa tena alrededor de 120 000 puntos de ventas a nivel nacional y en
promedio realizaban 25 recargas diarias, en la puesta en produccin del Sistema de
Consultas gener un impacto significativo en los tiempos de respuestas y en el rendimiento
de otro sistema con quien interactuaba, este era un sistema altamente transaccional, esto
trajo serias cadas continuas del servicio, generando prdidas de dinero considerables y
multas de entidades auditoras. La solucin involucr cambio de toda la infraestructura de BD
y un trabajo de afinamiento continuo debido al crecimiento de recargas en el mercado
peruano>>.
Definicin del problema
De los hallazgos encontrados se identifica que el problema fundamental es el bajo rendimiento

que presentan las aplicaciones cuando sus bases de datos comienzan a crecer con
cantidades considerables de informacin y el alto costo que provoca solucionarlo.
Antes de empezar con la discusin es, sin embargo, necesario definir un caso de estudio (CE)
el cual refleje o se aproxime a los requerimientos de la mayora de las empresas. A
continuacin se muestra la situacin actual del caso, y con ello, visualizar el requerimiento
principal del proyecto.
Situacin actual del caso de estudio
El CE del proyecto contempla a una empresa del sector bancario, la cual tiene problemas
serios con diversos sistemas importantes para su negocio. Existe una aplicacin que gestiona
los diversos pagos electrnicos que realizan las empresas y personas, como el comercio mvil,
los pagos a travs de Internet y todos los procesamientos ejecutados en el ciclo de vida de
estos pagos. Por tanto, es significativo cuidar esta aplicacin, pues las auditoras por parte
del gobierno son constantes y aleatorias.
Esta aplicacin es importante porque almacena los sucesos de las transacciones de todos los
medios de pagos. Y esa informacin es usada por otras aplicaciones de la compaa.
Seguidamente, se presenta los sistemas impactados del CE.
Modificado: 11/09/2017 04:52 p.m.

4
Sistemas impactados y la identificacin del problema
Continuando con la explicacin proporcionada de la situacin actual del CE, se tiene una
aplicacin con problemas de rendimiento en un mdulo llamado diario electrnico (Electronic
Journal). El modulo maneja registros de las transacciones que se ejecutan en diferentes
canales, tales como: AGENCIA, POS, ATM, KIOSK, INTERNETBANKING y
ASOCIACIONTARJERTA. En la figura 1-1 se ilustra mejor el enunciado mencionado.
ATM KIOSK
INTERNET
POS
BANKING
CARD
BANKS
ASSOCIATIONS
ELECTRONIC
JOURNAL
Figura 1-1: Mdulo de la aplicacin que tiene problemas en el rendimiento.
El modulo es el motor de procesamiento centralizado de la gran parte de las transacciones, lo

cual administra los pagos de los diferentes canales y es punto de conexin con las
asociaciones de tarjetas, as como con el core bancario.
El modulo tiene una compleja estructura de tablas, y se decidi no presentarlo para no cansar
al lector. Sin embargo, se mostrar la principal tabla (JOURNALTX) en la cual crece
exponencialmente alrededor de diez millones de registros en un da til. En la figura 1-2 se
presenta la tabla JOURNALTX.
Figura 1-2: Tabla JOURNALTX.
Modificado: 11/09/2017 04:52 p.m.

5
Esta tabla tiene informacin histrica de millones de registros porque todos los movimientos
realizados se guardan ah. Por ejemplo, una situacin frecuente es cuando un cliente quiere
solicitar informacin de algunas de sus transacciones porque cree que fue vulnerado; los
funcionarios del canal de Internet Banking tienen serios problemas en sus trabajos de auditora,
porque los tiempos de respuestas cuando consultan esa tabla es abrumador.
Adems, los sistemas de los otros canales tratan de conseguir esa informacin originando un
cuello de botella significativo. Por lo tanto, se identific que la tabla JOURNALTX debe ser el
input para el proceso de optimizacin y lograr la mejora en su rendimiento.
Consecuencias de continuar con la situacin actual
La aplicacin mencionada en la situacin actual tiene problemas de rendimiento, la cual

genera cuellos de botella en la interaccin con los dems procesos de otros sistemas. En
consecuencia, de continuar as, se generan los siguientes problemas, riesgos y situaciones:
Mantener los datos disponibles en la aplicacin resulta caro
Las adquisiciones realizadas para toda la infraestructura, como por ejemplo: nuevos
servidores, nuevo hardware o nuevos discos fsicos ms rpidos para el sistema de
almacenamiento son algunos ejemplos de costos que deben estar contemplados en el
presupuesto de la compaa.
Adems, los profesionales de BD adicionales que deberan considerarse para la

administracin eficiente del sistema, son gastos que inflan el presupuesto total asignado. Por
consiguiente se establece que es costoso continuar con la situacin actual.
Se produce bajo rendimiento en la aplicacin
En la situacin actual del CE se produce bajo rendimiento en la aplicacin cuando los usuarios
generan reportes para el anlisis histrico de los datos. Debido al problema de rendimiento,
la generacin de reportes usualmente son activados para ser ejecutados durante la noche o
los fines de semana, en otros trminos, solo se pueden generar reportes cuando la aplicacin
realiza pocas transacciones.
Se generan riesgos de no brindar un buen nivel de servicio a los clientes
En una auditora que se realiz en la compaa, concluyeron que la situacin actual no permite
cumplir con las polticas de alta disponibilidad con los datos de los clientes, en relacin con
las transacciones de sus cuentas financieras.
Modificado: 11/09/2017 04:52 p.m.

6
Adems, se indic que no se puede garantizar que la informacin est disponible para llevar
su propio control. Ms an, que tenga la capacidad de responder a los eventos de auditora,
litigios e investigaciones que realiza el gobierno.
Retorno de la inversin
No resulta significativo el retorno de la inversin (ROI, Return on investment de su definicin

en ingls), debido a los altos costos que representa. Mantener la BD para todas las
aplicaciones, la cual se va incrementando por aos y en algunos casos por dcadas. Por ende,
se desprende nuevamente la presencia de altos gastos operativos y de activos en el presente
caso de estudio.
Visin futura de los SI estn comprometidas.
Segn la situacin actual, el ltimo reporte de la auditora indica que hay problemas serios de
continuar con sus operaciones en el mercado peruano. La alta gerencia de la compaa desea
conocer si el logro de su visin futura en sus sistemas de informacin est comprometida,
debido a las evidentes complicaciones.
Retos de los gerentes de TI
Al rea de TI le exigen el cumplimiento de requerimientos de conformidad en el interior de la

organizacin. Y con respecto a los clientes, la gerencia de TI debe asegurar en cumplir con
las polticas de nivel de servicios establecidos con ellos, y eso origina muchos gastos que
desestabiliza el presupuesto asignado. Ms an, est presente el riesgo de impactar en el
prestigio de la organizacin.
Cuando al gerente de TI le encomendaron investigar el origen de los problemas, su equipo de

trabajo hall que las bases de datos de ciertas aplicaciones crecen rpidamente, generando
bajo rendimiento en sus sistemas.
Estos son los retos que enfrentan la mayora de los gerentes de TI para aliviar sus problemas
de bajo rendimiento de sus aplicaciones. Esta investigacin trata de analizar esa problemtica
con la finalidad de reducir costos y cumplir con las polticas y requerimientos de conformidad
de las empresas.
1.2 Objetivos y resultados esperados del proyecto
A continuacin en esta seccin se describe el objetivo general y los especficos de este

proyecto de tesis.
Modificado: 11/09/2017 04:52 p.m.

7
Objetivo general
Definir e implementar una tcnica para mejorar los tiempos de respuestas de las consultas a
base de datos con cantidades considerables de informacin.
Objetivo especficos
Los objetivos especficos de este proyecto son:
Objetivo especfico 1 (OE1): Disear el funcionamiento correspondiente a cada fase del

proceso de la solucin.
OE2: Analizar las tablas de mayor crecimiento en la BD.
OE3: Facilitar al DBA (administrador de base de datos) la configuracin de las nuevas

particiones que sern creadas a partir de la tabla seleccionada.
OE4: No apercibir de los resultados producidos del proceso de optimizacin para que
el usuario final o la aplicacin puedan consultar la tabla o insertar registros en ella sin
dificultades.
OE5: Mejorar los tiempos de respuestas de las consultas a la tabla que fue procesada.
Resultados esperados
A continuacin se lista los resultados esperados para este proyecto:
Resultado esperado 1 para el objetivo 1 (RE1): Se espera un informe que explique el

flujo de los procesos de la solucin.
RE2: Visualizacin de una lista de tablas que tienen grandes cantidades de registros
para que el DBA elija la tabla que ingresar al proceso de particin.
RE3: Pantallas interactivas para que el DBA personalice la configuracin de las

particiones que sern creadas. Por ejemplo: confirmar el nombre de las particiones; o
el TABLESPACE (revise la definicin en el marco terico ubicado en la seccin 2.1).
RE4: Transparencia para que el usuario final o la aplicacin no tengan la necesidad de

realizar otras operaciones al acceder a la tabla que fue procesada.
Modificado: 11/09/2017 04:52 p.m.

8
RE5: Aumento en el rendimiento de las consultas a la tabla que fue procesada.
1.3 Herramientas, procedimientos y metodologas
En esta seccin se describe las herramientas, procedimientos y metodologas que se

utilizaron en el proyecto.
Herramientas
A continuacin se lista las herramientas que se utilizaron en la implementacin de este

proyecto:
Herramienta: SQL
Su definicin en ingls es Structured Query Language. SQL es un lenguaje estndar ANSI

(revise su definicin en la seccin 2.1), para operaciones relacionales en base de datos. Se
caracteriza por ser eficiente, fcil de aprender y usar. Con SQL se puede definir, recuperar y
manipular los datos de las tablas de una BD. En la figura 1-3 se ilustra un ejemplo de su uso:
Figura 1-3: SQL, ejemplo (fuente de la imagen [ORA02, 46]).
Cuando se usa SQL para consultar la BD relacional, no se especifica la ruta de acceso a la

tabla y no se necesita conocer como la data est fsicamente almacenada. SQL es un conjunto
de declaraciones con lo cual todos los programas y usuarios acceden a los datos en una BD
Oracle.
Los programas de las aplicaciones y las herramientas de Oracle a menudo permiten a los
usuarios acceder a la BD sin usar SQL directamente, pero estas aplicaciones utilizan
sentencias SQL para atender los requerimientos del usuario.
SQL provee declaraciones para una variedad de tareas, entre ellas:
Modificado: 11/09/2017 04:52 p.m.

9
Consultar datos.
Insertar, actualizar y eliminar filas en una tabla.
Crea, remplaza, altera y borra objetos en la BD.
Controla accesos a la BD y a sus objetos.
Garantiza consistencia e integridad en la BD.
SQL unifica todas las tareas anteriores en un lenguaje fcil y permite trabajar con los datos
en un nivel lgico [ORA02, 46].
Herramienta: PL/SQL
Es un lenguaje de procesamiento de transacciones de alto rendimiento porttil implementado

por Oracle, dispone de estructuras de programacin similares a la mayora de los lenguajes
de programacin, facilita la interaccin con la BD [ORA10, 37].
Su definicin en ingls es Procedural Language extensin to SQL que significa que una
extensin del lenguaje de procedimientos de SQL. PL/SQL se integra perfectamente con
construcciones de procedimientos SQL. En la figura 1-4 se ilustra mejor este prrafo:
Figura 1-4: PL/SQL, definicin (fuente de la imagen [ORA03, 37]).
PL/SQL provee una estructura de bloques para unidades de cdigo ejecutable. El

mantenimiento de cdigo se hace ms fcil con una estructura de este tipo bien definido
[ORA03, 38].
Adems, proporciona construcciones de procedimientos tales como:
Variables, constantes y tipo de datos.

Estructuras de control tales como declaraciones condicionales y bucles.
Unidades de programas reutilizables que se escriben una vez y se ejecutan muchas
veces.
Modificado: 11/09/2017 04:52 p.m.

10
En la figura 1-5, se muestra el entorno de ejecucin de PL/SQL en el servidor de BD Oracle.
Aqu se observa que un bloque PL/SQL contiene declaraciones de procedimiento y las
sentencias SQL [ORA03, 39].
Figura 1-5: PL/SQL, entorno (fuente de la imagen [ORA03, 39]).
Al enviar este bloque al servidor, el motor analiza primero el bloque para identificar las
sentencias de procedimiento y las sentencias SQL, para luego pasarlos a su ejecutor
respectivo.
Las herramientas de desarrollo de aplicaciones de Oracle pueden contener tambin su propio

motor de PL/SQL. Por consiguiente, todas las sentencias de procedimiento se ejecutan
localmente y slo las sentencias SQL se ejecutan en la base de datos [ORA03, 39].
Procedimientos
A continuacin se muestra un resumen de los procedimientos y tareas que permitieron llegar

a los resultados esperados:
Para obtener el RE1:
<<Un informe que explique el flujo de los procesos de la solucin>>.
Para obtener este resultado se analiz la problemtica del caso de estudio y se investig
soluciones similares (revisar el estado del arte en la seccin 2.2 para ms detalle). Las tareas
mencionadas fueron la base para disear una solucin que cumpla todos los objetivos
especficos planteados.
Modificado: 11/09/2017 04:52 p.m.

11
En los captulos tres y cuatro se explica con ms detalle este RE.
<<Visualizacin de una lista de tablas que tienen grandes cantidades de registros para que el
DBA elija la tabla que ingresar al proceso de particin>>.
Para la elaboracin del reporte se us la vista USER_EXTENTS para obtener informacin de las
tablas (WHERE SEGMENT_TYPE='TABLE') del usuario actual. Adems se tuvo que agrupar por
el nombre del segmento (GROUP BY SEGMENT_NAME) para calcular el tamao de las tablas.
En la seccin 4.4 se explica con ms detalle este proceso.
<<Pantallas interactivas para que el DBA personalice la configuracin de las particiones que
sern creadas>>.
Se estudi los campos que deberan ser configurables al inicio del proceso. Se elabor mens
para que visualice una coleccin de opciones para facilitar el ingreso de parmetros al proceso
de particin.
En la seccin 4.5 se explica con ms detalle este propsito.
<<Transparencia para que el usuario final o la aplicacin no tengan la necesidad de realizar

otras operaciones al acceder a la tabla que fue procesada>>.
Se us una representacin lgica de una o varias tablas para enmascarar las particiones y
encubrir la complejidad de la solucin (revisar el concepto de VISTA en el marco terico
ubicado en la seccin 2.1). Tambin se us un componente almacenado en la BD que se
invoca automticamente si ocurre alguna manipulacin en los datos de la tabla (para ms
detalle revisar el concepto de TRIGGER en el marco terico ubicado en la seccin 2.1).
Se emple un tipo especial de trigger llamado INSTEAD OF TRIGGERS, lo cual permiti

manipular los datos que administra una vista como si se tratara de una tabla. Para la versin
inicial del producto las OPERACIONES DML son la consulta de la tabla y la insercin de
registros en ella. (Revise la seccin 2.1 para conocer ms de las operaciones DML).
Modificado: 11/09/2017 04:52 p.m.

12
<<Aumento en el rendimiento de las consultas a la tabla que fue procesada>>.
Para verificar esta evidencia se compar los PLANES DE EJECUCIN (esta definicin se explica
con mayor amplitud en la seccin 2.1) antes del proceso de particin y despus de ello. Sin
embargo aqu se puede adelantar que un plan de ejecucin es un conjunto de pasos que el
optimizador del motor de la BD Oracle realiza cuando se est ejecutando una sentencia SQL
para realizar una operacin.
Metodologa
La metodologa que ayud a gestionar este proyecto fue la gua del PMBOK (Project
Management Body of Knowledge). Sin embargo, debido a la naturaleza del proyecto (este es
un trabajo acadmico realizado por una sola persona) y al poco tiempo asignado, no se usaron
todas las reas del conocimiento.
A continuacin se lista las reas de conocimiento que fueron tiles durante el ciclo de vida del
proyecto:
Gestin de la integracin del proyecto.

Gestin del alcance del proyecto.
Gestin del tiempo del proyecto.
Gestin de la calidad del proyecto.
Gestin de riesgos del proyecto.
Los procesos de cada gestin mencionada se describen ms adelante en los anexos de este
informe.
1.4 Alcance, limitaciones y riesgos
En esta seccin se explican lo que solucionar el proyecto. Luego se indican las razones que
pueden posibilitar que el proyecto no se culmine. Y por ltimo, se describen los riesgos que
pueden impactar negativamente en el proyecto.
Modificado: 11/09/2017 04:52 p.m.

13
Alcance
El proyecto se enfoca en resolver el problema principal de la situacin actual del caso de

estudio que se describi en la seccin 1.1. En ese sentido se percibi la necesidad de afinar
la base de datos para mejorar el rendimiento de la aplicacin ms transaccional, porque se
observ que esta aplicacin tiene muchas transacciones que se procesan en un da.
Diariamente se procesa alrededor de diez (10) millones de registros en esas tablas. Eso
provocaba que las tablas ms consultadas en el sistema se llenen rpidamente. Naturalmente
se identific la necesidad de realizar un anlisis de rendimiento de la base de datos de esta
aplicacin y encontrar una solucin.
Con las evidencias presentadas en la situacin actual del CE, se puede indicar que el
requerimiento principal es <<la implementacin de una solucin para afrontar los problemas
de todos los das, cuando sus bases de datos crecen en cantidades considerables de
informacin>>.
Limitaciones
A continuacin se explican las limitaciones que pueden imposibilitar que el proyecto culmine:
Para que el avance del proyecto sea continuo se necesita comunicacin constante con el
asesor de tesis para elaborar de forma apropiada las funcionalidades esperadas en el
producto. Sobre este asunto, el asesor es un profesional especializado en base de datos en
la tecnologa Oracle y posee mucha experiencia en este rubro.
Por tanto, se pudo dar la situacin en la cual se pierda comunicacin con l, debido al viaje
que se realiz fuera del pas por motivos laborales. Sin embargo, esta situacin fue controlada
y superada porque se mantuvo comunicacin con el asesor a travs de Internet.
Otra consideracin fue el hardware que se us para elaborar la solucin, pues se requera un
computador estable, en otros trminos, que no tenga problemas en la memoria RAM, ni en la
velocidad del CPU y tenga mucho espacio en disco disponible para trabajar sin retrasos. Este
fue superado por la compra de una laptop nueva con 500 GiB de disco duro y 3 GiB de
memoria RAM.
Riesgos
En la tabla 1-1 se registraron los riesgos y su plan de contingencia respectivamente:
Modificado: 11/09/2017 04:52 p.m.

14
DESCRIPCIN DISPARADOR PLAN DE CONTINGENCIA
Qu es este riesgo? Qu accin o evento indica que el Si se materializa el riesgo que se har en respuesta o
riesgo se va a dar para tomar medidas como respaldo o como reparacin.
correctivas?
Poco tiempo Si la elaboracin del producto Se tomar como prioridad alta para
disponible para no se encuentra finalizada solicitar permisos especiales, para
el desarrollo de antes del 30 de noviembre ausentarme en el trabajo actual, en la
la tesis. del 2014, entonces se primera semana de diciembre. Y en este
tomarn medidas tiempo libre culminar con todos los
correctivas. retrasos generados en los entregables
del producto.
Sobrecosto en Si el presupuesto asignado Se tiene planeado la venta de un bien

el presupuesto es menor del 10 % del total mueble, un auto valorizado por ocho mil
asignado. antes del 30 de setiembre del dlares. Y asignar el 20% de la venta al
2014, entonces se tomarn presupuesto del proyecto.
medidas correctivas.
Amenaza de Si la situacin financiera es Se tiene planeado aceptar la propuesta

abandonar el crtica al finalizar el mes de de trabajo en el extranjero. Y continuar la
proyecto. setiembre del 2014, entonces tesis en las noches y los fines de semana.
se tomarn medidas Adems se asignar el 40% de la venta
correctivas. del auto al presupuesto familiar.
Tabla 1-1: Registros de los riesgos del proyecto.
1.5 Justificativa y viabilidad
En esta seccin se presenta la justificativa de esta investigacin, as como la viabilidad del

mismo, con los cuales se logr la aceptacin para que la investigacin propuesta sea
considerada como proyecto de tesis.
Justificativa
Las circunstancias para desarrollar esta investigacin resulta de la investigacin recogida en

la seccin 1.1. Por tanto, a continuacin se explica los motivos ms importantes para llevar a
cabo este proyecto:
Modificado: 11/09/2017 04:52 p.m.

15
Cuando una corporacin tiene un sistema altamente transaccional, usualmente el gerente de
TI recomienda la compra de otras soluciones informticas para configurar las tablas de estas
bases de datos para tratar el problema de bajo rendimiento.
Entonces se generan enormes costos de licenciamientos y mantenimiento anual de estas

tecnologas adicionales. Esto es un problema que enfrentan las empresas, el costo carsimo
de otras licencias extras para este tipo de sistemas.
Por tanto, el propsito de esta investigacin permitir implementar una solucin econmica y
fcil de usar que automatizar el proceso de divisin de tablas con abundante informacin y
mejorar el tiempo de respuesta de consulta a ellas.
Viabilidad
Para posibilitar las probabilidades de llevar a cabo el proyecto, se decidi instalar como motor
de base de datos, la versin Oracle Database Express Edition (XE). A continuacin se
examina por qu, distinguindolos y separndolos en tres aspectos: en la viabilidad
econmica, tcnica y temporal.
Viabilidad econmica
Los costos generados fueron agrupados en dos aspectos: en el uso del software y en el trabajo
realizado por el tesista.
Con respecto al uso de la licencia de Oracle Database XE, este software est disponible sin
cargo por su uso, modificacin, distribucin y es fcil de instalar.
Con respecto al trabajo realizado por el tesista, los costos est en funcin al tiempo dedicado
a las actividades del proyecto, por lo tanto, seguidamente se presenta un resumen de las
principales actividades realizadas en la construccin del ambiente de trabajo para la tesis. En
la figura 1-6 se describe la descomposicin de estas actividades.
Modificado: 11/09/2017 04:52 p.m.

16
Ambiente de trabajo para el
proyecto de tesis
Elaborar el plan Crear la mquina Instalar el software de Actualizar el

de actividades virtual BD documento
Preparar un resumen de Preparar un resumen de

Planear y estimar las
la documentacin de la documentacin de Tipear los anexos
actividades a realizar
Oracle VirtualBox Oracle Database XE
Preparar el documento Descargar e instalar el Planear la instalacin de Tipear los scripting

software de virtualizacin Oracle Database XE
Crear tablas en el
Descargar Oracle
Investigar herramientas documento
Preparar un resumen de Database XE
softwares la documentacin de
Oracle Linux 5 Release 2 Configurar los interface de
red
Buscar infomacin de
virtualizacin Descargar e instalar el
sistema operativo OL52 Configurar el storage
Buscar infomacin de
sistemas operativos Actualizar el documento
Crear los file systems
Buscar informacin de
base de datos Instalar Oracle Database
XE
Actualizar el documento
Figura 1-6: Actividades realizadas en la construccin del ambiente de trabajo.
Viabilidad tcnica
Acerca de la tecnologa, no se pretende determinar cul es la mejor, no hay ninguna relacin

comercial con los creadores de estos. Por lo tanto, la eleccin de la tecnologa base se debe
principalmente al fcil uso en proyectos pequeos.
La versin XE ofrece una solucin integral y compatible con los siguientes entornos de
desarrollo:
Oracle SQL Developer.

Oracle Application Express.
Java y PHP.
Los entornos mencionados son herramientas suficientes para manejar una base de datos
Oracle. Adems se ajusta a la finalidad de este proyecto.
Viabilidad temporal
Se decidi usar los productos de Oracle por ser la ms comercial y porque se posee mayor
experiencia en su tecnologa tanto en el motor de BD as como en las herramientas
mencionadas.
Adems, el tiempo asignado al proyecto es muy corto y; para evitar el riesgo de no cumplir
con los entregables, se decidi usar esta tecnologa.
Modificado: 11/09/2017 04:52 p.m.
17
1.6 Correlacin de los resultados esperados con las
secciones de este informe
En la tabla 1-2 se muestra la relacin del desarrollo de los objetivos especficos con la
ubicacin en este informe.
RESULTADO ESPERADO (RE) SECCIN
1.- Se espera un informe que explique el flujo de los procesos Todo el captulo tres y
de la solucin. cuatro.
2.- Visualizacin de una lista de tablas que tienen grandes Seccin 4.4.
cantidades de registros para que el DBA elija la tabla que
ingresar al proceso de particin.
3.- Pantallas interactivas para que el DBA personalice la Seccin 4.5.

configuracin de las particiones que sern creadas.
4.- Transparencia para que el usuario final o la aplicacin no Seccin 4.6.

tengan la necesidad de realizar otras operaciones al acceder a
la tabla que fue procesada.
5.- Aumento en el rendimiento de las consultas a la tabla que Seccin 4.7.

fue procesada.
Tabla 1-2: Correlacin de los RE con las secciones de este informe.
Modificado: 11/09/2017 04:52 p.m.

18
2
CAPTULO DOS: MARCO CONCEPTUAL

Algunos trminos descritos en este informe puede ser difciles de comprender para un lector
que no est familiarizado en los temas de base de datos, por tal motivo esta seccin trata de
explicar todos los trminos que fueron referenciados para ser explicados en este captulo.
Adems en este captulo slo incluye los conceptos que fueron utilizados en este informe.
Este captulo cubre los siguientes temas:
Marco terico.
Estado del arte.
2.1 Marco terico
Despus de completar la revisin de esta seccin se puede conocer y manejar los conceptos
relacionados al problema y a la solucin propuesta para enfrentar el bajo rendimiento cuando
las aplicaciones acceden a sus bases de datos con cantidades considerables de informacin.
En muchas formas, los profesionales de TI, incluso los especializados en bases de datos,
cuando modifican algunos ajustes para mejorar el rendimiento de sus aplicaciones lo realizan
siguiendo las recomendaciones del especialista de esa aplicacin o producto informtico. Y
Modificado: 11/09/2017 04:52 p.m.

19
quizs la tensin del momento o la poca duracin de la ventana de tiempo que tienen, les
impide revisar o tener ms claro algunos de las definiciones que a continuacin se describen.
Estructura lgico y fsico en una base de datos
Una base de datos tiene estructuras lgicos y fsicos. La relacin entre la base de datos, sus
tablespaces y sus datafiles se ilustra en la figura 2-1.
Figura 2-1: Tablespace y datafiles (fuente de la imagen [ORA04, 61]).
Cada base de datos se divide lgicamente en dos o ms tablespaces. Uno o ms datafiles

son explcitamente creados para cada tablespace para almacenar fsicamente los datos de
todos los segmentos en un tablespace.
Si se trata de un tablespace temporal, este tiene un archivo temporal en lugar de un archivo

de datos. Un datafile de un tablespace se puede almacenar fsicamente en cualquier
tecnologa de almacenamiento como SAN, NFS, NAS, ASM, Exadata, RAW, File System
[ORA04, 61].
Tablespace
Una base de datos est dividido en unidades de almacenamiento lgico llamados tablespaces.
Estos agrupan las estructuras lgicas relacionales con sus datafiles (archivos fsicos de
almacenamiento) respectivos. Por ejemplo: los tablespaces comnmente agrupa todos los
segmentos de una aplicacin para simplificar alguna operacin administrativa [ORA04, 62].
Modificado: 11/09/2017 04:52 p.m.

20
Oracle data block
En el nivel ms fino de granularidad, los datos de un BD Oracle se almacena en bloque de

datos llamados data block. Un bloque de datos corresponde a un nmero especfico de bytes
de espacio fsico en el disco. Un tamao de data block es especificado para cada tablespace
cuando es creado. Un BD usa y asigna espacio libre en bloques de datos Oracle [ORA04, 62].
Extents
El siguiente nivel de espacio lgico de un BD es el extent. Este es un nmero especfico

contiguo de data block Oracle (obtenidos en una simple asignacin). Estos son usados para
almacenar un tipo especfico de informacin. Los data block en un extent estn lgicamente
contiguos pero fsicamente pueden estar no contiguos [ORA04, 62].
Segments
El nivel de almacenamiento lgico de BD por encima de un extent es llamado un segment.

Este es un conjunto de extents asignados por una cierta estructura lgica. Por ejemplo:
segmento de datos, segmento de indexes, segmento UNDO o los segmentos temporales
[ORA04, 62].
ANSI
ANSI (por sus siglas en ingls: American National Standards Institute). Es la voz autorizada
de los Estados Unidos para supervisar el sistema de normas de estndares para los productos,
servicios, procesos y sistemas en los EEUU [WEB06].
Acerca de las vistas en la BD Oracle
Una vista es una representacin lgica de una o muchas tablas. En esencia, una vista es una
consulta almacenada que presenta datos de una o varias tabla, estas son llamadas tablas
base. Estas tablas base tambin pueden ser otras vistas. Todas las operaciones sobre una
vista en realidad afectan a las tablas base [ORA06, 102].
Las vistas permiten adaptar la presentacin de los datos a diferentes tipos de usuarios. Y
proporcionar un nivel adicional de seguridad a la tabla, al restringir el acceso a un conjunto
predeterminado de sus filas o sus columnas. Por ejemplo, en la figura 2-2 muestra como la
vista staff no muestra la columna salario de la tabla base employees [ORA06 ,102].
Modificado: 11/09/2017 04:52 p.m.

21
Figura 2-2: View, ejemplo (fuente de la imagen [ORA06, 103]).
Con la vista se puede ocultar la complejidad de los datos. Por ejemplo, una simple vista puede
definir una combinacin de filas y columnas de varias tablas. Sin embargo, la vista oculta el
hecho que esta informacin se origina a partir de varias tablas [ORA06, 102].
Una consulta tambin puede realizar numerosos clculos con datos de sus tablas base. De
este modo, los usuarios pueden consultar una vista sin saber cmo se llev a cabo dicho
clculo [ORA06, 102].
Presenta los datos en una perspectiva diferente de sus tablas base. Por ejemplo, el nombre
de las columnas de una vista puede ser cambiada sin afectar sus tablas base [ORA06, 102].
Se puede aislar los cambios en las definiciones de sus tablas base. Por ejemplo, si la
definicin de una vista hace referencia a ciertas columnas de su tabla base, y se agrega
nuevas columnas a la tabla, entonces la definicin de la vista no se afecta y todas las
aplicaciones que usan las vistas no son comprometidas [ORA06, 102].
A continuacin se presenta un ejemplo del uso de una vista: considere la tabla hr.employees
que tiene varias columnas y filas, para permitir a los usuarios mirar solo cinco de todas sus
columnas, se puede crear una vista como sigue:
CREATE VIEW staff AS

SELECT employee_id, last_name, job_id, manager_id, department_id
FROM employees
;
Modificado: 11/09/2017 04:52 p.m.

22
Como sucede en todas las consultas en general, la vista que define la consulta (query) no
puede contener la instruccin FOR UPDATE. En la figura 2-2 se presenta la vista staff creada.
Notar que la vista solo muestra cinco columnas de la tabla base [ORA06, 103].
Clave de particin
Este concepto es usualmente utilizado en el proceso de particin de tablas de Oracle (Oracle

Database Partitioning), sin embargo este informe no es ajena a ello. La clave de particin
consiste en un grupo de columnas que determina la particin que residir una fila determinada
[ORA07, 2].
Operaciones o declaraciones llamados <<DML>>
Son las sentencias que modifican datos de los objetos de un esquema en particular. Por
ejemplo, la insercin y la eliminacin de filas son operaciones DML [ORA06, 176].
Operaciones o declaraciones llamados <<DDL>>
Las sentencias DDL definen objetos de un esquema. Por ejemplo, la creacin de una tabla o
agregar columnas a una tabla son operaciones DDL [ORA06, 176].
Acerca de los triggers
Un trigger de base de datos es una unidad de programa almacenado compilado, escrito en

PL/SQL o en JAVA, que la BD de Oracle invoca automticamente cada vez que se produce
una de las siguientes operaciones:
Declaraciones DML sobre una tabla o vista particular.

Declaraciones DDL invocado por cualquier usuario.
Por eventos de base de datos (por ejemplo: inicio de sesin, cierre de sesin, encender
o apagar la base de datos son eventos que se pueden invocar a travs de los triggers).
Los triggers son objetos del esquema similares a los programas pero difieren en la manera
como ellos son invocados. Un programa es ejecutado explcitamente por un usuario,
aplicacin o trigger. Los triggers son implcitamente invocados por la base de datos cuando
ocurre algn evento descrito en el prrafo anterior [ORA06, 176].
Tipos de triggers
Los triggers pueden ser categorizados de acuerdo a su significado de invocacin y al tipo de

accin que ellos realizan. Oracle Database soporta los siguientes tipos de triggers:
Modificado: 11/09/2017 04:52 p.m.

23
Row trigger.
Statement trigger.
Instead of trigger (este es el tipo de trigger que se us en esta solucin).
Event triggers.
A continuacin se explica el tem Instead of trigger. Sin embargo, se puede revisar los otros
en la documentacin oficial de Oracle [WEB01].
<<INSTEAD OF Trigger>>
Una vista (revise la nota previa, Acerca de las vistas en la BD Oracle) presenta la salida de
una consulta (query) como una tabla. Si se desea cambiar la vista como si se tratara de una
tabla, entonces se debe crear INSTEAD OF Trigger [ORA09, 157].
Este tipo de trigger es til para modificar vistas en forma transparente debida que no se puede
modificar directamente a travs de las declaraciones DML [ORA06, 178].
El Instead of trigger es definido sobre una vista, y su evento que le invoca es cualquier
declaracin DML. En lugar de ejecutar una operacin DML, el motor de BD Oracle ejecuta
este trigger [ORA09, 154].
Una vista presenta la salida de una consulta como una tabla. Para cambiar la vista como si se
tratara de una tabla, se debe crear Instead of trigger. En lugar de cambiar la vista, se cambiar
las tablas base de la vista [ORA09, 157].
Leyendo y entendiendo el plan de ejecucin
Para ejecutar una sentencia SQL, el motor de BD Oracle necesita realizar muchos pasos. En
cada paso recupera la fila de datos fsicamente de la BD o los prepara para el usuario que
emiti la sentencia. La combinacin de los pasos que Oracle usa para ejecutar una sentencia
es un plan de ejecucin (execution plan) [ORA08, 310].
Se puede examinar el plan de ejecucin escogido por el optimizador para una sentencia SQL
mediante el uso de la declaracin EXPLAIN PLAN. Cuando la declaracin es emitida, el
optimizador escoge un plan de ejecucin y luego inserta datos describiendo el plan en una
tabla de la BD. Simplemente se emite la declaracin EXPLAIN PLAN y luego se consulta la
tabla mencionada [ORA08, 310].
La declaracin EXPLAIN PLAN muestra los planes de ejecucin elegidos por el optimizador
para las sentencias SELECT, UPDATE, INSERT y DELETE. Un plan de ejecucin es la secuencia
de operaciones que la BD realiza para ejecutar una sentencia [ORA08, 317].
Modificado: 11/09/2017 04:52 p.m.

24
La tabla del plan de ejecucin muestra la siguiente informacin:
El orden de las tablas referenciadas por la sentencia DML.

El mtodo de acceso por cada tabla mencionada en la sentencia DML.
El mtodo de combinacin para tablas afectadas por las operaciones de unin en la
sentencia DML.
Operaciones con los datos como filtrar, ordenar o agregacin.
Optimizacin, como el costo y el nmero de elementos de cada operacin.
Los resultados del EXPLAIN PLAN permiten determinar si el optimizador selecciona un plan de
ejecucin particular, como los bucles anidados. Este resultado tambin permite entender las
decisiones del optimizador y el rendimiento de una consulta [ORA08, 318].
2.2 Estado del arte
En el transcurso de esta investigacin se busc otras publicaciones y soluciones parecidas

que existen hasta antes de la fecha de publicacin de este informe. A continuacin se
presentan cada uno de estos hallazgos:
<<Informatica Data Subsets>>
Informatica Data Subsets es un software para la creacin de subconjuntos de datos en una

base de datos reduciendo el esfuerzo y el espacio en disco necesario para dar soporte a las
aplicaciones [WEB02].
Caractersticas del producto
Se puede crear un subconjunto de datos en aplicaciones heterogneas y base de datos, tales

como: Oracle, DB2, SQL Server, Sybase, Teradata. Adems en plataformas como Windows,
UNIX/Linux y Z/OS.
Se puede controlar el proceso de dividir los datos desde un ambiente central con motor
multiprocesos que maneja largo volmenes de datos. Proporciona aceleradores predefinidos
para varias aplicaciones empresariales, tales como: ERP, SFA, CRM, SCM, Oracle E-
Business Suite, SAP, PeopleSoft, Siebel [WEB02].
Cuadrante mgico de Gartner, Inc.
En una publicacin oficial de Gartner, Inc., lder en investigacin en TI del mundo y asesora
de compaas, ubic a la empresa <<Informatica>> en el cuadrante lder para la integridad de
la visin [WEB03].
Modificado: 11/09/2017 04:52 p.m.
25
En la figura 2-3 es un grfico que fue publicado por Gartner, Inc. Como parte de una larga
investigacin esta debe ser interpretada en el contexto de la publicacin. Esta se encuentra
en los anexos de este informe, en la seccin llamado Magic Quadrant for Structured Data
Archiving and Application Retirement.
Figura 2-3: Cuadrante mgico de Gartner (fuente de la imagen [WEB04]).
<<Oracle Partitioning en Oracle Database 12c>>
Oracle Partitioning es una tecnologa que permite que las tablas, ndices y las tablas de ndice-
organizado (Index-Organized Tables) puedan ser divididos en partes ms pequeas
denominadas particiones [WEB05].
Modificado: 11/09/2017 04:52 p.m.

26
De esa manera permite que los objetos de BD puedan ser gestionados y accedidos a un nivel
ms fino. Cada particin posee un nombre propio y pueden poseer caractersticas de
almacenamientos particulares. Adems es completamente transparente para casi cualquier
aplicacin sin la necesidad de cambios en las mismas. Oracle Partitioning esta direccionado
para soportar actividades de tablas e ndices de gran tamao, generalmente contenidas en
BD de gran tamao denominadas Very Large Databases (VLDB) los cuales estn compuestas
de cientos de gigabytes o terabytes [WEB05].
Perspectivas de Oracle Partitioning para un DBA y para las aplicaciones
Desde la perspectiva de un administrador de base de datos (DBA), un objeto particionado

posee mltiples piezas que se pueden administrar ya sea colectiva o individualmente. Esto le
da al administrador una gran flexibilidad en el manejo de las mismas. Sin embargo, para las
aplicaciones una particin es idntica a una tabla sin particiones; no es necesario realizar
modificaciones al acceder a una particin [WEB05].
Cuadro comparativo sobre el estado del arte
Despus de comparar las principales particularidades de los productos en el mercado, se

puede anunciar que est solucin tiene todas las caractersticas mencionadas en la tabla 2-1,
entre las ms importantes: ser fcil de instalar y usar; y sobre todo, econmico. Seguidamente,
se presenta un cuadro comparativo sobre lo encontrado en el mercado para poder sustentar
la elaboracin de la tesis.
CARACTERSTICAS INFORMATICA ORACLE

DATA PARTITIONING
SUBSETS
Framework es libre. No No
Framework tiene estndares conocidos. No No
Fcil entendimiento de la documentacin. Si Si
Documentacin es libre. No Si
Se integra con productos no propietarios. Si No
Posee una herramienta administrativa. Si Si
Tabla 2-1: Cuadro comparativo sobre el estado del arte.
Modificado: 11/09/2017 04:52 p.m.

27
3
CAPTULO TRES: ANLISIS

Preliminares.
Vista panormica de la solucin.
Anlisis de los datos.
Creacin de las particiones.
Enmascaramientos de las particiones.
Desplazamientos de los datos.
Manipulacin de los datos.
Resumen del anlisis.
3.1 Preliminares
En el inicio de la discusin del anlisis, se utilizaron diversos recursos fundamentales para

facilitar la identificacin de estrategias y, con ello, favorecer la culminacin de este trabajo. Es
necesario conocer estos recursos para tratar slidamente este captulo:
Abreviaturas y definiciones.
Observaciones encontradas al definir la solucin.
Modificado: 11/09/2017 04:52 p.m.

28
Abreviaturas y definiciones
El catlogo que define todos los trminos y abreviaturas se encuentra en los anexos. No
obstante, es necesario mostrar algunas usadas en este captulo:
BD: Base de datos.

CE: Caso de estudio del proyecto.
SQL: Structured Query Language, SQL es un lenguaje estndar ANSI para operaciones
relacionales en BD.
TI: Tecnologa de la informacin.
Observaciones encontradas al definir la solucin
Con respecto al motor de la BD, se hall que este sistema tiende a tener muchas operaciones
de lectura aleatorias y secuenciales. Esta mezcla de operaciones causa, tambin, problemas
en las operaciones de lectura en los discos. Similar para las operaciones de escritura.
Esto se puede aplicar para resolver el problema que presentan los procesos de copias de
seguridad, por ejemplo. La explicacin principal del por qu es la enorme duracin que exigen
estos procesos, lo que origina poca disponibilidad para otros sistemas.
Durante el anlisis, se determin que las operaciones de lectura y escritura en los discos
fsicos son consideradas estratgicas y deberan acompaar en el planeamiento de esta
solucin. Son estratgicas porque eliminando el potencial problema que tienen stos, ser
tambin una decisin clave para lograr una optimizacin completa en la BD.
Asimismo, en los requerimientos se estableci que esta propuesta no sea examinada. La

explicacin fue que la configuracin de discos no se ajusta a la justificacin principal al ttulo
de este informe. Adems el poco tiempo asignado en la investigacin contribuy que este
asunto no sea tratado. Sin embargo se retomar en una versin futura de esta solucin.
3.2 Vista panormica de la solucin
Una visin general de la solucin se observa en la figura 3-1, esta ser la gua principal para
toda la explicacin de este captulo.
Modificado: 11/09/2017 04:52 p.m.

29
BD
BD produccin
produccin
Vista de
particiones
1.
1. Anlisis
Anlisis de
de los
los datos
datos
3. Enmascaramiento
2. Creacin de las particiones de las particiones
Creacin de la vista de
Seleccionar de la tabla de mayor crecimiento particiones
Datos
Tabla enorme
4. Desplazamiento
de los datos
De la tabla enorme hacia las
particiones
5. Manipulacin de los datos

Configurar la vista para que administre las
operaciones con los datos en las particiones
Figura 3-1: Fases de la tcnica de optimizacin
Si se mira de izquierda a derecha, y de arriba hacia abajo; la secuencia de fases de la solucin

es:
1. Anlisis de los datos (examinar las tablas de mayor crecimiento).

2. Creacin de las particiones.
3. Enmascaramiento de las particiones (creacin de la vista de particiones).
4. Desplazamiento de los datos (de la tabla hacia las particiones).
5. Manipulacin de los datos (configurar la vista para que administre las operaciones con
los datos en las particiones).
A continuacin se explicarn con mayor amplitud los diversos aspectos de cada uno de las
fases mencionadas.
3.3 Anlisis de los datos
Es la primera fase de la solucin, la cual consiste bsicamente en buscar las tablas de mayor
crecimiento y clasificarlas de acuerdo con su valor en la aplicacin. Y con ello, determinar las
que tienen problemas de rendimiento.
Este es un procedimiento manual porque se necesita estudiar la naturaleza de la tabla, tales

como: el tamao de sus registros, que tipo de dato se utiliza en cada columna, el tipo y tamao
Modificado: 11/09/2017 04:52 p.m.

30
de su tablespace, etc., lo cual sirve para el anlisis de la existencia de algn impacto negativo
en las aplicaciones involucradas.
El resultado de esta fase es la tabla que origina el problema de rendimiento, la cual ser el
input para el proceso de optimizacin. Este es un paso muy importante porque es el origen
para que empiecen las siguientes fases.
3.4 Creacin de las particiones
La creacin de particiones consiste en fraccionar la tabla gigante en otras ms pequeas, con

la finalidad de obtener beneficios en el rendimiento de las consultas y en las tareas de
mantenimiento. Usualmente a este proceso es conocido como particin de tablas y a las tablas
divididas, se le llama particiones. As lo definen los buscadores por Internet.
Se puede decir que este mtodo est muy usado por las empresas de software que ofrecen
tecnologas relacionadas con la BD. Sin embargo, esta solucin no es ajena a ello. Entonces
esta etapa consiste bsicamente crear nuevas tablas con la misma estructura de la tabla
gigante pero sin datos, el llenado de las particiones se explica en la seccin 3.6.
3.5 Enmascaramiento de las particiones
Ahora la tabla gigante ya no existe o fue alterada (puede haber cambiado su nombre o fue
movida hacia otro lugar). Pero se necesita que la aplicacin siga consultando estas particiones
de forma inadvertida. Es decir, la aplicacin no necesita enterarse que su tabla gigante ya no
existe.
Para lograr eso, se utilizar una presentacin lgica una capa de abstraccin que agrupa
subconjuntos de combinaciones de datos; en otros trminos, una tabla lgica basada en una
o varias tablas. En el mundo de la informtica, esa definicin es conocida como vista, (revise
el detalle en el marco terico).
Entonces aqu se puede indicar que la vista agrupa las particiones y los enmascara para su
fcil administracin.
3.6 Desplazamiento de los datos
Luego de tener creadas las nuevas particiones, se mueven los datos de la tabla gigante hacia
sus respectivas tablas, segn algn criterio de seleccin, conocido como clave de particin o
columna pivote.
Modificado: 11/09/2017 04:52 p.m.

31
El criterio de seleccin puede ser un conjunto de columnas que establece en que particin se
ubicar un registro de la tabla gigante. En esta parte se pueden aplicar diferentes modalidades
o mecanismos, las cuales los buscadores por Internet lo llaman Estrategias de
particionamiento.
3.7 Manipulacin de los datos
Despus de conseguir la vista de las particiones con sus datos respectivos. Ahora falta la
administracin de los datos que encapsula la vista. Este proceso se tratar con profundidad
en los siguientes captulos.
Sin embargo, se puede adelantar que para manipular los datos de la vista es necesario saber
qu operaciones se estn invocando sobre ella. Esta invocacin se logra a travs de un
procedimiento en la BD que se ejecutar cuando cumpla alguna condicin en la vista. Estas
condiciones pueden ser operaciones de manipulacin de datos, como insertar, borrar o
actualizar registros.
En el mundo de la informtica, esa definicin es conocida como trigger, en realidad es un tipo

especial de trigger, llamado instead of (revise el detalle en el marco terico).
3.8 Resumen del anlisis
El informe se basa en el CE, pues proporcion supuestos necesarios en las diferentes fases
del anlisis, sin lo cual no se hubiera terminado este informe.
Se recomend solo enfocarse en planear una estrategia para la particin de tablas y no en la

configuracin de los discos, porque no cumple cabalmente el objetivo de esta investigacin.
Sin embargo se retomar este criterio en una versin futura de esta solucin.
El desarrollo de la tcnica de optimizacin consiste bsicamente en la particin de tablas. El

cual tiene las siguientes fases:
1. Anlisis de los datos (examinar las tablas de mayor crecimiento).

2. Creacin de las particiones.
3. Enmascaramiento de las particiones (creacin de la vista de particiones).
4. Desplazamiento de los datos (de la tabla hacia las particiones).
5. Manipulacin de los datos (configurar la vista para que administre las operaciones con
los datos en las particiones).
Modificado: 11/09/2017 04:52 p.m.

32
4
CAPTULO CUATRO: DISEO

Preliminares.
Resumen de alto nivel del proceso de optimizacin.
Diagrama del flujo del proceso de optimizacin.
Visualizacin de las tablas de mayor crecimiento.
Pantallas interactivas para el DBA.
Transparencia para la aplicacin.
Rendimiento de las consultas a la tabla.
4.1 Preliminares
Para ejecutar el proceso de optimizacin se requiere conocer los siguientes recursos, trminos
y tareas previos para favorecer la comprensin del diseo de esta solucin:
Abreviaturas y definiciones.
Acerca de los scripts que construye el CE.
Acerca de los scripts de instalacin.
Acerca de los scripts del proceso.
Modificado: 11/09/2017 04:52 p.m.

33
Pasos previos a la ejecucin del proceso de optimizacin.
Abreviaturas y definiciones
A continuacin se describe algunas de las abreviaturas utilizadas en este captulo con sus
respectivas definiciones tales como:
CE: Caso de estudio del proyecto.

SO: Sistema operativo.
RE: Resultado esperado.
POS: Point of Sale terminal, que significa terminal de punto de venta.
ATM: Automated Teller Machines, que significa mquinas de cajero automtico.
Query: En BD significa consulta, quiere decir que un query en un BD realiza una bsqueda
de datos de una o varias tablas.
Acerca de los scripts que construye el CE
La instalacin del ambiente del caso a probar conforma tres conjuntos de scripts, distribuidos
de la siguiente forma:
1. Script para la creacin de tablespaces, creacin del esquema propietario de la

aplicacin y otorgamiento de privilegios necesarios al esquema.
2. Script para la creacin de todos los objetos del esquema propietario, tales como,
creacin de tablas y creacin de secuencias.
3. Script para la insercin de datos.
Acerca de los scripts de instalacin
Son los scripts para la implementacin del producto en la BD, los cuales instalan todos los
objetos para dar soporte al proceso de optimizacin.
Acerca de los scripts del proceso
Son los scripts para ejecutar el proceso de optimizacin en la BD. Estn agrupados en dos
partes: los relacionados con las pantallas y la generacin de las sentencias DDL, y los
relacionados con la ejecucin de las sentencias generadas.
Pasos previos a la ejecucin del proceso de optimizacin
Modificado: 11/09/2017 04:52 p.m.

34
Asegurarse que el usuario del SO que ejecutar los comandos del proceso de optimizacin
tiene el acceso completo a la ubicacin fsica del directorio base donde se encuentran los
paquetes de scripts de la instalacin, as como las del proceso.
Por ejemplo, para este caso, se copi todos los scripts mencionados (los del CE, los de la
instalacin y los del proceso) hacia un directorio en el computador que aloja la BD
(/u01/tesis); este folder se cre con los permisos de escritura y ejecucin (chmod -R 0777
/u01/tesis).
Despus de copiar todos los paquetes de scripts hacia el folder mencionado (/u01/tesis) se
debera tener una distribucin de archivos como se muestra en la tabla 4-1:
-bash-3.2$ tree
.
|-- ce
| |-- PUCPTESIS_CASOESTUDIO_parte01.sql
| |-- main.sql
| `-- parametros.sql
|-- install
| |-- PUCPTESIS_PARTICION_instalacion.sql
| |-- main.sql
| `-- parametros.sql
`-- process
|-- 1a.sql
|-- 1b.sql
|-- 1c.sql
|-- 1d.sql
|-- 1e.sql
|-- 1f.sql
|-- 2a.sql
|-- 2b.sql
|-- 2c.sql
|-- 2d.sql
|-- end.sql
|-- infotabla.sql
|-- init.sql
|-- main.sql
|-- main1.sql
|-- main2.sql
|-- parametros.sql
|-- readme.sql
`-- set.sql
3 directories, 27 files
Tabla 4-1: Distribucin de scripts.
Modificado: 11/09/2017 04:52 p.m.

35
4.2 Resumen de alto nivel del proceso de optimizacin
El proceso tiene dos partes principales:
Parte 1: Las pantallas de interaccin con el DBA.

Parte 2: La ejecucin de proceso de forma automtica.
Parte 1: Las pantallas de interaccin con el DBA
El proceso de optimizacin empieza con la visualizacin de las tablas ms pesadas de la

aplicacin, con el propsito de que el DBA escoja de la lista aquella que requiera ser
optimizada. Es importante asegurar que se haya realizado el estudio previo de la tabla
seleccionada, como se mencion en la seccin 3.3 en la nota Anlisis de los datos.
Luego el proceso contina con pantallas interactivas para que el DBA proporcione una
configuracin personalizada segn su criterio o valide los valores predeterminados por el
programa.
Mientras se dialoga con el usuario, el motor va construyendo sentencias DDL con la

informacin que obtuvo previamente. Al finalizar la participacin con el DBA, el programa le
presenta las declaraciones DDL que gener y pide la autorizacin a l para ejecutarlas.
Parte 2: La ejecucin de proceso de forma automtica
Aqu se ejecuta la siguiente secuencia de sentencias DDL generados en la fase previa:
Creacin de las particiones de la tabla.

Creacin de la vista de particiones.
Migracin de los datos de la tabla hacia las particiones.
Creacin del trigger sobre la vista.
4.3 Diagrama del flujo del proceso de optimizacin
En la figura 4-1 se muestra el diagrama principal del flujo del proceso.
Modificado: 11/09/2017 04:52 p.m.

36
Inicio del proceso de
optimizacin
Visualizar las tablas ms

pesadas de la aplicacin
Seleccionar la tabla que origina No

el problema de rendimiento
No Personalizar la configuracin de
las particiones por parte del DBA
Generar las sentencias DDL
Recuperar
informacin de la El DBA autoriz la
PRE PARTICIN Si ejecucin de las sentencias
DDL generadas por el
motor?
Ejecutar las sentencias DDL
Reporte del
proceso
Fue exitoso?
Si
Proceso completo
Figura 4-1: Diagrama de flujo del proceso.
4.4 Visualizacin de las tablas de mayor crecimiento
Para presentar las tablas ms pesadas se elabor un query sobre la vista USER_EXTENTS para
obtener el tamao de las tablas del dueo de la aplicacin. Las tablas de mayor tamao son
presentadas de forma descendente. Por ejemplo, en la figura 4-2 se muestra el resultado de
ejecutar el script que contiene el query.
4.5 Pantallas interactivas para el DBA
A continuacin se explica con mayor detalle lo mencionado en la seccin 4-4. En la primera

parte del proceso se presenta pantallas, las cuales permiten una interaccin a modo de
Modificado: 11/09/2017 04:52 p.m.

37
dilogo entre proceso y usuario. La primera pantalla interactiva se observa en la figura 4-2,
donde el programa pide que escriba o escoja la tabla que ingresar al proceso de optimizacin.
Figura 4-2: Lista de tablas pesadas.
Durante el diseo se busc hacer fcil la personalizacin del proceso, en el que el DBA ingresa
su configuracin o valida los valores predeterminados por el programa, esto es una opcin til
para l. Segn el ejemplo, la JOURNALTXGIGANTE ser la ms indicada. En la figura 4-3, se
ilustra mejor este prrafo.
La tabla no es obligatorio que figure en la lista mencionada, porque ella puede ser muy grande
en el corto plazo y no esperar que lo sea. Por ende, el programa permite el ingreso de
cualquier tabla.
Modificado: 11/09/2017 04:52 p.m.

38
Figura 4-3: Seleccin de la pantalla gigante.
En la siguiente pantalla se pide la seleccin de la columna pivote (revise la nota clave de

particin en la seccin 2.1, para ms detalle).
Figura 4-4: Seleccin de la columna pivote.
Modificado: 11/09/2017 04:52 p.m.

39
El DBA deber ingresar cualquiera de las columnas de la tabla. En la figura 4-4, se presenta
un ejemplo donde se escogi la columna CANAL que ser la clave de la particin.
El siguiente dilogo solicita el tipo de particin por la cual se desea realizar el proceso de
particin. En la figura 4-5, se presenta este caso.
Figura 4-5: Seleccin del tipo de particin.
Luego se muestra la lista de las particiones que sern creadas y se pide al DBA que actualice
esa informacin. En la figura 4-6, se ilustra esta situacin.
Figura 4-6: Lista de particiones que se crearn.
Modificado: 11/09/2017 04:52 p.m.

40
Figura 4-7: Pantalla para configurar una particin.
Antes de proporcionar la conformidad del proceso, el DBA puede personalizar ms los valores
que el programa ha establecido de forma predeterminada. Un ejemplo de cmo puede
modificar esos valores se muestra en la figura 4-7. Entre los valores que se pueden cambiar
estn: el nombre de la particin, la columna pivote y el tablespace.
Continuando con el ejemplo de las pantallas presentadas, para modificar el nombre

predeterminado de la particin ASOCIACIONTARJETA por TARJETAS, simplemente
actualizamos el cuadro de texto correspondiente como se muestra en la figura 4-8.
Figura 4-8: Modificando el nombre de la particin.
Despus actualizar la configuracin preestablecida sugerida por el programa, el DBA debe

ingresar su confirmacin mediante la letra Y como se ilustra en la figura 4-9.
Figura 4-9: Actualizando informacin de las particiones.
Luego, el programa genera las sentencias DDL de cada particin para que el DBA valide la
declaracin. En la figura 4-10, se ejemplifica esta parte.
Modificado: 11/09/2017 04:52 p.m.

41
Figura 4-10: Sentencia DDL de la particin.
De no estar conforme con la declaracin, puede regenerar la DDL actualizando nuevamente

los valores de los cuadros de texto como se ilustra en la figura 4.7.
La participacin con el DBA termina con su autorizacin para la ejecucin de las sentencias
DDL generadas por el programa. La figura 4-11 es el ltimo dialogo con el usuario.
Figura 4-11: Autorizacin para la creacin de particiones.
4.6 Transparencia para la aplicacin
El RE4, transparencia para la aplicacin, se encuentra en la segunda parte del proceso, segn
el cual el programa ejecuta la consecuente secuencia de sentencias DDL generados cuando
el programa interactuaba con el DBA:
Modificado: 11/09/2017 04:52 p.m.

42
Creacin de las particiones de la tabla.
Creacin de la vista de particiones.
Migracin de los datos de la tabla hacia las particiones.
Creacin de constraints.
Creacin del trigger sobre la vista.
Creacin de las particiones de la tabla
Despus que el DBA autoriz continuar con la segunda parte del proceso, seguidamente se
ejecuta las sentencias DDL de las particiones generadas. En la figura 4-12, se ejemplifica la
creacin de nuevas tablas sin datos y con la misma estructura de la original.
Creacin de las particiones
Tabla enorme
Figura 4-12: Creacin de las particiones.
Creacin de la vista de particiones
Para lograr la transparencia para la aplicacin, el diseo contempl el us de una

representacin lgica para enmascarar todas las particiones (tablas) creadas y encubrir la
complejidad de la solucin. Esto se logr mediante la creacin de la vista de particiones. En
la figura 4-13 se ilustra mejor este prrafo.
Modificado: 11/09/2017 04:52 p.m.

43
Vista de
particiones
Enmascaramiento de
las particiones
particiones
Tabla enorme
Figura 4-13: Creacin de la vista de particiones.
Migracin de los datos de la tabla hacia las particiones
Despus de la vista, el programa ordena los registros con respecto a la columna pivote y
determina los rangos de registros con la finalidad de moverlos a las particiones
correspondientes. En la figura 4-14 se ilustra esta parte.
Vista de
particiones
Enmascaramiento de
las particiones
particiones
Tabla enorme
Datos
Migracin de los datos
De la tabla enorme hacia las

particiones
Figura 4-14: Migracin de los datos.
Creacin de constraints
Modificado: 11/09/2017 04:52 p.m.

44
Luego de la migracin de los datos a sus respectivas tablas, segn su clave de particin, se
crea constraints de tipo check en ellas, lo cual garantiza que los nuevos registros se
encuentren en sus concernientes particiones.
Creacin del trigger sobre la vista
En esta versin inicial del producto, las operaciones DML son la consulta de la tabla y la
insercin de registros en ella. (Revise la seccin 2.1 para conocer ms de las operaciones
DML). El diseo puso atencin en utilizar los triggers sobre la vista.
Durante la investigacin se determin que el tipo de trigger llamado INSTEAD OF TRIGGERS,

permite manipular los datos que administra la vista como si se tratara de una tabla. (Revise
la seccin 2.1 para obtener ms detalle acerca de este trigger). Por tanto, este diseo
contribuye la transparencia para la aplicacin (RE4).
4.7 Rendimiento de las consultas a la tabla
La medicin del rendimiento de la tabla cuando aquella es consultada, es trascendental para

la justificacin de esta investigacin. Entonces para determinar la ganancia en el rendimiento
y notar el beneficio, se utiliz la comparacin de los planes de ejecucin de la consulta, antes
del proceso de optimizacin y despus de ello.
Tambin se realizaron pruebas que comparan los tiempos de respuesta en los momentos
mencionados y se evidencia el resultado esperado. En el captulo 6, Pruebas de rendimiento,
se explica con ms detalle cmo se efectuaron estas pruebas.
Modificado: 11/09/2017 04:52 p.m.

45
5
CAPTULO 5: CONSTRUCCIN
Preliminares.
Instalacin del producto.
Proceso de optimizacin.
5.1 Preliminares
Para favorecer la comprensin del cmo se elabor la construccin de la herramienta de

optimizacin, se requiere conocer algunos recursos que fueron tiles:
Declaracin de variables en PL/SQL.

Beneficios de usar el atributo %TYPE.
Creacin de un registro con el atributo %ROWTYPE.
Creando un <<INSTEAD OF Trigger>>.
Declaracin de variables en PL/SQL
Modificado: 11/09/2017 04:52 p.m.

46
Sintaxis
Figura 5-1: Sintaxis declaracin de variables PL/SQL (fuente de la imagen [ORA03, 62]).
Ejemplo
Figura 5-2: Ej. Declaracin de variables PL/SQL (fuente de la imagen [ORA03, 62]).
Beneficios de uso el atributo %TYPE
Un error en el programa PL/SQL puede ocurrir durante su ejecucin. Entonces para evitar
consumir mucho tiempo analizando los diferentes errores en los extensos subprogramas del
producto, se us este tipo de atributo en la declaracin de variables PL/SQL. Por lo cual, se
asegur que la variable sea del tipo de dato correcto y preciso.
Este atributo se us frecuentemente en los subprogramas cuando el valor almacenado de las

variables es derivado de una de las tablas de la BD. Para usar este tipo de atributo para
declarar la variable; se debe prefijar el nombre de la columna y de la tabla BD, o el nombre de
otra variable declarada previamente; a la clusula %TYPE como se aprecia en la figura 5-3
[ORA03, 75].
El atributo %TYPE fue usado para declarar una variable con lo cual se obtuvo las siguientes
ventajas:
Se evit errores causadas por falta de coincidencia de tipos de datos o por precisiones
equivocados.
Se evit el uso de codificar fijamente la declaracin del tipo de dato (hard coding).
Se evit actualizar la declaracin en las variables cuando cambiaban la definicin de la
columna.
Ejemplo
Modificado: 11/09/2017 04:52 p.m.

47
Figura 5-3: Sintaxis %TYPE (fuente de la imagen [ORA03, 77]).
Creacin de un registro con el atributo %ROWTYPE
El atributo %ROWTYPE es usado para declarar un registro que puede mantener una fila entera
de una tabla o vista [ORA03, 188].
Sintaxis
Figura 5-4: Sintaxis %ROWTYPE (fuente de la imagen [ORA03, 188]).
Creando un <<INSTEAD OF Trigger>>
El INSTEAD OF trigger cambia las tablas base de una vista. A continuacin se presenta un
ejemplo donde la vista EMP_LOCATIONS tiene la columna NAME creada por las columnas
LAST_NAME y FIRST_NAME de la tabla EMPLOYEE. [ORA09, 157].
CREATE VIEW EMP_LOCATIONS AS

SELECT e.EMPLOYEE_ID
, e.LAST_NAME || ', ' || e.FIRST_NAME NAME
, d.DEPARTMENT_NAME DEPARTMENT
, l.CITY CITY
, c.COUNTRY_NAME COUNTRY
FROM EMPLOYEES e
, DEPARTMENTS d
, LOCATIONS l
, COUNTRIES c
WHERE e.DEPARTMENT_ID = d.DEPARTMENT_ID
AND d.LOCATION_ID = l.LOCATION_ID
AND l.COUNTRY_ID = c.COUNTRY_ID
ORDER BY LAST_NAME
;
Para actualizar EMP_LOCATIONS.NAME se debe actualizar las tablas EMPLOYEES.LAST_NAME y

EMPLOYEES.FIRST_NAME; para ello, se usa el INSTEAD OF Trigger, como se aprecia en el
siguiente ejemplo:
Modificado: 11/09/2017 04:52 p.m.

48
CREATE OR REPLACE TRIGGER update_name_view_trigger
INSTEAD OF UPDATE ON emp_locations
BEGIN
UPDATE employees SET
first_name = substr( :NEW.name, instr( :new.name, ',' )+2)
, last_name = substr( :NEW.name, 1, instr( :new.name, ',')-1)
WHERE employee_id = :OLD.employee_id
;
END
;
INSTEAD OF DML Triggers
Un INSTEAD OF trigger es la nica manera de actualizar una vista porque esta no puede por s
misma. Por lo cual, se debe establecer previamente un diseo de operaciones DML apropiadas
en las tablas base [ORA10, 338]. A continuacin, un ejemplo:
-- Creacin de la vista:
------------------------
CREATE OR REPLACE VIEW order_info AS
SELECT c.customer_id,
c.cust_last_name,
c.cust_first_name,
o.order_id,
o.order_date,
o.order_status
FROM customers c
, orders o
WHERE c.customer_id = o.customer_id
;
-- Creacin del INSTEAD OF trigger:

-----------------------------------
CREATE OR REPLACE TRIGGER order_info_insert
INSTEAD OF INSERT ON order_info
DECLARE
duplicate_info EXCEPTION;
PRAGMA EXCEPTION_INIT(duplicate_info, -00001);
BEGIN
INSERT INTO customers
(customer_id, cust_last_name, cust_first_name)
VALUES (
:new.customer_id,
:new.cust_last_name,
:new.cust_first_name
)
;
INSERT INTO orders
(order_id, order_date, customer_id)
VALUES (
:new.order_id,
:new.order_date,
Modificado: 11/09/2017 04:52 p.m.

49
:new.customer_id
)
;
EXCEPTION
WHEN duplicate_info THEN
RAISE_APPLICATION_ERROR(num => -20107,
msg => 'Duplicate customer or order ID');
END order_info_insert
;
/
5.2 Instalacin del producto
En esta seccin se describe los scripts que implementan el producto para la solucin
propuesta. Lo cual contiene tres partes principales:
Parmetros.
Creacin de objetos para la implementacin.
Verificacin de objetos despus de la instalacin.
Parmetros
Son los parmetros necesarios para la ejecucin del script principal: el nombre de usuario y
su contrasea. A continuacin se muestra dos ejemplos:
Ejemplo 1: colocando el usuario y la contrasea en el comando de

ejecucin
sqlplus <usuario>/<contrasea> @install
Ejemplo 2: pasando como argumentos en el script parametros.sql
sqlplus /nolog @install
Adems, en el archivo install.sql se debe colocar el nombre del usuario dueo de la

aplicacin as como su contrasea, en este ejemplo: tesis y feliznavidad respectivamente:
@readme
@parametros 'tesis' 'feliznavidad'
@PUCPTESIS_PARTICION_instalacion
Modificado: 11/09/2017 04:52 p.m.

50
Esta forma es til para las modalidades donde los pases a produccin requieren que otra rea,
usualmente la de seguridad, valide la contrasea a travs de un proceso de codificacin as
como su descodificacin.
Creacin de objetos para la implementacin
El script crea las siguientes tablas para dar soporte al proceso de optimizacin:
TIPO_PARTICION.
TABLA_CANDIDATA.
PRE_PARTICION.
PARTICION.
Creacin de la tabla TIPO_PARTICION
A continuacin se muestra una porcin del script donde estn las sentencias DDL para la
creacin de la tabla TIPO_PARTICION:
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~ Creacion de la tabla TIPO_PARTICION ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
CREATE TABLE TIPO_PARTICION(

PARTITION_TYPE VARCHAR2(10),
PARTITION_DESCRIPTION VARCHAR2(40)
)
;
ALTER TABLE TIPO_PARTICION

ADD CONSTRAINT PARTICIONTIPO_PK PRIMARY KEY (PARTITION_TYPE)
;
INSERT INTO TIPO_PARTICION (PARTITION_TYPE, PARTITION_DESCRIPTION)

VALUES ('LISTA','LIST')
;
INSERT INTO TIPO_PARTICION (PARTITION_TYPE, PARTITION_DESCRIPTION)

VALUES ('RANGO','RANGE')
;
Creacin de la tabla TABLA_CANDIDATA
creacin de la tabla TABLA_CANDIDATA:
Modificado: 11/09/2017 04:52 p.m.

51
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~ Creacion de la tabla TABLA_CANDIDATA ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
CREATE TABLE TABLA_CANDIDATA(

TABLE_NAME VARCHAR2(30),
TBS_NAME VARCHAR2(30),
TABLE_DDL VARCHAR2(4000)
)
;
ALTER TABLE TABLA_CANDIDATA

ADD CONSTRAINT TCANDIDATA_PK PRIMARY KEY (TABLE_NAME)
;
Creacin de la tabla PRE_PARTICION
creacin de la tabla PRE_PARTICION:
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~ Creacion de la tabla PRE_PARTICION ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
CREATE TABLE PRE_PARTICION(

TABLE_NAME VARCHAR2(30),
PARTITION_TYPE VARCHAR2(10),
PARTITION_NAME VARCHAR2(30),
PIVOT_COLUMN VARCHAR2(30),
PIVOT_COLUMN_VALUE VARCHAR2(30),
COUNT NUMBER(31),
TBS_NAME VARCHAR2(30),
UPDATE_REQUEST CHAR (1),
CREATED DATE NULL,
PARTITION_DDL VARCHAR2(4000),
CONFIRM_REQUEST CHAR (1)
)
;
ALTER TABLE PRE_PARTICION ADD CONSTRAINT PREPARTICION_TABLENAME_FK

FOREIGN KEY (TABLE_NAME) REFERENCES TABLA_CANDIDATA (TABLE_NAME)
;
ALTER TABLE PRE_PARTICION ADD CONSTRAINT PREPARTICION_PARTITIONTYPE_FK

FOREIGN KEY (PARTITION_TYPE) REFERENCES TIPO_PARTICION (PARTITION_TYPE)
;
Modificado: 11/09/2017 04:52 p.m.

52
Creacin de la tabla PARTICION
creacin de la tabla PARTICION:
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~ Creacion de la tabla PARTICION ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
CREATE TABLE PARTICION AS SELECT * FROM PRE_PARTICION

;
ALTER TABLE PARTICION

ADD CONSTRAINT PARTICION_PK PRIMARY KEY (PARTITION_NAME)
;
ALTER TABLE PARTICION ADD CONSTRAINT PARTICION_TABNAME_FK

FOREIGN KEY (TABLE_NAME) REFERENCES TABLA_CANDIDATA (TABLE_NAME)
;
ALTER TABLE PARTICION ADD CONSTRAINT PARTICION_PARTITIONTYPE_FK

FOREIGN KEY (PARTITION_TYPE) REFERENCES TIPO_PARTICION (PARTITION_TYPE)
;
Verificacin de objetos despus de la instalacin
El script de esta parte se encuentra en los anexos, en la seccin verificacionobjetos.sql,

sin embargo aqu se puede mencionar el resultado de su ejecucin:
Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit Production

Connected.
'INICIO de la ejecucion del script <<verificacion.sql>>. '
=========================================================================
~ ~
~ Verificacion de objetos: ~
~ ======================== ~
~ A. Estructura ~
~ A1. Informacion del tablespaces. ~
~ ~
~ B. Seguridad ~
~ B1. Informacion del usuario creado. ~
~ B2. Listado de privilegios sobre objectos. ~
~ ~
~ C. Esquema ~
~ C1. Lista de objectos del tablespace. ~
~ C2. Listado de Objetos PL/SQL. ~
~ ~
Modificado: 11/09/2017 04:52 p.m.

53
~ Parametros: ~
~ ===========
~ 1. USUARIO: tesis
~ 2. USUARIO_PASS: ******
~ ~
=========================================================================
Conexin: TESIS@XE, A las 18/12/2014 15:41:10
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ A. Estructura ~
~ A1. Informacion del tablespaces. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
LARGEST
SIZE TOTAL FREE
FILE FREE EXTENT ONLINE
FILE NAME (MB) (MB) (MB) STATUS STATUS
------------------------------ ---- ----- ------- ---------- ------
/u01/oradata/tesis_01.dbf .240 ....1 ......1 AVAILABLE ONLINE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ B. Seguridad ~
~ B1. Informacion del usuario creado. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
USUARIO TABLESPACE TABLESPACE
ESTADO ESQUEMA DEFAULT TEMPORAL CREACION PROFILE
------ ---------------- ---------- ---------- ---------- ----------
OPEN TESIS TESIS_TBS TEMP 18-DEC-14 DEFAULT
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ B2. Listado de privilegios sobre objectos. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROPIE
TARIO OBJETO PRIVILEGIO ADMINISTRA
---------- -------------------- ---------- ----------
SYS DIRDATAPUM READ NO
SYS DIRDATAPUM WRITE NO
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ B3. Listado de privilegios del sistema. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PRIVILEGIO ADMINISTRA
------------------------------ ----------
CREATE ANY TRIGGER NO
CREATE PROCEDURE NO
CREATE SEQUENCE NO
CREATE SYNONYM NO
CREATE TABLE NO
CREATE TRIGGER NO
CREATE VIEW NO
DEBUG CONNECT SESSION NO
EXECUTE ANY TYPE NO
SELECT ANY DICTIONARY NO
SELECT ANY TABLE NO
Modificado: 11/09/2017 04:52 p.m.

54
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ C. Esquema ~
~ C1. Lista de objectos del tablespace. ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROPIE SEGMENT SEGMENT SIZE
TARIO TYPE NAME (KB) BLOCKS EXTENTS
---------- ------- ---------------- --------- ------- -------
TESIS INDEX CANALDEPAGO_PK 64 8 1
TESIS INDEX JOURNALTX_PK 64 8 1
TESIS INDEX PARTICIONTIPO_PK 64 8 1
TESIS INDEX PARTICION_PK 64 8 1
TESIS INDEX TRANSACCION_PK 64 8 1
TESIS TABLE CANALDEPAGO 64 8 1
TESIS TABLE JOURNALTX 64 8 1
TESIS TABLE JOURNALTX1 10240 1280 25
TESIS TABLE JOURNALTXGIGANTE 98304 12288 83
TESIS TABLE PARTICION 64 8 1
TESIS TABLE PRE_PARTICION 64 8 1
TESIS TABLE TABLA_CANDIDATA 64 8 1
TESIS TABLE TIPO_PARTICION 64 8 1
TESIS TABLE TRANSACCION 64 8 1
************************************************************************
'FIN de la ejecucion del script <<verificacion.sql>>. '
Conexin: TESIS@XE, A las 18/12/2014 15:41:10
Disconnected from Oracle Database 11g Express Edition Release 11.2.0.2.0 - 64bit
Production
5.3 Proceso de optimizacin
En esta seccin se describe los scripts que ejecutan el proceso de optimizacin. El cual
contiene dos partes principales:
Parte1: Las pantallas interactivas y motor de sentencias DDL.

Parte2: La ejecucin de las declaraciones DDL.
Parte1: Las pantallas interactivas y motor de sentencias DDL
Los scripts que ejecutan la primera parte del proceso se encuentran en el folder <<process>>
del directorio principal, este contiene los siguientes scripts:
Modificado: 11/09/2017 04:52 p.m.
55
<<main1.sql>>: Es el script que invoca a los dems en esta primera parte del proceso.
<<1a.sql>>: Visualizacin de las tablas de mayor crecimiento.
<<1b.sql>>: Proceso que genera las sentencias DDL de la tabla.
<<1c.sql>>: Men para escoger la columna PIVOTE y el tipo de particin.
<<1d.sql>>: Proceso que llena la tabla PRE_PARTICION.
<<1e.sql>>: Proceso que actualiza la solicitud de particiones.
<<1f.sql>>: Proceso que genera las sentencias DDL de las particiones.
<<infotabla.sql>>: Script invocado desde el 1a.sql hasta el 1f.sql.
<<main1.sql>>
Es el script principal de la primera parte del proceso, el cual invoca a los dems archivos sql.
A continuacin se muestra un fragmento del script donde se aprecia las llamadas a los
restantes:
@1a
@1b '&&OBJECT_TYPE' '&&TABLE_NAME' '&&USUARIO'
@1c '&&TABLE_NAME'
@1d '&&TABLE_NAME' '&&PIVOT_COLUMN' '&&PARTITION_TYPE'
@1e '&&TABLE_NAME'
@1f '&&TABLE_NAME'
<<1a.sql>>: Visualizacin de las tablas de mayor crecimiento
Para presentar las tablas ms pesadas se elabor un query sobre la vista USER_EXTENTS para
obtener el tamao de las tablas del usuario actual. A continuacin se explica mejor en una
porcin del script donde se encuentra esta consulta:
COLUMN TABLE_NAME HEADING "TABLE|NAME" FORMAT a20

COLUMN MEGABYTES HEADING "TABLE|SIZE|(MEGABYTES)" FORMAT 999999.9999
SELECT
SUBSTR(SEGMENT_NAME,1,20) "TABLE_NAME"
, ROUND(SUM(BYTES)/(1024*1024),4) "TABLE_SIZE_MEGABYTES"
FROM USER_EXTENTS
WHERE SEGMENT_TYPE='TABLE'
GROUP BY SEGMENT_NAME
ORDER BY TABLE_SIZE_MEGABYTES DESC
;
<<1b.sql>>: Proceso que genera las sentencias DDL de la tabla
Este script genera la sentencia DDL de la tabla que se desea ser optimizada.
Modificado: 11/09/2017 04:52 p.m.

56
Se utiliz la librera DBMS_METADATA, la cual proporciona recuperar la informacin del
diccionario de datos en forma de XML o declaraciones DDL con la finalidad de volver a crear
el objeto [ORA11, 1909].
De todas las funciones, se invoc a la funcin GET_DDL para obtener los metadatos de la tabla
con una simple llamada. A continuacin se presenta un extracto del script donde se observa
su uso:
SELECT
DBMS_METADATA.GET_DDL(
UPPER(TRIM('&&OBJECT_TYPE'))
, UPPER(TRIM('&&OBJECT_NAME'))
, UPPER(TRIM('&&OWNER'))
) INTO v_TABLE_DDL
FROM DUAL
;
La funcin recibe argumentos, tales como: el tipo y nombre del objeto, as como el dueo del
mismo.
<<1c.sql>>: Men para escoger la columna PIVOTE y el tipo de particin
En esta parte se busca que el DBA seleccione la columna PIVOTE, la cual ser la clave de
particin de la tabla. Luego se pide la seleccin del tipo de particin. A continuacin se muestra
un fragmento del script:
COLUMN COLUMN_NAME FORMAT a20

COLUMN DATA_TYPE FORMAT a20
SELECT
SUBSTR(COLUMN_NAME,1,20) AS COLUMN_NAME
, SUBSTR(DATA_TYPE,1,20) AS DATA_TYPE
FROM USER_TAB_COLUMNS
WHERE TABLE_NAME=UPPER(TRIM('&&TABLE_NAME'))
ORDER BY COLUMN_NAME
;
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~ Seleccione la columna pivote: ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
ACCEPT PIVOT_COLUMN PROMPT 'Ingresar PIVOT_COLUMN: '
COLUMN PARTITION_TYPE FORMAT a14

SELECT PARTITION_TYPE
FROM TIPO_PARTICION;
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modificado: 11/09/2017 04:52 p.m.

57
PROMPT ~ Seleccione el tipo de particion: ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
ACCEPT PARTITION_TYPE PROMPT 'Ingresar PARTITION_TYPE: '
<<1d.sql>>: Proceso que llena la tabla PRE_PARTICION
El script de esta parte se encuentra en los anexos, en la seccin 1d.sql, sin embargo aqu
se puede mencionar el resultado de su ejecucin:
*** INICIO de la ejecucion del script <<1d.sql>>. ***

========================================================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ Lista de parametros ingresados:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TABLE_NAME (parametro 1): 'JOURNALTXGIGANTE'
PIVOT_COLUMN (parametro 2): 'CANAL'
PARTITION_TYPE (parametro 3): 'LISTA'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~ ~
~ 1.d- Proceso que llena la tabla <<PRE_PARTICION>>. ~
~ ~
~ Este proceso completa la tabla PRE_PARTICION. ~
~ ~
~ Input: ~
~ TABLE_NAME, PIVOT_COLUMN, PARTITION_TYPE ~
~ Output: ~
~ PRE_PARTICION ~
~ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SQL_TXT:
INSERT INTO PRE_PARTICION (TABLE_NAME , PARTITION_TYPE , PARTITION_NAME ,
PIVOT_COLUMN , PIVOT_COLUMN_VALUE , COUNT , TBS_NAME) (SELECT
UPPER('JOURNALTXGIGANTE'), UPPER('LISTA'), CANAL, UPPER('CANAL'), CANAL,
COUNT(1), 'TESIS_TBS' FROM JOURNALTXGIGANTE GROUP BY CANAL )
PL/SQL procedure successfully completed.
~ Verificacion (1.d)
~ ~~~~~~~~~~~~~~~~~~
~
~ Lista de parametros ingresados:
~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~
Modificado: 11/09/2017 04:52 p.m.

58
~ NOMBRE DE TABLA PARTICION: PRE_PARTICION
~
~ PARAMETRO: JOURNALTXGIGANTE
~
~ DETALLE:
~ ~~~~~~~
PIVOT
TABLE PAR PARTIT PIVOT COLUMN PARTIT TBS UPDA CONF
NAME TYP NAME COLUMN VALUE CANTIDAD DDL NAME REQU CREAD REQU
------ --- ------ ------ -------- --------- ------ ------ ---- ----- ----
JOURNA LIS AGENCI CANAL AGENCIA 200000 Null TESIS_ Null Null
JOURNA LIS ASOCIA CANAL ASOCIACI 200000 Null TESIS_ Null Null
JOURNA LIS ATM CANAL ATM 200000 Null TESIS_ Null Null
JOURNA LIS INTERN CANAL INTERNET 200000 Null TESIS_ Null Null
JOURNA LIS KIOSK CANAL KIOSK 200000 Null TESIS_ Null Null
JOURNA LIS POS CANAL POS 200000 Null TESIS_ Null Null
6 rows selected.
========================================================================
*** FIN de la ejecucion del script <<1d.sql>>. ***
<<1e.sql>>: Proceso que actualiza la solicitud de particiones
En esta parte, el proceso espera que el DBA actualice la informacin de las particiones, esta
termina cuando ingresa su confirmacin mediante la letra Y, la cual indica al programa que
la configuracin fue personalizada o est conforme con los valores predispuestos por el motor.
A continuacin, un fragmento del cdigo:
PROMPT
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~ ACTUALIZAR INFORMACION DE LAS PARTICIONES ~
PROMPT ~ Ingrese 'Y' si esta conforme con la informacion. ~
PROMPT ~ En caso contrario actualice la tabla PRE_PARTICION. ~
PROMPT ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT
DEFINE UPDATE_REQUEST='&UPDATE_REQUEST'
PROMPT
UPDATE PRE_PARTICION
SET PARTITION_NAME=UPPER(TRIM(SUBSTR(PARTITION_NAME,1,10)))
, TBS_NAME=UPPER(TRIM(TBS_NAME))
, UPDATE_REQUEST=UPPER(SUBSTR('&&UPDATE_REQUEST',1,1))
, CREATED=SYSDATE
;
<<1f.sql>>: Proceso que genera las sentencias DDL de las particiones
Modificado: 11/09/2017 04:52 p.m.

59
Aqu el motor genera las sentencias DDL de las particiones. De modo que, primero se declara
las variables necesarias; y, por otro lado, un cursor que recorre la tabla PRE_PARTICION para
obtener la informacin recopilada del DBA.
A continuacin se explica mejor en el siguiente cdigo:
DECLARE
v_ERROR_MSG VARCHAR(1000) := '';
v_TBS_NAME TABLA_CANDIDATA.TBS_NAME%TYPE;
v_TABLE_DDL TABLA_CANDIDATA.TABLE_DDL%TYPE;
v_UPDATE_REQUEST PRE_PARTICION.UPDATE_REQUEST%TYPE;
v_PARTITION_DDL PARTICION.PARTITION_DDL%TYPE;
v_TABLE_NAME PARTICION.TABLE_NAME%TYPE := UPPER(TRIM('&TABLE_NAME'));
v_SQL_TXT PARTICION.PARTITION_DDL%TYPE;
CURSOR preparticion_cursor IS
SELECT * FROM PRE_PARTICION
WHERE TABLE_NAME = v_TABLE_NAME
ORDER BY PARTITION_NAME ASC
;
Luego se procede a actualizar la informacin proporcionada por el DBA para todas las
particiones. A continuacin se presenta el fragmento ms significativo del script:
BEGIN

IF (v_UPDATE_REQUEST='Y')
THEN

FOR recprepar in preparticion_cursor
LOOP
SELECT REPLACE (v_TABLE_DDL, v_TBS_NAME, recprepar.TBS_NAME)
INTO v_PARTITION_DDL
FROM DUAL
;
SELECT REPLACE (v_PARTITION_DDL

, v_TABLE_NAME
, recprepar.PARTITION_NAME)
FROM DUAL
;
--Bug encontrado 16-11-2014,

--todas las particiones necesitan tener la misma columna como PK.
SELECT REPLACE (v_PARTITION_DDL
, recprepar.PARTITION_NAME ||'_ID'
, v_TABLE_NAME||'_ID')
FROM DUAL
;
Modificado: 11/09/2017 04:52 p.m.

60
UPDATE PARTICION
SET PARTITION_DDL = v_PARTITION_DDL
WHERE PARTITION_NAME = recprepar.PARTITION_NAME
;
COMMIT
;
END LOOP
;
END IF
;
EXCEPTION

END
;
/
<<infotabla.sql>>: Script invocado desde el 1a.sql hasta el 1f.sql
Este script se invoca dinmicamente en cada etapa y sirve para asegurar la calidad de la
secuencia de las fases durante toda la primera parte del proceso.
La sucesin de cambios se registra en las tablas PRE_PARTICION y PARTICION, por lo tanto

se verifica constantemente para determinar los puntos de fallo y tomar medidas correctivas.
A continuacin se presenta el fragmento ms significativo del script:
PROMPT ~
PROMPT ~ Lista de parametros ingresados:
PROMPT ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROMPT ~
PROMPT ~ NOMBRE DE TABLA PARTICION: &&PARTICION_TABLA
PROMPT ~
PROMPT ~ PARAMETRO: &&TABLE_NAME
PROMPT ~
PROMPT ~ DETALLE:
PROMPT ~ ~~~~~~~
PROMPT ~
@set 'ON'
COLUMN TABLE_NAME HEADING "TABLE|NAME" FORMAT A6
COLUMN PARTITION_TYPE HEADING "PARTITION|TYPE" FORMAT A3
COLUMN PARTITION_NAME HEADING "PARTITION|NAME" FORMAT A6
COLUMN PIVOT_COLUMN HEADING "PIVOT|COLUMN" FORMAT A6
COLUMN PIVOT_COLUMN_VALUE HEADING "PIVOT|COLUMN|VALUE" FORMAT A8
COLUMN COUNT HEADING "CANTIDAD" FORMAT 99999999
COLUMN PARTITION_DDL HEADING "PARTITION|DDL" FORMAT A6
COLUMN TBS_NAME HEADING "TBS|NAME" FORMAT A6
COLUMN UPDATE_REQUEST HEADING "UPDATE|REQUEST" FORMAT A4
COLUMN CREATED HEADING "CREADO" FORMAT A5
Modificado: 11/09/2017 04:52 p.m.

61
COLUMN CONFIRM_REQUEST HEADING "CONFIRM|REQUEST" FORMAT A4
SELECT SUBSTR(TABLE_NAME,1,6) "TABLE_NAME"

, SUBSTR(PARTITION_TYPE,1,3) "PARTITION_TYPE"
, SUBSTR(PARTITION_NAME,1,6) "PARTITION_NAME"
, SUBSTR(PIVOT_COLUMN,1,6) "PIVOT_COLUMN"
, SUBSTR(PIVOT_COLUMN_VALUE,1,8) "PIVOT_COLUMN_VALUE"
, COUNT
, NVL2(PARTITION_DDL,'NoNull', 'Null') "PARTITION_DDL"
, SUBSTR(TBS_NAME,1,6) "TBS_NAME"
, NVL(UPDATE_REQUEST,'Null') "UPDATE_REQUEST"
, TO_CHAR(CREATED,'DD-MM') "CREATED"
, NVL(CONFIRM_REQUEST,'Null') "CONFIRM_REQUEST"
FROM &&PARTICION_TABLA WHERE TABLE_NAME=UPPER(TRIM('&&TABLE_NAME'))
ORDER BY PARTITION_NAME
;
Parte2: La ejecucin de las declaraciones DDL
Los scripts que ejecutan la segunda parte del proceso, tambin se encuentran en el folder
process del directorio principal. Este contiene los siguientes scripts:
<<main2.sql>>: Es el script que invoca a los dems en esta primera parte del proceso.
<<2a.sql>>: Ejecucin de las sentencias DDL de las particiones.
<<2b.sql>>: Creacin de la vista de particiones.
<<2c.sql>>: Migracin de los datos hacia las particiones.
<<2d.sql>>: Creacin del trigger para la vista.
<<main2.sql>>
Es el script principal de la segunda parte del proceso, el cual invoca a los dems archivos sql.
A continuacin se muestra un fragmento del script donde se aprecia las llamadas a los
restantes:
@2a '&&TABLE_NAME'
@2b '&&TABLE_NAME'
@2c '&&TABLE_NAME'
@2d '&&TABLE_NAME'
<<2a.sql>>: Ejecucin de las sentencias DDL de las particiones
Aqu el motor genera las sentencias DDL de las particiones. De modo que, primero se declara
las variables necesarias; y, por otro lado, un cursor que recorre la tabla PARTICION para
obtener declaraciones DDL generados en la primera parte.
Modificado: 11/09/2017 04:52 p.m.

62
DECLARE
v_ERROR_MSG VARCHAR(1000) := ''
;
v_SQL_TXT PARTICION.PARTITION_DDL%TYPE
;
v_CONFIRM_REQUEST PARTICION.CONFIRM_REQUEST%TYPE
;
v_TABLE_NAME PARTICION.TABLE_NAME%TYPE := UPPER(TRIM('&TABLE_NAME'))
;
CURSOR particion_cursor IS
SELECT * FROM PARTICION
;
Luego con la autorizacin del DBA, se procede a ejecutar las sentencias DDL con el comando
EXECUTE IMMEDIATE para cada iteracin del cursor de las particiones. A continuacin se
presenta el fragmento ms significativo del script:
IF (v_CONFIRM_REQUEST='Y')
THEN

FOR rec_particion in particion_cursor
LOOP
v_SQL_TXT:= rec_particion.PARTITION_DDL
;
EXECUTE IMMEDIATE v_SQL_TXT
;

END LOOP
;
END IF
;

Para asegurar la calidad de la secuencia de fases durante el proceso, se consultan las vistas
USER_TABLES y USER_OBJECTS, donde las primeras filas del resultado deben evidenciar las
tablas generadas en la fase previa.
A continuacin se muestra el query que explica mejor el prrafo anterior:
PROMPT
PROMPT ~ Verificacion (2.a):
Modificado: 11/09/2017 04:52 p.m.

63
PROMPT ~ ~~~~~~~~~~~~~~~~~~
@set 'ON'
COLUMN CREATED HEADING "CREADO" FORMAT a10
COLUMN TIME HEADING "HORA" FORMAT a10
COLUMN TABLE_NAME HEADING "TABLA" FORMAT a20
COLUMN TABLESPACE_NAME HEADING "TABLESPACE" FORMAT a20
COLUMN STATUS HEADING "ESTADO" FORMAT a8
SELECT
TO_CHAR(UO.CREATED,'DD-MM-YYYY') as CREATED
, TO_CHAR(UO.CREATED,'HH24:MI:SS') as TIME
, SUBSTR(UT.TABLE_NAME,1,20) as TABLE_NAME
, SUBSTR(UT.TABLESPACE_NAME,1,20) as TABLESPACE_NAME
, UT.STATUS as STATUS
FROM USER_TABLES UT
, USER_OBJECTS UO
WHERE UT.TABLE_NAME = UO.OBJECT_NAME
ORDER BY UO.CREATED DESC
;
<<2b.sql>>: Creacin de la vista de particiones
Este script crea la vista de todas las particiones generadas en la fase anterior. De modo que,
primero se declara las variables necesarias; y, por otro lado, un cursor que recorre la tabla
PARTICION para obtener los nombres de las particiones.
DECLARE
v_SQL_TXT PARTICION.PARTITION_DDL%TYPE;
v_CONFIRM_REQUEST PARTICION.CONFIRM_REQUEST%TYPE;
v_TABLE_NAME PARTICION.TABLE_NAME%TYPE := UPPER(TRIM('&&TABLE_NAME'));
;
TYPE particion_type IS TABLE OF particion_cursor%ROWTYPE

INDEX BY PLS_INTEGER
;
particion_ particion_type
;
Despus se procede a modificar el nombre de la tabla para crear la vista con el mismo nombre
de ella. Luego se recorre el cursor de las particiones para generar la sentencia DDL. Y con
ello, crear la vista de particiones con el comando EXECUTE IMMEDIATE.
Modificado: 11/09/2017 04:52 p.m.
64
DBMS_OUTPUT.PUT_LINE('Renombrando la tabla particionada: ' );

DBMS_OUTPUT.PUT_LINE('=================================')
;
v_SQL_TXT:= 'ALTER TABLE ' || v_TABLE_NAME ||' RENAME TO '
|| v_TABLE_NAME || '_TEMP '
;
;
--
DBMS_OUTPUT.PUT_LINE('Creando la vista de particiones: ' );
DBMS_OUTPUT.PUT_LINE('===============================')
;
OPEN particion_cursor
;
FETCH particion_cursor BULK COLLECT INTO particion_
;
v_SQL_TXT:= 'CREATE VIEW ' || v_TABLE_NAME ||' AS '
;
FOR i IN 1..particion_.COUNT()-1
LOOP
v_SQL_TXT := v_SQL_TXT || ' SELECT * FROM '
|| particion_(i).PARTITION_NAME || ' UNION ALL '
;
END LOOP
;
v_SQL_TXT := v_SQL_TXT || ' SELECT * FROM '
|| particion_(particion_.COUNT()).PARTITION_NAME
;
;
CLOSE particion_cursor
;
Para asegurar la calidad del proceso, se consulta la vista USER_VIEW donde el resultado debe
evidenciar la vista de particiones generada en esta fase.
PROMPT
PROMPT ~ Verificacion (2.b) de la vista recien creada.
PROMPT ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@set 'OFF'
CLEAR COLUMN
SET LONG 90000
COLUMN VIEW_NAME HEADING 'VIEW|NAME' FORMAT a20

COLUMN VIEW_TEXT HEADING 'VIEW|TEXT'
Modificado: 11/09/2017 04:52 p.m.

65
SELECT
SUBSTR(VIEW_NAME,1,20) "VIEW_NAME"
, TEXT "VIEW_TEXT"
FROM USER_VIEWS
ORDER BY 1
;
<<2c.sql>>: Migracin de los datos hacia las particiones
Luego de tener creadas las nuevas particiones, se ejecuta este script para mover los datos de
la tabla hacia sus respectivas particiones, segn el criterio de seleccin de la columna pivote.
De modo que, primero se declara las variables necesarias; y, por otro lado, un cursor que
recorre la tabla PARTICION para obtener los nombres de las particiones, la columna pivote as
como su valor. A continuacin se explica mejor en el siguiente cdigo:
DECLARE
v_SQL_TXT VARCHAR(1000) := '';
SELECT * FROM PARTICION WHERE TABLE_NAME = v_TABLE_NAME
;
Luego por cada iteracin del cursor se genera la sentencia DDL y; con el comando EXECUTE
IMMEDIATE se mueven los datos a su respectiva particin y se crea los constraints para cada
una de ellas.
FOR rec IN particion_cursor

LOOP
DBMS_OUTPUT.PUT_LINE('Copiando los datos para la particion: '
|| rec.PARTITION_NAME)
;
DBMS_OUTPUT.PUT_LINE('===========================================')
;
v_SQL_TXT:= 'INSERT INTO ' || rec.PARTITION_NAME
;
v_SQL_TXT:= v_SQL_TXT || ' (SELECT * '
;
v_SQL_TXT:= v_SQL_TXT || ' FROM ' || rec.TABLE_NAME || '_TEMP'
Modificado: 11/09/2017 04:52 p.m.

66
;
v_SQL_TXT:= v_SQL_TXT || ' WHERE ' || rec.PIVOT_COLUMN
|| q'[ = ']'||rec.PIVOT_COLUMN_VALUE||q'[' ]'
;
v_SQL_TXT:= v_SQL_TXT || ' ) '
;
;
DBMS_OUTPUT.PUT_LINE('Creando constraint para la particion: '
|| rec.PARTITION_NAME)
;
DBMS_OUTPUT.PUT_LINE('===========================================')
;
v_SQL_TXT:= 'ALTER TABLE ' || rec.PARTITION_NAME|| ' ADD CONSTRAINT '
;
v_SQL_TXT:= v_SQL_TXT ||rec.PARTITION_NAME||'_'||rec.PIVOT_COLUMN
||'_CK CHECK ('
;
v_SQL_TXT:= v_SQL_TXT ||rec.PIVOT_COLUMN
|| q'[=']'
||rec.PIVOT_COLUMN_VALUE
||q'[') ]'
;
;
END LOOP
;
Para asegurar la calidad del proceso, se consulta la vista USER_CONS_COLUMNS donde el

resultado debe evidenciar los constraints generada en esta fase.
PROMPT
PROMPT ~ Verificacion (2.c) de los constraints recien creados:
PROMPT ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CLEAR COLUMN
@set 'ON'
COLUMN OWNER HEADING "Propietario" FORMAT A6

COLUMN CONSTRAINT_NAME HEADING "Contraint" FORMAT A20
COLUMN TABLE_NAME HEADING "Tabla" FORMAT A20
SELECT OWNER
, CONSTRAINT_NAME
, TABLE_NAME
FROM USER_CONS_COLUMNS
WHERE TABLE_NAME IN ( SELECT PARTITION_NAME FROM PARTICION WHERE TABLE_NAME=
UPPER(TRIM('&&TABLE_NAME')) )
AND CONSTRAINT_NAME LIKE '%_CK'
;
Modificado: 11/09/2017 04:52 p.m.

67
<<2d.sql>>: Creacin del trigger para la vista
Aqu se crea el trigger de forma dinmica para la vista creada en la fase anterior. Similar a los
anteriores fases, se declara la variables necesarios. A continuacin se explica mejor en el
siguiente cdigo:
DECLARE
v_SQL_TXT VARCHAR(4000) := '';
v_PIVOT_COLUMN PARTICION.PIVOT_COLUMN%TYPE;
;
CURSOR columna_cursor IS
SELECT COLUMN_NAME FROM USER_TAB_COLUMNS
ORDER BY COLUMN_ID
;
TYPE columna_type IS TABLE OF columna_cursor%ROWTYPE

INDEX BY PLS_INTEGER
;
columna_ columna_type
;
Luego se genera la sentencia DDL as como su ejecucin con el comando EXECUTE

IMMEDIATE. A continuacin se presenta el fragmento ms significativo del script:
v_SQL_TXT:= 'CREATE OR REPLACE TRIGGER INSERT_ON_'

|| SUBSTR(v_TABLE_NAME,1,15)
||'_TG INSTEAD OF INSERT ON '|| v_TABLE_NAME
;

;
v_SQL_TXT:= v_SQL_TXT ||' BEGIN '
;
v_SQL_TXT:= v_SQL_TXT ||' v_PIVOT_COLUMN_VALUE:= :new.'
||v_PIVOT_COLUMN||' ; '
;
v_SQL_TXT:= v_SQL_TXT ||' CASE v_PIVOT_COLUMN_VALUE '
;
OPEN columna_cursor
;
Modificado: 11/09/2017 04:52 p.m.

68
FETCH columna_cursor BULK COLLECT INTO columna_
;
FOR rec IN particion_cursor
LOOP
v_SQL_TXT:= v_SQL_TXT
||q'[ WHEN ']'||rec.PARTITION_NAME||q'[' THEN ]'
;
v_SQL_TXT:= v_SQL_TXT ||' INSERT INTO ' || rec.PARTITION_NAME
;
v_SQL_TXT:= v_SQL_TXT || ' ( ' || columna_(1).COLUMN_NAME
;
FOR i IN 2..columna_.COUNT()
LOOP
v_SQL_TXT:= v_SQL_TXT || ', '||columna_(i).COLUMN_NAME
;
END LOOP
;
v_SQL_TXT:= v_SQL_TXT || ' ) VALUES( :new.'
|| columna_(1).COLUMN_NAME
;
FOR i IN 2..columna_.COUNT()
LOOP
v_SQL_TXT:= v_SQL_TXT || ', :new.'||columna_(i).COLUMN_NAME
;
END LOOP
;
v_SQL_TXT:= v_SQL_TXT || ' )'
;
v_SQL_TXT:= v_SQL_TXT || '; '
;
END LOOP
;
CLOSE columna_cursor
;
v_SQL_TXT:= v_SQL_TXT || ' END CASE ; '
;
v_SQL_TXT:= v_SQL_TXT || ' EXCEPTION '
;

;
Para asegurar la calidad del proceso, se consulta la vista USER_TRIGGERS donde el resultado
debe evidenciar los triggers generada en esta fase.
PROMPT
PROMPT ~ Verificacion (2.d) del <<trigger>> recien creado.
PROMPT ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Modificado: 11/09/2017 04:52 p.m.

69
@set 'OFF'
CLEAR COLUMN
set LONG 90000
COLUMN TRIGGER_NAME HEADING 'TRIGGER|NAME' FORMAT A15

COLUMN TRIGGER_TYPE HEADING 'TRIGGER|TYPE' FORMAT A10
COLUMN TRIGGERING_EVENT HEADING 'TRIGGER|EVENT' FORMAT A15
COLUMN TRIGGER_BODY HEADING 'TRIGGER|BODY'
SELECT
SUBSTR(TRIGGER_NAME,1,15) "TRIGGER_NAME"
, SUBSTR(TRIGGER_TYPE,1,10) "TRIGGER_TYPE"
, SUBSTR(TRIGGERING_EVENT,1,15) "TRIGGERING_EVENT"
, TRIGGER_BODY
FROM USER_TRIGGERS
;
Modificado: 11/09/2017 04:52 p.m.

70
6
CAPTULO 6: PRUEBAS DE RENDIMIENTO

Preliminares.
Primera prueba: Comparacin de los planes.
Segunda prueba: Comparacin de los tiempos.
6.1 Preliminares
Para favorecer la comprensin de cmo se realizaron las pruebas para medir la herramienta
de optimizacin, es necesario conocer lo siguiente:
Caso de prueba.
Momentos de las pruebas.
Pruebas de rendimientos.
Recopilacin de estadsticas para las pruebas.
Encontrando el costo de un query.
Caso de prueba
Modificado: 11/09/2017 04:52 p.m.

71
Consisti en consultar la tabla JOURNALTXGIGANTE, por tanto, esta fue el input del proceso de
optimizacin.
Fases de las pruebas
Son los instantes en los cuales se realizaron los ensayos. Y fueron dos:
Fase inicial: Antes de que la tabla ingrese al proceso de optimizacin.

Fase final: Despus de finalizar el proceso de optimizacin.
Pruebas de rendimiento
Se realizaron dos estudios que demostraron la mejora en los tiempos de respuestas en el

caso de prueba:
Comparacin de los planes de ejecucin en los diferentes momentos de las pruebas.

Comparacin de las estadsticas de medicin de tiempo sobre un bloque PL/SQL en
los momentos mencionados.
Encontrando el costo de un query
Las consultas (queries) o cualquier sentencia DML realizada consume recursos tales como:
espacio en disco, tiempo de CPU, capacidades en las operaciones de I/O, etc., por eso los
diseadores de las aplicaciones deben asegurarse de no abusar de ellos.
En efecto, una forma de controlar es medir los costos relativos que generan los queries; y para
ello, se us la herramienta que el motor de la BD (Oracle optimizer) proporciona.
6.2 Recopilacin de estadsticas para las pruebas
El optimizador de Oracle (Oracle optimizer) utiliza las estadsticas recogidas en las tablas e
ndices para llegar a un plan de ejecucin ptimo para que consuma menos nmero de
recursos al completar una cierta tarea.
Para ambas pruebas, el motor de BD no recogi las estadsticas de forma automtica,

entonces se actualizaron las estadsticas, utilizando las clusulas compute statistics, para
recopilar de manera manual y, as, garantizar que ellas representen con precisin las
caractersticas de los objetos de BD.
Modificado: 11/09/2017 04:52 p.m.

72
En la fase inicial
Aqu se actualizaron las estadsticas de la tabla JOURNALTXGIGANTE. A continuacin se

presenta el comando empleado:
REM Actualizando las estadisticas
ANALYZE TABLE JOURNALTXGIGANTE COMPUTE STATISTICS

;
En la fase final
Aqu se actualizaron las estadsticas de las nuevas particiones recin creadas. A continuacin
se presentan los comandos ejecutados:
REM Actualizando las estadisticas
ANALYZE TABLE TARJERTA COMPUTE STATISTICS

;
ANALYZE TABLE POS COMPUTE STATISTICS
;
ANALYZE TABLE AGENCIA COMPUTE STATISTICS
;
ANALYZE TABLE ATM COMPUTE STATISTICS
;
ANALYZE TABLE INTERNETBA COMPUTE STATISTICS
;
ANALYZE TABLE KIOSK COMPUTE STATISTICS
;
6.3 Primera prueba: Comparacin de los planes
Antes de abordar con la explicacin de este ensayo, es necesario repasar qu significa plan
de ejecucin (execution plan) y el uso de la clusula EXPLAIN PLAN en las sentencias SQL
(revise la seccin 2.1 para ahondar en este asunto).
Se examin el rendimiento en dos tipos de planes de ejecucin:
Plan usando la funcin DBMS_XPLAN.DISPLAY.

Plan usando la funcin DBMS_XPLAN.DISPLAY_CURSOR.
Plan usando la funcin DBMS_XPLAN.DISPLAY
Modificado: 11/09/2017 04:52 p.m.

73
Por ejemplo, para obtener el plan del query en los diferentes momentos de las pruebas, se
us la clusula EXPLAIN PLAN FOR. A continuacin se muestra su empleo:
COLUMN NROCUENTA FORMAT A20

SET LINESIZE 160
EXPLAIN PLAN FOR

SELECT * FROM JOURNALTXGIGANTE WHERE CANAL='ATM'
;
Explained.
La explicacin del plan de ejecucin se encuentra en la tabla PLAN_TABLE. Entonces, se utiliz

la funcin DISPLAY del paquete DBMS_XPLAN para mostrar el plan [ORA11, 4567].
A continuacin, un ejemplo de cmo presentar el resultado del ltimo comando EXPLAIN PLAN
almacenado en la tabla PLAN_TABLE:
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY)

;
Plan usando la funcin DBMS_XPLAN.DISPLAY_CURSOR
Para validar el filtro del query se utiliz otro plan que emplea estadsticas rowsource. Y, para
ello, se realizaron los siguientes procedimientos:
Apagado del control que muestras las salidas (DBMS_OUTPUT.PUT_LINE) de los bloques
PL/SQL en el SQL*PLUS. A continuacin, un ejemplo:
SET SERVEROUTPUT OFF
Luego se us la clusula /*+ gather_plan_statistics */ en la sentencia SQL. A

continuacin se presenta su uso:
SELECT /*+ gather_plan_statistics */ * FROM JOURNALTXGIGANTE WHERE CANAL='ATM';
Y, por ltimo, para mostrar el contenido del plan, se utiliz la funcin DISPLAY_CURSOR del
paquete DBMS_XPLAN, segn el cual se permite formatear y mostrar el contenido del plan de
ejecucin de cualquier cursor cargado recientemente [ORA11, 4567]. A continuacin, un
ejemplo de cmo invocarlo:
Modificado: 11/09/2017 04:52 p.m.
74
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(null, null, 'ALLSTATS LAST') )
;
Este plan presentar informacin complementaria al anterior (DBMS_XPLAN.DISPLAY), por

ejemplo, la columna Starts, la cual indica que el optimizador evala las filas que tienen la
columna con un valor mayor que cero (0). En los siguientes apartados se muestra su utilidad.
Planes de ejecucin en la fase inicial
Aqu se examinan los planes de ejecucin escogidos por el optimizador en el momento inicial.
En la figura 6-1, se observa que el costo (ms detalle, se explica en la nota Encontrando el
costo de un query de los preliminares de este captulo) empleado fue de 3232. Este dato ser
comparado con el obtenido en el otro momento.
Figura 6-1: Plan de ejecucin antes del proceso (DBMS_XPLAN.DISPLAY).
En la figura 6-2, se muestra otro plan con ms informacin, entre ellos, se aprecia la columna
Starts, donde todos los valores son iguales a uno, lo cual indica que el optimizador evalu
esas filas.
Planes de ejecucin en la fase final
Aqu se examinan los planes de ejecucin escogidos por el optimizador en el momento final.
En la figura 6-3, se aprecia que el costo empleado fue dos (2). Adems, da la impresin que
recorre todas las particiones en lugar de solo buscar la solicitada, como se indica en el
predicado (CANAL=ATM).
Modificado: 11/09/2017 04:52 p.m.

75
Figura 6-2: Plan de ejecucin antes del proceso (DBMS_XPLAN.DISPLAY_CURSOR).
Figura 6-3: Plan de ejecucin despus del proceso (DBMS_XPLAN.DISPLAY).
Modificado: 11/09/2017 04:52 p.m.

76
Esa duda se clarifica con el siguiente plan presentado en la figura 6-4. Ah se observa que los
pasos 4, 7, 9, 11 y 13 tienen el valor cero (0) en la columna Starts, lo cual significa que el
optimizador conoce que los pasos 3, 6, 8, 10 y 12; no necesitan ms evaluacin.
La parte ms importante del plan es la informacin del predicado, segn el cual los filtros NULL
IS NOT NULL siempre se evalan como falso. Por consiguiente, el optimizador no evala esos
pasos.
Figura 6-4: Plan de ejecucin despus del proceso (DBMS_XPLAN.DISPLAY_CURSOR).
Conclusin de la primera prueba
El costo empleado en el primer plan fue 3232 y en el segundo fue 2. Por tanto, se aprecia una
mejora en el rendimiento.
Adems, se explic que el optimizador no evala todas las particiones como aparenta en los
planes obtenidos con la funcin DBMS_XPLAN.DISPLAY. Por eso se presentaron los planes con
la otra funcin DBMS_XPLAN.DISPLAY_CURSOR.
Modificado: 11/09/2017 04:52 p.m.

77
Por tanto, con las evidencias presentadas, se concluye que el optimizador no evala todas las
particiones y la mejora en el rendimiento es notoria al comparar todos los planes antes del
proceso y despus de ello.
6.4 Segunda prueba: Comparacin de los tiempos
Este ensayo consiste en comparar los estadsticos de medicin de tiempo sobre un bloque
PL/SQL en los diferentes momentos de las pruebas. Para controlar la visualizacin de las
estadsticas de tiempo (timing) se utiliz la siguiente declaracin:
SET TIMING ON
El bloque PL/SQL que se ejecut fue el siguiente:
DECLARE
total number
;
i number
;
BEGIN
i:=1
;
LOOP
SELECT COUNT(*) INTO total
FROM JOURNALTXGIGANTE WHERE CANAL='ATM'
;
i:=i+1
;
EXIT WHEN i=700
;
END LOOP
;
END
;
/
Estadsticos de medicin de tiempo en la fase inicial
En la figura 6-5 se muestra el periodo transcurrido en la ejecucin del bloque PL/SQL, lo cual
fue 35.49 segundos.
Modificado: 11/09/2017 04:52 p.m.

78
Figura 6-5: Periodo transcurrido en la ejecucin del bloque PL/SQL en el momento inicial.
Estadsticos de medicin de tiempo en la fase final
En la figura 6-6 se muestra el periodo transcurrido en la ejecucin del bloque PL/SQL, lo cual
fue 9.51 segundos.
Modificado: 11/09/2017 04:52 p.m.

79
Figura 6-6: Periodo transcurrido en la ejecucin del bloque PL/SQL en el momento final.
Conclusin de la segunda prueba
El tiempo transcurrido en el momento inicial fue 35.49 segundos y en el final, 9.51.

Comparando ambos periodos se calcula, (1 9.51/35.49) x 100%, que hay una ganancia
de 73.2%.
Por tanto, con las evidencias presentadas se concluye que esta herramienta mejora los
tiempos de respuestas de las consultas en las tablas que fueron ingresadas al proceso de
optimizacin.
Modificado: 11/09/2017 04:52 p.m.

80
7
RESTRICCIONES, CONCLUSIONES Y
RECOMENDACIONES
A continuacin se presentan las restricciones, conclusiones, recomendaciones finales:
Restricciones
Esta versin no considera a las tablas que tienen columnas de tipo de datos tales como: LONG,
LONG RAW y LOBS. Aquellos sern tratados en una futura versin.
Con respecto a la integridad referencial entre tablas, esta versin no funciona para aquellas
(tablas hijas) que depende de otra tabla, asimismo para las que son padres. Estas debilidades
sern desarrolladas en la siguiente versin.
Y por ltimo, con respecto a la cantidad de columnas y el nmero de particiones de la tabla,

esta versin est limitada por una longitud mxima de 4000 caracteres en la definicin de la
vista de particiones o en el trigger. En la siguiente versin se mejora esta caracterstica.
Modificado: 11/09/2017 04:52 p.m.

81
Conclusiones
Esta herramienta es til para superar los problemas relacionados con BD cuando las
aplicaciones muchas veces se quedan colgadas en produccin. Resumiendo toda la
Problemtica de la seccin 1.1, la causa muchas veces se debe que la BD debe soportar
procesos con picos de rendimiento altos.
Con esta herramienta se reducir el TCO (costo total del producto); y no requerir invertir en
aumentar el hardware, porque muchas veces es el camino ms fcil para las empresas, sin
embargo, con ello no se ataca el problema principal, como s lo hace esta solucin.
Asimismo, se logra que el proceso de particin de tablas sea transparente para el usuario final
o la aplicacin. De este modo, se elimina la necesidad de efectuar otras operaciones o
cambios en la aplicacin.
La herramienta tiene un motor inteligente, generador de cdigo, que produce sentencias DDL
de forma automtica logrando reducir las horas hombre. Naturalmente, se obtiene ms
utilidades para la corporacin.
Con respecto a las licencias sofisticadas de compaas de software, por ejemplo, comparando
con Oracle Database Enterprise Edition, se genera un ahorro significativo porque la solucin
es independiente de la edicin del producto Oracle.
Con respecto al objetivo principal de esta investigacin, mejora de los tiempos de respuestas
cuando las tablas gigantes son consultadas, se comprob un progreso muy significativo.
Resumiendo todo el captulo 6, Pruebas de rendimiento, se puede decir que con esta
herramienta se logr una ganancia por encima del 70%.
Leccin aprendida
Inicialmente se estuvo declarando algunas variables para unas tablas en particular sin utilizar
el atributo %TYPE entonces el bloque de cdigo PL/SQL generaba errores por cada declaracin
de variable alterada.
Luego se us este atributo, de modo que, el motor PL/SQL determinaba el tipo de dato y el
tamao de la variable cuando se compila el bloque, esto asegura que una variable de este
tipo de atributo es siempre compatible con la columna de la tabla que se est usando.
Recomendaciones y trabajo futuro
Modificado: 11/09/2017 04:52 p.m.

82
Se analiz la posibilidad de tener otra BD, para migrar las tablas con problemas. La nueva BD
puede ser de varios modos: relacional, no relacional, orientada a objetos y archivos planos.
Cuando se investigaba, se encontr una variedad de productos de estos tipos. Adems, se
determin no desviar la investigacin principal encontrar una solucin y cumplir con todos
los requerimientos en el poco tiempo asignado. Sin embargo, se puede retomar esta
propuesta para una futura investigacin. Adems se consider la realidad del CE; el gerente
de TI quiere optar por la mayora de los motores de BD ms conocidos, y estos son de tipo
relacional. Ms an, el lenguaje SQL que se usa para las operaciones con los datos es un
lenguaje muy familiar para ellos.
Las operaciones de lectura y escritura en los discos fsicos son consideradas estratgicas y
deberan acompaar en el planeamiento de esta solucin. Son estratgicas porque eliminando
el potencial problema que tienen stos, ser tambin una decisin clave para lograr una
optimizacin completa en la BD. De modo que, este punto se encuentra en otro nivel, en la
capa del sistema operativo o en el hardware de los discos. Por lo tanto, en el despliegue de
esta solucin se deber tratar con el especialista de los sistemas de almacenamiento de la
empresa.
Con respecto a las operaciones DML en la vista de particiones, los comandos tales como,
delete y update, debern ser implementadas en una futura versin, porque son instrucciones
que cualquier sistema utiliza. Y, con ello, se lograr completa transparencia para cualquier
aplicacin.
De igual modo, con respecto al desplazamiento de los datos hacia las particiones, la propuesta
de mejorar ese mecanismo deber ser analizada e implementada, el uso de la tecnologa
DATA PUMP puede optimizar la herramienta al tratar tablas muy pesadas.
Por ltimo, con respecto al interfaz de usuario, se propone continuar con el desarrollo de las
pantallas interactivas en formato HTML.
Modificado: 11/09/2017 04:52 p.m.

83
REFERENCIAS BIBLIOGRFICAS
[PEI] Curso de Planificacin Estratgica en Informtica PUCP por Luis E. Ros
Alejos. Marzo 2013.
[ORA01] Oracle Database VLDB and Partitioning Guide 11g Release 2

(11.2).E25523-01. Septiembre 2011.
[ORA02] Oracle Database 11g: SQL Fundamentals I. Volumen I Student Guide.

D49996GC20. Edition 2.0. Octubre 2009.
[ORA03] Oracle Database 11g: PL/SQL Fundamental. Student Guide. D49990GC11.

Edition 1.1. Abril 2009.
[ORA04] Oracle Database 11g: Administration Workshop I. Volumen I. Student

Guide. D50102GC20. Edition 2.0. Agosto 2010.
[ORA05] Oracle Database 11g: SQL Fundamentals I. Volumen II Student Guide.

D49996GC20. Edition 2.0. Octubre 2009.
[ORA06] Oracle Database Concepts 11g Release 2 (11.2). E40540-02. Mayo 2014.
[ORA07] ORACLE PARTITIONING. Oracle Data Sheet. 11g Release 2 (11.2).
[ORA08] Oracle Database Performance Tuning Guide 11g Release 2 (11.2).

E41573-04. Junio 2014.
[ORA09] Oracle Database 2 Day Developer's Guide 11g Release 2 (11.2). E10766-
08. Enero 2014.
[ORA10] Oracle Database PL/SQL Language Reference 11g Release 2 (11.2).

E25519-12. Enero 2014.
[ORA11] Oracle Database PL/SQL Packages and Types Reference 11g Release 2
(11.2). E40758-03. July 2013.
Modificado: 11/09/2017 04:52 p.m.

84
[PLSQL01] Oracle Database 11g. PL/SQL Programming. Develop Robust. Database-
Driven PL/SQL Applications. Michael McLaughlin. Oracle Press.
Enlaces en Internet
[WEB01] http://docs.oracle.com/cd/E11882_01/server.112/e40540/srvrside.htm#CNCPT318
[WEB02] http://www.informatica.com/us/products/application-ilm/data-subset/#fbid=KjwgbrtIVkM
[WEB03] http://www.informatica.com/us/data-archiving-magic-
quadrant/?ref=wwwbnrprdpg%20-%20fbid=KjwgbrtIVkM#fbid=KjwgbrtIVkM
[WEB04] http://www.gartner.com/technology/reprints.do?id=1-
1VDEQUO&ct=140611&st=sb&mkt_tok=3RkMMJWWfF9wsRonua3BcO%252FhmjTE
U5z17%252BsuXqGygIkz2EFye%252BLIHETpodcMS8NjNa%252BTFAwTG5toziV8R
7HNJc160s8QXBjm
[WEB05] http://www.oracle.com/technetwork/es/articles/database-performance/oracle-
partitioning-en-database-12c-2244565-esa.html
[WEB06] http://www.ansi.org/
Tomar en consideracin que todos los enlaces en Internet pueden cambiar en cualquier
momento despus de la fecha de publicacin de este informe (Diciembre 2014).
Modificado: 11/09/2017 04:52 p.m.

85
ANEXOS
Anexo A: Abreviaturas y definiciones
A continuacin se presentan las abreviaturas con sus definiciones respectivas utilizadas en

este informe:
TRMINO DEFINICIN
ATM Automated Teller Machines, que significa mquinas de cajero automtico.
BD Base de datos.
CE Caso de estudio del proyecto.
DBA Administrador de BD.
POS Point of Sale terminal, que significa terminal de punto de venta.
Query En BD significa consulta, quiere decir que un query en un BD realiza una

bsqueda de datos de una o varias tablas.
RE Resultado esperado.
SO Sistema operativo.
SQL Structured Query Language, SQL es un lenguaje estndar ANSI para

operaciones relacionales en BD.
TCO Total cost of ownership, TCO es el costo total de un producto o de un sistema

informacin.
TI Tecnologa de la informacin.
Modificado: 11/09/2017 04:52 p.m.

86
Anexo B: Magic Quadrant for Structured Data Archiving and
Application Retirement
El informe completo fue recogido del Internet y su explicacin se encuentra en el siguiente

enlace:
http://www.gartner.com/technology/reprints.do?id=1-
1VDEQUO&ct=140611&st=sb&mkt_tok=3RkMMJWWfF9wsRonua3BcO%252FhmjTEU5z17%252Bsu
XqGygIkz2EFye%252BLIHETpodcMS8NjNa%252BTFAwTG5toziV8R7HNJc160s8QXBjm
Modificado: 11/09/2017 04:52 p.m.

87

Proyecto de Tesis Técnica Optimización BD Jose Alegre (Dic. 2014)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto de Tesis Técnica Optimización BD Jose Alegre (Dic. 2014)

Cargado por

Copyright:

Formatos disponibles

PONTIFICIA UNIVERSIDAD CATLICA DEL PER

FACULTAD DE CIENCIAS E INGENIERA

DEFINIR E IMPLEMENTAR UNA TCNICA PARA MEJORAR LOS

Tesis para optar por el Ttulo de Ingeniero Informtico

Jos Alegre Argomedo

Asesor: Ing. Javier Cullas

Lima, junio del 2017

Modificado: 11/09/2017 04:52 p.m.

Modificado: 11/09/2017 04:52 p.m.

CAPTULO UNO: GENERALIDADES ................................................................................................. 2

1.2 OBJETIVOS Y RESULTADOS ESPERADOS DEL PROYECTO ....................................................................... 7

1.3 HERRAMIENTAS, PROCEDIMIENTOS Y METODOLOGAS ....................................................................... 9

1.4 ALCANCE, LIMITACIONES Y RIESGOS............................................................................................. 13

1.5 JUSTIFICATIVA Y VIABILIDAD ...................................................................................................... 15

CAPTULO DOS: MARCO CONCEPTUAL ........................................................................................ 19

2.1 MARCO TERICO .................................................................................................................... 19

2.2 ESTADO DEL ARTE ................................................................................................................... 25

CAPTULO TRES: ANLISIS ........................................................................................................... 28

3.1 PRELIMINARES ....................................................................................................................... 28

3.2 VISTA PANORMICA DE LA SOLUCIN .......................................................................................... 29

CAPTULO CUATRO: DISEO........................................................................................................ 33

4.1 PRELIMINARES ....................................................................................................................... 33

4.2 RESUMEN DE ALTO NIVEL DEL PROCESO DE OPTIMIZACIN ................................................................ 36

4.3 DIAGRAMA DEL FLUJO DEL PROCESO DE OPTIMIZACIN .................................................................... 36

Modificado: 11/09/2017 04:52 p.m.

4.7 RENDIMIENTO DE LAS CONSULTAS A LA TABLA ............................................................................... 45

CAPTULO 5: CONSTRUCCIN ...................................................................................................... 46

5.1 PRELIMINARES ....................................................................................................................... 46

5.2 INSTALACIN DEL PRODUCTO .................................................................................................... 50

5.3 PROCESO DE OPTIMIZACIN ...................................................................................................... 55

CAPTULO 6: PRUEBAS DE RENDIMIENTO .................................................................................... 71

6.1 PRELIMINARES ....................................................................................................................... 71

6.2 RECOPILACIN DE ESTADSTICAS PARA LAS PRUEBAS........................................................................ 72

6.3 PRIMERA PRUEBA: COMPARACIN DE LOS PLANES .......................................................................... 73

6.4 SEGUNDA PRUEBA: COMPARACIN DE LOS TIEMPOS ....................................................................... 78

Modificado: 11/09/2017 04:52 p.m.

ENLACES EN INTERNET ............................................................................................................................ 85

ANEXO A: ABREVIATURAS Y DEFINICIONES ............................................................................................ 86

Modificado: 11/09/2017 04:52 p.m.

Tabla 1-1: Registros de los riesgos del proyecto. ................................................................. 15

Modificado: 11/09/2017 04:52 p.m.

Figura 1-1: Mdulo de la aplicacin que tiene problemas en el rendimiento. ......................... 5

Modificado: 11/09/2017 04:52 p.m.

El problema de la falta de identificacin de oportunidades de negocio puede provocar prdidas

La particin de tablas brinda un enfoque simple, efectivo y til para la administracin de TI de

CAPTULO UNO: GENERALIDADES

En esta seccin se describe el contexto en donde se desarroll el problema y se identifica el

A continuacin se describen diversas situaciones recogidas que servirn para contextualizar

Modificado: 11/09/2017 04:52 p.m.

Modernas empresas frecuentemente corren bases de datos de misin-critica que contienen

<<Esas empresas se ven en la necesidad de comprar servidores ms potentes para mantener

Asimismo, <<ellas requieren adicionar otros dispositivos a su sistema de almacenamiento,

Casos relacionados con el rendimiento en una base de datos

Modificado: 11/09/2017 04:52 p.m.

Definicin del problema

De los hallazgos encontrados se identifica que el problema fundamental es el bajo rendimiento

Situacin actual del caso de estudio

Modificado: 11/09/2017 04:52 p.m.

Figura 1-1: Mdulo de la aplicacin que tiene problemas en el rendimiento.

El modulo es el motor de procesamiento centralizado de la gran parte de las transacciones, lo

Figura 1-2: Tabla JOURNALTX.

Modificado: 11/09/2017 04:52 p.m.

Consecuencias de continuar con la situacin actual