I'm preparing a migration plan to migrate on-premises SQL Server to Azure. On our on-prem there are two sql instance (DevSQL01\Dev and DevSQL01\Demo) running on single VM. Can we create a same scenario on azure, i.e. can we create two SQL instance on a single Auzure SQL VM or is their any other option?
I know i can create a windows VM on Auzre and install SQL Server and create two instance manually, but i like to find out options like managed instance, elastic pool, etc.. has the feature to host named instance by default.
Forgive me if this is noob question, I just started exploring cloud technologies.
On all flavors of Azure SQL PaaS (Managed Instance, DTU-model, vCore, Serverless, Hyperscale) the concept of named instance does not exist. Your best option is a SQL VM where you can run SQL Setup and install multiple instances.
It seems you need it for development purposes, then you may want to install SQL Server Developer Edition to avoid licensing costs as mentioned here. If this will be a Production server, remember to balance memory usage across the two SQL Server instances and leave some memory for the operating system to avoid impact on the server performance.
Related
When we create azure SQL on VM resource it seems that we are getting VM with full control and this resource is displayed both under VM and SQL services, but there has to be some difference between these two.
VM on SQL is intended for running of SQL server, but technically if we are getting VM then we should be able to install whatever we want on that VM? If this is the case, then we could turn this VM to be multi functional and make it to be the same as provisioning regular VM and installing SQL server manually.
If this is not the case and we are not getting full control, then it seems that this shouldn't be categorized as IaaS and shouldn't be marketed that way.
One obvious difference is in deployment models, with SQL on VM we are getting pre-installed SQL server with additional features like automated backups, etc.
Probably there is some difference in pricing models, but other then this I couldn't find any mentions about these two services.
SQL Server on Azure Virtual Machines provides full versions of SQL Server and simplify licensing costs when you pay as you go.
You are correct, SQL Server on Azure Virtual Machines provides additional benefits like Automated updates, Automated backups.
https://learn.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/sql-server-on-azure-vm-iaas-what-is-overview
When using SQL Server on Azure Virtual Machines you pay the per-minute licensing rate of SQL Server. The SQL Server license fee is included in the virtual machine image price.
https://azure.microsoft.com/en-us/resources/knowledge-center/how-do-i-license-sql-server-in-azure-virtual/
Microsoft Azure sends invoice with SQL License fee each month.
The question: Is it possible to point a view in database A running on Azure SQL Database service to tables/views on a SQL server running in a VM? I've tried external tables but come up short.
Scenario:
Two applications that is exchanging data, from two different vendors.
We've got three databases in total. One for each application and an integration database with views that both applications use either directly or through views.
The issue now is that we want to migrate to Azure and would prefer to use the Azure SQL Database service as much as possible, but one of the applications is not ready for it and therefor it's database has to be hosted on either a managed instance or in a VM.
The issue now is that there's view's in database A (running on Azure SQL Database service) that points to views and tables in the integration database, which again references tables in database B (running on SQL Server on the VM).
The short answer is "no". You can use external tables to query other SQL Azure databases, but there is no exact analogue for linked servers in Azure SQL Database. You can use SQL Azure Managed Instance (which supports SQL-SQL linked servers but not arbitrary linked servers).
There is a workaround, however. You can run SQL Server in an Azure VM and have it point to SQL Azure as a target as well as the other sources you want to connect. Then you can push data to/from Azure SQL DB using the SQL Server in a VM. You don't have the same management overhead in this approach since you don't really need to host data in the SQL Server if you don't want to do so. Note that this will be slower than doing direct connections to SQL Azure, but you can try to do this for a period of time if it would help you during a migration.
As the graph shows above. Which type of sql server edition is for the production? I know the "Developer" version is for the development. Also I already got the Azure VM and have the "Developer SQL Server" on my VM, how can I install the production SQL Server in my VM? Is this free?
My purpose is to make a production SQL Server database. Is there two options for me? One is install a production SQL Server in my VM, another is to create a new Azure SQL database. Which one would be the best way to do this?
As the graph shows above. Which type of sql server edition is for the
Production? I know the "Developer" version is for the development.
Also I already got the Azure VM and have the "Developer SQl server" on
my VM, how can I install the production sql server on my VM? Is this
free?
Developer is not licenced for production - you aren't allowed to use it for production purposes.
Express is licenced for production but if your database gets bigger that 10Gb then it is unsuitable for your use
My purpose is to make a production sql server database. Is there two
options for me? One is install a production sql server on my VM,
another is to create a new Azure SQL database. Which one would be the
best way to do this?
"Best" doesn't mean anything. What are your constraints? Are you creating a brand new database? What tools will be connecting to and using the database? Does it need to be accessible from the internet?
If this is a brand new application / database, and you have limited capability for maintaining a VM then I definitely recommend using SQL Azure instead of a VM
Most importantly, and based on you other question, make sure you understand the term "Production"
Can Azure SQL Server on VM be the production database?
For example, you usually don't provision a 'production' environment without also provisioning at least a dev environment.
It would also help to give us some background on "My purpose is to make a production sql server database". It sounds like this is a request someone has given you but maybe you don't fully understand the term 'production'
None of them are sql azure. They are all sql server on premise on a virtual machine on azure.
If you want to add a sql server azure, you go on your main azure portal page, then on the left panel at the top "create a resource", then chose "SQL Database" on the popular column. Then follow instructions.
If you want as less pain as possible, clearly choose sql azure instead of a sql server on premise on a virtual server on azure. It is by very far the only reasonable choice if you work on azure: cheap, strong, backup automatically done, disaster recovery extremely easily applicable without any prior setup, extremely easy to up size its capacity in case of overload, perfectly secured without any prior setup either.
The only problem of this is the security: it can be accessed only by recognized IP addresses that you mention on the azure portal. So typically, you mention the IP address of you development computer. If your website is on your azure subscription as well, you don't need to worry, it will go through the azure firewall with no setup.
If you reeeeeeally want to use a sql server on premise, well, don't use the developer edition. If you want to avoid performance and load issues, don't use express. The entreprise is very complete, but not useful in most of cases for simple application (like web applications).
If you want most of features, go for the Standard edition, if you want to keep focused on the database engine for your web application, go for the Web edition.
Finaly, if you wanna have a licence free edition on a virtual server, the express is free of charges, but not powerful and extremely limited. The developer edition is free of charges as well and contains every possible and impossible features of sql server. The only pb of this edition is that you are not allowed to use it in production. Only for tests and developments.
As you are already having Azure VM with Developer edition installed you can go for either of the below options.
If you are comfortable to manage the Azure VM yourself, go for IAAS(Infrastructure as a Service) approach: Install SQL Server Standard Edition or SQL Server Enterprise Edition (based on your application needs). Read the capability difference between them. If SQL Server Express edition would be suitable for your needs, then install the same. It does have limited features and many constraints. See the scalability support for different editions in the same link above.
If you want to offload the database server management, go for PAAS(Platform as a Service) approach: Create a Azure SQL database and point your application to it. Azure SQL database is more like SQL Server Enterprise Edition with some limitations like CLR not being supported. Read Azure SQL database differences with SQL Server editions
I need to host a web application in IIS in Azure, if I take a virtual machine with Windows 2012 standard, how do I install SQL Server? Or is there any other option?
Getting most out of the Azure platform, I would suggest to use Azure Web Apps and Azure SQL Databases for that.
Using VMs only make sense, if you need control over the underlying systems (e.g. OS settings, Advanced SQL Server features like SSRS).
If you are going to use AZURE make sure you read a little about what you can and cannot do on AZURE. For example there is no SQL Server Agent or global temp tables. I like the requirement that all tables require a clustered index. You may not.
Here are two articles that list some of the differences but these are an incomplete list:
https://blogs.msdn.microsoft.com/azureedu/2016/07/15/what-features-are-not-supported-in-azure-sql-database/
http://www.sqlservercentral.com/articles/Azure+SQL+database/143076/
To install SQL Server on Azure follow this:
https://learn.microsoft.com/en-us/azure/virtual-machines/windows/sql/virtual-machines-windows-portal-sql-server-provision
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)