Download Descargue el PDF – Volumen 11 Año 2 – Marzo 2011

Volumen 11 Año 2 – Marzo 2011
Métodos Para Desfragmentar Un
Tablespace
Contenido
Página
1 Métodos para
Desfragmentar
un Tablespace
3 BPEL desde la
Perspectiva Oracle
5 Base
DatosEdificio
Standby
5a. Ave.
5-55 de
Zona14,
Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311 Por:
en Cascada
Email. info@datum.com.gt
Editores Generales
Karlo Espinoza
Luis Cordón
Gerber Bautista
Debbie Moran
Francisco Barrundia
Ing. Manuel Carrillo
mcarrillo@datum.com.gt
Pagina 1/10
Un tablespace puede fragmentarse básicamente por los algoritmos y las
estructuras de datos (por ejemplo arboles b+) que acceden a la información, de
hecho en este tipo de estructuras (arboles b+) que tienen una estructura mas rígida
la fragmentación puede darse con el simple hecho de repetidas manipulaciones a
estas estructuras. Esta fragmentación puede darse únicamente de manera física si
se tienen tablespaces manejados por diccionario, por lo que todos
(absolutamente todos) deben tener una administración de extents de manera
local.
Utilizando particionamiento:
Autores Contribuyentes
Manuel Carrillo
Daniel Caciá
Deiby Gómez
Muchos sistemas no realizan ninguna operación de eliminación de datos históricos
en línea, en su lugar mantienen información histórica; incluso si ya no es necesaria.
En estos casos (y en muy raras ocasiones) la data es eliminada en cantidades
masivas en alguna oportunidad. El particionamiento es una de las opciones que
podemos utilizar para poder eliminar estos datos de una manera mucho mas fácil y
segura. Por ejemplo, si una columna tipo DATE o una secuencia es usada como
llave de particionamiento, la partición mas vieja de la tabla puede ser eliminada en
lugar de realizar eliminación de todas las filas viejas.
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Página 1
Al realizar esta operación, estamos eliminando la sobrecarga en tiempo de ejecución de eliminar
las filas y deja las filas restantes compactas, sin ninguna fragmentación. Esto también tiene el
beneficio de agrupar las filas más recientes juntas, lo que mejora el comportamiento de obtención
de resultados.
Cuando existan índices en la tabla, los índices también pueden ser particionados en la misma
columna que la tabla, este tipo de índice es conocido como índice local. Cuando la partición mas
vieja de la tabla es eliminada, las particiones correspondientes a los índices también son
eliminadas.
La fragmentación también ocurre cuando objetos de diferente magnitud de segmento ocupa el
mismo tablespace, la eliminación de dichos objetos provocan lagunas que pueden estar dispersas
de manera aleatoria por todo el tablespace.
Para poder evitar
recomendaciones:
esta
situación
se
considera
como
buena
práctica
las
siguientes
1)
2)
3)
4)
5)
6)
Colocar índices y tablas físicamente en discos separados (si fuera posible).
Nunca colocar segmentos de rollback (o UNDO) con segmentos de datos o de índices.
Colocar los Redo Logs en su propio disco.
Colocar de manera separada las tablas e índices de mayor uso en su propio tablespace.
Agrupar tablas e índices con carga similar (tablas con tablas e índices con índices).
Particionar tablas de alta actividad e índices para ayudar a re-balancear I/O de disco y
prevenir cuellos de botella en discos.
7) Utilizar tantos canales controladores de discos como sean requeridos para reducir la
saturación de canales.
También podría considerarse re-organizar el tablespace para compactar segmentos si se identifica
que hay áreas fragmentadas en el mismo.
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Página 2
BPEL Desde la Perspectiva de Oracle
Por: Ing. Daniel Cacía
dcacia@datum.com.gt
Business Process Execution Language (BPEL por sus
siglas en inglés), la abreviación de Web Services Business
Process Execution Language (WS-BPEL), es un estándar
que permite orquestar un conjunto discreto de servicios
web dentro de un flujo de procesos, reduciendo de manera
exponencial el costo y complejidad que implica la
integración entre negocios.
BPEL es un lenguaje basado en XML que permite
describir un proceso de negocios. Las etiquetas XML de
BPEL están definidas por OASIS (Organization for the
Advancement of Structured Information Standars).
Para entender mejor que es BPEL consideremos el flujo
ficticio que una tienda en línea podría necesitar para llevar
a cabo una venta:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
El cliente ingresa en a la tienda en línea.
El cliente selecciona el producto que desea comprar.
El sistema de ventas revisa si se tiene el producto en el inventario.
El sistema se da cuenta que ya no tiene ese producto en bodegas.
En lugar de indicarle al cliente que no tiene el producto, el sistema contacta
inmediatamente al proveedor del producto.
El sistema del proveedor del producto le responde de forma automática que si posee el
producto pero que el precio subió.
El sistema de la tienda en línea envía una notificación al cliente sobre el aumento del
precio y espera su confirmación.
El cliente confirma el pedido
El sistema de la tienda contacta al proveedor y hace el pedido.
El sistema del proveedor le indica la fecha estimada de entrega.
El sistema de la tienda envía la información al cliente.
En apariencia este flujo debería tener intervención humana para coordinar y tomar decisiones
respecto a cada situación que se genere, sin embargo con BPEL se puede definir un flujo de
proceso que permita tomar decisiones al sistema con o sin intervención humana. En otras
palabras, Oracle BPEL es la alternativa para remplazar Oracle Workflow. BPEL utiliza los web
services provistos por los negocios y permite, por medio de una interfaz gráfica, crear un flujo de
trabajo en el que se puede automatizar la toma de decisiones y el tipo de resultados que se
requiere en cada proceso.
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Página 2
En la actualidad existen muchas empresas que ven los Web Services y SOA como una alternativa
para solucionar los requerimientos de integración con otros negocios a través de aplicaciones
heterogéneas. Crear un web service es un proceso de 2 pasos. El primer paso consiste en
publicar el servicio y segundo agregarlo a un flujo de negocio. Publicar un web service significa
tomar una funcionalidad de una aplicación existente o sistema y crear un interfaz estándar para
que esté disponible a otros negocios.
Para poder dar el segundo paso es necesario una herramienta que cumpla con los
siguientes requerimientos:





