Scope & objectives**
To minimize the risks involved in the Unicode and to improve the performance of the Unicode also to reduce the Downtime.
Business Benefits**
Accelerated Unicode conversion.
Reduced downtime.
Reduced hardware / RAM /CPU requirements.
Salient Features**
Unicode is the International character-encoding standard that allows text data from different languages to be stored in one repository.
Unicode is prerequisite for all new technologies and any new and future code pages and characters.** **SAP provides lots of tools to convert existing non-Unicode to Unicode system. In a single code page system, all application servers and the database use one standard system code page. Multiple Display / Multiple processing (MDMP) systems deploy more than one system code page on the application server.
Planning Unicode conversion process**
Preparation: Check prerequisites. Data analysis for downtime minimization, special MDMP treatment.
Conversion: System will be down during database conversion. Upload / reload process for small databases. Minimum downtime tools for large databases.
Post-conversion: Unicode system is up and running. Verification of data consistency. Integration testing focused on language handling.
By following the below approach, the risks can be mitigating for a successful BI Unicode.
The challenges facing BI projects can be technical, or fiscal in nature. Discover how to eliminate problems before they occur, by preparing for them from the outset. Learn about common mistakes, find out how to avoid them and understand how successful projects can be executed. While doing BI Unicode conversion, migrate non-standard database objects, need to generate DDL statements using the ABAP report SMIGR_CREATE_DDL, perform this procedure before starting SAPinst. Additional database-specific information, see also SAP Note 888210.
Downtime optimization**
One aspect to consider before beginning with the conversion preparation is reducing the data volume in tables that are commonly associated with high data growth by means of archiving and or deletion (SAP Note 679456).
Use separate database server for export and import, so you can, install and prepare the Unicode database while the Non-Unicode system is still running. Run export and import in parallel (using Migration Monitor; see SAP Note 784118).
Determine the largest tables (typically n=50-200) via transaction DB02 and put them into separate packages.
Distribute the R3load processes on multiple machines (using Distribution Monitor; see SAP Note 855772).
Parallelize processing of very large tables using table splitting (see SAP Note 952514).
Optimize settings of your database (see SAP Note 857081).
Export the largest tables unsorted (see SAP Note 954268).
Create the indices for the largest tables in parallel (see SAP Note 954268; only available for Oracle databases)
Preparation steps that can be already done while the Non-Unicode system is running productively**
The following preparation steps can be executed at any time while the source system is still running productively. Determine split points for table splitting with R3ta (if used) Install target database. Trigger initial RADCUCNT run to build first Unicode nametab. The following preparation steps can be executed after the last change that affects the data dictionary of the source system has been done.
Final RADCUCNT run to update Unicode nametab.
R3ldctl run (to create packages (*.STR) files for R3load R3szchk run (to determine package sizes). Package splitting Distribution Monitor preparation (if used)
Post processing steps that can be postponed until the Unicode system is up and running productively**
The following steps maybe executed, while productive usage of the Unicode system has already started. System performance maybe affected. Manual SUMG repair for tables, where existing entries are not changed during productive usage(e.g. DBTABLOG, CDCLS). ABAP Program generation with transaction SGEN Update of database statistics.