
The extra upgrade load is caused by importing client-specific table entries for the Customizing settings. The more clients in a system, the more imports, since these entries must be distributed to all customer clients (cascaded).
New tables for new functions are usually shipped with content. Client-specific tables, whose delivery class (E, G, S, or W) cascades them into all customer clients, contain data that must be imported into all clients, and not just into a single target client. The overhead rises in an approximately linear relationship with the number of clients. The extra load is mainly concentrated in the upgrade phases TABIM, XPRAS, and LANG_IMP.
You must take extra clients into consideration when you size your database. If the data of the basis database system is structured in tablespaces, then the following tablespaces are affected:
| PSAPSTABD | +2% |
| PSAPSTABI | +4% |
| PSAPPOOLD/-I | +8% |
| PSAPBTABD/-I | +1% |
The actual increase in imported data varies of course from case to case.
This estimate was derived from various measurements, but can vary slightly. It is always a good idea to limit the number of clients at an initial stage, so that you are not confronted with unacceptably long upgrade downtimes at a later point.
You must evaluate the costs you save when operating a system with multiple clients against the increase in system downtime, and come to an appropriate decision.
The main phase of the upgrade, in which the system shuts down, substitutes the production database with the prepared tables with relatively little effort. This also reduces the total length of downtime. However, when you plan your system operations, you must remember that the cascade overhead described above remains an issue. The cascade phase is just relocated from downtime to the upgrade preparation phase, which means it competes with production operation of the system. However, you can usually solve this conflict by organizing your system operation effectively.