sturla
2nd November 2001, 13:54
I get an error message when I try to uppdate Purchase Statistics (running tdpst0201m000, full update on actual supplier data). It's on Baan IVc4, SP 6. The BW message say:
process 323 - Fatal error: Error 2555 (bdb_errno2555) on Select
process 323 - Fatal error: Can not continue in tdpst0201m000 ()
process 334 - Can't read session or object (bye)

I need to know what the reason is an what to do to avoid the message.

Sturla

patvdv
2nd November 2001, 14:16
Sturla,

This the famous 'snapshot too old' message:

01555, 00000, "snapshot too old: rollback segment number %s with name \"%s\" too small"
// *Cause: rollback records needed by a reader for consistent read are
// overwritten by other writers
// *Action: Use larger rollback segments
To understand the cause of the problem you must understand the mechanism of how Oracle provides rollback for your Baan transactions. Since Oracle does not allow dirty reads (show records *while* they are being updated by another process), it needs to keep a copy of the 'old' data in a storage area, ie. a rollback segment. However, rollback segments are limited in size and a transaction can never go across rollback segments. For that reason, updates are logged in a round-robin fashion in each rollback segment so that when a long running transaction comes to the 'end' of the rollback segment, it 'wraps around' to the beginning of it. Possibly it will start overwriting information that was stored by the same transaction earlier on.

Then comes your problem: you are trying to run a report on the same data but because Oracle *must* show you the data as it was before the other transaction started, the database needs to retrieve the data from the rollback segment. And bingo, there is some stuff missing because the other transaction has 'wrapped around' already in the rollback segment. Then you will get: snapshot too old.

sturla
2nd November 2001, 15:18
Patrick,

Thankyou!

How do I force Baan to use another, larger rollback segment? Do I have to put the small Rollback segments offline?

I'm not a technical guy, Pat, can you give me some more ideas about how to get around my problem.

Sturla

patvdv
2nd November 2001, 15:31
Well Sturla,

There is a couple of things you can keep in mind:

1. schedule your batch jobs properly: if you are encountering the snapshot problem because another user if running a long job at the same time whilst he/she should be really running that job at night or off-peak hours, then revise this.

2. use larger and more rollback segments:
increasing the initial extents might prove useful if your storage values are pretty small now. You must put them offline, drop and recreate them.

You cannot force a transaction to run against a particular rollback segment because Baan does not support it (Oracle does). However, if you know that a particular batch job is going to execute at a particular time and you are afraid of encountering this problem then you could consider creating 1 *very* large rollback segment and putting all your normal ones offline. After the batch job is finished you put or drop the big rollback segment and re-enable the normal ones for daily use.

Han Brinkman
2nd November 2001, 16:15
Of course it's also possible to solve this by changing the script. If you use a 'as prepared set' Baan will write the select into a qp file in the tmp directory.

Rgrds,
Han

patvdv
2nd November 2001, 16:29
Han,

I am not very familiar with the qptool. How would changing the script avoid this problem? Will it not execute the same SELECT statement(s) and return the same data?

Han Brinkman
2nd November 2001, 18:17
Pat,

Changing the script and using a 'as prepared set' has nothing to do with qptool. The prepared set will read the data into a qp<number> file and work with the data that is selected and written into that file. That's the way the euro conversion software works if you turn the fourth parameter on. That will prevent the 'snapshot to old' error.

The qptool is usefull to extract data from the database without using a session/bshell etc, testing sql statements.

Have a nice weekend,

patvdv
2nd November 2001, 22:24
Han,

Thanks for enlighting me. I can see the advantage of the 'as prepared set' now. :)

sturla
3rd November 2001, 12:11
Pat and Han,

Thankyou for a lot of information. I still can't do the job myself, but I have got a lot of useful information that helps me to hire a technical consultant.
I'm running a one man company (started some weeks ago), but have some partners that can do this job for me, and it makes it easier for me to explain the problem after getting all this information from you.

Have a nice weekend, both of you.

Best regards

Sturla

Han Brinkman
5th November 2001, 10:45
Never been there, I like the scandinavian Countries so if you need any help I would be more than glad to help you ....