Storage Estructuras de almacenamiento

Storage Estructuras de almacenamiento

Esquemas : Un esquema es una coleccin de objetos de base de datos
que son propiedad de un determinado usuario. Son estructuras
directamente referenciadas a la data de una base de datos (tablas,
ndices, vistas, secuencias, procedimientos, packages, etc.).
Tablespaces: Unidades de almacenamiento diseadas para agrupar
estructuras lgicas relacionadas (semnticamente vinculadas).
Data Blocks: La unidad de almacenamiento mas pequea, un data block
corresponde a un nmero especifico de bytes del espacio fsico en disco
de la base de datos, su tamao es especificado cuando se crea el
tablespace.
Extents: Es el siguiente nivel de almacenamiento lgico, es un numero
especifico de bloques contiguos que son utilizados para almacenar u
tipo especifico de informacin.

Storage Estructuras de almacenamiento lgico

Segmentos: conjunto de extends que estn alocados para una
estructura lgica en particular, diferentes tipos de segmentos
incluyen:

Segmentos de Datos: Almacenan toda la data para las tablas no

particionadas, para las particiones de una tabla, o clster de
tablas. Son creados cuando se ejecuta la sentencia CREATE.
Segmentos de ndice: Almacenan la data de los indices.
Segmentos Undo: Un undo tablespace es creado para cada
instancia, estos tablespaces contienen segmentos de undo para
almacenar temporalmente la informacin para ejecutar
operaciones tales como database recovery, rollback, etc.

Segmentos temporales: Creados cuando la base de datos

necesita espacio extra para completar una operacin, cuando la
operacin finaliza, los segmentos temporales son devueltos a la
instancia para usos futuros.

Storage - Estructuras de almacenamiento

Nota: 2 KB es el tamao minimo de un data block

que oracle puede manejar en el disco duro, sin
embargo no es comun ver esta configuracion,
normalmente se usa la configuracin por defecto
de 8 KB

Storage SYSTEM and SYSAUX Tablespaces

Ambos son tablespaces mandatorios y son creados al mismo tiempo que es creada la base de datos, la
recomendacin es que siempre estn disponibles.
SYSTEM tablespace es usada para funcionalidades core de la base de datos, por ejemplo: Tablas de
diccionario de datos. Debe estar siempre disponible cuando la base de datos esta abierta.
SYSAUX es un tablespace auxiliar y es utilizado para componentes adicionales (Ej. Enterprise Manager
Repository).
Importante: SYSAUX puede dejarse fuera de lnea mientras se estn ejecutando tareas de recuperacin
de tablespace, por otro lado SYSTEM siempre debe estar online ninguno de ellos puede ser read-only
tablespace.

Rendimiento ineficiente SQL - Causas

Estadsticas del optimizador vacas o incorrectas: Para que el plan de
ejecucin mas optimo pueda seleccionarse, es necesario tener
estadsticas precisas de la data (volumen y distribucin).
Falta de estructuras de acceso a datos : Tales como ndices, vistas
materializadas, particiones. La ausencia o existencia de estas estructuras
puede marcar un punto de inflexin radical en el rendimiento.

Seleccin de un mal plan de ejecucin: El optimizador CBO (Costbased optimizer) puede seleccionar un mal plan de ejecucin
principalmente a causa de mala estimacin de costo, cardinalidad y
selectividad de la consulta.
Pobre construccin de SQL: Aunque se tengan las mejores estadsticas y
las mejores estructuras de acceso a datos, si un SQL esta terriblemente
construido, no hay mucho que el CBO pueda hacer.

Rendimiento ineficiente SQL Por donde empiezo

a buscar?
Verificar las estadsticas
Estn los ndices siendo usados
correctamente?
Exists vs In
Verificar condiciones de desigualdad
Ayudar un poco al parser.

Si algo huele mal, puede que este mal.

Verificar las estadsticas

Estn los ndices siendo usados
correctamente?
Exists vs In
Verificar condiciones de desigualdad
Ayudar un poco al parser.
Si algo huele mal, puede que este mal.

RENDIMIENTO INEFICIENTE SQL