Interoperabilidad (WS, JMS, JCA, Portal, email, etc.)
Interacciones sincrónicas y asincrónicas
Mapeo y transformación de datos
Lógica de procesos (deterministica y no deterministica)
Mantenimiento y auditoría en “caliente”
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Página 3


Versionamiento
Transaccionalidad
Oracle ofrece el Oracle BPEL Process Manager, el cual es una herramienta que se integra con
Oracle Fussion Middleware y que está disponible para las versiones 10.1.3 y 11g. El Oracle BPEL
Procces Manager provee una solución amigable para desarrollar, diseñar, desplegar y administrar
procesos de negocios BPEL. Oracle BPEL Process Manager consta del BPEL Designer, el BPEL
Engine y el BPEL Console.
El BPEL Designer consiste en la interfaz gráfica y amigable que permite construir los
procesos BPEL. Lo que hace único al Oracle BPEL Designer es que utilizar BPEL como su
formato nativo, esto significa que los procesos creados con el diseñador son portables y
adicionalmente permite a los desarrolladores ver y modificar el código fuente de BPEL en cualquier
momento. BPEL Designer es un componente de Jdeveloper 11g y 10.1.3. Ofrece varias
herramientas que facilitan a los desarrolladores la conectividad y transformación de procesos
BPEL. Estas herramientas incluyen soporte para transformaciones XSLT y XQuery además de
adaptadores para “legacy systems” a través de JCA y protocolos nativos.
El BPEL Engine provee la más madura, escalable y robusta implementación de un servidor
BPEL. Es la plataforma sobre la cual publicamos nuestros flujos de procesos. El Oracle BPEL
Process Manager ejecuta los procesos a la vez que permite “capturar” el estado de los flujos
considerados largos en el tiempo y almacenarlos en la base de datos, permitiendo la escalabilidad
y alta disponibilidad del proceso.
EL BPEL Console provee una interfaz web para dar mantenimiento, administrar y depurar
los procesos desplegados en el BPEL server. Información histórica y auditorias son recolectadas
automáticamente y disponibles a través de la consola vía APIs de Java.
En conclusión, Oracle BPEL ofrece una opción para automatizar la interacción entre Web
Services y por lo tanto disminuir la intervención humana para toma de decisiones y orquestar el
resultado de cada servicio.
Si desea ver un ejemplo sencillo sobre el BPEL Designer puede visitar la siguiente dirección:
http://www.youtube.com/watch?v=XRzTySj-aak.
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Página 4
Bases de Datos Standby en Cascada
Por: Ing. Deiby Gomez
dgomez@datum.com.gt
estructuras de los datos pueden ser
diferentes. Es sincronizada por SQL Apply.
1. INTRODUCCIÓN
Una Base de Datos Standby asegura alta
disponibilidad, protección de datos y
recuperación de desastres para datos
empresariales. Oracle Data Guard provee un
conjunto de servicios que crean, mantienen,
manejan y monitorean una o más bases de
datos standby. Data Guard mantiene esas
bases de datos standby como copias
transaccionalmente consistentes de la base
de datos de producción, por lo tanto si la
base de datos de producción no está
disponible ya sea por un corte planeado o no
planeado, Data Guard puede realizar un
cambio entre el rol primario y el rol standby,
minimizando así el tiempo de inactividad que
implica el corte. Una configuración de Data
Guard está formada por lo siguiente:


Cascaded Standby Databases: Para reducir
la carga en su sistema primario, puede
implementar destinos en cascada, es decir,
una base de datos standby recibe datos redo
desde otra base de datos standby en lugar
de recibirlos directamente de la base de
datos primaria.
Las configuraciones en cascada soportadas
son:



PD
PD
PD
PS
PS
LS
PS
LS
PS
Una base de datos de producción
Desde una hasta nueve bases de
datos Standby
La base de datos de producción puede ser
sencilla o RAC.
Una base de datos Standby puede ser de
dos tipos:


Physical Standby
Logical Standby
Physical Standby: Es una copia bloque a
bloque idéntica de la base de datos primaria.
Es sincronizada por medio de Redo Apply.
Logical Standby: Contiene la misma
información lógica de la base de datos
primaria, aunque la organización y las
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Donde: PD=Base de Datos Primaria
PS=Physical Standby
LS=Logical Standby
Nota: Una base de datos Standby no puede
colocarse en cascada si su base de datos
primaria es RAC. Es posible crear una base
de Physical Standby a partir de una Logical
Standby de una base de datos primaria RAC,
Página 5
pero ésta ya no sería cascada de la base de
datos primaria RAC.
Las configuraciones no soportadas son:





PD
RAC
RAC
RAC
RAC
LS
PS
PS
LS
LS
LS
PS
LS
PS
LS
Una physical standby puede soportar un
máximo de nueve destinos remotos. Oracle
recomienda que destinos en cascada
únicamente sean usados para reportería o
para aplicaciones que no requieran acceso a
datos que estén completamente a la fecha
con el sitio primario.
Bases de datos Standby recibiendo datos
redo desde una physical standby: El
proceso para realizar un switchover o failover
es exactamente el mismo en una
configuración en cascada, porque todas las
bases de datos physical standby retransmiten
idénticos datos redo de la base de datos
primaria. La única diferencia es el tiempo
adicional que puede requerir la restauración
de los datos redo.
Bases de datos Standby recibiendo datos
redo desde una Logical Standby: Cualquier
base de datos que recibe datos redo en
cascada desde una Logical Standby no
puede participar en un en un switchover con
la base de datos primaria, únicamente bases
de datos Logical Standby que reciben
indirectamente datos redo de la base de
datos primaria.
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Creación de una base de datos en
cascada: Una base de datos standby en
cascada se crea siguiendo el proceso normal
de creación de una base de datos standby ya
sea logical o physical, según sea el caso,
pero la diferencia es que están entrelazadas.
El siguiente ejemplo asume que el sitio
primario tiene por nombre “boston”, el sitio
Physical Standby (Layer 1) tiene por nombre
“chicago” y el sitio Physical Standby (Layer 2)
tiene por nombre “denver”. Se requiere crear
un ambiente como el siguiente:
Primero se deberá crear una configuración
Physical Standby con el proceso normal,
luego se crea otra configuración Physical
Standby pero tomando como base de datos
primaria la primer Physical Standby.
A continuación los pasos resumidos:
Creación de la primer Physical Standby
(Layer 1):




Backup de la base de datos primaria
Transmitir el backup al sitio standby
(Layer 1)
Configurar Oracle Net (tnsnames,
listener, etc)
Realizar Duplicate en el sitio standby
(Layer 1)
Las siguientes operaciones son sobre el sitio
primario:




Habilitar FORCE LOGGING
Crear Password File
Configurar un Standby redo log.
Configurar
parámetros
de
inicialización.
Estos
parámetros
deben estar similar a los siguientes
datos:
DB_UNIQUE_NAME=boston
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
Página 6
VALID_FOR=(ONLINE_
LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STAND
BY_ROLE)
DB_UNIQUE_NAME=denver'

