SSRS: come gestire indisponibilità del servizio quando datawarehouse viene ricostruito

Question

Usiamo SSIS per costruire datawarehouse (ambiente pieno di Microsoft). Questo è pacchetto SSIS eredità che inizia con troncare tutte le tabelle di datawarehouse, eseguito durante la notte.

In questo periodo, ci limitiamo l'accesso all'applicazione, in questo modo il database non è alterato durante l'integrazione.

1 / integrazione può essere fatto su snapshot del database, in modo da poter mantenere l'applicazione installato e funzionante?

2 / domanda generale: come gestire il periodo in cui datawarehouse viene ricostruito? L'accesso alla relazione dovrebbe essere vietata fino a quando tutti i tavoli sono riempiti con i dati freschi. Esiste un Meccanismo di equilibrio tra 2 datawarehouse? Si potrebbe essere fatto con origini dati parametrizzati in SSRS invece di origine dati condivisa, ma mi sembra come officina del gas.

Ambiente: SQL Server 2005 e abbiamo intenzione di migrare al 2012

.

Answer 1

1. Snapshot del database sono di sola lettura, in modo da non poteva eseguire processi ETL di lettura / scrittura contro l'istantanea. Tuttavia, si potrebbe puntare report, query ad hoc per l'utente finale, ecc presso l'istantanea. Ciò consentirebbe di eseguire i processi ETL contro la base di dati dal vivo senza interferire con la segnalazione degli utenti. Una nuova istantanea avrebbe bisogno di essere creata dopo ETL elabora completa. A seconda di archiviazione disponibile, è possibile memorizzare più copie di snapshot.

2. Per quanto riguarda il data warehouse (DW) di aggiornamento, si consiglia di implementare processi carico incrementale . Invece di troncare massa / inserto operazioni, confrontare la allestita dati di origine con ciò che esiste già nel DW; Solo inserire / aggiornare i dati che deve cambiare. Questo vi darà un enorme vantaggio in termini di risorse utilizzate e il tempo necessari per i processi ETL per il completamento.

Answer 2

si dispone di uno scenario piuttosto brutta qui. Se il DW sono stati solo a cui si accede da un cubo OLAP si andrebbe bene perché i dati sarebbero in esso durante l'aggiornamento (a meno che non hai qualche ROLAP configurato)

Una panoramica avrebbe funzionato per una lettura solo DB durante il processo di ricostruzione. Si dovrebbe creare l'istantanea prima che l'aggiornamento, puntare tutti i rapporti ad esso e li li puntare di nuovo quando l'aggiornamento è finito.

Ma perché vietando l'accesso al DB sorgente durante l'aggiornamento? Hai paura che qualcuno avrebbe inserire i dati mentre viene copiato nel DB di destinazione? Si potrebbe facilmente risolvere che con un buon controllo delle transazioni sul pacchetto SSIS.