sqlldr导入数据到多个表的问题

kingstarer 2009-03-03 01:18:55
想把一个文件里面的数据同时导到两张表

控制文件如下:

Load DATA
INFILE 'test_direct.dat'
discardfile 'test_direct.dsc'
append
into table testf
when empid != ''
fields terminated by '|'
(
empid integer EXTERNAL,
empname char(20),
salary integer EXTERNAL
)
into table testg
when empid != ''
fields terminated by '|'
(
empid integer EXTERNAL,
empname char(20),
salary integer EXTERNAL
)


数据文件如下:

2010|zz|5600|
2011|gg|5700|
2012|mm|5800|
2018|sf|15800|
2020|sd|75800|
2021|ak|65800|


sqlldr test/test@test control=test.ctv log=test.log

结果不成功,日志如下:


Table TESTF:
6 Rows successfully loaded.
0 Rows not loaded due to data errors.
0 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.


Table TESTG:
0 Rows successfully loaded.
0 Rows not loaded due to data errors.
6 Rows not loaded because all WHEN clauses were failed.
0 Rows not loaded because all fields were null.
...全文
436 7 打赏 收藏 转发到动态 举报
写回复
用AI写文章
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
kingstarer 2009-03-11
  • 打赏
  • 举报
回复
这样啊 那就真是郁闷了 我的字段是不定长的~
moonshowder 2009-03-09
  • 打赏
  • 举报
回复
[Quote=引用 3 楼 kingstarer 的回复:]
谢谢LS的 确实成功导入了

想请教一下,为什么这样写就能导入,我那样写错在哪了

我在你的控件文件基础上再做了修改,把table2的控制参数除了when条件外全改成一样
结果发现又不能同时导入两张表了
[/Quote]
在同一个文件导入到2张以上表的情况下,when 后面必须要个POSITION
kingstarer 2009-03-04
  • 打赏
  • 举报
回复
换成不一样的条件也无法导入啊

WHEN col1!= ' '

WHEN col2!= ' '
cargoj 2009-03-04
  • 打赏
  • 举报
回复
两个WHEN都是一样的条件,应该是不能同时执行两个表导入的原因.
kingstarer 2009-03-04
  • 打赏
  • 举报
回复
谢谢LS的 确实成功导入了

想请教一下,为什么这样写就能导入,我那样写错在哪了

我在你的控件文件基础上再做了修改,把table2的控制参数除了when条件外全改成一样
结果发现又不能同时导入两张表了
moonshowder 2009-03-03
  • 打赏
  • 举报
回复

LOAD DATA

INFILE 'filename.txt'

append

INTO TABLE table1

WHEN col1!= ' '
fields terminated by " "
TRAILING NULLCOLS
(col1,col2)

INTO TABLE table2

WHEN col2!= ' '
(col1 POSITION(1:11) CHAR,
col2 POSITION(12:18) CHAR)

以上方法可以导入2张表中。要求数据长度一致。
同病相怜,我也是要这样导入,但是表的字段表比较多而且长度不确定。
kingstarer 2009-03-03
  • 打赏
  • 举报
回复
建表语句如下:


create table testf
(
EMPID NUMBER(4),
EMPNAME VARCHAR2(20),
SALARY NUMBER(16,2)
);

create table testg as select * from testf;



从日志来看,这些记录只被导进了一张表

我试过将when去掉,结果发现两张表都没导进去

