A DBA's Guide to OpenEdge Database Startup Parameters: The Good, the Bad, and the Obscure

The Parameters You Must Never Use in Production

These parameters might look tempting, offering quick performance gains, but they will lead to a game like "Russian Roulette". You may very well get away with it from time to time and be lulled into a sense of safety and happiness. But eventually you will roll the bad roll.

• -i (I don't care about my data): There is a popular myth that circulates to the effect that this parameter eliminates writes to the BI (before image) file, -i reduces bi notes but, more importantly, it also actually makes the I/O operations that write them unreliable. If anything goes wrong, your database is toast. You will receive a blunt error: "The last session was run with the no integrity (-i) parameter. (509)" and "Your database cannot be repaired. You must restore a backup copy. (510)". It's not kidding!
• -F (F*ck data integrity): This is typically used after a nasty error like a mismatched timestamp or an 1124 error, which is the big, scary one that means you’re in real trouble. It tells the database to "pretend that everything is fine". But everything is NOT fine. The database will warn you: "Your database was damaged. Dump its data and reload it. (37)". This isn't an empty threat; you'll have to reload and will still have relational integrity issues.
• -r (non-raw): This is less dangerous than -i and has many of the same performance benefits. While you might be able to recover from a crash, it's still not for production. The error message is a little softer, saying "Your database may have been damaged. (518)", but you should still only use it for tasks  which can be easily repeated by starting over (perhaps  by restoring a backup). Building a new db from scratch ("loading"), index rebuilds, or rolling forward redo logs.

The Default Settings Are Overly Conservative (And How to Fix Them)

You'd be surprised what some of the default values are in OpenEdge, even as of version 12.8. They are simply unreasonable.

The Critical Omissions

• Helper Processes: Workhorse processes like BIW, AIW, APW, and WDOG do not start by default. You should always start them, including the BIM (Before Image Manager), to assist with I/O on behalf of the user. Note: BIM is not available until OpenEdge 12.6 or better.
• After-Imaging: This is still not enabled by default, even in 2025. This is not optional. If your database crashes late on a Friday afternoon (as they always do), your recovery point is your last backup, which means you've lost an entire day of data. You need after-imaging enabled.

 Well-Known, But Still Abused

You know these parameters, but they are often misused as a workaround instead of a fix.

• -L (Lock Table): I've seen customers set this to over a billion. Why? Because they have one process like a year-end close that needs to lock a lot of records. But setting a ridiculously large lock table is just a workaround. The problem is with the code. A lock table overflow should be a "wake-up call" to fix the code, not just change a parameter.
• -B (Buffer Pool): The buffer pool defers disk I/O, as memory access is thousands of times faster than disk I/O. There is, however, no benefit for the buffer pool to be larger than your entire database.
• -bithold (BI Threshold): This is supposed to prevent a runaway BI file, but when it is triggered it looks, to the users, like the db has “frozen” or crashed. And it will probably happen while you are out at lunch and your backup will be scrambling to figure out what is going on. That often leads to rash actions and a cascade of errors. You need a good plan to monitor and respond to it.
• -ServerType: The default is "BOTH," which is a trap. The first clients that connect (either 4GL or SQL) can grab all the server slots, stranding the other type. Always specify either "4GL" or "SQL" and if you need both server types start a dedicated server for each
• -minport and -maxport: These network port ranges are often too wide and shared across many brokers. Your firewall team will love you if you set them correctly, but they'll hate you if you make the ranges too wide, as you only need a port for every server, not every user. Use separate, discrete ranges for each server to avoid conflicts.

 Some Lesser-Known Gems for Performance and Reliability

These parameters aren't always on your radar, but they are crucial for a modern, reliable OpenEdge deployment.

Network and I/O Tuning

• Network Prefetch: Parameters like -Mm, -prefetchDelay, and -prefetchNumRecs make a huge difference for no-lock queries.
  • With modern CPUs, it's actually faster to batch a bunch of records into a single, larger message than to send the first record immediately, which is what OpenEdge used to do. If you are on OE 11 or earlier use -prefecthDelay to change this. On OE12+ it is the default now.
  • Recommendation: Set -Mm to 16,384 (default was 1,024 before OE12, 8,192 in OE12+) and -prefetchNumRecs to 5,000 (default was 16 before OE12, 64 in OE12+). Since OpenEdge 11.6, you only need to set -Mm on the server which enables much simpler administration..

Reliability and Diagnostics

Reliability: You should consider using -MemCheck 1 and -DbCheck 1. While they are disabled by default and may have a small performance penalty, the peace of mind they offer far outweighs this. 

• Caveat: we recently learned that if more than one database is connected to a session (which is common) and the databases use different block sizes (which is not common) then -dbcheck can cause a db crash.  Progress kbase:  https://community.progress.com/s/article/ABL-process-crashes-with-error-49-when-using--DbCheck-parameter

• proGetStack & Client Statement Cache: If you've ever had a lock table overflow and a user says, "It wasn't me!" (because they're the victim, not the perpetrator), diagnostic tools are your best friend.
  • You can use proGetStack to get a stack trace if you have admin access to their machine.
  • If you don't, you can enable the client statement cache in advance to find the specific line of code and procedure they ran that last touched the database.
  • The -diag* parameters will dump a boatload of information about what everyone else was doing!

Miscellaneous

• Log Management: You can use -lgArchiveEnable, -lgArchiveDir, and -lgTruncateFrequency to automatically archive and truncate your database logs, preventing a log file from growing into a huge, unmanageable file.
• Connection Timeout: The -pendConnTime parameter defaults to 30 seconds. Since a client makes up to 50 attempts by default, this can lead to a very long wait. Setting this value much lower is often advisable.

 The New(ish) and Important Stuff (OpenEdge 12+)

OpenEdge 12 introduced significant architectural changes you need to understand.

• -threadedServer: This is enabled by default in OpenEdge 12 and allows for multithreaded 4GL servers. The goal is "fewer servers and more connections per server". Review your -Mn, -Mpb, -Ma, and -Mi settings to maximize the benefit.
• -ssj (Server-Side Joins): Enabled by default (-ssj 1). I’ve seen this feature "absolutely knock your socks off" for specific queries, especially ones where you're looking for records that don't contain something. It won't hurt the performance of other queries.
• Autonomous Update Statistics (AUS): A background service for the SQL engine that automatically updates statistics for "dirty" tables when at least 20% of the data has changed.
  • Enabling: Run proserve dbname -SQLAutoStats ON.
  • Warning: It requires at least seven additional connections, so adjust your -n and -Ma parameters. You must still run UPDATE STATISTICS initially, as 20% from zero is still zero.
• proBIM (BI Space Manager): This new process proactively reuses BI clusters even if a long-running transaction is holding open a note earlier in the file. This can significantly reduce the size of your BI file, preventing disasters like the customer case where a new feature led to a long-running transaction and a 500 GB BI file before the database was aborted.
• Notification Parameters: -dbnotifytime (default 30 seconds, OE 12.2+) and -usernotifytime (default 0, OE 11.x+) are used to notify clients about online schema or parameter changes. They can be viewed and modified using the _dbParams and _Servers VSTs. Always use a non-zero value.

Latches and Buffers

• -hashlatchfactor: Introduced in 11.7, this controls the number of latches for the buffer hash table (BHT). The BHT itself is a prime number in the neighborhood of 25% of the -B value, and this parameter defaults to 10% of the BHT size. Only adjust this if you are seeing latch contention.

 Not a Parameter, But It's Important (Database Structure)

These are critical configurations that are set when the database is created or changed offline.

• Database Block Size: You should use 4K or 8K, not 1K or 2K. As of OpenEdge 12.7, 1K and 2K are no longer options for creating new databases.
• Rows per Block: "Err on the high side" to get better packing of the data and waste less space in the block.  A general recommendation is 64 or 128.
• Blocks per Cluster: For Type 2 storage areas, use a cluster size of 512. The only Type 1 storage area you should have is the schema area, with no application data.
• BI and AI Block Sizes: It is recommended to set both of these to a size of 16.

Making Changes Online

You can make online changes to an ever-expanding list of eligible parameters using PROUTIL -C increaseto.

• Requirement: -dbnotifytime must be greater than zero at database startup. If it is disabled (set to 0), you cannot enable it online.
• Limitations: Changing -B with increaseto will not automatically recalculate dependent values like -hash. Replication sources and targets are also not updated, which can interfere with fail-overs and restarts.
• You can also use the _dbParams VST to modify parameters online with a for each statement, provided a notification parameter is enabled.

 The Roaming DBA's Final Word

The difference between a stable, high-performance OpenEdge environment and a brittle one that crashes on a Friday afternoon often comes down to a few minutes of attention to your startup parameters.

We've seen it all, from the systems that swear they don't need after-imaging until a crash wipes out a day or more (sometimes a LOT more) of data, to the administrators who try to fix bad code with a billion-sized lock table.

We’ve learned the hard way; both Rob and I have had to recover months worth of data via after-imaging roll-forward. Stop applying workarounds. Start using these parameters strategically.

Adopt the modern architecture of OpenEdge 12 and the new helper processes. Take control of your database environment, and you'll find that the "obscure" parameters become the secret weapons that keep your system running fast, reliably, and quietly.