Expertise Advices on ASSM + Unicode Conversion

[Former Member]

Hi,

I need some Expertise advice on Converting oracle Table Space to ASSM and Unicode.

Our company planning on upgrading ECC 5.0 to ECC 6.0 then we also want to do Unicode migration, but we need to know; what/when are the best practices to convert the oracle tablespace to ASSM?

I believe part of Unicode migrations we have to convert the Oracle tablespace to ASSM.

Option 1:

Is it better to convert all the tablespaces to ASSM before we do a Unicode migration? And then do the Unicode migrations?

Option 2:

Or is it better to do everything together at the same time Unicode Migrations and Tablespace conversation?

Is there are any benefits between those two options? Which one is really time saving? Option 1 or Option 2

Quick question on the side, how long would it take to convert 450 GB total data to ASSM?

Please advice on this!

Thanks in Advances

Kumar

[Former Member]

Hi,

Markus explanation is very clear. you dont need to convert tablespaces .

this will be done with the unicode conversion when you will create the database and tablespaces

Thanks

[Former Member]

Hi,

exactly Markus, the database will be recreated with unicode conversion.

In case of 10g ASSM by default but not with 9i.

Thanks

[markus_doehr2]

Note 620803 - Oracle 9i: Automatic Segment Space Management:

[...]

For new SAP installations as of SAP WebAS Release 6.40, ASSM is the default setting when creating tablespaces.

[...]

--

Markus

[Former Member]

Hi there,

I am not talking about new installation, this will be an upgrade from ECC 5.0 to ECC 6.0. We have ECC 5.0 and only recenty we have upgraded our oracle from 9i to 10G and in few months we want to upgarde to ECC 6.0 and after this we also planning on doing unicode conversion and ASSM?

so you're saying it is better to do both together at the same time? if yes, how long do you think is the downtime will be for 450 GB data, to do ASSM and Unicode Migrations?

Please advice.

Thanks

Kumar

[markus_doehr2]

A Unicode migration means to export the data via R3load, delete the current database, create the database new and re-import the data you just exported.

Because of that, it doesn't make sense to implement ASSM first because you will delete the database neverless, whether the source is using ASSM or not.

You WILL do a "new installation", it's a homogeneous system copy using R3load.

It's very difficult to say how much time you need, this depends on available CPU, number of parallel R3load processes for export and import, speed of the storage device etc.

We did a migration of an 650/850 GB (source/target) database in a weekend.

--

Markus

[Former Member]

Markus, thanks for your good understanding explanation.

To get a better understanding let me clarify some of the stuffs with you.

So you're saying, when we do a new installation of ECC and Oracle we can set the Oracle tablespace to ASSM and then export the database back(homogenous system copy) in this you will have your database tablespace ASSM and Unicode system or I am still mis-interpreting you?

This is the first time I am dealing with these kind of stuffs.

Thanks again for your help.

Any comments or advice would be nice.

Kumar

[markus_doehr2]

> So you're saying, when we do a new installation of

> ECC and Oracle we can set the Oracle tablespace to

> ASSM and then export the database back(homogenous

> system copy) in this you will have your database

> tablespace ASSM and Unicode system or I am still

> mis-interpreting you?

almost

I'll try again to explain what you will do:

- you start sapinst on the source system (ECC 6.0/Oracle 10g/NON-ASSM)

- you export the database using R3load

- you delete the original SAP system and the database files

- you install a new SAP system with a Unicode Kernel from the original installation CD/DVE set but not providing the Export CDs/DVDs that you got delivered but the export file you just created before using R3load

- sapinst will by default create the new Unicode database with ASSM (and all other nice stuff enabled) and import YOUR data

So you don't need to manually do anything, no migration, no tablespace copies, nothing - you just install the system as if you were installing a new system, with the difference of giving the installation YOUR exported data instead of the CDs. Sapinst will give you this option during installation.

I really hope though, that you have tested this at least once before doing a production migration, even if it's just to get a runtime estimate. Depending on the layout of your database and the applications used, you will have one single process running for a VERY long time while all the others are already finished. It's also advised to do test migrations because you will need to estimate the number of R3load processes you will use. Too much of them will overload the box and slow down the whole process, too less will not generate optimal throughput and thus run longer.

I did test our migration 4 times before we did the 5th equals production migration - admittedly, we have 12 langues (including Asian ones) so we wanted to make sure, everything is right.

--

Markus

[Former Member]

Thank you so much for giving a better understanding. that is very very very helpy ful advice.

if you have any good documents or procedure you wrote on the Unicode Migration/ASSM other than one in the SAP service market, they have very complex and understanding documents, would you mind sharing it with me, I am really a new-bie to Unicode and ASSM? any kind document is good. you can mail me at subramks@gmail.com.

Thank you again.

