I have a SQL box and a web box; the SQL box is close to capacity. I'd like to install reporting services and thought about installing it on a SQL instance i would install on the web box, and only use that instance for reporting services. Is this a good option? What pitfalls will I have if I try to do this?
It's recommended to not mix IIS and SQL on the same box. Because 0f different access patterns and security at least.
The fact your SQL box is close to capacity should set alarm bells ringing and big red flags waving. The Report Server databases are quite small, and I'd lie awake at night if I thought it would overload my your DB server
SO: Should SQL Server be on the same machine as your IIS installation?
If you just install the Reporting Services (SSRS) web piece this should be fine. SSRS comes in 2 sections, the web piece and the database catalog so you could have a web site run on the web server and the catalog database would live on you normal database server. You will need to manually configure SSRS through the SSRS configuration utility and specify the remote server name during the database set up.
The downside of this is that you would be required to purchase an additional SQL license for the web server, since an SSRS installation counts as a SQL instance, but you should be able to use a standard edition license to for both instances.
I didn't find a lot a great resources but the steps would be like this:
--install just SSRS (and Client tools to debug connection issues) on the web server
--run the SSRS configuration tool and configure the app pools, virtual directories
--in the same config tool in the database section just specify the remote SQL server and select "create database" and it will create the database for you and apply the permissions needed to the database instance.
One thing I have found to be kind of quirky about the SQL 2005 SSRS config tool is that you have to "apply" changes when it doesn't seem that intuitive, so beware.
Here's an OK link:
http://www.databasejournal.com/features/mssql/article.php/3573361/SQL-2005-Reporting-Services-Part-1.htm
Related
I'm currently working on a enterprise that uses TFS 2017, and we pretend to upgrade to Azure DevOps. So far I'm just studying about how to implement this TOOL. I'm new on devops things and I have these following doubts... Why do we need SQL Server to install DevOps Azure? What kind of information are stored in there?
In the server configuration wizard, I have the option to select an existing database to use for the Azure DevOps Server that's being deployed... Can I select the currently database that's used by TFS 2017?
Azure DevOps Server and Team Foundation Server store just about everything in massive SQL Server databases.
The main server configuration is stored in the tfs_configuration database and each project collection is stored in a separate database The default is tfs_defaultcollection.
The collection database holds all version controlled files (TFVC and Git), all work items (Product Backlog, Sprints etc), Test Cases and all test run attachments, your Pipelines, Builds and Releases as well as all of the artifacts produced by these pipelines.
These databases can grow considerably.
Whether you can keep your current database server depends on what version you're currently running. SQL Server 2016 SP1+ happens to be supported by both Azure DevOps Server 2020 as well as Team Foundation Server 2017. You could keep using that for the upgraded installation.
But my recommendation would be to install SQL Server 2019, you'll get all of the performance and security benefits of the new server, support for the latest Windows Server platform, as well as a support window that matches your new Azure DevOps Server installation.
You can find the SQL Server compatibility matrix for TFS/ADS here:
Azure SQL Database and SQL Server
TFS 2017 was one of the last versions to require a database for the Warehouse, which is a form of replicated data. Reports can be written to pull data from the warehouse, without impacting the user experience. The database is somewhat deprecated now, especially for reporting. Microsoft promotes the use of the API to pull data from the live database. TFS does however still need its "live" database to store all of the data presented to users. These will be work items, discussion comments, project templates, user mappings to AD, amongst other things.
You will need to upgrade your 2017 Schema to conform to the new standard as defined by Azure, which will be taken care of as part of the upgrade.
What kind of information are stored in there?
Issues, templates, build results, lots of things.
Can I select the database that's used by TFS 2017?
Yes, that will be upgraded during the installation.
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 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.
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)
When I try to install the Reporting Services on a second node of a failover cluster, I get the following error message:
Existing clustered or cluster-prepared instance failed. The instance selected for installation is already installed and clustered on node 2.
But, we never installed it before. Does anyone have any ideas? This is on Windows 2008 server 64-bit.
Just one thing though. You have to install Reporting Services using the Enterprise Edition media and to avoid doing all kinds of nasty stuff to the Licensing the fail-over cluster also have to be Enterprise Edition.
If you try to do this using the SQL Server Standard media you will not be able to install SSRS to a "Shared Database" and the encryption information in the database created by instance #1 will be mercilessly blasted into oblivion.
This will result in instance 1 of SSRS not working while instance 2 (on the second server) is working. Trying to fix this will only flip the situation.
Personally i find this to be quite the bummer from Microsoft since it practically means that you have to weigh the cost of Enterprise Edition against HA-enabling Reporting Services.
So basically, you have to acquire Enterprise Edition if you do not want your Reporting Services to be the Single Point of Failure.
Apparently, SQL Server can be installed on each node on a failover cluster. The caveat is that it must be two separate installations with two different instance names. You can, however, share the same report server database. Please read this article for more information on deploying Reporting Services.
http://msdn.microsoft.com/en-us/library/ms159114.aspx
Consider this article on SSRS scale out process. Install the shared report server database on the cluster. Then install reporting services to use the shared database. Reporting services will not failover, but the database will.
This is an option to failover IIS: http://support.microsoft.com/kb/970759