| Resolution | Why are we proactively communicating about the maximum 2.1 billion ROWID, per database Area? This limit is not new, and has been discussed frequently over the life of Progress Version 9 and OpenEdge Release 10. However, because of the continued growth in database size due to regulatory changes as well as business growth, and the fact that not all customers are aware of the limits, we feel we it is prudent to draw additional attention to it, Customers experience unplanned downtime when reaching the maximum. Compounding the issue is a common misconception about how the maximum number of records per Area is calculated. Therefore, we are proactively informing and educating customers so that potential issues can be avoided. What happens if you reach the maximum 2.1 billion ROWID per Area? Your database will perform an abnormal shutdown. Recovering from the error may be time consuming. Can the issue be avoided? Yes, appropriate configuration planning and proactive monitoring and management of databases can avoid the issue completely. Who is most likely to hit this issue? Customers who have large tables and have configured the database Storage Areas so that each block can hold up to 256 records and using Type I Storage Areas or Type II Storage Areas prior OpenEdge 10.1B could reach the limit. See Article 000010613 for further details. To be specific, the setting of the “maximum records per block” (for example 256) parameter for the Storage Area is the value that will be counted against the maximum number of addressable rows for that Area. This is independent of the actual number of records physically in the block. If you have large records, then you may only have ten records in a block, but 256 rows would be counted against the maximum available (2^31-1). Also note that a record fragment also counts against the record maximum. Large records that are fragmented, therefore compound the issue. Note that the maximum number of records in a Storage Area is independent of database block size, but the probability of encountering the limit is a bit higher with block sizes below 8192 bytes. When did Progress know about this issue? It has often been discussed in technical sessions at user conferences and other events. It has always been a potential, but highly improbable, issue. With the ongoing growth in average database size, it is now becoming more probable. As a result, this is a subject that we believe all Progress Database Administrators should be more aware of and should take steps to avoid. What steps can be taken to avoid the issue? 1. Identify the Storage Areas that might be close to the maximums. (See Article 000010613 for further details of a tool to help in this task)2. Determine the optimal records-per-block for the database objects in that Area. Then either: a) Purge data from the Area to temporarily reduce the count of records within the Area until you can plan for proper migration of the data to an Area that has the optimal records-per-block for those tables.b) Use the tablemove option in proutil to move data to a new Area with a more optimal definition of records-per-blockc) Dump and load the data to a new Area that has the most optimal records-per-block for the tables impacted. d) Contact Technical Support if you need further information or guidance. If I hit the maximum what can be done? 1. Go to a previous backup. Then restructure your database as detailed above. or2. Go to backup and roll forward to a point in time before the maximum was reached. Then restructure your database as detailed above. Contact Progress Technical Support if you need further information or guidance. Are there other rowid maximums to be concerned about? In addition to the maximum number of rows per Area, there is a related limit: maximum number of data blocks in a Storage Area.
Both limits are affected by the setting of the Area’s record-per-block. While the maximum for the number of records in an Area is 2.1 billion, the maximum number of data blocks varies depending on the setting of records-per-block. Please see Article 000010613 for further details. Where are all the Database Maximums documented? For OpenEdge 10, in the “OpenEdge Data Management: Database Design Guide” in the Chapter titled “OpenEdge RDBMS Limits”.
For Progress 9, in the “Database Administration Guide and Reference” Manual, in the Chapter titled “Database Limits”. Is Progress considering changing the 2 billion record maximum? The maximum rowids per area has practically been removed in OpenEdge 10.1B with the advent of 64-bit rowids and Type II storage areas. The number of rowids per Type II Storage Area is governed by the maximum area size rather than the addressability of 32-bit database keys which is a hard limit on Type I Storage areas of 2^31 addressable rows per area (and Type II Storage Areas prior to OpenEdge 10.1B) See Article 000022229 for further information. Are there services from Progress that can help identify best recommendations for creating a database structure and how to organize data in Areas? Technical Support is always available to assist customers with questions regarding database maximums, tools, administration and recovery questions. The most effective way to plan database health is through a Consulting engagement. |
|
|---|
