We just upgraded the Minion Maintenance suite!

Welcome to the next version of Minion Maintenance! Now you have a single installer for all three modules, plus new features and fixes for the entire backup and maintenance suite!

If you take a look at the page for Minion Backup, Minion Reindex, or Minion CheckDB, you’ll see that the download now says “Minion Maintenance 1.1”. Welcome to the next version!

Now you have a single installer for all three modules, plus new features and fixes for the entire backup and maintenance suite!

Minion Backup and Minion CheckDB got some important fixes, but it’s Minion Reindex that’s the real star of this release. MR was added to the unified installer, got on board the table-based scheduling bandwagon, and received an overall shine, polish, and upgrade. See “New in Reindex”, below!

Download and install

First, download Minion Maintenance from either Minion Backup, Minion Reindex, or Minion CheckDB…it’s the same system no matter where you download it!

Next, extract the files and install using the Minion Install Guide document that’s included in the download.

New in Reindex

New features:

  • Reindex heaps: New setting in the settings tables lets you choose whether to reindex heaps, or not.
  • Database groups: Minion Reindex DB groups for include and exclude.
  • Updated internals: MR now uses the DBMaintSQLInfoGet function, like MC and MB do.
  • Scheduling: The Minion.IndexMaintSettingsServer table provides table-based scheduling, just like Minion Backup and Minion CheckDB.
  • Install: New Powershell installer!
  • “Current” views: Minion.IndexMaintLogCurrent and IndexMaintLogDetailsCurrent show you the most recent set of activity.

Issues resolved:

  • Fixed: Some errors were not captured in the log tables.
  • Fixed: Japanese/international characters in a table name caused errors.
  • Fixed: Performance issues.
  • Fixed: Issue with object names in brackets. If object names have square brackets in the name, it will cause a syntax error. We now surround object names in double quotes instead of brackets.
  • Fixed: Issue with running PrepOnly then RunPrepped immediately after, in the same window.
  • Fixed: Formatting issues in Minion.HELP.
  • Fixed: Updated code “section” comments.

New in Backup

  • Added delete for SyncCmds
  • Fixed: Creating “Christmas tree folders” when using robocopy with multiple files.
  • Fixed: Missing a couple of entries in the InlineTokens table.
  • Fixed: Some sync commands being written to SyncCmds table even though SyncLogs is 0.
  • Fixed: Wasn’t logging properly when a DB is in an AG.
  • Fixed: Formatting issues in Minion.HELP.
  • Fixed: Wrong restore location when restoring to a named instance and the path is being converted from a local drive.  The instance name was being included in the UNC path.

New in CheckDB

  • Fixed: Data explosion for remote CheckDB results pull. Remote runs were pulling all of the CheckDBResult data instead of just for the current run.
  • Fixed: ServerName not populating correctly for remote CheckDB for the Minion Enterprise import.
  • Fixed: MinionTriggerPath wasn’t set correctly for the base folder.
  • Fixed: Databases with periods or other special characters may not import into Minion Enterprise for central reporting. Changed delimiter for the import process to accommodate this better.

Download Minion Maintenance from any of the maintenance pages today! Minion Backup, Minion Reindex, or Minion CheckDB.

Your Service Level Agreement is a Disaster

As a DBA, you’re in charge of getting systems up and running quickly in the event of an emergency. This is all right and proper, right up until you start defining SLAs. Let’s see what went wrong.

As a DBA, you’re in charge of keeping the systems healthy, and getting them back up and running quickly in the event of an emergency. This is perfectly right and proper, right up until you start defining a service level agreement.

A Service Level Agreement (SLA) defines the level of service you agree to provide, to get the system back up after a downtime. An SLA is usually expressed in terms of time. So, if you have a two-hour SLA, that means you agree that when there’s a grave issue, you’ll have the system back up within two hours.

But how did you get that two-hour SLA in the first place? Usually, it goes like this:

  1. The customer explains that they must have the database up within two hours of a problem.
  2. You don’t see any problems with that.
  3. Maybe there’s even a written agreement that you sign, knowing full well your database experience can easily handle a downed database in that time.

Like so many things, this sounds perfectly reasonable on the surface, but doesn’t hold up once it comes in contact with reality.

SLAs in the Real World

