Mein erster Gedanke wäre, einfach alle paar x Minuten ein SSIS Job starten, welcher die Daten rüber schaufelt.

In welchem Zeitrahmen müssen den die Daten in der Instanz B verfügbar sein und wie häufig kommen neue Daten rein?

Hi,

vereinfacht erklärt, erstellt der SQL Server für jedes Query einen Plan (Compiled Execution Plan). Dieser beinhaltet z.B. welche Objekte (Tabellen, Spalten etc) benötigt werden und wie diese miteinander agieren, damit du dein Ergebnis bekommst. Dieser Plan beinhaltet auch ob und welche Indizes genutzt werden sollen und wieviele Datensätze pro Tabelle vorraussichtlich geholt werden müssen.
Das letztere ist nur eine Schätzung auf Grund der Statistiken, welcher der SQL Server bei jeder Tabelle hinterlegt hat. (Die Kardinalität ist hier der entscheidende Faktor)
Auf Grund dieses Plans reserviert der SQL Server auch eine gewisse Menge an RAM, welches explizit dem Query zur Verfügung steht.

Wenn du jetzt aber sagst du hast 30 Parameter, dann vermute ich, dass diese wohl einen großen Einfluss auf den eigentlichen Ablauf des Querys haben.
Z.B. könnte ich mir vorstellen das aus einer TabelleA nur 1 Datensatz benötigt wird und bei einem neuen Lauf mit geänderten Parameter benötigt man vielleicht 10.000 Datensätze.

Mein Tipp ist, wenn das Query schnell genug ist und es wird mit OPTION (RECOMPILE) behoben, dann lass es so.
Wenn nicht, dann solltest du dir Gedanken machen wie du das große Query in kleinere unterteilen kannst.
Oder vielleicht mal die ganze Architektur überdenken, weil vernünftig hört sich das mit 30 Parameter nicht an 😉

Wegen Skripte für Performance Fragen empfehle ich meinen Kunden immer die Skriptsammlung von Brent Ozar.
Für dich wäre z.B. https://www.brentozar.com/blitzcache/multiple-plans/ interessant.

Schönen Gruß
Tom

Das hört sich eher nach einem Problem mit Parameter Sniffing an.
Probier doch mal OPTION (RECOMPILE) - Query Hints (Transact-SQL) - SQL Server

Wirst ja hoffentlich nicht ständig den SQL Server neustarten wollen ...

Schönen Gruß
Tom

Meiner Erfahrung nach, wirst du über die (zu erwartende) Datenmengen nicht an Laufzeiten kommen.

Das klappt oft nur bei simplen Sachen. Wie z.B. einem simplen Insert. Weil das Nadelöhr ist da z.B. I/O und wenn es ein vernünftiges Storagekonzept ist, sollte die Performance relativ stabil sein.

Mach das doch erst einmal über eine Tabelle. Hinterleg den Job mit der maximalen Laufzeit dort.
Die joinst du mit meinen Statement und schon bekommst du alle Jobs mit zu langer Laufzeit.

In einem zweiten Schritt könntest du dann z.B. deine Tabelle, in Betracht der durchschnittlichen Laufzeiten eines vernünftig gewählten Zeitraums, aktualisieren.

Woher weisst du dann, dass der Job zu lange läuft?
Ist das ein Erfahrungswert oder wie entscheidest du aktuell, dass der Job zu lange läuft.

Die aktuell laufenden Jobs bekommst du über die sysjobactivity Tabelle.

Z.B. alle laufenden Jobs mit Startzeitpunkt:

SELECT t1.job_id,
       t1.name,
       t2.start_execution_date
FROM msdb.dbo.sysjobs t1
    INNER JOIN msdb.dbo.sysjobactivity t2 ON t2.job_id = t1.job_id
WHERE t2.session_id = (SELECT MAX(session_id) FROM msdb.dbo.syssessions)
      AND t2.start_execution_date IS NOT NULL
      AND t2.stop_execution_date IS NULL
ORDER BY t2.run_requested_date ASC;

Du musst erst einmal feststellen was genau den Deadlock verursacht.

Brent Ozar hat da erst kürzlich eine kleine Zusammenfassung dazu erstellt:
Brentozar.com: Troubleshoot Blocking & Deadlock

Wie kann sich denn bei einem normalen Backup/Restore die Tabellenstruktur ändern? ...

Ich würde an deiner Stelle mal dein Backup und Restore anschauen. Das muss ja irgendwie ausserhalb der Norm sein.

Den Increment von einer Tabelle kannst du auch nachträglich mit

DBCC CHECKIDENT('<SCHEMA.TABELLENNAME>')

korrigieren.

Siehe https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-checkident-transact-sql?view=sql-server-2017

Ich nutze für 'Chunk' Operation immer dieses Skript:

WHILE ( 1 = 1 )
    BEGIN
        BEGIN TRANSACTION;
    
        DELETE TOP ( 500 )
        FROM    dbo.table1
        WHERE   condition IS NULL;
    
        IF @@ROWCOUNT = 0 -- terminating condition;
            BEGIN
                COMMIT TRANSACTION;
                BREAK;
            END;
    
        COMMIT TRANSACTION;
    END;

Die Anzahl der Rows ist natürlich immer situationsabhängig.
Musst du Millionen von Datensätzen löschen, würde es mit 500 länger dauern, als wenn du z.B. 10000 auf einmal löscht.
Generell solltest aber das machen was dein DBA dir vorgibt. Vorausgesetzt er kennt sich aus 😉

Hi,

bei Dropbox kannst du am PC auch auswaehlen welche synchronisierte Ordner du nutzen willst.
Nennt sich 'Selective Sync' und befindet sich bei den Erweiterten Eigenschaften.
Brauchst also nicht mehrere Accounts.

Wie das bei Smartphones aussieht weiss ich nicht, nutze Dropbox nur am PC.

Gruss,
Tom