Operazioni di report di grandi volumi, il modo migliore per replicare i dati transazionali

0

Stiamo revisionando un'app di contabilità legacy con alcuni report di grandi dimensioni. Una preoccupazione che è stata sollevata è dovuta alla natura transazionale dei dati, se iniziamo un rapporto a lungo termine come facciamo a garantire che i dati non vengano modificati prima di procedere con l'elaborazione?

Il blocco di tutto sulla transazione db è fuori, quello che è stato suggerito è mantenere una replica db che può essere bloccata, mi sembra una cosa da scherzo.

Mi chiedo se qualcuno abbia qualche prospettiva che è possibile condividere, ad esempio quale è il costo di creare dinamicamente un db di replica al momento del rapporto e di replicare solo ciò di cui abbiamo bisogno, quindi soffiare via il db temp? Qual è il costo di creare dinamicamente uno schema db e / o tabella solo per un singolo report? Come gestire contemporaneamente lo stesso report eseguito? C'è un modo più semplice?

    
posta StuTheDog 19.01.2015 - 17:52
fonte

1 risposta

1

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.

    
risposta data 19.01.2015 - 18:03
fonte

Leggi altre domande sui tag