Abf leccion 18

Jaime Amigo P. © 2006, Santiago - Chile
Instituto Profesional DuocUC
Escuela de Ingeniería
Manejando Datos

2
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
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
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
INSERT
• INSERT permite insertar filas a una tabla existente
• Con esta sintáxis sólo una fila se inserta a la vez
EJEMPLOS

6
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
• UPDATE permite modificar filas existentes en una tabla
EJEMPLOS
UPDATE

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

Abf leccion 18

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Abf leccion 18

Más de victdiazm

Abf leccion 18