• It doesn't allow you to install same version of LocalDB multiple times on the same machine which means you save lot of space/memory.
• Also, it switches off when you don't use it. So saves resources as well.
• It reduces management as you don't have many instances.

So how to go about it? Simple, just select LocalDB while installing SQL Express. But that's it? Well no...now time is to play with it. Different from standard SQL Express engine, by default LocalDB doesn't register a service on registry so you will not see a SQLSrvr.exe running on Task Manager. To start with LocalDB, start with a Command Prompt and browse to your SQL Server Installation directory.

-> CD C:\Program Files\Microsoft SQL Server\110\Tools\Binn

-> You will find SQLLocalDB.exe in the folder. This executable supports many parameters. Common ones are:

• c - Creates a new instance
• s - Starts an instance
• d - Deletes an instance
• p - Stops an instance
• i - Lists all instances  
• There are few other parameters which you may not use but you can access them with /? parameter.

-> Now the biggest problem is how to connect with it. Well the Server Name in Connection String is bit different to connect to LocalDB. Just use (LocalDB)\<instance_name>

That's it. You are connected. Keep in mind that this is Local so you can't connect to this instance from another server. Also, if you don't use this instance for more than 10 minutes, it will switch off automatically. So you need to start it again from above command and "s" parameter. Hope you will enjoy LocalDB and next time I will not forget them ;) Not writing much about LocalDB but if you are interested, let me know. I can write a little more formal post of usage with few screenshots too :)

Important: https://support.microsoft.com/kb/269196

Microsoft does not support moving an already installed and configured Windows Server 2008 or Windows Server 2008 R2 failover cluster from one domain to another.

So what’s the way out?

- Script out the SQL User Account from Current SQL Cluster - https://support.microsoft.com/kb/246133

- Script out the Jobs from SQL Server.

- Take a backup of your all production user databases.

- Shutdown SQL Cluster

- Remove the Disk Dependency from SQL Cluster Resource

- Un-mount the LUN from Cluster/Nodes

- Destroy the Cluster

- De-active/Delete Computer Accounts listed in Active Directory Users & Computers for Windows Cluster and SQL Cluster.

- Complete your ADMT Migration.

- Configure New Windows and SQL Cluster with same names and temporary LUN for SQL Server.

- Restore all the logins generated from Step 1.

- Attach the old SQL LUN and set the dependency.

- Attach the databases.

- Restore all the Jobs generated from Step 2.

Now what if they have the SSRS also hosted on Cluster? Well we first need to clarify what’s the approach followed. Different organizations follow different approach such as one might go for a separate server hosting RS components or not so good approach of hosting RS components on Cluster nodes (also RS is not cluster aware). If they have SQL Enterprise, they might go for RS on each node on scaled-out mode (keep in mind that Cluster Nodes should not be configured with NLB – Not Supported), the approach should be:

Backup the Encryption Key from RS Configuration Wizard and that should be enough. You will follow normal SQL migration steps mentioned above and configure RS on new environment with existing databases. Restore the Key backup. That’s it!!

https://blogs.technet.com/b/ptsblog/archive/2012/10/02/microsoft-operations-framework-mof-4-0-fundamentals.aspx

Pre-requisites for Web Sync (IIS)

• Install the Internet Information Services 6.0 (IIS 6.0) management compatibility components (all).
• Install ISAPI Extensions and CGI
• FTP Server Components ( In case no separate FTP Server and Web Server need to be used as FTP Server as well) 
  • FTP Server
  • FTP Management Console (Windows Server 2008)
• Install Replication Components (In case SQL Server and Web Servers are two separate box) - https://msdn.microsoft.com/en-us/library/ms172376(SQL.100).aspx

Steps for Web Sync Setup

