Sql Server 2017 Express Iso
Ashlie Hagenson
I tend to look at it the other way around. Supporting a database takes effort to test. So any company would want to choose the databases that most of their present and future customers would use. I don't see many SQL Server Express databases in enterprise data centers.
However, I would have to image that there are numerous smaller or younger companies that don't want to put out the expense for a standard SQL Server, Oracle etc. SQL Server Express allows up to 10gb per database and works well for smaller environments. Requiring a relatively expensive database platform increases the base cost of Jira considerably.
True, but they may want to move to SQL Server Standard or Enterprise as they grow. This would provide flexibility for budget, etc. They may also have SQL Server in their environment for other applications.
Anway, I know there are other options. I just don't understand any technical reason why it is not supported. If there is a product positioning, marketing or other reason, I would just like to understand.
I don't think it's marketing or positioning, or even technical, just about reach and cost. To fully support a database, Atlassian have to commit to fully testing the applications on it. I suspect only a small amount of the user base is interested in MS SQL Server Express, so there's very little point in investing in support for it.
I don't have any numbers but do see that SQL Server Express is used in third party applications quite a bit. They use it and deploy their solutions with it to keep the cost of their solution to a minimum. If they have customers with mid to large data or processing power needs, they step up to another version of SQL Server.
My guess is that your comment and Matt's comment above are correct and it is a testing issue. However, I have never run into an issue running something on Standard or Enterprise that won't run on Express. When I say that I'm taking about stored procedures/TSQL, etc. I would doubt that their is anything in Jira that takes advantages of features not found in Express. If JIira use SQL Server Agent or SSIS, that would not be available in Express. I have not seen that it uses either of these capabilities as they would not be available in other database platforms.
"Starting with SQL Server 2012, these memory limits are enforced only for the database cache (buffer pool). The rest of the caches in the SQL Server memory manager can use much more memory than is specified by these edition limits. For example, a SQL Server 2012 Express edition can use only a maximum size of 1.4 GB for its database cache. Other caches (such as the procedure cache, the metadata cache, and so on) can consume memory up to the size specified by the "max server memory" configuration."
I'm doing overall upgrade planning on our infrastructure and saw SQL Server 2014 SP3 will get out of mainstream support in july 2019 identified which systems still run this version, Backup Exec server being one of them. Even if the extended maintenance support continues, MS will definitely limit their efforts for 2014 in favour of 2016 and newer. Thus I'd like to get all our DB instances upgraded in time - where possible to the same versions on the whole infastructure so that we have to keep an eye on less software version to keep patched and maintained.
The BE 20.3 admin guide mentions SQL Server 2014 Express SP2 as minmum requirement, however I haven't found an indication what newer versions of SQL Server (Express) are supported for the BKUPEXEC instance.
Ideally I'd like to upgrade to SQL Server 2017, then again if Veritas doesn't support new SQL Server for the BKUPEXEC instance it wouldn't be worth the effort. Hence my question about what versions are actually supported by Veritas in this case - and where I can find about.
Refer Backup Exec software compatibility list . Check the backup exec database repository section under Backup Exec Feature specific compatibility. This lists all supported SQL version on which BE can host its database.
If your company plans on migrating from SQL 2014 globally to 2016 or newer, currently upgrading a SQL instance installed and used by BE isn't going to be easy even possible right now. After some time working with the Veritas support I thought I could share some details nonetheless:
It's really disappointing to realize that in 2019 with the new BE 20.4 Veritas still ships SQL 2014 32-bit while BE itself has been 64-bit only since BE15 (that's 2 major releases by now). SQL Server 2014 is the last version made available for 32-bit at all and reaching end of mainstream support this year. All newer SQL Server releases are only made available in 64-bit editions. At some point Veritas will *have to* provide a working and supported upgrade path for its customers.
So far I've not been pleased with the Veritas support engineers who at some point even wanted to talk me into SQL 2017 wasn't supported (contradicting the SCL) or that they'd support SQL 2014 with BE even after MS ending mainstream support for 2014. (Veritas cannot backport fixes into MS SQL 2014, this would be possible with an open source DBMS)
Warnings ahead if you intend to upgrade the default BKUPEXEC instance:
Your only way to migrate any given MS SQL 32-bit instance according to Microsoft is to export/import or attach/detach from the old to a new instance at some point. At some point the software on the other end needs to know about possibly changed connection parameters.
In the case of Backup Exec the article I've been pointed at ( _US/article.100001771) has not worked for us. beutility at some point in the process detaches the BEDB database from the old install yet fails to re-attach onto the new instance. The end result was that the database was not attached to neither the old, nor the new instance and BE services would not start.
Had I not taken a DB dump with beutility before the attempt, would have resulted in further disruption of services. In our case the restore of the DB with beutility worked but the was left with the DB wrong owner of teh DB ending up in ODBC connectivity errors thrown by Backup Exec.
If there is anything that I can share going forward I'll try to update this thread. For the moment I'd not encourage attempting the upgrade of the SQL Server instance used by Backup Exec if it is the default 32-bit 2014 version.
If nothing has changed between last summer, it means that they are still deploying an outdated 32-bit SQL DB with their current product. This was the case with 20.5 still. I haven't checked if they have in the meantime finally started offering a real migration guide. We really wanted and needed to get rid of SQL 2014 bach then in order to get rid of old releases.
Thank you for the heads up, just wanted to clarify is it safe for us to upgrade our current SQL database from 2012 x64 to atleast SQL 2014 x86 (included from the 20.4 installer) or better to install x64 SQL as well?
Sorry for asking it here as it's a pain to talk with the veritas support, we are planning to migrate our Backup exec from an old server to a new one but we can't proceed with it using the backup exec migration assistant as we are having errors with SQL permission and SQL compatibility, found out that the installer only includes a SQL 2014 x86, so I'm thinking if we can update the SQL 2012 from the source to atleast 2014, we might also get rid of the perms issue? cause for some reason we are also getting no access permission to the database even though the same service account was used.. I was sitting with the support for a few hours and we were not able to fix the issue at all, hoping for a reply and advance thank you!
We are about to roll out a dual web/internal transactional application where each client has their own database. Each database is very small - under 50MB each, so we were wondering if it would make sense to use SQL Express 2008 instead of the full SQL Server.
This seems to have the advantages of distributing disk I/O across servers while saving massive $$$ (since small 15K drives and used dual core servers are both inexpensive). If at some point we need too many servers, we can upgrade to SQL Server ... but with dozens of internal users this just seems too expensive right now (particularly since we'd need a failover box).
SQL server likes lots of RAM. The more the better. As the SQL Server can't load data into cache that'll put additional load on the disks. You should look at the Web Edition or Workstation edition of SQL Server. Those editions have higher limits than the Express edition, but cost less than Standard Edition.
We have used SQL Server Express for quite long, and its good and much better then earlier MSDE, we have more then 200 simulatenous connections, but we only have one database of size 2GB, and everything is smooth. We never had any problems provided we avoid expensive joins and we do good indexing. Now we are using SQL Standard, but till your database size is more then 4GB and your number of users are less then 200-500, you can certainly live with SQL Express.
What is your plan for backups? You don't have to use the SQL Agent but it sure makes a DBA's life easier. You could write T-SQL/SMO/PowerShell/whatever scripts that do your backups and then execute via sqlcmd or PowerShell using a Scheduled Task.
What is your plan for database maintenance? Over time, those databases will need to be defragged and checked for consistency. Standard Edition has all kinds of goodies to make this e-a-s-y whereas, in Express, you have to work (again with the scripting and scheduled tasks).
d3342ee215