Re: cross platform migration

  • From: Svetoslav Gyurov <softice@xxxxxxxxx>
  • To: max scalf <oracle.blog3@xxxxxxxxx>
  • Date: Thu, 13 Feb 2014 00:55:20 +0000

Hi Max,

Indeed, you need to convert the file system first which will save you
copying all the 30TB of data and then you need to run RMAN convert.

Are you considering GoldenGate as an option or it would be out of budget ?

Sve


On Thu, Feb 13, 2014 at 12:44 AM, max scalf <oracle.blog3@xxxxxxxxx> wrote:

> Thanks Sve, I was under the impression that i could just take the mount
> point from HP and mount it over to linux as i oracle was going to do the
> RMAN Conversion process for me.  But you are saying i need to do it at the
> storage level(CDS) and then also do it at database level ?
>
>
> On Wed, Feb 12, 2014 at 5:06 PM, Svetoslav Gyurov <softice@xxxxxxxxx>wrote:
>
>> Hi Max,
>>
>> Yeah, BCVs has been my favorite when we need to clone or refresh the
>> DEV/UAT environments. However these platforms still have different
>> endianness and you need to convert the file system itself. This can be done
>> using the Cross-platform Data Sharing (CDS) featureof Symantec's Veritas
>> Storage Foundation software which will allow you to create portable data
>> containers (PDC) and mount the volumes on different platforms. I remember
>> seeing one or two years ago similar presentation (maybe OOW presentations)
>> about using this approach and greatly reducing the time for migration.
>>
>> Regards,
>> Sve
>>
>>
>> On Wed, Feb 12, 2014 at 10:42 PM, max scalf <oracle.blog3@xxxxxxxxx>wrote:
>>
>>> Sve/All,
>>>
>>> Thanks for you input.  i guess RMAN incremental backup/restore/recover
>>> is out of the picture and so is data guard.  We are going from 10.2.0.4 to
>>> 10.2.0.4 (due to some SAP kernel restrictions)
>>>
>>> For that 30TB database all that Data is usable(cannot be purge/archived)
>>> so we have to move that to a platform, but one thing i can think of is for
>>> the big database we do have BCV split/mirror in place, can i somehow use
>>> that?
>>>
>>> For example
>>> 1. on source DB put all tablespace in read only mode and start meta data
>>> export(transportable tablespace=y)
>>> 2. once in read only mode take a BCV split(in parallel) of all the
>>> datafile mount points and mount it on target
>>> 3. once the file system is mounted on target, start the RMAN conversion
>>> process (how could would this take, is this depended on DB size or what?)
>>> 4. once conversion is completed, start the import of the metadata
>>>
>>> if above can be used, only concern i have is we have probably about 2k -
>>> 3K datafiles(spread across 100's of mount points) or so and i might some
>>> how miss doing the convert process in RMAN for those data file or miss them
>>> while doing the import part(where i believe i have to give datafile =
>>> locations of all files)..any pointers here ?
>>>
>>>
>>>
>>> On Wed, Feb 12, 2014 at 3:38 PM, Svetoslav Gyurov <softice@xxxxxxxxx>wrote:
>>>
>>>> Hi Max,
>>>>
>>>> My comments are inline, I assume you are migrating 10.2.X to 11.2.X ?
>>>>
>>>>
>>>> On Wed, Feb 12, 2014 at 8:54 PM, max scalf <oracle.blog3@xxxxxxxxx>wrote:
>>>>
>>>>> Hello List,
>>>>>
>>>>> I have a project that is going to get started soon and i wanted to get
>>>>> some Pointers with regards to it.  Please excuse my knowledge, as i am 
>>>>> from
>>>>> SQL Server background and a seasonal oracle DBA.  Project is to move our
>>>>> DB(multiple DB size from 1TB - 30TB) from hp-ux pa risc to RHEL.  We have
>>>>> quite a few restriction in options as our app is SAP :-( .  Couple of SAP
>>>>> notes i read suggested that we can use use cross platform transportable
>>>>> tablespace, which is what i am planning to do as well.  I wanted to find
>>>>> out couple of things from the list
>>>>>
>>>>>
>>>>>    1. First of all if anyone has done this(on a SAP system), if so
>>>>>    any gotcha
>>>>>    2. To reduce the down time i was planing to do a restore ahead of
>>>>>    the cut over(lets say 3 days in advance) and then keep applying 
>>>>> archive log
>>>>>    until the day of cut over.  Is that even possible for this situation 
>>>>> (as i
>>>>>    have to do RMAN Convert of the datafiles and then keep applying logs)
>>>>>
>>>>> Nope, you cannot restore/recover on a mixed platforms.
>>>>
>>>>
>>>>>
>>>>>    1. i cannot do transportable DATABASE, as i am going from big
>>>>>    endianess to little( i believe #2 is possible here, as i read this
>>>>>    
>>>>> doc<http://www.pythian.com/blog/howto-oracle-cross-platform-migration-with-minimal-downtime/>
>>>>>    )
>>>>>
>>>>> Correct, they should be having the same same endian and you are
>>>> migrating from Big to Little.
>>>>
>>>>
>>>>>    1. I read an option some place that mentioned i could have
>>>>>    heterogeneous data guard setup for this migration, but when i read MOS 
>>>>> doc
>>>>>    ID  413484.1, i do not think hp ux to RHEL Data guard is supported
>>>>>    or have i gotten that wrong.
>>>>>
>>>>> Indeed, it is not:
>>>> RMAN DUPLICATE/RESTORE/RECOVER Mixed Platform Support (Doc ID 1079563.1)
>>>>
>>>>
>>>>>    1. any other recommendation in general due to the size of our DB.
>>>>>     The one i am worried about is our 30TB DB which takes about 18 hours 
>>>>> to do
>>>>>    weekly Level 0 backup and customer wants to do the migration in less 
>>>>> than
>>>>>    10 hours
>>>>>
>>>>> Does all the 30TB db having operational data ? Are there any read only
>>>> or archive tablespaces ?
>>>>
>>>>
>>>>>    1. is cross platform transportable tablespace a bad idea as SAP
>>>>>    creates thousands and thousands of objects in the database and the 
>>>>> metadata
>>>>>    would be too much to export/import
>>>>>
>>>>> I can't think of a limitation of that one. You might export you
>>>> metadata in parallel and also exclude statistics to improve the time. You
>>>> problem here would be the time it takes to copy 30TB over the new platform
>>>> and then convert them.
>>>>
>>>> GoldernGate of course is the holly grail. Quick look on MOS shows that
>>>> HP-UX PARISC is supported platform for Oracle GoldenGate 11.2.1.0.6.
>>>>
>>>>
>>>> Regards,
>>>> Sve
>>>>
>>>>
>>>>> I would really appreciate some pointers.
>>>>>
>>>>> Thanks,
>>>>> Max
>>>>>
>>>>
>>>>
>>>
>>
>

Other related posts: