Newsletter Año 2 Volumen 11 Marzo 2011

5a. Ave. 5-55 Zona14, Edificio Euro Plaza Torre II, Nivel 12

Teléfono: (502)2364-5300 Fax: (502)2364-5311

Email. [email protected]

Volumen 11 Año 2 – Marzo 2011


Teléfono: (502)2364-5300 Fax: (502)2364-5311

Email. [email protected] Pagina 1/10

Métodos Para Desfragmentar Un Tablespace

Por: Ing. Manuel Carrillo

[email protected]

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: 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.

Contenido Página

1 Métodos para

Desfragmentar

un Tablespace

3 BPEL desde la

Perspectiva Oracle

5 Base de Datos Standby

en Cascada Editores Generales

Karlo Espinoza

Luis Cordón

Gerber Bautista

Debbie Moran

Francisco Barrundia

Autores Contribuyentes

Manuel Carrillo

Daniel Caciá

Deiby Gómez


Teléfono: (502)2364-5300 Fax: (502)2364-5311


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 esta situación se considera como buena práctica las siguientes recomendaciones:

1) Colocar índices y tablas físicamente en discos separados (si fuera posible). 2) Nunca colocar segmentos de rollback (o UNDO) con segmentos de datos o de índices. 3) Colocar los Redo Logs en su propio disco. 4) Colocar de manera separada las tablas e índices de mayor uso en su propio tablespace. 5) Agrupar tablas e índices con carga similar (tablas con tablas e índices con índices). 6) 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.


Teléfono: (502)2364-5300 Fax: (502)2364-5311


BPEL Desde la Perspectiva de Oracle

Por: Ing. Daniel Cacía

[email protected]

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. El cliente ingresa en a la tienda en línea. 2. El cliente selecciona el producto que desea comprar. 3. El sistema de ventas revisa si se tiene el producto en el inventario. 4. El sistema se da cuenta que ya no tiene ese producto en bodegas. 5. En lugar de indicarle al cliente que no tiene el producto, el sistema contacta

inmediatamente al proveedor del producto. 6. El sistema del proveedor del producto le responde de forma automática que si posee el

producto pero que el precio subió. 7. 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. 8. El cliente confirma el pedido 9. El sistema de la tienda contacta al proveedor y hace el pedido. 10. El sistema del proveedor le indica la fecha estimada de entrega. 11. 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.


Teléfono: (502)2364-5300 Fax: (502)2364-5311


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”


Teléfono: (502)2364-5300 Fax: (502)2364-5311


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.

http://www.youtube.com/watch?v=XRzTySj-aak


Teléfono: (502)2364-5300 Fax: (502)2364-5311


Bases de Datos Standby en Cascada

Por: Ing. Deiby Gomez [email protected]

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:

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

estructuras de los datos pueden ser diferentes. Es sincronizada por SQL Apply. 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 PS PS

PD PS LS

PD LS PS

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,


Teléfono: (502)2364-5300 Fax: (502)2364-5311


pero ésta ya no sería cascada de la base de datos primaria RAC. Las configuraciones no soportadas son:

PD LS LS

RAC PS PS

RAC PS LS

RAC LS PS

RAC LS 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.

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/


Teléfono: (502)2364-5300 Fax: (502)2364-5311


VALID_FOR=(ONLINE_ LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston' LOG_ARCHIVE_DEST_2= 'SERVICE=denver VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) DB_UNIQUE_NAME=denver' LOG_ARCHIVE_DEST_3= 'SERVICE=chicago VALID_FOR= (ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=chicago' STANDBY_ARCHIVE_DEST=/arch1/boston/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

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,STANDBY_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

Establecer parámetros de iniciación. Los parámetros deben ser similares a los siguientes:

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,STANDBY_ROLE) DB_UNIQUE_NAME=denver' STANDBY_ARCHIVE_DEST=/arch2/denver/ REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE

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 [email protected]


Teléfono: (502)2364-5300 Fax: (502)2364-5311


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.


Teléfono: (502)2364-5300 Fax: (502)2364-5311


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ó[email protected]

Retroalimentación, comentarios, temas de interés y sugerencias para hands-on sessions:

[email protected]

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: [email protected].

mailto:educació[email protected]

mailto:[email protected]

mailto:[email protected]

Newsletter Año 2 Volumen 11 Marzo 2011

Documents

Transcript of Newsletter Año 2 Volumen 11 Marzo 2011