Article

How to allow database extents larger than 2GB? (embedded video)

« Go Back

Information

 
EnvironmentProduct: Progress
Version: 9.1C, 9.1D, 9.1E
Product: OpenEdge
Version: 10.x, 11.x
OS: All Supported Operating Systems
Other: RDBMS
Question/Problem Description
How to allow database extents larger than 2GB?
How to allow database files larger than 2GB?
How Large Files support works?
How to enable large files support?
What is needed to enable large file support?
Which files does enablelargefiles affect?
How to run EnableLargeFiles?
How to allow large file support?
How to enable large file support?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause

Resolution
A new feature was implemented in the Version 9.1C Enterprise Database product to enable database extents to be larger than 2GB.

When large file processing is enabled for a database, a flag is set in the master block to permanently mark the database.  By default, large file processing is NOT enabled.  The reason for this is that once large files are enabled, releases prior to 9.1C will be unable to use or open these databases.  Earlier releases don't have the code necessary to use large files.

Please note that even in 9.1C and 9.1D, Progress still does not support large files on the following operating systems:

Linux:  
We still support some older Linux versions that do not have large file support, therefore we could not enable large files support in the Linux port.  Progress 9.1E supports large files on Linux
 
SCO OpenServer:
The operating system does not support large files.
 
SCO UnixWare:
The port for SCO UnixWare is the same as for SCO OpenServer; because SCO OpenServer does not support large files, we could not enable large files support in the SCO UnixWare port either.

When large file processing is enabled for a database, fixed and variable length extents with specified maximum sizes beyond 2GB are allowed.

If a variable length extent with no specified maximum size is created for a database with large file processing enabled, the extent will be allowed to expand to a maximum of 1 TB depending on the database blocksize and records per block.  (See the chapter, "Progress Database Limits" in the "Database Administration Guide and Reference" for details.)

For databases that do not have large file processing enabled, extents will be restricted to a maximum of 2GB, or the size specified for it in a .st file, whichever is less.

The following files will be allowed to exceed 2GB in size when large file processing is enabled:

  After Image Extents (.an)
  Before Image Extents (.bn)
  Control Area Extent (.db)
  Data Extents (.dn)
  Transaction Log File (.tn) 

  • Other files, in particular those that are directly accessed by 4GL client code (such as Data Dictionary .d files), still have a 2GB size restriction.The file system(s) where the database resides must be enabled to support files larger than 2GB.  
  • For some operating systems, file systems do not support large files by default and large files support must be enabled explicitly.
  • On an OS level, make sure that the ulimit for the users who will access the database is set to 'unlimited', or a limit higher than the expected size of the database files.
  • Various operating systems have differing limits on the maximum file sizes they support. For example, the maximum size of  files on IBM AIX is 64Gb.
  • The Progress backup(PROBKUP), restore(PROREST), binary dump, and binary load were enhanced to support large files in version 9.1B (except for Linux, where this feature has been introduced in OpenEdge 10).
  • As of 10.1C, the files mentioned in the ABL statements INPUT FROM and OUTPUT TO are no longer limited to 2 gigabytes in length. Also the lbi and srt temporary files for local before-imaging and sorting/result-listing are no longer subject to the 2 gigabyte limit.
The following are three ways to enable large file processing for a database:
  1. prostrct create - When creating a new database, if the .st file specifies a fixed length extent size or a maximum size for a variable length extent that is greater than 2GB, large file processing will be enabled for that database.  The following command will create a database with large file processing enabled:

