- In MS SQL Server Management studio
- Execute SELECT BNAME FROM hrs.USR02 WHERE MANDT='310';
SAP NOTE 118823 - CC-ADMIN: Size of a client
To be able to schedule client copies and also for system planning, the size of clients or tables in a client is required.
In productive environments some tables can become very large. This is important both for performance planning and for system planning.
For local client copies or remote copies you can carry out a tablespace analysis in the log after a test run. This analysis estimates the memory space required. For the latest information refer to Note 35415.
Depending on the release, typical Customizing clients have the following sizes:
3.0: approx. 150 - 200 MB
3.1: approx. 200 - 250 MB
4.0: approx. 350 - 400 MB
4.5: approx. 450 - 500 MB
4.6: approx. 150 - 1500 MB *
* depending on the components of mySAP.com applied
Production clients with application data can of course be considerably larger.
The following reports shall help you to estimate the memory requirements of a client. However, you must know that there is no 'optimal' memory requirement for a client on the database. Each tool uses its own estimation that occasionally leads to very different results (for more information, refer to point 3 of Note 35415). In any case it is recommended that you also use the tools of the database or of Transaction DB02 to be able to evaluate the estimations.
You also need to consider that for client copies into an already existing client, you can only partly calculate the memory requirements of the new client with the existing size of the client (for more information refer to point 2 of Note 70643).
The reports have a problem in principle with tables that are not stored transparently, but as POOL or CLUSTER tables. This data is heavily compressed, and the results of the reports are clearly too high as a result. The tables in question are mostly found in areas of the database that have corresponding names, such as PSAPCLUD or PSAPPOOLD and so on. Examples are: POOL table ATAB, CLUSTER tables RFBLG and AABLG.
For information about the table category, go to the ABAP dictionary (Transaction SE11). As of Release WebAS 6.20, the table category of the respective table is specified in the output list of RSTABLESIZE. You can use this to sort and filter the data accordingly.
As of Release WebAS 6.20, reports RSSPACECHECK and RSTABLESIZE give you the option of replacing the CLUSTER tables with the CLUSTER. This takes the compression into account. (This is in accordance with the behavior of the client copy. Therefore, as of Release 4.6, you should carry out a client copy test run in another client in the system to analyze the system resources, instead of using report YKSPACEC. You would then have the option of carrying out an analysis of the areas of the database in the log display (Transaction SCC3)).
- You can decide the size of individual tables in a client with the enclosed report YSTABSIZ as of Release 4.0. For Release 3.x, there is the equivalent program ZSTABSIZ. As from Basis Release 6.10, you can use report RSTABLESIZE as delivered.
Both the table name and the client can be entered generically. Thus, you can determine the distribution of a client with the table name '*' and the distribution of one table to different clients by entering the table name and the client '*'.
Furthermore, it is possible to exclude tables of delivery classes 'L' and 'A' from the selection.
The report delivers the number of the entries in table, the table width and the memory requirement in bytes. In this case, the memory requirement is the result of the maximum row width and the number of rows. The value might differ considerably from the needed memory requirements if the table entries are on average considerably smaller than the maximum width. Also, the results might be affected if a compression is used.
- To calculate the memory requirement in a subdivided manner by database areas, use the attached program YKSPACEC. As of Basis Release 6.10, you can use report RSSPACECHECK as delivered. However, these reports run only on databases with database areas (INFORMIX, ORACLE, ADABAS and DB2/CS), i.e. not with DB2/400.
For ORACLE and INFORMIX, please make sure that you have implemented advance correction 228745 from Note 35415.
The report delivers the memory requirement of the tables in the database areas affected and the free space in the database areas in KByte. Depending on the database used, this is a more or less exact estimation of the memory actually used in the respective database areas.
- There is a request in the queue for which "Target Client" is not specified.
- Delete that request of specify the target client which "clt" is empty or in red.
- Now try again.
- System Administration
- System Configuration
- Keystore Administration
- In the table above we can see the expiration date.
- Now we generate new certificate via Virtual Admin
- Go “Server”, then “Services” and then find and click once on “Key Storage” in the “Services” list. You will be presented with the below screen.
- Now we click create in the Entry area.
- An entry name “SLTKNEW” for now
- The Common Name (CN)
- The Organization Unit Name (OU)
- We have given the certificate a validity period of 10 years in place of 1 year that was previously assigned.
- We need to check “Store Certificate”
- Leave the Key Length as the default of “1024”
- User the drop down on “Algorithm” and choose “DSA”
- Once done choose “Generate” and looks like below
- Now we can activate and use the new key certificate.
- Once we have verified that the old and the new are aligned with regards to their common attributes and the new one is active for usage we need to export the old one to keep it safe for now. This is done by clicking on the “Entry” then “Export” button.
- Now that we have a protected backup of the original we can instate the new one we have just created. To do this we can either delete the old one or in this case (recommended) rename the old one for now.
- We have chosen to rename it using a timestamp identifier of “20110103” to indicate the date this was renamed. We need to do the same with its pair (Private Key).
- Once this is done we take the names of the original duo and reuse them on the new ones we have just generated. Please note that these need to be given exactly the same name as the original names and are case sensitive.
- SLTKNEW is now (SAPLogonTicketKeypair)
- SLTKNEW-cert is now (SAPLogonTicketKeypair-cert)
- Once this has been done we can then log back into the BI Portal and verify the effectiveness of the change.
- We may now export the certificate to Abap system.
- Start by pressing the download verify .def file button above and save the file to your machine.
- To import, go STRUSTSSO2
- Click import certificate
- Locate the certificate you wish to add.
- Now check the certificate
- Once we have verified that the new certificate is in place. Simply delete the old one from the list using the “Delete” button once you have verified you are highlighting the correct - outdated certificate in the list
- Now that we have renewed the certificate we need to ensure that the old entries are removed from the ACL and that the new one is re-added as it is has a different Serial Number as previously discussed.
- To do this, delete one at a time and then replace it. We have started by deleting the ACL entry for B0M against client “000” first and then re-adding it as in the below screenshot
- We have then deleted and re-added the entry for the non-existent client “999” as follows.
- The resultant output is that we now have the ACL also updated with the latest certificate information for the SSO to function correctly. If this is not done and the old entries are attempted to be re-used then the resultant outcome is an issue when loading web templates as follows
2. Go to: active server -> Services -> LogConfigurator.
3. Click "To Advance Mode".
4. Go to the tab "Categories".
5. In each Severity field of all the logs, set the value to Error.
6. Go to the tab "Locations" and repeat the step 5.
7. Go to the active Dispatcher and repeat steps 2-6.
8. If there are more active servers, repeat the procedure for each Server
and Dispatcher node of each on of them, for the entire cluster.
9. Restart the server.
- Open url http://domain.com/sso2
- If fails try http://domain.com:50100/ss02 (5 is fixed, 01 is your instance number and 00 is the port)
- Enter user j2ee_admin or any id which you have authorization to access the portal
- Click "I Agree" if you see this error. If not, then you may continue scrolling down to check your expiry date:
- The expiry date
- In ABAP you may check from Tcode strustsso2
- Then double click on the certs you see on you screen such as:
- You will be able to see the expiry date
- Open URL http://<server>.com/useradmin
- Enter valid user ID and password
- Enter a user ID (our case we choose Administrator).
- Select administrator by right clicking on the row
- Details of user Administrator will appear below
- Click Modify
- Select Assigned roles or Assigned Groups tab (ask the requester what need to be added)
- This example we add SAP_JAVA_SUPPORT. Highlight and click ADD.
- Now click Save