I have successfully configured merge replication on my local SQL server by creating two instances making one as Publisher and other as distributor.
Now to show demo to my client i need it to configure live by making my local system as Subscriber and any live sql server as publisher, can any one guide me that where should i configure live server ? As if i go to any paid SQL Standard edition it will cost me more than my salary , i just need to show demo to client. Can i install SQL Developer on any windows hosting? or there isn't any other option than buying server
If you want to Setup Merge Replication Demo on your local, then install 2 SQL Server instance or you can perform on same server as well. But for the better understanding you can consider one instance as a publisher and second as a subscriber.
Now, configure replication with Publisher and Distributor on Server-1 and subscriber on Server-2.
Related
I got a task to define various SharePoint farm topologies.
But I haven't any experience about SharePoint and anything else like that.
I found some information about the system requirement and the supported topologies, but I´m not sure if they are really supported.
It's hard to find helpful information. So my question.
I define a three tier topologie.
SharePoint 2016 Server
MSSQL 2016 Server
Workflow Manager Server
Is it supported to share the Database Server with the SharePoint and the Workflow Manager Server?
You can use the same SQL server for the workflow and SharePoint databases without a problem.
In fact I have a site that runs workflow manger from the SQL Server, database and IIS. This was due to the fact the all servers in the farm were Server 2016 and workflow manger is not supported on Server 2016. The only server available to install workflow manager was the SQL server which was Server 2012 R2.
Unless you have an insane amount of workflows, I wouldn't both with a dedicated workflow server, I would split the SharePoint server out into a Web and App Server.
NO, Based on Microsoft best practices SQL server should has its own box, SP and WFM should not be located on the same server to reduce any possible dependency in the future.
ex. sometimes, you will need to renew the certs which are expired. to do so, you need to change the time back.
if SQL and SP sharing the same box, the sites and db transactions will be infected.
another example: if WFM caused any memory leak or throttling, then the SP and SQL will also be infected.
you should dedicate a box for each platform.
1 more thing, the WFM should has odd number of servers. as the Windows/ service fabric uses voting to decide which server to handle the traffic. odd number of servers will allow one of the servers to be identified as preferred server to do so.
Is is possible to use AWS RDS for SQL Server as the destination / target for a read replica?
I have a database that runs on a private MS SQL instance in my data centre and I would like to publish a set of tables to an AWS SQL Server instance so that I can use that instance, and possibly others, to speed up read-only queries.
I know that AWS has restrictions and I wanted to know if the necessary infrastructure exists that would allow me to run a publisher and distributor within my data centre and target an AWS SQL Server database?
You can achieve this with Cloudbasic's RDS SQL Server HADR tool available on the AWS Marketplace: https://aws.amazon.com/marketplace/pp/B00OU0PE5M
Launch it in the same AWS VPC as your RDS SQL Server instance. In the quick setup, make sure to select SQL Server-to-SQL Server replication (as the tool also streams data from SQL Server to Redshift and S3 data lakes). Then to limit publishing to a subset of tables, after testing connections go to advanced settings, exclude tables you do not want to be published.
I'm using the Sync framework 2.1 with SQL Server 2008 and SQL Server CE with several clients.
I provisioned the client db and synced, then deployed that file with every client application.
Now sync doesn't seem to work correctly on all but one client. Did I need to provision the db for each client independently instead of using a copy?
This question does suggest so, please advise SyncFramework 2.1 updates & deletes do not seem to apply properly
in Sync Fx, each replica has a unique id to differentiate it from the other replicas. by copying a database, you'll end up with several replicas having the same id.
so what your doing will not work. if you want use a provisioned SQL CE database to initialize other clients, generate a snapshot and deploy the snapshot.
see: How To: Provision for Synchronization Using Snapshot Initialization
Recently we installed a new Sql Server 2008 server for a client and we had to move all the databases for them. Apparently they forgot about one application that uses replication with local Sql 2000 Desktop Edition instances. Now we're trying to get the replication running again.
Currently we get the error: The server '...' is not configured as distributor.
2 questions about that:
Is there a way to detect the type of replication used by just looking at the DB schema?
I'm guessing we don't need to run the replication wizard again since that changes the database schema which should be already ok. What do we need to do to manually hook up everything?
Apparently you made a fresh SQL Server installation, and not an upgrade, which would have been the recommended approach.
It seems that you can use both main types of replication now: merge replication and transactional replication (see this article)
Since you have a fresh installation, creating the publication from scratch is a must.
I recommend following the usual steps when setting up replication:
If at your subscriber you also need to make schema or data modifications then choose merge replication. If your subscribers are read-only or you don't need schema/data altered there, choose transactional replication.
Create your publication in SQL Server 2008. The distributor should also be this instance (because of replication rules between different versions of SQL Server - the distributor has to be the no earlier than the publisher). Choose your articles, snapshot agent schedule, security settings.
Initialize snapshot.
Re-create your MSDE 2000 subscription. Note that all agents should run at the Distributor.
You have to figure out your security settings. Especially how your subscribers connect to the publisher (SQL credentials or integrated security if in a domain).
So, recreating your publication shouldn't be very hard.
If you previously had merge replication setup then a real problem could be data at the subscribers that hasn't been uploaded to then publisher yet. So you have a bunch of subscribers all with their own modifications. In this situation you either discard the data or manually backup each subscriber and synchronize it after subscription initialization.
I have to setup a database for reporting, and I chose transactional replication for that because it seems the easiest way (setup has to be easy, i will have to explain to customers how to do that). Now for that i do need a distributor database, and i found information that it should not be on the publisher. As there will only be one subscriber, and the performance of the publisher matters alot and the performance of the subscriber does not, I was thinking of setting up the distributor on the subscriber. Does that make sense and is that even possible?
Flo,
Yes, this is a popular configuration. You'll want to configure distribution on the Subscriber and have it act as a remote Distributor for the Publisher. After configuring distribution on the Subscriber and creating the publication on the Publisher, you can then create the subscription on the Subscriber.
Remote Distributors are covered in Configuring Distribution and in How to: Configure Publishing and Distribution (SQL Server Management Studio).
Hope this helps.