Scheduled Downtime & Recovery Procedures

Which transaction do you use to drop SLT database triggers in the source system during an upgrade?

Before entering a planned source-system downtime, after you lock the users, what SLT-specific step must you do before deactivating the configuration?

When you run View Unprocessed Logging Table Records to verify a clean cutover, why can the default output mislead you, and what do you change?

During a source-system upgrade, why deactivate the SLT configuration rather than just leaving replication running?

How do you recognize the database triggers that SLT plants in the source system when you need to list or drop them?

In a source database migration you must drop the old logging tables — how are they named and how do you remove them?

After migration, if you continue delta replication for a table without a fresh initial load, what condition must hold while you recreate triggers and logging tables?

When a source system is transitioned from on-premise to private cloud, what breaks SLT replication if you overlook it?

When decommissioning SLT system A and moving replications to system B, what must you capture from A first, and how?

When switching replications from SLT system A to B, what does setting Refresh Behavior to No Action prevent, and is it mandatory?

In the A-to-B switch, what is the difference between the Start Recording and Start Replication (w/o Load) steps in system B?

During the A-to-B switch, how do you confirm the source table is now registered to both SLT systems?

After upgrading SLT to SP 15, how does the system decide which access-restriction table governs table permissions?

During an unplanned outage, why is SLT being down more urgent for the source system than the source being down for SLT?

In LTRC Expert Functions, which report resets stuck/suspended replication status versus which one recreates triggers and logging tables?

For tables whose triggers were dropped during an upgrade, when is it safe to resume delta instead of reloading from scratch?

After an upgrade with structural table changes, which report tells you a source/proxy/target column mismatch exists?

When Resolve Inconsistencies fixes a structural mismatch found after an upgrade, which systems does it actually change?

When upgrading DMIS, what is the compatibility rule between the SLT DMIS version and the source DMIS version?

After a DMIS upgrade, what must you run before releasing the system, and what does it check?

What is the real gotcha when deleting SLT triggers with IUUC_REMOTE before an upgrade?

Beyond SLT-DMIS-newer-or-equal, what is the maximum allowed gap between the SLT and source DMIS versions?

After implementing the required SAP Notes post-DMIS-upgrade, what step applies the latest fixes to your active replications, and where are the steps documented?

While the target SAP HANA system is under a planned patch upgrade, where does the data that cannot be written to the target end up?

After a target HANA patch, which connection test you run depends on how the target is connected to SLT — how do you choose?

For a target connected by a secondary database connection, where do you find the DB Connection Name to feed into ADBC_TEST_CONNECTION?

During a source database migration, what happens to SLT triggers versus logging tables, and what does that force you to do?

In the Azure-target flow (source → SLT → SAP Data Intelligence Cloud → Azure), which component's outage can actually corrupt data, unlike the others?

After the source upgrade completes, in what configuration state must you recreate the dropped triggers, and with which report?