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).
Related
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
Summary: Is there anything new in SQL Server 2014 (versus 2008 R2) that does not allow the following scenario? Can the same approach be transfered to the new server?
The application uses SQL Service Broker to collect data from satellite SQL Express machines (technology computers, now two, soon 4, and possibly more) to the central SQL Server with SQL Server Standard edition.
It is based on simplified security settings without the need to exchange certificates. I was asked to migrate the solution from SQL Server 2008 R2 to SQL Server 2014.
The situation was described in details at SQL Service Broker -- one central SQL and more satelite SQL... beginner wants to understand details and the solution was based on the Remus Rusanu's answer.
Yes. All SQL Server releases, from 2005 to 2014 inclusive, are compatible with each other at the Service Broker layer. In fact the 2008 instances are not even going to be able to figure out they are talking to 2014.
You should be able to migrate one machine at a time, w/o taking down everything. If the upgrades are don in-place (keeping the machine name the same and preserving the SSB endpoint settings) then you won't have to change anything after the upgrade, it should just keep working.
If you do side-by-side upgrade then you will have to port the SSB endpoint settings and certificates used from one instance to the other, along with moving the database.
Keep in mind that if you have a problem and you are forced to rollback to a backup then your entire, distributed, system state will not be consistent (basically conversations will no longer match the send sequence number and receive sequence numbers) and you may have to force some close conversations (manual END ... WITH CLEANUP on a case by case) or nuke the entire broker in the DB (ALTER DATABASE ... SET NEW_BROKER). Lets hope you won't have to do this. If is feasible then you could simply stop the entire system (eg. run ALTER ENDPOINT ... STATE = STOPPED on all 3 nodes to stop all SSB communication) and then do a backup and then do the upgrade, now being safe to rollback the upgrade and restore since everythign is 'frozen'.
I am new to SQL and to SQL server and I am using the book to build my knowledge. During early parts of the book, the author has below para. I am confused with the sentence in bold and italics below.
What is the purpose behind running multiple instances of SQL server on a given server? It seems that SQL server is a very costly software, in such case isn't installing multiple instances a costly task?
The Database Engine sits at the core of the SQL Server components. The engine operates as a service on a machine, which is often referred to as an instance of SQL Server. You can run multiple instances of SQL Server on a given server. When you connect to SQL Server, the instance is the target of the connection. Once an application is connected, it sends Transact-SQL (T-SQL) statements to the instance. The instance in return sends data back to the client. Within the connection is a security layer that validates access to the data as specified by the database administrators (DBAs). The Database Engine enables you to leverage the full capabilities of all of the other components, such as accessing, storing, and securing the data..
You might want to run various versions of SQL Server, e.g. 2008, 2008 R2 and 2012 simultaneously in parallel on a given machine. If you're e.g. a consultant and your clients use different versions of SQL Server, and you need to be able to get a backup from them, do some work, and send the database back, you have to use the same version as your client does. Backups aren't backwards-compatible, e.g. if your customer uses 2005, you can restore his 2005 backup onto your 2012 server, but you CANNOT return the data back to the client (since the backups are NOT backwards compatible - you cannot restore a 2012 backup on a 2005 server).
Or you might want to run separate instances for e.g. development and testing on the same physical server machine in separate instances (that are quite well isolated from one another). It's a great way to separate two (or more) "worlds" (environments) of SQL Server from one another; you might have all the same databases - but once in the "Development" context (for your dev team, work in progress), and a second time for your Quality Assurance or Testing team. If you have two totally separate instances, it's like having two (or more) servers living on one machine.
Multiple instances of SQL Server on a single physical machine are a great way to have separate environments - both based on the versions (and editions) of SQL Server you might need to support, but also in terms of the use of the instances - development vs. testing vs. demo vs. whatever-else-you-might-have.
Instances are very well protected from one another and don't interfere with each other - each has their own databases, logins, security, etc.
I´m deploying my database to a SQL Server 2008 R2 Express instance that my software also installs. Everything works fine, but on certain target machines there are other instances of SQL Server 2008, 2005, 2000...I know that, theoretically, SQL Server instances may coexist side-by-side. But I also know that there are several conflicts between them. Internet is full of them.
My most common symptom is: server protocols are not installed with a previous installed SQL Server 2008 instance (from other vendor). In SQL Server Configuration Manager, under "SQL Server Network Configuration", the item "Protocols for 'MyInstance'" is just missing. So any client machine can connect to server.
I´d like to minimize the visits to clients house and make my application as self-deployable as possible. Is there something I can do to avoid or resolve instances conflicts? Any advice? Am I wishing for something impossible?
You probably will want to read up on what versions can live on the same server/client:
Working With Multiple Versions and Instances of SQL Server
Work with Multiple Versions and Instances of SQL Server
Both of these links have the chart regarding what side-by-side installs are supported, the second though also includes a little bit more regarding the components and those that will be upgraded to the highest release installed.
With the issue you spoke of with SSCM this can be caused by many things, most of them revolve around a corrupted installation of the management tools; or I mostly see issues with WMI calls on the client. Since most of those settings are available within the registry I would suggest looking at that side to get your instance configured and locked down.
You might also look at SQL Server Compact Edition. It is developed as an embeded database that does not require install of the full SQL Server managemnet tools. You have the same API and controlls that come with full version of SQL Server, just a "compact" install. I have interacted with one application that used it but have not done any development with it.
We are working for a client with an asp.net/SQL server application which has been using a SQL Server 2005 system till now. The client has decided to upgrade the database to SQL Server 2008 R2 and has procured a powerful server machine with 16 processors with enough RAM and installed Windows Server 2008 64 bit on the system. Now we are tasked with the installation of SQL Server 2008 on the system followed by migration of the existing DB from the SQL 2005 box. Now I am not a SQL Server DBA nor am I a System Administrator by role. Hence, in spite of reading up a lot of the literature on the net, I am not quite able to make sense of it all or put it in the right order of execution. Can somebody explain me the following items, preferably in terms of bullet lists:
What are the points of consideration during installation of SQL Server 2008, specifically in terms of
Configuring memory usage
Configuring the SQL Server to take advantage of the multiple processors available
Other factors to configure to enable SQL Server 2008 features for performance and scalability
Other points, if any, for configuring the Windows Server 2008 with respect to SQL Server 2008
Note: We will only use the Database Engine services in SQL Server. The applications does not use SSIS, SSRS, etc.
SQL Server will take advantage of whatever processors are available. Processors will be shared between sessions - if all of the work is being done by a single session, then it will all occur on the same processor (to the best of my knowledge - this requires citation).
Memory usage is dynamic by default, meaning that there is no restrication on memory usage. You can limit the memory usage used by the server (right-click on the connection in SSMS and select properties) if needed. This is generally used if the instance is part of a server performing other tasks, such as running other database instances, web service tasks, etc.
SQL server is pretty good it sorting itself out according to its environment. If you are in a position that you need to create a server farm and distribute data and processing between different machines, this is a whole new topic, discussed at length on MSDN and the StackExchange forums.