Derived Roles

Derived Roles

As the name indications are derived from already existing roles.
There are two scenarios when we derive roles.

• The role menus are identical but the authorizations for the menu actions are different in the derived role.
• The menu and authorizations of the derived role are identical, but the organizational levels are different in the derived role.

The derived roles inherit the menu structure and functions (including transactions etc...) of the referred role.

The default authorization values of the derived role are that of the inherited role. The organizational values are to be maintained in the derived role.
The organization level data is only copied the first time the authorization data is adjusted for the derived role. If organization level data is maintained in the derived role, it is not overwritten by subsequent adjustments.

Roles derived from another cannot have any additional menu entries. The menu is maintained in the referred role which take effect immediately in all derived roles.


To change the menu of the derived role without changing the menu of referred role you have to break the inheritance relationship. Once the relationship breaks, the derived role is dealt as a normal role and the inheritance relation ship cannot be re established

How To Lock SAP Client

1. How to lock the client from logon
2. How to see the all the users connected per day (with the activities they have done and resource utilization)

I cannot answer the first straight away, but the second questions, there are many available SAP transactions.

use STAT very useful and many options available if you use them correctly.

1. I don't know how how to lock the client, but you can lock the system with "tp locksys " and unlock it with "tp unlocksys ". You can also stop the service, but then noone can login including yourself. However, I had problems with tp locksys when applying some Hot Packages and exporting client. It wouldn't work with system locked. I didn't try, but a simple ABAP that locks and unlocks all the users in table usr02 (with exceptions of yourself, SAP*, DDIC... - ofcourse) might be an interesting idea.

2. STAT transaction

You can lock the system thro "tp locksys" (Transport Utility).
Check the other options of "tp" command for locking the specific client under the system thro "tp help".

With this solution I can lock the whole system, but not specified by client.
Send me in more detail....

There's no way to lock a client.
You have to lock all users from loging in of this specified client.
The way you do is by user administration setting the lock.

We can lock a client using SCCR_LOCK_CLIENT and unlock SCCR_UNLOCK_CLIENT functions.

Once we run this functions with a client as input , that client will be locked/unlocked. Actually this function set flag '' Client is locked temporarly for client copy" in client maintanance menu. And the client will be available for users other than DDIC and SAP*. If you try to login in that client as any user , system gives message that ' Client locked temporarly'..

Is there any t-code to lock a client?

There is no direct tcode to lock a client. the easiest way to lock a client is
1. run tcode SE37
2. type function module name - SCCR_LOCK_CLIENT
3. enter the Client No.
4. execute the function module.

Copy a Client into a Stand Alone System

How to copy a client into a stand alone system?

The scenario is I have a 2 system landscape. I want to copy an existing client from DEV to a standalone system for some demo purposes.

There is an option for Client TRANSPORT which will help you perhaps:

A client transport differs from a remote client copy in that it does not use RFC. Like a remote client copy, however, a client transport is used to copy data between different R/3 Systems.

A client transport consists of two steps. First, a client export extracts client data from the source client to files at the operating system level. Second, the data is imported from the operating systemfiles into the target client.

To perform a client export, proceed as follows:

Log on to the source client. From the R/3 initial screen, choose:

*Tools *(r) *Administration *(r) *Administration *(r) *Client Admin. *(r) *Client Transport*(r) *Client Export*. Select the data to be copied using a profile.

Indicate the target system to which the client will be copied. (The target system must be defined in TMS as part of the transport domain.)

Begin the client export. As copying is a lengthy process, use scheduled background processing. The client export performed in the source system , exports the client data asynchronously bycalling the transport program tp at the operating system level. This export process will generate up to

3 data files at operating system level:

. RT<>; this file contains client-specific data

. RO<>; this file contains Cross-client data

. RX<>; this file contains SAPscript texts

Depending on the type of data selected through the client transport profile, the client copy command

files added to the buffer of the target system are

KO; this file is for cross-client data

KT; this file is for client-specific data

KX; this file is also for client-specific data

The client export change requests are not imported when an Import all takes place. Therefore, you must import these requests into the target client using TMS. You must import the data in the following order: first cross-client data, then client- specific data.

After the import process has completed, post-import activities are required possible for object generation steps. After completing the import, log on to the target client. From the R/3 initial screen, choose:
*Tools *(r) *Administration *(r) *Administration *(r) *Client Admin. *(r) *Client Transport *(r) *ImportEditing*

