Abf leccion 18

471 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
471
On SlideShare
0
From Embeds
0
Number of Embeds
62
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Abf leccion 18

  1. 1. Jaime Amigo P. © 2006, Santiago - Chile Instituto Profesional DuocUC Escuela de Ingeniería Manejando Datos
  2. 2. 2 Instituto Profesional DuocUC Escuela de Ingeniería Objetivos Después de esta lección, usted deberá: • Manipular datos a través de SQL • Usar Data Pump para exportar datos • Usar Data Pump para importar datos • Cargar datos con SQL Loader
  3. 3. 3 Instituto Profesional DuocUC Escuela de Ingeniería Manipulando Datos a traves de SQL SQL> INSERT INTO employees VALUES 2 (9999,'Bob','Builder','bob@abc.net',NULL,SYSDATE, 3 'IT_PROG',NULL,NULL,100,90); 1 row created. SQL> UPDATE employees SET SALARY=6000 2 WHERE EMPLOYEE_ID = 9999; 1 row updated. SQL> DELETE from employees 2 WHERE EMPLOYEE_ID = 9999; 1 row deleted. Manipulando Datos a través de SQL Las sentencias DML (insert, delete, update) permiten manipular datos en una base de datos.
  4. 4. 4 Instituto Profesional DuocUC Escuela de Ingeniería El comando INSERT • Crea una fila a la vez. • Inserta muchas filas desde otra tabla. El comando INSERT La sentencia INSERT permite crear una fila a la vez en una tabla. Esta información es primero escrita en el Buffer de Redo Log en la SGA. Usando lo que se conoce como subconsulta, es posible insertar filas desde otra tabla. Este método es referido como INSERT AS SELECT. El ejemplo de la figura indica: insert into dept_80 (select * from employees where department_id = 80); En este caso la tabla dept_80 tiene exactamente la misma estructura que la tabla employees. Si este no fuera el caso, usted debe nombrar cada columna en cada tabla. Los valores de las columnas seleccionadas deben ser los mismo que los referidos en la estructura de la tabla (mismo order y tipo de datos). Por ejemplo: insert into just_names (first, last) (select first_name, last_name from employees); Aqui la tabla just_names tiene solo dos columna que tiene el mismo tipo de datos que en la tabla employees, estas columnas con first_name y last_name. Usando INSERT SELECT es posible cargar datos desde una o mas tablas hacia otra.
  5. 5. 5 Instituto Profesional DuocUC Escuela de Ingeniería INSERT • INSERT permite insertar filas a una tabla existente • Con esta sintáxis sólo una fila se inserta a la vez EJEMPLOS
  6. 6. 6 Instituto Profesional DuocUC Escuela de Ingeniería El comando UPDATE Usado para modificar filas de una tabla. El comando UPDATE El comando UPDATE es usado para modificar filas existentes en una tabla. El número de filas modificadas depende de la condición especificada en la cláusula WHERE. Si la condición WHERE es omitida, entonces todas las filas son modificadas. Si no hay filas que cumplan la condición WHERE, entonces ninguna fila es modificada.
  7. 7. 7 Instituto Profesional DuocUC Escuela de Ingeniería • UPDATE permite modificar filas existentes en una tabla EJEMPLOS UPDATE
  8. 8. 8 Instituto Profesional DuocUC Escuela de Ingeniería El comando DELETE Usado para remover filas de una tabla. El comando DELETE El comando DELETE es utilizado para remover o eliminar filas existentes en una tabla. El número de filas modificadas dependerá de la condición WHERE. Si la condición WHERE es omitida, entonces todas las filas de la tabla serán eliminadas. Si no hay filas que cumplan la condición, entonces ninguna fila será removida. Note en el ejemplo, cuando no hay filas a eliminar, no genera un error; el mensaje solo retorna que no hay filas eliminadas en la tabla.
  9. 9. 9 Instituto Profesional DuocUC Escuela de Ingeniería DELETE • DELETE permite eliminar filas existentes en una tabla • No se pueden borrar filas que contienen una clave primaria que es clave foránea en otra tabla (concepto de integridad referencial) EJEMPLOS
  10. 10. 10 Instituto Profesional DuocUC Escuela de Ingeniería Los comando COMMIT y ROLLBACK Usado para finalizar una transacción. • Commit: Asegura los cambios de forma permanente • Rollback: Deshace los cambios Los comandos COMMIT y ROLLBACK Por defecto cada comando DML ingresado o ejecutado no es comiteado (confirmada su actualización en la base de datos). Varias herramientas (incluida iSQL*Plus) tiene varias opciones que puede ser configuradas para hacer commit sobre cada comando o grupo de comandos. Antes de que se confirme un COMMIT o ROLLBACK, los cambios realizados por sentencias DML quedan en un estado de pendientes. Sólo el usuario que hizo los cambios tiene permiso para ver los cambios de los datos actualizados. Otros usuarios pueden seleccionar los mismo datos, pero verán los datos antes de que cualquier cambio se haya realizado y estos no hayan sido confirmados por el usuario que los ejecuto. Por defecto, un usuario que intenta hacer un cambio sobre la misma fila que otro usuario esta modificando, deberá esperar hasta que el primer usuario haga un commit o un rollback Esto es controlado automáticamente por el mecanismo de bloqueo de Oracle. Dado que el mecanismo de bloqueo esta construido dentro de la fila, no existe forma que la base de datos quede bloqueada.
  11. 11. 11 Instituto Profesional DuocUC Escuela de Ingeniería Restricciones de Integridad y DML Restricciones de Integridad y DML Todas las restricciones de integridad son forzadas cuando se ejecutan sentencias DML. Columnas FOREIGN KEY: • INSERT y UPDATE: El valor debe existir en la tabla padre. • DELETE: Una fila en la tabla padre tiene debe tener al menos una fila referenciada y no puede ser borrada. Columnas NOT NULL: • INSERT: No se puede hacer inserciones sin un valor • UPDATE: No se pueden hacer modificaciones con un valor NULL Columnas cláve UNIQUE: • INSERT y UPDATE: No puede tener el mismo valor que otra columna en la tabla, excepto NULL. Cada NULL es considerado único, por tanto todas las filas podrían tener un valor de columna NULL con una restricción de clave UNIQUE (clave única). Columnas PRIMARY KEY: • Aplica las reglas de clave UNIQUE y columnas NOT NULL. Columnas CHECK: • INSERT y UPDATE: Valores deben reunir una condición de restricción para poder ser ingresados o modificados.
  12. 12. 12 Instituto Profesional DuocUC Escuela de Ingeniería Exportar con Data Pump Exportar con Data Pump El utilitario Oracle Data Pump permite alta velocidad de transferencia de datos desde una base de datos a otra. Por ejemplo, se puede exportar una tabla y sus índices asociados desde una base de datos e importarlos a otra base de datos. Data Pump es una característica completamente integrada en Oracle Database 10g que permite carga y descarga de datos y metadatos desde y hacia la base de datos a muy alta velocidad. Automáticamente administra y planifica múltiples flujos paralelos de carga y descarga para un máximo rendimiento. La infraestructura de Data Pump puede ser llamada a través del paquete de PL/SQL DBMS_DATAPUMP. De esta forma, utilidades personalizadas de movimiento de datos pueden ser construidas utilizando Data Pump. Oracle Database 10g incluye para esto las siguientes utilidades cliente: •Export de línea de comando (expdp) •Import de línea de comando (impdp) •Interfase de export/import basa en Web de Oracle Enterprise Manager •Interfaze personalizada para modelos complejos de Data Mining (Mineria de Datos) Data Pump es también la fabrica de muchas otras características clave en Oracle Database: Replicación basada en flujo y espera lógica, Data Pump rápidamente genera la configuración inicial en el sitio replicado utilizando la tecnología Flash Back para entregar un punto de partida consistente.
  13. 13. 13 Exportar con Data Pump (continuación) La instalación de grilla inicial está basada en tablespaces transportables, los cuales recaen en datapump para mover y enganchar los metadatos para los objetos definidos en el conjunto de tablespaces transportados. Cuando se reúnen requerimientos para DataPump de grandes consumidores, reiteradamente escuchamos “el tiempo es oro”. Si no haces nada más, haz una importación y exportación mucho más rápida de grandes cantidades de datos. DataPump disminuye el tiempo utilizado para grandes operaciones de importación y exportación por dos órdenes de magnitud en algunos casos. Como resultado los clientes de exportación e importación (expdp e impdp) soportan todas las características de los clientes originales (exp e imp), como también muchas nuevas características, tales como reinicio en checkpoint, estimación del tiempo de trabajo, selección flexible de objetos, carga directa desde una instancia a otra y monitoreo detallado de trabajos. DataPump es una característica integral de Oracle Database 10g y por lo tanto, está disponible en todas las configuraciones. Sin embargo, paralelismo del proceso está disponible solo en versión Enterprise Edition. 1. En la primera página, usted selecciona lo que desea exportar e ingresa las credenciales del host (cuenta que pertenece al grupo DBA en el Servidor de la Base de Datos). Solicita los campos Username y Password. Database: Esta opción exporta la base de datos completa, también llamado full export. Los siguientes esquemas no puede ser exportados como parte del full export porque los metadatos que contienen estan exportados como parte de otros objetos en el conjunto DUMP FILE: SYS, ORDSYS, ORDPLUGINS, CTXSYS, MDSYS, LBACSYS y XDB. Este modo requiere que usted tenga el rol EXP_FULL_DATABASE. Schemas: Esta opción permite exportar todos los objetos de uno o más esquemas. Si no tiene el rol EXP_FULL_DATABASE, entonces solo puede especificar su propio esquema. Esquemas de referencias cruzadas no pueden ser exportados a menos que el esquema referenciado también se especifique en la lista que se exportará. Tables: En este modo solo un conjunto de tablas, particiones u objetos dependientes son exportados. Se debe tener el rol EXP_FULL_DATABASE para especificar tablas que no pertenecen a su esquema y solo puede ser especificado uno por vez. Note que el tipo de definiciones para las columnas no es exportado en modo TABLE. Se espera que este tipo de definiciones exista al momento de realizar el import. Al igual que en el export de esquemas, las referencias cruzadas no son exportadas. 2. Si selecciona Schemas o Tables para el tipo de export, la siguiente página permitirá seleccionar el conjunto de esquemas o tablas que se desean exportar. Haga click en ADD para seleccionar el esquema o tablas a exportar. 3. La página de opciones es el siguiente paso, si selecciono Database el export irá directamente a esta página después de seleccionar el tipo de exportación. El máximo número de hembras indica el grado máximo de paralelismo que será usado en el Job de exportación. Se puede ver o estimar cuán grande será el proceso, seleccionando blocks para una rápida estimación y statistics para una estimación más precisa. Haciendo click en Estimate Disk Space Now, verá los resultados. También puede especificar información adicional respecto del archivo de log a generar en este proceso. Haciendo click en Advanced Options obtendrá lo siguiente:
  14. 14. 14 Exportar con Data Pump (continuación) • Content: usted puede exportar solo los metadatos (estructuras), los datos o ambos. - Flashback: Obtener un export consistente a un instante de tiempo en particular. • Query: Obtener solo los datos que cumplen una condición provista por la cláusula WHERE. 4. La siguiente página son los Files. Se utiliza para especificar el directorio, nombre del archivo y el número máximo para los archivos de export. Al usar %U substituye la variable comenzando con 01 para el primer archivo, 02, 03 y así sucesivamente. Se crean suficientes archivos de DUMP para permitir que todos los procesos especificados en el parámetro PARALLEL esten activos. Por ejemplo, si tenemos expa%U, expb%U y expc%U son todos los especificados para un job (trabajo) que tenia un paralelismo de 6, el primer archivo de dump será expa01.dmp, expb01.dmp, expc01.dmp, expa02.dmp, expb02.dmp, y expc02.dmp. 5. La siguiente página es el Schedule. Use esta página para esquematizar el trabajo de exportación. 6. La última página es Review. Use esta página para desplegar el código PL/SQL para el comando de exportación generado en las selecciones realizadas en las páginas anteriores con el asistente. Puede modificar o no el código, sino tiene los conocimientos suficientes no realice cambios. También es posible copiar el código Pl/SQL propuesto, y llevarlo a un script para efectos de documentación, si lo considera necesario. Haga clik en Submit Job para comenzar el proceso de exportación. Después que el job ha sido ejecutado, haga click en View Job para monitorear el proceso del proceso
  15. 15. 15 Instituto Profesional DuocUC Escuela de Ingeniería Importar con Data Pump Importar con Data Pump Use Data Pump Import para cargar datos extraídos con Data Pump Export. En la página Maintenance, haga click en Import from Files y leer los archivos escritos por Data Pump Export previamente. 1. Files: Indica el directorio y nombre del archivo a importar al servidor de base de datos. Podrá seleccionar 1 o más archivos, indicar esquemas o tablas a específicas. También puede escoger generar un archivo de log e ingresar las credenciales de hot respectivas. 2. Select Objects: Esta página solo aparece cuando se selecciona en la opción Files, seleccionando los objetos a importar. Use esta página para seleccionar usuarios que desean ser importados.
  16. 16. 16 Importar con Data Pump (continuación) 3. Re-Mapping: Esta página solo se despliega si selecciona previamente Selected Objetcs en la página de selección de objetos. Use esta página para colocar los datos importados de un usuario, en un esquema diferente al de origen según lo señalado en los cambios campos Source User y Destinations User. 4. Options: Use esta opción para configurar opciones para reusar el archivo de datos, errores en la creación de objetos e índices inutilizables. 5. Schedule: Use esta página para esquematizar el proceso de import como un JOB en el sistema de trabajos de Oracle (Job Scheduler). 6. Review: Use esta página para desplegar el código PL/SQL para el comando de importación generado, según las opciones seleccionados en los pasos previos. Se puede editar manualmente el código PL/SQL o haga click en Import para iniciar el proceso. Después que el trabajo ha sido ejecutado, haga click en View Job para monitorear el proceso.
  17. 17. 17 Instituto Profesional DuocUC Escuela de Ingeniería Objetos DIRECTORY SQL> CREATE DIRECTORY dpump_dir1 2 AS '/usr/apps/datafiles'; Directory created. SQL> SELECT * FROM DBA_DIRECTORIES 2 WHERE DIRECTORY_NAME = 'DPUMP_DIR1'; OWNER DIRECTORY_NAME DIRECTORY_PATH ------- --------------- -------------------- SYS DPUMP_DIR1 /usr/apps/datafiles Objetos DIRECTORY DataPump es un servidor basado en archivos de DUMP (vaciado), archivos de log y archivos SQL accedidos relativamente desde un servidor basado en rutas de directorio (server-based directory path). DataPump requiere que se especifique el path del directorio como un directorio de objetos. Un directorio de objetos mapea un nombre a un path de directorio sobre el sistema de archivos del servidor de datos. Use la sentencia CREATE DIRECTORY para crear objetos directory o haga click en Create Directory Object. Este especifica un alias para un directorio en el sistema de archivos en el servidor de la base de datos. Se debe tener el privilegio de sistema CREATE ANY DIRECTORY para crear directorios. Cuando se crea un directorio, automáticamente esta permitido leer o escribir sobre el directorio y puede otorgar estos privilegios a otros usuarios o roles. Para ver este tipo de objetos use la vista DBA_DIRECTORIES. Nota: Oracle no verifica que exista el directorio, por tanto, se debe especificar un directorio válido del sistema operativo. En resumen, si el sistema de archivo usa case- sensitive en el nombre de directorio y archivos, debe asegurarse que los nombres están bien escritos. Recuerde, que el sistema operativo es quien controlará la seguridad de los archivos en el directorio.
  18. 18. 18 Instituto Profesional DuocUC Escuela de Ingeniería SQL*Loader Input data files Control File SQL*Loader Log file Bad files Discard files Tablas e índices SQL*Loader SQL*Loader es una pequeña herramienta que permite cargar datos desde archivos externos a tablas de una base de datos. Es una poderosa herramienta que tiene un motor que parsea la data, en base a pequeñas limitaciones de formato en los archivos de entrada. Los archivos usados por SQL*Loader son los siguientes: Input Data Files: SQL*Loader lee datos desde uno o más archivos especificados en el archivo de control. Desde la perspectiva de SQL*Loader, los datos en el archivo de datos estan organizados como registros. Un archivo de datos en particular puede ser de largo fijo o variable. El formato debe ser específicado en el archivo de control con el parámetro INFILE. Si, no hay un formato especificado, se asume el formato por defecto. Control File: Es un archivo de texto escrito en un lenguaje que comprende SQL*Loader. El archivo de control le dice a SQL*Loader dónde encontrar los datos, cómo parsearlos e interpretar los datos, dónde insertar los datos y mucho mas. Aunque no esta definido el archivo de control tiene 3 secciones: • La primera sección contiene información variadas, por ejemplo: - Opciones globales como tamaño de variables, registros, salto de registros, etc - La cláusula INFILE especifica dónde esta localizada la data - Datos a ser cargados
  19. 19. 19 SQL*Loader (continuación) • La segunda sección consiste en uno o más bloques de INTO TABLE. Cada uno de esos bloques contiene información sobre la tabla en la cual los datos serán cargados, nombre de la tabla y columnas de la tabla. • La tercera sección es opcional y si esta presente, contiene datos de entrada. Log File: Cuando SQL*Loader inicia su ejecución, crea un archivo de log. Sino puede crearlo, termina la ejecución de carga. El archivo de log contiene un resúmen detallado de carga, incluyendo una descripción de cualquier error ocurrido durante el proceso. La extensión por defecto es .log Bad File: Contiene los registros que han sido rechazados, ya sea por SQL*Loader o por la base de datos. Los rechazos se producen cuando el formato de entrada es inválido. Después que el registro ha sido aceptado para procesarlo por SQL*Loader, es enviado a la base de datos para su inserción dentro de la tabla como una fila. Si Oracle determina que la fila es válida, entonces inserta la fila en la tabla. Si la fila es inválida, entonces el registro es rechazado y SQL*Loader lo coloca en el archivo de malos (bad file). La extensión por defecto para este tipo de archivos es .bad. Discard File: Este archivo es creado solo cuando es necesario y solo si esta especificado en el archivo de control. Contiene aquellos registros que no han sido cargados. Sino se ha descartado ningún registro durante el proceso de carga, este archivo no es generado. La extensión por defecto es .dsc La diferencia entre los datos erróneos y los descartados es que los primeros son aquellos datos que no han sido insertados en las tablas de la base de datos porque no han podido ser leidos correctamente desde el fichero de datos de entrada o bien su inserción causa errores de incumplimiento de restricciones definidas en las tablas, mientras que los datos descartados no se insertan en la base de datos porque no verifican una determinada condición que puede imponerse en el fichero de control, de manera que tan solo se inserten los datos que satisfacen dicha condición. Un concepto importante a la hora de trabajar con SQL*Loader es el de registro físico y registro lógico. Suponiendo que el fichero de datos es de texto, un registro físico es una línea del fichero. Un registro lógico se corresponde con una fila o tupla de una tabla. La equivalencia entre estos dos tipos de registros puede ser cualquiera. Un registro físico puede dar lugar a varios registros lógicos de manera que cada lectura de una línea del fichero de entrada produce la escritura de varias filas en las tablas. Si por el contrario se necesitan varios registros físicos para formar un registro lógico, se necesitará leer varias líneas del fichero de datos antes de proceder a la inserción de una fila. El caso más sencillo y conveniente es cuando se produce la identidad entre ambos tipos de registro, en el cual cada lectura de una línea del fichero de datos puede generar una inserción en la base de datos.
  20. 20. 20 SQL*Loader (continuación) Mediante la adecuada especificación del fichero de control puede programarse en cierta medida el proceso de carga de datos, ya que se dispone de una cierta capacidad de especificación de condiciones para determinar si los datos leidos han de insertarse o no en la base de datos. La estructura del fichero de datos de entrada puede ser fija o secuencial. Es fija si los valores están dispuestos de forma invariable en posiciones determinadas del fichero de datos y secuencial si simplemente, los valores están colocados uno a continuación del otro en cada línea del fichero y separados por un carácter determinado. En la práctica, pueden existir ficheros cuya estructura presente características de los dos tipos. No es obligatorio que los valores de todos los atributos o columnas del registro lógico aparezcan especificados en los campos del registro físico; se pueden leer todos o tan solo parte de los atributos. Los atributos cuyos valores no aparecen en el fichero de datos se insertan en las tablas con valores nulos. Aunque el fichero de control permite una amplia gama de posibilidades para particularizar la carga de datos a las características del fichero de entrada, puede ser necesario o conveniente preprocesar los datos (por ejemplo, en un editor de texto) eliminando datos innecesarios, contenidos redundantes, etc. Si los datos a ser cargados están ordenados según algún atributo o combinación de atributos entonces se puede aprovechar esta circunstancia para acelerar el proceso. Es muy interesante la posibilidad de insertar valores a determinados atributos de las tablas automáticamente, sin necesidad de especificar dichos valores en el fichero de datos. Por ejemplo, se puede tener un atributo en una tabla cuyo valor se vaya incrementando en una cantidad fija cada vez que se inserta una fila en esa tabla, o bien el valor a insertar para ese atributo es constante para cada fila insertada.
  21. 21. 21 Instituto Profesional DuocUC Escuela de Ingeniería El Control File de SQL*Loader El control file le dice a SQL*Loader: • Dónde encuentra los datos a cargar • El formato de los datos • Detalles de configuración: – Administración de Memoria – Registros rechazados – Otros • Cómo manipular los datos El archivo de control SQL*Loader Es un archivo de texto que contiene instrucciones DLL. Las DLL son usadas para controlar los siguientes aspectos: • Dónde el SQL*Loader encuentra los datos • Cómo espera que los datos esten formateados • Cómo esta configurada (administración de memoria, rechazo de registros, interrupción de carga etc) la carga de datos • Cómo manipula los datos que estan siendo cargados
  22. 22. 22 El archivo de control SQL*Loader Control File (continuación) Un ejemplo para ilustrar el archivo de control es el siguiente: 1 -- This is a sample control file 2 LOAD DATA 3 INFILE ’SAMPLE.DAT’ 4 BADFILE ’sample.bad’ 5 DISCARDFILE ’sample.dsc’ 6 APPEND 7 INTO TABLE emp 8 WHEN (57) = ’.’ 9 TRAILING NULLCOLS 10 (hiredate SYSDATE, deptno POSITION(1:2) INTEGER EXTERNAL(3) NULLIF deptno=BLANKS, job POSITION(7:14) CHAR TERMINATED BY WHITESPACE NULLIF job=BLANKS "UPPER(:job)", mgr POSITION(28:31) INTEGER EXTERNAL TERMINATED BY WHITESPACE, NULLIF mgr=BLANKS, ename POSITION(34:41) CHAR TERMINATED BY WHITESPACE "UPPER(:ename)", empno POSITION(45) INTEGER EXTERNAL TERMINATED BY WHITESPACE, sal POSITION(51) CHAR TERMINATED BY WHITESPACE "TO_NUMBER(:sal,’$99,999.99’)", comm INTEGER EXTERNAL ENCLOSED BY ’(’ AND ’%’ ":comm * 100" ) Explicación simple, por número de línea: 1. Comentario, puede aparecer en cualquier parte de la data. Esta precedido de dos guiones. Todo texto a la derecha de los guiones es ignorado hasta el fin de dicha línea. 2. La sentencia LOAD DATA indica que es el comienzo de una nueva carga de datos. Si se esta continuando una carga interrumpida previamente, entonces use la sentencia CONTINUE LOAD DATA. 3. La palabra clave INFILE indica el nombre del archivo que contiene los datos que se desean cargar.
  23. 23. 23 El archivo de control SQL*Loader Control File (continuación) 4. La palabra reservada BADFILE especifica el nombre del archivo que contendrá los registros rechazados. 5. La palabra clave DISCARDFILE especifica el nombre del archivo que contendra los registros descartados. 6. La palabra clave APPEND es una de las opciones que pueden usarse cuando se cargan datos en una tabla que no esta vacía. Para cargar datos en una tabla vacía use la palabra clave INSERT. 7. La palabra clave INTO TABLE permite identificar tablas, campos y tipos de datos. Esto define la relación entre registros del archivo de datos y filsa de tablas en la base de datos. 8. La cláusula WHEN especifica una o más condiciones que cada registro debe satisfacer antes que SQL*LOADER los cargue. En este ejemplo, cargará solo los registros si el carácter 57th es punto decimal. 9. La cláusula TRAILING NULLCOLS le dice a SQL*Loader como tratar aquellas columnas que contienen nulos. 10. Los restante del archivo de control, contiene una lista de campos que proveen información del formato de la columna en la tabla que esta siendo cargada.
  24. 24. 24 Instituto Profesional DuocUC Escuela de Ingeniería Consideraciones de la Sintáxis del Control File • La sintáxis es un formato libre. • La sintáxis no es case sensitive. • Los comentarios se pueden hacen con (--), los que marcan el inicio del comentario hasta el final de la línea. • La palabra CONSTANT es reservada. Consideraciones sintaxis del archivo de control • La sintaxis tiene un formato libre (sentencias pueden extenderse a múltiples líneas). • Es insensible a mayúsculas o minúsculas, sin embargo, cadenas de caracteres encerrados en comillas simples o dobles, permiten controlar eso. • En la sintaxis del archivo de control, comentarios comienzan con – y terminan al final de la línea • La palabra CONSTANT tiene un significado especial en SQL*Loader y por ende, es una palabra reservada. Para evitar conflictos no utilice la palabra ese palabra en nombre de tablas ni columnas.
  25. 25. 25 Instituto Profesional DuocUC Escuela de Ingeniería Input Data y Data Files • SQL*Loader lee datos desde uno o mas archivos especificados en el archivo de control. • Desde la perspectiva SQL*Loader’s, los datos en el datafile estan organizados como registros. • Un datafile puede ser uno de los siguientes formatos: – Formato Fixed-record (Registro Largo Fijo) – Formato Variable-record (Registro Largo Variable) – Formato Stream-record (Registro Corriente) Datos de Entrada y Archivos de Datos Formato de registro de largo fijo Un archivo tiene un formato de registro fijo, si todos los registros tienen los mismo bytes. Aunque este formato es el menos flexible, da lugar a un mejor rendimiento que un formato de largo variable. El formato de registro de largo fijo es simple de especificar. Por ejemplo: INFILE <datafile_name> "fix n" Este ejemplo especifica que SQL*Loader debe interpretar el archivo de datos como formato de largo fijo donde cada registro tiene un largo de n bytes. El siguiente ejemplo muestra un archivo de control que especifica un formato de registro de largo fijo que contiene 4 registros físicos. El primer registros es [0001, abcd], que tiene exactamente 9 bytes de largo y el décimo caracter es el retorno de carro. load data infile ’example.dat’ "fix 10" into table example fields terminated by ’,’ (col1, col2) example.dat:
  26. 26. 26 Formato de registro de largo fijo (Continuación) 0001,abcd 0002,fghi 0003,klmn Formato de registro de largo variable Un archivo tiene un largo variable de registro, cuando el largo de cada registro es incluido al comienzo de cada registro en el archivo de datos. Este formato provee mas flexibilidad que el anterior. Por ejemplo, puede especificar a un archivo de datos que será interpretado como formato de largo variable como sigue: INFILE "datafile_name" "var n" En este ejemplo, n especifica el nùmero de bytes en el largo del registro. Si n no esta especificado, SQL*Loader asume largo 5. Especificando n mayor que 40 resulta un error. El siguiente ejemplo muestra una especificación de archivo de control que le dice a SQL*Loader que busque datos en el archivo example.dat y que el formato de registro es variable de 4 bytes. El archivo exmaple.dat contiene 3 registros. Físicos. El primero especificado sera de 009 bytes de largo, el segundo 010 bytes de largo y el tercero de 012 bytes. load data infile ’example.dat’ "var 3“ into table example fields terminated by ’,’ optionally enclosed by ’"’ (col1 char(5),col2 char(7)) example.dat: 009hello,cd, 010world,im, 012my,name is, Formato de Registro Simple Un archivo esta en formato de registro simple cuando los registros no especifican tamaño; SQL*Loader en vez de buscar formato de registros, busca un terminador de registro. El registro simple es el formato más flexible, pero puede tener efectos negativos sobre el rendimiento. La especificación de los datos en el archivo deben ser interpretados, como sigue: INFILE <datafile_name> ["str terminator_string"] El terminator_string es especificado como ’char_string’ o X’hex_string’ Donde: ’char_string’ es un string de caracteres encerrado en comillas simples o doble X’hex_string’ es un byte en formato decimal
  27. 27. 27 Instituto Profesional DuocUC Escuela de Ingeniería Métodos de Carga Conventional Direct path Array insert Block writes Tabla SGA High-water mark Métodos de Carga SQL*Loader provee dos métodos de carga de datos: • Path Convencional (Conventional path) • Path Directo (Direct path) Conventional Path La carga convencional construye un arreglo de filas a ser insertadas y utiliza sentencias SQL INSERT para cargar los datos. Durante la carga convencional, las entradas de los registros son parseadas basadas sobre especificaciones de los campos, y un arreglo de registros es construio insertandolos en la tabla indicada en el archivo de control. Los registros que no cumplan los criterios de las especificaciones son descartados o rechazados, dejándolos en un archivo separado (que también debe estar indicado en el archivo de control)
  28. 28. 28 Métodos de Carga (continuación) Direct Path Una carga directa construye bloques de datos en memoria y salva dichos bloques directamente en los extents asignados para la tabla cargada. Las entradas de los archivos de redo log no se generan, a menos que, la base de datos este en modo ARCHIVELOG. Este método de carga usa especificaciones de campos ara construir bloques de datos de Oracle enteros y escribirlos directamente a los datafiles de la base de datos. Este método de carga es mucho más rápido que el método antes descrito pero tiene ciertas limitaciones.
  29. 29. 29 Instituto Profesional DuocUC Escuela de Ingeniería Comparando Ruta de Cargas Directas y Convencionales Otros usuarios no pueden hacer cambios a las tablas Otros usuarios pueden hacer cambios a las tablas No pueden cargarse datos en tablas particionadas Pueden cargarse datos sobre tablas particionadas INSERT no dispara triggersINSERT dispara triggers Hace cumplir solo las restricciones de PRIMARY KEY, UNIQUE y NOT NULL Obliga cumplir todas las restricciones (constraints) Genara entrada de redo log bajo condiciones específicas Las entradas de redo log siempre se generan Usa datos guardadosUsa COMMIT para hacer los cambios permanentes Carga DirectaCarga Convencional Comparando Carga Directa y Convencional Metos de Salvar los Datos La carga convencional utiliza procedimientos SQL y COMMIT para salvar los datos. La inserción de un conjunto de registros viene seguida de una operación COMMIT, para confirmar que estos cambios queden reflejados en la base de datos. La carga de datos involucra varias transacciones. La carga directa utiliza datos salvados ahorrando escritura de bloques de datos a los datafiles de la base de datos. A continuación se mencionan algunas diferencias con respecto al uso del COMMIT: • Durante la salvada de datos, solo los bloques completos son escritos a la base de datos • Los bloques son escritos después de la marca high-water de la tabla • Después que los datos son guardados, la marca high-water es movida • Los recursos internos no son liberados después que los datos son salvados • Un dato salvado no finaliza la transacción • Los índices no son modificados después de cada salvada de datos
  30. 30. 30 Comparando Carga Directa y Convencional (Continuación) Cambios de Registros La carga convencional genera entradas de redo similares a las sentencias DML. Cuando se usa carga directa, las entradas de redo no son generadas siempre que: • La base de datos este en modo NOARCHIVELOG • Si la base de datos esta en modo ARCHIVELOG, pero el logging deshabilitado. Logging puede ser deshabilitado seteando el atributo NOLOGGING para la tabla o usando la cláusula UNRECOVERABLE en el archivo de control para el SQL*Loader. Haciendo cumplir las restricciones Durante una carga convencional, todas las restricciones habilitadas deben cumplirse de la misma manera que actuan con operaciones DML. Durante la carga directa, las restricciones son manejadas como sigue: • Las restricciones de NOT NULL son chequeadas cuando los arreglos son construidos • Las restricciones de FOREIGN KEY y CHECK son deshabilitadas y pueden ser habilitadas al final usando los comandos apropiados en el archivo de control para el SQL*Loader. Las restricciones de FOREIGN KEY son deshabilitadas porque ellas pueden usar funciones SQL. Sino solo se requiere insertar un pequeño número de filas, use cargas convencionales. • Las restricciones de PRIMARY KEY y UNIQUE son chequeadas durante y al final de la carga, y pueden ser deshabilitadas si se violan las reglas de integridad. Disparando triggers de INSERT Si en una carga convencional una tabla tiene triggers de INSERT estos son disparados pra cada fila insertada; en el caso de una carga directa, estos triggers son deshabilitados y activados una vez finalizado el proceso. Considere utilizar cargas convencionales para cargar datos en tablas con triggers de INSERT. Cargando Tablas Particionadas La carga directa no puede ser usada para cargar filas en tablas particionadas. Para ello, utilice carga convencional. Bloqueo Mientras la carga directa esta en proceso, otras transacciones no pueden hacer cambios en las tablas que estan siendo cargadas. La única excepción a esta regla es cuando varias sesiones de carga paralelas son usadas concurrentemente.
  31. 31. 31 Instituto Profesional DuocUC Escuela de Ingeniería Cargando Datos con SQL*Loader Cargando Datos con SQL*Loader Use el asistente Load Data from File para cargar datos desde bases de datos no Oracle a bases de datos Oracle. Al aparecer el asistente, seleccione Load Data from File desde la sección Utilities en la página Maintenance de Enterprise Manager. Se pueden cargar datos como sigue: 1. Conectarse a EM como SYS u otro usuario con privilegios de Administrador. 2. Haga click en Load Data from File bajo Utilities en la página Maintenance para invocar el asistente de carga de 6 pasos. 3. Ingrese el path del archivo de control en el servidor de la base de datos. Ingrese además el usuario y password del host, y haga click en Next. 4. Seleccione “Provide the full path and name on the database server machine” sobre los datos a cargar: página de archivo de datos e ingrese el path. Haga click en Next. 5. El path convencional por defecto para el método de carga. Puede seleccionar path directo si es necesario.
  32. 32. 32 Cargando Datos con SQL*Loader (continuación) 6. Seleccione “Generate log file where logging information is to be stored” bajo Optional Files on the Load Data: Options page. Puede aceptar el nombre del archivo por defecto o ingresar uno diferente. Note que esta página da la opción de limitar el número de filas a cargarse. Haga click en Next 7. Ingrese el nombre del trabajo y descripción sobre la página de Schedule. Seleccione Immediately para ejecutar ahora el trabajo. Haga click en Next. 8. La data a cargar: Página que permite revisar el nombre del archivos y métodos de carga. Si dese modificar algo, haga click en Back. De otra forma, haga click en Submit Job para iniciar la carga. 9. Aparece una página de estado con el mensaje Load Data Submit Successful . Haciendo click en View Job, visualizará un resúmen del trabajo. Este indica que el trabajo ha tenido éxito. Se puede visualizar el archivo de log, haciendo click bajo Logs heading o viendo directamente el archivo de log. 10. Puede confirmar que la data ha sido cargada navegando a la páginade Tables en Enterprise Manager, selccionando la tabla cargada y ejecutando la acción View Data.
  33. 33. Jaime Amigo P. © 2006, Santiago - Chile Instituto Profesional DuocUC Escuela de Ingeniería Fin de la Lección

×