oracle imp-00017 3113,exp imp 常见问题解决

为了使测试与生产数据保持一致，只需要导出数据的时候，可以将测试库的表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以及以下版本不支持导出含LOBs对象的表；不能使用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后暂时解决了这个问题

导入的时候一直报违反外键约束,触发器发生错误等。解决方法有二,一是在导数前手工disable掉所有的触发器和外键约束,二是直接全schema导入,不要分两遍导。

IMP-00058: ORACLE error 3113 encountered

ORA-03113: end-of-file on communication channel

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

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导入不进去。

所以跨平台导测试库，即浪费时间，效果也不好。