Use report RSCLCCOP to transport user master records, profiles and authorizatons between clients in an R/3 system.
Start RSCLCCOP from the target client which the users and authorizations should be copied.
Do not use this report if the target client contains some users and authorizations you want to preserve.
Copying table entries from client 000
I need to copy table entries from client 000.
I have identified which entries I need to copy through running RPULCP00 but I don’t know how to move the entries.
The simplest way is to go into the table through SM31
Then in your top row of buttons there should be one called ‘utilities’ from here select ‘adjust’,
Then select the client that you want to compare/copy from (you need to have an RFC destination set up).
This will then show you the contents of the table in both clients and identify the status of each record, they will fall into the following categories:
ML Differences, logon client entry
MR Differences, comparison client entry
L Entry only exists in logon client
R Entry only exists in comparison client
Identical entries
(M) Differences only in hidden fields
You should be able to scroll down the table, select the entries that you want to import, then hit the ‘adjust’ button, then hit the ‘copy all’ button, then back out with the green arrow, and save your table.
That should do the job.
SAP Tablespace sizes in large databases
—–Original Message—–
Robert and others following the thread,
First a little background on extents in our production system. We created the instance about 4 months prior to going live. As man of you know, getting down time during the last few months is nearly impossible, so we saw and let extents grow. In fact, by the time we went live, we had 2 objects over 450, 5 objects over 300, about 50 objects (tables and indices) that were over 100 extents, and we had hundreds of objects over 10 extents.
I agree to doing both planning for growth and monitoring growth. And the earlier in your SAP implementation you do this the better – which is something we did not do until after we created our productive instance.
We were very concerned about this situation and spoke to 3 or 4 different SAP consultants. We got the same answer from each – objects in high extents will have little or no performance impact. Like Sanjay mentioned, the consultants had no specific reason for this.
I do not believe you will find an SAP employed person who will say you should keep extents below a specific value. Also, I cannot definitively give that advice either.
Over the months we have all our objects below 100 extents. We have not seen a significant change in database response time. Our goal is to have all objects below 20 extents – which is a corporate standard.
But we will not ask for extra down time to reach this goal.
Good luck trying to keep objects below 10 extents. While data is “pumped” into the system during the weeks before going live, whatch the extents, they will take off. This also occurs after performing a SAP version upgrade.
—–Reply Message—–
Why not do both? Planning for growth is critical. Monitoring daily can be automated via CCMS can it not? With proper alert thresholds, a system freeze can be thwarted long before extents reach 300 (max extents in my version of Oracle).
My question to you both is, how many extents are to many? I have heard from consultants that SAP says that, for performance reasons 10 is the limit. I do not understand the logic in this. Unless There is alot of fragmentation throughout the tables, why not 50 or 100? I just completed a Client Copy and have 4 tables in the BTABD tablespace that are over 17
extents. Is this to many? and should I lose the uptime for a reorg for 17 versus 10 extents?
I guess what I am asking is, since both of you seem to have put some thought into this, is there a hard-and fast number when in comes to an acceptable amount of extents? SAP seems to be overly conservative most of the time – was wondering if anyone has good numbers?
SAP Learning 