如何在不同的表空间中导入 Oracle 转储
我想将 oracle 转储导入到不同的表空间中。
我有一个由用户 A 使用的表空间 A。我已撤销该用户的 DBA 权限并授予他连接和资源权限。 然后我用命令转储了所有内容
exp a/*** 所有者=a file=oracledump.DMP log=log.log compress=y
现在我想将转储导入到用户 B 使用的表空间 B 中。所以我给了他连接和资源的授权(没有 DBA)。 然后我执行了以下导入:
imp b/*** file=oracledump.DMP log=import.log fromuser=a touser=b
结果是包含大量错误的日志:
IMP-00017:以下语句失败,出现 ORACLE 错误 20001:“BEGIN DBMS_STATS.SET_TABLE_STATS IMP-00003:遇到 ORACLE 错误 20001 ORA-20001: 输入值无效或不一致
此后,我尝试了相同的导入命令,但使用了选项 stats=none。 这导致了以下错误:
ORA-00959: 表空间“A_TBLSPACE”不存在
应如何完成此操作?
注意:很多列都是 CLOB 类型。 看来问题与此有关。
注2:oracle版本是9.2、10.1和10.1 XE的混合版本。 但我认为这与版本无关。
I want to import an oracle dump into a different tablespace.
I have a tablespace A used by User A. I've revoked DBA on this user and given him the grants connect and resource. Then I've dumped everything with the command
exp a/*** owner=a file=oracledump.DMP log=log.log compress=y
Now I want to import the dump into the tablespace B used by User B. So I've given him the grants on connect and resource (no DBA). Then I've executed the following import:
imp b/*** file=oracledump.DMP log=import.log fromuser=a touser=b
The result is a log with lots of errors:
IMP-00017: following statement failed with ORACLE error 20001: "BEGIN DBMS_STATS.SET_TABLE_STATS
IMP-00003: ORACLE error 20001 encountered
ORA-20001: Invalid or inconsistent input values
After that, I've tried the same import command but with the option statistics=none. This resulted in the following errors:
ORA-00959: tablespace 'A_TBLSPACE' does not exist
How should this be done?
Note: a lot of columns are of type CLOB. It looks like the problems have something to do with that.
Note2: The oracle versions are a mixture of 9.2, 10.1, and 10.1 XE. But I don't think it has to do with versions.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

发布评论
评论(10)
对我来说,这个工作正常(Oracle Database 10g Express Edition Release 10.2.0.1.0):
impdp B/B full=Y dumpfile=DUMP.dmp REMAP_TABLESPACE=OLD_TABLESPACE:USERS
但是对于新的恢复,您需要新的表
空间 也许有用 http://www.oracle-base.com/articles/10g/OracleDataPump10g .php
该问题与 CLOB 列有关。 看来imp工具无法重写create语句以使用另一个表空间。
资料来源: http://asktom .oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:66890284723848
解决方案是:
在正确的表空间中手动创建架构。 如果您没有用于创建架构的脚本,则可以使用 imp 工具的 indexfile= 创建它。
您必须自己禁用所有约束,oracle imp 工具不会禁用它们。
之后,您可以使用以下命令导入数据:
imp b/*** file=oracledump.dmp log=import.log fromuser=a touser=b stats=noneignore=y
注意:由于其他错误,我仍然需要statistics=none。
有关数据泵的额外信息
从 Oracle 10 开始,导入/导出得到了改进:数据泵工具 ([http://www.oracle-base.com/articles/10g/OracleDataPump10g.php][1] )
使用它将数据重新导入到新的表空间中:
首先为临时转储创建一个目录:
<块引用>
创建或替换目录临时转储为“/temp/tempdump/”;
授予对目录临时转储的读、写权限;导出:
<块引用>
expdp a/* schemas=a 目录=tempdump dumpfile=adump.dmp logfile=adump.log
导出
导入:
<块引用>
impdp b/* 目录=tempdump dumpfile=adump.dmp logfile=bdump.log REMAP_SCHEMA=a:b
导入
注意:转储文件是从服务器磁盘存储和读取的,而不是从本地(客户端)磁盘存储和读取的
我的解决方案是使用 GSAR 实用程序替换 DUMP 文件中的表空间名称。 当您执行replce时,请通过添加空格来确保转储文件的大小不变。
例如
gsar -f -s"TSDAT_OV101" -r"USERS " rm_schema.dump rm_schema.n.dump
gsar -f -s"TABLESPACE """USERS """ ENABLE STORAGE IN ROW CHUNK 8192 RETENTION" -r" " rm_schema.n1.dump rm_schema.n.dump
gsar -f -s"TABLESPACE """USERS """ LOGGING" -r" " rm_schema.n1.dump rm_schema.n.dump
gsar -f -s"TABLESPACE """USERS """ " -r" " rm_schema.n.dump rm_schema.n1.dump
我想改进不同服务器(数据库)上不同表空间中的两个用户
1。
首先为两台服务器(数据库)的临时转储创建一个目录:
服务器#1:
CREATE OR REPLACE DIRECTORY tempdump AS '/temp/old_datapump/';
GRANT READ, WRITE ON DIRECTORY tempdump TO old_user;
服务器#2:
CREATE OR REPLACE DIRECTORY tempdump AS '/temp/new_datapump/';
GRANT READ, WRITE ON DIRECTORY tempdump TO new_user;
2。
导出(服务器 #1):
expdp tables=old_user.table directory=tempdump dumpfile=adump.dmp logfile=adump.log
3.
导入(服务器#2):
impdp directory=tempdump dumpfile=adump_table.dmp logfile=bdump_table.log
REMAP_TABLESPACE=old_tablespace:new_tablespace REMAP_SCHEMA=old_user:new_user
答案很困难,但可行:
情况是:用户A和表空间X
- 将转储文件导入到不同的数据库中(仅当您需要保留副本时才需要这样做)原始表空间)
重命名表空间
alter tablespace X 重命名为Y
- < p>为expdp命令创建一个目录并授予权限
- 使用expdp创建转储
- 删除旧用户和旧表空间(Y)
- 创建新表空间 (Y)
- 创建新用户(使用新名称) - 在本例中为 B - 并授予权限(也可授予通过步骤 3 创建的目录)
使用 impdp 导入转储
impdp B/B directory=DIR dumpfile=DUMPFILE.dmp logfile=LOGFILE.log REMAP_SCHEMA=A:B
就是这样...
因为我想导入
(到 Oracle 12.1|2)一个从本地开发数据库 (18c xe) 导出
的转储,并且我知道我的所有目标数据库将有一个名为 DATABASE_TABLESPACE 的可访问表空间,我刚刚创建了我的架构/用户来使用该名称的新表空间,而不是默认的 USERS (我无权访问该表空间)在目标数据库上):
-- don't care about the details
CREATE TABLESPACE DATABASE_TABLESPACE
DATAFILE 'DATABASE_TABLESPACE.dat'
SIZE 10M
REUSE
AUTOEXTEND ON NEXT 10M MAXSIZE 200M;
ALTER DATABASE DEFAULT TABLESPACE DATABASE_TABLESPACE;
CREATE USER username
IDENTIFIED BY userpassword
CONTAINER=all;
GRANT create session TO username;
GRANT create table TO username;
GRANT create view TO username;
GRANT create any trigger TO username;
GRANT create any procedure TO username;
GRANT create sequence TO username;
GRANT create synonym TO username;
GRANT create synonym TO username;
GRANT UNLIMITED TABLESPACE TO username;
由此创建的 exp
使 imp
对我的目标感到满意。
---创建新表空间:
CREATE TABLESPACE TABLESPACENAME DATAFILE
'D:\ORACL\ORADATA\XE\TABLESPACEFILENAME.DBF' 大小 350M 自动扩展下一个 2500M 最大大小无限
记录
永恒的
范围管理本地自动分配
块大小 8K
段空间管理手册
闪回开启;
---然后使用以下命令导入
CREATE USER BVUSER IDENTIFIED BY VALUES 'bvuser' DEFAULT TABLESPACE TABLESPACENAME
-- 其中 D:\ORACL 是 oracle 安装路径
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
你这里有几个问题。
首先,您使用的不同版本的 Oracle 是导致表统计错误的原因 - 当我们的一些 Oracle 10g 数据库升级到版本 2 时,我遇到了同样的问题,而有些数据库仍在运行Release 1 和我在它们之间交换 .DMP 文件。
对我有用的解决方案是使用相同版本的
exp
和imp
工具在不同的数据库实例上进行导出和导入。 最简单的方法是使用同一台 PC(或 Oracle 服务器)发出所有导出和导入命令。其次,我怀疑您收到
ORA-00959:表空间'A_TBLSPACE'不存在
,因为您正在尝试从成熟的数据库导入.DMP文件Oracle 数据库集成到 10g Express Edition (XE) 数据库中,默认情况下,该数据库会为您创建一个名为USERS
的预定义表空间。如果是这种情况,那么您需要执行以下操作。
使用 .DMP 文件创建一个包含结构(表)的 SQL 文件:
imp/<密码>@XE file=<文件名.dmp>; indexfile=index.sql full=y
在文本编辑器中打开索引文件(index.sql),该编辑器可以对整个文件进行查找和替换,并按顺序发出以下查找和替换语句(忽略单引号..'):
查找:'REM<空格>' 替换:<无>
查找:'""' 替换:'"USERS"'
查找:'...' 替换:'REM ...'
查找:'CONNECT' 替换:'REM CONNECT'
保存索引文件,然后针对您的 Oracle Express Edition 帐户运行它(我发现最好创建一个新的、空白 XE 用户帐户 - 或者如果我要刷新,则删除并重新创建):
sqlplus/@XE @index.sql
最后运行相同的 .您使用同一帐户创建索引文件的 DMP 文件,用于导入数据、存储过程、视图等:
imp/<密码>@XE file=<文件名.dmp>; fromuser=<原始用户名>; touser=; ignore=y
时,您可能会收到 Oracle 错误页面,因为 Oracle 将尝试使用相同的数据库标识符,这很可能会失败,因为您位于不同的数据库上。
You've got a couple of issues here.
Firstly, the different versions of Oracle you're using is the reason for the table statistics error - I had the same issue when some of our Oracle 10g Databases got upgraded to Release 2, and some were still on Release 1 and I was swapping .DMP files between them.
The solution that worked for me was to use the same version of
exp
andimp
tools to do the exporting and importing on the different Database instances. This was easiest to do by using the same PC (or Oracle Server) to issue all of the exporting and importing commands.Secondly, I suspect you're getting the
ORA-00959: tablespace 'A_TBLSPACE' does not exist
because you're trying to import a .DMP file from a full-blown Oracle Database into the 10g Express Edition (XE) Database, which, by default, creates a single, predefined tablespace calledUSERS
for you.If that's the case, then you'll need to do the following..
With your .DMP file, create a SQL file containing the structure (Tables):
imp <xe_username>/<password>@XE file=<filename.dmp> indexfile=index.sql full=y
Open the indexfile (index.sql) in a text editor that can do find and replace over an entire file, and issue the following find and replace statements IN ORDER (ignore the single quotes.. '):
Find: 'REM<space>' Replace: <nothing>
Find: '"<source_tablespace>"' Replace: '"USERS"'
Find: '...' Replace: 'REM ...'
Find: 'CONNECT' Replace: 'REM CONNECT'
Save the indexfile, then run it against your Oracle Express Edition account (I find it's best to create a new, blank XE user account - or drop and recreate if I'm refreshing):
sqlplus <xe_username>/<password>@XE @index.sql
Finally run the same .DMP file you created the indexfile with against the same account to import the data, stored procedures, views etc:
imp <xe_username>/<password>@XE file=<filename.dmp> fromuser=<original_username> touser=<xe_username> ignore=y
You may get pages of Oracle errors when trying to create certain objects such as Database Jobs as Oracle will try to use the same Database Identifier, which will most likely fail as you're on a different Database.