prostrct create largedb largedb.st
where largedb.st contains, for example, the following:

   #
   # largedb.st to create database largedb wit.h large file
   # processing enabled.
   #
   # a fixed length bi file of 1GB and a variable length
   # bi file with a maximum size of 4GB
   #
   b tests/largedb.b1 f 1048576
   b tests/largedb.b2 v 4194304
   #
   # SCHEMA AREA with a fixed length file of 3GB and a variable
   # length file with a maximum size of 3GB
   #
   d "Schema Area":6,64 tests/largedb.d1 f 3145728
   d "Schema Area":6,64 tests/largedb.d2 v 3145728
   #
   # TABLE AREA with a fixed length file of just over 2GB and
   # a variable length file with a maximum size of 1TB
   #
   d "Table Area":7,64 tests/largedb_7.d1 f 2097280
   d "Table Area":7,64 tests/largedb_7.d2
   #
   # a fixed length ai file of 2GB and a variable length
   # file with a maximum size of 1TB
   #
   a tests/largedb.a1 f 2097152
   a tests/largedb.a2
   #


2) proutil - You might enable large file processing for a database by running a new proutil option. The syntax of the command is as follows:

proutil <dbname> -C EnableLargeFiles

where "<dbname>" is the name of the database.

The database must be offline when enabling large file processing. 
There is no corresponding command to disable large file processing for a database.
Once large file processing is enabled for a database, the database can not be accessed by Progress versions prior to 9.1C.
In Progress versions 9.1E and later, the proutil EnableLargeFiles utility may be used to enable large file processing on a void database.



3) procopy/prorest - In Progress versions prior to 9.1E, if a database is created or replaced using procopy or prorest utilities and the source database has large file processing enabled, large file processing will be enabled for the target database. Similarly, if a database with large file processing enabled is copied to a void Progress database, the target will have large files enabled. Copying of a database without large file processing to another that has large files enabled will not cancel large files on the target.

In Progress versions 9.1E and later, if the target database of a procopy or prorest operation exists (even if only as a void database), the target’s large files setting will not be changed. Void databases in these versions may be enabled for large file processing using the proutil EnableLargeFiles utility. This change was made to allow the designer of a database to determine its large file status, rather than the procopy or prorest function.

As in Progress versions prior to 9.1E, if the target database in a procopy or prorest operation does not exist, the resulting database’s large file processing state is set to match that of the source database.

Enabling large file processing for a database will allow existing variable length extents that were created without a specified maximum size to expand beyond 2GB. New fixed and variable length extents with maximum sizes greater than 2GB may be added. Existing extents with a maximum size that was specified in a .st file will not be affected.

The prostrct add utility, used to add extents to an existing database, does not enable large file processing. In order to add a file with a  specified size larger than 2GB, large file processing must already be enabled for the database as described above.

Specifying Maximum Size for Variable Length Extents:

In version 9.1C is the ability to specify a maximum size for variable length extents. To do this, you can specify "v" as the extent type (in addition to "f" for fixed-length, or nothing for variable-length); after the "v" you must specify the maximum size for the variable length extent.

Existing .st files do not have to be changed.

The syntax description of the line format for a structure description  file is shown here:

    line               =  comment | areatype  pathname [sizeinfo]

    comment            = * | : | #

    areatype           = a | b | d | t [areainfo]

    areainfo           = ["areaname"[:areanum][,recsPerBlock]]

    areaname           = string

    areanum            = numeric value

    records per block  = numeric value

    path               = . | string | !"string2"

    sizeinfo           = extType size

    extType            = f | r | v

    size               = numeric value > 32

The following lines illustrate definition of two variable length extents, one with a maximum size of 3GB and one that may expand to the maximum area size, assuming that large file processing is enabled.

   d "Employee":7,32 /usr1/emp v 3145728
   d "Invoice":8,32 /usr1/inv

Note that specifying a maximum size for a variable length extent does not cause it to be pre-allocated to that size. It only means that the extent will not be allowed to grow beyond the specified size.

Also note that,at most,one variable length extent per data area is allowed and it must be the last extent in the area..
Workaround
Notes
Attachment 
Last Modified Date9/13/2015 4:15 AM
Disclaimer

The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.



Feedback
 
Was this article helpful?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful.



Characters Remaining: 255