I love patching clustered servers (not!), and patching polyserve is usually quite simple and not an issue.   I'm not referring to Polyserve patches, but Operating System (microsoft, hba, other drivers etc) patches.

We normally have designed a special "rolling" sequential patch of 15 minute intervals for the clustered servers, trying to give each server enough time to recover before the next one rolls.

Something happenned with that sequence, and things rolled like a ping-pong !  Polyserve stabilized, but there was an issue with two instances.  Review of the issue determined that the mount points that these instances rely on, did not happen, meaning the mounts failed.

I attempted to remount the volumes and received the following error, "10.10.49.114 assign_drive_letter failed: "D:\Mounts\SysData\" is already a reparse point.". 

I'm not really sure why this happenned, meaning windows, polyserve, san related root cause.  I attempted to reboot the nodes that these failed on and recieved the same error, hey a reboot fixes everything under windoze, right ?

I found the only way to correct this was to find the folder where these "reparse points" (junction point or mount point) stem from and to completely delete that folder.  So in the above example I had to delete the folder eamload_data1 under eam (remember to do this on each node that has a problem).  I then assigned the mount point as normal, and all the instances worked fine.

I've seen sporadic issues with mount points in the past, polyserve and non-polyserve.  See a previous point here on how to remove a ghosted mount point...

http://www.lifeasbob.com/2008/03/25/ManuallyRemoveAMountPoint.aspx 

It'll be interesting to see if this happens again or was a "one time" deal.

Assigning SQL Server a static port number is necessary for many reasons, cluster, firewalls, security through obsecurity etc.  We use Polyserve and often have to assign port numbers, we've never really had a good guide to follow on this, even the Polyserve documentation doesn't really have a white paper or a short paragraph on a port numbering strategy.  After several years now of running static ports, one is definetly needed.  Before you can create a strategy for your Polyserve environment or SQL Server, the below except is a great generic explanation about port numbering and uses.

This is from December 1999, but is just as relevant today.  Source = http://www.microsoft.com/technet/archive/community/columns/inside/techan23.mspx?mfr=true 

Summer is still in full swing, but we've had a day or two of nice weather.  A quick check of the brewing calendar shows it's time to get those Heavy winter brews started.

I'm working on two of my favorites this weekend: 

• Hard Red Winter Wheat
• Bus Oil

Hard Red Winter Wheat is a Belgian Abbey, styled after a trip through Kansas City's Board of Trade.  On the monitor were futures for Hard Red Winter Wheat, hence I designed this beer around that name. 

Bus Oil is a Strong Porter, finished with Vanilla Bean for a very subtle, silky smooth black brew.

Both of these are very strong, perfect for winter and both require a good 2-3 months to reach peak, so "get your winter brew on", now...

Finally got around to tasting the Heather Ale, it's a fine line between Braggot and Ale, but after tasting this, it is definetly an Ale.

The beer is definetly unique.  It pours nicely, quickly developing a very thick creamy head.  First impression is the nose, wow, the combination of Heather and some of the "bee items" (propolis and pollen) creates a cross of freshly crushed pine needles.

The beer takes a bit too drink, it is not a light beer and has some attitude.  One or two bottles of this and things can look right with the world.  I'm quite pleased with the balance and flavors of the beer, which is always a challenge with "big" alcohol heavy beers.  Definetly the dominating profile is the nose from the heather and "bee items".

I want to brew this again, but will definetly cut back on the Bee Pollen and Propolis to 1 or 2 ounces from 8.  Also the Heather Honey from Scotland costs a fortune ($80 for 1/2 gallon), so I'm going to have to find a reasonable subsititute.  Though in my mind the comination of the Heather Honey and Heather tips is what makes this "Heather Ale".  I may try a substitute and compare them.  I currently have a 1/2 gallon of Meadow Foam Honey, which is also some expensive and rare stuff, wonder how it will brew up...Link to original post on creating Heather Ale.

The beer has only been aged 6 months in the bottle (feb 08), having been brewed in Nov 07.  These honey based ales (braggot), take several months to brew and can easily improve with age. 

It'll be interesting to taste over the next year.

Recently we upgraded the Proliant Support Pack (PSP) to higher version (8.10.0.0), and then we began to recieve the following error from the HP Network configuration Utility:

Working with SSIS, a stored procedure was recently changed from a simple select statement to include some more procedural statements that utilized temporary tables.  Surprisingly the SSIS package stopped working, even though the result set from the stored procedure remained the same.  One of the reasons to use the stored procedure in ssis, was to avoid embedding the login in the SSIS packages related to data access, what gives ?

Error is:

Do you want the component to fix these errors automatically?

I've seen several solutions to this problem using "set fmtonly off" in the SSIS call and "set nocount on" in the stored procedure.  While "set nocount on" is usually recommended, i'm not too pleased with the "set fmtonly off" solution, as I've read issues where this may or may not work and cause performance issues.

There seem to be several different ways to fix this, each of them slightly different, my preference is option 3. 

1.  Put "set nocount on" in the stored procedure, put "set fmtonly off" before the execution of the procedure [in the ssis call]. 

2.  re-write the stored procedure to use table variables instead of temporary tables, a good solution as well.

3.  Add some meta-data and the "set nocount on" to the stored procedure with a "short circuited if clause" (if 1=0), and a bogus select statement at the top.  I've tested with trying to leave the "set nocount on" out and it did not work.

Verify your block size, the default in windows is 4096.

The debate always is what is the optimal block size, I prefer a block size of 64K for NTFS Volumes.

You need to fsinfo to verify this, you can see below this d drive is at 4096, the default, Microsoft recommends a block size of 8K or greater, for volumes hosting sql server databases (the os is fine at 4096).  Block Sizes smaller than 8K may lead to data corruption.

fsutil fsinfo ntfsinfo f

c:\>fsutil fsinfo ntfsinfo d:
NTFS Volume Serial Number :       0x60f2135af213342e
Version :                         3.1
Number Sectors :                  0x000000000237efff
Total Clusters :                  0x000000000046fdff
Free Clusters  :                  0x000000000046bcfa
Total Reserved :                  0x0000000000000000
Bytes Per Sector  :               512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x0000000000008000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0x0000000000237eff
Mft Zone Start :                  0x00000000000c0000
Mft Zone End   :                  0x000000000014dfc0