Unicode Conversion  in Downtime Minimized Strategy

Hi,
Whether a Unicode Conversion can be done in a Downtime Minimized Strategy as what we have in Application Upgrade?
Regards,
Sam

No. Unicode conversion can be a easy project or a big project it depends on many factors lke developments, languages installed, product version, etc...
One of the steps of unicode conversion, is the EXPORT and IMPORT. During this time your system is unavailable.
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/unicode/unicode%2bfaq
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_i18/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d393238373239%7d
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5001004f-ce99-2910-8fa9-c5e564a5f318
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_i18/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d363535333331%7d
cheers

Similar Messages

  • Minimize downtime during UNICODE conversion

    Hello forum !
    I am looking at the UNICODE conversion of a large (?) SAP Oracle database for ECC. The Database it self is at about 10 TB. UNICODE converting this in one single run will take too long to fit inside the company defined tolerable downtime window.
    When looking at the data I find that the largest 50 tables makes up about 75% of the total database size. Most of the 50 largest tables have data for several years back, and I am able to partition the tables with one partition pr year.
    The good thing about this is that I am able to make the partitions with old data (more than one year old data) READ-ONLY.
    My assumption is that I will be able to UNICODE convert 60-70% and create the indexes for these partitions without taking down the database to be converted.
    Now,- doing the downtime-phase I will be able to exclude the old partitions of the largest tables in the export since I have already created a new UNICODE database with these objects and thereby drastically reducing the required downtime.
    Is there anyone who has any experience with an approach like the one I have schetched out here ?
    Kjell Erik Furnes

    Can you please be a bit more specific on your installation? How long is your possible downtime (export time should be about 2/3 of that)? How long is your actual export estimation? Do you have suitable hardware (CPU/disk)?
    What you absolutely need to have:
    [1043380 - Efficient Table Splitting for Oracle Databases|https://service.sap.com/sap/support/notes/1043380] -> export tables with ROWID splitting
    [855772 - Distribution Monitor|https://service.sap.com/sap/support/notes/855772] -> enables distributed and parallel export/import
    So on the hardware side you will need, a storage subsystem as fast as possible with two copies of the disks (one for exporting and one for importing). A bunch of application servers with fast CPUs helps a lot, everything connected with at least gigabit ethernet.
    If you knew all this already, sorry for the spam. But i achived throughputs at about 400gb/hour on a medium sized hardware, i think throughputs of 1tb/hour should be possible (not talking about cluster tables
    Regards, Michael

  • Changing Upgrade Strategy from Downtime Minimized to Resource Minimized

    I have started a QAS upgrade to ECC 6.0 in Downtime Minimized mode.  It appears that I have not started it soon enough, or have not allocated enough resources to the upgrade.  Since in my system there is very little activity at night, I was wondering if it was possible to allocate more resources to the upgrade or switch to Resource Minimized mode, then switch back to downtime minimized in the morning.  Anyone have any thoughts?

    Am I allowed to answer my own question?  Well here goes.  If you kill the upgrade during the EU_IMPORT phases you can choose to change to 'fast import' for the remainder.

  • SAP R/3 4.6 C to ECC 6.0 Upgrade using CU &UC method- Unicode conversion

    Basis Gurus
       I am working on upgrade from R/3 4.6C to ECC 6.0.
    ECC 6.0 upgrade completed( still in non Unicode).  Now I am in the process of Unicode conversion.
    I have used following methods for the upgrade.
    1. Combined Upgrade & Unicode conversion(CU & UC)
    2. Resource minimized( as I am doing it in Sandbox).
      As I understand I need to perform the DB export and Import now for the unicode conversion.
      According to the Upgrade document, First I need to run Export using R3load in ECC6.0(Non unicode)
      and then install Unicode system and import the same data file.
      My understanding was, when I choose, Resource minimized, I need to run Export and import
      in the same system.
      Can you please help me , whether I need another Unicode system for import ??
    Graham

    Hi,
    Dont get confused with upg strategy and unicode conversion.
    In general Upgrade strategy (either downtime-minimized/resource minimized)
    In unicode conversion you have export/import(exp/imp) of data concept
    In CU&UC approach you have to do in a streach to complete migrate from old release to new realease ECC 6.00.
    Using database independent (sapinst only) or Using database dependent (migration monitor or Distribution monitor)
    It can be done in 2 ways.
    If you dont have addtional server for unicode conversion
           1)you can either do exp on same hardware and take bakup and do import using the exp dump.
           2)Do exp on one server and prepare your target empty database on another server and complete imp of data.
    Hope this is clear.
    Regards,
    Vamshi.

  • Combined upgrade & Unicode conversion.

    Hi
    I need some suggestions for my concerns: I would appreciate, if you reply ASAP for below situations and actions.
    Current system: HP unix DB: Oracle10.2.0.2
    SAP 6.20 with SP 61, single code page
    strategy: resource minimized.
    Upgrading from 4.7 was 6.20 to ECC6.0 with CU & unicode conversion.
    we ran UCCHECK and provide the list to ABAP, but they are not modifying now.
    Mean while we started the preconversion steps for unicode conversion and completed. SPUMG.
    Upgrade prepare is completed and currently in begining of down-time.
    so far ABAP programs are not unicode complaint!!!
    we don't know, when would they modify??
    If we complete the upgrade and post upg steps for ecc 6.0 and
    pre coversion steps for unicode.
    is it a problem, if the ABAP programs are not modified yet, can it be done after conversion and before export???
    or after import??
    Your time is highly appreciated.
    Thanks
    creddy

    Per CU&UC guide, you can do some conversions in parellel
    and after upgrade, you have to perform preparation steps and then export, that is what i am following.
    What you said is right for single code page conversion method.
    upgrade first
    unicode conversion second.
    I am following CU&UC method.
    Thanks
    reddy

  • Combined upgrade and Unicode conversion for ECC5 MDMP system

    Hello,
    We are planning to do Upgrade and Unicode conversion of ECC5 MDMP system to ECC6 EHP4 Unicode. We are adopting Combined upgrade and Unicode conversion strategy to minimise the downtime.
       In source version ECC5 we are in support pack level 6. Should we need to update the support pack to any target version to start with CU&UC or we can start with ECC5 with SP 6 itself.
    Since we cant afford more downtime for support pack update also, is it ok to start with upgrade and unicode conversion with current version.
    please advice.
    Regards
    Vinay

    Hello Vinay,
    please note that as a prerequisite the Basis SP should be accurate for an MDMP conversion.
    There is no MUST to have the latest Basis SP, but without you could have severe issues in SPUMG.
    On the application side, there are in most cases no hard requirements on the SP level.
    Best regards,
    Nils Buerckel
    SAP AG

  • Combined Upgrade and Unicode conversion of Sap 4.6C to ECC6.0

    Hello all,
    my project team intends to carry out a combined upgrade and unicode conversion of an SAP ERP 4.6C system with MDMP to ECC6.0 (no enhancement package). The system is running on Oracle 10.2.
    In preparation for this upgrade, I have gone through the SAP notes 928729, 54801.
    We need to get a rough estimate of the entire downtime so as to alert our end users. From the CU&UC documentation in 928729, I read up note 857081. However the program in this note cannot be used to estimate the downtime as my system is < SAP netweaver 6.20.
    Is there any other SAP note or tool or program that I can use to estimate the downtime for the entire CU&UC? Thanks a lot!

    Hi,
    Combined upgrade depend upon number of factors like database size, resources on the server and optimization. In order to get idea of how much downtime, it will take, I would suggest you to do combined upgrade and unicode conversion on sandbox system which should be the replica of your production system. And try to optimize it. From there you can get approx. downtime required.
    Also, please read combined upgrade and unicode conversion guides on  http://service.sap.com/unicode@sap
    Thanks
    Sunny

  • 4.7EEx1.10 to ECC6.0 upgrade and Unicode conversion

    Hi Experts,
    We are going to initiate the upgrade from next month onwards. Subsequently i have started preparing the plan and strategy for the same.
    As our current setup is 4.7EEx110/Win 2003 R2-64 bit/Oracle 10.2.0.4.0 (Non unicode). And we have recently migrated on to this setup from WIn2k 32 bit. Also the current hardware is Unicode compatible.
    With respect to strategy for achieving this Upgrade and Unicode conversion, i am planning as follows.
    Step 1) Perform Unicode conversion on the current landscape (Both Export/import on the same servers)
    Step 2) Setup Temporary landscape as part of Dual maintenance strategy and migrate data from the current systems to temporary systems using backup/restore method.
    Step 3) Perform the SAP version upgrade on the current landscape and setup transport routes from temporary to current landscape in order to keep it in sync
    Step 4) after successful upgrade, decommission the temporary landscape
    Please provide your suggestions and valuable advices if there is anything wrong with my strategy and execution plan.
    Regards,
    Dheeraj

    Hi,
    Thanks. As i have already referred these notes as i am seeking advise with respect to my upgrade approach.
    However i have planned to perform in the following manner.
    1) Refresh Sandbox with Prod data and perform Upgrade to ECC6.0 EHP5 & subsequently Unicode conversion on the same server (Since both export & Import has to perform on the same hardware as we have recently migrated on this hardware which is Unicode compatible)
    2) Setup temporary landscape for DEv & QAs and establish transport connection to Production system in order to move urgent changes
    3) Keep a track of the changes which have transported during upgrade phase so that the same can be implemented in the upgraded systems i.e. Dev & QAS
    4) After Sandbox Migration and signoff, we will perform Dev & QAS upgrade & unicode conversion on the same hardware (Note: Since these are running on VMware can we export the data from the upgraded system and import on to a new VM?)
    5) Plan for production cutover and Upgrade the Prod system to ECC6.0 Ehp5 and then Unicode conversion. As i am planning to perform upgrade over the weekend and then Unicode conversion activity in the next weekend (Is it a right way?)
    My Production setup: DB on one Physical host and CI on separate Virtual host
    6) After the stabilization phase, we are planning for OS & DB upgrade as follows:
          a) Windows upgrade from 2003 R2 to Windows 2008 R2
          b) Oracle Upgrade from 10.2 to 11.2
    If anyone thinks that there is anything wrong with my above approach and need changes then please revert.
    I have one more doubt as I am going to upgrade 4.7EEx110 (WAS 620, Basis SP64) to ECC6.0 EHp5.As I presume that I can straight away upgrade from the current version to ECC6.0 Ehp5 without installing EHP. Kindly confirm
    Thanks

  • Wrong text in ADRC and LFA1 table after Unicode conversion

    Hello,
    We are doing MDMP to Unicode on SAP 4.7 system.
    In post unicode activities,we had corrected the garbage characters in
    table ADRC
    by converting to target langauage ZH using SUMG t-code.
    Condition used for addind table ADRC in SUMG is LANGU ='1' and
    LANGU_CREA = 'EN'
    But after converting and saving the data,most of the records have
    incorrect character in word.
    and text field of search term/company name/city in table LFA1 are also
    wrong in correspond field in table ADRC.
    Thanks
    Harshavardhan

    Hi Harshavardhan,
    Assumption: You have Chinese entries in table ADRC with ADRC-LANGU_CREA = EN
    Now you have to distinguish two problems:
    1) Chinese texts are stored in ADRC fields, which are NOT used for search help texts (most of the fields - e.g. ADRC-NAME1):
    These texts can be handled in two ways:
    a) Change LANGU_CREA = EN to LANGU_CREA = ZH for these entries (e.g. where ADRC-COUNTRY = CN) before the Unicode conversion (by the way, I would not use ADRC-LANGU, since this is the communication language, which does not necessarily comply with the code page of the entry).
    This needs to be done in a similar way as shown in z-reports described in  SAP Note 634839 ( although this specific fool-the-system case is not covered there - you have to adapt those examples)
    b) Use SUMG to repair the entries using language ZH (as you already did)  
    My favourite would be a), as this can be done before the conversion (Note that SUMG ineeds to be executed during downtime !)
    2) Chinese texts are stored in ADRC fields, which are used for search help texts (e.g. ADRC-MC_NAME1):
    a) If these entries were inserted / changed with logon language ZH, then point 1) applies
    b) If users logged on with logon language EN and created the entries, then most of these texts are destroyed already in Non-Unicode system. Then there is no automatic repair possible (at least point 1 does not work). Here my statement from before is valid:
    Those entries need to be generated again - e.g. if you do a dummy change on the name.
    According to my knowledge, this is a manual effort (either before or after the conversion) - but maybe it can be automized ...
    Best regards,
    Nils Buerckel
    SAP AG

  • R/3 Export & Import during Unicod Conversion via SOCKET Method

    Hi
    We are in the process of upgrading our R/3 Enterprise to ECC 6.0. The size of the database is around 4 TeraBytes.
    Can somebody help us with necessary documentation/ othe rinputs to handle R/3 Export & Import using SOCKET method?  FYI we referred the SAP given doucments on the same. Any particular DOs & DO NOTs would be highly appreciated.
    Thank You
    Sai

    Hi Rahul
    regarding your 'Unicode doubt"' some ideas:
    1) The Upgrade Master Guide SAP ERP 6.0 and the Master Guide SAP ERP 6.0 include introductory information. Among other, these guides reference the SAP Service Marketplace-location http://service.sap.com/unicode@sap.
    2) In Unicode@SAP can you find several (content-mighty) FAQs
    Conclusion from the FAQ: First of all your strategy needs to follow your busienss model (which we can not see from here):
    Example. The "Upgrade to mySAP ERP 2005"-FAQ includes interesting remarks in section "DO CUSTOMERS NEED TO CONVERT TO A UNICODE-COMPLIANT ENVIRONMENT?"
    "...The Unicode conversion depends on the customer situation....
    ... - If your organization runs a single code page system prior to the upgrade to mySAP ERP 2005, then the use of Unicode is not mandatory. ..... However, using Unicode is recommended if the system is deployed globally to facilitate interfaces and connections.
    - If your organization uses Multiple Display Multiple Processing (MDMP) .... the use of Unicode is mandatory for the mySAP ERP 2005 upgrade....."
    In the Technical Unicode FAQ you read under "What are the advantages of Unicode ...", that "Proper usage of JAVA is only possible with Unicode systems (for example, ESS/MSS or interfaces to Enterprise Portal). ....
    => Depending on the fact if your systems support global processes, or depending on your use of Java Applications, your strategy might need to look different
    3) In particular in view of your 3rd option, I recommend you to take a look into these FAQs, if not already done.
    Remark: mySAP ERP 2005 is the former name of the application, which is named SAP ERP 6.0, now
    regards, and HTH, Andreas R

  • Effort estimate (ABAP) during Unicode Conversion project

    Hi ,
    I am working on a CU&UC (Combined Upgrade and Unicode Conversion) project from 46C to ECC6.
    We are having 8 different codepages (MDMP SYSTEM) and around 10000 custom objects.
    Does anyone have any experince in doing such kind of project ? I am looking at the effort estimate on technical side (ABAP) and functional side.
    Any inputs of Technical effort in such a project with related number of codepages and custom objects will be useful (in man days & project duration).
    Thanks
    Dilip

    Hi Dilip,
    the main effort from ABAP side seems to be testing of the new system and creating the Unicode vocabulary. You need test teams and test plans for all locations and for the vocabulary you need people for all your languages. ABAP coding itself is probably not your biggest problem. You have to switch your system to unicode and then check all your sources. This could be done by a report or transaction (check the documentation regarding the Migration). From my point of view this is the main effort you'll have, testing and building the vocabulary. How big this effort is depends on your system. I think six month are a good time frame for the whole project (I assume you migrate a landscape of 3 systems). Because I'm working in the Basis administration I could not tell you the exact man days, but I would estimate up to two weeks for the vocabulary per language. You should have the numbers for the system tests from previous upgrades.
    The technical migration effort depends on your hardware and time requirements. If your system is big (TBytes) and your downtime is very limited it could be necessary to tune the migration by testing it several times. If your requirements are not that high, then a single test migration could be sufficient. I've done two bigger migrations with 2.5 and 3.5 TB in less than 24 hours but therefore you have to have fast hardware and you have to tune your process well. If you have a single huge table this could destroy all efforts reaching your time target, if for example the index build could not be done in less then your time target. If you have enough hardware resources and time to tune your migration you could reach almost any time (which makes sense - some hours).
    Best regards
    Ralph Ganszky

  • Doubt about unicode conversion

    Dear Friends,
    I have a doubt about the unicode conversion. I have read (one server strategy) that I have to do export (R3load), delete the ECC 6.0 non-unicode, install an unicode database and then import with R3load. My doubt is about the deletion of ECC 6.0 non unicode. Why?  can I convert to unicode only with an export (R3load) and subsequent import (R3load) without any deletion?. Obviously I must to change the SAP kernel with a unicode one. Is it correct?
    Cheers

    you can not convert a SAP System to unicode by just exchanging the executables from non unicode to unicode ones.
    a non unicode SAP Oracle database is typically running with a database codepage WE8DEC or US7ASCII (well this one is out of support).
    so every string stored in the database is stored using this codepages or SAP-Internal codepages.
    When converting to unicode you have to convert also the contents of the database to unicode. As unicode implementation starts at a time where Oracle did not support mixed codepage databases (one tablespace codepage WE8DEC the other one UTF8) inplace conversions are not possible. To keep things simpler, we still do not support mixed codepage databases.
    Therefore you have to export the contents of your database and import it to a newly created database with a different codepage if you want to migrate to unicode.
    regards
    Peter

  • MDMP: TWIN Upgrade + Unicode conversion

    Hello ,
    We have adopted twin upgrade and unicode conversion method and at present we are converting the twin system to unicode conversion.
    In Twin system we have completed SPUMG 7 scans. Whether i need to run UMG_TWIN_CREATE_TRANSPORT  now to save the results for twin preparation run or i need to perform this step after Additional preparatory step.
    Kindly suggest
    Regards
    Vinay

    Hi Vinay,
    Excerpt from the UCG:
    2.4 Final Preparation Steps
    2.4.1 SPUMG Updates
    If there is a time difference between the scan and the database export, it may happen that a new table has been created or a Support Package has brought a new table with it. In such a case, the preconversion must be rerun right before the export is carried out to ensure that the data change is reflected in the Export Control Table.
    End excerpt
    Hence this step is necessary in case of DB changes (e.g. new tables with or without  content).
    Therefore if you have significant changes, I would recommend to create the twin transport after this step.
    However this step has to be repeated in the PRD system as well (see TU&UC-Guide) to reflect the changes between Twin and PRD system. In order to minimize downtime, the differences between the two systems should be small.
    Best regards,
    Nils Buerckel
    SAP AG

  • Unicode conversion - space allocation

    Hi All -
    We are starting to look at converting our system to Unicode this summer, and I'm worried that we have enough space allocated on UNIX box to allow for successful conversion!
    I have read the Unicode conversion guide for allocating additional space to tablespaces on the database, but does anyone have any words of caution / wisdsom for non-tablespace related space needs during a Unicode conversion?  For example, I think I have all our /oracle/[sid]/sapdata directories accounted for - I am just trying to determine if I'm missing anything else.
    Input is appreciated.  Thanks!
    Abby

    Hi Abby,
    additional Hardware requirements due to Unicode are described in SAP note 1139642.
    There are no general rules for the additional hardware components needed for a Unicode conversion.
    This highly depends on your planned scenario (One Server inplace / new Unicode server) and your downtime requirements. But even knowing the details no one will be able to give exact figures.
    If you are lucky, you might find someone who did a similar scenario on comparable hardware.
    However we highly recommend to plan for a Sandbox conversion (with a copy of your PRD system), which will be the best approach to find out reliable downtime figures and possible hardware bottlenecks.
    Please also have a look at SAP note 857081.
    Best regards,
    Nils Buerckel
    SAP AG

  • Unicode Conversion approach

    HI All
    During Unicode approach isit possible to do the conversion of custom and standard program to unicode and make the system live and later on do the data conversion with business downtime.
    The reason i am asking so as to reduce the business down time. We are going for CU&UC and donot want a long business downtime.
    Let me know if there are any approach where we can do the data conversion in the later phase.
    Thanks
    Rajat Sarkar

    Hi,
    please have a look at:
    http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000380759&_OBJECT=011000358700000620342009E
    > Page 21
    Excerpt begin:
    1) Start release >= SAP NetWeaver AS 6.20
    > UCCHECK can be run before or during Unicode conversion
    2) Start release <= 4.6C (CU&UC or TU&UC*)
    > Execute the whole UCCHECK procedure in the SBX Unicode system
    > Upgrade the DEV system to SAP ERP 6.0 (Non-Unicode or Unicode) and execute UCCHECK (Additional Maintenance System necessary)
    Excerpt End.
    Therefore if you have a 4.6c system (or lower) as source system, then the Unicode enabling procedure (UCCHECK) cannot be separated from the actual Unicode conversion (Export / Import). In case of NW 6.20 or higher, you can do most of the enabling before the conversion (you will still need a rework after the conversion).
    Best regards,
    Nils Buerckel

Maybe you are looking for