none
Biztalk and SQL Server Hotel RRS feed

  • Question

  • How is it with Biztalk 2013 and SQL Server Hotels versus dedicated SQL server?

    Current setup is two vritualized 2008 R2 servers with Biztalk 2013 Std and SQL Server 2012 Std
    We are discussing whether Biztalk will perform just as well or better if the SQL server were moved to an instance large non-virtual SQL server installation 

    Would a dedicated instance behave similar or better as a dedicated server and is a setup like even official supported?
    I'd say keep existing two setup, but?

    Pro/Cons?

    Thanks in advance  /Peter

    Wednesday, May 6, 2015 11:33 AM

Answers

  • Few important points:

    • The MessageBox Database requires it's own dedicated SQL Server instance but that can be shared with other BizTalk Databases.  This is primarily due to the MaxDegreeOfParallelism setting.
    • Named instances of SQL Server are fully supported.  Other named instances on the same Windows instances are largely irrelevant.
    • The performance evaluation would be the same with BizTalk as for any other application.  Basically, can the shared SQL environment provide the same resources as the dedicated setup.  There is nothing BizTalk specific here.
    • My position is that the BizTalk SQL Server and Databases are, or should be, owned by the BizTalk side admin wise, meaning not 'controlled' by the DBA's. This might be difficult with a shared setup.
    Wednesday, May 6, 2015 2:34 PM
    Moderator
  • As long as you're looking at providing distinct instances for BizTalk SQL databases [John has listed the BizTalk requirements w.r.t degree of parallelism, etc.] and your infra (hotel) is a n + l clustered setup. You should look at distinct instance for SSO, Management + Rules, Message Box, DTA, Applications. You might not want BAM on that hotel and may have a separate environment with Analysis Services.

    If the infra is planned properly, you would definitely benefit from lower SQL core licensing, SAN (you'd necessarily have to use mapped LUNS for DB and Log instances to save on Drive letters across the hotel) and now with per instance MSDTC you are likely to get better performance over a virtual instance.

    Regards.

    Wednesday, May 6, 2015 6:05 PM

All replies

  • SQL Server Hotel?  I've not heard that term before.
    Wednesday, May 6, 2015 12:11 PM
    Moderator
  • SQL server with multiple instances for different purposes
    Wednesday, May 6, 2015 12:21 PM
  • Few important points:

    • The MessageBox Database requires it's own dedicated SQL Server instance but that can be shared with other BizTalk Databases.  This is primarily due to the MaxDegreeOfParallelism setting.
    • Named instances of SQL Server are fully supported.  Other named instances on the same Windows instances are largely irrelevant.
    • The performance evaluation would be the same with BizTalk as for any other application.  Basically, can the shared SQL environment provide the same resources as the dedicated setup.  There is nothing BizTalk specific here.
    • My position is that the BizTalk SQL Server and Databases are, or should be, owned by the BizTalk side admin wise, meaning not 'controlled' by the DBA's. This might be difficult with a shared setup.
    Wednesday, May 6, 2015 2:34 PM
    Moderator
  • As long as you're looking at providing distinct instances for BizTalk SQL databases [John has listed the BizTalk requirements w.r.t degree of parallelism, etc.] and your infra (hotel) is a n + l clustered setup. You should look at distinct instance for SSO, Management + Rules, Message Box, DTA, Applications. You might not want BAM on that hotel and may have a separate environment with Analysis Services.

    If the infra is planned properly, you would definitely benefit from lower SQL core licensing, SAN (you'd necessarily have to use mapped LUNS for DB and Log instances to save on Drive letters across the hotel) and now with per instance MSDTC you are likely to get better performance over a virtual instance.

    Regards.

    Wednesday, May 6, 2015 6:05 PM
  • Thanks, the dbo issue won't be a problem ;-)
    Thursday, May 7, 2015 8:53 AM