oracle中copy from的用法

1.语法及使用说明
1.1 语法
下面我们来看一下SQL*Copy Command的语法及使用说明。
在解释SQL*Plus Copy Command的语法之前，我们必须要明确SQL*Plus Copy Command不是一个方法或是函数，也不是一个SQL语句，它是一个命令(command)，当然这个命令必须在SQL*Plus里运行。

SQL*Plus Copy Command的语法：
COPY {FROM database | TO database | FROM database TO database} {APPEND|CREATE|INSERT|REPLACE} destination_table [(column, column, column, ...)]
USING query

我们分部分来解释一下：

COPY – 这个不太需要解释，主命令，声明要执行COPY操作

From Database – 源数据库
To Database – 目标数据库
此处注意花括号中有三种可选的写法(以”|”隔开)，如果源数据表和目标数据表在同一个Schema中，则可以只写From Database，也可以只写To Database，当然还可以是第三种写法，把From Database和To Database写全。但如果源数据表和目标数据表不在同一个Schema中，则必须用第三种写法，即把From Database和To Database都写全
From Database和To Database的格式是一样的：USERID/PASSWORD@SID，这个大家都应该很熟悉了。

{APPEND|CREATE|INSERT|REPLACE} – 声明操作数据的方式，下面分别解释一下：
Append – 向已有的目标表中追加记录，如果目标表不存在，自动创建，这种情况下和Create等效。
Create – 创建目标表并且向其中追加记录，如果目标表已经存在，则会返回错误。
Insert – 向已有的目标表中插入记录，与Append不同的是，如果目标表不存在，不自动创建而是返回错误。
Replace – 用查询出来的数据覆盖已有的目标表中的数据，如果目标表不存在，自动创建。

destination_table – 目标表的名字
[(column, column, column, ...)] – 可以指定目标表中列的名字，如果不指定，则自动使用Query中的列名。
USING query – 查询语句，交流的数据来自这儿。


备注:

1.这种方法适合小额数据的迁移,只能在SQL*PLUS中运行.

2.这种方法不能copy大对象的表,不然会抛异常"CPY0012: Object datatypes cannot be copied"

转载

在数据表间复制数据是Oracle DBA经常面对的任务之一，Oracle为这一任务提供了多种解决方案，SQL*Plus Copy 命令便是其中之一。SQL*Plus Copy 命令通过SQL*Net在不同的表(同一服务器或是不同服务器)之间复制数据或移动数据。
　在实际运行环境中若能恰当地选择使用SQL*Plus Copy 命令可以有效地提高数据复制的性能。
　下面将简要介绍SQL*Plus Copy 命令使用，并在性能方面与其他两种方案进行对比，力求能提供一个使用Copy 命令的方案参考。
1.语法及使用说明
1.1 语法
下面我们来看一下SQL*Copy 命令的语法及使用说明。
在解释SQL*Plus Copy 命令的语法之前，我们必须要明确SQL*Plus Copy 命令不是一个方法或是函数，也不是一个SQL语句，它是一个命令(command)，当然这个命令必须在SQL*Plus里运行。 

中国网管联盟bitsCN.com

 

SQL*Plus Copy 命令的语法： 
网管联盟bitsCN_com


COPY {FROM database | TO database | FROM database TO database} {APPEND|CREATE|INSERT|REPLACE} destination_table [(column, column, column, ...)]
USING query 


我们分部分来解释一下：

COPY – 这个不太需要解释，主命令，声明要执行COPY操作

From Database – 源数据库
To Database – 目标数据库
　此处注意花括号中有三种可选的写法(以”|”隔开)，如果源数据表和目标数据表在同一个Schema中，则可以只写From Database，也可以只写To Database，当然还可以是第三种写法，把From Database和To Database写全。但如果源数据表和目标数据表不在同一个Schema中，则必须用第三种写法，即把From Database和To Database都写全
　From Database和To Database的格式是一样的：USERID/PASSWORD@SID，这个大家都应该很熟悉了。 网管网www_bitscn_com 

{APPEND|CREATE|INSERT|REPLACE} – 声明操作数据的方式，下面分别解释一下：
Append – 向已有的目标表中追加记录，如果目标表不存在，自动创建，这种情况下和Create等效。
Create – 创建目标表并且向其中追加记录，如果目标表已经存在，则会返回错误。
Insert – 向已有的目标表中插入记录，与Append不同的是，如果目标表不存在，不自动创建而是返回错误。
Replace – 用查询出来的数据覆盖已有的目标表中的数据，如果目标表不存在，自动创建。

destination_table – 目标表的名字
[(column, column, column, ...)] – 可以指定目标表中列的名字，如果不指定，则自动使用Query中的列名。
USING query – 查询语句，交流的数据来自这儿。

1.2 使用范例
下面我们通过几个例子来看一下SQL*Plus Copy 命令的使用：

1.2.1 在同一个服务器的同一个Schema中复制数据：
同时指定From database和To database
SQL> copy from scott/tiger@lsj to scott/tiger@lsj create dept1 using select * from dept;
只指定From Database 
SQL> copy from scott/tiger@lsj create dept2 using select * from dept; 中国网管联盟bitsCN.com 
只指定To Database 
SQL> copy to scott/tiger@lsj create dept3 using select * from dept;

1.2.2 在同一个服务器的不同Schema中复制数据：
这种情况下必须同时指定From Database和To Database
SQL> copy from scott/tiger@lsj to lsjdemo/lsjdemo@lsj create dept using select * from dept;
注意这种情况下，using select * from dept 中并不需要使用scott.demp的形式。

1.2.3 在不同的服务器间复制数据：
SQL> conn lsj/lsj@sunserve
已连接。
SQL> copy from scott/tiger@lsj to lsj/lsj@sunserve create dept using select * from dept;
2.4 性能实验结果
实验数据：
记录数：5,082,500
数据量：504M
实验结果

方案------------------------执行时间(秒) ---------Undo(M) ------Redo(M)
Copy command -------------520.51----------------------0 ---------------- 592
Insert into…select …---- 631.64 ------------------345 -------------1720 

网管论坛bbs_bitsCN_com


Create Table…------------- 244.79 --------------------0 ----------------515

2.总结

　Create Table…as select…是最快的，而且生成的Undo和Redo信息最少，所以只要可能，请尽量使用这种方案。但这种方案有一定的限制，即目标表必须是不存在的，不能用它向已有的目标表中追加记录。
　Insert into … select … 是最慢的，而且生成最多的Undo和Redo信息，对I/O的压力最大，优势在于大家对它比较熟悉，使用起来比较简单，适合于处理少量的数据，若要处理大量的数据，不推荐使用这种方案。
　Copy Command可以处理Create Table不能处理的情况，即向已有的数据表中追加记录，相对于insert来说，效率更高一些，生成更少的Redo信息，不生成Undo信息，所以在执行大量的数据追加时，推荐使用Copy Command命令。


本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/yanleigis/archive/2008/10/13/3066942.aspx