Oracle数据库数据恢复、性能优化

找回密码
注册
搜索
热搜: 活动 交友 discuz
发新帖

133

积分

0

好友

17

主题
1#
发表于 2014-2-24 18:40:26 | 查看: 9534| 回复: 9
本帖最后由 saup007 于 2014-2-24 21:20 编辑

一张大表200G左右,有很多分区,子分区,怎么迁移能快一点?

我使用expdp、impdp,在expdp时,由于表结构太长,报BUG了,我就只expdp数据,表结构使用PL/SQL Developer导出来。

impdp时超慢的,可能因为有分区,而且还有子分区!

分区共有1647个,每个分区下有38个子分区,这张表共有62587个对象(select count(1) from dba_objects where object_name='' and owner=''

有其他方式迁移吗?

补充:

有使用并行、此表暂时没有索引。
2#
发表于 2014-2-25 13:49:54
是否考虑 传输表空间?

回复 只看该作者 道具 举报

3#
发表于 2014-2-25 14:54:49
Maclean Liu(刘相兵 发表于 2014-2-25 13:49
是否考虑 传输表空间?

表空间上,还有其他对象。

如果使用传输表空间,需要自包含,那这个用户下有二个表空间,用户名_USER01、用户名_INDEX01 都要迁移过去。

总共大概2个多T吧。目录服务器空间是有,但为了200G,要传输2T的数据文件过去吗,之后再把多余的删除?

我尝试 按分区导出,生成1647个dmp文件,之后按脚本impdp,效果可能比单独impdp快些吧(导出与导入一个空的分区需要12分钟,导入一个5Gdmp文件,需要1小时20分钟)

再尝试创建DB_LINK CREATE TABLE TABLE_NAME_1 PARALLEL(DEGREE 4) NOLOGGING AS SELECT * FROM TABLE_NAME_SOURCE@DBLINK WHERE 分区字段< 时间 and 分区字段 >= 时间 ,现在在测试这个需要多长时间。

新建的库,没有开归档、闪回等。

回复 只看该作者 道具 举报

4#
发表于 2014-2-25 15:15:19
本帖最后由 saup007 于 2014-2-25 15:17 编辑

其实我这次迁移,大概6张表,总量也1个T了,但其他都导完了,包括一个dmp 500G(只有分子,没有子分钟,而且分区并不多)的都导进去了,只剩下这一个了。

而且使用表空间迁移,因为有大概的表分区、子分区的,我怀疑表结构都导不出来。(之前这个200G的表,expdp导出的时候都报错了,我只有expdp 数据,表结构用PL/SQL Develop导出来的)

回复 只看该作者 道具 举报

5#
发表于 2014-2-25 15:18:20
这个是expdp 导出200G大小的表报的错(因为太多分区、子分区了)
  1. Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production


  2. Estimate in progress using BLOCKS method...
  3. Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
  4. Total estimation using BLOCKS method: 224.8 GB
  5. Processing object type TABLE_EXPORT/TABLE/TABLE
  6. Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT
  7. Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX
  8. Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
  9. Processing object type TABLE_EXPORT/TABLE/COMMENT
  10. Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
  11. ORA-39014: One or more workers have prematurely exited.
  12. ORA-39029: worker 1 with process name "DW01" prematurely terminated
  13. ORA-31671: Worker process DW01 had an unhandled exception.
  14. ORA-00600: internal error code, arguments: [kupfiWriteLob_1], [], [], [], [], [], [], []
  15. ORA-06512: at "SYS.KUPW$WORKER", line 1397
  16. ORA-06512: at line 2

  17. Job "DBA_LIUJINLIN"."SYS_EXPORT_TABLE_01" stopped due to fatal error at 18:28:50
复制代码

回复 只看该作者 道具 举报

6#
发表于 2014-2-25 16:45:24
I understand that expdp is failing when trying to export the statistics as
@ per the analysis done.  Customer is not willing to exclude the statistics.
@ .
@ If its very critical for this backup to happen, below workaround can be
@ tried:
@ .
@ ACTION PLAN
@ =============
@ 1. Exclude the statistics during the FULL DATABASE METADATA ONLY expdp dump
@ 2. And take the statistics backup seperately by following t he below step :
@ -- Create a STATS table
@                exec dbms_stats.create_stat_table(‘SYS’,’dictstattab’);
@ -- Export all the schema statistics to this table
@                exec
@ dbms_stats.export_schema_stats(‘<Schema>’,’dictstattab’,statsown=>’SYS’);
@ -- And then take a exp/expdp backup of that stats table(here backup will
@ happen for an object – table and not statistics)
@ .
@ In this way, as a workaround, customer will be having a backup of complete
@ metadata as well as backup of statistics for all the objects

回复 只看该作者 道具 举报

7#
发表于 2014-2-26 11:20:18
我乱想的,
是不是可以把某个分区导入到 新库的某个普通表中,然后再用分区交换的方式。

当然工作量可能很大

回复 只看该作者 道具 举报

8#
发表于 2014-2-26 23:48:29
确定表结构一点没变?  比如说新库中 添加了 新的分区 。
如果结构变了,会慢很多很多

回复 只看该作者 道具 举报

9#
发表于 2014-2-28 15:27:34
不了峰 发表于 2014-2-26 11:20
我乱想的,
是不是可以把某个分区导入到 新库的某个普通表中,然后再用分区交换的方式。

是的,最后就使用类似的方法。使用create table as select 使用并行,nologging

回复 只看该作者 道具 举报

10#
发表于 2014-2-28 15:28:57
psufnxk2000 发表于 2014-2-26 23:48
确定表结构一点没变?  比如说新库中 添加了 新的分区 。
如果结构变了,会慢很多很多 ...

表结构肯定没有变的,一致的。

我还想,把目标端表结构改了,只有分区,没有子分区,我expdp一个分区,impdp试了一下,特别奇怪,这个分区有4个子分区有数据,有2个最大的子分区报错,却有2个子分区导入进去了。奇葩。

回复 只看该作者 道具 举报

您需要登录后才可以回帖 登录 | 注册

QQ|手机版|Archiver|Oracle数据库数据恢复、性能优化

GMT+8, 2024-12-21 05:59 , Processed in 0.048042 second(s), 20 queries .

Powered by Discuz! X2.5

© 2001-2012 Comsenz Inc.

回顶部
TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569