Production Issue: Wrong AI Extent Creation Date

Hello All,

During a planned downtime activity, we were not able to start our database due to the error messages of “wrong creation date of AI extents”. Below are DB logs for the same:

Code:
(9212) Extent /ai /db-name.a1 has the wrong creation date Thu Jan 1 01:00:00 1970,
(9216) Control Area has a creation date of Sat Nov 25 14:47:28 2017.
(605) Probable backup/restore error.
(9214) Creation date mismatch.
We had to disable OpenEdge replication and AI to start the database. We recreated replication server after that and currently replication is in sync with LIVE.

It’s very strange for me that AI extent creation date in DB logs is Jan 1 01:00:00 1970 and this message is for all AI extents. Please help to find the cause and suggest what to do if this issue comes again.

Progress Version: 10.2B08
OS Version: Red Hat Enterprise Linux 6.10 64 Bit

Please suggest.

Regards,
Learner
 

TomBascom

Curmudgeon
What was the nature of the planned downtime activity?
 
Thanks for your response Tom.

Downtime activity was to increase SQL width of two fields.

Regards
 

TomBascom

Curmudgeon
By itself that would not cause a problem with ai extents.

The problem that you describe is more likely to have been a result of someone tampering with the after-image extents. For instance by copying them from one place to another using OS commands.



Or maybe an excessively long hostname: Progress KB - Database corruption errors 9214 9212 9216 605 on Linux when processes generate protrace files
 
Thanks for sharing articles.

We didn't touch AI extents and there is no such OS commands used to copy AI files from one to other place, AFAIK.

Please suggest if could find the exact OS command/actions/users IP that causes this issue by checking OS logs or something.

Regards
 

TomBascom

Curmudgeon
These things don't just happen out of thin air. Somebody did something. Perhaps mistakenly. But something occurred.

There may be additional helpful information in your db log file regarding the shutdown and the utilities that were actually run between shutdown and successful restart.

If shell history was enabled and if no efforts at a coverup are being made then you could try searching administrators shell history files. Once in a while hat will turn up something that someone forgot that they ran or something similar.

BTW -- OpenEdge 10 is ancient, obsolete and unsupported. You should upgrade. OE 12 is the current release. RH6 is also ancient, obsolete and ought to be upgraded.
 

Cringer

ProgressTalk.com Moderator
Staff member
You need to know exactly what happened during the downtime. The most likely (from experience!) is that someone did a command on a test database whose .st file was still pointing at the production database. Another good argument for having non-production databases on a different server!
 

cj_brandt

Active Member
You need to know exactly what happened during the downtime. The most likely (from experience!) is that someone did a command on a test database whose .st file was still pointing at the production database. Another good argument for having non-production databases on a different server!
This is a very good suggestion.
 
Top