Oracle exp imp 常见问题解决

傷城~ 2022-08-18 01:00 577阅读 0赞

今天在ITPub中看到一篇不错的Oracle文章，想着以后是会有用的先转过来留作备用，感谢大神beyond\_sea的分享。

文章转自：[http://blog.itpub.net/7532565/viewspace-586778][http_blog.itpub.net_7532565_viewspace-586778]

为了使测试与生产数据保持一致，只需要导出数据的时候，可以将测试库的表truncate，保留其它如索引，trigger，constraints，grants等不用再重新导。

exp时候rows=y，其它全部选n  
imp时候rows=y，其它选n

ignore：是否忽略创建错误。

Oracle在恢复数据的过程中，当恢复某个表时，该表已经存在，就要根据ignore参数的设置来决定如何操作。  
若ignore=y，Oracle不执行CREATE TABLE语句，直接将数据插入到表中，如果插入的记录违背了约束条件，比如主键约束，则出错的记录不会插入，但合法的记录会添加到表中。

若ignore=n，Oracle不执行CREATE TABLE语句，同时也不会将数据插入到表中，而是忽略该表的错误，继续恢复下一个表。（当索引与数据rows要分两次导入时候，导入索引时候要指定ignore=y，否则索引导不进去。

当数据库中已经有要导入的表，并且表中已经存在一些数据时候，如果不覆盖这些数据，append导入数据到这个表，直接指定ignore=y即可）

当表中有long或者lob类型的字段时候，imp的时候对这个表单独imp，要加commit=n，导完一张表提交一次，这样会比加commit=y快。

对含有long或者lob类型字段的表imp时候，加了commit=y，由于long字段很大，数据缓冲很快就会满，每插入一行就会commit一次。导致很频繁的提交，imp会等待log file sync，导致导入很慢。

show parameter filesystemio_options --应该为setall

~~~~~~~~~~~~  
导入导出BLOB数据  
~~~~~~~~~~~~  
可以用IMP/EXP  
条件：  
1. 导入时要确保有该BLOB字段的列的表还未建起来。  
2. 在EXP/IMP中参数中指定BUFFER到一定的值，内存必须足够容纳一次预取一行的数据量，有写LOB列可能达到2G。

**加快exp速度：**

direct=y (常规路径导出使用sql select语句从表中取出数据，直接路径导出则将数据直接从硬盘读到pga然后写入导出文件） recordlength=65535 (定义了export i/o缓冲的大小，类似于常规路径导出的buffer参数）

直接路径导出的限制：8i以及以下的版本不支持导出客户端和数据库的字符集转换，因此导出前要保证NLS\_LANG参数设置正确；  
815以及以下版本不支持导出含LOB对象的表；不能使用query参数）

**加快imp速度：**

加大temp表空间。  
sort\_area\_size 加大，注意这个参数是每个会话的大小。buffer=102400000 （定义了每一次读取导出文件的数据量）commit=y (表示每个数据缓冲满了之后提交一次，而不是导完一张表提交一次，减少对系统回滚段等资源的消耗）  
第一次导入数据，rows=y,indexes=n  
第二次导入索引，rows=n,indexes=y

consistent如果指定为Y则所有导出的数据都是一致的，如果为N（为默认值）则只保证单个表中数据的一致性。

imp导入时候总报回滚表空间无法扩展，指定commit=y，加大buffer 解决。

**统计信息的导出和导入：**

EXP-00091: Exporting questionable statistics.

解决方法：exp的時候加了STATISTICS=NONE 或者imp的时候指定RECALCULATE\_STATISTICS=y 不导出统计信息，或者导入时候加上重新收集统计信息。

根本解决方法：  
导出的时候重新设置环境变量  
这个问题当前的环境变量NLS\_LANG设置与数据库的不相同。

NLS_LANG=AMERICAN_AMERICA.数据库实际值
    export NLS_LANG

第一遍导结构时导入一遍后，在导数据时会报ORA-20005错，显示该统计信息被锁定，加了statistics=none后暂时解决了这个问题。  
导入的时候一直报违反外键约束，触发器发生错误等。  
解决方法有二  
1. 在导数前手工disable掉所有的触发器和外键约束  
2. 直接全schema导入,不要分两遍导。

IMP-00058: ORACLE error 3113 encountered
    ORA-03113: end-of-file on communication channel

如果第一次导入时，部分表没有导入，可以指定表名和owner来只导入部分表：

userid=username/password@dbname
    file=(exp01.dmp,exp02.dmp,exp03.dmp,exp04.dmp,exp05.dmp,exp06.dmp,exp07.dmp,exp08.dmp,exp09.dmp,exp10.dmp,exp11.dmp,exp12.dmp,exp13.dmp,exp14.dmp,exp15.dmp,exp16.dmp,exp17.dmp,exp18.dmp,exp19.dmp,exp20.dmp,exp21.dmp,exp22.dmp,exp23.dmp,exp24.dmp,exp25.dmp,exp26.dmp,exp27.dmp,exp28.dmp,exp29.dmp,exp30.dmp,exp31.dmp,exp32.dmp,exp33.dmp,exp34.dmp,exp35.dmp,exp36.dmp,exp37.dmp,exp38.dmp,exp39.dmp,exp40.dmp,exp41.dmp,exp42.dmp,exp43.dmp,exp44.dmp,exp45.dmp)
    fromuser=appdata
    touser=hubei
    tables=()
    rows=y
    commit=y             
    grants=n
    indexes=n
    constraints=n
    RECALCULATE_STATISTICS=y
    IGNORE=y
    log=imp2.log
    buffer=80000000

**Import物化视图基表时导致严重的Latch Free**

最近在使用imp恢复一个表的数据的时候，发现虽然imp数据到同一个库中的另外一个用户下的临时表，但是却导致了原用户下的该表上sql执行时都产生了非常多的latch free等待，严重影响到了应用的正常运行。

检查发现原用户下的表上LAST\_DDL\_TIME有变化，而最近也没得该表作什么DDL操作。而由于LAST\_DDL\_TIME更新了，导致对表上的所有sql都要重新解析，从而执行时都在等待latch free。

进行测试，发现如果exp时基表上没有mview log，则imp到另外用户下的临时表时不会对原表的LAST\_DDL\_TIME作修改，反之就会更新该时间，进而导致重新解析所有相关的SQL。

imp时如果dmp文件中带有mview log的创建语句，则在数据导入完成后会执行mview log数据的更新，但是由于本身mview log这个表不存在，所以就会提示错误信息：

ORA-06512: at line 1
    IMP-00017: following statement failed with ORACLE error 942:
     "BEGIN SYS.DBMS_SNAPSHOT_UTL.SYNC_UP_LOG('OWNER','TABLE NAME'); END;"
    IMP-00003: ORACLE error 942 encountered
    ORA-00942: table or view does not exist
    ORA-06512: at "SYS.DBMS_SNAPSHOT_UTL", line 1589
    ORA-06512: at line 1

在export/import中，经常遇到卷空间不足或者表空间不足的问题，不得不重新开始，浪费比较多的时间和人力。

9i及10g，对于export/import使用下面三个参数，可以在出现问题的时候，将export/import作业挂起来。等问题解决后，继续进export/import，而不用重新开始。

RESUMABLE：        y 或者 n，控制是否作业可以继续 
    RESUMABLE_NAME：   挂起作业名称 
    RESUMABLE_TIMEOUT：作业挂起多长时间后，中止作业。
                       默认超时时间为7200秒,也就是2小时。

使用中，设置RESUMABLE=y，并给RESUMABLE\_NAME一个名字，设置RESUMABLE\_TIMEOUT为比较长的时间（我一半设置100个小时）。  
在export/import过程中，定时查询dba\_resumable视图，可以看到设置了resumable的作业信息。

如果作业没有挂起，ERROR\_NUMBER 列为0，ERROR\_MSG列为空。当出现错误的时候，ERROR\_NUMBER为相应的错误代码，ERROR\_MSG为具体的错误信息。

根据ERROR\_MSG信息，解决问题后，export/import作业会自动继续进行。

RESUMABLE=y
    RESUMABLE_NAME=imp_lu001
    RESUMABLE_TIMEOUT=720000

full imp之后，执行脚本授权，编译失效对象：

select object_type,count(*) from dba_objects where status='INVALID' group by object_type;

恢复所有的权限：

select 'grant ' ||privilege||' on ' || owner||'.'||table_name || ' to '|| grantee || ';' from  dba_tab_privs;
    
    select 'grant ' ||granted_role|| ' to '|| grantee || ';' from  dba_role_privs;
    
    select 'grant ' ||privilege|| ' to '|| grantee || ';' from  dba_sys_privs;
    
    select 'grant ' ||privilege||' on ' || owner||'.'||table_name || ' to '|| grantee || ' with grant option;' from  dba_tab_privs where GRANTABLE='YES';
    
    select 'grant ' ||granted_role|| ' to '|| grantee || ' with admin option;' from  dba_role_privs where ADMIN_OPTION='YES';
    
    select 'grant ' ||privilege||' to '|| grantee || ' with admin option;' from  dba_sys_privs where ADMIN_OPTION='YES';

编译失效过程：

select 'alter '||OBJECT_TYPE||' '||OWNER||'.'||OBJECT_NAME||' compile;' from dba_objects where status='INVALID' and object_type='PROCEDURE';

编译失效公共同义词：

select 'alter public '||OBJECT_TYPE||' '||OBJECT_NAME||' compile;' from dba_objects where status='INVALID' and object_type='SYNONYM';

编译失效对象：

set linesize 151 set wrap on set space 1 set feedback off set timing off set pause off set term off set heading off set recsep off set pagesize 0 set verify off spool alt_pkg.sql select 'PROMPT ALTER '||decode(object_type,'PACKAGE BODY','PACKAGE ',object_type||' ') ||owner||'.'||object_name ||' COMPILE'||decode(object_type,'PACKAGE BODY',' BODY;',';')||chr(10)||'ALTER '||decode(object_type,'PACKAGE BODY','PACKAGE ',object_type||' ')||owner||'.'||object_name ||' COMPILE'||decode(object_type,'PACKAGE BODY',' BODY;',';') from dba_objects where status ='INVALID' order by object_type;
    
    spool off
    set feedback on set timing on set term on set heading on set recsep WRAP set pagesize 14 set verify on @@./alt_pkg exit

１. 先根据appdata用戶下的view相关的同义词生成指向表的脚本同义词。

spool 1.sql

create or replace public synonym '||synonym_name||' for '||owner||'.'||synonym_name||';'　
    from dba_synonyms 
    where table_owner='APPDATA' 
      and table_name like '%_VW';

spool 2.sql

create or replace public synonym '||synonym_name||' for '||owner||'.'||table_name||';'　
    from dba_synonyms 
    where table_owner='appDATA' 
      and table_name like '%_VW';

spool off

２. 创建指向表的同义词,运行１.sql。

３. 重导applog用户，不导数据，导入表跟sequence的时候会报错，可以忽略。

４. 重建appdata相关的公共同义词，运行２.sql。

8i 每个版本的数据exp/imp 操作都会遇到这个问题，以下是我们10g升级中规避这个问题的方法，还比较有效：  
（1）先导一次结构。  
（2）在applog用下建立被公有同义词指向view的同名的私有同义词，直接指向基表， (有公共同义词，有私有同义词，会先引用私有同义词）  
提取脚本如下：

spool create\_syn.sql

select 'create synonym applog.'||synonym_name||' for appdata.'||synonym_name||';' from dba_synonyms where table_owner='APPDATA' and wner='PUBLIC' and synonym_name<>table_name and table_name in ( select object_name from dba_objects where wner='APPDATA' and object_type='VIEW' );

spool off

执行提取出来的脚本。  
（3）开始进行导入，应该不会遇到trigger创建失败的情形了。  
（4）导入完成 后，利用以下脚本抽取删除这些增加的私有同义词脚本，执行之。

spool drop\_syn.sql

select 'drop synonym applog.'||synonym_name||';' from dba_synonyms where table_owner='appDATA' and wner='PUBLIC' and synonym_name<>table_name and table_name in ( select object_name from dba_objects where wner='appDATA' and object_type='VIEW' );

spool off

这次导库之后缺少很多trigger的原因是导入时报错ora－25001：

ORA-25001: cannot create this trigger type on views

需要到导入log文件查询是哪个表上的哪个trigger，进而查询和该表同名的公共或私有同义词是否指向了视图，指向了视图会导致无法在视图上创建trigger。  
可能的原因是，在源数据库，该trigger是建立在table上的，建完trigger以后，创建了一个和该table同名的同义词，指向却是某个视图。  
需要到源数据库拷贝trigger代码，在table前面加上owner.，绕过同义词，直接在table上创建该trigger。

经过在生产库查询，确实是因为源库上和这些trigger相关的表的公共同义词建立在了view上，这样导入的时候就不可避免的这些trigger导入不进去。  
所以跨平台导测试库，即浪费时间，效果也不好。

[http_blog.itpub.net_7532565_viewspace-586778]: http://blog.itpub.net/7532565/viewspace-586778