Scheduled Downtime & Recovery Procedures

In the DB-migration scenario, when you finally click Activate on the SLT config, what does that single action create in the source — and why is that broader than in the upgrade scenario?

When recreating SLT triggers after a source upgrade, what must the configuration's state be, and which report do you run?

After a DMIS upgrade completes, there is a final step you must NOT skip before releasing the system — one that has no equivalent in a plain NetWeaver upgrade. What is it?

Why is locking users the mandatory FIRST action before deactivating an SLT configuration for planned source downtime, rather than just deactivating directly?

After locking users but before deactivating an SLT config for downtime, why do you wait a few minutes and re-check the logging table instead of deactivating immediately?

When running View Unprocessed Logging Table Records to confirm the logging table is drained, why sort the output descending rather than accepting the default order?

In the source-upgrade scenario, which transaction drops the SLT triggers in the source system, and what is the key precaution when doing so?

After deleting SLT triggers in the source system via IUUC_REMOTE, what validation step confirms the deletion actually succeeded?

The book warns that for tables whose triggers were dropped during an upgrade you must "restart the loads from scratch." When is the reset-flags-and-continue-delta approach valid INSTEAD?

After an upgrade may change table structures, which report finds mismatches, and across which three systems does it compare?

The Resolve Inconsistencies between Proxy Table and Target Table report fixes structure mismatches — but which structure does it NOT modify?

The DMIS-upgrade scenario adds a version-compatibility rule absent from a plain NetWeaver upgrade. What is the rule between the SLT and source DMIS versions?

In the DMIS-upgrade scenario, dropping the source triggers is described as CONDITIONAL, unlike the plain source-upgrade scenario. Under what condition do you drop them?

Why does the target-SAP-HANA-patch scenario NOT involve dropping or recreating any triggers or logging tables in the source?

In the target-HANA-patch scenario, which connection test you run depends on HOW the target is connected. What are the two cases?

In the source database-migration scenario, what happens to the SLT logging tables and triggers during the migration — and why does this dictate a different recovery than an upgrade?

Which transaction and report drops the migrated SLT logging tables in the source after a database migration, and what makes this step dangerous?

The on-premise-to-private-cloud transition adds a recovery step that none of the pure-upgrade scenarios need. What is it and why?

Contrast the on-prem-to-cloud transition with the source database-migration scenario: why does one require dropping/recreating logging tables while the other does not?

When switching replications from SLT system A to system B, what must you export from system A first, and with which transaction?

In the SLT A→B switch, why set Refresh Behavior to "No Action" in LTRS on system B before starting replication, and when is this setting appropriate?

During the SLT A→B switch, after configuring system B, which Data Provisioning action creates the logging tables and triggers in the source — and how does it differ from what starts the actual data transfer?

During the A→B switch, how can you verify in the source system that the triggers/logging tables now serve BOTH SLT systems, and what does the evidence look like?

In the SLT A→B switch, at what point do you stop the replications in system A, and why not immediately after starting B?

Across all planned-downtime scenarios, why is the SLT configuration required to STAY deactivated during trigger/logging-table recreation, only being activated as the final step?

Reset Status for Triggers and Logging Tables versus Reset Load and Replication Status — which recovery problem does each solve?

After reactivating an SLT configuration post-downtime, what specific monitoring signal tells you replication is genuinely catching up rather than just 'active'?

During a target-HANA patch, changes pile up in the source logging table because SLT can't reach the target. What is the real operational limit this imposes on how long the patch window can run?

Which SLT downtime scenario does NOT require locking users as an initial step, and why is it exempt?

What is the common cross-scenario condition that decides whether you can 'continue delta without initial load' versus 'reload from scratch' after downtime?

Name the recovery-tool difference between a DATABASE migration and a plain source UPGRADE in the SLT downtime chapter.