EhP5 - System compiling after SGEN

[Former Member]

Hi everyone,

After installed EhP5, we start SGEN with option "Regenerate after upgrade".

But all transaction started for the first time, compiles

We restarted SGEN with option "Generate All Objects of Selected Software Components".

We selected all software components.

A lot of archive (oracle) but transactions run for the first time still compiles...

Could you help me ?

Thank you,

Philippe

[Former Member]

Hi everyone,

My problem is solved with this notes:

Note 1630356 - SGEN terminates after 500 generation errors

Note 1588826 - Limiting the SGEN generation set to 70 objects

Thank you everyone!!

Philippe

[Former Member]

Good morning everyone,

I see in the log today : "Generation stopped due to 515 generation errors (see long text)"

SGEN must to continue and not stop, isn't

Long text:

Generation stopped due to 515 generation errors (see long text)

Message no. TSGEN228

Diagnosis

Unable to generate many objects (the generation status displays the value 'E', meaning that no syntax errors are involved). There are several reasons for why these generation errors may occur. The most frequent cause is that the tablespace containing the load tables is full.

Procedure

Generation Status in the Database Table GENSETC

You can use the generation status of the objects in the database table GENSETC to determine how many objects:

Were generated successfully (GENSTATUS ='X'),

Are currently being processed (GENSTATUS ='P'),

Are still in initial status (GENSTATUS ='I'),

Showed a syntax error durin generation (GENSTATUS ='S')

Showed an error of a different type (GENSTATUS ='E').

Clarifying the Cause

The SysLog (transaction SM21) can be helpful when determining the cause of generation errors. Here you also see entries if the most frequent cause for a large number of generation errors was that a tablespace did not have enough space for the load tables. You can check how much free space is available in the tablespaces by calling transaction DB02.

Resuming Generation after Revealing the Cause of Error

To resume the generation after it has been stopped, choose the generation task 'Regenerate the objects of the last run' when you recall transaction SGEN and then choose 'Resume'. The servers that you select for parallel generation must have the same machine type as those before the generation was stopped. The transaction now resets the generation status of all objects with generation errors (GENSTATUS ='E') to 'I' (initial). If you now restart the generation, all objects that have not yet been edited (GENSTATUS ='I') are generated.

Best regards,

Philippe

[Former Member]

Hi,

Running SGEN requires additional database space - as the compiled programs are to be stored.

Actually while starting the SGEN, the system shows space requirements in the status bar (not explicitely though).

Hence check in tcode db02 if any tablespaces are full. If so, then extend the same via brtools.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/1b/d20f6fe45a9e43b1856ea1b52c9612/content.htm

Then re-run SGEN.

Regards,

Srikishan

[tomas_black]

Hello Philippe,

please provide more details about the errors, the message you posted is a generic one, and the individual log/object files should be analysed why they errored out.

In the meantime, I'll provide some hints regarding the runtime of SGEN:

- initially it should be checked that SGEN is stuck because of lack of available work processes (DIA? BGD?). Please check this in SM50/66 and rearrange your WPs in RZ03.

Do you have any error message which you can see from your oracle alert log during such execution, etc? Sometimes defragmented state of the database may cause the difference too!

Transaction SGEN determines the so-called generation set through the options given in the first screen and the content of the file REPLIST. The resulting set is saved in table GENSETC. After that step the SGEN starts a maximum of 8 generation jobs in batch which then do the dirty work and process the content of GENSETC. So there are in actually two parts which are citical:

First part is SGEN related and means the calculation of the generation set.

Second part is the performance of the gen. jobs and this is out of control of SGEN. This is SAP system related and depends on resources of the system itself like main memory, number of cpu and last but not least, the database performance.

I would say that the runtime of the gen jobs is heavily depending on the database performance of the system. All the eight jobs access the tables REPOSRC and REPOLOAD and some other administrative tables thus creating heavy database load.

Hence the performance of the gen jobs is not SGEN related, SGEN cannot do anything after having started the batch.

So there are two option to be looked at:

1. If there are enough system resources like main memory, number of cpu AND enough SAP system resources like number of batch jobs and the database load is not near 100% THEN we could think about increasing the maximum number of batches to perform the generation. This is meant for all instances. That means a modification to change the max from 8 to say some higher value like 16.

2. If the runtime of the batch is the issue then a general look into DB performance is helpful. I am not an expert with Oracle, so I cannot tell the details of the DB02 transaction which could give some performance hints as well as native Oracle tools. If this is the case, you might want to log the case with component BC-DB-ORA.

The runtime of the batch is out of control of SGEN, but are the performance factor in generation.

In case that the DB performance or the general SAP system batch performance is the issue than I would not expect big differences in runtime of the generation jobs between SGEN and SAMT. The basic work is the same.

Especially when the database is the limiting factor both the SGEN batch jobs and SAMT should take a similar amount of time.

I hope the above information helps to solve the issue. In case there are enough resources for the generation you could modify report RSPARAGENER8 to increase the number of processes. I attach the info below.

NB: Please find here the statement to change to increase the number of

processes used for generation.

=====================================================================

In report RSPARAGENER8 line 194-195:

data: njobs_max type i value 8. " maximum number of parallel tasks in

• the RFC group

>> defines the maximum number of tasks

>> changing this values will increase the number of procs used/created

for SGEN

>> The value is used in lines 492-496 were the number of workprocesses

>> is limited by the njobs_max value

Perhaps you can do this analysis and see whether it does make relevant to you

#589124: Performance improvements when Support Package imported

I hope this helps.

Best regards,

Tomas Black

[Former Member]

Hi,

Thank you for your quick support,

All jobs are terminated succesfully without error.

@Christian: You are right, but in my case, all transactions and all programs start with a compilation. Is it really normal ?

Philippe

[Former Member]

All, no. A lot, yes !

Olivier

[Former Member]

Hello Philippe,

Even after a full successful SGEN, I've always seen a lot of programs recompiling at first launch.

So, I would say there is not much to be done and we just have to live with it.

Regards,

Olivier

[Former Member]

Hi,

In both the cases, does the SGEN job complete successfully without any errors?

Regards,

Srikishan