A Helpful SQL Server DBA Checklist

Update: As Omer points out in the comments to this entry, the recommendations made in the DBA Checklist mentioned below are in places at odds with the official BizTalk/SQL Server best practices. When reviewing the checklist, please refer to the Microsoft BizTalk SQL Server Best Practices KB article.

SimpleTalk has a helpful DBA checklist for all those BizTalkers who double-hat and manage a SQL Server as-well-as a BizTalk environment. It covers a number of useful topics, including:

  • General best practices
  • High-availability
  • Performance tuning
  • Application coding and design
  • SSIS, Analysis Services, Reporting Services & Service Broker

Plenty of content for both new and experienced DBA’s – well worth a look.

Enhanced by Zemanta

Next UK SOA/BPM User Group Meeting – 14th October 2008 London

The next UK SOA/BPM User Group Meeting has been announced which will be taking place on Tuesday, 14th October 2008 at Microsoft’s London office.

The meeting will include an introduction to BizTalk 2006 R3 2009, a presentation by ISV Frends Technology on integration solutions, plus developer and architecture sessions; there will also be beer and pizza. Full details can be found at the UK SOA and BPM User Group website.

I look forward to meeting you there!

VeriSign: 48 Billion DNS Queries A Day

Completely off topic for this blog, but interesting nonetheless: Verisign yesterday reported that they processed more that 48 billion DNS queries per day in the second quarter of 2008. Wow.

VeriSign also maintained 100 percent uptime for the DNS system during the second quarter, as it has for the past decade. I think this must be one of only a handful of cases in the industry, given how elusive even 99.999% uptime is.

More info over at Data Centre Knowledge.

Enhanced by Zemanta

BizTalk Assembly Redirection

Over on the BizTalk Gurus Forums, Richard Wallace asked for opinions on best practice for central business logic that would span over a number of BizTalk applications. One of his suggestions was to use .Net assemblies that contained this business logic, however he was concerned about the re-build / re-deploy tax that this would introduce into his BizTalk projects if he needed to change his business logic assemblies.

In my reply I suggested that he looked at assembly redirection, which allows developers to redirect one version of an assembly to another, through changes to an executable’s .config file – in our case, btsntsvc.exe.config. Having never done this in anger in BizTalk, I though this would be a good opportunity for a blog post – here are my findings.

Configuration Changes

To enable assembly redirection, the following lines need to be added to the runtime/assemblyBinding element in the .config file

   1:  <runtime>
   2:      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
   3:          <dependentAssembly>
   4:              <assemblyIdentity name="BizTalkAssemblyRedirectionHelper" publicKeyToken="5cce5ee5c1d7dc25" culture="neutral" />
   5:              <bindingRedirect oldVersion="" newVersion="" />
   6:          </dependentAssembly>
   7:      </assemblyBinding>
   8:  </runtime>

On line 4, we identify the assembly we wish to redirect; on line 5 we identify the new version. If we had wanted, we could specify a range of ‘old’ assemblies that are to be redirected, as follows:

   1:  <bindingRedirect oldVersion="" newVersion=""/>

Restart the Host Instance/s for the redirect to take effect. If the new version of the assembly cannot be found in the GAC, you will only see an error when the CLR attempts to load the assembly at runtime, not when the Host Instance restarts, the error is a usual favourite:

Error details: Object reference not set to an instance of an object.

Testing Redirection: Orchestrations & Maps

To test the redirection, I created an orchestration and map that invoked simple helper classes contained within a separate assembly. The helper classes expose a single method which takes two strings as input parameters and returns a concatenation of the these two parameters – an example of the version 2.0 code can be seen below. Versions and were deployed to the GAC.

   1:  using System;
   2:  using System.Diagnostics;
   4:  namespace BizTalkAssemblyRedirectionHelper
   5:  {
   6:      [Serializable]
   7:      public static class RedirectionHelper
   8:      {
   9:          public static string ConcatHelper(string a, string b)
  10:          {
  11:              Trace.WriteLine("RedirectionHelper - Orchestration, version");
  12:              return (a + b);
  13:          }
  14:      }
  16:      public class RedirectionMapHelper
  17:      {
  18:          public string ConcatMapHelper(string a, string b)
  19:          {
  20:              Trace.WriteLine("RedirectionHelper - Map, version");
  21:              return (a + b);
  22:          }
  23:      }
  24:  }

Four messages were submitted into BizTalk; in-between the second and third messages, the assembly redirection code was enabled to point to version 2 of the assembly and the Host Instance restarted. The results of the test can be seen in the DebugView screenshot below – once the redirection config change is applied, both the Map and Orchestration start to use the version 2 of the assembly:

Assembly Redirection - DebugView Output


A few conclusions can be drawn from this test:

  • Assembly redirection can be used within BizTalk for helper classes in both Orchestrations and Maps (on ports & in orchestrations). There are other cases I can think of, such as pipeline components, for example.
  • The signatures of these helper methods must remain the same between releases.
  • There is a possible issue with build and revision numbers as highlighted by Richard Hallgren in BizTalk assembly version redirection.
Enhanced by Zemanta