Converting MSSQL to PostgreSQL for Reporting Server

[Glazarus]

Hello, 

Hoping someone can assist 

As part of our upgrade from EBO v3.2.0.59 to v6.04, we are in the process of migrating our Reporting Server Database from MSSQL to PostgreSQL. The migration began approximately seven days ago and is still ongoing.

I wanted to check the following:

1. Is there a log we can monitor using BareTail to track progress and identify any processes that may be stuck?
2. Are there any resource throttling settings we can adjust to accelerate the conversion?

Below are the current system specifications:

• Database: StruxtureWareReportsDB (505GB)
• Report Server Configuration:
  • 8 CPUs
  • 64GB RAM
  • OS: 100GB
  • Data: 900GB
  • Backup: 1TB

Your insights or recommendations would be greatly appreciated.

[Will_Workman · Accepted solution]

Last time I migrated a MSSQL Report Server to PostgreSQL with TimescaleDB it took almost 2 weeks.  And that SQL database was about 500GB too.  PSS told me that you just have to let it run.  The migration tool does know how far along it has come so if the process gets interrupted it can pick up back where it left off.  Good luck!

[Glazarus]

Hi Will, Thanks for your response mate! 

Another quick one, would it be feasible to first upgrade the reporting server with a fresh database while archiving the existing MSSQL database? Upon successful completion of the upgrade, we would then proceed with converting the archived MSSQL database to PostgreSQL. Once the conversion is finalised, we would attach this second database to the reporting server.

This phased approach would ensure both the pre-upgrade and post-upgrade databases can coexist on the reporting server.

The reasoning for this is to ensure we retain historical data without disrupting current operations.

[Will_Workman]

@Glazarus 

The migration tool needs both a live Report Server and a live External Log Storage Server to perform the migration as the tool makes connections to both the backend databases and then transfers the historical data.  Since both servers are still live, there should not be any disruption to either live system during the transfer (other than the small load of an additional client connection).  The site I transferred was up and running throughout the entire transfer without any complains from the owners.  I don't think the step of setting up another MSSQL server just for the migration is necessary.

It was recommended to me to upgrade the Enterprise Server, Workstation, and Report Server to the latest 3.2 CP before starting the migration to PostgreSQL.  At the time of writing the latest is EBO 3.2.4.7003 (CP5).

If you need to perform any maintenance or configuration tasks on the Report Server, then I recommend using the SBO Reports Agent Config Benji Tool.

I highly recommend using EBO External Log Storage Installer Benji Tool for setting up the External Log Storage Server if you have not done so already.

[Glazarus]

@Will_Workman, thanks for the information.

We're currently upgrading from EBO v3.2.0.59 to v6.04 and wanted to clarify: do we need to start the transfer while still on v3.2, or can we complete the upgrade to v6.04 first and then initiate the transfer? Also, if I understand correctly, the migration process allows continued access to reports without any disruptions, correct?

Our main concern is that the upgrade is scheduled during our EOM period, so maintaining report availability is critical.

Thanks again for your help.

[Will_Workman]

@Glazarus 

You need to migrate the data out of the Report Server to the External Log Storage server before upgrading EBO beyond v3.2.  Report Server was dropped in EBO v4.0.

Make sure you apply the latest EBO v3.2.4 CP to WorkStation, Enterprise Server, and Report Server before starting the transfer as it added extra code to support the transfer.  You do not need to apply the CP to the AS's.

Yes, you will continue to have normal access to both the Report Server and External Log Storage Server during the transfer.  Both databases need to be online for the transfer tool to work.  The transfer tool is basically just a client connection to both servers where it reads from the Report Server and writes to the External Log Storage Server.

Once the data transfer from RS to ELSS is complete, you can upgrade from EBO v3.2.4 to EBO v6.0.4.

Once the data transfer is complete, you can enable ELSS on each AS.  Do this one AS at a time (or in small batches) to prevent a huge burst of data all at once.  In EBO v4.0 and higher there is an option to merging the ES Extended Trend Log data into the External Log Storage Server bucket for the associated AS trend.  That way you can keep all of the data in one location while not loosing any history.  Once that process is done you can deleting the Extended Trend Log from the ES and clean up the ELSS buckets for those ES Extended Trend Logs.  There are detailed instructions in the Release Notes and Technical Reference Guide.

FYI, you only want to enable Events storage in the ELSS in the topmost server (EC or ES).  If you enable events in both the AS and ES, then duplicate entries will be stored in the ELSS as the child servers send event data up to the parent server.