--脚本代码
脚本a.sql：
spool ./a.log
select * from dual;
spool off
脚本b.sql：
spool ./b.log
select * from dual;
spool off
脚本all.sql：
spool ./all.log
@@./a.sql
@@./b.sql
spool off
--开始测试
--先进入cmd，然后切换到d盘
C:\Documents and Settings\zhs>d:
--进入文件所在目录
D:\>cd D:\zhs\test
--显示脚本文件
D:\zhs\test>tree /f
文件夹 PATH 列表
卷序列号码为 0006EE50 60AF:FBA0
D:.
│ a.sql
│ all.sql
对于单纯的导数据，经验证，比impdp命令还快。
但是，一般企业禁用dblink方式。
主要原因是：
1、一般开发不会关会话，使用后不关闭导致session过多而影响系统
2、dblink没有详细的日志记录，出了问题不易排查，一般的操作都是有现成的同步方式或工具的，所以为了节省问题处理时间，采用现成的更可靠。
对于关闭dblink产生的session，有如下文章可参考。
抄自：http://blog.itpub.net/9932141/viewspace-631509/
db-link session在基于连接池的管理中可能会引起目标管理系统的Session
zhsimptaccoinfo.sql是使用copy命令的数据迁移脚本：
spool ./copy.log
Set copycommit 1000;
Set arraysize 100;
copy from user/pwd@sid to user/pwd@sid INSERT copy(id,...) USING
select id,... from copy;
spool off
迁移的表字段极多，开始没换行，导致报
SP2-0027: Input is too long (> 2499 characters) - line
ignored
然后按网上的方式，把copy拆为多行，copy需要在换行后面加-
spool ./copy.log
Set copycommit 1000;
Set arraysize 100;
copy from user/pwd@sid to user/pwd@sid INSERT copy(id,...) -
USING select id,... from copy;
spool off
结果报了如下错误
SQL> @zhsimptaccoinfo.sql
SP2-0027: Input is too long (> 2499 characters) - line
ignored
Array fetch/bind size is 100. (arraysize is 100)
Will commit after every 1000 array binds. (copycommit is
1000)
Maximum long size is 80. (long is 80)
SP2-0502:
SP2-0503:
(2016-07-07 17:36)
ORA-38307: object not in RECYCLE BIN
环境:Oracle Database 10g Enterprise Edition Release
10.2.0.3.0
1.查询回收站有那些信息
select object_name ,type,original_name from user_recyclebin
2.清除回收站中的相关内容
--彻底删除表purge table origenal_tableName
--彻底删除索引purge index origenal_indexName
--完全删除回收站中的内容
purge recyclebin
一种情况是,当purg某个表或索引的时候,如果表或者索引的名字不在recyclebin中就会出现ORA-38307,可以尝试将回收站中的信息全部清楚来处理
以上抄自：http://blog.itpub.net/15720542/viewspace-626248/
有个用了几年的过程，今天突然报了这个问题，查看代码，对临时表是这么写的：
truncate table a;
drop table a;
purge table a;
然后把这3个语句拿到plsql执行，一样报错。
改为下面就没问题：
drop table a purge ;
执行完过程之后恢复代码，毕竟用了几年。具体原因不祥
有这么个update语句
update A t
set status =
1
where exists (select 1
from B B
where B.code = A.code)
因性能问题需要修改写法。
在oracle10G这么update是没问题的：
update(
select
A.status,1 t_status
&
在做spring＋mybatiss时，自动扫描都配置正确了，却在运行时出现了如下错误。后来查看target/classes/.../dao/文件夹下，发现只有mapper的class文件，而没有xml文件，将对应的xml文件放到这个文件夹下运行就不会出现下面的错误。说明出现这个错误的原因是maven编译时没有将xml文件放进去。
解决方法：
在pom.xml中添加如下代码：
src/main/java
**/*.xml
&nbs
往表里插数据时报以下错误：
[jcc][t4][102][10040][3.57.82]
非原子批处理出现故障。虽然已经提交了批处理，但是该批处理的某个成员至少发生了一个异常。使用 getNextException()
来检索已经过批处理的特定元素的异常。 ERRORCODE=-4228, SQLSTATE=null
原因：长度不够，将长度为200的数据插入varchar（20）的列。
其实这个问题是以前同一个客户遇见的问题，当时一个工程师解决后记录的过程如下：
应用同事反映但是对应到执行存储过程，执行了2，3个小时了，还没出来结果。
存储过程主要是执行一条update sql语句，单独将语句拿出来，clp命令行执行很快，2－3s即可执行完成。
执行的SP：
call pdw.P_OCS_ACTIVE_UPDATE('20120304',?)
存储过程主要业务SQL：
SET vn_Step=1;--
call papp.p_debug(txdate,vn_PrcName,vn_Step,vv_sql); --
UPDATE PODS.T_ODS_PAR_CUSTMSG a
SET run_code='UU'
WHERE sm_code in ('o3','os','om','ol','ox') AND NOT EXISTS
(SELECT * FROM PODS.T_ODS_PAR_OCSACTIVEMSG b where
a.ID_NO=b.ID_NO );
COMMIT;--
根据了解，这个存储过程有些时候了，最近无改动，以前都正常。
根据具体情况，第一反应是这个存储过程中语句的执行计划不正确了。静态sql的访问计划是在第一次编译后存储在数据库的包中的，之后运行都
典型的 DB2 数据转移任务涉及三个步骤：
把数据以二进制或文本格式从源数据库导出到一个临时数据交换文件,在系统之间转移生成的文件,把数据从文件导入或装载到目标数据库中.
使用 DB2 LOAD 实用程序的 FROM CURSOR 选项简化 DB2? for Linux?, UNIX?, and
Windows? 的数据转移过程。本文介绍 LOAD FROM CURSOR 特性并提供两个接口 Command Line
Processor 和 ADMIN_CMD 存储过程的使用示例。
典型的 DB2 数据转移任务涉及三个步骤：
把数据以二进制或文本格式从源数据库导出到一个临时数据交换文件
在系统之间转移生成的文件
把数据从文件导入或装载到目标数据库中
在数据量很大的情况下，使用 EXPORT
实用程序生成数据交换文件常常要花费很长时间。另外，在把数据移入和移出数据库时，必须考虑不同的数据库编码页和操作系统。
可以使用 LOAD 实用程序的 FROM CURSOR 选项避免这些问题。当指定 FROM CURSOR 选项时，LOAD
实用程序直接把一个 SQL 查询的结果集作为数据装载操作的来源，这样就不需要生成临时数据交换文件。因此，LOAD FROM
CURSOR 是在不同的表空间或数据库之间快速
加载中…
转载▼