Re: SQL Server 2005 Standard Edition .rar
Blair Capellas
Mostly no, it isn't dangerous, but it depends on which version of SQL Server you are talking about, what parts you are using (just the DB engine?, SSIS?, SSRS?, ...) and your level of aversion to the small risk.
Developer edition is essentially Enterprise edition under a different licence. The problems you could hit are that some features might not be enabled in your production, standard edition, installation that are present in your development environment.
If you are using SQL Server 2016sp1 or above then this is unlikely to be a problem at all: almost everything is available to all editions. If you are using an older version then there might be differences to watch out for. For instance table level data compression was not supported outside enterprise (and developer) editions before 2016sp1 (including the original release of SQL Server 2016). The risk here being that one of your devs may make use of a feature that is not enabled in production. To see which features this affects, check MS's editions documentation: 2012, 2014, 2016, 2017. The risk here is small, and can be mitigated with care.
You could also go the other way: if you don't specifically need greater feature set and your dev environments don't have the data size to need more RAM than it will make use of, make your devs use Express instances then you know they won't use anything that won't be present when you deploy to Standard!
The differences beyond features between the editions and licensing options are how much RAM and how many CPUs/cores are supported. Unlike feature differences this will not cause your code to fall over because things are missing in production that are present in development, but it might cause performance differences. So again, the risk here is small. The same editions comparison pages listed above include this information also.
In any case, even if you use Developer edition for general dev, I would recommend using Standard edition in your Test environment because you want Test to be as close to Production as possible. Furthermore, matching versions and service pack levels, even if you don't match editions, is strongly recommended where possible.
Developer Edition is equivalent to Enterprise, not Standard. So you could run into performance differences in Prod that you didn't have while testing in Dev. This is a good article but basically it's like having enterprise in dev and standard in prod, which I wouldn't want personally.
I need to install SSRS for report development and deployment. I don't work with it myself and I haven't had much luck trying to find the information I need. My boss would like me to install SSRS 2019 Enterprise Edition. It looks like there is just one download for SSRS 2019. Here are the questions I have.
Our situation is the following. If the SSRS 2019 features are internal and not dependent on the SQL Server version, we'd like to host the reporting services databases on one of our SQL Server 2017 Enterprise servers instead of installing a SQL Server 2019 Enterprise Edition server just to host reporting services database.
We've looked around trying to find these answers but despite a lot of MS's documentation getting a lot better, SSRS is still somewhat vague in their wording. I'd really like to not have to do this multiple times trying to get it right. Any help would be greatly appreciated.
SSRS 2019 is part of SQL 2019, there is no separate licensing for SSRS, bu it requires SQL 2019 license, ie, SSRS 2019 standard requires SQL 2019 standard or enterprise and SSRS enterprise requires SQL 2019 enterprise; you don't have to install SQL 2019 if you don't use it, install SSRS 2019 enterprise on 12-core box requires 12-core SQL 2019 enterprise licenses. I use SSRS 2017 and the reportserver database is on SQL 2016 and it works fine. Not sure how Microsoft checks the edition is standard or enterprise, though.
Are you planning on scaling-out your deployment - if not, then I see no reason not to host everything for SSRS on the same server. It has to be licensed the same anyways so the only disadvantage would be system resources - which are quite minimal for the actual databases.
As far as I can tell - the version of the database engine won't be a problem, but the Edition will be...for SSRS Enterprise the databases will need to be installed on an Enterprise instance of the database engine.
It's one of the few things that I was actually able to find but everything else was not clear at all, at least not to me. For instance, if there is only one download for SSRS 2019, how does it know if it's Enterprise or Standard?
We're also keeping the SSRS server separate from the database server. We don't want issues with configuration problems to affect the production box. The person working with SSRS had already had issues that caused him to uninstall and reinstall SSRS to fix a configuration issue and that would not be a good thing on our production box.
You can use Standard Edition to support the databases for Enterprise SSRS, but it doesn't save you anything since you already have to license the SSRS instance at Enterprise Edition prices (with SA if you want to be able to install PowerBI Report Server).
Since you are keeping this separate from production and you don't appear to have any requirements to scale-out your deployment, then I would not host the databases on that (or another) server. Install the database engine and reporting services on a single system - which makes the installation and configuration much easier to manage and maintain.
You don't have to 'spin' up another server to host SQL Server 2019 Enterprise Edition - but you do have to 'spin' up a new server to host SSRS 2019 and that must be licensed the same. Because you have to license it anyways - installing the database engine and reporting services on the same machine requires the exact same licensing.
Great point about putting SQL Server on the SSRS box since the licensing cost is the same. And we're not concerned about scaling out at this point since this will be for a small group of users. Thanks Jeffery.
Main differences between web and standard are the max memory and max number of cores. Both web and standard version don't have the possibility of online indexing, this is only possible in the enterprise edition.
For a database size having a size of around 200GB, the web edition looks to be ok. But this depends also on the workload of the database, are just some users querying this database or is this database used by thousand of users.
This is leading to confusion for SQL Server customers. It would be better for Microsoft to update the documentation to reflect that SQL Server Standard is NUMA aware. Perhaps add an additional footnote, as they have footnotes for other features in that same section.
We are in FEBR 2022 and they have not changed a thing in the documentation where the compare all the versions. -us/sql/sql-server/editions-and-components-of-sql-server-version-15?view=sql-server-ver15
I just ran a test on SQL Server 2012 and upgraded from Developer Edition to Enterprise Edition on a test instance, and I still had version 11.0.3431 (Service Pack 1, Cumulative Update 10) after the upgrade.
I went through the hell of doing that same technique of mdf/ldf swapping after an uninstall/reinstall on hundreds of servers, and I still remember that queasy feeling! It worked though, even if it took years off my life.
After two databases failed to restore to the new instances, I learned that the error message means they are using Enterprise features not supported by Standard edition. The DMV query shows that the compression feature is enabled on the 2008 R2 server for almost every database there, and the new instance error log indicates that is the problem with these two databases. A specific table is named for each database.
I tried tips from various articles and technet. The commands from this one ( -compression-using-the-sql-server-vardecimal-storage-format/) seemed promising, since the logs told which tables had data compression.
Most people typically script this out with a command on an index-by-index basis so that the work can be done in smaller chunks. (Rebuilding all the indexes on a large table can sometimes fill up transaction logs and be painful.)
Books online has some sample syntax here (bottom of the page): -us/library/hh710073.aspx. You could do some scripting to identify all the compressed indexes in a database and generate commands to rebuild them with no compression.
The first thing I would do in that case would be to query sys.partitions for the database and make sure that the data_compression column really does say NONE for each row in the table. If not, you can use that to track down the culprit.
Thank you again for pointing out those resources, Kendra, everything seems to be working well now. Of twelve application databases, it turned out only 3 vendor and one utility database were using data compression.
I modified my test and utility databases and tested that they restore and attach properly to the 2008 R2 Standard instance now from fresh decompressed backups. I have disabled data compression on the last two databases and will test more with the application team before moving those to the new instance.
Ah! I never replied.
We were out of IPs.
However, it went quite well. Put one in maintenance mode, upgraded and rebooted, etc. I would have been much more concerned had I been doing more than an edition upgrade. I just left the other instances alone, and turned them off.
Hi Kendra,
In my environment, my assignment below:
upgrade database server from sql server 2008 R2 enterprise edition to sql server 2014 standard edition.
My manager wants to know my feedback on it. will here any situation can happen for the enterprise to standard edition. What are those? And please let me know all about the scenario to done that? I will highly appreciate for that. Thanks