Archive | February, 2015

Mentoring – risk and reward

8 Feb

So, Paul Randall is offering to mentor six people for a couple of months, in response to the feedback from the Tribal Awards last year.

Now that’s a double-edged sword, isn’t it?

First of all, the opportunity to seek guidance and assistance from one of the most knowledgeable people in the SQL Server community, for free, is not to be sniffed at.

But just imagine the fun to be had in job interviews forever afterwards:

“So, you trained with Paul Randall?”, I know its mentoring, but people will see what they want to, “Well, we have a 200 server system with 20 Tb databases in 30 countries. Clustering is a bit flaky and the Merge Replication between our 7 Russian sites and Australia keeps failing – how would you fix that?”.  People can set higher expectations when they see certain names in connection with you.

And of course, there’s always the thought of failing to meet Paul’s expectations too. After all, this is his own time he’s sacrificing – squeezing in between his day job and the inordinate amount of reading he appears to do to.  Years from now whenever he’s asked – “Oh yeah, Steve – nice enough guy but I wouldn’t want him anywhere near my systems.” – the career version of the Black Spot. The rest of my career on NoSQL databases.

And what do I actually need anyway? With the all-seeing eye that is Google and a company-paid subscription to SafariBooksOnline, it certainly isn’t reading material. And although it pains me to say so, I do work with several people who really know their SQL Server, so the day-to-day stuff should be catered for. And no, I’m not giving names – they’d be insufferable.

And that’s the problem – day-to-day stuff.  Training beyond what I need for my current job. Methodology. The ‘what’ and the ‘how’.

I have so many draft articles in my blog – slowly composting because I’m not sure how to approach them or even if they’re of enough interest to myself really to actually complete.

I paid my own way to SQL Pass a couple of years ago and I’ve paid for this year too, as well attending a SQLBits conference a few years ago. This is currently how I find out what others do, outside of my little bubble of experience.

I’ve changed direction several times within my long career in IT and it’s usually because somebody who is very experienced in their field and can teach it has shown me into their little world. Not necessarily taught me the syntax and the tool usage, but shown me how to think in a way that takes advantage of whatever language/tool they use. A couple of months of being shown that can make changes that last years.

So I’m willing to put my name forward for this, in my own style. Who knows, we may both learn something. Even if not selected it made me think about what I really want out of this new direction my career has taken. And if I get nothing more from this, I can at least thank the man who introduced me to the Wool trilogy via his twitter messages.

Generating Replication Scripts – Things To Watch Out For

5 Feb

Scripting a Publication is useful for both Disaster Recovery and copying a Publication to a test environment. If you use the Wizard each time then you have to make sure that you’re consistent with the options and choices made in Live and once again on the Test (or DR) server.  By creating the script you should get something that reproduces the Publication and Subscription in full.

However, generating the script doesn’t always give you an exact copy of what you are scripting from. Some defaults might be included that weren’t used originally and some settings may be specified that were simply not used with the original creation.

A couple of examples I can demonstrate using the Publication scripted in earlier articles (http://wp.me/p3Vxvi-3l), a more entertaining example using partition switching will have to be described.

Example 1 – There wasn’t a Publication Snapshot in the Original

But if you ask SSMS to generate a Create Script for the Publication it will include one:

To generate the scripts from an existing Publication you need to right-click on the Publication name within Replication/Local Publications branch (on the Publisher):

Art01

Specify where you want the script to go and it will be generated.

In this option I’ve chosen to have the script sent straight to a New Query Window.

Now bear in mind that this Publication does not use a Snapshot. I never specified it when I originally scripted this publication.

So what is this here for?

Art02

If I’m going to use this script as a true copy of the original then I need to remove this entry.

Example 2 – The ‘sync_type’ has been set incorrectly

From the Subscriber, generate the Create Script just as with the Publisher, to a New Query Window.

This time the comments within the script do have the good grace to warn you that a default has been use that you might not want:

Art03

 

In this case I need that to be set to ‘none’.

As an aside, in SQL Server 2000 this setting was also case-sensitive – ‘none’ wouldn’t work as expected, but ‘None’ would.

Example 3 – Partition Switching fails with Replication

I have no test example to hand with which to demonstrate this (at least, not one that I can show outside of my employer’s environment) but it is simple enough to describe, now that I know the cause and resolution.

Several databases in use at my current workplace specify different partition schemes between the Publisher and the Subscriber. This is a common practice, particularly where the Subscriber might be a ‘staging’ database used to ultimately transfer data elsewhere.  So the Publisher might keep data for a couple of weeks but the Subscriber only needs to store it for a day or two, because another system is being used to store/consume that data for other purposes (reporting, analysis or whatever).

So, in my innocence I script the Publication and Subscription via SSMS, make the alterations shown in the previous two examples and create the Publication on a test environment. All is good and Replication works fine. Data that I insert into the Publisher appears in the Subscriber and I have that warm, smug feeling of having created a Publication without incident. Something to be savoured.

However, part of creating this test environment also includes setting up the jobs that purge the data in both Publisher and Subscriber, with the use of Partition Switching (for a basic example of Partition Switching, have a look at http://wp.me/p3Vxvi-3l ).

When the job runs against the Publisher that executes Partition Switching I get the following error:

“The table ‘<schema>.<tablename>’ belongs to a publication which does not allow switching of partitions [SQLSTATE 42000] (Error 21867)”.

Just for a laugh, if you want to see just how many errors Replication can produce, go to https://technet.microsoft.com/en-us/library/cc645609(v=sql.105).aspx (and to add to the fun, they aren’t logged).

After much digging around and asking others who have more Replication scars than myself it transpires that some settings aren’t scripted out and also aren’t found by any of the guid screens associated with Replication.

In the past I have right-clicked on the Publication name, selected ‘Properties’ and looked at ‘Subscription Options’, believing that comparing these between the original and the copy would be enough.  Ah, well.

There is a Replication command ‘sp_helppublication’ which shows several setting that are not visible elsewhere. At its most basic, running this command with just the Publication name will produce a row with all of the setting associated with that Publication:

Art04

 

With the particular Publication in mind I scrolled along to the far right, and the setting for ‘allow_partition_switch’ was set to 0. As BOL specifies for this parameter – “Specifies whether ALTER TABLE…SWITCH statements can be executed against the published database”.

Executing ‘sp_helppublication’ against the Live Publication shows this value as ‘1’ – so it is permitted in Live but wasn’t scripted anywhere by the automatic process through SSMS.

To change this to the value required requires the command ‘sp_changePublication’, executed against the Publisher DB in question:

EXEC sp_changepublication @publication=N'Publication Name;', @property=N'allow_partition_switch', @value = 'true';

However, that isn’t the end of it. In executing this command it also sets ‘replicate_partition_switch’ to ‘1’, which I don’t want. The publisher and Subscriber in our environments generally have different Partition Switching schemes, so just because the Publisher decides to purge any data doesn’t mean that the Subscriber does too. So I now need to unset that parameter:

--it also sets 'replicate_partition_switch' to 'true' when the previous command executes and we want that as --'false'
EXEC sp_changepublication @publication=N'Publication Name', @property=N'replicate_partition_switch', @value = 'false';

Having jumped through these hoops I now find that Partition Switching works fine and my Publication in Test really is a copy of the Publication in Live.