关于 Oracle 的数据导入导出及 Sql Loader (sqlldr) 的用法

在 Oracle 数据库中,我们通常在不同数据库的表间记录进行复制或迁移时会用以下几种方法:

1. A 表的记录导出为一条条分号隔开的 insert 语句,然后执行插入到 B 表中
2. 建立数据库间的 dblink,然后用 create table B as select * from A@dblink where ...,或 insert into B select * from A@dblink where ...
3. exp A 表,再 imp 到 B 表,exp 时可加查询条件
4. 程序实现 select from A ..,然后 insert into B ...,也要分批提交
5. 再就是本篇要说到的 Sql Loader(sqlldr) 来导入数据,效果比起逐条 insert 来很明显

第 1 种方法在记录多时是个噩梦,需三五百条的分批提交,否则客户端会死掉,而且导入过程很慢。如果要不产生 REDO 来提高 insert into 的性能,就要下面那样做: 阅读全文 >>

oracle定时任务[转]

DBMS_JOB系统包是Oracle“任务队列”子系统的API编程接口。DBMS_JOB包对于任务队列提供了下面这些功能:提交并且执行一个任务、改变任务的执行参数以及删除或者临时挂起任务等。

DBMS_JOB包是由ORACLE_HOME目录下的rdbms/admin子目录下的DBMSJOB.SQL和PRVTJOB.PLB 这两个脚本文件创建的。这两个文件被CATPROC.SQL脚本文件调用,而CATPROC.SQL这个文件一般是在数据库创建后立即执行的。脚本为DBMS_JOB包创建了一个公共同义词,并给该包授予了公共的可执行权限,所以所有的Oracle用户均可以使用这个包。 阅读全文 >>

DB2 登录数据库时的代码页转换错误 SQL0332N

客户端连接到另一台机器上的 DB2 数据库,用 DB2 的控制中心连接没问题,但是用 Quest Central for DB2 来连接,输入用户名和密码,确定,出现提示窗口:

[IBM][CLI Driver] SQL0332N  没有从源代码页 "86" 至目标代码页 "819" 的转换。原因代码是 "DB2INST1"。  SQLSTATE=01539

无法登录,原因是本机的代码页(codepage) 与数据库的代码页不相符且无符完成又向转换。

解决办法是在命令行下执行 db2set DB2CODEPAGE=819

dos> db2set DB2CODEPAGE=819

然后,再次用 Quest Central for DB2 来连接数据库就 OK 啦

参考:1. SQL0332N Reason Code 1

JDBC 连接 Oracle 时,用 rs.absolute(n) 真的不如 n 次 next() 性能好

前面写过一篇:Oracle 驱动版本引起的显示字段奇怪编码问题。讲到因 Oracle 8.0.5 不支持子查询排序,为改善原来那种每次翻页时都捋出所有数据成对象到 List 中,然后从中拣取页面实际要显示的记录的性能问题时,采用了 rs.absolute() 直接跳到起始记录游标的方法,但又引入了乱码问题,例如:"无效",变成了 "0xE697A0E69588"。

虽说,换个驱动,如 8.1.7.0.0 以上版本的驱动就能解决乱码的问题,但这一换又怕会影响到其他的应用。有朋友评论说,其实循环 next() 到某处比 absolute() 定位要好,乍一看,有些牵强,不过试试就知道了。下面就来做样一个测试,测试代码如下: 阅读全文 >>

Oracle 驱动版本引起的显示字段奇怪编码问题

开门见山把产生问题的原因的解决办法列出来。

我们一般获取 Statement 都是通过 conn.createStatement() 方法,很少传递参数给它的,所以其内置属性都取默认值的,取记录只用 while(rs.next()) 逐个取即可。然而有一个需求(Oracle 8i 之前的版本不支持子查询排序,所以无法用 rownum 取分页记录) 是通过如下代码来得到 Statement:

Statement stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);

由它获得的结果集可以 rs.absolute(n) 直接跳到第 n 行记录来获得值,但就这个用法出问题了,取出来的中文出现乱码了,如 "无效",变成了 "0xE697A0E69588" 阅读全文 >>

Oracle SQL优化[转]

     Oracle SQL的优化规则:

  • 尽量少用IN操作符,基本上所有的IN操作符都可以用EXISTS代替

        用IN写出来的SQL的优点是比较容易写及清晰易懂,但是用IN的SQL性能总是比较低的,从ORACLE执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别:
       ORACLE 试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询。由此可见用 IN的SQL至少多了一个转换的过程。一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了。 阅读全文 >>

为何不直接使用 Oracle 提供的连接池实现

我在 Websphere Application Server (WAS) 下配置 JDBC 提供程序时,选择了 Oracle JDBC Driver 确定之后,看到最后一个选项是:oracle.jdbc.pool.OracleConnectionPoolDataSource。

顾名思义,这是一个 DataSource 实现为,就像 DBCP 的 BasicDataSource 一样。那么能不能也像 BasicDataSource 那样,通过 new BasicDataSource(),然后设置各个必须的属性得到一个数据源 DataSource 呢?这个 OracleConnectionPoolDataSource 又是在哪个包里呢? 阅读全文 >>

嵌入式数据库典型技术―SQLite和Berkeley DB的研究

摘 要: 与常见的数据库相比,嵌入式数据库具有体积小、功能齐备、可移植性、健壮性等特点,本文分析和比较了典型的嵌入式数据库SQLite和Berkeley DB。首先从体系结构、子系统间调用关系、任务执行过程等角度对SQLite和Berkeley DB进行了详细分析,然后重点从数据类型、存储方式、模式、数据库引擎和错误处理及加密功能等方面讨论了SQLite和Berkeley DB的异同点,最后列举了一个基于ARM—Linux的SQLite应用实例。

关键词: SQLite、Berkeley DB、SQL、虚拟数据库引擎(VDBE) 阅读全文 >>

开源嵌入式数据库 SQLite 简介

1、SQLite简介
SQLite 是 D. Richard Hipp 用 C 语言编写的开源嵌入式数据库引擎。SQLite第一个Alpha版本诞生于2000年5月. 至今已经有7个年头了.目前版本是 2007.6.18 出来没久的 SQLite 3.4.0

其创建者保守地估计 SQLite 可以处理每天负担多达 100,00 次点击率的 Web 站点,并且 SQLite 有时候可以处理 10 倍于上述数字的负载。

下面是访问SQLite官方网站: http://www.sqlite.org/ 时第一眼看到关于SQLite的特性. 阅读全文 >>

Hibernate从2升级到3不支持Oracle8外连接(+)的解决办法

最近接手了一个要维护的项目,是用Hibernate2+Oralce8写成的,因为看到Hibernate3页出来这么久了,而且也感觉Hibernate3有它的许多新的特性,如批量删除和更新,新的HQL语法解析器AST。

升级过程大致按照孙卫琴的那篇文章 如何把Hibernate2.1升级到Hibernate3.0?来做,该替换的替换完,该设置的设置完,程序一跑,当程序执行到向下面这种查询的时候(Oracle所特有的外连接查询),报错。

语句为:(描述为类似语句,把项目中的实际表名隐去了) 阅读全文 >>