AnySQL.net

    以前一直以为sqlldr不能装载大于4k大小的文本, 原来这个理解是错误的. 但是在免费的文本导出程序ociuldr中, 没有充分考虑long类型. 第一, 用于fetch的数组大小是固定的500, 第二默认的long类型导出长度是4000. 最主要的原因是ARRAY固定为500不是件好事, 如果我指定long的导出长度为1MB, 那不是得用掉500M的系统内存?

    在最新的改进中, ARRAY SIZE的默认值变为50, 最小值为5, 最大值为2000, LONG类型的默认导出长度为32K, 还有就是LONG类型的导出长度乘以ARRAY SIZE的值不能超过100MB, 如果超出, 则ARRAY SIZE的值变为100MB除以LONG导出长度后的值, 如果不足5, 则设为5. 命令行帮助中多了两行:

       long  = maximum long field size
       array = array fetch size

    在生成控制时, LONG类型也能自处理, 生成的字段定义如下所示:

--
-- Generated by OCIULDR
--
OPTIONS(BINDSIZE=8388608,READSIZE=8388608,ERRORS=-1,ROWS=50000)
LOAD DATA
INFILE 'uldrdata.txt' "STR X'06'"
INTO TABLE t_views
FIELDS TERMINATED BY X'07' TRAILING NULLCOLS
(
  OWNER CHAR(30),
  VIEW_NAME CHAR(30),
  TEXT CHAR(32768)
)

    其中TEXT是视图的定义, 我已经在本地试过了, 导入了10K大小的视图定义.

    在DBMS_METADATA之前, 要获得建表语法, 估计很多人都要用Toad或PL/SQL Developer之类的程序了, 不过很多数据库运行在Unix或Linux上, 并不允许我们用这类工具去连接, 这时还真是一件难事. 就算有了DBMS_METADATA我也并不觉得它很方便, 因此不如自已写一个角本, 在我的DBDiff程序中, 已经通过exp/imp的办法实现了, 将相关部分功能独立出来, 就成了getddl工具(Windows版本).

    程序经以过以下步骤来实现这个功能: 1, rows=n进行导出; 2, 用show=y加上indexfile选项生成内容; 3, 处理生成的indexfile并打印出DDL语句. 因此这个小工具需要Oracle的客户端, 并且客户端的版本不能高于服务器端.

Usage: getddl table=... [user=...]
(c) Copyright Lou Fangxin, 2008, all rights reserved.

    user就是exp或imp时的用户名, table就是exp的tables参数, user参数不指定就以sys用户连接. 下面来看一个例子.

C:\>getddl table=sh2.t_iottest
CREATE TABLE "T_IOTTEST" ("COL1" NUMBER NOT NULL ENABLE,
  PRIMARY KEY ("COL1") ENABLE)
  ORGANIZATION INDEX PCTFREE 10
  STORAGE ( FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) PCTTHRESHOLD 50 ;

    在生成的DDL角本中, 没有表对应的Trigger, 如果是Context有关的, 也有可能不准确, 另外表的授权语句不能生成. 用这个工具导出的DDL语句中没有Tablespace子句, 也没有Initial和Next子句. 欢迎大家使用!

    到现在为止, 免费文本导出小工具(ociuldr)的累计下载次数已经突破5000次, 已经有很多的知名的大公司, 选择下载源代码, 进行编译和使用, blue_prince在阿里巴巴更是创下了导出文本速度的新记录.

    而我大约是这个工具的最大用户吧, 昨天花了二个小时, 给数据仓库组导了10亿条记录, 在导的过程中发现了一个无关紧要的小问题, 当文字类型字段不是从表中直接来时, 可能会分配过多的内存. 如下所示.

C:\>ociuldr user=test/test query="select '' from dual"
1638450 bytes allocated for column '' (1)

       0 rows exported at 2008-01-25 08:39:37
       1 rows exported at 2008-01-25 08:39:37
         output file uldrdata.txt closed at 1 rows.

    引起这个问题的原因是由于OCI接口不能正确地估计返回字段的长度, 在以前的测试中没有试这种占位列,因此没有发现.

