 | |
#41
 
| |||
| |||
|
Re: 9iR2 exp -> 10g imp -
06-11-2008
, 01:17 PM
|
Noons wrote: On Jun 8, 3:12 am, jeremy <jeremy0... (AT) gmail (DOT) com> wrote: might be a good idea to use also destroy=n... Oh I looked through the documentation and couldn't find that one - which manual is it in? the utilities. Also in the command line, if you type "imp help=yes" you'll see most of the commands available. the default is "n", but I've long ceased to believe in "defaults", so I include it anyway. And since you're considering using FULL=YES, tablespaces become relevant. I have had great success using a combination of fingerscrossed=yes with asifbymagic=always _hyper-speed=yes is also a good one to try, but in the spfile only! FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. |
this technique to upgrade, I would be very interested. (I'm about to
do exactly that)
TIA,
Arch
#42
| |||
| |||
|
|
Noons wrote: On Jun 8, 3:12 am, jeremy <jeremy0... (AT) gmail (DOT) com> wrote: might be a good idea to use also destroy=n... Oh I looked through the documentation and couldn't find that one - which manual is it in? the utilities. Also in the command line, if you type "imp help=yes" you'll see most of the commands available. the default is "n", but I've long ceased to believe in "defaults", so I include it anyway. And since you're considering using FULL=YES, tablespaces become relevant. I have had great success using a combination of fingerscrossed=yes with asifbymagic=always _hyper-speed=yes is also a good one to try, but in the spfile only! FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. |
this technique to upgrade, I would be very interested. (I'm about to
do exactly that)
TIA,
Arch
#43
| |||
| |||
|
|
Noons wrote: On Jun 8, 3:12 am, jeremy <jeremy0... (AT) gmail (DOT) com> wrote: might be a good idea to use also destroy=n... Oh I looked through the documentation and couldn't find that one - which manual is it in? the utilities. Also in the command line, if you type "imp help=yes" you'll see most of the commands available. the default is "n", but I've long ceased to believe in "defaults", so I include it anyway. And since you're considering using FULL=YES, tablespaces become relevant. I have had great success using a combination of fingerscrossed=yes with asifbymagic=always _hyper-speed=yes is also a good one to try, but in the spfile only! FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. |
this technique to upgrade, I would be very interested. (I'm about to
do exactly that)
TIA,
Arch
#44
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
#45
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
#46
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
#47
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
#48
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
#49
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
#50
| |||
| |||
|
|
FWIW - I always pre-create the tablespaces and users on the new database, then just import the relevant schemas (from a full=y export from the source db). Which just reminded me, one of the sessions at OOW 07 was about using exp/imp for upgrading, and some pitfalls and things to watch out for when upgrading this way. I forget what they (things to watch for) were, perhaps I can find it on my DVD set.. Pardon my butting in here, but if you have info on pitfalls in using this technique to upgrade, I would be very interested. (I'm about to do exactly that) |
watch out for grants, procedures and invalid objects.
Assuming a copy through exp/imp being used to
land an older db into a new release framework,
my progress steps are as follows, with a manual
thorough check step in between each:
1- pre-create all storage (tablespaces), adjust controls for
new release, whatever they may be.
2- import schema by schema (owner by owner, NEVER sys or system)
3- do the import in stages: create tables only, no data (rows=n,
indexes=n, grants=n)
4- then disable all created triggers (if any), and load the rows
(rows=y, indexes=n, grants=n)
5- then do all indexing (rows=n, indexes=y, grants=n)
6- then repeat for all other schemas
7- last, do a grants=y,indexes=n, rows=n import to get all the grants.
8- last, manually enable anything I've disabled, including
constraints, triggers and such.
Works fine for most cases. Careful with things like FGAC
and AQ/replication, those require some careful thinking
and changes to above steps.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.