Our current Reporting and analysis server for TFS 2015 is SQL 2012 Standard. I would like to upgrade to SQL 2016 Enterprise (Join our current 2016 Enterprise environment). What would that process be and will there be any historical data loss?
Is it as simple as remove the configuration for Standard and the point it to the new Enterprise server and then let it rebuild the warehouse and the cube?
outside of the time it takes to rebuild, will I loose anything?
First, check your versions.
TFS 2015 RTM does not support SQL Server 2016.
TFS 2015 Update 3 and beyond does support SQL Server 2016.
Assuming your reporting databases (TFS_Analysis and TFS_Warehouse) are on a totally separate instance of SQL server than your TFS operational databases (TFS_Configuration and TFS_<ProjectCollection>), or are going to be moved to a totally separate database instance, there should be minimal risk. You just update the reporting configuration to point to the new SSRS/SSAS servers and databases and everything will rebuild, no historical data will be lost.
If your intent is to totally migrate your TFS databases to a new SQL server version, it's a more involved process with a higher degree of risk -- downtime will be required and it's wise to do a test migration first.
Regardless, no data will be lost.
Related
I want to upgrade a SQL Server 2016 to 2019 by performing an in-place upgrade and also upgrade SSRS.
Microsoft documentation instructs me to migrate the SSRS databases.
To upgrade from Reporting Services 2016 and older versions to Reporting Services 2017 and later, follow the Migrate a Reporting Services Installation (Native Mode) article, with Reporting Services 2017 or later as your destination instance.
Is a migration necessary? If so, does that mean I should do a side-by-side upgrade of the SQL Server engine? I hoped that I could:
Clone the entire server as a backup. Run the Database server upgrade
(in-place).
Run the SSRS 2019 standalone installer.
Restore the SSRS encryption keys.
Configure SSRS to use the existing (and newly upgraded) databases.
I don't understand why I would need to follow the migration procedure? Is it just that in-place database engine upgrades are not recommended? I have some dependencies that make me reluctant to create a new server or install 2019 next to 2016.
No, the migration was not necessary. Yes, the in-place SQL Server upgrade worked.
We uninstalled SSRS 2016 and then performed the SQL Server upgrade
to 2019.
Then we installed SSRS 2019 (a separate installer, apart from SQL Server).
We restored the SSRS encryption keys. Here, we ran into an issue.
Unexpected error: This edition of reporting services doesn't support
scale out, but the database has other servers registered. We'll need
to remove those to continue. Do you want to remove the other
registered servers?
I was able to find a solution here and here. I had to delete the 2016 SSRS instance from the table dbo.keys.
The last step was to complete the SSRS configuration, and SSRS was
available.
Configuration included pointing SSRS at the existing 2016 databases
(reportserver and reportservertempdb) by selecting Change Database and choose an existing database.
The database upgrade did not change the compatibility level of the two databases.
I have both test and production enviroments with a TFS 2017 update 1 on premises running in a windows server 2012 virtual machine. In the same virtual machine is running SQL Server 2014 as TFS database. I used this configuration for 3 years without problems.
Now I want to upgrade to Azure DevOps Server 2019 update 1.1 on premises. Furthermore I want to change architecture with two virtual machines with windows server 2016: one for database tier with SQL Server 2016 and one for application tier with Azure DevOps Server 2019 update 1.1.
What is the best practice to perform upgrade above described. Maybe the correct way is to leave the original single virtual machine with TFS 2017, prepare two new virtual machine both with windows server 2016 (one for SQL Server 2016 and other for DevOps 2019) and finally perform a "move project collection" from SQL Server 2014 to SQL Server 2016. Does the move project collection works even if the source comes from TFS 2017 and the destination is Dev 2019?
Is there any official documentation provided by Microsoft about the scenario of upgrade described above?
think best approach is to setup the new VM´s (with TFS2017 and stuff), then create DB dumps of old one and integrate these in the "new" TFS2017. After i would recommend to update to TFS2018, then 2019 (AzDo Server).
Why? => In most updates there were also done some updates in TFS Warehouse DB´s and stuff.
In the past we also updated from e.g. 2015 to 2017 but had better feeling doing the updates "piece by piece" to be sure that all the Warehouse changes were done "in a clean way".
I am looking to perform a migration upgrade of our TFS 2010 instance to TFS 2013.
Our current implementation has both application and data tiers all residing on a single Windows 2008 R2 Enterprise server.
For this migration upgrade though, each tier will have its own dedicated server.
There are a few salient points I wish to emphasise though, which are:
TFS 2010 Data Tier - This is currently supported by SQL Server 2008 R2 (SP2) Enterprise Edition.
TFS 2013 Data Tier - We'll be supporting this with SQL Server 2012 Enterprise (min. SP1) or 2014.
TFS 2013 App Tier - This will be hosted on a Windows Server 2012 R2.
For the data tier migration, my intention is to obtain backups of the TFS 2010 databases from SQL Server 2008 R2, migrate and restore them to the TFS 2013's data tier which will have SQL Server 2012/2014.
My question therefore is: To perform the TFS 2013 data tier upgrade, should I follow these high-level steps:
1) Install SQL Server 2008 R2 (SP2) Enterprise Edition on the new data tier host.
2) Restore the TFS 2010 database backups to the new data tier.
3) Subject to a successful DB restore, perform an in-place SQL Server upgrade to SQL Server 2012/2014 Enterprise.
4. Install TFS 2013 on the application tier and complete the migration upgrade.
Alternatively, can I simply proceed as follows:
1) Restore the TFS 2010 database backups directly to the new data tier (SQL Server 2012/2014 Enterprise).
2) Install TFS 2013 on the application tier and complete the migration upgrade.
So basically, the question is whether I have to perform the backup and restore on like-for-like SQL Server instances initially, or whether I can restore the SQL Server 2008 R2 Enterprise backups directly to SQL Server 2012/2014 Enterprise?
Your scenario is a standard upgrade. You can use the new hardware to do a dry run first, and then wipe everything clean and use it again for the production upgrade.
For our dry run, the steps for our upgrade will be:
Copy recent database backups to new SQL instance.
Install TFS2013 on new application tier.
Use scheduled backups to restore the database backups.
Run through the upgrade wizard, being sure to use a service account
which does not have any permissions in production environment. See
Protecting production in the dry run in pre-production document for
more information.
Optionally configure new features which require changes to our
existing projects.
Useful links:
https://learn.microsoft.com/en-us/azure/devops/server/upgrade/walkthrough?view=azure-devops
I'm planning to migrate all the SSRS reports from 2008R2 server to new sql server 2014 environment. As far as migration is concerned, I was asked to take the backup of 2008R2 report server database and restore it in 2014 server.
I was not convinced with this since there may be new tables available in 2014 Report server.
The new features of 2014 cant be utilized if the old report server database is restored.
Please let me know if this thought is correct.
Are there any new tables available in 2014 report server database?
What is the best option to migrate ssrs reports from 2008 r2 to 2014 server?.
Your question is a bit confusing, I will assume you want to move the database from a Server A with SQL Server 2008R2 + SSRS 2008R2 to a Server B with SQL Server 2014 + SSRS 2014.
Are there any new tables available in 2014 report server database?
There is no official communication on it.
If you really want to know it you could do a schema compare between the 2 versions.
But do not forget to compare everything, not only tables:
Columns
Stored Procedures, Functions
...
Database structure is not the only thing to take into account, what about:
All the configuration files
Encryption Keys
...
What is the best option to migrate ssrs reports from 2008 r2 to 2014
server?.
Short answer:
My recommended way of doing it would be to use RS Scripter and generate a script on Server A with all the objects (reports, datasources, subscriptions, ...) you want to move.
Then you can restore it on Server B.
Long answer:
If you really want to migrate the full database like you were asked to do, there is no officially supported way to move the database to another SQL instance and upgrade the version at the same time.
You could try to follow the steps to Backup and Restore Operations for Reporting Services, and apply it to a newer SQL Server instance with another SSRS version, but it will be at your own risk.
The supported ways to do would be to either:
Upgrade from SSRS 2008R2 to SSRS 2014 on Server A
Move from Server A to Server B
or
Move from Server A to Server B
Upgrade from SSRS 2008R2 to SSRS 2014 on Server B
Here are the related MSDN articles for these operations:
Migrate a Reporting Services Installation (Native Mode)
Upgrade to SQL Server 2014
Again, I would advise using a tool to migrate the reports and other items instead of trying to migrate the full database.
I do not think restore 2008R2 reportserver db on 2014 will work, because the report definition schema is totally different.
I did a migration task to move 2008R2 reports to 2012. Because there are hundreds of reports on the 2008R2 server, I found the easiest way is to write some codes to read report definition, and then create on 2012 server.
From: https://msdn.microsoft.com/en-us/library/ms143747.aspx
There are two general approaches to upgrading a Reporting Services
deployment:
Upgrade: You upgrade the Reporting Services components on
the servers and instances where they are currently installed. This is
commonly called an “in place” upgrade. In-place upgrade is not
supported from one mode of Reporting Services server to another. For
example, you cannot upgrade a Native Mode report server to a
SharePoint mode report server. You can migrate your report items from
one mode to another. For more information, see the ‘Native to
SharePoint Migration’ section later in this document.
Migrate: You
install and configure a new SharePoint environment, copy your report
items and resources to the new environment, and configure the new
environment to use existing content. A lower level form of migration
is to copy the Reporting Services databases, configuration files, and
if you are using SharePoint mode, the SharePoint content databases.
If you do an in-place upgrade from SQL Server 2008R2 to SQL Server 2014, then everything should work as expected.
As part of a disaster recovery test of our TFS 2008 instance I hoped to restore our backups of the database (currently on SQL Server 2005) to SQL Server 2008.
I noticed a warning on MSDN that this could make a restore impossible.
Has this been done in the wild? What are the risks?
Your disaster recovery plan should never include an upgrade at the same time. It's prudent to make the upgrade first and then plan your disaster recovery plan. Waiting for a recovery opportunity could spell trouble.
That being said, as long as you're using the latest service packs, TFS 2008 is fully supported on SQL Server 2008 now.
Buck Hodges is a definitive TFS guru. Here's what he says:
SQL 2008 SP1 has just been released,
and we've gotten a couple of questions
about whether it is supported with
with Team Foundation Server 2008. We
tested SQL 2008 SP1 with both the
original release of TFS 2008 and TFS
2008 SP1, and we do fully support
using it with either release of TFS
2008.
http://blogs.msdn.com/buckh/archive/2009/04/09/tfs-2008-supports-sql-2008-sp1.aspx
I have performed one upgrade of TFS 2008, and we tried to restore backups to a SQL Server 2008 instance. We were also upgrading from the final beta of TFS 2008, so I can't say whether the issues we encountered were due to it being from a beta, or if it was due to the change in SQL Server versions. It turned into a minor disaster, and we ended up reinstalling TFS fresh and copied our source code into it (which luckily was fully checked out on several developer machines). We lost our source control history for a short time, but we were eventually able to get the original instance up and running again, which we kept around for legacy source control history reference.