https://zen4sync.codeplex.com/

By default, this option is set to FALSE, as explained here in BOL:

 [ @stream_blob_columns= ] 'stream_blob_columns'
Specifies that a data stream optimization be used when replicating binary large object columns. stream_blob_columns is nvarchar(5), with a default of FALSE. true means that the optimization will be attempted.

However one should be careful with the NOTE information (see below):

When filestream is enabled - @schema_option = 0x000000010C034FD1 (100000000 --> Use this option to replicate the FILESTREAM attribute if it is specified on varbinary(max) columns. Do not specify this option if you are replicating tables to SQL Server 2005 Subscribers. Replicating tables that have FILESTREAM columns to SQL Server 2000 Subscribers is not supported, regardless of how this schema option is set. See related option 0x800000000) - the stream_blob_column option is also enabled and a warning is generated:

Warning: To allow replication of FILESTREAM data to perform optimally and reduce memory utilization, the 'stream_blob_columns' property has been set to 'true'.  To force FILESTREAM table articles to not use blob streaming, use sp_changemergearticle to set 'stream_blob_columns' to 'false'.

Should this option NOT be necessary (you will not be transfering data greater than 16K) than you should disable the option in order to avoid possible performance issues.

Important
Enabling this memory optimization may reduce the performance of the Merge Agent during synchronization. This option should only be used when replicating columns that contain megabytes of data.

Note
Certain merge replication functionalities, such as logical records, can still prevent the stream optimization from being used when replicating binary large objects even with stream_blob_columns set to true.

If sql_variant column includes a value with new datetime type, the value is replicated as base type nvarchar even if schema option 0x200000000 is not set during the application of the SNAPSHOT (only).

After the snapshot has been applied, if you execute the command to verify the property of the sql_variant column:

SELECT SQL_VARIANT_PROPERTY(column_name,'BaseType'), * FROM table_name

You will see that on the Publisher it shows as (example) DATE while on the subscriber its NVARCHAR

Cause:

 Its an issue that invovles both the snapshot agent and SNAC10.

 Solution/Workaround

 THE WORKAROUND THAT WAS POSTED HERE BEFORE HAS BEEN REMOVED AS IT HAD OTHER IMPLICATIONS AND IS NOT RECOMMENDED

 Microsoft is still looking into this however the solution to this issue is to verify if sql_variant is the right datatype to use or if there is anything way (within the app code) to work around the basetype difference. 

Consider the following scenario:

• You use a merge publication operation to replicate XML data in Microsoft SQL Server 2005, in Microsoft SQL Server 2008, or in Microsoft SQL Server 2008 R2.
• A foreign key violation error occurs in the same merge replication batch.

In this scenario, you may find the merge replication fails and the XML data is partly replicated or lost. Additionally, an error message that resembles the following is logged in the SQL Server error log if this issue occurs:

Cause:

This issue occurs because the merge replication stays in an error state and cannot handle a sequential stream of the XML data when a Foreign Key violation error occurs.

Solution:

https://support.microsoft.com/kb/2582285

Compatibility level affects behaviors only for the specified database, not for the entire server. Compatibility level provides only partial backward compatibility with earlier versions of SQL Server. Use compatibility level as an interim migration aid to work around version
differences in the behaviors that are controlled by the relevant compatibility-level setting.

           
In this link, you see some examples of how the database compt mode alters the way SQL “treats” the database, for example:

           
With a DB COMPT LEVEL of 90 --> SET XACT_ABORT OFF is not allowed inside a trigger.

https://msdn.microsoft.com/en-us/library/bb510680.aspx

Publication Compatibility Mode:

Merge replication uses the publication compatibility level to determine which features can be used by publications in a given database. The values range from 80RTM (SQL Server 2000 that has no service packs installed) to 100RTM for SQL Server 2008.

           
Examples of how the publication compatibility level affects the publication:

The following features require a compatibility level of 90RTM or higher:

• Logical
  records
• Subscriber
  upload options.
• Nonoverlapping
  partitions
• Business
  logic handlers
• Schema
  changes that use ALTER <OBJECT> statements

https://msdn.microsoft.com/en-us/library/ms143241.aspx

So basically:

DB compatibility mode affects the DATABASE (and what you can do using this database)

Publication Compatibility mode affects the PUBLICATION (and what you can do in replication)

While running the snapshot agent, the available memory of the server goes down to 0 and snapshot may even fail. Should the snapshot complete, the memory is released very slowly.

Cause:

This is because in the current design (SQL 2005 and higher), snapshot agent uses SNAC BCP provider which uses memory mapped files for BCP out data and does not flush the data based on a threshold.

Solution:

https://support.microsoft.com/kb/2582285

Error "You can only specify the READPAST lock in the READ COMMITTED or REPEATABLE READ isolation levels" generated when altering published table columns in a transactional replication.

Cause:

Unable to alter columns on Published database if using any isolation level besides the READ COMMITTED or REPEATABLE READ isolation level.

READPAST hint is not compatible with READ UNCOMMITTED isolation level, but only with READ COMMITTED and REPEATABLE READ isolation levels.

READPAST hint is used in internal stored procedures in order to resolve issues within replication.

Solution/Workaround:

Other options (other isolations levels) that reduce locking:

In SQL Server, you can also minimize locking contention while protecting transactions from dirty reads of uncommitted data modifications
using either:

• The READ COMMITTED isolation level with the READ_COMMITTED_SNAPSHOT database option set to ON.
• The SNAPSHOT isolation level.

https://msdn.microsoft.com/en-us/library/ms173763.aspx

An alternative would be to create a stored procedure that performs the alter statement, in which we specify the isolation level necessary, and call that stored procedure when the alterations to the columns is needed.

Publisher: SQL Server 2008

Subscriber: SQL Server Compact 3.5

Merge Replication

Performance issue when using keep_partition_changes or precomputed partitions

Cause:

There could be many causes to this and analysis would have to be done however sometimes it may be due to missing indexes.

Solution/Workaround:

In a test environment, use the following indexes and verify performance:

CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]

ON [dbo].[MSmerge_current_partition_mappings] ([partition_id])

INCLUDE ([rowguid])

GO

//--//

-- changed and new indexes on system tables

DROP INDEX nc5MSmerge_contents ON MSmerge_contents

CREATE NONCLUSTERED INDEX [NCL_marker] ON [dbo].[MSmerge_contents] ([marker], rowguid)

CREATE NONCLUSTERED INDEX [NCL_partition_id_rowguid] ON [dbo].MSmerge_current_partition_mappings (partition_id, [rowguid])

-- update statistics on system tables

update statistics MSmerge_current_partition_mappings with fullscan

update statistics MSmerge_contents with fullscan

update statistics MSmerge_partition_groups with fullscan

-- update statistics on all tables involved in join filters

update statistics <table name> with fullscan