Migration from HP-UX to Linux

[former_member240105]

Dear Community members,

                                            We are doing POC for migration of ECC from HP-UX  ( Code page ---> 4102 =  Big Endian) to Linux   ( Code page --> 4103 = Little Endian) platform with no DB change ( Oracle).My question is , although ECC on source system is Unicode, does this migration still be considered as Code Page conversion ? ( I am thinking code page conversion for H/W is happening in this case)  If so, Do I have to unload the cluster tables in sorted order always during code page conversion ?

954268 - Optimization of export: Unsorted unloading

• Code page conversion
  If you convert the codepage, you must always unload cluster tables as sorted. The codepage is converted for the following actions:

• non-Unicode --> Unicode
• MDMP --> Unicode
• Unicode (big endian) --> Unicode (little endian) ------> My scenario
• Unicode (little endian) --> Unicode (big endian)
• EBCDIC --> ASCII

  Caution: For a code page conversion, the conversion must be carried out during the export to ensure that cluster tables are always exported immediately.

I have read the below thing in one of the document.

Note: If a code page conversion is performed, table clusters must be unloaded sorted. As of R3load 6.40 patch level 55 (compile date February 10, 2006) and R3load 7.00 patch level 10 (compile date February 10, 2006), R3load automatically ensures that table clusters are exported in sorted order during a code page conversion.

I request you  guys to shed some light on this topic.

Thanks,

Hari

[JPReyes]

Hi Hari,

This means you need to do a Heterogeneous System copy (to change the endianess), but you do not need to do a unicode conversion.

Not sure if thats the answer that you needed.

Regards, Juan

[Former Member]

Hi Hari,

As mentioned earlier by Juan, you need to just carry out Export/Import (Hetrogenours copy) on the Linux.

As if the source is non-unicode you need to check the box for Unicode in SWPM while performing migrations.

In your case your already having source as unicode you dont need to worry about it.

Regards,

Ram

[former_member240105]

Hi Juan,

               My mistake, I was not clear in my original post. I wanted to actually use Distmon for parallel export/import and just wanted to check if I can do unsorted unload for cluster tables given that this is code migration. See below Note 954268 where there is restriction.What happens if I proceed with unsorted unload ignoring the below condition for cluster tables ? Will there be any performance impact on target system after import ?

954268 - Optimization of export: Unsorted unloading

• Code page conversion
  If you convert the codepage, you must always unload cluster tables as sorted. The codepage is converted for the following actions:
• non-Unicode --> Unicode
• MDMP --> Unicode
• Unicode (big endian) --> Unicode (little endian) ------> My scenario
• Unicode (little endian) --> Unicode (big endian)
• EBCDIC --> ASCII

Thanks,

Hari

[JPReyes]

Hi Hari,

The note does seem to suggest that you should use a sorted unload approach.

If you have the time I would stick to the recommendation.

Regards, Juan

[former_member240105]

Thanks Juan,

                     I did performed export with distmon tool and found out cluster tables/packages (SAPCLUST) were unloaded with unsorted order as it has used DDL template file DDLORA_LRG.TPL

I found information from Note 954268 saying thinking that R3load would unload cluster tables in sorted order irrespective of Config file.

• R3load
  The latest R3load from the SAP Service Marketplace, which ensures that specific tables (type: report, screen, nametab) and cluster tables are always unloaded sorted during a codepage conversion - irrespective of the configuration in the DDL<db>.TPL file.
  • R3load 6.40, as of patch level 55 or
    as of the compile date February 10, 2006 2006
  • R3load 7.00, as of patch level 10 or
    as of the compile date February 10, 2006 2006.

My question is - How would I know if the table is unloaded sorted or unsorted although SAPCLUST package export log is showing as "Without ORDER BY PRIMARY KEY the exported data may be unusable for some databases" which is evident that it has used DDLORA_LRG.TPL file from CMD file and exported unsorted.If this is true then does statement  from Note 954268 is wrong?

My R3load version is 7.20 PL 133 should be already knowing about this.

(RTF) ########## WARNING ###########

        Without ORDER BY PRIMARY KEY the exported data may be unusable for some databases --->Unsorted unload

/sapmnt/XXX/exe/R3load: job completed

/sapmnt/XXX/exe/R3load: END OF LOG: 20151028222238

/sapmnt/XXX/exe/R3load: START OF LOG: 20151028222238

/sapmnt/XXX/exe/R3load: sccsid @(#) $Id: //bas/721_REL/src/R3ld/R3load/R3ldmain.c#8 $ SAP

/sapmnt/XXX/exe/R3load: version R7.20/V1.6 [UNICODE]

Compiled Dec  4 2013 13:44:00

/sapmnt/C3D/exe/R3load -e SAPCLUST.cmd -datacodepage 4102 -l SAPCLUST.log -stop_on_error

(DB) INFO: connected to DB

(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF16

(DB) INFO: Export without hintfile

(GSI) INFO: dbname   = "XXX20140523120508

                                      "

(GSI) INFO: vname    = "ORACLE                          "

(GSI) INFO: hostname = "XXXX                                                        "

(GSI) INFO: sysname  = "HP-UX"

(GSI) INFO: nodename = "XXXXX"

(GSI) INFO: release  = "B.11.31"

(GSI) INFO: version  = "U"

(GSI) INFO: machine  = "ia64"

(GSI) INFO: instno   = "0020179969"

(RTF) ########## WARNING ###########

        Without ORDER BY PRIMARY KEY the exported data may be unusable for some databases

Request experts to pitch in to clarify my doubt.

Thanks,

Hari Buggana

[Former Member]

Hello Hari,

The key warning you are zooming in on is "without ORDER BY PRIMARY KEY" ....... unusable for "some" databases. Bear in mind it's just a warning.

As you are coming from and going to Oracle this is not a problem.

DDLORA_LRG.TPL as you have seen will unload data *unsorted*. That said (and the note is correct), cluster tables will always be unloaded *sorted*. It's hard coded.

So to summarise, even if you choose a unsorted unload, cluster tables will always be unloaded sorted.

If you're a curious cat then check your active sessions during the export (CDCLS, EDI40 etc ....) and you'll see the "order by" statement in the active SQL.

I hope I've cleared up some slightly muddy waters.

ps: Please keep in mind that for your production run the migration has to be done by a certified OSDB consultant.

KR,

Amerjit