Creación de una Base de Datos en. con Oracle VM. Newsletter Febrero Contenido. Editores Generales. Autores Contribuyentes.

Transcripción

1 Newsletter Febrero 2014 Contenido Página: Creación de una Base de Datos en con Oracle VM 1 Creación de una Base de Datos en Oracle 12c con Oracle VM 5 Implementación de una Arquitectura Orientada a Servicios (SOA) Por Ing. Manuel Carrillo mcarrillo@datum.com.gt Copiar archivos de sistema operativo y software a la ruta que se muestra en la imagen 8 Cómo Crear un Standby Físico con RMAN Active Duplicate - Parte 1 Crear una máquina virtual con las siguientes características: 5a. Ave Zona14,Edificio Euro Plaza Torre II, Nivel 12 Teléfono: (502) Fax: (502) info@datum.com.gt Editores Generales Pagina 1/10 Francisco Barrundia Alejandro Lau Debbie Morán Autores Contribuyentes Manuel Carrillo Marlon Pérez Francisco Barrundia Página 1

2 Página 2

3 Agregar discos de ASM (compartidos si es un CLUSTER), el mínimo de discos para ASM son 5. Si se desea agregar más discos de los provistos por default, es mejor crear la máquina virtual en base a una plantilla DB/RAC. Luego se agregan los discos (tanto el de S.O. como el de software, más los discos de ASM. Para poder conectarse desde una dirección de la red , debe agregarse a la máquina virtual una NIC para la red , si se desea usar una interfaz para la comunicación privada, debe agregarse también la NIC denominada "interconnect". Iniciar la máquina virtual: Página 3

4 Se seleccionan las opciones por defecto y se colocan claves para root, oracle y grid. Las claves para "oracle" y para "grid" pueden cambiarse posteriormente mediante el archivo de configuración "param.ini" que se encuentra en /u01/racovm/param.ini". [grid@nodo1 ~]$ crsctl stat res t Name Target State Server State details Local Resources ora.data.dg ONLINE ONLINE nodo1 STABLE ora.listener.lsnr ONLINE ONLINE nodo1 STABLE ora.asm ONLINE ONLINE nodo1 Started,STABLE ora.ons OFFLINE OFFLINE nodo1 STABLE Página 4

5 Implementación de una Arquitectura Orientada a Servicios (SOA) Por Ing. Marlon Antonio Pérez mperez@datum.com.gt Introducción Implementar una arquitectura orientada a servicios (SOA) en una organización significa definir una estrategia para el desarrollo de la tecnología de la información empresarial. Se organizan funciones de aplicaciones dentro de servicios interoperables, basados en estándares industriales. Los servicios pueden ser reutilizados o combinados rápidamente para atender necesidades del negocio. Implementar SOA en una organización genera los siguientes beneficios: Reusabilidad Los servicios TI producen servicios de negocio. Interoperabilidad Servicios levemente acoplados. Escalabilidad y Flexibilidad Servicios documentados, asincrónicos y de alta funcionalidad. El costo de implementación es bajo dado que se basa en estándares y que reutiliza el esfuerzo realizado por la organización en la construcción de sus distintos sistemas de información. Este artículo presenta una metodología que se puede utilizar para implementar una arquitectura orientada a servicios en una institución pública o en una empresa privada. Se describe un método para diseñar los procesos de negocio y se define el concepto de orquestación en dicha arquitectura. Contenido 1. Metodología para implementar SOA Para implementar SOA en organizaciones tanto privadas como públicas, se utiliza un modelo de 8 dominios. Dominado por la tecnología Disciplina organizacional Arquitectura Negocio y estrategia Infraestructura Organización Información Gobernanza Operación, administración y mantenimiento Proyecto, portafolio y servicios Figura 1 Modelo de 8 dominios Página 5

6 El modelo de 8 dominios crea un plan de trabajo que define la dirección de la organización como objetivos del negocio, identificando los alcances y la motivación. Así se determina la dirección del departamento de Tecnología de la Información y se utiliza la estrategia SOA para definir el funcionamiento de los procesos de negocio. La estrategia SOA se basa en identificar el punto de vista de los actores clave, prioriza los beneficios SOA para la organización y examina la realidad actual de cada proceso de negocio. Al implementar SOA, se busca que en el futuro la organización se guíe a través de definiciones, estándares, reglas, principios, guías y vistas que permiten que el core business y la cultura organizacional estén claramente identificadas e implementadas en la Tecnología de la Información que da sustento y base a la organización. Se define una arquitectura de referencia para desarrollo de aplicaciones, garantizando que esté basada en las necesidades y requerimientos del core business de la organización. Se define una arquitectura destino y los principios a ser utilizados por los arquitectos de la organización para crear las decisiones de diseño arquitectónico en todas las aplicaciones que desarrollen. Esta arquitectura de referencia será el componente clave para lograr que la organización goce de los beneficios de implementar SOA. La metodología SOA permite identificar a los clientes de los servicios y los canales principales de desarrollo, así como las aplicaciones existentes en la organización (web, portales, mashups, procesos BPM, etc.). Además, permite clasificar los servicios y establecer los requerimientos para desarrollar una arquitectura orientada a servicios. Un servicio SOA provee una unidad de trabajo como parte del proceso de negocio, de tal manera que desarrolle una función de negocio. Un servicio web es un sistema de software o una función de negocio bien descrita, diseñada para soportar interacción máquina-máquina a través de una red, utilizando tecnologías y protocolos estándar para comunicarse con los clientes. 2. Diseño de procesos de negocio en una arquitectura SOA Se deben diseñar las necesidades del negocio de manera que sean dirigidas por un proceso de negocio. Se deben identificar los servicios que desarrollan funcionalidad como parte del proceso de negocio y construir un portafolio de servicios. Las interfaces de los servicios deben ser especificadas utilizando el estándar WSDL. Luego, establecer la forma en que se generarán los servicios. Las opciones más utilizadas son: Java WS y adaptadores JCA BPEL Aplicaciones compuestas SCA.NET WS 2.1 Creación del portafolio de servicios Para establecer los servicios del portafolio es muy importante tener en mente que los servicios son componentes a ser reutilizados, de manera que la lógica de negocio sea íntegra y consistente en toda la organización. Este portafolio puede implementarse como un repositorio empresarial, fortaleciendo la gobernanza de los procesos de negocio bajo el paradigma SOA. Además, se puede establecer un UDDI o registro del servicio en el momento del diseño, con independencia de ubicación al momento de Página 6

7 ejecución. Se puede utilizar tecnología de adaptación para reutilizar funcionalidad empacada en aplicaciones proporcionadas por terceros como SAP y otras. El portafolio podrá desarrollar nuevos servicios utilizando tecnología habilitada para SOA: servicios web (WS), aplicaciones compuestas (SCA), lenguaje de ejecución de procesos de negocio (BPEL), bus de servicios (Service Bus). 3. Concepto de orquestación en la arquitectura orientada a servicios Permite el acceso a datos y servicios elementales de lógica de negocio que serán consumidos por la capa de orquestación de servicios. Esta capa puede apoyarse en modelos que utilicen lenguaje unificado de modelación (UML), específicamente diagramas de actividades. De esta forma se logrará mucha agilidad en los procesos dado que la lógica base del negocio se separa de la lógica de control. Los sistemas de gestión de procesos de negocio (BPMS) proveen las herramientas de modelación y el ambiente de ejecución para crear éstos servicios. Conclusiones Para aprovechar los beneficios de SOA, se debe desarrollar un portafolio de servicios que incluya el ciclo de vida de los servicios y la estructura organizacional para SOA. Además, se necesita ser capaz de definir políticas, procesos y administración de la estrategia SOA y del plan de trabajo a seguir. De esta forma se evitan conflictos de intereses entre los actores involucrados y la organización favorece a que las personas trabajen ordenada y coordinadamente. La implementación de SOA mejora la agilidad del negocio ante el cambio en el mercado. La arquitectura SOA asegura una gestión centralizada de herramientas para definir políticas de control de cambio y de manejo de nuevas versiones. Administra la forma en que se consumen y utilizan los servicios, define una estructura de contrato entre los proveedores y los consumidores, denominados contratos del nivel del servicio (SLA por sus sigla en inglés). La implementación de SOA provee una administración centralizada de servicios distribuidos y heterogéneos, además de obligar al seguimiento de los convenios establecidos para los servicios (SLA). Bibliografía Oracle University, ORACLE SOA Suite 11g: Essential Concepts OSIATIS, ITIL v3, gestión de servicios TI Thomas Erl. (2005), Service-Oriented Architecture (SOA): Concepts, Technology, and Design, Crawfordsville, Indiana: Prentice Hall Thomas Erl. (2007), SOA: Principles of service design, Boston, Massachusetts: Prentice Hall Página 7

8 Por Lic. Francisco Barrundia Como crear un Standby Físico con RMAN Active Duplicate - Parte 1 Para este ejemplo tenemos lo siguiente: Primary : prod Server : srvprod Standby : stdby Server : srvstdby DB_NAME: prod Lo primero es encontrar la ubicación de los Online Redo Logs y Datafiles que residen en la base de datos primaria. Luego definir dónde van a residir en la base de datos Standby para establecer los parámetros LOG_FILE_NAME_CONVERT y DB_FILE_NAME_CONVERT. Asegurarse de que estos directorios existen y que tienen el espacio necesario para contener la base de datos. La base de datos primaria debe estar configurada en modo archivelog y con force logging. Para habilitar archivelog y force logging: SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount SQL> alter database archivelog; SQL> alter database open; SQL> alter database force logging; SQL> select log_mode,force_logging from v$database; LOG_MODE FOR ARCHIVELOG YES Ahora que estamos en modo archivelog y establecido force logging para la base de datos primaria, configurar tnsnames.ora y verificar con tnsping, desde ambos sitios primario / standby. El resultado en ambos servidores debe de ser algo similar a esto: $ tnsping prod Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = srvprod)(port = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = prod))) OK (0 msec) Página 8

