SQL Server: database separato per i report?

Sul nostro SQL Server, abbiamo un database per ciascuna delle nostre app Web. Per i report, utilizziamo Reporting Services e tutti i dati dei report (inclusi i parametri dei report) provengono da stored procedure.

Le procedure memorizzate si trovano nello stesso database dei dati nel report. Quindi, ad esempio, i proc che servono i report sugli stock si trovano nel database degli stock. Alcuni report mostrano informazioni da più di un database e quindi il proc sarà in uno di quei database di origine. I parametri del report ottengono i loro dati dai proc in un database Enterprise che contiene dati come negozi, dipendenti, ecc.

Ciò significa che tutti i report hanno almeno una connessione al database Enterprise e un'altra connessione a un altro database - e talvolta più di questo.

La mia domanda è: c'è un vantaggio nel spostare i processi di reporting in un database "Report" separato . Conosco i vantaggi dello spostamento di report su un altro server e non ne sto parlando - questo sarebbe sullo stesso server.

Le cose che potrebbero influenzare questo sono:

• Avere più di una connessione al database per un report influisce sulla velocità del report?
• Avere il proc di reporting in un database separato dai dati, ci impedirebbe di utilizzare le viste indicizzate?
• Hai trovato più facile / difficile gestire i rapporti in un database separato?

Per favore fatemi sapere cosa ne pensate.

La risposta è: sì, c'è un vantaggio nel farlo. I rapporti sul database operativo utilizzeranno molte risorse e interferiranno con le prestazioni del sistema operativo. Ricorda che le prestazioni del database sono soggette a vincoli meccanici (le testine del disco si spostano avanti e indietro e la latenza di rotazione mentre aspettiamo che il settore giusto appaia sotto la testata). Sono disponibili due opzioni generali per una strategia di reporting:

1. Replica il tuo database su un altro server e sposta gli sproc di reporting su di esso. I report vengono eseguiti dal server replicato. Questo è il minimo sforzo e può riutilizzare i report esistenti e le procedure memorizzate.
2. Costruisci un data warehouse che consolidi i dati dai tuoi sistemi di produzione e li trasformi in un modulo molto più intuitivo per i report . Se disponi di molti rapporti statistici ad hoc che potrebbero essere fatti in modo accettabile da un'istantanea a partire dalla "chiusura dell'attività ieri", un data warehouse potrebbe essere l'approccio migliore.

Penso che dipende molto dal tipo di SP che stai eseguendo. Se sono pesanti e potrebbero influire su altre cose in esecuzione sul server di database, le sposterei. Altrimenti proverei a tenere il più vicino al database su cui stanno effettivamente riferendo, se lo trovo molto più facile da mantenere e tenere traccia di. Anche solo avere il rapporto vicino al database effettivo potrebbe influire sulle prestazioni, ma se si è su una configurazione standard e non si sposta una quantità enorme di dati, credo che sarebbe una piccola differenza.

Ho anche trovato utile questo articolo.

Consiglio di non spostare le procedure memorizzate in un altro database per diversi motivi. Dal punto di vista dello sviluppo è necessario riprodurre due database ogni volta che si desidera apportare modifiche. Di conseguenza ora vedrai come sincronizzare lo schema dal database "dati" e le procedure memorizzate dal secondo con le versioni di produzione. Per quanto riguarda il ripristino di emergenza e il backup / ripristino, ora è necessario occuparsi del ripristino di 2 database solo per far funzionare il sistema.

Durante il test hai anche aggiunto complessità. Avrai più punti di errore rispetto a permessi, versioni, ecc. Ora se hai più di 1 persona che lavora su diverse iniziative sui database, avrai più tempo a coordinare gli sforzi. Ora immagina che siano le 3 del mattino, il sistema è inattivo e devi cercare le autorizzazioni su tutti i database e assicurarti che nessuno abbia lasciato una funzione o una procedura sul database sbagliato durante lo sviluppo.

Ti consiglierei di usare due database.

La derivazione di report da un database "live" causa problemi di prestazioni.

Inoltre, poiché il database di report è principalmente per le ricerche, è possibile personalizzare qui gli indici per prestazioni migliori. (Il database live avrebbe inserti che sarebbero influenzati negativamente da determinati indici)

Un altro approccio consiste nello spostare le tabelle di report in schemi separati e filegroup separati. I file nel filegroup di report potrebbero essere spostati lontano dai dischi rigidi di dati. Questo è molto più semplice per l'amministrazione, lo sviluppo futuro e la gestione degli accessi.