Unable To Write Extent Header, Ret = 0 File = /db1-glob/d1gtway.d1

Jatinder K

New Member
Hi Team,

Database is getting corrupt and inaccessible very frequent due to below mentioned error :-

Work around - We have added variable extents to application areas and restored database with full backup.

After a few hours, Application team has encountered with same issue.

Please help to check. Thanks

----------------------------------------------------------------------------------------------------------------------------------
[ Error ]

| Unable to write extent header, ret = 0 file = /db1-glob/D1GTWAY.d1. (539) |

| |

| |

| <OK> |

[]


======================================================================
$ $DLC/bin/proserve /db1-glob/D1GTWAY

PROGRESS Version 9.1D09 as of Tue May 25 09:31:19 EDT 2004

09:28:51 BROKER : SYSTEM ERROR: Unable to store shared memory and semaphore id

entifiers (5436)

09:28:51 BROKER : Unable to read master block, file = /db1-glob/D1GTWAY, errno

= 1. (6070)

09:28:51 BROKER : SYSTEM ERROR: Unable to store shared memory and semaphore id

entifiers (5436)

09:28:51 BROKER : Removed shared memory with segment_id: 16777310

09:28:51 BROKER : ** This process terminated with exit code 2. (8619)
============================================================================
 

Jatinder K

New Member
HI Cringer,

Thanks for your response. Below are the answers :-

1) Progress version, Service Pack and product

PROGRESS Version 9.1D09

2) OS and version

Oracle Solaris 10 1/13 s10s_u11wos_24a SPARC

3) What you have tried

We are getting error "Unable to write extent header, ret = 0 file = /db1-glob/D1GTWAY.d1. (539)" on test database.

Below is the work around in detail -

1) Added variable extents in schema and application areas.
2) Restored database with full backup
3) Given full permission to database files
4) Start database

4) What errors you are receiving

Below errors are coming very frequent even after DB restored with full backup

Please help to check.

===================================================================================================
[ Error ]

| Unable to write extent header, ret = 0 file = /db1-glob/D1GTWAY.d1. (539) |

| |

| |

| <OK> |

[]


======================================================================
$ $DLC/bin/proserve /db1-glob/D1GTWAY

PROGRESS Version 9.1D09 as of Tue May 25 09:31:19 EDT 2004

09:28:51 BROKER : SYSTEM ERROR: Unable to store shared memory and semaphore id

entifiers (5436)

09:28:51 BROKER : Unable to read master block, file = /db1-glob/D1GTWAY, errno

= 1. (6070)

09:28:51 BROKER : SYSTEM ERROR: Unable to store shared memory and semaphore id

entifiers (5436)

09:28:51 BROKER : Removed shared memory with segment_id: 16777310

09:28:51 BROKER : ** This process terminated with exit code 2. (8619)
============================================================================
 

cj_brandt

Active Member
If you have corrupted the master block of an area, then you should consider running a dump and load to create a new db.
dump the existing tables from the database with the corruption in the master block.
Create a new database and load the tables into it.
 

Jatinder K

New Member
That's fine, We have backups available to recreate the database from scratch.

I am interested to know the root cause of this issue. How the database is getting corrupt every day ? Please help
 

TomBascom

Curmudgeon
What makes you think it is getting corrupted every day?

Perhaps your backup is simply restoring the corruption over and over...

Have you ever used -F to force your way into this database?

Why did you add variable extents? What was your reasoning behind that?
 

Jatinder K

New Member
Thanks for your reply !

below are the answers :-

What makes you think it is getting corrupted every day?

After backup restoration, We are able to start database and application user can access the database for routine work. It becomes inaccessible after a few hours of restoration.

Perhaps your backup is simply restoring the corruption over and over...

Database backup is good. We had restored the same backup on another server and do not see such issue there.

Have you ever used -F to force your way into this database?

I have used earlier to open the database forcefully as last resort.

It's not working in this case.


Why did you add variable extents? What was your reasoning behind that?

We had only fixed extends so created variable extends also to avoid space issue
 
Last edited:

TomBascom

Curmudgeon
You have used -F... That message about it being a bad idea wasn't kidding. You must dump & reload.

You mention a "space issue". Could you elaborate? (It's just a side-show until after you fix the -F issue with a D&L)
 

cj_brandt

Active Member
Go ahead and dump all the tables just as a test to see if all the tables can be read and accessed.

Restoring a database backup doesn't recreate the database from scratch, that is why a D&L is recommended.

If you are a bit nervous about performing a D&L, look at the Progress KB or search archives of OE sites for steps to perform. Lots of help available.
 

TomBascom

Curmudgeon
You might also run proutil dbanalys right after a restore as a check that you can read everything successfully.
 

Jatinder K

New Member
Thanks Tom and CJ_bradt for your help.

Will apply both the solution and keep the database under observation.

Regards
Jatinder Kumar
 

Jatinder K

New Member
Just to update you, We had the same issue today and its resolved now without restoring from full backup and Dump & Load.

Solution -
1) Run prostrct unlock <dbname>
2) Truncate database
3) Start database with full services

Regards
Jatinder Kumar
 

TheMadDBA

Active Member
Just echoing what everybody else is telling you... if you have ever used -F against this database you MUST do a dump and load and try and salvage what you can. Everything else is just a series of hacks to get into the database.

If you care about your job and/or this data you need to schedule this as soon as possible.

And then see about upgrading to a modern and supported version of OpenEdge.
 

TomBascom

Curmudgeon
Also...

You never should have needed to use -F. You /should/ have restored and rolled forward your after-image logs. I'll go out on a limb and guess that after-imaging is not enabled for your databases. If I got that right then you should also get a high-urgency project going to implement after-imaging. After-imaging is your best friend. If you implement it correctly it will save your job when everything around you goes up in flames.
 

Jatinder K

New Member
Thank you for your suggestions !

We have performed Dump and Load today morning and verified the data. It looks good now.

Database migration activity is scheduled next month to upgrade databases form 9.1D to Opendge 11.5 version. After image will be enabled during migration activity.

Regards
Jatinder Kumar
 

Jatinder K

New Member
Hi All,

We had a same issue even after performing Dump & Load. Database was working fine since Monday. DB's block size is 1024.

I would bring to your notice that, We had OS upgrade from solaris 9 to solaris 10 2 months ago. Is it causing this issue ?

In addition, Database is restored on remote device.

/db1-glob/D1GTWAY.db is on a remote device. (9466)

Please help !

Regards
Jatinder Kumar
 
Last edited:

cj_brandt

Active Member
1. You would get a performance boost by switching to a db block size of 4096 or 8192. On windows we use 4096, and 8192 on the rest.
2. I think it is time to ask the hardware team to look for issues.
3. I don't understand the reason to have your databases on remote share.
4. I don't know if version 9 has the builddb option on prostrct. If it does, you could use that to create a new .db file.
 

TheMadDBA

Active Member
Never ever run your database on a remote device. Ever. Just don't.

I have no idea if 9.1D was supported on Solaris 10 or not. The remote/nfs mount for the DB is the likely cause of most of your issues. Stop doing that ASAP.
 
Top