9 $ tnsping stdby Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = srvstdby)(port = 1521))) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = stdby))) OK (10 msec) A continuación, crear y replicar el archivo de claves de la base de datos primaria, el cual se encuentra en $ORACLE_HOME/dbs. Cambiarle el nombre para reflejar el nombre de la standby. El nombre debe coincidir con el ORACLE_SID utilizado, no con el DB_NAME. $ cd /u01/app/oracle/product/11.2.0/dbhome_1/dbs $ orapwd file=orapwprod password=test entries=5 $ scp orapwprod srvstdby:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwstdby orapwprod 100% KB/s 00:00 Ahora vamos a configurar el archivo de parámetros para la base de datos standby. cat initprod.ora *.audit_file_dest='/u01/app/oracle/oradata/dump/prod/adump' *.audit_trail='db' *.compatible='11.2.0' *.control_files='/u01/app/oracle/oradata/prod/control/control01.ctl' *.db_block_size=8192 *.db_cache_size=128m *.db_name='prod' *.db_recovery_file_dest='/u01/app/oracle/fast_recovery_area' *.db_recovery_file_dest_size=2g *.db_unique_name='prod' *.diagnostic_dest='/u01/app/oracle/oradata/dump/prod' *.log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(all_logfiles,all_roles) DB_UNIQUE_NAME=prod' *.log_archive_dest_2='service=stdby ASYNC valid_for=(online_logfiles,primary_role) DB_UNIQUE_NAME=stdby' *.log_archive_dest_state_1='enable' *.log_archive_dest_state_2='enable' *.open_cursors=300 *.pga_aggregate_target=128m *.processes=150 *.remote_login_passwordfile='exclusive' *.sga_target=512m *.UNDO_TABLESPACE='UNDOTBS1' FAL_SERVER=stdby; FAL_CLIENT=prod; DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/stdby/STDBY/datafile/','/u0 1/app/oracle/oradata/prod/PROD/datafile/' LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/stdby/STDBY/onlinelog/','/ u01/app/oracle/oradata/prod/prod/onlinelog/' LOG_ARCHIVE_CONFIG='DG_CONFIG=(prod,stdby)' Página 9

