Migration problem 7.2.3 to 8.0.5

Question

I keep getting an error in the same place when trying to do an
import of a database. Checked tablespace sizes, and we are doing
a local import. Did 2 seperate exports, and same problem, both
import and export as 'system'..
IMP-00017: following statement failed with ORACLE error 3113:
"GRANT SELECT ON "V_AR" TO "SELECT_ON_ALL""
IMP-00003: ORACLE error 3113 encountered
ORA-03113: end-of-file on communication channel
IMP-00000: Import terminated unsuccessfully
This is a select on a view..
Anyone care to elucidate on possible causes for this ??
The Import is started as
imp system/manager log=imp.log commit=y file=expdat.dmp fu
ll=y
null

Answer 1

Michael Peddemors (guest) wrote:
: I keep getting an error in the same place when trying to do an
: import of a database. Checked tablespace sizes, and we are
doing
: a local import. Did 2 seperate exports, and same problem, both
: import and export as 'system'..
: IMP-00017: following statement failed with ORACLE error 3113:
: "GRANT SELECT ON "V_AR" TO "SELECT_ON_ALL""
: IMP-00003: ORACLE error 3113 encountered
: ORA-03113: end-of-file on communication channel
: IMP-00000: Import terminated unsuccessfully
: This is a select on a view..
: Anyone care to elucidate on possible causes for this ??
: The Import is started as
: imp system/manager log=imp.log commit=y file=expdat.dmp fu
: ll=y
I just upgraded from 7.2.3 to 7.3.4. The initial full import to
7.3.4 failed since the crdb<SID>.sql and crdb2<SID>.sql scripts
created temp and rollback tablespaces that did not match the
names that had been given to the 7.2.3 system. Yes, could have
changed the names in 7.3.4 to conform to the 7.2.3 but I am
looking ahead to upgrading to 8.x sometime this year. 7.3.4
appears to be more like 8 than 7.2.3 in terms of file
organization and default data file locations. Hopefully, when it
is time to move to 8 the move will be smoother.
I have a script that creates my tablespaces. I then created the
schemas in the 7.3.4 system. The last step was to import using a
parameter file which did a by user import. This was a lot of
work, but it also did not load the new system with old tables
that had been left hanging around. There will be cleanup work
needed taking this approach, but the end result should be a
cleaner database in the long run.
null