RE: RMAN convert 5TB db on Linux (Little Endian) to AIX (Big Endian) - alternatives?

From: Taylor, Chris David <ChrisDavid.Taylor_at_ingrambarge.com>
Date: Wed, 7 Mar 2012 13:10:38 -0600
Message-ID: <C5533BD628A9524496D63801704AE56D6ADD51C833_at_SPOBMEXC14.adprod.directory>



Thanks Josh. Great info.

Chris Taylor

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

Any views and/or opinions expressed herein are my own and do not necessarily reflect the views of Ingram Industries, its affiliates, its subsidiaries or its employees.

-----Original Message-----

From: Josh Collier [mailto:Josh.Collier_at_banfield.net] Sent: Wednesday, March 07, 2012 1:10 PM
To: Taylor, Chris David; 'sandeep salian' Cc: 'oracle-l_at_freelists.org'
Subject: RE: RMAN convert 5TB db on Linux (Little Endian) to AIX (Big Endian) - alternatives?

I used this white paper to move 8tb from big to little endian.

http://www.oracle.com/technetwork/database/features/availability/maa-wp-10gr2-platformmigrationtts-129296.pdf

it worked great. Rman endian conversion on the target took 4 hours.

However, I suggest doing a lot of testing I found bugs in the following areas:

TTS with compressed tables (bug 10324526) TTS and flashback (bug 12619529)

The latest PSU is essential to avoid catching more bugs.

Run DBV and RMAN logical block validation on the database after the conversion is also essential. Also using db_block_checking is helpful to find bugs during test.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Taylor, Chris David Sent: Tuesday, March 06, 2012 2:42 PM
To: 'sandeep salian'
Cc: 'oracle-l_at_freelists.org'
Subject: RE: RMAN convert 5TB db on Linux (Little Endian) to AIX (Big Endian) - alternatives?

Impressive....Something to consider. I assume you divided the datafiles (tablespaces) being converted by units that were self contained and run them in parallel?

Chris Taylor

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

Any views and/or opinions expressed herein are my own and do not necessarily reflect the views of Ingram Industries, its affiliates, its subsidiaries or its employees.

From: sandeep salian [mailto:sallianz11_at_gmail.com] Sent: Tuesday, March 06, 2012 4:01 PM
To: Taylor, Chris David
Cc: oracle-l_at_freelists.org
Subject: Re: RMAN convert 5TB db on Linux (Little Endian) to AIX (Big Endian) - alternatives?

We just went live with a 32 TB database after migrating it from HP-UX to Linux. We ran the RMAN convert from 16 rman scripts [ 4 mounts on 4 RAC nodes (4X4) ] and the RMAN itself took 4.5 hrs in total. On Tue, Mar 6, 2012 at 7:17 AM, Taylor, Chris David <ChrisDavid.Taylor_at_ingrambarge.com<mailto:ChrisDavid.Taylor_at_ingrambarge.com>> wrote: I was asked about converting a 5 TB 10.2 database on RHEL to a 11.2 database on AIX. As I was thinking through this, I understand that to do the conversion from Linux to AIX the database would have to be at the same version. So, I'd either have to upgrade prior to moving, or after. Then I was thinking about the RMAN conversion speed to convert from little endian to big endian and I think I would have a problem due to the time required.

I don't have access to the exact I/O throughput on the system but if I can convert 4 GB in 14 minutes (stats taken from a white paper) through RMAN, that's close to 1/3 GB per minute. So I could do 1 GB = 3 minutes. (Should I expect more than 1/3 GB per minute?)

So, if I have 1 TB (approx. 1000GB) that would 3000 minutes. Now if I have 5 TB, that's 15,000 MINUTES (!) to convert through RMAN.

Is that really my only option (or best option anyway)?

What other options should I explore?

Chris Taylor

"Quality is never an accident; it is always the result of intelligent effort."
-- John Ruskin (English Writer 1819-1900)

Any views and/or opinions expressed herein are my own and do not necessarily reflect the views of Ingram Industries, its affiliates, its subsidiaries or its employees.

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Wed Mar 07 2012 - 13:10:38 CST

Original text of this message