Quali fattori oggettivi indicano che è tempo di implementare la replica di SQL Server?

Sto cercando di trovare un equilibrio tra alte prestazioni del nostro database e facilità di manutenzione. Stiamo valutando di utilizzare la replica per migliorare le prestazioni, replicando i nostri report SSRS in un database fisicamente separato dal nostro database transazionale. Tuttavia, l'abilitazione della replica presenta numerosi svantaggi dal punto di vista dello sviluppatore:

• Rende più difficili le modifiche allo schema
• Interferisce con il nostro server di integrazione / build automatizzato
• Sembra rendere difficile l'implementazione del controllo del codice sorgente SQL

La mia domanda è : quando sai che è ora di andare con la replica alla luce di questi inconvenienti? Come si decide se la complessità aggiuntiva giustifica i guadagni?

L'abbiamo usato prima, quindi configurarlo non è un problema. Si tratta più di prendere la decisione di abilitarlo o meno. Sto cercando alcune metriche delle prestazioni degli oggetti che altri hanno osservato con la replica.

Ovviamente la cosa migliore sarebbe fare dei test di carico simulati sui nostri server e scoprirlo da soli, ma spero che ci siano alcune linee guida generali là fuori.

La replica dovrebbe essere considerata durante la fase di progettazione dell'applicazione. Se si dispone di una forza lavoro / base di utenti distribuita geograficamente, potrebbe essere utile disporre di database regionali e database centrali. I database disconnessi sui laptop possono "sincronizzarsi" quando finalmente si riconnettono con la rete (pensa al personale di vendita sulla strada).

Per quanto riguarda i rapporti, la replica NON è la risposta. La maggior parte dei problemi di prestazioni in un ambiente di reporting deriva dal fatto che i report vengono scritti su un sistema configurato per l'elaborazione delle transazioni online (OLTP).

La replica a scopo di reportistica consiste semplicemente nello spostare i dati OLTP su un altro server, mantenendo però la stessa struttura ostile ai report. In sostanza, stai gettando più hardware sul problema e aumentando i costi di manutenzione, ma per guadagni marginali.

Quello che dovresti guardare è come ottenere i dati specifici di cui hanno bisogno i tuoi rapporti e trasformarli in un formato più utile. Crea un feed che acquisisce nuove transazioni dal tuo database di produzione e lo memorizza in un database di report, preferibilmente su un server separato. Ogni volta che il feed viene eseguito, dovrebbe acquisire tutti i dati più recenti dell'ultima volta in cui è stato eseguito, trasformarli e archiviarli. I report attualmente in esecuzione ti daranno una buona idea dei tipi di trasformazioni richieste.

Seguendo questo approccio, otterrai enormi vantaggi in termini di prestazioni.

Per quello che vale, abbiamo trovato che la replica è utile in una situazione simile perché gli autori di report possono "possedere" gli indici sul database replicato. Questo ci ha dato la possibilità di migliorare le prestazioni delle query aggiungendo indici che gli sviluppatori di applicazioni non avrebbero mai approvato in produzione a causa del loro impatto negativo su INSERTI e AGGIORNAMENTI.

Forse parte del tuo caso d'uso è copiare alcune tabelle transazionali, cambiare un po 'di indicizzazione e vedere se ne vale la pena?

Spero che questo ti aiuti!