The OpenEdge DBA Files

Posts about:

Business Continuity

New DBA Series: Please Don't CRASH Your Database AGAIN!!

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. 

Read More

User Died, DB Crashed, Business MAD!

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.

 

Read More

Corruption and Crash Protection, Courtesy of After-Imaging

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.

Read More