Is it possible to create Transactional Replication setup between 2017 Enterprise edition to 2005 Standard edition in MS SQL Server?
I heard that it is possible through scripts, is it right?
Publisher and Subscriber needs to be within 2 versions and Distributor should be higher than or equal to subscriber. You can always configure with a Subscriber that is beyond 2 versions from Publisher through T-SQL scripts and it might work. But it is not supported by Microsoft which means you are on your own if there is anything that blocks you.
As you called out, you should be able to configure replication between 2017 and 2008R2 but your 2008R2 server would miss all the improvements and updates we made to the internal stored procedures and metadata related to replication. Though most of these changes should be backward compatible, some of these might not work as expected if your running them in unsupported configurations.
Related
I have two sql servers
Windows Server 2008R2 SQL Server 2012
Windows Server 2012R2 SQL Server 2016
I want to mirror one of the databases to the other.
Will it work on different sql versions or cause problems?
The summary is-
The principal and mirror server instances must be running on the same version of SQL Server. While it is possible for the mirror server to have a higher version of SQL Server, this configuration is only recommended during a carefully planned upgrade process. In such a configuration, you run the risk of an automatic failover, in which data movement is automatically suspended because data cannot move to a lower version of SQL Server.
For more details, please visit Here
Will it work on different SQL Versions or cause problems?
Yes, but it will work only when Primary is Lower and Secondary is Higher version, as it already confirmed by MkRabbani, you need to plan it accordingly.
Consider, by any chance if fail-over happened the database cannot be reverted back (by fail-over again). So, it's possible but depends on your scenario how do you want use Mirroring, Log Shipping etc.. as all work in same manner (always lower to higher version possible, but not higher to lower).
I'm following a step-by-step guide written by a Microsoft field engineer on below documentation to create BizTalk 2016 AOAG with SQL 2016 enterprise edition in conjunction with Server Management Studio (14.0.17224.0):
https://learn.microsoft.com/en-us/biztalk/core/high-availability-using-sql-server-always-on-availability-groups?redirectedfrom=MSDN
My question on preparing the availability group using Server Management Studio (14.0.17224.0) supports database DTC option is that new functionally added to SQL management studio (14.0.17224.0) and during creation of his lab environment he mention DTC support cannot be applied from the SSMS and must be done in script?
I created AG though SSMS GUI and ran query to find DTC status on DATABASE as below
:
--===Checking where there DTC support is ENABLED or NOT for BIZTALK 2016 SSODB======
SELECT NAME,DTC_SUPPORT FROM sys.availability_groups
HOLD ON!
The first thing you should do is really, double, triple check you really, absolutely 110% need (as in no other option) to use AOAG with BizTalk Server.
While supported, AOAG is in practice a net negative with BizTalk Server over regular failover clustering alone since it adds significant additional complexity to the setup, while providing no incremental benefit to BizTalk Server.
Note, this situation is specific to BizTalk Server. Many apps can and do benefit from AOAG, just not BizTalk Server.
Availability Groups is better H/A solution in my opinion. It comes with database-redundancy and a much faster failover which a BizTalk environmient will benifit from.
From SQL 2016 SP2 and SQL Server 2017 it also supports Cross Database Transaction inside instances in AOAG so you only need one instance (instead of 4 instance in SQL 2016 SP1).
I belive that a Windows Failover Cluster is more complex because you have a lot more shared resources while in Availiability Groups it is only the listner that is a resource in WFC.
Starting with SQL Server 2016 (13.x) Service Pack 2 you can alter an availability group for distributed transactions. For SQL Server 2016 (13.x) versions before Service Pack 2, you need to drop, and recreate the availability group with the DTC_SUPPORT = PER_DB setting.
We are updating several SQL Server 2008R2 instances to SQL Server 2012 SP3 CU2. I know that the database versions will be changed from 100 to 110 during this process (e.g. once finished, the databases can no longer be moved back to a 2008R2 instance).
Does this change to the databases occur during the upgrade itself or the first time that the databases are brought online when the server restarts?
SQL server keeps track of version in two ways. First, your SQL Server instance has a version (for example SQL Server 2008 R2 is 10, followed by some decimals to keep track of patches).
Your databases are a separate version, known as a Compatibility Level. If you upgrade your instance, your databases will not be upgraded until you choose to do so. That does not mean there will not be an impact, however it does mean those databases can remain in their old version. Your example of 100 and 110 are both Compatibility Level.
Please see changing Compatibility on MSDN here: https://msdn.microsoft.com/en-us/library/bb510680.aspx
Has anyone here moved the database underlying a SP 2010 install from one database instance to another (same data, just hosted in another instance)?
For example. we just want to move the database to a diffrerent machine.
In addition, has anyone moved SP 2010 from using SQL Express to a higher version of SQL Server? I would like to run some proof of concept tests with SQL Express, and if all goes well, then move to SQL Standard or Enterprise.
Cheers,
Daniel
Check out the following article:
http://technet.microsoft.com/en-us/library/cc512725.aspx
I don't think you'll run into any problems, just make sure you aren't going backwards in versions between databases. Backing up a database in SQL Server 2008 and restoring in 2005 isn't easy.
I've never done this with SharePoint, but I believe it lets you specify the location of the configuration database. Then you just need to match the user permissions.
The TechNet article "Move All Databases (SharePoint 2010)" is your main guide.
Note that this article contains the following warning:
The new database server must be running the same version of Windows
Server and Microsoft SQL Server as the existing database server.
This in NOT true!
Both from my own experience in migrating SharePoint databases and talks I've had with Microsoft Primary Field Engineering, I can say this method also works when SQL Server versions differ. But only if you upgrade to higher SQL Server versions (i.e. SQL Server 2005 to SQL Server 2008 R2). I was told this scenario is also fully supported by Microsoft.
Also, don't forget to update the database compatibility level for the migrated databases. This should future-proof your databases and enable advanced SQL Server optimization.
I see this question here on SO but I am not sure that answers my question. My Central SQL server is 2005 Standard. I am developing an app that requires SQL Express to be installed locally. I am then programmatically creating the Subscriptions and then Syncing them.
Can I use 2008 Express for this on the local machines?
In short, yes.
The technology is backwards compatible and so a SQL Server 2008 subscriber can receive a subscription from a SQL Server 2005 Publisher.
For detailed documentation on the backward compatibility of SQL Server Replication please consult the following reference:
http://msdn.microsoft.com/en-us/library/ms143323.aspx
I realize this is old, but I ran into a similar situation (Using Web Synchronization with Replication) as the original poster and found this posting and used the short answer above to start working on it. I got an error that explictly said I needed SQL 2008 or later as the publisher to use SQL 2008 Express as the subscriber. This MS page:
http://msdn.microsoft.com/en-us/library/ms143241.aspx
clearly states it in the matrix of publishers and subscribers:
" This configuration is not supported because the Publisher version must be equal to or greater than the Subscriber version."
Anyway, I wanted to post the clarification in hopes that it will save the next person the time and frustration it cost me.