cancel
Showing results for 
Search instead for 
Did you mean: 

ST22: DBIF_REPO_SQL_ERROR: SQL 1555: Regenerating program resolves

Former Member
0 Kudos

We're started getting Short Dumps in our DEV system which, on the surface, look like Oracle errors (SQL1555="snapshot too old"). HOWEVER:

1. Oracle is logging absoutely NO errors (the alert log is clean).

2. PSAPUNDO is more than big enough.

3. UNDO_RETENTION is sufficient.

4. Redo log sizes are big enough also.

The way we've found to fix this problem is to regenerate the programs referenced in the ST22 Dumps. Thus far, we've regenerated SAPLSVIM, SAPMM06E, and SAPL0PX7. Things are okay for a day or two, and then we need to regenerate them again (only SAPLSVIM so far: we've regenerated it twice).

Everyone says they haven't made any changes that would cause this, but there was a set of transports that touched Table View Maintenance (but for a CUSTOM table). The ABAPers all say it's BASIS/Oracle, and we (BASIS/Oracle) can't find anything Oracle-related. Again, if we regenerate the program(s) everythings works fine again for a little while.

What all this looks like if you're using the system is that ANY table viewed via SM30 (and only SM30) Short Dumps with the above SQL error along with the reference that "SQL error 1555 occurred when accessing program "SAPLSVIM " part "LOAD"". Once we regenerate the program, everything works fine again.

Any ideas?? Please send them along.

Thanks,

Lara

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

I had to drop and recreated the table in order for the problem to permanently disappear.

Former Member
0 Kudos

Thanks, Markus.

I have double-checked the log sizes, and we're pretty current on our Oracle patches (we're at 10.2.0.2 and, insofar as the note with the patches is updated almost daily (LOL), I'm sure that we don't have every patch listed installed). All our other systems are on the same patch level and redo log size and those systems are not having an issue.

Take, for example, this situation:

When this problem is occurring (when the program needs to be regenerated again), I can't even view T000 via SM30, nor can I execute t-code SCC4. Now...as I'm sure you know this is a VERY small table and I am making no changes (hence no issue with the commits); I just want to see it. Once I regenerate SAPLSVIM, it works perfectly.

Any other thoughts?

markus_doehr2
Active Contributor
0 Kudos

> When this problem is occurring (when the program needs to be regenerated again), I can't even view T000 via SM30, nor can I execute t-code SCC4. Now...as I'm sure you know this is a VERY small table and I am making no changes (hence no issue with the commits); I just want to see it.

Once I regenerate SAPLSVIM, it works perfectly.

I understand the problem. When this is happening, the problem is not with your actual transaction but all other open transactions. Are there any longrunning batchjobs or any users having a huge number of non-commited transactions open?

What you could try is to use SGEN to regenerated everything and then restart the system to initialize the buffers.

Markus

Former Member
0 Kudos

Currently running SGEN on the hopes that I'll see the exact result you mention.

After restarting the system, I'll monitor so see if it crops up again. If it does, I'll check for any longrunning batchjobs or any users having a huge number of non-commited transactions open? I don't remember seeing any over the last few days, but, hey...I may have missed that.

Thanks for the input; I'm going to keep this thread open a little longer in case it crops up again (we seem to be good for a couple of days and then the dumps resume).

Cheers,

Lara

markus_doehr2
Active Contributor
0 Kudos

4. Redo log sizes are big enough also.

ORA-01555 means, that amount of not-committed data is bigger than the current redo log group can keep. This can be caused by one huge (self written?) reports/transactions, that don´t do enough commits.

I would cross check the redo log sizes

I would also check if you are using the current patchset and the latest interim patches for your database version.

Markus