Migración De Bases De Datos De Terceros

Newsletter Junio 2012 Migración De Bases De Datos De Terceros Contenido Por: Ing. Alejandro Lau alau@datum.com.gt Página: 1 Migración De Bases De Datos De Terceros 3 Matar un proceso DataPump 4 Administración de 5a. Ave. usuarios 5-55 Zona14,Edificio en Oracle Euro Plaza Torre II, Nivel 12 Editores Generales Debido al constante crecimiento en los ambientes de base de datos, en cuanto a concurrencia, volumen de datos y nuevas aplicaciones, se genera mayor Pagina demanda 1/10 de recursos como CPU, memoria, almacenamiento. Dada la eficiente Daniel Cacía administración que Oracle Database hace de estos recursos, es común que los Gerber Bautista clientes consideren migrar su ambiente no Oracle a un entorno Oracle. Oracle provee una herramienta para realizar migraciones de bases de datos no Debbie Moran Oracle o "de terceros", como MySQL, IBM DB2, Informix, Microsoft SQL Server, Francisco Barrundia Sysbase Adaptive Server, Microsoft Access y Teradata. Esta herramienta es SQL Developer. Autores Contribuyentes Alejandro Lau Daniel Cacía Francisco Barrundia Migration Workbench y SQL Developer Anteriormente existía la herramienta Migration Workbench, que proveía esta la funcionalidad mencionada. En la actualidad, dicha funcionalidad fue integrada a SQL Developer. El objetivo es poder migrar la base de datos de terceros de una forma más rápida y automatizada. La opción manual es configurar ODBC hacia la base de datos de terceros y Database Gateway for ODBC (DG4ODBC, antes Heterogeneous Services) y luego migrar tabla por tabla con instrucciones CREATE AS SELECT. Email:info@datum.com.gt Página 1

Requisitos Se requiere acceso a una base de datos 10g o superior para soportar el repositorio de migración y opcionalmente una base de datos Oracle separada como destino de la migración. Puede usarse la misma base de datos para ambos propósitos. Descargar Oracle SQL Developer. Se recomienda la versión 3.0, ya que soporta un procedimiento mejorado sobre las versiones anteriores. Configuración El procedimiento general es el siguiente: 1. Crear el repositorio de migración. Éste consiste en un esquema de base de datos que almacena meta data del proceso de migración. Son 42 tablas, 24 vistas, índices, triggers y código PL/SQL. Se requiere un usuario con el rol RESOURCE y los privilegios CREATE SESSION y CREATE VIEW. Luego desde SQL Developer tenemos la opción Tools > Migration > Repository management > Create Repository... y nos conectamos con el nuevo usuario. 2. Configurar una conexión a la base de datos de terceros. Se requieren dos pasos: a. Instalar y configurar el manejador o driver JDBC propio de la base de datos, lo cual se realiza una sola vez para cada conexión de terceros. b. Crear una conexión por cada base de datos que se desee migrar, lo cual se logra con el panel de conexiones del SQL Developer, ícono "+" verde en la parte superior. 3. Ejecutar el asistente de migración (migration wizard). En el menú de contexto de la conexión a base de datos de terceros aparece la opción "Migrate to Oracle". Hay dos opciones de migración, en línea y fuera de línea. En la primera se conecta a la base de datos de terceros para "importar" los objetos hacia Oracle. La segunda no requiere conexión a la base de datos de terceros, sino que utiliza archivos extraídos de la misma. a. Capturar la base de datos: almacena en el repositorio el estado actual de la base de datos a migrar. Esto minimiza la necesidad de estar consultando la base de datos de terceros durante el proceso. b. Convertir el modelo capturado: en base a los esquemas, tipos de datos, etc. en la base de datos de terceros, se genera un modelo orientado a Oracle. c. Generar y ejecutar scripts SQL a partir del modelo convertido. Se requiere de una conexión a Oracle con un usuario DBA. d. Migrar los datos a Oracle: se copian los datos a las nuevas tablas en Oracle. 4. Copiar solo algunos objetos a Oracle. Esta es una alternativa para copiar solo algunas tablas y sus datos a Oracle, sin usar ni configurar el repositorio. Solo se requiere conexión a ambas bases de datos. Es el método recomendado para MS Access. Página 2

