At many recent gatherings of technical colleagues, the question has been raised more than once as to whether it is good practice to archive SAP data and/or extend data archiving projects before a Unicode conversion. Although there is, of course, interest in the space savings gained by archiving data before a Unicode conversion, I have found the more common reason behind the inquiry is a concern about being able to access the archived information after the conversion. In order to answer this concern fully, it is necessary to understand the technology that underlies the data archiving process at SAP. The tool at the heart of this process is the Archive Development Kit (ADK); it provides the required functionality to write the archived data in such a manner that it can be read from the archive later without regard to operating system, hardware, data conversions, or code pages used. ADK also provides additional operational functionality but these capabilities are outside the scope of this blog. ADK methods include certain Meta data in the data records that are written to the archive file, a so called "flat" file, in the file system during archiving. This Meta data allows for the efficient and effective reading of the information in the archive file during any later access to it. In addition to other information, the Meta data contains information about the code pages used when the data was written to the flat file. Therefore, whenever an end user inquiry later requires reading archived data from the file system or 3rd party storage system, the information can easily be decoded and presented in the proper format using ADK methods. Of course, the data in the original file is never changed—the system simply reads and translates the information into the appropriate format for the system in which it is being read. It is just this functionality that makes the archiving of data before the conversion to Unicode in your environment a realistic and desirable option. Now that you know that you will have no problems reading your archived data after a Unicode conversion, what are some other considerations involved in such a conversion? A major benefit of course is the fact that any conversion will proceed more quickly when there is less data to be transformed. This is an obvious advantage and makes good business sense from the perspective of reducing your system downtime during a switchover to Unicode; i.e., less data means a faster conversion, which in turn leads to a quicker uptime of the system after the conversion. But what about database space? Estimates, such as the ones provided in the Apr-Jun issue of the SAP Insider magazine article, “Unicode: Overhead or Necessity?” state that you can expect to add approximately 10-30% to your onsite database storage requirements after a conversion. Here data archiving can also help. If you reduce the amount of data to be converted prior to the conversion through data archiving, then the space savings in the converted database system will also be higher. Consider, for example, the case of a 100 byte record which has been fully archived prior to the conversion. Given the 10-30% increase factor range mentioned for the Unicode conversion, the space allocated in the converted system without the archival of this 100 byte record would be 110-130 bytes. However, if this record is archived prior to the conversion, then no space at all would be required for it. By pursuing a more proactive archiving strategy prior to the Unicode conversion, initial allocation of space for the converted database will be reduced accordingly. Additionally, the Unicode conversion by its very nature provides a reorganization of both the tables themselves and their indexes. After data archiving, table reorganizations may be desirable and would lead to maximum space gains; however, in normal operation, such reorganizations may not be practical, due to time and resource constraints. Archiving before a Unicode conversion has the additional benefit of a complete DB reorganization. This automatic reorganization during the Unicode conversion process will return even more useable space to the active online database in the near term from the tables that have been actively archived. Index reorganization becomes an added bonus in any space savings, but primarily will assist with better performance in the system. Of course, any files or storage locations containing data archived prior to the conversion will not increase in size at all after the conversion. They remain available, as before, for access as required. And due to improved ADK compression techniques, even files or storage locations for archived data filled after the Unicode conversion is completed will show little or no increase in size from that which could have been expected before the conversion. (See SAP Note 705447 for a correction to a short-term exception which may occur between SAP Web Application Server 6.20 to 6.40.) To summarize, the addition of new or extended archiving projects before the Unicode conversion in your environment, can yield positive results in multiple areas with no risk to your ability to access that data again when needed.