SLAs are often poorly thought-out, and very rarely tested. As a matter of fact, most companies don’t even have SLAs; they have SLOs. An SLO is a Service Level Objective – something you’re striving for, but don’t know for sure whether you can achieve. SLOs allow you to have some kind of metric, without bothering to test in advance whether the objective is even possible.

This lack of testing is the primary barrier to achievable SLAs. Lots of factors can impact your ability to get a system up and available after an issue. Let’s take a close look at just two of those factors: hardware failures, and data corruption.

Hardware Failures

When a hardware failure causes an outage, it can take a long time to get replacement parts. Companies work around this – sometimes – by keeping replacement components on hand for important systems, but that’s only sometimes. If your company has no replacements lying around, you are completely at the mercy of the hardware vendor. This can – no, will – demolish your SLA.

Now, maybe your company has an SLA with the parts vendor, and maybe they don’t. Typically, that vendor SLA will be something like a four-hour replacement window…but that’s just when they agree to show up! The vendor can’t promise that the parts will be installed, configured, and running in that time.

So, your two hour SLA won’t work with the four hours it takes just to get the hardware, and the two (or more) hours getting everything set up. Oh yes, plus the time to diagnose the issue in the first place, possibly reinstall SQL, restore the database, troubleshoot additional issues, or all the above. All of this puts you at least three times the SLA you agreed to support.

Conclusions:

  • Consider how long it takes to get replacement parts.
  • If your customer is important enough, keep replacement parts in-house.
  • Account for extra time, for troubleshooting, installation, configuration, restoring, more troubleshooting, and anything else that can come up.

Data Corruption

Database corruption is another outage scenario. Depending on the level of corruption, it may take anywhere from a few minutes to a few hours to diagnose and fix it.

For now, we’ll assume that it’s just a table that’s gotten corrupted. Now, is it the data, or just an index? If it’s an index, depending on the size of the table, it could be a quick fix, or it could be a couple hours. However, if it’s a table, then you may have to restore all or part of a database to bring it back. That brings another host of issues into the fray, like:

  • Do you have enough space to restore the database somewhere?
  • How long will it take?
  • Is the data even onsite?
  • How will you get the data back into the production table?
  • Do you bring the system down while you’re fixing it?

Of course, it could also be the entire database that’s down, in which case you will need a restore (assuming the corruption wasn’t present in the last backup). A few of the things you must consider:

  • Do you know how long that restore will take?
  • Have you done what is necessary to make sure you can restore quickly by tuning your backups, making sure the log is small, turning on IFI (Instant File Initialization), etc.?

Without some foresight, you could easily spend that two hour SLA window zeroing out 90GB of log file. Your 1.5 hours of data restore will put you quite a bit outside of your agreement.

Conclusions:

  • Make sure you have space to restore your largest database, somewhere off the production server.
  • Implement a good CheckDB solution, plus alerting.
  • Practice various recovery scenarios to see how long they take.
  • Make sure your backups are in order.
  • Practice database restores, and get your backups tuned. (Tuning your backups means you can tune your restores, too!)
  • Take these practice sessions into account when you make your SLAs.

The Solution

The conclusions above are a good start, but not at all the complete picture. If you’re keeping a single SLA for any given server, you’re doing yourself and your customers a huge disservice.

First, define separate SLAs for the different types of failure, and define what each specific failure looks like. For instance, if you define an SLA for database availability, define what ‘available’ means. Does it mean people can connect?  Does it mean that major functions are online?  Does it mean absolutely everything is online?  Does it include a performance SLA?  I’ve seen performance SLAs be included in downtime procedures because sometimes a database is so important, if the performance isn’t there, then it might as well be offline.

Next, review SLAs regularly. So, you’ve reasonably determined that you can accommodate a four-hour SLA for the DB1 database. What about, as the database grows?  Are you going to put in an allowance for the database tripling in size?  Surely you can’t be expected to hold the same SLA two years later that you did when the database was new.

Finally, test, test again, and then test one more time just to be sure. In fact, you should be testing your recovery procedures periodically so you can discover things that may go wrong, or lengthen the process. if you promised two-hour downtime and you can’t get your recovery procedures under that time, then you’ve got some re-working to do, don’t you?  Don’t just throw in the towel and say you can’t do it, because contracts may already be signed and you may have no choice but to see that it works. Maybe you’re really close to being able to hit the SLA, and you just have to be creative (and maybe, to work for a company that’s willing to spend the money).

