Why People and Processes Matter More Than Technology

Edwin M Sarmiento — Thu, 06 Aug 2015 00:20:53 +0000

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.

Your poor man’s SQL Server log shipping-PowerShell version

Edwin M Sarmiento — Sat, 01 May 2010 14:18:00 +0000

In 2008, I was privileged to be a part of a project to write a chapter for a book that was for a good cause. SQL Server MVP Deep Dives became an avenue for a lot of the SQL Server MVPs to share their expertise for the benefit of not just the technical community but of the beneficiary.

I wrote a chapter for the book based on this blog post some three years ago and one of the recommendations I did was to convert the VBScript scripts to Windows PowerShell. So, here it is.

I’ve converted the VBScript that does the checking of the folders containing my latest LOG backups and restoring them in NORECOVERY mode to Windows PowerShell. What is fascinating is the fact that if the process I’ve outlined in the blog post is followed thru, adding another database to be configured for log shipping was as easy as creating regular LOG backups via TSQL scripts or database maintenance plans – no need to add an entry for every database that will be configured. How cool was that?

So, here’s the Windows PowerShell version of the custom restore LOG backup command

$logBackupFolder="your LOG backup location here or a parameter variable"


##Variable for time duration - the amount of time you need to generate and restore LOG backups

$1HourOld = [DateTime]::Now.AddHours(-1)
##Retrieve folders and files in the specified directory

foreach ($databaseName in (Get-ChildItem $logBackupFolder | Where { $_.PsIsContainer }) )

{

foreach ($logName in (Get-ChildItem $logBackupFolder$databasename | where {($_.CreationTime -ge $1HourOld) -and ($_.Extension -eq ".trn")} SELECT name))

{
$logBackupPath = [System.String]::Concat("'$logBackupFolder",$databasename,"",$logName.Name,"'")

$restoreSQL = "RESTORE LOG $databaseName FROM DISK=$logBackupPath WITH NORECOVERY" | Out-File D:$databaseName.sql
Invoke-Expression "osql.exe -SYourSQLServerInstanceHere -E -iD:$databaseName.sql"

} }

You might be wondering why I am using osql.exe instead of sqlcmd.exe. Well, it’s still there even if you have SQL Server 2008. Which means this script will work even for SQL Server 2000 instances as long as you install Windows PowerShell on the machine running SQL Server.

And all of that for a mere 17-liner script. I could write it even less than that but I’m a big fan of script readability. Now, that’s a good enough reason to dig deeper on what Windows PowerShell has to offer

Edwin M Sarmientolog shipping – Edwin M Sarmiento

Why People and Processes Matter More Than Technology

Your poor man’s SQL Server log shipping-PowerShell version