REVISANDO NDICES
Que exista un ndice no garantiza que sea usado. Estos factores conllevan al no
uso de ndices:
El optimizador podra decidir no utilizar ndices en base a la selectividad de los
elementos de la tabla.
Ejecutar una funcin sobre la columna indexada: Ejemplo - WHERE UPPER(name) =
'ROBERT'. La solucin para esto es crear function based indexes.
Ejecutar operaciones matemticas sobre la columna indexada : Ejemplo - WHERE
HORSE_POWER/2 = 110;

Concatenacin de columnas : Ejemplo - WHERE firstname || ' ' || lastname = 'CARL

JOHNSON '
El uso de sentencias 'OR ' confunde a varias versiones del CBO el cual raramente
seleccionara usar un ndice en la columna referenciada usando una sentencia OR, La
nica manera de garantizar que un ndice es utilizado en este caso es usar un INDEX
HINT.

Conversiones implcitas : Ejemplo WHERE size_char = 20106;

Verificar las estadsticas

Estn los ndices siendo usados
correctamente?
Exists vs In

Verificar condiciones de desigualdad

Ayudar un poco al parser.
Si algo huele mal, puede que este mal.

RENDIMIENTO INEFICIENTE SQL

EXISTS VS IN
La funcin Exists busca la presencia de un solo row que coincida con el criterio de
comparacin, por otro lado la sentencia In busca para todas las ocurrencias.

Ejemplo: Consideremos el siguiente escenario

TABLA1, TABLA2 cada una con 1000 registros.

Opcin A usando In:

SELECT t1.campo

FROM table1 t1
WHERE t1.code IN (SELECT t2.code FROM table2 t2);

Opcin B usando exists :

SELECT t1.campo

FROM table1 t1
WHERE EXISTS (SELECT '1' FROM table2 t2 WHERE t2.code = t1.code)

RENDIMIENTO INEFICIENTE SQL

EXISTS VS IN
Anlisis:
Opcin A usando In:
SELECT t1.campo
FROM table1 t1

WHERE t1.code IN (SELECT t2.code FROM table2 t2);

Todas las rows de TABLA2 sern ledas por cada row en TABLA1, lo cual genera un producto
cartesiano con 1,000,000 de rows leidas.

Opcin B usando exists:

SELECT t1.campo
FROM table1 t1
WHERE EXISTS (SELECT '1' FROM table2 t2 WHERE t2.code = t1.code)

Como mximo 1 row de TABLA2 ser leda por cada row en TABLA1, reduciendo
sensiblemente la sobrecarga de procesamiento que genera la sentencia.

Verificar las estadsticas

Estn los ndices siendo usados

correctamente?
Exists vs In

Verificar condiciones de desigualdad

Ayudar un poco al parser.
Si algo huele mal, puede que este mal.

RENDIMIENTO INEFICIENTE SQL

CONDICIONES DE DESIGUALDAD
Si una condicin utiliza desigualdades (numero_partes> 80) el
optimizador debe estimar el numero de rows a ser retornadas antes de
poder decidir la mejor manera de retornar los datos, esta estimacin es
propensa a errores.

Si se esta usando un index range scan para una columna especifica, el

rendimiento de la consulta puede ser mejorado usando un >= en lugar de
un >, (numero_partes > 80 se convierte en numero_partes >= 81).
En el caso de > se realizara un index full scan.

En el caso de >= Oracle salta hasta la posicin del ndice con una entrada para
el valor de numero_partes en 81 y comienza a realizar el scan a partir de este
punto.
Para ndices largos, esto es muy importante porque reduce el numero de
bloques ledos.

Verificar las estadsticas

Estn los ndices siendo usados
correctamente?

Exists vs In
Verificar condiciones de desigualdad
Ayudar un poco al parser.
Si algo huele mal, puede que este mal.

RENDIMIENTO INEFICIENTE SQL

AYUDANDO AL PARSER

El parsing de un SQL es uno de los procesos mas caros en trminos de tiempo/recursos.

Amigos del parser:

Bind Variables

Aliasing

Bind Variables : Para comprender la importancia de las Bind Variables, imaginemos un sistema
que genera las siguientes consultas:

SELECT code, fullname, size FROM invent WHERE id = 674;

