I searched everywhere but couldn't find an answer. I know LocalDB cannot be a subscriber to merge replication. But what about transactional replication?
I've tried both the SQL Server Management Studio and RMO programming to create a pull subscription to a publication with type of transactional replication, but it keeps telling me "replication is not installed on this instance of SQL server". There is no option for me or the user to select replication feature during the install. And re-installing LocalDB won't do any help.
I know it is possible to use sync framework to do the job but it is something new to me and I've already deployed LocalDB to the clients computer in my previous software release, so I prefer to stick around with the replication method before I know for sure that LocalDB doesn't support any form of replication.
To summarize my question: How do I create a pull subscription on a LocalDB instance to subscribe to a transactional replication?
BTW, the LocalDB is deployed to the clients computers using the bootstrapper came with Windows 8 SDK, which can be found in this directory if you have one installed: {C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages\SqlLocalDB2012}
I would be happy to provide more information if I didn't make it clear. Thanks in advance!
Based on your question: "How do I create a pull subscription on a LocalDB instance to subscribe to a transactional replication?", the answer is simple. You can't.
Setting up a pull subscription requires replication components to be installed (they're not), and requires Agent to be installed (it's not).
I think you have a reasonable chance of getting a push subscription set up, as all the serious code happens on the distributor.
The problem, I find in your question is that you were not able to setup transactional replication in a Local DB instance.
I want to add my work on Transactional Replication.
Recently, I created Two Local SQL Server instances. I setup Transactional replication among these two SQL Server instances without any problem. I hope this helps. Please comment if there is any question on this.
Related
I'm trying to upgrade my TFS2017 Update 3 environment, to a new Azure DevOps Server (on-premise) environment.
I've created a new server for Azure DevOps Server, as I'd like a newer version of Windows Server, and in general just want a completely fresh environment. I took backups of my databases, shut down the old TFS2017, without deleting anything.
I migrated the databases to a new SQL Server instance (where I have all my other databases), as I see no need to use an SQL Server license just for source control.
Now comes the fun part. I tried to configure Azure DevOps Server to use the existing database (after the migration to the new SQL server instance was done). I had some issues with the TfsJobAgent service, but got those resolved.
I then tried to reconfigure Azure DevOps Server (as it failed the first time), but during configuration, it now tells me that data is corrupt, and that the existing database cannot be used. Good thing that I took backups :)
It should be said, that the new SQL server instance is a 2019 version, so that shouldn't be a problem.
I'm not quite sure what is happening here, and why it's giving me this error. Am I migrating in a wrong way? There's not much documentation out there describing this flow.
Please go through the documentation below before upgrade:
https://learn.microsoft.com/en-us/azure/devops/server/upgrade/get-started?view=azure-devops
And follow the steps in article Upgrade scenario walkthrough for Team Foundation Server to upgrade your TFS. Summarize the steps here:
Prepare your environment. The first step is to check the system requirements for TFS 2018. Upgrade SQL Server is
necessary for your scenario. Including SQL Server, you also need to check other system
requirements and prepare the environment.
Expect the best, prepare for the worst. You must have a complete and consistent set of database backups in case something
goes wrong.
Do the upgrade. Once the preparation is done, you'll need to install the new version of TFS to get new binaries, and then run
through the upgrade wizard to upgrade your databases.
Configure new features. Depending on what version you upgraded from, you may need to configure each team project to gain access
to some of the new features made available.
For some reason the SQL Management Tool doesnt work with Azure SQL Databases. This is nothing short of painful if you use the designers and diagrams to design your database.
I'm sure I'm not the only one who has stumbled at this point and would like to know what tool I can use to visual design and maintain the database.
SQL Server Management Studio supports Azure SQL DB. Step-by-step docs are here: http://azure.microsoft.com/en-us/documentation/articles/sql-database-manage-azure-ssms/
You will have problems if you have not configured firewall rules for your database to include your client IP range. What sort of errors are you experiencing?
The latest update to SSMS supports full design and edit with a few minor things missing.
We have a single MS Server 2012 for hosting our MSSQL 2014.
On the Server we already installed two instances of MSSQL 2014.
One for the productive Business-Applications and one instance for the development Databases.
Beside the MSSQL 2014 installation we need to setup the TFS2013.
My question is if it is a good thought to make an own instance for the TFS or if we should just use one of the existing instances (Probably the dev) to store the databases.
We would love to use another instance because we would like to isolate the TFS Databases (so a restart of the TFS SQL Service should not affect the prod dbs) from the rest. We know that the administration needed for three instances is bigger than for two but we can neglect that.
Will there be a big loose in performance with a third instance, or isnt it that dramatic?
To avoid some anwsers, there is no possibility to implement the TFS or MSSQL on an other server(Because we just don't have any free resources).
The Server is from the hardware POV suitable and because we're a small company there won't be that much connections to the DB's (40 Employees to the Prod Instance, 3-5 Developers connecting to the DEV and TFS Instances).
The data tier of your TFS installation does not require any restarts. It's just a database that's created on your SQL Server.
The application tier of TFS is where the real work happens. This is where your users connect to and where the Windows Service and IIS websites are running.
It is no problem to use a shared SQL Server instance for installing Team Foundation Server.
If you want more information on how to install TFS checkout the ALM Rangers documentation. We have just released a new version of the guide that can be found here.
I would install also on a separate instance because the development or the production databases may require an SQL Server services restart which will cause a TFS unavailability.
Also you don't want to give permissions to the developers on TFS databases (usually developers are requiring higher permissions on their development databases, e.g. sysadmin for backup/restore)
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.
In an installation with 2 SQL Server 2008 SP2 Standard servers we use mirror to have failover partner for the databases.
One of the purposes of the databases are to supply reports through SQL Server Reporting Services.
My question is how I set this up to have failover of the reports AND keep cost at a minimum.
I can see one solution where the reporting databases are mirrored as well as the user databases they use. But will the reporting services failover?
Another way could be to install 2 separate instances of reporting services on each database server where the reporting databases are not mirrored and both are running. But then how do I redirect the users browsers from one entry address to a running reporting service?
There's also a witness server running SQL Server 2008 Express. This could be upgraded to standard and run the reporting services (should be able to failover through native client connection), but then the reporting service it self has no failover.
I don't know if I'm missing something here but is it impossible to do this in a good way without using SQL Server Enterprise and a failover cluster solution?
Any ideas, thoughts and links would be appreciated, but be aware that I have read a lot of guides and best practices around the internet and haven't found any that answers this question so please only post relevant links.
Any info I gather from you post, links and my research and testing will of course go back to Stackoverflow for future reference for others as I can't imagine I'm the only one who would like such a solution.
Smint
You will need to mirror all data and then manually repoint the report server when the data moves to the mirrored servers.
Moving interrelated databases with mirroring complicates things. If one goes offline for some reason and failes to the mirror, will all other databases fail as well?
You may want to have a human make these decisions and use a manual failover on the mirroring as well.