| Resolution |
The OpenEdge Database engine can run for long periods of time when awareness of limits, monitoring and documented procedures are in place. The following list, excludes performant and DR strategies. While not exhaustive it, documents items to consider to ensure that a database will not need to be taken down for offline maintenance.
- Sufficient disk space for current and future data (.d#), Before image (.b#) and After image (.a#) extents. Including a periodic PROSTRCT STATISTICS report aides in understanding current and predicting future area growth. Refer to Article How to find out the space utilization of a database?
- Large files can be enabled on Enterprise databases: proutil <dbname> -C EnableLargeFiles to allow maximum variable extent file extent growth. Refer to Article How to tell if proutil -C EnableLargeFiles has been run against a database?
- The Before-Image Clusters will be constantly reused as long transactions complete. There can be special job runs that may include a large scope transaction or a runaway job that causes unexpected BI growth that may eventually exceed current disk capacities. To avoid reaching the maximum available space, database startup parameters -bithold and -bistall can be used to halt bi growth online until addressed. Ensure a written procedure on how to identify and respond to a bi stall event is available. Refer to Article How can -bithold -bistall and the proquiet bithreshold be implemented?
- When using OpenEdge Replication or After Imaging it is necessary to have empty AI extents available. This can be achieved with the use of RFUTIL scripts that copy the full AI extents to a backup directory or by enabling the AIArchiver. Refer to Article How to enable automated AI File Management?
- OpenEdge 10.1C04, 10.2A02 or 10.2B releases, the After Image sequence number limit was raised to 2,147,483,647. In prior versions the limit was 65,535, at which time AI files can no longer be rolled forward. Cannot roll forward AI files when sequence number is larger than 65535 error 8019
- A Progress database can be backed up with PROBKUP 65535 times, before it needs to be dumped and loaded. Refer to Article How many online probkups can be taken?
- If Type II Storage Areas are not used, they need to be periodically monitored to be able to proactively restructure online before MAXAREA is reached. Refer to Article When does the 2 billion rowid limit per Storage Area apply?
- Type II Storage Areas should be used. The ease of most online maintenance operations and the performance of such are facilitated by having this structure as opposed to Type I Areas.
- Memory overwrite checking should be considered as a proactive measure Refer to Article What is the -MemCheck Parameter?
- Periodic IDXCOMPACT should be run online where warranted. Refer to Article Which is better IDXBUILD or IDXCOMPACT?
- Periodic database integrity checks should always be run in order to proactively address issues before production sites experience the consequences. Refer to Article What tools / utilities can I run to check the integrity of a database or check for corruption?
- Periodically re-evaluate that sufficient Shared Memory structures are available. Database Buffers and specifically Lock Table Entries as more users and more data are processed by the application over time. Exceeding Lock Table entries can cause dbdowns when -Mxs is eventually exhausted. Refer to Article -B and -L Database startup parameter values recommendations.
- Ensure that the runtime database environment is excluded from any third party access outside of a quiesced database. Refer to Article What are Database Quiet Points?
- When making online Schema changes, special considerations are needed for inactive indexes. In particular Primary Indexes and Schema Changes to Replication Enabled environments. Refer to Article How to activate a Primary Index
|
|
|---|
