we have three SQL servers serving a variety of applications on different webservers.
Each application is using reporting services functionality.
The average load per server per month is about 40.000 reports, taking an average of 3.1 secs to deliver a report.
At this moment the the situation is as follows:
Application A has his database on SQLServer A and is using Reporting
Services on SQLServer A. (SQL 2008)
Application B has his database on SQLServer B and is using
Reporting Services on SQLServer B. (SQL 2008R2)
Application C has his database on SQLServer C and is using
Reporting Services on SQLServer C. (SQL 2008R2).
We have just bought a new server, runnning SQL 2012.
Would it be wise to move all reporting to the Reporting Server 2012?
My idea is that there would be a significant performance-gain. Also, There would be only one reporting server to manage. But is that so? Are there penalties when running reports on one server while the database feeding the reports is on another server? Is it a problem if the Reporting Services version is different then that of the database server?
I would like very much to hear your thoughts on this.
Performance and manageability are two key-components.
Greetings and thanks for thinking with me,
Henro
Are you using the Enterprise Edition of SSRS 2012 (so that could take advantage of scale out via deploying parts of the SSRS implementation on different servers)? Here's a SSRS 2012 feature list by edition. Also, are you using any scheduled (i.e. snapshot or scheduled delivery) of reports to balance the load requests?
Related
My client has two business databases running on SQL Server 2005, together with SSRS databases (ReportServer and ReportServerTempDB), all on the same W2K3 server. My client is thinking about separate the SSRS out from the server, moving to a W2k12 R2 server, and upgrade the SSRS databases to SQL Server 2014, but with the business databases remain on SQL server 2005/W2k3 (because of $$$).
Will that be possible and is that likely to experience problems in the future?
Thanks in advance.
p.s. I should also mention there are two .NET 4.0 C# apps connected to the business and SSRS databases atm. SSRS databases are full of overnight generated report snapshots, plus ad-hoc reports generated via the apps. The SSRS db is about 80GB.
I do agree with BIDeveloper, the only way to really be sure of this is to test it. However, I can tell you from experience that so long as your report writers do not try to take advantage of new features found in the new sql server version that your SSRS instance is running off, you should be fine.
We had a similar situation where our databases were 2008r2, running on windows 2008r2 servers, but our SSRS was running on a windows 2012 server, with the SQL Server backing for SSRS was running on SQLServer 2012. - It was fine - so long as all the SSRS reports were able to run against the 2008r2 sql servers. We had a few bad report writers that tried to use sql server 2012 functions that didn't run on 2008, and those reports had errors. After the report writer fixed their mistake, the reports worked fine.
An example off the top of my head would be if a report writer wrote the following query to be executed in the report:
SELECT
TRY_CONVERT(INT, 100) [SomeConvertedInt]
FROM
<SOMETABLE>
It would work fine on their local development machine running SQL 2012, but would fail when the report was being executed on the SSRS server. To fix, they would have to remove the new 2012 function - in this case, TRY_CONVERT().
You need to create a new SSRS instance at the version you are proposing - without touching the old instance. Then do full testing.
This is the only way to prove your plan will work.
Our Application using SQL Server Enterprise Edition, BI services (SSIS,SSAS,SSRS).My customer is restricted to SQL Server Standard Edition only.
Now i have to migrate everything From EE to SE of SQL Server.
1-While deploying SSAS (Semi-Additive measures are not supported) ?
Might be i have fix this using Calculated Measures.
I am not sure about limitation with other services (SSIS, SSRS) could encounter while migration. Can somebody please help here !!!!!!
I have to move SSIS jobs,Reports Etc ...
Thanks
Veneet
The best place to start is with the docs. There are separate sections on SSIS, SSAS and SSRS. The headlines are:
SSIS
Standard does not support Change Data Capture Service for Oracle by Attunity and Change Data Capture Designer for Oracle by Attunity.
SSRS
Standard does not support Data driven report subscription, Scale out deployment (Web farms), Alerting and Power View.
SSAS
Standard does not support Scalable Shared Databases, Semi-additive Measures, Perspectives, Writeback dimensions, Linked measures and dimensions, Proactive Caching, Push-mode processing, Direct Writeback and Measure Expressions
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.
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.