Pythian Group

Yesterday, I saw a Twitter post regarding the speaker evaluation results from SQL Rally 2011 in Orlando, FL last May. I was surprised to see that my session was in the top 3 best sessions of the conference. I dug up the Excel spreadsheet containing my session evaluation results and began to read. I found one comment very fascinating (the only evaluation where I got very low scores) as the response pertains to the speaker’s knowledge of the subject. The comment was: “copy and paste coder.” I’ve been doing this specific presentation for almost 5 years now with a few tweaks every once in a while based on feedback from attendees. Yes, I live and breathe disaster recovery as part of my day-to-day job. However, there are several reasons why I do not type nor write code during my presentations. Here are a few of them:

1. A presentation is a performance: Many will disagree with me on this, especially experts who believe that to demonstrate their expertise, they should be writing code and doing live demos during a presentation. Whenever I go up the stage to deliver a presentation, I always think about the attendee/audience. My goal is not to display my expertise nor to brag about what I can do that the audience could not. I always remember that my presentations are not about me, but about the audience. Which is why I do a lot of preparation prior to delivery – research, writing an appropriate storyline (you got it right – storyline), selecting the right demos, building test environments, writing demo scripts, rehearsing my presentation, etc. Yes, I rehearse my presentations and I say it out loud. I do the best that I can to make sure that the audience will be entertained, engaged, enlightened, educated and encouraged. If I’m doing a presentation on disaster recovery, I even plan out what type of disaster will I be simulating. Doing this will help me make sure that I don’t go beyond the time limit that was alloted for my session while covering all of the items that I intend to. I’d be very happy if the audience will walk out of my presentation with something that they will do when they get back to their regular routine. I keep in mind what Dr. Nick Morgan, one of America’s top communication theorist and coach, always say:”The only reason to give a speech is to change the world.” So, if you’ll be attending a presentation I’m delivering in the future, I’ll assure you that you won’t be disappointed.

Read the rest of this entry . . .

You were in your favourite bar one Saturday night when, suddenly, you hear your mobile phone ring. You pick up the phone and heard the sound of a screaming voice on the other end (no, it’s not your wife telling you to go home and take out the trash). The background noise is preventing you from understanding what is actually being said. You checked on the phone number that registered on the phone – it’s your manager. You get out of the bar to clearly hear what is being said until you barely hear the last phrase, “the production database is in recovering state for more than an hour now…” And, then, your battery went dead. Sound familiar?

In my previous blog post, I talked about the different acronyms that come with the term disaster recovery. In this blog post, I’ll talk about key items that we sometimes tend to ignore when creating a disaster recovery strategy – the lion, the “switch” and the wardrobe (I’ve been a fan of the Narnia movie series from which I got the idea). And, yes, I did get a phone call similar to that while I was driving with my family that I had to pull over and guide the other person on the line as they try to recover the database.
Read the rest of this entry . . .

In my previous blog post, I talked about high availablity and disaster recovery (HADR) and how it is more than just the underlying technology that keeps the entire strategy intact. In this blog post, I’ll describe a few acronyms – sometimes called buzzwords – that are commonly referred to in HADR projects and implementations (I know I use them a lot when addressing questions regarding HADR.) These acronyms fall under the second P in my PPT for HADR – PROCESS. Every HADR project or implementation should first be able to define these acronyms well before they even purchase the hardware, software and technologies they intend to use. Let’s get going.
Read the rest of this entry . . .

While I was at the PASS Summit 2010, I’ve spent a fair amount of time at the Ask-the-Experts table on high availability, disaster recovery and virtualization. Conference attendees with different requirements on high availability and disaster recovery come to these tables and ask questions.

I’ve spent a fair amount of time doing high availability and disaster recovery (HADR) in my previous life as a data center engineer focusing on the Microsoft platform. My previous organization sold high availability and disaster recovery solutions to customers like crazy, highlighting the fact that the solutions are more than just the technology aspect. Every time I talk about HADR in my presentations, I focus on the three main ingredients to have a successful implementation – people, process and technology (PPT). Note that technology is at the end of the list as the people and the process components should come first.

What I heard at the PASS Summit gave me insights as to how people approach HADR (and I thought I only saw these on the newsgroups and forums as I answer their questions.) Most SQL Server DBAs (and maybe even a lot of IT professionals) want a technical answer to their HADR problem. They want to know if failover clustering, database mirroring, replication or log shipping is the best solution to their requirement. What’s funny is that when I ask them about what their RPO/RTO/SLAs are, they scratch their head and ask what those acronyms are. And when I start explaining these acronyms to them, they still want to hear what the best solution is for their requirement.

As I prepare for my presentation on Disaster Recovery Techniques for SQL Saturday #61 in Washington DC, I’ll be writing a series of articles about disaster recovery and what RPO/RTO/SLAs are and how they fit into the whole disaster recovery strategies. Before I dive into the “technology” part of the PPT ingredient for a successful HADR implementation, I will talk about the people and the process part first. Why? Because these two will drive the technology part of the whole strategy. And if you’re in the Washington DC area, feel free to drop by at the SQL Saturday event.

