if we start a long running report how do we ensure the data is not modified before we get around to processing it?
Questo non è un requisito tipico. Di cosa hai paura che ciò influenzi? Il rapporto attualmente in esecuzione o il carico di lavoro transazionale?
Se sei preoccupato per la segnalazione di diverse versioni di dati che potrebbero inquinare il report o creare una rappresentazione errata dei dati, allora dovresti assicurarti una visualizzazione point-in-time del database appena prima che i report salti off.
Nota: sono un professionista di SQL Server quindi la mia ulteriore guida parla a nome della tecnologia SQL Server relativa al mio particolare RDBMS
Istantanee del database sono un'ottima soluzione qui. Quando si crea uno snapshot del database, viene utilizzato un file sparse per registrare le pagine modificate dal momento in cui viene creata l'istantanea. L'istantanea stessa è una vista statica coerente al livello di transazione del database al momento della creazione dello snapshot . Sfrutta un'operazione copy-on-write ogni volta che viene modificato il database originale.
Se vuoi scaricarlo su un server separato, puoi sfruttare la replica transazionale per un sottoinsieme del database di origine (l'editore), specificando articoli particolari da replicare, a differenza dell'intero database. Considera questo un approccio ristretto e offloaded, nonché un approccio focalizzato sui dati (rispetto all'intero database) al reporting. Puoi mettere in pausa la distribuzione dei dati agli iscritti quando sei pronto per eseguire il carico di lavoro del rapporto e poi riprendere quando è completato .
La soluzione più semplice qui sarebbe lo snapshot del database . Creare lo snapshot prima di eseguire il report. Esegui il rapporto sullo snapshot. Quindi, quando il report è terminato e non hai più bisogno della visualizzazione statica del tuo database da quel tempo di snapshot, rilascia lo snapshot.