The OpenEdge DBA Files

It's for developers too!  Read on to see how ProTop can inform your development lifecycle by helping you uncover issues before they reach production. Oh, and it's free!

Has your OpenEdge Database Application fallen victim to the Out Of Memory (OOM) Killer? Are you hunting for memory leaks? Use ProTop's "dirty memory" script on Linux to see which processes hold more private memory than others.

You might imagine there are many ways to back up an OpenEdge database.  But not all of them are created equal. And if you haven't tested it, it doesn't count!

Cardinal rule #1 - Use probkup

• Do it daily during a lull in user activity - no reason not to. With the ability to back up online, business is not interrupted.
• Buy more disks if you have to, but back up to a local drive, uncompressed. This way, the backup is ready to restore (and roll AI/archives against), reducing the time you need to return to operations (RTO).
• You must use it if you use OE Replication, as it's the only way to reseed a replication target.
• Watch out! It might slow down your application for data stored in type I storage areas  (What? Still using Type I storage areas? tsk tsk).  
• Disk reads will jump while the backup reads blocks not already in memory, dropping your buffer hit rate. But you'll likely not feel it if you stick to the first bullet above.

Cardinal rule #2 - Back up ALL of the files needed to effect a restore

• Execute a prostrct list as a part of your backup routine and include the structure file in the files you back up.
• Include the keystore if TDE is enabled in the database.

Cardinal rule #3 - Don't rely on incremental backups

• They can take just as long and create a similar-sized backup.
• They add unnecessary complexity (see the exception below).
• You still need a full backup before you can take incremental backups.
• If you do not perform full backups regularly, you will use increasing amounts of backup media for incremental backups and expanding recovery time due to needing to restore multiple incremental backups in addition to the full backup.
• EXCEPTION: If an application database undergoes an extended period of very high write volume, taking periodic incremental backups may be less I/O intensive than writing to lots of large AI extents.  Test it!
• If you are using after-imaging (you are, right?), there is no reason for incremental backups (except for the exception above!).

probkup switches to use

• -com - reduces the number of IO ops needed to create the backup file and reduces the backup file size (may decrease the speed of backup on high-speed systems, so test!).
• -verbose - to know where you are.
• On 11.3.x or 11.4.0 - use "bibackup all" to overcome the prorest bug (fixed in 11.5.0) that, if not used, will render the backup useless!

Cardinal rule #4 - Test it, regularly

Document and exercise your restore process (prorest) regularly to verify it (still) works!

Use ProTop to monitor and alert for lock table usage and discover the cause of lock table overflows in your database application.

"Will ProTop tell me when it is time to add a new fixed and or variable extent to my OpenEdge database?" It most certainly can.

The schema area should not be used to store application data. And, if you are getting ready to dump & load, certain schema attributes require special attention.

Blocked sessions are the silent killers of enterprise applications. No one in IT notices there's a problem until the business is seriously affected.

ProTop is a living breathing entity. It is growing and changing all the time. Be sure to regularly update your installation to ensure you have access to all of the great new features, enhancements and fixes. Here's how...

It all started on Monday evening when the Out Of Memory (OOM) killer decided to kill the database broker process, _mprosrv. Given the circumstances, it was suggested that we “just” reboot. “Just” is a four-letter word. Whenever you hear “just,” you should prepare yourself…

So we rebooted…

… and, of course, it took longer than expected. Forty-five minutes to shut down (mostly to “deactivate” swap), and then, since the server hadn’t been rebooted for 2 years, the filesystems needed another 45 minutes for an fsck. Ok, that was painful, but at least we have a nice clean system to restart the db.

If you follow the guidelines suggested here, you can expect more hours of uninterrupted sleep at the very least, and at best? You will experience minimal disruption to your system should your OpenEdge databases be damaged for reasons beyond your control.