Integrity Checks are Useless*

Integrity checks have become more and more important over the years, as companies store more and more data. This data is absolutely critical, so when corruption happens, it can break a company. But in all but the smallest shops, running any kind of integrity check is all but completely useless. Unless you have Minion CheckDB.

Integrity checks have become more and more important over the years, as companies store more and more data. This data is absolutely critical, so when corruption happens, it can break a company.

But in all but the smallest shops, running any kind of integrity check is all but completely useless.

Integrity checks without management

DBCC CHECKDB was originally written without consideration of management. For a very long time, you could only output CHECKDB results to the client – meaning you had to run it by hand – or to the error log. Seriously, what good is that? Later, Microsoft added the ability to output CHECKDB results to a table, but that remained undocumented for years so very few people knew it even existed.

That’s not the only problem. A lot of DBAs don’t run CHECKDB at all, because large databases take a long time to process. CHECKDB takes an internal snapshot for its operations. For large databases, that snapshot can fill up the drive, killing the integrity check process entirely. So, you have nothing to show for your efforts. Some DBAs tried to get around this issue by moving to CHECKTABLE instead, but that process comes with the same issues, and is even harder to manage because there are so many more tables than databases.

Integrity checks without reporting

Another reason that running DBCC CHECKDB is useless is this: reporting is still very difficult. Let’s say you have 50 servers – yes, I know a lot of you may have many more than that – and CHECKDB is set to run through a maintenance plan, outputting results to the SQL error log. In this scenario, you have to mine the log for CHECKDB results. That means you not only have to know when the CHECKDB completes on each and every server, but you also have to know what the log entry will look like, and how to parse out the results so they’re readable…again, on every single one of 50 servers. There is simply no easy way to consume CHECKDB results on any kind of scale.

Useful integrity checks with Minion CheckDBMinion makes integrity checks useful again

The whole goal of Minion CHECKDB was to transform these issues surrounding integrity check processing into simple settings. Now DBAs of every skill level can have a stable, standardized integrity check process for even their largest databases.

Minion CHECKDB has a huge number of groundbreaking features. MC solves the reporting problem by capturing integrity check results to our own log table, along with a huge amount of additional information. Now it just takes a simple query to get the results. Instead of the native raw CHECKDB results, the MC log table tells you how many corruption errors were encountered. Then you can drill deeper from there if you like.

We’ve also solved the problem of the large database that can’t be processed because it runs out of snapshot space. In fact, we’ve solved that a few ways, and I’ll discuss a couple of them here.

  • You can create a custom snapshot on a different drive that has more space. MC manages those snapshots for you, so it’s literally a set and forget operation.
  • Or, you can restore a recent backup of your database to a remote system and run CHECKDB against that instead. Remote CHECKDB even brings the results back to the primary server, so you don’t have to go hunting for them. Again, this is a setting; you configure it, and then MC manages the whole process for you.

Of course, there’s more

There are many more features in Minion CHECKDB that I didn’t mention. But since MC is completely free, you can download it and install it on as many instances as you want. Go explore!

Put MC on all your systems and start doing integrity checks again. We’ve taken away all the excuses. And when coupled with Minion Backup and Minion Reindex (both also free), you’ve got a maintenance suite that meets all your needs from planning to reporting, and everything in between.

 

*Without proper management and reporting!

Webinar: Introducing Minion CheckDB!

Minion CheckDB will be available for download on February 1, 2017! In celebration, we’re having a Minion CheckDB webinar on Wednesday, February 1 and on Friday, February 3 at 12:00 PM.

 

productimg_checkdb

Minion CheckDB is available for download as of February 1, 2017!

In celebration, we had Minion CheckDB webinars.

Done: And, we will be giving away 3 licenses of Minion Enterprise to one lucky winner* at each webinar. Must be present to win! 

Minion CheckDB completes the MinionWare maintenance and backups suite in style. Each solution is plug-and-play for the busy DBA, and deeply configurable for those shops with in-depth needs.

This new module is MinionWare’s most ambitious free release yet, featuring all of the rich scheduling and logging functionality in previous products, plus remote CheckDB, multithreading, custom snapshots, rotational scheduling, and more.