C:\>ociuldr user=test/test query="select '' from dual"
  200050 bytes allocated for column '' (1)

       0 rows exported at 2008-01-25 08:42:56
       1 rows exported at 2008-01-25 08:42:56
         output file uldrdata.txt closed at 1 rows.

    对于这个小问题, 你可以不理, 当然如果心里觉得不爽, 就下载新的吧!

    比较两个环境, 比如测试A和测试B, 或测试环境和正式环境之间的表结构差异, 是件很麻烦的事, 如果有成千上百的表, 可能会相当地耗时, 花个一两天也是有的. 正是因为不想花这么长的时间去做麻烦的事, 就偷懒地写了ocidiff这个表结构比较和自动同步程序.

    一位51job的DBA朋友正好面临同样的问题, 我就推荐了这个程序给他. 早上正式使用后, 回馈说程序运行相当的快速和准确, 几分钟内完成手工几个小时才能完成的事, 并给出可读性很好很清晰的比较报告, 因此决定作为正式工具在公司内部使用, 以大大的减少了DBA在这类琐事上无谓的时间消耗. 每年年初他们网站的流都要上升个几倍, 因此需要花更多的时间面对负荷的上升, 就不能花太多的时间在手工比较表结构这种事上面. 这个角本再加上良好的SQL编写习惯, 可以防止某些低级错误.

    这个工具是命令行的OCI程序, 做成命令行是为了更适合在OS上进行作业调度, 这一点虽不为大众所喜欢, 但却是很实用的. 这是一个三年前开发的工具, 已经成熟稳重了, 并且和人工处理相比, 它的结果更加准确. ocidiff是点对点的比较, 另一个工具(Compare Any Column)则可以进行多点之间的比较, 比较方式更加灵活.

    作为一个很偷懒的DBA, 有好几个用来偷懒的角本. 不偷懒的DBA不是好DBA, 不是指不做事的, 是指在做事中相办法偷时间的.

    这世上有8个DUL类(包括DUL本身)的产品, 大家不一定要找Oracle DUL了, 也不一定要找AUL, 中国人要去破解就去破国外的吧, 别破解AUL了, 最近发现很多写程序的都是大牛, 很容易破AUL, 也可能是我太菜了.

• Bernard’s Data UnLoader
  Oracle官方工具, 由Netherlands的Oracle工程师Bernard van Duijnen用C语言写成. 由Oracle支持人员提供服务服务, 价格相当贵. 不过流出来的很多, 一般不能提供远程恢复, 要求现场或传文件的, 都是在用它私下恢复吧.
• DUDE/jDUL
  最早曾经开源(jDUL)过, 后来不开源了, 名称改为DUDE, 由OakTable的成员编写, 网站上可以看到一个团队在维护, 支持Oracle 7, 恢复数据字典(整理建表角本)方面比我的AUL历害, 其他不相上下, Big File表空间大家都没有开始用呢.
• AnySQL UnLoader (AUL)
  由Oracle ACE Fangxin Lou(就是我了)用C编写的, 以服务的方式提供, 不支持Oracle 7.
• Oracle Salvage
  由Oralce内核开发人员Scott Martin用C编写的版本, 以产品方式出售.
• OracleRecovery
  用Microsoft Visual C++编写的DUL, 以产品方式出售.
• Recovery for Oracle
  一波兰人用Delphi编写的工具, 没有使用过, 以产品方式出售.
• 另一个MyDUL
  由国内的Jerry Sun所写, 但还不完善, 作者也无心搞下去了, 知道有怎么多版本后, 更不会搞下去了.
• CLOUT
  由Oracle-Internals网站站长开发的, 用于验证某些概念的, 不对外开放.

    由于破解相当历害, 因此暂停AUL下载, 等想出一个较强的算法后, 再说了. 真正需要的话可以发邮件给我索取. 还有一个MYjDUL的东东, 估计是没有抄写成功, 有宣传页面, 却没有试用版本, 只能算是营销中的宣传手段(象打磨的汉芯)了.