The OpenEdge DBA Files

Read on for more soul crushing, database corrupting, career killing ways to CRASH your OpenEdge database!

Linux "Out of Memory Killer"

A Linux self-preservation mechanism, the OoMK terminates a process when memory is over-committed. Unsurprisingly, the OoMK kills the process consuming the most memory, which, most likely, is the database broker process.

A quick Google search will turn up numerous interesting articles on how to avoid this situation, including ways to tune "oom_adj". In practice, though, it is unlikely that your database will be spared and you are better off making sure that you have ample memory to handle the expected workload on your server. 

The best way to avoid disasters is to learn from mistakes, preferably someone else’s. Memorize this series or polish your resume-writing skills!

Welcome to our monthly ProTop newsletter, where you’ll find out what’s new, tips and tricks and other cool ways to use both the free and commercial versions of ProTop.

Database Administrator (DBA). Sounds important, doesn’t it?  But what are you supposed to do every day?

People often ask us: “what tasks should an OpenEdge DBA be performing? When? What should my daily, weekly, quarterly, etc. checklist have on it?”

Welcome to our monthly ProTop newsletter, where you’ll find out what’s new, tips and tricks and other cool ways to use both the free and commercial versions of ProTop.

Welcome to our monthly ProTop newsletter, where you’ll find out what’s new, tips and tricks and other cool ways to use both the free and commercial versions of ProTop.

Welcome to our monthly ProTop newsletter, where you’ll find out what’s new, tips and tricks and other cool ways to use both the free and commercial versions of ProTop.

Anyone who has been around the OpenEdge world for a while has had to face the dreaded “User died holding shared memory latch. ABNORMAL SHUTDOWN” crash. While this sometimes happens as a result of a Progress OpenEdge bug, more often than not it’s a human error. Here are three key points to understand in order to minimize the chance of crashing your database when trying to terminate a shared memory client.

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.

No one wants to think about a database crash, and even less about losing data, and yet every month or two I get a call from an IT Director in exactly that situation. Their OpenEdge system has been down for hours and stays down for hours more while we do our best to perform emergency surgery. In the end the customer is left with a stitched up database and a post-mortem that reveals that all this could have been avoided if they had simply followed the advice in this blog and protected their OpenEdge database with after-imaging.

Protecting against lost data

Data protection is comprised of two equally important components: backups and after-image archives. Almost everyone understands backups: if there’s a problem, they get you 95% of your data back, up until the time of the last backup. After-image archives get you down that last mile, containing the detailed changes that were applied to your database. Think of them as a recording that you can play back (we call this “rolling forward”) on top of your restored DB. All the recorded changes are applied to the restored database in the same way as they were done the first time around.