Transport Tables between Clients
Use report RSCLCCOP to transport user
master records, profiles and authorizatons between clients in an R/3 system.
A D V E R T I S E M E N T
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?
|