SELECT code, fullname, size FROM invent WHERE id = 234;
SELECT code, fullname, size FROM invent WHERE id = 332;

Cada vez que una de estas consultas se ejecuta, oracle busca en el shared pool si esta consulta
ha sido ejecutada anteriormente. Si es asi, entonces utiliza el plan de ejecucin que ya utilizo
antes.

RENDIMIENTO INEFICIENTE SQL

AYUDANDO AL PARSER
Pero Y si las query no puede ser encontrada en el shared pool?
Antes de ejecutar la consulta, Oracle tiene que comenzar el proceso completo de parsing,
analizando los muchos posibles caminos de ejecucin y determinando cual es el mas optimo.
(hard parse), proceso que en un sistema OLTP (On-line transaction Processing) puede llegar
a ser incluso mas costoso que la propia ejecucin de la consulta como tal.

La clave aqu es que las condiciones cambian, por lo cual aunque las queries son similares
nunca son las mismas: id = 674, 234, 332.

Las bind variables son variables de sustitucin, y son usadas en lugar de los valores
explcitos 674,234,332 y que permiten enviar el mismo SQL a Oracle cada vez que la query
es ejecutada:

SELECT code, fullname, size FROM invent WHERE id = :code_num;

RENDIMIENTO INEFICIENTE SQL

AYUDANDO AL PARSER
Aliasing:
- La fase de parsing de una query puede ser optimizada si usamos
Aliases para las tablas de forma correcta, si un alias no esta
presente en una consulta con mltiples joins y condiciones, el
motor de base de datos debe resolver a cual de las tablas
involucradas pertenecen las columnas especificadas.
Sentencia no apropiada
Sentencia buena

Ejemplo:
SELECT first_name, last_name
FROM employee, countries
WHERE country_id = id AND
lastname = 'JOHNSON';

SELECT e.first_name, e.last_name

FROM employee e, countries c
WHERE e.country_id = c.id AND
e.last_name = 'JOHNSON';

Verificar las estadsticas

Estn los ndices siendo usados
correctamente?
Exists vs In
Verificar condiciones de desigualdad
Ayudar un poco al parser.
Si algo huele mal, puede que este mal.

RENDIMIENTO INEFICIENTE SQL EJEMPLOS

Why This Sucks?

SELECT COUNT(*) FROM products p

WHERE prod_list_price < 1.15*(SELECT AVG(unit_cost) FROM cost c
WHERE c.prod_id = p.prod_id);

- El subquery se estar ejecutando por cada row encontrada en el query

exterior , la query anterior es mejor si se escribe de esta forma:

SELECTY COUNT(*) FROM products p

(SELECT prod_id, AVG(unit_cost) ac FROM costs GROUP BY prod_id) c
WHERE p.prod_id = c.prod_id AND
p.prod_list_price < 1.15 * c.ac;

RENDIMIENTO INEFICIENTE SQL EJEMPLOS

Why This Sucks?
SELECT *
FROM job_history jh, employees e

WHERE substr(to_char(e.employe_id),2) = substr(to_char(jh.employe_id),2);

SELECT *
FROM car_engine
WHERE cc_cuantity_char = 3000;

Cuando nuestra query requiera un de una union de los resultados de

muchas consultas, meditemos sobre si estamos usando correctamente las
funciones UNION y UNION ALL.

RENDIMIENTO INEFICIENTE SQL

UNION VS UNION ALL

El operador UNION , contrario a UNION ALL, asegura que no

habrn rows duplicados en el resultado de la query; sin
embargo esta caracterstica requiere de un ordenamiento
extra con el fin de eliminar las rows duplicadas.

Si se sabe que no hay rows en comn entre las queries

involucradas, se debe usar UNION ALL en lugar de UNION,
esto elimina el ordenamiento extra.

CONTEXTO: QUE ES ARQUITECTURA?

IEEE 1471-2000

The fundamental organization of a system

embodied in its components, their relationships to
each other, and to the environment, and the
principles guiding its design and evolution
Tomado: Estndar ISO 1471-200
Tomado: Estndar IEEE 1471-200

1.

Incrementar eficiencias

2.

Reducir costos