• Create a new FTP Site from IIS Management Console with appropriate Physical Path and expected Alias.
• Enable Anonymous Read access
• Give NTFS Write Permissions to Publisher SQL Server Service Account
• Configure Merge Publication (Follow the GUI wizard)
• Right Click on Publication and select Configure Web Synchronization
• Select Subscription Type
• Select the Name of IIS Server
• Create a new Virtual Directory
  • Give Alias and Physical Path
  • Replication ISAPI would be copied in the folder.
  • Select Basic Authentication and select Default Domain and Realm from Browse option
  • Select Users/Groups who need access to Virtual Directory (Give the Service Account details)
  • Give the UNC path for FTP physical folder
  • Finish the wizard.

Web Server Configuration Check

• Check ISAPI and CGI restriction – The Replication ISAPI components should be allowed.
• Application Pool should be set to Enable 32 bit Application.
• Disable Anonymous Authentication and enable Basic Authentication in IIS.
• Make sure that Local Computer/IIS_IUSRS have Read, Read & Execute and List permissions in Virtual Directory created above.
• Add IIS and SQL Publisher Computer Accounts to IIS_IUSRS group with same permissions as above.
• SQL Service Account should have full permissions on this folder.
• Create a Self Signed Certificate in IIS and bind your Web Sync virtual directory to use it.
• Configure SSL Settings and Select Require SSL and Client Certificate to Ignore.
• Access https://<iisboxfqdn>/<websyncfolder>/replisapi.dll and that should give you certificate warning. On acceptance, it would prompt for User Account/Password. On proper authentication, page should show SQL Server WebSync ISAPI in message.
• Install the Certificate in Trusted Root CA.
• Export the Certificate and install in trusted Root CA of Subscriber box.

Publisher Steps

• Change the Publisher Snapshot Folder location to FTP sites Physical UNC Path (If not set yet)
• Select Allow Subscribers to download Snapshot file using FTP and type in proper FTP server name, Path (ftp).
• Select Allow Subscribers to synchronize by connecting to Web Server and type in Web Server URL with Virtual Directory (https) as above.

Note: Defining alternate Snapshot Folder would always create a subfolder named FTP inside the UNC path. You need to make sure that you mention this in your FTP snapshot location.

Subscriber Steps

• For Connected subscribers (LAN), create subscription using wizard and change the default snapshot location to FTP.
• In the wizard make sure to select Use Web Sync and it would pick up Web Sync URL as mentioned in above step automatically.
• Type in User Name/Password on basic authentication section.
• For remote subscribers, you can create a script from subscriber created from above step and execute the same on remote subscribers

Please refer to below two articles for more details on security settings:

• https://msdn.microsoft.com/en-us/library/ff714039.aspx
• https://blogs.technet.com/b/mdegre/archive/2010/06/16/configuring-web-synchronization-on-windows-2008-64bit-for-merge-replication-with-sql-ce-subscribers-on-iis7.aspx

Referring back to two my previous posts on Merge Replication with SQL Server, there are few concerns as well with Merge Pub on few specific scenarios such as:

- Merge Pub always wins so writing directly on the publisher is not recommended for proper conflict resolution practices

- Data issue could fail entire merge topology in case data is written directly on the publisher than the subscribers

- Excessive locking could be an issue at the publisher end in case we have more subscribers

- Application performance which completely relying on publisher apart from merge partners could be impacted due to lower priority

Possible Solution:

In case you are facing any of the scenarios/issues, we recommend you to have a separate subscriber from where you can perform all the application specific read/write operations. Depending upon the server configuration, you might want to setup a separate subscriber hosted on separate box or it could be hosted on the publisher itself as the local subscriber with a new DB.

But we need to make sure that we don’t have any resource bottleneck on the publisher box otherwise the architecture wouldn’t really help but create more problems. Primarily we suggest you to review CPU and IO usage during peak usage hours on the publisher box using perfmon counters. Please refer to https://technet.microsoft.com/en-us/library/cc722414.aspx for more information on how to collect the performance data using perfmon. Also, https://pal.codeplex.com/ would help in assessing perfmon data.

Problem Description - In this scenario Customer wanted to setup a centralized DB with two location offices. They wanted to make sure that location specific data stays either in the particular location or on central server but it should not traverse across other locations. They had location identified in the table.

