Team Foundation Server (TFS) failure attempting to add
an attachment when replication is configured on SQL backend version 2008 R2 (RTM) - 10.50.1617.0 (X64) Enterprise
Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1).

Error:

TF237082: The attachment could not be uploaded. Verify that
you have a network connection and that Team Foundation Server is available.

HTTP Status
Code: InternalServerError – TFS51334: An unknown Web service error occurred:
UPDATETEXT is not allowed because the column is being processed by a concurrent
snapshot or is being replicated to a non-SQL Server Subscriber or Published in
a publication allowing Data Transformation Services (DTS) or tracked by Change
Data Capture.

Solution:

Step 1 ~ Root cause could be size restriction on the publisher. Verify that SQL replication
is configured to handle the maximum text size.

exec sp_configure 'max text repl size', '2147483647'

reconfigure with
override

Step 2 ~ Root cause could be incorrect or lingering old metadata
related to the publication. In our case there was a column in the TFS database
having a value > 0 in its  is_non_sql_subscribed
column.

select @@SERVERNAME

go

use Tfs_Production

go

select object_id,name,
is_dts_replicated, is_column_set, is_merge_published,
is_non_sql_subscribed, is_replicated, *

from sys.columns

where object_id
= object_id('Attachments')

go

select id,
name, colstat

from sys.syscolumns

where id =
object_id('Attachments')

go

 The quickest way we could reset the column and resolve the problem was to do the following:

1)   Drop all replication components (subscriptions, publications, and distribution database)

2)    Setup a small dummy database having 1 small table with a primary key

3)   Recreate distribution and publish the dummy table

4)   Create subscription for dummy publication

5)   Create publication on TFS database

6)   Create TFS subscription

7)   Drop dummy subscription, publication, and database

Problem: 16TB data warehouse partitioned by month on a datetime key column. A new file group, data file, and partition are created for the next month during the last week of the current month. This monthly maintenance task occurred without issue while DW was hosted in SQL2K8 R2, however, it failed after the DW was migrated to a new server running SQL2K12 RTM. The FG and file created successfully and the NEXT USED command completed successfully. The exact failure point occured at the following command:

ALTER PARTITION FUNCTION PFEventDateTimeRangeByMonth ()

SPLIT RANGE (N'2012-10-01T00:00:00.000') 

The command would run for several seconds before generating a stack dump in the SQL log and returning the error "A severe error occurred on the current command. The results, if any, should be discarded" in the results pane.

Troubleshooting: Attempted all of the following to try and resolve ~

0) Verified that all other monthly partition operations in 11 other DW's on the same server were working just fine.

1) Tried splitting the partition using a variety of date ranges, file group, and data file configurations.

2) Thought maybe a recent partition switch/merge operation for old data might have precipitated the problem. Restored the last 2K8 full backup before the switch/merge had occurred and tried split again unsuccessfully (BTW - customers loved having the DW offline for 6 days while I restored the db and reloaded the delta data for no reason)

3) Restored same full backup to Test server and ran full CHECKDB. It surprisingly finished within a faster than anticipated 48 hours, but no corruption was found.

4) Escalated the issue to the product team where they confirmed a product limitation that would need to be resolved via CU. In the meantime, they worked diligently to find a workaround.

Resolution: The product team explained that the bug was related to how the indexed view metadata was unexpectedly blocking the split operation. Not sure that means the metadata was corrupted, but rather it did not change to an expected state as part of the split operation. We see similar issues from time-to-time with trans. replication publication metadata in SQL2K8.  

The workaround identified required us to drop the 2 indexed views, split the partition, then rebuild the indexed views. Not knowing for sure when the CU would be released, we opted to limit risk by creating new partitions for the next 8 months. When recreating the last indexed view (and the largest one) the operation failed and returned the same severe error from the original issue, however, no stack dump or exception was generated in the SQL log. Because the production maintenance window was closing fast, I decided to reduce the number of records in the indexed view by 50% by adjusting the WHERE filter. We were fairly confident the new range would satisfy most business use case scenarios. Thankfully the 2nd attempt with the adjusted filter worked after a few hours build time.

- Jonathan Foster

We are SQL enthusiasts in the MPSIT group within Microsoft IT. Though we are Microsoft employees, we are also faced with many of the same challenges as end users. What differentiates us is the availability of internal resources like SQL product teams, SQLCAT team, SQL internal discussion alias etc.,. Our purpose for this blog is to share our experience solving problems faced by enterprise operations personnel where documentation is insufficient or nonexistent.  We want to help fill this unique knowledge gap in the SQL community to further advance SQL Server as the preferred database solution across the globe.

Please share your feedback and comments, we're listening!

Thanks,
MPSIT Operations - SQL Team