Operations | Monitoring | ITSM | DevOps | Cloud

If you’re using SQL Sentry regularly, there’s a great event management feature that provides a lot of value for our advanced users. I often find the SQL Sentry Event Calendar isn’t being used as often as it once was. The Event Calendar lets you view historical and future events, drill down into event failures, and reschedule jobs using drag and drop all from within the SQL Sentry desktop client. In addition, you can create custom views of events you need to reference frequently.

In today’s post, we’ll dive into how we, at AppSignal, solved a daunting engineering challenge. Giving you a look into the kitchen, this post will show you how we tested a new database in production without having to worry about errors/downtime. Alright, let’s get cooking!

When I first started trying to figure out how to automate database deployments, over 15 years ago, I will freely admit, I was both skeptical and reluctant. I had to be dragged up to the notion that automating getting the database code out the door wasn’t just an excuse by the developers to find a way to bypass the DBA team. As per the traditional, biased, story, our favorite word was “No!”.

"No one likes documentation", chirped the little blue birds. The bird quotes in the image above are all taken from real tweets and are listed below for accessibility: I can't argue with "liking to write documentation" being a rare skill, since so many people are vocal about disliking it. That tweet might prove to be true, in which case, technical writers should simply be more appreciated for the rare gems that they are. In this blog post, however, I’m going to explain.

SentryOne Document supports multiple metadata sources, and we plan to expand available providers in the future. But what if you want to add a metadata source that isn’t currently supported? This is where SentryOne Document’s Custom Metadata Import, available in both the Software and Cloud edition, can help. Leveraging this provider, you can manually insert any metadata source—DB2, REST API, or others.

Once you’ve committed to changing your culture in order to automate your database deployments, what’s next? You’ve already done the hard part, making the decision to shift the culture. Now, what’s involved is just lots of labor. There are three things you can do to begin your Database DevOps journey: Let’s discus these in detail. It’s important to understand, not just why these are your first three steps, but why they should occur in this precise order.

How would you like it if your application shut down or started running slow without any warning? Let’s say, for instance, users who like your application try to access it, but aren’t able to. How would you know whether low traffic to your site is because users weren’t satisfied or because they simply weren’t able to access it? Users definitely won’t be satisfied when your application starts crawling with long response times.

When DevOps teams talk about monitoring a database, the primary motivation is to ensure that the database won’t suffer a performance hiccup. Long queries, timeouts and table scans are among the most popular causes behind lousy customer experience. However, in recent years, more data has been shifted to cloud databases.

VoltDB is an ACID-compliant, in-memory relational database designed to support real-time analytics. VoltDB’s in-memory storage, stored procedures, and shared-nothing architecture make it specifically optimized for quickly processing massive streams of data. This means VoltDB is tailored for use cases like online gaming, telecommunication, and financial applications, which require fast data processing.