To display client transport logs, use the Transport Organizer.During client transport, a Repository consistency check can be performed by clicking the RFC system check button in Transaction SCC8. If inconsistencies are detected, a list of the ABAP Dictionary tables definitions missing in the target system is generated. This will help your recognize in advance formal problems that may occur during the import of the source data.

Steps For SAP Client Copy / System Refresh

Before doing a client copy, you need to prepare the following :-

1. Find the source client space with the client size custom program which can be implemented using the rel. note:
Find the space of the client - '0118823'. This will give you the size of the source client.

2. If your are on Unix OS, adjust all the file systems according to PRD file system to fit the PRD client in DEV
client based on space requirements also.

3. You can do the client copy by remote or export/import client.
Remote method is not preferred if you are doing a large client copy.
Do a client export/import.

4. To speed up the export/import, use R3trans export/import for the clustered tables.
Please find the rel. notes related to performance improvements for cluster tables in OSS.

5. Do import and post processing.
Note: Export may take 10 to 20 hr. for 50gb of data
import may take 4 days and post import will take 8 to 15 hr. for 50gb of data. And it all depends on
your system performance.

Please refer OSS rel. notes for the few RZ10 parameters which needs to be set for cluster tables to speed up the process.

Note :-

If it is a fresh installation, do this --

1. SCC4 --> Create client no. and fill other details.
2. Logon to the newly created client with SAP* and PASS as password.
3. SCCL --> choose any profile (preferably SAP_ALL), source client 000 and target client .
4. Preferably do a test run initially to check if it can go well.
5. As a care check space in databases.

What are step and procedure to create a client & to take a client copy from source to target.

By: Kavitha.G

If you are copying from same system then flow the below steps:

1. Create the client in Tcode scc4.
2. Before that create a logical System in BD54.
3. Login in the newly created client with
user Name : sap* and password : pass
4. Use the Tcode sccl to copy the client.if you are not familiar with the client copy. Try a test run and then schedule it in background.
5. You can select the needed profile.
6. To view the log files use the tcode scc3.

If you are using different system then create a rfc connection in sm59.test the connection and then continue from the 1st step
You can also import and export a client. Use scc7 for importing from the client and scc8 fro exporting from the source client

What is system refresh when and why it is done?

The system refersh is nothing but the deletion of the client and replacing the data from other client. For example : you have clients 100, 200 and 300. Suppose when you want to refresh the client 100 you remove the client 100 and replace it with 200 0r 300 as per your reqiurement. Mostly the refresh of clients will be happen at the time of development stage.

System Refresh is a simplified term to Client Copy. Client Copy means copying the production client on to the quality to test the real data. As recommend by SAP this need to carried out every 3 months.

The process to carry out the same is as follows:
1. Create a client on quality system using txn scc4
2. Create a RFC between Production system and Quality System (need to create on quality system)
3. Login to the newly created client using sap* and pass as a password
4. Txn sccl to start the client copy. You can test the client copy by selecting the test run option. (test run will estimate the time taken for the activity).

Problems in Heterogeneous Setup

Problems in Heterogeneous Setup

We Planning to go for hetrogenius setup.
Development server - HP-UX11i,oracle9.2,sap47.
Production server - SUN Solaris with same oracle and sap version
My issue is that, will I face any problems in this setup?
Because right now developments are going on HP-UX.

Venkatesh

I am not in a hetro-geneous setup.

But a similar installation I have already visited, which one of the big installation in Bangalore, they used Sun solaris as dev and HP UX as PRD. But no problems. Logically SAP system just looks for where the data is stored and works on TCP/IP. It just does not matter where the database resides for development and production.

The transport mechanism just transports from the development client to productive client. So I assure you 100% you can plan this. This is supported by SAP.

You can even plan NT as development machine. It just works fine.

But some advantages are available if you have similar systems.

1. When updating patches for a particular os/db combination , you have a chance to see how it works, before trying
it on productive system.

2. You learn a lot on installation, sizing, many other related issues at the time of development, so that you can easily
sort it our at the time of installation of prd system.

The above cannot be told as advantageous, but take a note of these. After all it is a matter of cost + convenience!

I am on NT + SQL Server with SAP 4.7 Ent. and its works fantastic without any problems.

Problems with Multi-clients in one SAP Production instance

You are working on group of companies. They don't want to share any data between companies, simply no integration required, therefore mgt wants to have one client for one company that end up having multi-clients in prod instance. However, one of the SAP local guy told you not to continue with this lanscape.

