I have data warehouse database on SQL Server Enterprise. Currently the SSIS that feeds the data warehouse is running on the same server.
I would like to move the SSIS execution on another server. What are the licensing options for SQL Server for running the SSIS? Can I use SQL Server Standard with server + 1 CAL license? SSIS runs under one service account.
Thank you.
From memory if the two instances are on a separate physical host then two licenses are required. If they are two VM's on the same host then only 1 enterprise license is required for the physical box.
Best to contact your Microsoft Rep or use the Microsoft License Audit Tool (Can't find it right now) for a definitive answer though as these things change over time.
Note: This answer applies to on-premise only, cloud etc. are special cases.
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.
I have implemented executing sqlcmd.exe to run a script (provided by hosting & ops DBAs) that copies a newly created database in the C# app that creates the database to a second server in an AlwaysOn Availability Group. Unfortunately we have no AlwaysOn Availability support in our development or integration environments so I have only been able to test executing sqlcmd to run the script and handling the script failure. Is it at all possible for me to simulate the AlwaysOn Availability Group environment on my developer workstation if a create a second SQL Server instance. I am running SQL 2014 Developer Edition at the moment but should it be required, will be able to upgrade to SQL 2016 Developer Edition.
If this is not possible we will be forced to deploy without full end to end testing and have the first end to end tests happen in the production environment.
I have fairly good developer level SQL skills; in other words I'm very comfortable with stored procedures and such but have very little knowledge of the new and advanced features for actually administering SQL servers.
You can but you will either have to create VM (Virtual Machines) using VMWare software or VMs using Microsoft (MS) technology. There are other VM products but these two are used for the majority of virtualizations of the SQL Server/Microsoft stack. If you use MS technology you can download the software for usually up to 90 days (free) without activating the software. I would do it on an SSD so it finishes in a timely basis and you probably need 12-16GB of memory on the host, developer, machine.
There are detailed online instructions on creating VMs for SQL Server on clusters. The best ones have screen shots.
I have a program that is a .net console app that is intended to track information at a few websites daily and then put this data into an SQL database.
Previously I've had this program running on a scheduler on my computer but I'm about to take off on a 3 month vacation so I'm planning on deploying it on azure to run it while I'm away.
Last night I set up a SQL server VM. I got it all set up then I tracked the pricing and realized that using the SQL Server image increased the price by about 30$ per month compared to the Windows image (http://www.windowsazure.com/en-us/pricing/calculator/?scenario=virtual-machines)
I have an SQL Server license. So I was thinking of just setting up a Windows VM and then installing SQL server on it. THe only problem is that I'm going to have to copy the MSI over and install it etc. - it would take ages.
Is it possible to just create an SQL Server VM in azure and then enter my own license in there to avoid paying the extra 30$ per month?
By the way, is there a more economical way to get Azure to do this then using a VM? Really, it just needs to run daily and performance doesn't matter.
To answer your question directly: you can only utilise your own SQL Server license on an Azure VM if your organisation's agreement with Microsoft includes License Mobility (http://www.windowsazure.com/en-us/pricing/license-mobility/). If your are unsure or believe this is not the case then you cannot deploy your own license. This is exactly the same on Amazon Web Services (AWS).
SQL Databases for Azure Mobile Services that are under 20MB are free - that may be an option depending on your needs. (see point 5 on this page: http://www.windowsazure.com/en-us/pricing/details/mobile-services/).
You can try converting the .NET console application to Worker Role (PAAS) and use Web Edition of SQL Database (PAAS), and recalculate your TCO.
You can start with the SQL Server Trial image, then apply your own license on it (as on any trial installation).
You could also have a free Azure Web Site, with your code triggered as a "web job". For DB, there is a 20MB free tier for Azure SQL Database.
Why don't you just create a SQL Azure DB. They are only $4.95/mo for DB's under 100MB http://www.windowsazure.com/en-us/pricing/details/sql-database/
Saves the entire headache of running your own SQL Server.
Update: SQL Azure now has different pricing
As suggested in the comments, use Azure WebJobs and if possible a free SQL DB if you only have very limited data to track operation.
Under 20Mb free
~$5/mo for up to 2GB
More Details: http://azure.microsoft.com/en-us/pricing/details/sql-database/
I'd like to compare Windows Azure SQL Database and SQL Server on VM. So I'd like to ask:
which SQL server edition on Windows Azure(S,M edition; Web or Standard) should I choose to compare it with Windows Azure SQL Database Web. I know that these are different concepts PaaS IaaS and so on. In my question I am referring to your experience with these two technologies and their performance. I know that it would be roughly comparison
I made comparison for Azure SQL and SQL Server Std hosted on Azure VM (Large (A3)) for 2GB database. I just copied DB from Azure to VM, so, basically, I had 2 Databases with identical data and was able to run same queries.
SQL Azure DB has known advantages, but when it goes to performance people starts crying:
Getting last 1000 transactions from ~100k transactions with many joins takes:
Azure SQL: 7:40 mins
SQLServer on VM: 2:30 mins
Getting 10 transactions with specific parameter's:
Azure SQL: 3:57 mins
SQLServer on VM: 1:05 mins
In this test I didn't care about query performance, I just want to see the difference for the same data/queries between Azure SQL and SQL Server on Azure VM. As you see, it's very differ.
Roughly, Windows Azure SQL Database is comparable to the features of SQL Server 2012 Standard Edition, but this comparison is only approximate, because each offer is meant for a different use case and offers a different balance of features.
In Understanding Azure SQL Database and SQL Server in Azure VMs you'll find a detailed comparison. Some distinctive characteristics are:
SQL Database is highly available; each database is backed by 3 servers; each operation will only be completed when it is accepted by at least 2 servers. This leads to a higher latency than SQL Server on a single server.
SQL Database runs on cloud infrastructure. Client applications must be fault-tolerant.
SQL Database runs on shared resources, so clients may experience performance fluctuations. The Premium Offer for Windows Azure SQL Database delivers more powerful and predictable performance.
SQL Database has a few limitations on support for features, Transact-SQL, Data Types and Tools and Utilities.
See also how to Compare SQL Server with Windows Azure SQL Database and the guidance on SQL Server in Windows Azure Virtual Machines.
Regarding Windows Azure SQL Database Web edition: Web and Business editions are identical except for storage capacity (see my detailed SO answer about this, here), so it doesn't matter for your comparison.
Regarding SQL Server editions, I think this is going to be primarily a difference in features and licensing, not performance. That said: If you choose the Enterprise edition, you may find more features are active, therefore consuming more resources. Fortunately the Web, Standard, and Enterprise editions are all in the Virtual Machine gallery, so you can deploy any of them without having to do a custom install.
When comparing Windows Azure SQL Database with SQL Server, you should probably start with this MSDN article which goes into detail about the limitations of SQL Database as well as T-SQL differences.
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.