I’m here at the PASS Community Summit 2010 in Seattle, WA. This happens to be the largest SQL Server conference in the world with regards to content, attendees and Microsoft participation. With the conference center very close to the Microsoft Redmond campus, Microsoft can afford to send as much as they can from the SQL Server team – from the development team, CSS team, SQLCAT as well as from their business platform group. There have been several announcements made in today’s keynote, few of which were just waiting to be blogged about from the insiders since earlier this year. First of which is the release of SQL Server 2008 R2 Parallel Data Warehouse. Formerly codenamed Project Madison, this was used to be DATAllegro, Inc. – a provider of breakthrough data warehouse applicances – before Microsoft bought them over back in 2008. SQL Server 2008 R2 Parallel Data Warehouse will be readily available in the market so that customers can take advantage of having a data warehouse appliance that runs the very familiar Microsoft SQL Server product.
Read the rest of this entry . . .

A few weeks ago I did a demonstration on Installing a SQL Server 2008 R2 Failover Cluster on Windows Server 2008 R2 at TechInsights 2010 in Kuala Lumpur, Malaysia and have had questions about what needs to be done as part of the installation. While I’ve done several of these demonstrations in as short as 45 minutes to an hour, creating a SQL Server Failover Cluster is not something that you do in that timeframe. Planning the server infrastructure, disk allocations, network configuration and bunch of other technologies that relate to Windows Clustering need to be considered.
Read the rest of this entry . . .

Installing a 32-bit version of SQL Server 2005 Reporting Services on a Windows Server 2003 64-bit could be a bit of a challenge, as it requires IIS. I have seen several customers who purchased servers with Windows Server 2003 64-bit pre-loaded while they only have a license for a 32-bit SQL Server 2005.

It is always recommended to have a 64-bit application running on a 64-bit OS to take full advantage of the 64-bit platform. IIS, by default, runs 64-bit on a 64-bit Windows Server system. SQL Server Reporting Services requires ASP.NET which can be manually installed on top of IIS.

When you install the .NET Framework on a 64-bit machine, you have both the 32- and 64-bit versions. Nonetheless, you will not be able to install ASP.NET 32-bit version on a 64-bit IIS, which will be needed by SQL Server Reporting Services.

To be able to install ASP.NET 32-bit on a 64-bit IIS, Read the rest of this entry . . .

Most people think Windows administrators make a living with their right-hand—you know, right-clicking and left-clicking the user interface to get things done. While anybody can do that in Windows, the real value comes in when you no longer need to rely so much on the user interface but instead write scripts. Lower total cost of ownership is achieved when the administrative costs are kept low, and this is where Windows PowerShell comes in.

I’ve spent a fair amount of time writing VBScript scripts to administer Windows servers and workstations and automating repetitive tasks. One reason for me moving into Windows PowerShell is its roots in the Microsoft .NET Framework, as I have done a fair amount of .NET programming. But what is Windows PowerShell anyway?

Windows PowerShell is an extensible command-line shell and an associated scripting language built on top of the .NET Framework v2.0. It was released in 2006 and is currently available for Windows XP SP2/SP3, Windows Server 2003, Windows Vista, and is included in Windows Server 2008.

PowerShell will be included as a common engineering criteria (CEC) in future releases of Microsoft server products, making it a must-learn for Microsoft server administrators.

Administrators (DBAs included) have been using scripting to automate administrative tasks with scripting languages like DOS batch, VBScript, Perl, and a few third-party tools like KiXtart and WinScript. Windows PowerShell complements the administrators’ existing scripting toolkit to easily manage and administer Windows workstations and servers and other Microsoft server products as THEY are being built using the .NET Framework.

Although it is designed for operating systems, Windows PowerShell can be used to administer SQL Server 2005 instances and higher, as Server Management Objects—the object model used to manage SQL Server 2005—are built using the .NET Framework, thus exposing the object model in PowerShell. And since SMO is compatible with SQL Server 2000, you can administer SQL Server 2000 instances using Windows PowerShell. SQL Server 2008 even ships with its own PowerShell snap-in.

No wonder it makes sense to learn a thing or two about Windows PowerShell. Besides, I’ve seen Windows administrators being “forced” to do SQL Server DBA tasks even without knowing what T-SQL is. Windows PowerShell makes it a level playing field.

I will be posting a series of blog posts on getting started with Windows PowerShell, and how any Windows administrator can use it for their day-to-day tasks. In the process, I’ll also cover how to use Windows PowerShell for administering SQL Server instances.

In Part 1 of this series, we prepared our Windows Server 2008 servers to be a part of a cluster. Part 2 showed us how we can add the shared disks, install the Failover Cluster Feature, and run the Validate Cluster Configuration Wizard. In this post, we will complete the process by creating a Windows Server 2008 cluster.

Creating the Windows Server 2008 cluster

Once you have managed to install the Failover Cluster Feature on both nodes, you can run the Failover Cluster Management console on either of the nodes. To do so:

Read the rest of this entry . . .

In Part 1 of this series, we prepared our Windows Server 2008 servers to be a part of a cluster. In this part, we will look at adding the iSCSI disks to the servers. The series of steps outlined below should be done on both nodes.

Before we go any further, I must mention that you should have at least two network cards configured on both of the servers, where one NIC is connected to the local area network, and the other to the other server and is private. This second NIC will be considered your heartbeat, where communication between nodes will travel. This is basic when configuring any cluster nodes. How these cards are configured will come into the picture as we go along in the process.

1. Add the iSCSI Targets as disks on the server nodes

Windows Server 2008 comes with iSCSI Initiator software that enables connection of a Windows host to an external iSCSI storage array using network adapters. This differs from previous versions of Microsoft Windows where you need to download and install this software prior to connecting to an iSCSI storage. You can launch the tool from Administrative Tools and select iSCSI Initiator.

To connect to the iSCSI target: Read the rest of this entry . . .