cancel
Showing results for 
Search instead for 
Did you mean: 

Compression and Unicode conversion

Former Member
0 Kudos

Hi Experts,

I have a question about Oracle 11g Compressed tables and Unicode Conversion . When doing Unicode conversion , will the compressed table be uncompressed and re-compressed during unicode conversion ?? Any known impacts due to compression on unicode conversion.

Thanks

Prince kudilil

Accepted Solutions (1)

Accepted Solutions (1)

former_member189725
Active Contributor
0 Kudos

Yes , it will be uncompresssed and compressed again. This is beacuase R3load will read the rows uncompressed as the fetch would basically use the dictionary to uncompress rows. Then R3load would do the character conversion and store the data into dump files . During import the data would be imported by R3load and the insert or load would basically compress the data again.

Answers (2)

Answers (2)

stefan_koehler
Active Contributor
0 Kudos

Hi Prince,

yes the Oracle Advanced Compression is fully supported by R3load.

An unicode migration is also based on the R3load mechanism - so if your source database (or only a few tables) was already compressed - your target database will be compressed too. Before you export your database you have to run the ABAP report SMIGR_CREATE_DDL which gets the definitions (and also the compress options). The generated file is used for the import then.

For more detailed information check the following sources:

- Sapnote #1436352: Supported operations (OCI Direct path)

- [Uwe Specht Whitepaper (Compression, ASM, SMIGR_CREATE_DDL)|http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/f0774cd8-03dd-2d10-0897-8ca1ffc388ec?QuickLink=index&overridelayout=true] - Page 13 / 14

Even if your tables keep compressed in the target (unicode) system - you maybe see that the tables are larger as in the source system. This is "normal" and depends on your used characters (some unicode characters need more space).

Regards

Stefan

Former Member
0 Kudos

Thanks Stefan. So if there are many huge compressed tables ( 400gb+ ) exist in source system, the migration time and the space requirement can increase considerably ?

Thanks

Prince Kudilil

stefan_koehler
Active Contributor
0 Kudos

Hello Prince,

well the definition of migration time is composed of export and import time.

The export and import time depends on your I/O storage subsystem, source/target database server (utilization is important for advanced export methods like splitting, parallelism, manually defined access paths and so on), and CPU power of R3load application server.

The table compression itself does not have an impact on the R3load application server part, but can reduce the export time significantly if the export is customized (like parallel FTS). By default it is done sorted (by primary key index used) so you will not have a huge benefit.

What i meant with the possible increasing space has nothing to do with the compression itself - it was about the used bytes in UTF-8 encoding: http://docs.oracle.com/cd/E11882_01/server.112/e10729/ch6unicode.htm#i1006779

Regards

Stefan

Former Member
0 Kudos

Hi Stefan,

Thanks for the details. I was under the impression that the compressed table will have to uncompress during export and then compress again during import, thus extending the time for export and temporary space for keeping uncompressed data during export.

Thanks

Prince Kudilil

former_member188883
Active Contributor
0 Kudos

Hi Prince,

Unicode conversion is achieved with the process of exporting the database and importing it into a unicode code.

During this export and import database already gets compresses.

Coming to your question , In case you have implemented Oracle 11g compression activited, You need to ensure that these settings already exits in your target system. If yes, then imported system will data stored in compressed format as per Oracle 11g settings.

Regards,

Deepak Kori