In-place conversion problem

[balebob]

Hi All,

I am testing an in-place coversion on the production db from MFGPRO eB SP5 to eb 2.1 SP5 with Progress OE10.1A02. I am following QAD eB2.1 Conversion Guide - Progress Database and run into a strange problem... The conversion fail to update the source schema using the delta schema file that is shipped with eB2.1. I am using the delta file in the $QAD/inplace/progress/storagearea called 'dlteBSP5-eB21.df' to optimize data files on disk. The error is:
** Insufficient disk space to extend the brfore-image file. (854)
QAD suggested that I should add more BI extents and re-run the conversion again. I added an additional 10 GB of BI extent and still am running into the same error. The current production database size is at 80 GB (raw data) which I allocate 120 GB for future grow. An additional 10 GB of BI size is more than 10% of my current database size. I am now increase the BI size to 30 GB on my test box to see if it will pass this stage or not. If it passes, then in-place conversion is not going to save me on disk space or conversion time since I have to re-built my database first to add more BI extents which will use additional space on the system.

Is there something that I am missing? I re-read the conversion guide from QAD over and over and cannot figure out why it failed.

Please help and thank you. Oh, btw, we are using AIX 5.2.
Bob.

 

[oldemanw]

I recall reading something about diskspace (80% full limit?) when we upgraded from Progress 9.1 to 10.0.
Your answer may be in the Progress manual.

 

[balebob]

Thanks, 80% full limit... is it a system file size of the dump data directory? Is this in Progress document or QAD document?

Bob

 

[oldemanw]

Hi Balebob,

This is what I found on the Service Pack 5 CD for OpenEdge 10.0:

SYSTEM INFORMATION:

Platform: LINUX Intel
Serial Code(s): 178 (CD-ROM)
Service Pack Version: 10.0B05


Warning Messages for Storage Area Limits Bug: 20050729-029
=============
When the address space in a storage area is totally exhausted,
a database crash will occur. In the past, some crashes have not
proven recoverable due to large transactions processed during part
of crash recovery.

A change has been made to the RDBMS to warn of approaching address
limits, and to ensure crash recovery can proceed. The change causes
WARNING messages to be printed to the database logfile at the points
where 80% of the address space is consumed, and again at 90% of address
space utilization. These are warnings, and not fatal errors. Processing
is NOT allowed to consume 100% of a storage area now. Instead, a
database will crash short of the 100% point so that space reserved for
crash recovery can be utilized to handle the transactional portions of
recovery, i.e. recovery should perform correctly. For combinations of
small block sizes (1024 and 2048) and large numbers of records per block
(256 and 128) 1GBytes of space is reserved. For all other combinations,
5GBytes for recovery is reserved.

The sequence of events seen in the logfile is thus: 2146204160

06:10:06 WARNING: Area: 51 extent TONOPAH has reached the 80% threshold
for block usage - current block hiwater 1716963328

22:07:04 WARNING: Area: 51 extent TONOPAH has reached the 90% threshold
for block usage - current block hiwater 1931583744

07:10:02 SYSTEM ERROR Area: 51 extent TONOPAH has exceeded the maximum
number of blocks per area - extend: 2146201034 maximum 2146204160

Please also refer to prior information provided regarding the "statparse"
tool, a free utility that can be used routinely to monitor storage area use.

Hope this helps,
-Willem.