oracle 10g import. 1

[TheDash]

Hi,

I am aware of the desupport of oracle 7.3.3.5 to 10g but will a full=y import ever work from 7.3.3.5 to 10g? I tried to do it, it worked but there are invalid objects. I tried many ways to compile them but they are still invalid.

 

[SantaMufasa]

Dash,

I have a few questions whose answers may allow us to do some thinking outside "The Box" to achieve your objective(s) [of getting your 7.3.3.5 data onto a 10g database].
[ul][li]How many tables, consuming how much space are needing migration to 10g?[/li][li]Do you have access to intermediate versions of Oracle databases (e.g., 8i or 9i)?[/li][li]Are your two databases (7.3.x source and 10g target) on the same network?[/li][li]Do you have proficiency with Oracle database links?[/li][/ul]

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm. The cost will be your freedoms and your liberty.”

 

[TheDash]

Santa,

Thanks for asking these. Here are the answers.

How many tables, consuming how much space are needing migration to 10g?

Answer: This was a no-data import from a no data export dump file. The export file itself is only 8MB.

Do you have access to intermediate versions of Oracle databases (e.g., 8i or 9i)?

Yes, I do have access to intermediate versions of Oracle database. (8i and 9i).

Are your two databases (7.3.x source and 10g target) on the same network?

They are on the same network.

Do you have proficiency with Oracle database links?

Thanks for this question from you... I do have proficiency with dblinks. The 7.3.3.5 database is on solaris and 10.2.0.3 is a windows system. I tried to import full=y from my PC and the export hanged at a user. That was where dblinks are created. I then did the import on the windows box itself and it worked without a problem. The dblinks were created by import process. Is it ok like that?

Is this a legitimate import.

One of my other concerns right now is the numerous invalid objects. Thanks..

 

[SantaMufasa]

Dash,

Under these circumstances, and if there is nothing to lose by doing so, I would:[ul][li]Empty out the target user schema(s) (to ensure a clean import)[/li][li]Import each schema using the "fromuser=<schema name> touser=<schema name>" clauses on your "imp" command line. (I.e., do not use the "full=y" clause.)[/li][/ul]In this way, you are able to isolate when/where import problems occur. You can also incrementally "fix" the invalid objects before you proceed to the next user schema. (If you are not familiar with methods of resolving "invalid" objects, let us know.)


Advise us of your findings/progress.

Mufasa
(aka Dave of Sandy, Utah, USA)
[I provide low-cost, remote Database Administration services: www.dasages.com]
“Beware of those that seek to protect you from harm. The cost will be your freedoms and your liberty.”

 

[TheDash]

Thank you. I have been told that since that is is a very old database the invalid objects are not of major concern. Thanks for your time and advise.