Some of the potential problem of using multi-clients in one prod instance are:

1. problems affecting one client immediately affect all other clients.
an eg.: 1 client runs a job that fills up a tablespace or file-system.

2. a system problem (system crash) affects all clients immediately. e.g. an Oracle archive stuck will affect all clients.

3. programs/tables are client independant. Invidual customers cannot make changes to common programs/client without affecting the others.

4. Poorly written ABAP's will cause bad response throughout the SAP system, affecting all clients. I shudder to think of a situation where the programmer for 1 customer stuffs up and the other customers demand blood!

5. Taking all of this into account, your change management will turn into a NIGHTMARE! especially considering that each customer probably does no care about the other customers, so EVERY change of theirs is the most important one.

The above are some of the problems if you have multi-client in one SAP instance and there are many more arguments.

What is the best way to refresh QA from PRD?

How to make a system copy:

1. Take offline backup of both the server (source and target servers)

2. Verify the backup is successfully done.

3. Run the following command on source system.
a. Login as adm
b. svrmgrl
c. connect internal
d. alter database backup controlfile to trace;
e. exit;
f. Above command will generate a .trc file in /oracle/P01/saptrance/usertrace directory.
g. Copy the text from CREATE CONTROLFILE until the (;) and paste it in to any new .sql or controlfile.sql file.
h. Copy the controlfile.sql to target system.
i. Edit the file and replace the entire source SID to target SID.
j. Edit the reuse database command with the set database command

4. Copy the aft generated during the backup file from the source system to target system. (/oracle//sapbackup)
a. Change all the source to target .
b. Only don't change the backup volume name it must be target system .
c. Copy the above aft file name line from the source back.log to target.log file.

5. Shutdown the target server instance.

6. From this onwards all the command on the target system only.
a. Login as adm
b. run the SAPDBA
c. select J (Restore/Recovery)
d. select B (Full restore and recovery)
e. select A (Select backup of type)
f. Select the offline backup which you want to restore.
g. It will take some time to restore.
h. Once the database is restored login as adm and run the
i. svrmgrl
j. connect internal;
k. startup nomount (if the database is already mounted shutdown it using the shutdown command)
l. run the following command
m. @controlfile.sql (file name of the control file contains the CREATE CONTROLFILE statement)
n. After the run the above command it should give the "Statement Processed)
o. alter database open resetlogs p. shutdown
q. Start the database and SAP services using startup.

7. After this you have to reconfigure the STMS.

8. All the jobs also you have to reconfigure and reschedule.

9. Reconfigure all the printers.

10. If you want to change the Client number then use the local copy tool and remove the original client after successfully import to new client.

SAP Background Jobs or Update Process Canceled due to Insufficient Swap Space

Symptom

Error messages in the trace files dev_w, where the texts malloc failed, rstg PERM, etc., appears, especially if the background jobs are active with large amounts of data.

Corrective action

Increase the swap space or decrease the R/3 Extended Memory.

If necessary, increase the roll area.

Check if the maximum process size (operating system parameter) is sufficient.

See: Swap Space Bottleneck During R/3 Operation

SPAU and SPDD OSS

When you apply a package, a large number of objects are changed.

If you have applied any OSS notes to objects in your system, the hot package may overwrite these objects.

SPDD is used to identify dictionary objects

and

SPAU (repository objects), will identify any objects where the hot package is overwriting changes you have made through OSS notes.

You must check all objects identified in SPAU and decide whether you need to reapply the OSS note or reset the code to the original SAP Code.

If, for instance, you are applying hot package 34, SPAU identifies an object where you have applied an OSS note. You must check the OSSs note and see if SAP have fixed that note in a hot package.

If the OSS note has been fixed in hot package 34, then you should reset the object to its original source code. This means that there is no repair flag set against this object again and it is now SAP standard code.

If, however, the object is not fixed until hot package 38, or there is no fix available you have to reapply the OSS note, otherwise users will encounter the problems they had before the note was applied.

You must transport all reapplied notes and Reset to SAP Standard objects after you apply your hot package to your QAS and PRD systems.

How to Monitoring the Operating System

After starting up the memory management, you must monitor the swap space and the operating system paging. Problems can arise if the swap space is insufficient, or the operating system paging exceeds a specific amount.

Use the CCMS tools in R/3 for monitoring (data source: saposcol). To start the tools, call transaction ST06.

This section covers the following topics:

Checking Unused Working Memory using Transaction ST06

Memory Pools on AS/400

Checking Page Fault Rates