Consultor Eletrônico

Status: Verified

GOAL:

What are the Progress database enhancements in 10.1B?

GOAL:

Progress Database new functionalities introduced in OpenEdge 10.1B

GOAL:

Summary of OpenEdge new functionalities in 10.1B

GOAL:

What are the database enhancements in 10.1B?

FACT(s) (Environment):

All Supported Operating Systems
OpenEdge 10.1B

FIX:

Summary of the OpenEdge RDBMS related changes in the 10.1B release. Please refer to the "OpenEdge Getting Started: New and Revised Features" documentation for full details.

Most of the features listed have to be explicitly enabled. To view the current feature-enablement of a database, run 'proutil dbname -C describe' for a full listing.

1) Elimination 2.1 billion row limit for Storage Areas - large table support

For tables stored in Type II Storage Areas, rowids and block numbers have been expanded from 32 to 64 bits. The maximum number of rows in an area (and a table) is (2 ^ 63). This feature is automatically enabled when a database is first opened in OpenEdge 10.1B. Effectively database tables can grow to 9 quintillion rows, effectively physical limits of storage areas will be reached before the row limit is reached for any given Storage Area. This change also affects the contents of indexes and the transaction logs and a variety of error messages.

2) Maximum storage areas increased.

It is possible have 32,000 (-6) Storage Areas (previous limit was 1,000 - 6) making it easier to maintain and scale large databases. The -maxarea database startup parameter has been added to configure this as needed. The maximum number of extents per Storage Area remains 1000 pre-10.1B and 1024 post 10.1B.

3) 64-bit dbkeys

rowids (and recids) are widened to 64 bits in order to store and retrieve rows in large tables.

If an application practices treating integers and recids as interchangeable, an error is raised when a recid value is stored in an integer variable or column /and/ the value to be stored is larger than approximately 2.1 billion.

Converting rowids to character strings will produce longer strings (more digits).

The format of OpenEdge 10.1B bi-notes, ai-notes and backup files are different to previous versions due to the expanded size of the dbkeys, rendering these incompatible with prior versions. The 'proutil -C revert' utility needs to be run against an OpenEdge 10.1B+ database in order to allow utlity access in earlier OE10 versions (provided no 10.1B+ features are in use). Additionally, please refer to Progress Solution P120084, "Summary of compatibility rules for 10.1B and earlier OpenEdge versions."

All OpenEdge 10.1B+ database utilities support 64-bit dbkeys.

If the database was not dump and loaded to or created in OpenEdge 10.1B+, it is advisable after backing up the database in OpenEdge 10.1B+ to run the 'dbtool dbname' > Option 6. Record Fixup prior to starting the database for application access. This utility finds and pads out any records < 10 bytes which would cause problems later if fragemented.

4) 64-bit integer data type and Sequence generator value support

A new data type, INT64, has been added to the 4GL set through the data dictionary. SQL had support for 64-bit integers previously: BIGINT).

Sequence values can now be 64-bit integers. If the database was not dump and loaded to or created in OpenEdge 10.1B+, sequence support for INT64 can be enabled with the "proutil dbname -C enableseq64" utility.

5) Larger index keys

The maximum size of an index entry has been increased to 2,000 bytes provided a database block size is at least 4096 bytes.
If the database was not dump and loaded to or created in OpenEdge 10.1B+, sequence support for INT64 can be enabled with the "proutil dbname -C enablelargekeys" utility.

6) VST's (virtual system tables)

If the database was not dump and loaded to or created in OpenEdge 10.1B+, it is advisable after backing up the database in OpenEdge 10.1B+ to run "proutil dbname -C updatevst" to ensure the latest. working set of VST's.

a) VST counters expanded to 64-bits

Most of the counter value columns in the virtual system tables have been change to be of type INT64.

b) _UserTableStat and _UserIndexStat

These are new VST's to allow reporting per user, table and index activity counts

7) Improved shared memory segment allocation

Enhanced shared memory to effectively store and execute against huge data tables without forfeiting system performance. Previously, the maximum shared memory segment size the database would allocate on 32-bit systems was 128 megabytes (or less if the OS didn't allow) and 1GB on 64-bit systems. A new database configuration parameter, -shmsegsize, allows the shared-memory segment size to be set explicitly. For 32-bit systems, this means a database can address fewer but larger shared segments (up to the size allowed by the operating system). On some operating systems, this means it will be able to use more shared memory than before (but it is still a 32-bit address space) when limited by the number of shared-memory segments a process can allocate by the OS. In particular, note that AIX allows up to 256 megabytes shared-memory segment size.

On 64-bit systems, a database can address up to 32 gigabytes per segment (previously 1 Gygabyte) and the maximum number of segments has been increased to 256 (from 116). If the operating system allows.

Please refer to PSDN whitepaper for further details on this subject: OpenEdge Release 10.1B and higher Shared Memory

8) Add new Storage Areas online

Storage Areas can be added online with the 'prostrct addonline dbname addonl.st" if certain concurrency conditions are met. Previously, OpenEdge 10.1A could only add extents to an existing Storage Area.

9) Enable After-Imaging online

After-imaging can be enabled on online, through the 'probkup online' utility, provided ai extents are already present in the database structure.

10) Multi-database queries in ODBC/JDBC

Applications that access the OpenEdge database through odbc or jdbc can perform queries involving multiple databases on the same host..