Matar un proceso Data Pump Por: Ing. Daniel Caciá dcacia@datum.com.gt Exportar e importar datos con data pump es una actividad cotidiana para la mayoria de DBA's, y por lo mismo, dado que es una actividad muy utilizada, debe conocerse a la perfección. Con data pump a diferencia de las antiguas herramientas de exportación "exp" e "imp", tiene la curiosa particularidad de seguir ejecutándose en Background si no se cancela de una forma correcta, por lo que a continuación explicaré algunas de las maneras típicas antes utilizadas que no funcionan con el nuevo expdp o impdp. Con frecuencia la tarea de export se lanza desde una consola, si se intenta cancelar con el típico "Ctrl+C" se verá que el proceso aún sigue ejecutándose en Background, esto se puede confirmar por la disminución acelerada en espacio proporcionalmente al tiempo, este comportamiento también suele pasar si el export se intenta detener con cerrar la ventana de la consola desde la cual se lanzó el export. La solución es un kill -9? No, aunque teóricamente un kill -9 mataría el proceso, también presenta el comportamiento de seguir ejecutándose en Background y por lo tanto sigue consumiendo espacio (si de un export se tratase), aunque entre los procesos del sistema operativo ya no aparezca, eso se puede ver mediante la siguiente sentencia a nivel del SO: ps ef grep expdp La forma correcta para matar un proceso de export o import con data pump, consta únicamente de dos pasos: Identificar el proceso data pump ejecutándose Matar el proceso anteriormente identificado Página 3

Identificar el proceso data pump ejecutándose: Esto se realiza únicamente con una conexión hacia la base de datos contra la cual se está ejecutando el proceso data pump, esto puede lograrse mediante un sqlplus, Toad, etc. Una vez se tenga una conexión hacia la base de datos ejecutar la siguiente consulta: SELECT owner_name, job_name, operation, job_mode, state, attached_sessions FROM dba_datapump_jobs WHERE job_name NOT LIKE 'BIN$%' ORDER BY 1,2; Con esta consulta se logra identificar los procesos data pump actualmente ejecutándose, comúnmente solo retornará un proceso, de esta consulta debemos enfocarnos en el campo "owner_name" y "job_name" que son los datos con los cuales pasaremos al siguiente paso. Matar el proceso anteriormente identificado: Una vez tengamos identificado el proceso que ha quedado colgado se deberá matar a nivel de la base de datos mediando la ejecución de un PLSQL el cual expongo a continuación: DECLARE dmp NUMBER; BEGIN dmp := DBMS_DATAPUMP.ATTACH('JOB_NAME','OWNER_NAME'); DBMS_DATAPUMP.STOP_JOB (dmp,1,0); END; / Donde JOB_NAME es el nombre del proceso data pump identificado en el primer paso y OWNER_NAME es el nombre del dueño del proceso. Es necesario tomar en cuenta que si se intenta cancelar el proceso mediante formas no correctas podría dejar inestable el proceso y luego aunque se cancele correctamente podría no responder, teniendo que esperar en esa situación hasta que el proceso termine en Background. Administración de usuarios en Oracle Por Lic. Francisco Barrundia fbarrundia@datum.com.gt 1. Creación de usuarios Una de las más básicas tareas de un administrador de base de datos es identificar los usuarios. Cada usuario que conecta en la base de datos debe de tener una cuenta. En las cuentas compartidas son difíciles de aplicar una auditoria. Para crear un usuario utilizamos la sentencia CREATE USER. Cuando creas una cuenta como mínimo tienes que asignar un único nombre (username) y una contraseña para poder autenticarse. Página 4

Para cambiar alguno de los atributos que se le ha añadido al usuario creado se utiliza la sentencia ALTER USER. 2. Autenticación Oracle Cuando uno se conecta con una instancia de una base de datos la cuenta de usuario debe de estar autenticada. ORACLE provee tres métodos de autenticación para nuestra cuenta de usuario. AUTENTICACIÓN MEDIANTE PASSWORD: Cuando un usuario conecta con una base de datos verifica que este usuario y la contraseña introducida almacenada en la base de datos, sea correcta. Las contraseñas se guardan encriptadas en la base de datos (en el data dictionary). SQL > CREATE USER david IDENTIFIED BY tititus; En este caso tititus es la contraseña de David que será guardada encriptada en la base de datos. AUTENTICACIÓN EXTERNA: Cuando un usuario conecta con la base de datos se verifica que el nombre de usuario es el mismo que el nombre de usuario del sistema operativo para permitir la validación. No se almacenan las cuentas en la base de datos de ninguna forma. Estas cuentas están siempre referidas con OPS$.A partir de la versión 10g puedes configurar OS_AUTHENT_PREFIX en el spfile SQL > CREATE USER ops$david IDENTIFIED BY tititus; Mediante IDENTIFIED EXTERNALLY decimos a la base de datos que nuestra cuenta es externa y tiene que ser validada con el sistema operativo. AUTENTICACIÓN GLOBAL: Cuando un usuario se conecta con la base de datos se verifica globalmente cuando la información pasa por una opción avanzada de seguridad ( ADVANCED SECURITY OPTION ) para la autenticación tal como Kerberos, RADIUS... Para las cuentas globales no se almacena tampoco nada en la base de datos. SQL > CREATE USER david IDENTIFIED GLOBALLY AS CN=alumnos,OU=campus... Mediante IDENTIFIED GLOBALLY decimos a la base de datos que nuestra cuenta se autentica globalmente, mediante otra opción de seguridad avanzada. 3. Asignaciones a los usuarios ASIGNACIÓN DE UN USUARIO A UN TABLESPACE ( DEFAULT TABLESPACE ) Mediante esta sentencia asignamos un usuario a un tablespace, este será su tablespace por defecto cuando creamos un usuario. SQL > CREATE USER david IDENTIFIED BY tititus DEFAULT TABLESPACE users; Mediante esta sentencia, en caso de tener creado ya el usuario le asignamos un tablespace. Página 5

