Any tips for a clean change in partition size for tag history partitions

I have read posts documenting issues when changing partition sizes (mostly from monthly to weekly) and I would like to know if anyone has experience with doing that and avoiding issues such as having overlapping dates between partitions and potentially losing tag history data for potentially weeks before things smooth out.

Has anyone done this without a major headache?

How would you lose data?
The historian will create the new partition when the end date equals the creation date + length and then the next one will do the same but on a shorter timespan.
There should be no data loss if you use the management tools on the gateway web interface.

For example
You currently have paritions in monthly lengths
sqlt_data_2_2024_01
When the timestamp in sqlt_data_2_2024_01 hits 2/1/2024 (whatever time)
The system will create the next parition table called something like
sqlt_data_2_20240201
Which will then end in a week and the next would be
sqlt_data_2_20240208

When you change the partition size, it doesn't immediately create a new one, it continues on as originally scheduled and then on next creation starts with the new schedule.

1 Like

How would you lose data?

I don't actually know - I'm asking out of an abundance of caution after reading other posts that talk about overlapping dates and missing data.

When you change the partition size, it doesn't immediately create a new one, it continues on as originally scheduled and then on next creation starts with the new schedule.

That is useful information. I had wondered how it would work since week breaks don't line up with month and year breaks.

I forgot to come back and share what I learned in doing this. When you change the partition size based on months or years the partition parameters are predefined based on the calendar but when you use a partition size in weeks it immediately creates a new partition. That explains what was happening in the other stories I had read.

Interestingly I also learned that with weekly partitions it only creates the subsequent partition (once the current partition has reached its ending timestamp) the next time data is written so unlike monthly and yearly partitions the beginning timestamp of the next partition may not be the same as the ending timestamp of the prior partition so your "weeks" may be a week and a few seconds or minutes depending on your data collection settings.