I wanted to ask about Your experience related to set up a Transactional replication between SQL SERVER 2008R2 (publisher) and SQL SERVER 2017 (subscriber).
I know that this is not supported by Microsoft according to "Transactional & Snapshot Replication compatibility matrix", in the docs.
But I set up this kind of transactional replication (2008R2 -> 2017) on a few databases and it works without any errors. So the question is when or in what kind of situation (maybe some special type of configuration, user-defined data types...), this replication could stop to work or generate errors?
Support for SQL Server 2008 R2 has ended, so everything you do is unsupported.
In this configuration (2008 Publisher/Distributor/Push Subscription) all replication activity is driven from the SQL 2008 R2 instance, and with a SQL 2014 subscriber this was a supported configuration.
So the only thing that would break is if SQL 2017 somehow behaved differently than SQL 2014 did. To minimize the likelihood of issues keep the subscriber in 100 or 120 database compatibility level. 130 compatibility level introduced some breaking changes.
Related
we are currently using a 2008R2 publisher/distributor for replication.
The subscribers are versions 2008R2 and 2012.
Next week, we would like to update our servers step by step.
I read in the docs, that the subscriber must be within 2 versions of the publisher.
Does this mean, i could upgrade the publisher/distributor to 2014 and use subscribers with versions 2008R2, 2012 and 2017 simultaneously? (we plan to upgrade the subscribers to SQL-server 2017)
For SQL Server 2014 publisher you can have subscribers of SQL Server 2017
SQL Server 2016,SQL Server 2014,SQL Server 2012,SQL Server 2008 R2,SQL Server 2008
So it is possible.
Matix will give you a sound idea.
https://learn.microsoft.com/en-us/sql/relational-databases/replication/replication-backward-compatibility?view=sql-server-ver15
I would like to use Always Encrypted as part of SQL 2017 or SQL 2019 to encrypt a few columns but those columns are currently involved in transactional replication in the architecture. Always Encrypted does not appear to support transactional replication in SQL 2017 (would like to confirm) and I cannot find an authoritative answer for support with SQL 2019.
We successfully tested implementing Always Encrypted in SQL 2017 on columns in a table that are not involved in transactional replication. We could not get Always Encrypted to work for tables for those columns involved in replication. This validates the documentation that it is not supported. Not sure if there are any workarounds. The documentation for SQL 2019 seems to mirror the SQL 2017 documentation but I want to validate the limitation because I don't know if the documentation has been updated for the soon-to-be-released version of SQL Server.
Not code related
I was hoping that a key technology in SQL Server (transactional replication) would have introduced support for Always Encrypted columns over the course of 3 releases.
I want to test SQL Server 2014 In-Memory OLTP tables but I'm getting an error message when trying to create the filegroup.
ALTER DATABASE Test_DB ADD FILEGROUP Test_FG CONTAINS MEMORY_OPTIMIZED_DATA
FILEGROUP ... CONTAINS MEMORY_OPTIMIZED_DATA' failed because it is not
supported in the edition of this SQL Server instance
My database version is Microsoft SQL Server 2014 - 12.0.4100.1 (X64)
All the docs I'm reading are telling me this should be supported in SQL Server 2014, anybody have an ideas on what I've missed please?
Hey there are certain limitations in In-Memory OLTP of SQL server 2014.
This link lists them all, have a look.
https://msdn.microsoft.com/en-us/library/dn246937(v=sql.120).aspx
And the IN-Memory feature is not supported on Express edition of sql server 2014. Try Developer/SP1(service pack 1 - evaluation edition).
You can find the pre-reqs here: https://msdn.microsoft.com/en-IN/library/dn170449.aspx
We are considering to upgrade our Database from SQL Server 2008 R2 to SQL Server 2014. However, The new licensing with Core based seem to be very expensive.
We have one primary database and one secondary database. If we have SQL Server 2014 Enterprise Edition for the Primary database and SQL Server 2014 Standard Edition for the Secondary Database.
Question 1)
Is it possible to run transaction log shipping in different edition as above?
Question 2)
Could it be possible to run it from SQL Server 2014 to SQL Server 2008 R2?
Is it possible to run transaction log shipping in different edition as above?
Going for possibility yes it is possible to configure log shipping between SQL Server 2012 Enterprise and standard edition. But Just think of scenario where you are using enterprise features in Enterprise edition and failover happens now SQL server is on standrad edition and enterprise features will not work and you might face issue with application, some functionality crashing. I dont think you want this.
Plus again if you are using enterprise features and to configure loghshipping you take backup of enterprise edition and try to restore it on standard it would fail saying the backup has enterprise features and DB cannot be brought online because current database does not supports it
Could it be possible to run it from SQL Server 2014 to SQL Server 2008 R2?
No because you cannot restore database backup taken on SQL Server 2014 on SQL Server 2008 R2. If you like to make SQL Server 2008 R2 as primary and 2014 as secondary then you may succeed in configuring logshipping using T-SQL scripts( you cannot do it using GUI) but consider scenario where failover occurs and 2014 is new primary you cannot fail it back to 2008 r2 as Higher to lower version is not allowed.
Hope this is clear
Microsoft isn't letting you own a Web Edition of SQL 2012 like they did with 2008. But 2012 Standard edition is way overkill for my needs.
Can I have a database server running 2012 Enterprise (or Standard) and use transactional replication to populate data on a 2008 Web Edition box? This would, of course, be 1-way replication only.
Thanks... trying to save a bunch of money on licensing here.
Yes, replication is possible, as a subscriber only. See the Replication matrix in this article.
Basically, SQL Server 2008 Web Edition supports as subscriber only:
Merge replication.
Transactional replication.
Snapshot replication.