Re: cross platform migration
- From: max scalf <oracle.blog3@xxxxxxxxx>
- To: Svetoslav Gyurov <softice@xxxxxxxxx>
- Date: Wed, 12 Feb 2014 18:44:19 -0600
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:
