Data area doesn't grow bigger than ~160 GB - Forum - OpenEdge RDBMS - Progress Community

Data area doesn't grow bigger than ~160 GB


Data area doesn't grow bigger than ~160 GB

This question is not answered


One of our customers have a a following problem. One big table "printouts" is placed alone on a type II area. The area is in one variable size file, that currently  is almost 160 GB. The block size is 8k and the server is Windows server. If they try add records to the area, the database crashes with errors:

[2017/07/04@00:47:10.667+0300] P-162768     T-162772 I ABL   135: (9450)  bkioWrite:Insufficient disk space during write, fd 2864, len 16384, offset 19902184, file E:\db\datas\database_11.d1

[2017/07/04@00:47:10.698+0300] P-162768     T-162772 F ABL   135: (8897)  SYSTEM ERROR: Unable to extend database within area printouts.

[17/07/04@00:47:10.698+0300] P-162768 T-162772 1 4GL -- (Procedure: 'programX.p' Line:84) SYSTEM ERROR: Unable to extend database within area printouts. (8897)

Area settings in st file: "printouts":11,64;512 E:\db\datas\database_11.d1

   Statistics for Area: printouts

   Files in Area: printouts

  E:\db\datas\database_11.d1  163038707712
  Database Block Usage for Area: printouts
  Active blocks: 19901951
  Data blocks: 19901446
  Free blocks: 505
  Empty blocks: 235
  Total blocks: 19902186
  Extent blocks: 1
  Records/Block: 64

A couple of months old tabanalys for the area (when it worked):
AREA "printouts" : 11  BLOCK ANALYSIS

19470847 block(s) found in the area.

Current high water mark: 19470847

    505 free block(s) found in the area
    19470332 record block(s) found in the area
    0 index block(s) found in the area
    0 empty block(s) found in the area
    2 object block(s) found in the area
    2 cluster list block(s) found in the area
    1 object list block(s) found in the area
    2 cluster map block(s) found in the area

                                       -Record Size (B)- ---Fragments--- Scatter
Table                Records    Size   Min   Max  Mean      Count Factor  Factor
PUB.printouts      912754005  123.4G    68 12382   145  917107791    1.0     1.0

We have studied this with co-workers and couldn't find solution. The customer has moved some old records from the area to an other place so we have managed so far, but we should solve this soon.

Any ideas what might be the problem?



All Replies
  • Did you post the area setting reported by a recent prostrct list? Maybe someone tried to add a new extent and then immediately removed it but left the first extent with the fixed size?

    Does E disk have the free space?

    Did you check the possible corruptions on file system level? Can you copy/delete/restore E:\db\datas\database_11.d1 ?

  • Hi!

    I ran a new prostrct list and the result was the same: just one variable size data file for the area. E-disk has free space about 110 GB and no other database areas have faced this kind of problem.

    The company resposible for the server has checked disks and found no problems. Disk system is a mirrored Hitachi Data Systems SAN.

    As the database is in very important use 24/7 there's very little I can do online, but I try to find a place to restore last backup and do some testing with that.



  • Can you add (online) new extent to the area? It will work either as a workaround or as a debugging of the issue.

  • What is the version of Windows ?  Try to add another variable length extent to the area and allow OE and Windows to start using the new extent.

    I couldn't tell from your previous post if other databases already had single extents larger than 160gb - " no other database areas have faced this kind of problem."

    Limit might be with something besides OE.

    If there is space available, try to create a test database with a single fixed extent of 175gb and see if it can be created.

    If that works, take a binary dump of a table and load it back into the 175gb extent, repeat the load until you fill the extent and see if there are similar errors around 160gb.

  • Hi! Looks like addonline command solved the issue. The new variable size file has started growing and no error messages or crashes have occurred after the file addition.



  • So it's more likely that the root case was a problem with disks and this issue is not solved.

  • What is the size of database_11.d1 after it was fixed by prostrct?

    Is it larger than the offset reported by the error 9450?

    If you have a short timeframe to test db then I'd recommend to update a few records with RECIDs at the end of database_11.d1.

    For example:

    for table where recid(table) eq myRecid:
      assign = "x" +
      assign = substring(, 2).

    Db might crash with the same error 9450 if there is a problem with disk writes.