Almost 8 years ago, I wrote a blog post about what I call the poor man’s SQL Server log shipping. In it, I outlined the process of how log shipping works. This became the basis of the chapter I wrote for the SQL Server MVP Deep Dives Volume 1 book. What’s interesting is that while I wrote the content with SQL Server 2000 in mind, the concepts and the principles behind the process still apply up to SQL Server 2014. I recently had a customer who wanted to move their existing database server from SQL Server 2000 to SQL Server 2008 R2 with minimal downtime. The only option was to implement log shipping because of the size of the database. However, there are a few restrictions.

• We can’t change the SQL Server service account on the current production environment because it will require a service restart
• Log shipping between SQL Server 2000 and SQL Server 2008 R2 is not supported out-of-the-box. We do not have the appropriate wizards and stored procedures  that we can use to configure log shipping between these two versions

Given the restrictions, it’s easy to just give up on the option to use log shipping. But isn’t log shipping just an automated backup-copy-restore process? As long as the source can run log backups and the destination can copy and restore those generated backups without breaking the log sequence, I don’t see any reason why it can’t be done. But every once in a while, I get asked about my approach and how it could possibly work.

• This can’t be a disaster recovery solution. I didn’t say it is. In fact, it’s a one-way traffic because the database schema between the two versions are different. Once you failover to the higher version, there is no turning back. This approach is ideal for doing version upgrades on different hardware while minimizing downtime. If you are dealing with the same version of SQL Server, I don’t see any reason why you would use this approach because the wizards and the stored procedures are available for you to use.
• I don’t have a domain account. I used to think that I needed a domain account to implement log shipping. It is recommended as a best practice but not necessary. This means that two SQL Server instances can be on a workgroup and still be configured for log shipping. How?
  • Configure the SQL Server service account (database engine and agent) to use a local Windows account.
  • Create the same local Windows account (with the same password and permissions) on the machines participating as standby servers for a log shipping configuration.
  • Use the same account for the SQL Server service account on all machines.
• We don’t have a DBA. That’s where I come in. 🙂

My point is that the reason why I was able to recommend this solution to customers is because I understand the principles and concepts involved in the process. It’s easy to focus our attention on technology solutions instead of the processes and people involved to get the job done. And this is the reason I coined the PPT methodology – people, process and technology. I’ve used this methodology a lot in high availability and disaster recovery projects but it pretty much applies to just about any aspect in life – finding a job, planning a vacation, etc. Technology is just there to complement what we – the people – can accomplish by defining the processes that we need to follow to accomplish a goal. Besides, we need to stop looking at constraints as a limitation but rather as an opportunity for creativity.