测试LOB的SECUREFILE存储方式时发现,如果利用SQLLDR的TRUNCATE方式导入数据,随着测试次数的增加,LOB对象占用的空间也会逐步增加[转帖]_MySQL, Oracle及数据库讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MySQL, Oracle及数据库讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3949 | 回复: 0   主题: 测试LOB的SECUREFILE存储方式时发现,如果利用SQLLDR的TRUNCATE方式导入数据,随着测试次数的增加,LOB对象占用的空间也会逐步增加[转帖]        下一篇 
wayne
注册用户
等级:中校
经验:1690
发帖:221
精华:0
注册:2011-7-21
状态:离线
发送短消息息给wayne 加好友    发送短消息息给wayne 发消息
发表于: IP:您无权察看 2011-9-8 21:15:07 | [全部帖] [楼主帖] 楼主

测试LOB的SECUREFILE存储方式时发现,如果利用SQLLDR的TRUNCATE方式导入数据,随着测试次数的增加,LOB对象占用的空间也会逐步增加。

创建表的脚本很简单:

create table t_load_4m_sf (id number, full_name varchar2(100),
create_date date, contents blob, constraint pk_t_load_4m_sf primary key(id))
lob (contents) store as securefile;


用于加载LOB数据的控制文件如下:

[oracle@dbserver1 sqlldr]$ more sqlldr_4M_sf.ctl
LOAD DATA
INFILE 'filename.dat'
INTO TABLE T_LOAD_4M_SF
TRUNCATE
FIELDS TERMINATED BY ','
(ID CHAR(255),
FULL_NAME CHAR(255),
CREATE_DATE SYSDATE,
CONTENTS LOBFILE(FULL_NAME) TERMINATED BY EOF)


数据文件格式如下:

[oracle@dbserver1 sqlldr]$ more filename.dat
1,/home/oracle/2M/IMG_5015.JPG
2,/home/oracle/2M/IMG_5016.JPG
3,/home/oracle/2M/IMG_5017.JPG
4,/home/oracle/2M/IMG_5018.JPG
5,/home/oracle/2M/IMG_5022.JPG
6,/home/oracle/2M/IMG_5023.JPG
7,/home/oracle/2M/IMG_5025.JPG
.
.
.
663,/home/oracle/2M/DSC00142.JPG
664,/home/oracle/2M/DSC00143.JPG


导入命令如下:

[oracle@dbserver1 sqlldr]$ sqlldr enmotest/oracle control=sqlldr_4M_sf.ctl
SQL*Loader: Release 11.2.0.2.0 - Production on Mon Aug 8 17:32:54 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Commit point reached - logical record count 64
Commit point reached - logical record count 128
Commit point reached - logical record count 192
Commit point reached - logical record count 256
Commit point reached - logical record count 320
Commit point reached - logical record count 384
Commit point reached - logical record count 448
Commit point reached - logical record count 512
Commit point reached - logical record count 576
Commit point reached - logical record count 640
Commit point reached - logical record count 664


第一次执行导入,检查表的空间占用:

SQL> select table_name, a.segment_name, bytes/1024/1024 from user_segments a, user_lobs b where b.segment_name = a.segment_name order by 1;
TABLE_NAME SEGMENT_NAME BYTES/1024/1024
------------------------------ ------------------------------ ---------------
T_LOAD_4M SYS_LOB0000062585C00004$$ 1088
T_LOAD_4M_SF SYS_LOB0000062641C00004$$ 1220.1875


其中T_LOAD_4M是LOB没有采用SECUREFILE方式保存的普通表。这个表每次执行TRUNCATE方式的SQLLDR加载后,空间并不会发生变化,但是T_LOAD_4M_SF随着执行SQLLDR次数的增加,空间占用的情况分别变为:

SQL> select table_name, a.segment_name, bytes/1024/1024 from user_segments a, user_lobs b where b.segment_name = a.segment_name order by 1;
TABLE_NAME SEGMENT_NAME BYTES/1024/1024
------------------------------ ------------------------------ ---------------
T_LOAD_4M SYS_LOB0000062585C00004$$ 1088
T_LOAD_4M_SF SYS_LOB0000062641C00004$$ 1348.1875
SQL> select table_name, a.segment_name, bytes/1024/1024 from user_segments a, user_lobs b where b.segment_name = a.segment_name order by 1;
TABLE_NAME SEGMENT_NAME BYTES/1024/1024
------------------------------ ------------------------------ ---------------
T_LOAD_4M SYS_LOB0000062585C00004$$ 1088
T_LOAD_4M_SF SYS_LOB0000062641C00004$$ 1540.1875
SQL> select table_name, a.segment_name, bytes/1024/1024 from user_segments a, user_lobs b where b.segment_name = a.segment_name order by 1;
TABLE_NAME SEGMENT_NAME BYTES/1024/1024
------------------------------ ------------------------------ ---------------
T_LOAD_4M SYS_LOB0000062585C00004$$ 1088
T_LOAD_4M_SF SYS_LOB0000062641C00004$$ 1732.125


除了第一次加载空间增长了128M外,以后每次加载都会导致表空间增长192M。而同样的操作并不会导致BASICFILE方式的LOB表。

导致这个现象的原因除了SECUREFILE存储方式外,也与SQLLDR的TRUNCATE导入方式有关,SQLLDR的TRUNCATE只是为了清空数据,由于随后还要执行导入,因此没有必要回收分配的空间,因此这个TRUNCATE语句会保留现有的空间,在加上SECUREFILE的特殊性,导致了每次加载LOB都使得表的空间不断的增长。

而如果尝试直接执行TRUNCATE TABLE语句,则会使得表的高水位线被清空,表的大小恢复到0。虽然这里存在一定的空间泄漏,但是对于实际生产环境中,这种TRUNCATE的SQLLDR方式应该极为罕见,因此并不会导致什么危害。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论