Deleting individual historian partitions?

[Eric_G]

I'm preparing to move the historian database to another machine. I'd like to reduce downtime by copying over as much of the historian data as possible beforehand.

My plan is to copy the database to the new system, then on the running system, drop sqlt_data_1_yyyymmdd tables not from 2025, and remove rows from the sqlth_partitions table referring to those dropped tables.

Then when we're ready to switch over, I'll again copy the (much reduced in size) running database and restore it on the new system and get it online.

Later, I'll restore the missing tables using the first copy and add their rows back into the sqlth_partitions table.

Will this work?

[hunterdg]

I feel like purging the partition pointers isn’t necessary. Otherwise - seems reasonable (but unsupported I imagine) - test it first of course

[pturmel]

This topic might help:

Tag History Migration Best Practices? Upgrading to new servers!

If you are allowed downtime, it is as simple and making the new database connect just like the old database, using the same database connection (just update the driver ahead of time). MariaDB slots in as a replacement for MySQL quite nicely. Switch to DNS names in the connection URL before old shutdown if you are going to change IP addresses--make that DNS name point at the new DB before new gateway startup/restore. So: Switching to DNS name for DB connection and put in mutually compatible…