10 Casi todo el trabajo que se hará en el servidor primario, lo único que se hará en el servidor standby es: - Crear las ubicaciones para archivos de diagnóstico / redo / datafiles / control files - Verificar la conectividad entre el servidor primario y standby - Arrancar la instancia de base de datos standby, que es el siguiente paso $ export ORACLE_BASE=/u01/app/oracle $ export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 $ export ORACLE_SID=stdby $ cat initstdby.ora DB_NAME=prod DB_UNIQUE_NAME=stdby DB_BLOCK_SIZE=8192 $ sqlplus / as sysdba SQL> startup nomount pfile='/home/oracle/bin/dg.ora'; SQL> exit Ahora volvemos al servidor primario y agregamos los standby redo logs, en este caso se crean dos del mismo tamaño que los online redo logs en la primaria. SQL> select instance_name,host_name from v$instance; INSTANCE_NAME HOST_NAME prod srvprod SQL> select name from v$database; NAME PROD SQL> select GROUP#,THREAD#,MEMBERS,BYTES FROM V$LOG; GROUP# THREAD# MEMBERS BYTES SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE ; SQL> ALTER DATABASE ADD STANDBY LOGFILE SIZE ; SQL> SELECT GROUP#, BYTES FROM V$STANDBY_LOG; GROUP# BYTES Página 10

