Cleaning up does not mean it has to be empty. However the Action Pack has to calculate a cut-off date in order to determine which data is static (INITIAL, REFRESH step) and which is not (FINAL step).
So if you have a failed job in the process monitoring which failed 2023 then only data older than that job execution will be considered in the INITIAL step, because this execution is still in process monitoring. Clean up by deactivating old tasks from the process monitoring.
https://docs.automic.com/documentation/webhelp/english/AA/24.3/DOCU/24.3/Automic%20Automation%20Guides/Content/Installation_Upgrade/install_upgrade_MigratingAEDB.htm#link8
Original Message:
Sent: Feb 20, 2025 05:24 AM
From: Cristian Suciu
Subject: SQL Queries for UTF-8 Migration impact on Source Database
How important it is to clean up Process Monitoring?
If possible, we would like not to do that as then there will be quite an effort to put everything back there. (Schedules, Periods, Events and so on...)
Cristian
Original Message:
Sent: Feb 20, 2025 04:59 AM
From: Markus Embacher
Subject: SQL Queries for UTF-8 Migration impact on Source Database
Hi Cristian,
if you want to have a shorter downtime window, then decrease CHANGE_LOGGING_DAYS to 1 and make sure you perfectly clean up your process monitoring.
Regards, Markus
Original Message:
Sent: Feb 20, 2025 04:38 AM
From: Cristian Suciu
Subject: SQL Queries for UTF-8 Migration impact on Source Database
We just finished testing this way.
We performed yesterday the Final run of the Migration Workflow on AE on the destination.
The source and destination (TEST) are on different servers.
We executed the queries generated while the source was still active. Of course there are differences in tables due to the fact we did not bring down the source DB. But that's because processes were still executing.
Step 1 of the statements took about 7 hours and step 2 took several minutes.
We compared data and almost all of the tables were created on the target DB and data record count is very similar on all tables. With tables like OH that do not store data from runs having the same value on both source and target.
We will go ahead an perform our migration process on our DEV instance with source and target on the same host. I am also changing the parameter for Logging days to 3 from 14 hoping that it will increase the runtime of the workflow for the online mode and reducing the time for downtime. Would that be the case?
7 hours is a high number for having downtime especially that this was our DEV instance we tested on and our Production instance is much larger.
Cristian
Original Message:
Sent: Feb 20, 2025 04:29 AM
From: Thomas Steckbauer
Subject: SQL Queries for UTF-8 Migration impact on Source Database
Hi,
I was also thinking of the same migration scenario as Cristian.
Would be great if there is a chance to test all UTF8 migration steps for MSSQL without shutting down the source database or the requirement of triple storage (source db, clone, UTF8 db) ;-)
BR
Thomas
Original Message:
Sent: Feb 20, 2025 03:44 AM
From: Markus Embacher
Subject: SQL Queries for UTF-8 Migration impact on Source Database
Hi Cristian,
the FINAL step does not consider CHANGE_LOGGING_DAYS. If you do not shut down the source Automic instance, then you will run into foreign key violations because of inconsistencies.
The easiest way of getting all the timings is to create a clone of your source database and using the clone as the migration source.
Regards, Markus
Original Message:
Sent: Feb 20, 2025 02:05 AM
From: Cristian Suciu
Subject: SQL Queries for UTF-8 Migration impact on Source Database
Hi Peter,
How long are the SQL queries supposed to run for? Is there an estimate of the runtime of these queries during the system downtime?
We want to make sure that we keep our downtime to the minimum. Is there any particular settings we can change before the downtime so that we keep it as short as possible?
We kept the CHANGE_LOGGING_DAYS to 14 but I think too much data remained uncopied after the Initial and Refresh run.
Thanks,
Cristian
Original Message:
Sent: Feb 19, 2025 01:14 PM
From: Peter Grundler
Subject: SQL Queries for UTF-8 Migration impact on Source Database
Hi Cristian,
the documentation states:
According to this, you have to stop the AE system before running the SQL statements created by the final step.
I doubt that it will work as long the old system is active because the SQL statements are like this:
insert into [AH] select * from upgrade.dbo.[AH] where AH_Idnr > 2555050;
insert into [RH] select * from upgrade.dbo.[RH] where RH_AH_Idnr > 2555050;
insert into [RT] select * from upgrade.dbo.[RT] where RT_AH_Idnr > 2555050;
Suppose, the entire SQL command sequence will run for some minutes. If AE is still active and creates new entries in the database, you will miss these new records from tables you've already processed and copy them from INSERT statements that are still waiting to be executed. This sounds like creating an inconsistent target database, right?
best regards,
Peter
------------------------------
Automic Certified Professional/Expert & Broadcom Knight
For AUTOMIC trainings please check https://www.qskills.de/qs/workshops/automic/
Original Message:
Sent: Feb 19, 2025 04:58 AM
From: Cristian Suciu
Subject: SQL Queries for UTF-8 Migration impact on Source Database
We have tested the whole migration workflow from the source of our DEV instance to a test database on a different server.
We want to run the SQL statements on the test database that is on a different server than our live DEV instance.
The question is: If we run the statements generated by the Final mode, will it impact in any way the source database (dev instance) that is still live and running jobs, or will it only do alterations on the destination database?
Thanks,
Cristian