Customer had done some research on centralized replication topics on external sites but that made him more confused as he did not have any prior experience of replication topology.

Solution - We recommended them to go for a publication on central DB with two publisher. Each publisher with filtered articles based on location data and bi-directional subscriptions. With this approach, only location specific (filter specific) data could traverse between location and central DB and on central DB contains all data.

Error while setting up Merge:

Problem Description – This is one of the common error when you try to setup merge pub on the same DB where you removed previous merge pub:

Msg 20092, Level 16, State 1, Procedure MSmerge_disabledml_314BFF6E71E546EBA2994DC09C6C0CCF, Line 8

Table '[dbo].[Table_1]' into which you are trying to insert, update, or delete data is currently being upgraded or initialized for merge replication. On the publisher data modifications are disallowed until the upgrade completes and snapshot has successfully run. On subscriber data modifications are disallowed until the upgrade completes or the initial snapshot has been successfully applied and it has synchronized with the publisher.

Msg 3609, Level 16, State 1, Line 1 The transaction ended in the trigger. The batch has been aborted.

Solution - This is typically expected when few of the merge triggers remains in the database from the previous merge configuration (which was earlier removed). Look for and remove any triggers in sys.triggers where the name is like MSmerge%. Also verify Database Roles and Schemas for the same trigger name (MSmerge%) and if it does exist, remove the same as well.

Setting up Merge Sync to near Real-time:

Problem Description – Customer wanted to setup Merge Sync near real time. By default, merge sync (on continuous setup) polling interval is set to 60 seconds.

Solution – This can be achieved by following below steps:

1. Open Replication Monitor.

2. Select the Publication

3. Under All Subscription, your subscription would be listed for each subscriber.

4. Right Click on the subscriber one by one.

5. Select Agent Profile.

6. Click on New and Default Agent Profile.

7. Give a Name and scroll in Profile Parameters.

8. Change the Value for Polling Interval (should be in INT) as per your expected duration.

9. Click OK and select the new profile

Note: This could cause excessive lock in merge replication db. Also, this could cause high resource utilization as well.

Maintenance Recommendation of Merge System Tables:

Problem Description – Customer wanted to know the best practices for Merge System Tables as they had high fragmentation on those tables.

Solution - As part of maintenance for merge replication, occasionally check the growth of the system tables associated with merge replication: MSmerge_contents, MSmerge_genhistory, and MSmerge_tombstone. Periodically re-index these tables by running DBCC Transact-SQL commands. To re-index these system tables, execute the following commands on the publication database:

• DBCC DBREINDEX ('MSmerge_contents')
• DBCC DBREINDEX ('MSmerge_genhistory')
• DBCC DBREINDEX ('MSmerge_tombstone')

Additionally, one should minimize the size of the merge system tables (specifically MSmerge_history) by using sp_mergecleanupmetadata. Reference from below articles/posts:

https://msdn.microsoft.com/en-us/library/aa256294(v=sql.80).aspx

https://msdn.microsoft.com/en-us/library/aa237440(v=sql.80).aspx

https://technet.microsoft.com/en-us/library/cc966386.aspx

https://blogs.msdn.com/b/repltalk/archive/2010/02/23/collection-of-merge-replication-best-practices.aspx

Subscription Priority:

Problem Description – Customer wanted to know the concept of Scubscription Priority as whatever the priority they define while setting up Subscriber, always the publisher was winning.

Solution – Reference https://msdn.microsoft.com/en-us/library/ms152513.aspx and https://msdn.microsoft.com/en-us/library/aa237187.aspx

• To manage the conflict resolution, Merge follows Publisher win when any changes happen within a minute (Polling Interval)
• If the changes happen beyond the polling interval, last change would win.
• Priority setting is applicable when we use multiple subscribers.
• By design, Publisher would always have 100% priority (higher than the max subscription priority 99.99%)

Scenario Details:

