MCOD - Frequently Asked Questions
We have classified your various queries under three broad categories for easy navigation . Please click on any of the links below to find answers on a topic of your choice
1. When will the technology be available for customers? Are there any restrictions on supported components, hardware, databases or operating systems?
The technology is scheduled to be available with the SAP Web Application Server and all mySAP.com components that incorporate it with their next release. SAP continues to deliver platform-independent solutions and thus makes this technology available on the major database platforms supported by SAP. Details about the mySAP.com components that currently can be used in an MCOD installation can be found here.
2. What effort is involved for customers who wish to implement this technology? Is the technology supported for SAP R/3? What is the transition path for existing components?
Using this technology is as straightforward as installing a separate component. Thus, no extra effort is required. SAP R/3 customers need to upgrade to mySAP.com (including the latest SAP R/3 4.6C component) or SAP R/3 Enterprise.
3. Do you have any customers that are running Multiple Components in One Database?
The option to implement this is available to first customers since Q2/2001.
4. Can you quantify the benefit of this technology? How much hardware can be saved? To what extent can operating costs be reduced?
Initial estimates based on project experience show that around 10% of disk space and around 30% of hardware backup costs (tapes, tape drives, disk systems) can be saved. Initial estimates place operating cost reductions at around 40% for managing backup administration or high-availability concepts.
5. Now there is the option to run multiple independent components in one database. What is the impact on performance?
Running multiple independent components in one database is an additional option. If all other factors remain the same, performance is not adversely affected. Maximum scalability is still achieved by using one database per component.
6. Do customers have to change the business logic in order to implement Multiple Components in One Database?
All SAP components are built on a clearly separated architecture that distinguishes between business logic and technology. Changes in the technology layer do not affect the business logic and business data of the component. The components continue to be independently changeable without restrictions.
7. Can this solution also be installed on an existing R/3 System?
Yes, if you have release 4.6C SR2 or higher.
8. When I install my system for the first time, can I choose the e-business solution I want in one database or on one server?
Yes, if the product in question is released for Multiple Components in One Database. So for example in an MCOD installation that should contain an R/3 system and a CRM system you can first install the R/3 system and then add the CRM system using the already existing database instance of the R/3 system. Or alternatively you can start with the CRM system and later on add the R/3 system.
9. Will the solution affect customizing and table access? For example, does the Implementation Guide (IMG) call the right tables?
The products are still separated logically even though they reside in one database. Therefore, there are no common customizing tables. The IMG, for example, will always call the right table, that is, the one that belongs to the product.
10. If I remove an e-business solution at a later date, will the tables with the specific IDs remain or will they be deleted?
They will be deleted. The migration tools completely delete from the database all database objects that belong to the removed component
11. Will there be a separate release cycle to meet existing release dependencies?
No. There are no release dependencies because the individual components reside in the database while still being completely independent from one another. Therefore, their technology infrastructure releases can be different. Also, the individual components can be upgraded at different times.
12. Which system landscape is officially recommended by SAP?
The official stand from SAP regarding server and database landscaping has not been changed. Which solution is practical depends on the customer’s landscape and requirements. This slide shows possible deployment options using MCOD.
13. Are parallel databases available and supported?
Yes. Currently DB2/390 is the only database platform which can be used in parallel mode for all SAP scenarios (see section Questions concerning IBM zSeries). SAP will evaluate the usage of parallel databases as a possible solution for higher scalability on the database side.
14. How do you monitor performance if you have Multiple Components in One Database?
The administrator will still have the familiar CCMS (Computing Center Management System) for database monitoring. SAP plans to enhance this tool to monitor separate components.
15. How long does it take to upgrade the database?
It depends on the RDBMS used. Usually it takes between approximately 15-60 minutes to upgrade the database software. For DB2/390 the procedure might be even faster.
16. Are system copies supported?
System copies are currently supported by an export and a subsequent import of the system data using R3load.
17. Is there any information already available on sizing?
Sizing multiple components in one database is possible by sizing each individual component using the SAP Quick Sizer and then adding the requirements for those components that share a common resource. That means, all values gained for the database have to be added, because the database is shared by all systems. For the other values it depends how the installation is performed e.g. if all central instances share the same hardware, also these values have to be added. If the central instances are split on several machines, the values can be treated individually. SAP will work on additional sizing options once it has gained more experience with controlled installations.
18. What about the network infrastructure that is required with the mySAP Workplace?
The mySAP Workplace itself does only need a Web browser on the desktop and works with standard Internet protocols. The network load of the mySAP Workplace depends mainly on the network load of the integrated components. Please see the Workplace conventions and requirements for further information.
19. What are the target groups for the installation of Multiple Components in One Database?
Basically, all customers can benefit from the new installation option. However, SAP recommends customers the installation of development or test systems with this option first to gain more experience.
20. Are there any benchmarks planned for Multiple Components in One Database?
SAP Standard Application Benchmarks are already available for each component. Benchmarking multiple, independent components in one database is possible
21. Do you already have statements from analysts?
An analyst for Gartner Group Inc said: "With its single-database technical architecture and professional sizing capability, SAP is the only e-business software vendor to have scaled to 1,500 concurrent business users in the real world. mySAP.com now offers more flexibility to customers needing to operate multiple applications with a single database."
22. Is MCOD a good fit for all customers or customers of a certain size?
Considering the option on installing multiple components in one database is independent of the size of the IT landscape. For example, you can consider using Multiple Components in One Database to manage development systems, quality assurance systems, test systems, and training systems as well as for productive systems.
23. How do you handle backup-recovery issues?
One of the advantages is that you are able to consistently back-up and recover multiple e-business components using only one database.
24. Is the size of this box CPU/Memory must have to be very large to be able to share these resources?
This depends. The sizing of the system landscape has to ensure that the complete workload of all installed systems can be handled simultaneously. DB2/390 even can expand into parallel database to avoid bottlenecks on the database side (see section Questions concerning IBM zSeries)
25. Can I use MCOD in conjunction with the Microsoft Cluster Server (MSCS)?
No, currently we do not support MCOD installations in conjunction with MSCS due to some restrictions for the joint fail over of the central instances of the single systems in such a setup which does not allow full functionality of the cluster.
26. If I start an MCOD installation with new systems from scratch. Which system should be installed first?
Normally you should start with the system that requires the highest basis release. Going this way you will install the newest database version with the first system and no database upgrade is necessary.
27. Do I have to pay additional fees if I want to use MCOD?
No, MCOD is an additional installation option that can be used without additional payments. There are no changes made to the existing license conditions.
28. Does the license model change with MCOD?
No. MCOD has no influence on the license model. Even for the commonly used database a database license has to be available for each SAP system which is installed in this database.
29. Can I use the IDES scenario within an MCOD installation?
The IDES scenario provides master data, transactional data, and customizing data that represents a fictional company. This data is stored in client 800 and has no specialties that impedes the usage of IDES in combination with MCOD.
1. I already have a two SAP systems installed each one using its own database. How can I migrate both into the One Database solution?
First, both system have to be a release level that supports MCOD. Then we suggest to migrate the smaller DB into the larger one using the export and import features.
2. Will I run into security problems when installing several different components on one DB?
Using database schemas, the technological basis of MCOD, it is possible to logically separate the individual systems so that they don't influence one another. This applies to DDL and DML operations.
3. If there are space overflows in one system, will this affect the other systems?
No. Most databases separate the different tablespaces for the components. Only SAP DB and SQL Server might run into problems because these databases behave like a single container.
4. Is there a checklist for detecting problems when using the same resources?
You can check the following: 1) Have you split memory consumption of the DB server by users? 2) Have you split expensive SQL statement of the DB server by users? 3) Have you split space consumption and Space3 overflows by users? 4) Have you defined a master for administration such as for backups? 5) Have you clearly defined locking methods on the DB Dictionary?
5. In which system should I schedule backup dates (Transaction DB13), DB parameter changes and so on?
You should perform planning and scheduling in one system, only.
6. Will my upgrade of one system affect any of the other systems?
In general, the systems are completely independent from one another. During an upgrade, DDL operations take place which may incur in wait times for those components which do DDL operations at the same time. In this case there may be wait times on the DB Dictionary itself. However, DDLs have very short runtimes which is why you will probably not notice that wait times.
7. How many users do I need for administration (transports, etc.)?
The same as you had before. The different DB schemas are reflected in the environments and profiles of the ADM users.
8. I am using Oracle database. Do I have to increase the number of rollback segments or is it sufficient to increase PSAPROLL. How about PSAPTEMP?
You should increase both, PSAPROLL and the number of rollback segments to avoid possible contentions. Note that large JOINs and SORTs may not occur in all systems at the same time so that you have the opportunity to save memory consumption, particularly shared memory.
9. Is the combination of Unicode and non Unicode based systems in a common database possible?
Currently only on the DB2/390 platform a combined installation of Unicode and non Unicode based systems is supported. With more actual releases from other vendors, SAP will support the combined installation also for other platforms. If you intend to combine Unicode and non Unicode systems, please contact SAP.
10. I am using DB2/390 database. What do I have to watch out for in addition?
Please see section Questions concerning IBM zSeries.
11. Is it possible to run systems with different languages in one common database?
For an installation that contains only Unicode based systems, this is no problem. For non Unicode based system it depends on the database as shown in the table below. Please also notice question 9.
DB2 on zSeries
* Only if the data inthe used code page of the database is a superset of all required languages
12. Can I use the sapdba tool for the Oracle database to perform a system copy?
No, at the moment sapdba does not support the copy of a single system in an MCOD installation. To copy a system that is part of an MCOD installation you have to export the system from the database using R3load. Then you can import this data to a newly installed system also using R3load.
13. Can I use MCOD in combination with Unicode?
For details about the support of Unicode installations, please refer to SAP note 79991.
14. The new tablespace layout for Oracle introduced with MCOD contains the SAP system ID in the tablespace names also for single system installations. How can I perform a system copy for such a system?
SAP note 617444 describes in detail how the system and the database has to be set up.
Questions on IBM ZSeries
1. What about the availability of MCOD for the DB2/390 platform?
The availability is dependent on the SAP components and their releases, but not on the database platform. MCOD is available on DB2/390 since end of 2001 on SAP R/3 4.6 and mySAP.com components based on Web Application Server 6.20 and higher. For additional information see Actual Status of Availability.
2. How many SAP systems can I deploy in one DB2 database?
For systems based on the SAP 4.6 kernels, not more than 5 systems should be put into one database. With SAP technology 6.20 or later customers can put up to 20 different SAP systems into one DB2 database.
3. Can I use database tools to backup or copy single systems from MCOD database?
When residing in the same database different SAP components are defined with different database schema and their tables do not share the same tablespaces. Consequently backups of individual DB2 tablespaces and indexes can be taken and used for SAP system recovery purposes. Note that each component can be separately recovered to current time (end of logs).
For a prior point in time recovery, however, you need to recover all the components within the same database. The reason for that is the DB2 catalog and directory which are shared by all the components.For the same reason it is impossible to use database means for homogeneous system copy of individual components, but rather do it by SAP tools
4. What about the system performance if I put several SAP systems into one database?
Certainly it is needed more resources for the database work than with a single system, but less resources than the sum of all the systems within the database, because the load is much better balanced using this architecture. Resources like CPUs and memory can easily be added by expanding into a DB2 data sharing system.
5. Is it possible to use MCOD with the DB2 data sharing mode?
Yes! DB2 data sharing is very well suited for the SAP's MCOD initiative. This is especially true for productive environments in which data sharing deployment is strongly recommended. Each data sharing member should be connected to the set of application servers dedicated to a particular SAP component. The SAP components in one database are stored independently from each other and using DB2 in data sharing mode you will not see any resource conflict between the data sharing members. With the MCOD setup a very high degree of scalability can be achieved.