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. 

Nectar Daloglou‘s post on 99 Ways to Crash Your Database was so popular, we thought we’d bring you even MORE ways to ruin the upcoming holidays!

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.

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.

Friday. 11:00 AM. I get a phone call from a managed services provider who knows nothing about OpenEdge. Their customer had been down since around 5:00 AM and no one knew what to do. Oh, and by the way, this is version 8 on Windows.

Ahhh…Mike Tyson. You gotta love Mike Tyson. You, on the other hand, you are probably more like Marvis Frazier. I see the puzzled look on your face: no, not Smokin’ Joe Frazier, the first person to beat Muhammad Ali in 1971. I’m talking about Marvis Frazier, his son. Look it up: KO’d in 30 seconds. Nice uppercut in the first round. When people talk to me about their high availability measures, I think about Marvis Frazier. Good looking guy. He talked the talk and walked the walk, but when it came time to deliver, he failed. Twice. Most of your high availability planning is the same. It’s good enough to impress the 24-year-old junior auditor from Deloitte but will never deliver when you actually need it.