• Single copy of database at the publisher end which is working as the Publisher DB
• Database is the backend of Custom ERP application.
• Database size is very small (4-5 GB)
• They have written custom SP which can write in backend apart from the FE application.
• Subscribers have Push subscription and running with SQL Express (On Demand /Custom Logic)
• More than 100+ subscribers.
• Users can write text using special characters such as ‘%&/*’ etc. in the application.
• Similarly the custom SP would process from remote files and write data in the application backend publisher db.

Issue Description:

When Publisher finds a special character in the replication articles, it fails. This causes entire environment failure. To fix this, they manually clean those special characters and they need to reinitialize the replication. They don’t want to have re-initialization and address the issue by some other way.

RCA Performed:

In the past, in most cases special characters were inserted either from FE application or through the custom SP based job which is actually processing some exported file and inserting data straight to database. But when a similar issue occurs at the subscriber level, only that subscriber fails and not the entire replication topology.

Solution Recommended:

Considering various facts such as Licensing Cost, TCO, and Administration overhead, we recommended the customer to setup a local subscription on the same server.

In this architecture, we recommended:

• A Staging DB where there will not be any direct write operations.
• ERP App and Custom SP based write operations would be happening to ERP Live DB.
• This DB would be a bi-directional subscriber with Staging DB with separate Publisher.
• This subscription would be running on regular frequency (automatic).
• Another publisher which would address remote subscribers’ requirement such as one way replication for few articles.

Benefits with this architecture:

• Consistency would be managed at the subscriber level.
• Subscription failure would not impact the rest of the replication topology.
• There will not be any locking issue at ERP App tier due to isolated remote subscriber sync process.

Challenges with this architecture:

• Extra storage might be required depending upon DB size.
• Separate maintenance jobs would be needed for staging DB as well.
• Higher CPU/Memory usage might be a concern.

This is one of those recent crazy cases where I was working.

Issue Description

Customer had a table of 1.5 TB in size with multiple partition (yearly partitioning strategy). Even though Microsoft always recommends that the last partition should be empty, they could not follow the strategy and added data in the last partition and it was more than 100GB at the time of call.

When they further tried using SPLIT function to create a new empty Partition so that they can move the 2011 data to a new partition, it was taking lot of IO and it was completing after almost 20+ hours. They wanted to know what was actually happening in the Partition Split and how to reduce the long processing time.

Research Outcome

Well this was one of those requests where recommendations were not followed and when there is an issue, explanation are expected. I really did not have any other option except looking at some internals. Mainly I referred few articles written by:

Kimberly Tripp: https://msdn.microsoft.com/library/ms345146.aspx

Kalen Delaney: https://sqlblog.com/blogs/kalen_delaney/archive/2009/08/16/altering-a-partition-function.aspx

I even looked at all the documentations which could help but alas, there is not much which could be shared. So here all what I could find:

• When you create Partition on one of your tables in SQL Server, primarily it keeps :
• Partition ID
• Partition Number
• Partition SPLIT or Partition MERGE will not do anything with First or Last Partition but would change the Partition Number (Sequence Number) depending upon the activity. In simple words, SQL would create new Partition and move the pointers so that it becomes part of the table:

• This process seems to be simple when the last partition is empty and we are creating a new in range partition where data is not in the table. (Scenario of last partition empty) where what max is happening is update in Partition Sequence Number.
• But when you have data in your last partition and you create new partition using partition SPLIT, it definitely follows the basic steps such as:
• Creating a new empty Partition.
• Update all the sequences numbers
• But at the end, the most important activity is, moving the data what was earlier sitting in the last partition due to no range definition (if that is the intent of defining the partition) but now has to move in new partition based on your new range.
• The above step is a time consuming process as physically we are moving the data pages from one location to another. And for sure, more the data, more the time it’s going to consume.

Summary

Overall to summarize, we commented on their approach. We mentioned that splitting the data partition is wrong and particularly with huge amount of data in the last partition, it is expected to give high IO usage and it would take longer time. We recommended them to go for Sliding Windows Approach with Partition Switch and follow archival strategy than keeping all the data in one table. Another alternate option what we suggested them to review is documented in Partitioning White Paper (Page 51).