In a previous blog post, I walked you thru how I built my portable Hyper-V lab using Gigabyte’s GB-BXi5-4570R mini barebone PC. I even had a chance to test it out immediately after getting it all configured. I brought the kit with me to Microsoft’s Big Data Hackathon event in Toronto. And, boy, I surely don’t miss the heavy backpack. Even with my MacBook Pro, a portable router, power adapters and extension chords, my pack it’s still way lighter than when I carried the Dell Latitude E6520.
As an IT professional, it is important to have a lab environment to play around with – whether you’re a developer writing code or a systems administrator building servers – to test ideas and concepts prior to doing it for reals. Time and time again, I’ve heard folks say how expensive it is to build a lab environment. That used to be the case but not anymore. With cloud providers and virtualization options, there is really no excuse to not build a personal lab environment that is both affordable and economical.
A few days ago, one of my customers reached out to me on Yahoo Messenger (yes, it still exists) and asked how to identify what the potential data loss is when DBCC CHECKDB reports corruption of a SQL Server database. My common response is the usual “it depends” in that there are cases when DBCC CHECKDB may recommend using the option REPAIR_ALLOW_DATA_LOSS. And while you may be fine with doing so, it may not be supported. An example of this is a SharePoint database where Microsoft KB 841057 specifically mentions that using this option renders the database in an unsupported configuration. But say you have decided to proceed, how do you know what data potentially gets lost? This blog post walks you thru the process of identifying potential data loss when DBCC CHECKDB reports corruption in your SQL Server database.
This video is a compilation of different database recovery techniques that SQL Server DBAs should be familiar and comfortable with. We will look at recovering a database to a specific point in time, isolating critical objects or using table partitioning as an HA/DR option (more commonly called online piecemeal restore) and performing page-level restores.
I started doing some serious database disaster recovery stuff in 2006 while working for Fujitsu Asia. As the only hard core SQL Server guy in a team of Wintel engineers, the buck stops with me when it comes to anything related to SQL Server. And since our main offerings all revolve around high availability and disaster recovery, I have to be very familiar and well versed with all possible recovery techniques that are available to the version of SQL Server that we are running. On top of that, I need to make sure that all our backup strategies meet a specific application platform’s recovery objectives and service level agreements.