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

  • From: "Taylor, Chris David" <ChrisDavid.Taylor@xxxxxxxxxxxxxxx>
  • To: 'Josh Collier' <Josh.Collier@xxxxxxxxxxxx>, 'sandeep salian' <sallianz11@xxxxxxxxx>
  • Date: Wed, 7 Mar 2012 13:10:38 -0600

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@xxxxxxxxxxxx] 
Sent: Wednesday, March 07, 2012 1:10 PM
To: Taylor, Chris David; 'sandeep salian'
Cc: 'oracle-l@xxxxxxxxxxxxx'
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Taylor, Chris David
Sent: Tuesday, March 06, 2012 2:42 PM
To: 'sandeep salian'
Cc: 'oracle-l@xxxxxxxxxxxxx'
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@xxxxxxxxx]
Sent: Tuesday, March 06, 2012 4:01 PM
To: Taylor, Chris David
Cc: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx<mailto:ChrisDavid.Taylor@xxxxxxxxxxxxxxx>> 
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.


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



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


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




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

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 03-2012