不知道有哪位大是能解释一下为什么会出现这样的情况,要怎么修改控制文件才能达到目的?
PRM-DUL Oracle数据库恢复工具,一款专为Oracle数据救援而研发的企业级工具。可在多个操作平台(AIX/HPUX/SOLARIS/Linux/Windows)使用并支持对Oracle 9i/10g/11g/12c各版本数据库的数据救援工作。软件基于JAVA 开发,绿色无需安装,图形化操作界面,易于上手使用。可基于单数据文件操作或Oracle ASM存储磁盘操作。 PRM-DUL Oracle数据库恢复工具(简称PRM-DUL)是一款专为Oracle数据救援而研发的企业级工具。从1.0版本发布到现在,已经历了多次功能增强、补丁修正和恢复逻辑改进。PRM-DUL Oracle数据库恢复工具已在多个操作平台(AIX/HPUX/SOLARIS/Linux/Windows)被证明稳定可用。当前版本软件支持对Oracle 9i/10g/11g/12c各版本数据库的数据救援工作。软件基于JAVA 开发,绿色无需安装,下载解压后便可直接使用。(Windows上直接点击prm.bat,在Linux/Unix上运行./prm.sh)注意JAVA版本推荐在1.6版本以上。如果需对裸设备文件进行数据救援,请安装并使用JAVA openjdk版本,除此之外,使用官方JAVA版本既可。图形化操作界面,易于上手使用。使用者无需额外学习一套命令,或者了解ORACLE 的底层数据结构原理即可以通过恢复向导(Recovery Wizard)来恢复数据库中的数据。软件支持对单个数据文件的数据扫描和抽取,同时也支持对Oracle ASM存储数据恢复。其导出的数据既可导出为sqlldr导入数据文件,也可通过PRM-DUL的Data Bridge功能直接导出并插入到指定新库中,实现不落地恢复。 PRM-DUL Oracle数据库恢复工具功能 》》可以在不需要运行Oracle数据库的情况下直接针对数据库文件或进行数据解析。 》》支持ASM,可直接读取ASM磁盘并对其中数据文件以及文件中的数据进行扫描解析。 》》支持裸设备数据文件读取。 》》支持LOB字段(CLOB, NCLOB和BLOB)恢复,并支持同一个中,不同LOB列使用不同CHUNK SIZE的情况 》》支持多种Big Endian/Little Endian操作平台(AIX/HPUX/SOLARIS/Linux/Windows)数据数据恢复 》》支持分区、子分区数据恢复 》》支持各种,包括普通的HEAP和聚簇(CLUSTER)数据恢复 》》支持被truncate后的数据恢复 》》支持被drop后的数据恢复 》》支持在没有SYSTEM空间和数据字典损坏的情况下的非字典模式数据恢复,并能为判断数据类型提供辅助依据 》》支持10g及以上的大文件(BigFile)空间 》》支持同一个库中不同块大小的数据文件 》》以纯文本导出时,能够自动生成建SQL语句和SQL*Loader导入所需的control文件 PRM-DUL Oracle(数据库恢复工具) v4.1更新日志 1. 对使用DELETE命令误删除的数据的救援恢复支持 2. 对在字典模式下LOB数据Data Bridge功能增强,大幅度改善导出性能 3. 增加在非字典模式下LOB数据的Data Bridge支持。 4. 增加对字典模式/非字典模式数据加载信息的重用支持 5. 增加Schema级的DDL导出支持(包含相,索引,视图建立语句信息) PRM-DUL Oracle数据库恢复工具截图
使用ODU恢复TruncateODUmanual ODU3月 15th, 2009 意外Truncate的事情时有发生,ODU提供了方便的恢复Truncate的功能。被Truncate的,只要原来的空间没有被重用(即数据被覆盖),则数据都是可以恢复的。 如果发现一个被意外地Truncate,而需要马上恢复。首先要做的就是关闭数据库,或者OFFLINE那个所在的空间,或者关闭所有应用。目的只有一个,确保空间不会被重用,数据不会被覆盖。 下面举例说明如何用ODU恢复被Truncate掉的。 1. 建立测试的DB_JJ_INFO_TEMP。 SQL> connect pdata/test 已连接。 SQL> create table DB_JJ_INFO_TEMP as select * from dba_objects; SQL> truncate table DB_JJ_INFO_TEMP; 2. 我们OFFLINE掉DB_JJ_INFO_TEMP空间(实际上在实际的系统中,如果有比较多的活动,则空间不容易被OFFLINE下来)。然后做一个Checkpoint,让ODU能够读到最新的数据字典数据SQL> select tablespace_name from user_tables where table_name='DB_JJ_INFO_TEMP'; TABLESPACE_NAME ------------------------------ PDATA SQL> alter tablespace PDATA offline; 空间已更改。 SQL> alter system checkpoint; 系统已更改。 22=================================完善字典文件格式如下 control.txt文件中的数据格式为: 空间号 文件号 相对文件号 文件名 块大小 是否大文件空间 每列之间用空白分隔,可以只需要前四列,即块大小和是否大文件空间可省略,块大小省略时,数据文件的默认块大小为config.txt中block_size的大小。下面是一个示例的数据: #ts #fno #rfno filename block_size bigfile 0 1 1 D:\ORACLE\ORADATA\XJ\SYSTEM01.DBF 4096 1 2 2 D:\ORACLE\ORADATA\XJ\UNDOTBS01.DBF 4096 3 3 3 D:\ORACLE\ORADATA\XJ\DRSYS01.DBF 4096 4 4 4 D:\ORACLE\ORADATA\XJ\EXAMPLE01.DBF 4096 5 5 5 D:\ORACLE\ORADATA\XJ\INDX01.DBF 4096 6 6 6 D:\ORACLE\ORADATA\XJ\ODM01.DBF 4096 7 7 7 D:\ORACLE\ORADATA\XJ\TOOLS03.DBF 4096 7 8 8 D:\ORACLE\ORADATA\XJ\TOOLS02.DBF 4096 9 9 9 D:\ORACLE\ORADATA\XJ\XDB01.DBF 4096 11 10 10 D:\ORACLE\ORADATA\XJ\TEST01.DBF 2048 14 11 11 D:\ORACLE\ORADATA\XJ\K16.DBF 16384 如果数据文件头是完好的,则ODU会自动从文件头里面获取空间号,文件号,相对文件号,文件块大小等。空间号,文件号和相对文件号可以写为0。 注意:ODU将检查control.txt文件中的第一个数据文件是否为SYSTEM空间文件,所以要将SYSTEM空间的第1个文件放在control.txt文件中的第一行。否则将不能自动获得数据字典数据。 3. 运行ODU,并unload数据字典。 ODU> unload dict get_bootstrap_dba: compat header size:12 CLUSTER C_USER# file_no: 1 block_no: 177 TABLE OBJ$ file_no: 1 block_no: 241 CLUSTER C_OBJ# file_no: 1 block_no: 49 CLUSTER C_OBJ# file_no: 1 block_no: 49 found IND$’s obj# 19 found IND$’s dataobj#:2,ts#:0,file#:1,block#:49,tab#:3 found TABPART$’s obj# 230 found TABPART$’s dataobj#:230,ts#:0,file#:1,block#:3313,tab#:0 found INDPART$’s obj# 234 found INDPART$’s dataobj#:234,ts#:0,file#:1,block#:3377,tab#:0 found TABSUBPART$’s obj# 240 found TABSUBPART$’s dataobj#:240,ts#:0,file#:1,block#:3473,tab#:0 found INDSUBPART$’s obj# 245 found INDSUBPART$’s dataobj#:245,ts#:0,file#:1,block#:3553,tab#:0 found IND$’s obj# 19 found IND$’s dataobj#:2,ts#:0,file#:1,block#:49,tab#:3 found LOB$’s obj# 156 found LOB$’s dataobj#:2,ts#:0,file#:1,block#:49,tab#:6 found LOBFRAG$’s obj# 258 found LOBFRAG$’s dataobj#:258,ts#:0,file#:1,block#:3761,tab#:0 4. 获取PDATA用户下的DB_JJ_INFO_TEMP,也就是我们要恢复的的信息: ODU> desc PDATA.DB_JJ_INFO_TEMP Object ID:33547 Storage(Obj#=33547 DataObj#=33549 TS#=11 File#=10 Block#=1400 Cluster=0) NO. SEG INT Column Name Null? Type --- --- --- ------------------------------ --------- ------------------------------ 1 1 1 OWNER VARCHAR2(30) 2 2 2 OBJECT_NAME VARCHAR2(128) 3 3 3 SUBOBJECT_NAME VARCHAR2(30) 4 4 4 OBJECT_ID NUMBER 5 5 5 DATA_OBJECT_ID NUMBER 6 6 6 OBJECT_TYPE VARCHAR2(18) 7 7 7 CREATED DATE 8 8 8 LAST_DDL_TIME DATE 9 9 9 TIMESTAMP VARCHAR2(19) 10 10 10 STATUS VARCHAR2(7) 11 11 11 TEMPORARY VARCHAR2(1) 12 12 12 GENERATED VARCHAR2(1) 13 13 13 SECONDARY VARCHAR2(1) 从上面的输出中,我们可以看到,PDATA.DB_JJ_INFO_TEMP所在的空间号为11,数据段头部为10号文件的1400号块。 5. 接下来用ODU扫描空间的extent: ODU> scan extent tablespace 11 scanning extent… scanning extent finished. 6. 我们使用ODU来确定DB_JJ_INFO_TEMP原来的data object id。一般来说,数据段的数据块,一般是在段头后面相邻的块中。但是我们可以从段头来确认: ODU> dump datafile 10 block 1400 Block Header: block type=0×23 (ASSM segment header block) block format=0×02 (oracle 8 or 9) block rdba=0×02800578 (file#=10, block#=1400) scn=0×0000.00286f2d, seq=4, tail=0×6f2d2304 block checksum value=0×0=0, flag=0 Data Segment Header: Extent Control Header ------------------------------------------------------------- Extent Header:: extents: 1 blocks: 5 last map: 0×00000000 #maps: 0 offset: 668 Highwater:: 0×02800579 (rfile#=10,block#=1401) ext#: 0 blk#: 3 ext size:5 #blocks in seg. hdr’s freelists: 0 #blocks below: 0 mapblk: 0×00000000 offset: 0 -------------------------------------------------------- Low HighWater Mark : Highwater:: 0×02800579 ext#: 0 blk#: 3 ext size: 5 #blocks in seg. hdr’s freelists: 0 #blocks below: 0 mapblk 0×00000000 offset: 0 Level 1 BMB for High HWM block: 0×02800576 Level 1 BMB for Low HWM block: 0×02800576 -------------------------------------------------------- Segment Type: 1 nl2: 1 blksz: 2048 fbsz: 0 L2 Array start offset: 0×00000434 First Level 3 BMB: 0×00000000 L2 Hint for inserts: 0×02800577 Last Level 1 BMB: 0×02800576 Last Level 1I BMB: 0×02800577 Last Level 1II BMB: 0×00000000 Map Header:: next 0×00000000 #extents: 1 obj#: 33549 flag: 0×220000000 Extent Map ------------------------------------------------------------- 0×02800576 length: 5 Auxillary Map ------------------------------------------------------------- Extent 0 : L1 dba: 0×02800576 Data dba: 0×02800579 ------------------------------------------------------------- Second Level Bitmap block DBAs ------------------------------------------------------------- DBA 1: 0×02800577 从上面的输出中的“Extent 0 : L1 dba: 0×02800576 Data dba: 0×02800579”可以看到,段的第1个数据块的RDBA为0×02800579,也就是10号文件的1401块。 我们dump第10号文件的1401块头,来得到DB_JJ_INFO_TEMP原来的data object id: ODU> dump datafile 10 block 1401 header Block Header: block type=0×06 (table/index/cluster segment data block) block format=0×02 (oracle 8 or 9) block rdba=0×02800579 (file#=10, block#=1401) scn=0×0000.00285f2b, seq=2, tail=0×5f2b0602 block checksum value=0×0=0, flag=0 Data Block Header Dump: Object id on Block? Y seg/obj: 0×830b=33547 csc: 0×00.285f21 itc: 3 flg: E typ: 1 (data) brn: 0 bdba: 0×2800576 ver: 0×01 Itl Xid Uba Flag Lck Scn/Fsc 0×01 0xffff.000.00000000 0×00000000.0000.00 C--- 0 scn 0×0000.00285f21 0×02 0×0000.000.00000000 0×00000000.0000.00 ---- 0 fsc 0×0000.00000000 0×03 0×0000.000.00000000 0×00000000.0000.00 ---- 0 fsc 0×0000.00000000 Data Block Dump: ================ flag=0×0 -------- ntab=1 nrow=16 frre=-1 fsbo=0×32 ffeo=0×145 avsp=0×113 tosp=0×113 可以看到,DB_JJ_INFO_TEMP原来的data object id就是33547。 7. 使用ODU来unload数据: ODU> unload table PDATA.DB_JJ_INFO_TEMP object 33547 Unloading table: DB_JJ_INFO_TEMP,object ID: 33547 Unloading segment,storage(Obj#=33547 DataObj#=33547 TS#=11 File#=10 Block#=1400 Cluster=0) 8. 使用sqlplus将PDATA空间ONLINE: SQL> alter tablespace test online; 空间已更改。 9. 使用sqlldr导入我们恢复的数据: E:\ODU\data>sqlldr test/test control=TEST_T1.ctl SQL*Loader: Release 9.2.0.8.0 - Production on 星期日 3月 15 15:13:56 2009 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. 达到提交点,逻辑记录计数6502 达到提交点,逻辑记录计数13004 达到提交点,逻辑记录计数19506 达到提交点,逻辑记录计数26008 达到提交点,逻辑记录计数30071 至此,恢复数据的步骤已经完成。我们来对比一下数据,看看数据是否和被Truncate前的数据完全一样: SQL> select * from t2 minus select * from DB_JJ_INFO_TEMP; 可以看到,数据已经完全恢复。

17,377

社区成员

发帖
与我相关
我的任务
社区描述
Oracle 基础和管理
社区管理员
  • 基础和管理社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