Kumar

[markus_doehr2]

I would suggest the following: Forget about ASSM - it will be enabled by default after your conversion, that's all I can say about ASSM in this context.

The Unicode migration itself is a really complex process, we had quite some issue to fight with. To see the whole story we were going through read that thread:

The topic is a bit different but I explain in-depth there, what problems we encountered, maybe this will helpful for you too.

You're right, the guides are pretty complex and the procedure and preparation is too so I would NOT do that as newbie (no offense). We had a consultant from SAP on-site while we were doing the preparation for the migration because of those many languages we had. The migration itself was then done by me after those four tests migrations I mentioned earlier.

If your system is a single codepage migration, it's not that difficult if you follow the guides provided (http://service.sap.com/unicode@sap) for your specific support package level. Just follow it step-by-step, read all the note (yes, I know, there are SO MANY).

My "best practice recommendations" are:

- use the VERY LATEST tools (kernel, R3load and dboraslib) for the export (VERY important!)

- if possible, install the latest Basis support package (SP 12 in your case) <b>before</b> you start the preparation (that is running the task of SPUMG)

- If you install the unicode instance, also use the latest tools there, latest kernel and latest R3load, you can patch the system while the database is created (there's enough time)

- if you have external systems connected, make sure, they are aware of the fact, that they are "talking" to Unicode systems after the migration (Fax-Servers, EDI and also all SAP systems such as BW, CRM, SCM or also SAP-KPRO-Servers or what else you have there)

- test, test, test, don't do the migration just theoretically

I can't provide a guide, they are highly individual depending on what modules are implemented, what external interfaces and connections to systems you have etc. etc. I could provide you with a "guide" but I'm VERY sure, there's something missing/too much and I won't be responsible for any errors/problems you will get. We did a full day of just evaluating the system, interfaces etc.

The only advise is - do a test migration, connect the system to everything you also have on production and test.

--

Markus

[Former Member]

Thanks Again.

Just like you mentioned, we are planning on doing at least 3 test migrations before we do migrations to OUR Sandabox, then DEV, then QA and finally the PRD. We are also planning on having someone from SAP just for initial phase as well, and at the end.

"I could provide you with a "guide" but I'm VERY sure, there's something missing/too much and I won't be responsible for any errors/problems you will get. We did a full day of just evaluating the system, interfaces etc"

That is not a problem, I am really aware of that it would be different for each company modules and stuffs. For a good start I just need some kind of good procedure to start with? it would be good start if I have some kind of documents procedures? Please sent me any documents to my e-mail at subramks@gmail.com

Thanks again for your help. That was really really help full answers.

Kumar

[markus_doehr2]

Ok - with a consultant you're on the safe site - if you've done it once, you will get the procedure.

I'll need to check with my chief if it's ok to send the document - it contains internal data of screenshots, that can't be scrambled.

--

Markus

[Former Member]

Thank you Markus. Let me know if you can send any documents after consulting with your Chief. I can promise that I wont distribute any documents that you sent.

Thanks

Kumar

[markus_doehr2]

Just to add - I´m not permitted to send them, sorry - they contain too much company internal information.

--

Markus

[Former Member]

Thank you Markus for your help and everything.

Kumar

[Former Member]

Hi,

with Option 2 you will save time

Thanks

[markus_doehr2]

He will create a new database though, with or without ASSM - so the amount of time used is the same.

If he uses the SR2 installation CDs and Oracle 10g ASSM is activated by default.

--

Markus

[Former Member]

Hi Markus,

What i mean by option 2 is faster is this will do the job once.

but with option 1: he will convert to ASSM (need to reorgnaize the tablespaces for that which means export/recreate tps/import) and after that he will recreate the database so the tablespaces again for the unicode conversion.

c/c: option 2 is faster than option 1

Thanks

[markus_doehr2]

Yes - ok - sure, you're right.

--

Markus

[Former Member]

Ahmed,

Can you please justify your answer? why do you think Option 2 will be better because I need to make power point presentation putting all the pros and cons and which options to go with?

thanks in Advance

Kumar

[Former Member]

Hi,

You will do both together, there is no time consuming as you have to recreate the database and tablespaces with unicode.

Thanks

[Former Member]

Hi,

First at all, ASSM migration is pure Oracle database task. it is a reorganization of the database. to do unicode conversion you need to export, recreate the database and import the data

So you can do ASSM migration with the unicode conversion process as follow:

- Unicode Preparations

- With SAPINST export your database (R3load)

- Recreate your database with ASSM tablespaces

- With SAPINST import your database

- Unicode Postprocessing

Good Luck

[Former Member]

Thanks for reply. To get a better clarifications

is is better do it before unicode migration or during the unicode migration? Is it time consuming if we decided do together? which one is has more benefit? option 1 or 2?