Business transformation is a term used to refer to

strategic, enterprise-wide change, projects that have a
profound impact on the organisations capabilities,
environment, processes and performance

3.

Fuente: Trends in business transformation study CapGemini & The Economist

Intelligence Unit

Incrementar agilidad de negocio

5.

4.

Enfrentar nuevos mercados

Crecer

Contexto: Niveles de Arquitectura

Abstraccin vs. Generalizacin (No hay que conocer

todos los detalles)

Arquitectura de Solucin

Arquitectura de Dominio ( Software,

Seguridad, BI, etc.)

Componentes / Objetos / Plataformas /

Infraestructuras

Abstraccin

Especificacin

Arquitectura
Empresarial

Arquitecturas por Nivel

Que hay en cada uno de los niveles

Nivel Arquitectura

Arquitectura de Negocio

Arquitectura de
Informacin

Arquitectura de
aplicaciones

Arquitectura de Infraestructura

Solucin

Enfoque: Plan de implementacin

6.0 Roadmap (2)

Iniciativas de
negocio y
tecnolgicas

Explorar universo de
requerimeintos

Informacin
tcnica sobre
aplicaciones,
plataformas
mainframe,
etc.

Evaluar
requerimientos

Priorizar

Emplear criterios:
Beneficio (30%)
Capacidad (40%)
Criticidad (15%)
Riegos (20%

Definir
roadmap

Arquitectura Empresarial
Alineacin negocio vs. Tecnologa

Metas de negocio

Reducir costos

Retos tecnolgicos

Visin
empresarial de
Arquitectura

Integracin de
negocio

Infraestructura (
Cloud/Virt.)

Inteligencia de
negocio

Gestin
empresarial

Servicios &
Aplicaciones

Datos & Big

Data

Crecer
Alineacin

Innovacin &
Agilidad
Globalizacin

Seguridad

Idea Original: Oracle Enterprise Architecture Framework

Desarrollo de
aplicaciones

Arquitectura de Procesos
Niveles de granularidad de los procesos

N-0: Macroprocesos
N-1: Grupos de procesos

N-2: Proceso de negocio

N-3: Actividades de negocio
N-4: Procedimientos/Tareas de negocio
N-5:
Pasos/Requermientos de
negocio

ESTILOS DE ARQUITECTURA DE LAS

APLICACIONES
MAINFRAME

Modelo host

1980
Terminal

1970

1990

1998

- Lgica Presentacin
- Lgica funcional
- Datos

Host

2005

ESTILOS DE ARQUITECTURA DE LAS

APLICACIONES
CLIENTE/SERVIDOR 2 NIVELES

Modelo host

Modelo Cliente/Servidor dos niveles

1980

-Datos

- Lgica Presentacin
- Lgica funcional

Terminal

Cliente

- Lgica Presentacin
- Lgica funcional
- Datos
Host

Servidor

1970

1990

1998

2005

ESTILOS DE ARQUITECTURA DE LAS

APLICACIONES
CLIENTE/SERVIDOR MODIFICADO

Modelo host

Modelo Cliente/Servidor dos niveles

1980

-Datos

- Lgica Presentacin
- Lgica funcional

Terminal

Cliente

- Lgica Presentacin
- Lgica funcional
- Datos
Host

Servidor

1970

1990
Modelo Cliente/Servidor modificado
- Lgica funcional
-Datos

- Lgica
Presentacin
Cliente
Servidor

1998

2005

ESTILOS DE ARQUITECTURA DE LAS

APLICACIONES
N-TIER / MULTI-CAPAS

Modelo host

Modelo Cliente/Servidor dos niveles

1980

-Datos

- Lgica Presentacin
- Lgica funcional

- Lgica Presentacin
- Lgica funcional
- Datos

Terminal

Host

Cliente
Servidor

1970

1990

2005
Multicapas

Modelo Cliente/Servidor modificado

- Lgica funcional
-Datos

- Lgica
Presentacin
Cliente
Servidor

WebServer

1998

Terminal
(Browser)

AppServer

Lgica
Presentacin

Lgica Negocio
(componentes)
Datos

DBServer

ESTILOS DE ARQUITECTURA DE LAS

APLICACIONES
ORIENTACIN A SERVICIOS

Modelo SOA/BPM

2009

Pesentacin

Modelo Cliente/Servidor dos niveles

1980

-Datos

- Lgica Presentacin
- Lgica funcional

Canales
(Web2.0) Portal

Cliente
Servidor

Negocio

BPM

Dashboard

1970

1990

2005
Multicapas

Modelo Cliente/Servidor modificado

- Lgica funcional
-Datos

- Lgica
Presentacin
Cliente
Servidor

Datos

ESB

WebServer

1998

Terminal
(Browser)

AppServer

Lgica
Presentacin
Lgica Negocio
(componentes)
Datos

DBServer

QUE ES EL MODELO MVC

Patrn Estructural

3 Capas: Modelo, Vista y Controlador

Ampliamente usado
Data de 1979, por Trygve Reenskaug para Smalltalk
Se combina con otros patrones y se extiende
No resuelve todos los problemas de la vida real

Mas info aca.

COMPONENTES DEL MODELO MVC

Modelo
Contiene el ncleo de la funcionalidad (dominio) de la aplicacin
Encapsula el estado de la aplicacin

Vista
Es la presentacin del Modelo
Puede acceder al Modelo pero nunca cambiar su estado
Puede ser notificada cuando hay un cambio de estado en el Modelo.

Controlador
Reacciona a la peticin del Cliente, ejecutando la accin adecuada y creando el modelo
pertinente

ESTRUCTURA DIVERSA

ALTA COHESIN y BAJO ACOPLAMIENTO

Cohesin: Es la medida en la
que un componente se dedica a
realizar solo la tarea para la cual
fue creado, delegando las tareas
complementarias
a
otros
componentes.

Acoplamiento: El acoplamiento es
la medida en que los cambios de un
componente tiende a necesitar
cambios de otro componente

PRINCIPIOS CLAVES DE DISEO

Cuando iniciamos con un diseo,
debemos mantener en mente los
principios claves que nos ayudaran a
crear una arquitectura que se adhiere a
principios probados, minimiza costos y
mantenimientos, y promueve la
usabilidad y la escalabilidad. Estos
Separacin
de Responsabilidades:
principios
son:
Dividir la aplicacin en distintas
caractersticas que tengan el menor
traslape posible minimizando al mximo
los puntos de interaccin entre ellas con
el objetivo de lograr alta cohesin y bajo
acoplamiento.
Principio de Responsabilidad nica:
Cada componente debe ser responsable
de una funcionalidad especfica y no
ms.

PRINCIPIOS CLAVES DE DISEO

No repetirse a si mismo (DRY): Una
funcionalidad no debe repetirse ms de
una vez. En trminos de diseo, una
funcionalidad debe ser implementada
solamente en un componente y no debe
estar duplicada en ninguna otra parte.

Principio del menor conocimiento: (Tambin conocido como

principio de Demeter LoD). Un componente u objeto no debe conocer
los detalles de implementacin interna de los otros componentes u
objetos.
Minimizar el diseo adelantado: Solo disea lo que es necesario, En
algunos casos puede ser requerido un diseo preliminar cuando la
incertidumbre sea alta y el riesgo asociado a lo que se est diseando
tambin lo es, de lo contrario evita crear diseos grandes.
(Especialmente si ests haciendo Agile.)

STRUTS 2 - ARQUITECTURA
Actions
Interceptors
Value Stack / OGNL
Results / Result types
View technologies

STRUTS 2 - ARQUITECTURA
Action
Clases que contienen la lgica de negocios completa y controlan la interaccin
(producen todos los resultados) entre el usuario, el modelo y la vista.

Interceptors
Interceptan las peticiones y respuestas aplicando lgica pre y post ejecucin de
una accin. Se pueden personalizar solamente si son necesarios, de lo contrario
se pueden usar los interceptores por defecto.

View
Paginas HTML-JSP que se usan para interactuar con el usuario.

Configuration Files
Archivos de configuracin que sincronizan la interacion MVC. Los config
necesarios son los siguientes: struts.xml, web.xml, struts.properties.

STRUTS 2 CICLO DE EJECUCIN