DB_UNIQUE_NAME=denver
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/denver/
VALID_FOR=(ONLINE_
LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_2=
'LOCATION=/arch2/denver/
VALID_FOR=(STANDBY_LOGFILES,STAND
BY_ROLE)
DB_UNIQUE_NAME=denver'
STANDBY_ARCHIVE_DEST=/arch2/denver/
REMOTE_LOGIN_PASSWORDFILE=EXCLU
SIVE
LOG_ARCHIVE_DEST_3=
'SERVICE=chicago
VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=chicago'
STANDBY_ARCHIVE_DEST=/arch1/boston/
REMOTE_LOGIN_PASSWORDFILE=EXCLU
SIVE

Habilitar Archive mode
En el sitio standby (Layer 1):


Copiar el archivo de parámetros del
sitio primario al sitio standby
Establecer parámetros de iniciación.
Los parámetros deben ser similares
a los siguientes:
DB_UNIQUE_NAME=chicago
LOG_ARCHIVE_CONFIG=
'DG_CONFIG=(chicago,boston,denver)'
LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/chicago/
VALID_FOR=(ONLINE_
LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_2=
'SERVICE=denver
VALID_FOR=(STANDBY_LOGFILES,STAND
BY_ROLE)
DB_UNIQUE_NAME=denver'
LOG_ARCHIVE_DEST_3=
'SERVICE=boston
VALID_FOR=
(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=boston'
STANDBY_ARCHIVE_DEST=/arch1/chicago/
En el sitio standby (Layer 2):





Backup de la base de datos Layer 1
Transmitir el backup al sitio standby
(Layer 2)
Configurar Oracle Net (tnsnames,
listener, etc)
Realizar Duplicate en el sitio standby
(Layer 2)
Copiar el archivo de parámetros del
sitio primario al sitio standby
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Establecer parámetros de iniciación.
Los parámetros deben ser similares
a los siguientes:



Crear Password File.
Iniciar la Physical Standby.
Verificar que estén sincronizadas las
bases de datos.
Tip técnico del día:
Updates de multiples tablas:
Al querer actualizar más de una tabla a la vez con
una sentencia SQL, muchos clientes tienden a
utilizar sintaxis errónea como esta:
UPDATE employees e, address a SET
e.division ='North America'
where e.employee_id = a.employee_id
and a.country ='USA'
Esta clausula generara un error ya que si se
quiere acutalizar 2 tablas a la vez, debe utilizarse
un subquery con la clausula WHERE exists:
UPDATE employees e
SET e.division = 'North America'
WHERE exists
(SELECT a.employee_id
FROM address a
WHERE a.country='USA' AND
a.employee_id =
e.employee_id)
Por Lic. Francisco Barrundia
fbarrundia@datum.com.gt
Página 7
Nuevo Web Site
Le invitamos a visitar nuestro totalmente nuevo sitio web, una nueva herramienta de contacto al
servicio de nuestros clientes. Ingrese a www.datum.com.gt para conocer más sobre nuestros
servicios, productos, noticias, etc.
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Página 8
Gracias a la retroalimentación de nuestros clientes, Datum – Educacional estará impartiendo el
siguiente curso:
Oracle Database 11g: New Features for Administrators
Este curso está diseñado para introducir las nuevas características de Oracle Database 11g, las
cuales son aplicables al trabajo que normalmente realizan los administradores de la base de datos
y personal relacionado. El curso no intenta proveer de cada detalle acerca de características que
ya existía en versiones anteriores (excepto cuando se está definiendo el contexto para una nueva
característica o cuando se compara el anterior comportamiento con el actual). En consecuencia el
curso será mucho más útil si usted ha administrado otras versiones de bases de datos Oracle,
particularmente Oracle Database 10g.
El curso consiste en lecciones dirigidas por un instructor certificado, demostraciones y prácticas
que le permiten conocer cómo se comportan las nuevas características.
Después de completar este curso usted será capaz de:















Instalar Infraestructura de Grid Oracle
Instalar Oracle Database 11g
Usar las mejoras para Automatic Storage Management (ASM)
Implementar table compression e hybrid columnar compression
Implementar las mejoras en data warehousing y particionamiento
Usar SQL Performance Analyzer
Usar SQL Plan Management y cargar SQL plan baselines
Usar Database Replay
Definir y manejar Automatic SQL Tuning
Usar las mejoras para Resource Manager
Usar Enterprise Manager para monitorear comandos SQL
Usar las nuevas y mejoradas características de RMAN
Usar Total Recall para crear, proteger, y usar datos históricos
Usar Data Pump en modo legacy
Usar Data Recovery Advisor
Próxima fecha:
Este curso se estará impartiendo del 09 al 20 de mayo de 2011 de 8:30 a 12:30 en las
instalaciones de Datum, S. A. ubicadas en 5ª. Avenida 5-55 zona 14 Europlaza Torre II nivel 12,
ciudad de Guatemala.
Para inscribirse llamar al (502) 2364-5300 o escribir a educación@datum.com.gt
Retroalimentación, comentarios,
temas de interés y sugerencias
para hands-on sessions:
newsletter@datum.com.gt
5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12
Teléfono: (502)2364-5300 Fax: (502)2364-5311
Email. info@datum.com.gt
Comentarios y Sugerencias:
Su opinión es muy importante; si desea hacernos algún comentario o
sugerencia, por favor escríbanos al correo electrónico:
newsletter@datum.com.gt.
Página 9