SQL > ALTER USER david DEFAULT TABLESPACE users; La base de datos toma un tablespace por defecto, en caso de querer cambiar este tablespace utilizamos la siguiente sentencia SQL > ALTER DATABASE DEFAULT TABLESPACE users; ASIGNACIÓN DE UN USUARIO A UN TABLESPACE TEMPORAL Un tablespace temporal se utiliza para almacenar segmentos temporales que son creados durante operaciones como ORDER BY,SELECT DISTINCT, MERGE JOIN o CREATE INDEX. A veces a los usuarios se les asocia un tablespace temporal para realizar este tipo de operaciones, cuando estas operaciones finalizan este segmento temporal que se ha creado exclusivamente para la operación desaparece. SQL > CREATE USER david IDENTIFIED BY tititus DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp; Mediante TEMPORARY TABLESPACE asignamos como tablespace temporal temp al usuario david. En caso de que el usuario esté creado si queremos asignarle un tablespace temporal utilizamos ALTER USER SQL > ALTER USER david TEMPORARY TABLESPACE Temp; ASIGNACIÓN DE UN PERFIL A UN USUARIO Al igual que podemos asignar un tablespace a un usuario, también podemos asignarle un perfil (profile). El principal perfil ( profile ) por defecto se denomina default. Si el usuario no está lo podemos crear de la siguiente forma: SQL > CREATE USER david IDENTIFIED BY tititus DEFAULT TABLESPACE users TEMPORARY TABLESPACE temp PROFILE resource_profile; En caso de que el usuario ya esté creado al igual que en los anteriores casos utilizamos la sentencia ALTER USER. SQL > ALTER USER david PROFILE resource_profile; BORRADO DE UN USUARIO Para borrar un usuario utilizamos la sentencia DROP USER, podemos opcionalmente incluir la opción CASCADE, se utiliza para borrar recursivamente los objetos del usuario que se pretende borrar. SQL > DROP USER david CASCADE OTORGANDO PRIVILEGIOS (GRANTING) Página 6

A un usuario podemos otorgarle una serie de privilegios. Un privilegio permite a un usuario acceder a ciertos objetos o realizar ciertas acciones:. - Privilegios sobre Objetos ( Object privileges ) a permisos sobre vistas, tablas, secuencias, procedimientos, paquetes. - Privilegios del Sistema ( System privileges ) a permisos sobre niveles de la base de datos como pueden ser conexión a la base de datos, creación de usuarios, limitar cuentas. - Privilegios sobre Roles ( Role privileges ) a muchos permisos son otorgados mediante roles agrupando un conjunto de privilegios. Para otorgar privilegios utilizamos la sentencia GRANT, para quitar un privilegio o permiso a un usuario utilizamos la sentencia REVOKE EJEMPLOS: Privilegio sobre una tabla: SQL > GRANT ALL ON tabla_alumnos TO david Siendo tabla_alumnos una tabla de nuestra base de datos y david un usuario de esta, hemos asignado mediante GRANT ALL,todos los permisos al usuario david sobre esta tabla. GRANT ALL = permisos SELECT, INSERT, UPDATE, DELETE Si queremos asignar sólo uno de estos permisos utilizamos la misma sentencia pero con el permiso que queramos otorgar. SQL > GRANT SELECT ON tabla_alumnos TO david SQL > GRANT SELECT,INSERT ON tabla_alumnos TO david Privilegio sobre un paquete, función o procedimiento: Los permisos que podemos otorgar a las funciones, paquetes o procedimientos almacenados en nuestra base de datos son los siguientes: EXECUTE, DEBUG. QUITANDO PRIVILEGIOS Tip técnico del día: Como determinar el porcentaje de bloques libres y usados en una tabla? SELECT owner, table_name, pct_used, pct_free FROM all_tables WHERE table_name = 'XYZ'; Síguenos en Facebook: https://www.facebook.com/pages/datum- SA/269377659745551 Si queremos quitar un privilegio a uno de estos objetos haremos lo mismo que con GRANT pero utilizando la sentencia REVOKE. SQL > REVOKE ALL ON tabla_usuarios FROM david Y Twitter: https://twitter.com/#!/datumgt Página 7

. Página 8