Restore testing, restore performance, rollback, and recovery procedures.
25 associated posts24 primary posts
Let's say you're a DBA managing a 2TB database. You use SQL Server transaction log shipping to keep a standby copy of the database nice and warm in case of emergency. Lots of data can change in your log shipping primary database: sometimes it's index maintenance, sometimes it's a code release, sometimes it's just natural data processing.
I recently posed the question, “Who’s taking your backups?” This is of utmost importance, because your business’s data is the business. Protecting it and backing it up need to be priorities for DBAs.
Now, for my next question: who is responsible for restoring those backups?
This question came up when working with a client last week. The team mentioned they were planning to move some tables into a new filegroup. The new filegroup is intended to help quickly restore data in cases when a monthly process goes off the rails and leaves the data in some tables in a bad state.
Managing data is about managing risk, but no matter how we good we are at managing risks, they're still risks.
We've seen several high-profile data failures recently:
Every day, your servers do hundreds or thousands of operations that are all resource-intensive. You want these operations to finish as quickly as possible, because they're absolutely mission critical, and you'll lose your job if they're not done successfully. Whole companies have been lost when these operations fail. Yet do you really know how to make these operations happen faster?
