Re: migrate database
- From: Jurijs Velikanovs <j.velikanovs@xxxxxxxxx>
- Date: Thu, 12 Jan 2006 23:37:26 +0000
Some times in development process to restore just SYSTEM tablepace can
be extremely useful.
One good example I had got some time ago.Development team located on
the remote side to production.
Development have got all necessary environments for successful
development cycle (Development, Testing, Testing Delivery etc).
Even with all proper devilment cycle, time to time emergency
deliveries were installed directly in to production (hot fixes).
The unimportant think was, that after those deliveries the Production
DB (~2TB) and the Pre-production DB have been unsynchronized.
The Project manager asked me to develop way to compare to databases
quickly enough and ensure the possibility to repeat process then it is
required.
As you can imagine development side hadn't 2TB disk array.
The answer was to restore just SYSTEM tablespace (from production) on
Development side.
Then using the Change Management OEM component or any different tool
to compare tow local databases.
Jurijs
On 1/12/06, Bobak, Mark <Mark.Bobak@xxxxxxxxxxxxxxx> wrote:
> Seems to me, there's some confusion here. The question I think we ought
> to be asking is "Why would you want to move a SYSTEM tablespace?"
>
> The answer, I think, is that you'd never want to move *just* a SYSTEM
> tablespace.
>
> You will either:
> Use RMAN to move an entire database, which would necessarily include the
> SYSTEM tablespace, and all other tablespaces, w/ the possible exception
> of TEMPORARY tablespace(s).
>
> OR
>
> Use transportable tablespace feature. To do so, you need to create a
> target database (which would by definition create a SYSTEM tablespace
> for that new database), and then transport individual tablespaces from
> your source db to this new target db. As part of the move, the data
> dictionary metadata (contained in the SYSTEM tablespace or the source
> and target dbs) will be updated as the tablespaces move from one db to
> the other. In this context, it makes no sense to talk about moving the
> SYSTEM tablespace.
>
> Corrections welcome, but I think that sums it up....
>
> -Mark
> --
> Mark J. Bobak
> Senior Oracle Architect
> ProQuest Information & Learning
>
> "There are 10 types of people in the world: Those who understand
> binary, and those who don't."
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jurijs Velikanovs
> Sent: Thursday, January 12, 2006 6:09 PM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Re: migrate database
>
> Adar absolutely right. Instead to use "cross-platform transportable
> tablespace" in case of SYSTEM tablespace you have to use a
> "cross-platform transportable DATABASE" feature.
> Then you can transport a minimum set of tablespace SYSTEM, UNDO, SYSAUX.
> To do that you have to use RMAN, instead of the traditional
> transportable tablespace procedure.
>
> If the initial question was: Can I transport a SYSTEM tablespace across
> different platforms?
> Answer would be: Yes, with some limitations using "cross-platform
> transportable DATABASE", and restore through RMAN min set of
> tablespaces.
>
> Limitation in that case is endian format. It is well described in the
> 10g doc (see below) Cheers, Jurijs
>
> PS Next week I going to play with that feature, moving SYSTEM tablespace
> from Linux to Win. Ill update the thread with the results.
>
> Oracle(r) Database
> Backup and Recovery Advanced User's Guide 10g Release 2 (10.2)
> B14191-01
>
> Page 15-7, Cross-Platform Transportable Database: RMAN CONVERT DATABASE,
>
> Restrictions on Cross-Platform Transportable Database The principal
> restriction on cross-platform transportable database is that the source
> and destination platform must share the same endian format. For example,
> while you can transport a database from Microsoft Windows to Linux for
> x86 (both little-endian), or from HP-UX to AIX (both big-endian), you
> cannot transport a whole database from HP_UX to Linux for x86 using this
> feature. You can, however, create a new database on a destination
> platform manually, and transport needed tablespaces from the source
> database using cross-platform transportable tablespace as described in
>
>
>
>
> On 1/12/06, Yechiel Adar <adar76@xxxxxxxxxxxx> wrote:
> > The replies I saw are mixing two concepts:
> > 1) Using RMAN to copy a DATABASE to new platform, which copy the whole
>
> > database, including system tablespace.
> > 2) Using transportable tablespace to move TABLESPACE to a new database
>
> > on another platform.
> >
> > I do not know much about RMAN so I will not touch this topic.
> > Transportable tablespace is:
> > 1) Exporting the metadata that describe the objects in the tablespace.
> > 2) Moving the tablespace to the new location.
> > 3) Running import tablespace that merge the objects metadata into an
> > existing database.
> >
> > Since the import works against existing database, and this database
> > already have SYSTEM tablespace, you can not do transportable
> > tablespace for system.
> >
> > Adar Yechiel
> > Rechovot, Israel
> >
> >
> >
> > Ignizio, Richard wrote:
> >
> > >When using Transportable tablespaces you cannot export the SYSTEM
> tablespace(but you can export the undo tablespace):
> > >
> > >exec sys.dbms_tts.transport_set_check('SYSTEM');
> > >BEGIN sys.dbms_tts.transport_set_check('SYSTEM'); END;
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > //www.freelists.org/webpage/oracle-l
> >
> >
> >
>
>
> --
> Jurijs
> +44 7738 013090 (GMT)
> ============================================
> http://otn.oracle.com/ocm/jvelikanovs.html
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
>
>
--
Jurijs
+44 7738 013090 (GMT)
============================================
http://otn.oracle.com/ocm/jvelikanovs.html
--
//www.freelists.org/webpage/oracle-l
Other related posts:
