Sql Server Express 2017 Versions
Natalie Omahony
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!
Amazon RDS supports several versions and editions of Microsoft SQL Server. The following table shows the most recent supported minor version of each major version. For the full list of supported versions, editions, and RDS engine versions, see Microsoft SQL Server versions on Amazon RDS.
For information about licensing for SQL Server, see Licensing Microsoft SQL Server on Amazon RDS. For information about SQL Serverbuilds, see this Microsoft support article about Where to find information about the latest SQL Server builds.
With Amazon RDS, you can create DB instances and DB snapshots, point-in-time restores, andautomated or manual backups. DB instances running SQL Server can be used inside a VPC. Youcan also use Secure Sockets Layer (SSL) to connect to a DB instance running SQL Server, and you can use transparent data encryption (TDE) toencrypt data at rest. Amazon RDS currently supports Multi-AZ deployments for SQL Server using SQLServer Database Mirroring (DBM) or Always On Availability Groups (AGs) as a high-availability, failover solution.
To deliver a managed service experience, Amazon RDS does not provide shell access to DBinstances, and it restricts access to certain system procedures and tables that requireadvanced privileges. Amazon RDS supports access to databases on a DB instance using any standardSQL client application such as Microsoft SQL Server Management Studio. Amazon RDS does not allowdirect host access to a DB instance via Telnet, Secure Shell (SSH), or Windows RemoteDesktop Connection. When you create a DB instance, the master user is assigned to thedb_owner role for all user databases on that instance, and has alldatabase-level permissions except for those that are used for backups. Amazon RDS manages backupsfor you.
A production DB instance should use Multi-AZ deployments. Multi-AZdeployments provide increased availability, data durability, and faulttolerance for DB instances. Multi-AZ deployments for SQL Server areimplemented using SQL Server's native DBM or AGs technology.
If your AWS account has a default VPC, then your DB instance isautomatically created inside the default VPC. If your account does nothave a default VPC, and you want the DB instance in a VPC, you mustcreate the VPC and subnet groups before you create the DB instance.
By default, DB instances are created with a firewall that preventsaccess to them. You therefore must create a security group with thecorrect IP addresses and network configuration to access the DBinstance.
The following table shows the maximum number of supported databases for eachinstance class type and availability mode. Use this table to help you decide ifyou can move from one instance class type to another, or from one availabilitymode to another. If your source DB instance has more databases than the targetinstance class type or availability mode can support, modifying the DB instancefails. You can see the status of your request in the Eventspane.
For example, let's say that your DB instance runs on a db.*.16xlarge with Single-AZ and thatit has 76 databases. You modify the DB instance to upgrade to using Multi-AZAlways On AGs. This upgrade fails, because your DB instance contains moredatabases than your target configuration can support. If you upgrade yourinstance class type to db.*.24xlarge instead, the modification succeeds.
SQL Server Standard Edition uses only a subset of the available processors if the DB instance has more processors than the software limits (24 cores, 4 sockets, and 128GB RAM). Examples of this are the db.m5.24xlarge and db.r5.24xlarge instance classes.
If you have a scenario that requires a larger amount of storage, you can usesharding across multiple DB instances to get around the limit. This approachrequires data-dependent routing logic in applications that connect to thesharded system. You can use an existing sharding framework, or you can writecustom code to enable sharding. If you use an existing framework, the frameworkcan't install any components on the same server as the DB instance.
To use these features, we recommend that you install SQL Server on an Amazon EC2 instance, oruse an on-premises SQL Server instance. In these cases, the EC2 or SQL Serverinstance acts as the Master Data Services server for your SQL Server DB instanceon Amazon RDS. You can install SQL Server on an Amazon EC2 instance with Amazon EBS storage,pursuant to Microsoft licensing policies.
Because of limitations in Microsoft SQL Server, restoring to a point in time beforesuccessfully running DROP DATABASE might not reflect the state ofthat database at that point in time. For example, the dropped database istypically restored to its state up to 5 minutes before the DROPDATABASE command was issued. This type of restore means that youcan't restore the transactions made during those few minutes on your droppeddatabase. To work around this, you can reissue the DROP DATABASEcommand after the restore operation is completed. Dropping a database removesthe transaction logs for that database.