In this webinar we’ll show you how this FREE tool by MinionWare can meet your needs with almost effortless management. You are going to LOVE it.

If you simply can’t wait, check out the Minion CheckDB tutorials!

*(Giveaway offer is not open to previous ME winners.)

Database snapshots for everyone!

If you’re lucky enough to have SQL Server 2016, go on and upgrade to SP1….you get extra-lucky special database snapshots in any version! Oh what’s that? You don’t use snapshots? Well let’s see a couple of good use cases for them.

Database snapshots have been available in SQL Server Enterprise edition in the last several versions. But if you’re lucky enough to have 2016 at work, go on and upgrade to SP1….you get extra-lucky special database snapshots in any version!

(Be sure to read the footnote for “Database snapshots” in that link.)

What are database snapshots for?

Oh what’s that? You don’t use snapshots? Well let’s see a couple of good use cases for them:

  • Take a database snapshot before an upgrade, data load, or major change. It’s WAY faster than a backup, and you can roll back the changes if you need to, almost instantly.
  • Customize integrity checks. When you run DBCC CheckDB or DBCC CheckTable, behind the scenes SQL Server creates a snapshot of the database to run the operation against. You can also choose to create a custom snapshot…among other reasons, so you can specify where the snapshot files are placed. This is especially useful for shops running tight on disk space.

Speaking of integrity checks and snapshots, Minion CheckDB is slated to come out on  this coming February 1.  Be on the lookout…it’s going to blow your mind.

Sign up for your trial of Minion Enterprise today, and sign up for our newsletter for updates!

productimg_checkdb

Announcing Minion CheckDB release date!

Minion CheckDB is the third piece of our free backup and maintenance tools, rounding out the list with Minion Backup and Minion Reindex…and it’s coming in early 2017.

productimg_checkdbMinionWare will release Minion CheckDB on Febuary 1, 2017!

Minion CheckDB 1.0

Minion CheckDB is the third piece of our free backup and maintenance tools, rounding out the list with Minion Backup and Minion Reindex. CheckDB will have the same native interface, the same configurability, and the same rich scheduling introduced in Minion Backup. And of course, it will have a the same kind of visionary features that users have come to expect from MinionWare products, like:

  • Rich logging
  • Automated rotating schedules for objects
  • Automated remote CheckDB operations
  • Automated choice of whether databases get a DBCC CheckDB operation, or a series of DBCC CheckTable operations
  • And much more!

Minion Backup 1.3

What’s more, we will also release Minion Backup 1.3 on that date! New MB features include:

  • Our new dynamic naming functionality (called named parts)
  • Improved restore process
  • Additional advances both for their own sake and to support Minion CheckDB

 

Subscribe to the MinionWare newsletter for news and updates about Minion Enterprise, backup and maintenance, and more.

Share custom solutions in the MinionWare Community Zone

The Minion backup and maintenance modules are free, and completely open. So it’s really easy for our target audience (DBAs) to write their own queries, alerts, reports, and whatever else they could possibly need. And now, they can share those solutions online at the MinionWare Community Zone. We can’t wait to see what’s next!

Since we released Minion Reindex over a year and a half ago, we’ve had a ton of wonderful feedback, praise, questions, and best of all, custom made solutions to custom in-house problems.

minionware_logo

You see, Minion Reindex and Minion Backup are both free, and completely open. Nothing’s encrypted, and all data and configuration options are in tables. Minion Enterprise also stores configurations and collected data in tables (and, provides views and functions for easy access). So it’s really easy for our target audience – that is, database administrators – to write their own queries, alerts, reports, and whatever else they could possibly need.

And now, they can share those solutions online at the MinionWare Community Zone.

Continue reading “Share custom solutions in the MinionWare Community Zone”

Minion CheckDB Beta

In May 2016, we called for people to take part in the Minion CheckDB beta! This…was that call.

Come meet Codex!
minion checkDB
We’ve had many of you asking to be part of the Minion CheckDB beta and now is the time. We’re putting the finishing touches on the 1st beta and it’s looking great with some fabulous features.

So this is the open call for beta users. If you’d like to meet Codex before anyone else then send me an email.

Continue reading “Minion CheckDB Beta”