SYSTEM ERROR: memory violation (49)

[sdjensen]

I have a problem starting one of my databases on our test server (Suse 10.something).

Database is a OpenEdge 10.0b04.
Database 'test' crashed with memory violation error.

When I try to truncate the db I receive the following

09:20:06 proutil -C truncate bi session begin for root on /dev/pts/0. (451)
09:20:07 SYSTEM ERROR: Memory violation. (49)
09:20:07 ** Save file named core for analysis by Progress Software Corporation. (439)
09:20:07 proutil -C truncate bi session end. (334)

And I cannot start the database up again.
If I try to use OpenEdge 10.1a02 I can truncate it without the error and I can start the database up without any problems.

Any idea why?

Database is only used for test data so it is not problem if I lose the data.
I just would like to know why it works with 10.1 and not with 10.0.

 

[StuartT]

It sounds to me as if the DB has been created as a 10.1 DB not 10.0b

 

[sdjensen]

The db is version 9 converted to 10.0b04 and it have been running for at least one year as version 10.0b04 without problems.

 

[TomBascom]

Did you run it as 10.1 prior to the initial crash?

There are features in 10.1 that 10.0 wouldn't be able to deal with. If you ran it as 10.1 for a while and one of those features was exercised and then tried to run it as 10.0 afterwards that might explain what you are seeing.

 

[sdjensen]

Did you run it as 10.1 prior to the initial crash?

There are features in 10.1 that 10.0 wouldn't be able to deal with. If you ran it as 10.1 for a while and one of those features was exercised and then tried to run it as 10.0 afterwards that might explain what you are seeing.

Nope. The database was running using version 10.0. Every DLC pointers pointed to a 10.0 version.

The 10.1 is running a completely different database and the two databases was been running side by side the last year if not more.

 

[TomBascom]

Any updates or patches lately? Maybe to Java?

 

[sdjensen]

No updates as far as I can see.

No change in hardware, network or software configuration.

We had a power failure on monday, but server was on UPS so it *should* not have an impact.
We also have other servers on save UPS and "knock-on-wood" they are running normally

 

[TomBascom]

You could try running dbanalys and dbrpr scans to see if they turn anything up.

Other than that I'm out of ideas.

 

[sdjensen]

First I tried Idxfix and it failed with
Large word-indexed text fields require a larger stack. (2765)
Out of stack space! Increase PROGRESS stack -s (2766)
when scanning the indexes (3)

I then found the index which gave the errors and deleted the records that created the error.
I ran idxfix again and this time it succeed without any errors. 1 index, 212612 blocks, 9468 keys checked. 6844 index changes (both add and delete).

I tried to startup the database using 10.0 but same error.

Dbanalys - nothing unsual.
I'm not familiar with the dbrpr and the db is up and running so I have to wait till tonight to check that.

I was hoping someone would say "hey I know why. Its because you have done this and this and not this. No need to worry " but apparently no one have seen this issue before.

Anyway do not spent to many hours thinking about the problem it is only a test server.

Thanks for reading

 

[taqvia]

Well I encountered a similar issue month back . In my case it was a live database(small one).The solaris box came down and as a result all the DB's running on the box came down. when the box was up all the database came up normally except one with the same error and no conclusive reason was found so for hit and trail method i copied database(os level) on the other server and too my surprise the database came up(prostrct repair) normally there. just did a probkup on that server and restored it back.

My DB was too small in this case

Arshad