11 Ahora vamos con el script RMAN para crear la base de datos standby. $ cat duplicate.rmn run { allocate channel prmy1 type disk; allocate channel prmy2 type disk; allocate channel prmy3 type disk; allocate channel prmy4 type disk; allocate auxiliary channel stby type disk; duplicate target database for standby from active database spfile parameter_value_convert 'prod','stdby' set db_unique_name='stdby' set db_file_name_convert='/u01/app/oracle/oradata/prod/prod/datafile/','/u01/ app/oracle/oradata/stdby/stdby/datafile/' set log_file_name_convert='/u01/app/oracle/oradata/prod/prod/onlinelog/','/u0 1/app/oracle/oradata/stdby/STDBY/onlinelog/' set control_files='/u01/app/oracle/oradata/stdby/control/control01.ctl','/u01 /app/oracle/oradata/stdby/control/control02.ctl' set log_archive_max_processes='10' set fal_client='stdby' set fal_server='prod' set standby_file_management='auto' set log_archive_config='dg_config=(prod,stdby)' set log_archive_dest_2='service=prod ASYNC valid_for=(online_logfile,primary_role) db_unique_name=prod' ; } Tip Técnico del Mes Si al intentar realizar un expdp obtenemos este error... les sugiero que chequeen el user con el que están tirando la tarea tenga permisos sobre el directorio en el cual se va a volcar el dump... SELECT * FROM ALL_DIRECTORIES -- chequeamos los directories existentes SYS DATAPUMPDIR /u01/app/oracle/oracle/product/10.2.0/db_1/rdbms/log/ SELECT * -- chequeamos los permisos que tienen los usuarios sobre los directories FROM user_tab_privs WHERE table_name = 'DATAPUMPDIR' -- asignamos permisos al usuario correspondiente, para que pueda acceder al directory específico GRANT READ, WRITE on DIRECTORY DATAPUMPDIR to USUARIO1; Por Lic. Francisco Barrundia fbarrundia@datum.com.gt Página 11