Definizione del problema

I nostri utenti hanno bisogno della possibilità di interrogare un database che è per lo più aggiornato. I dati possono essere aggiornati fino a 24 ore e ciò è accettabile. Quale sarebbe l'approccio più economico per ottenere e mantenere aggiornato un secondo database con una copia di produzione? C'è un approccio a cui non sto pensando?

Carico di lavoro

Abbiamo un'applicazione di terzi che utilizziamo per monitorare l'attività di trading di azioni. Durante il giorno, si verificano molti piccoli cambiamenti come parte di vari flussi di lavoro (sì, questo commercio era valido. No, questo è sospetto, ecc.). Di notte, eseguiamo grandi operazioni basate su set (carica le negoziazioni del giorno precedente).

La soluzione e il problema attuali

Facciamo uso di snapshot del database . Alle 22:00 rilasciamo e ricreamo l'istantanea. Quindi inizia l'elaborazione ETL. Questo è ovviamente tassativo sul nostro disco, ma consente ai nostri utenti la possibilità di interrogare il database senza bloccare il database (usano un front-end di Access). Lo usano fino a notte fonda e al mattino presto, quindi noteranno tempi di inattività.

Il problema con questo approccio è duplice. Il primo è che nel caso in cui l'elaborazione notturna non vada a buon fine, e questo non è terribilmente insolito, possiamo ripristinare il database con conseguente eliminazione dell'istantanea. L'altro problema è che i nostri tempi di elaborazione stanno scivolando oltre il nostro SLA. Stiamo tentando di risolvere questo problema collaborando con il fornitore dopo aver identificato query scritte male e mancanza di indicizzazione. Lo snapshot del database è anche un colpevole di questo rallentamento, come evidenziato dalla differenza di velocità quando è presente rispetto a non --- scioccante, lo so.

Approcci considerati

Clustering

Abbiamo attivato il clustering di database, ma ciò non ha soddisfatto le esigenze di rendere disponibili i dati e in genere ha complicato la vita dell'amministratore. Da allora è stato spento.

Replica di SQL Server

Abbiamo iniziato a guardare la replica la scorsa settimana. La nostra teoria è che possiamo ottenere un secondo catalogo in piedi e sincronizzato con il database di produzione. Prima dell'inizio dell'ETL, interromperemo la connessione e la riattiveremo solo una volta completato il processo ETL.

L'amministratore ha iniziato con Snapshot Replication ma è preoccupato che ci vogliono più giorni di utilizzo elevato della CPU per generare l'istantanea e il consumo del disco richiesto. Indica che sembra scrivere tutti i dati su file fisici prima di inviarli al sottoscrittore, quindi il nostro database da 6 TB avrà un costo di 1,8 TB nei costi di archiviazione. Inoltre, se ci vorranno più giorni per generare uno snap, non si adatterà allo SLA desiderato.

Dopo aver letto il bell'articolo, sembra che Snapshot potrebbe essere il modo per inizializzare gli abbonati, ma poi vorremmo passare alla replica transazionale per mantenerlo sincronizzato dopo. Presumo che l'attivazione / disattivazione della replica transazionale non forzerà una reinizializzazione completa? Altrimenti, faremo saltare la finestra temporale

Mirroring del database

Il nostro database è in modalità di recupero COMPLETO, quindi il mirroring del database è un'opzione, ma ne so ancora meno della replica. Ho trovato la risposta SO che indicava "Il mirroring del database impedisce l'accesso diretto ai dati, i dati con mirroring sono accessibili solo tramite un'istantanea del database".

Log Log

Sembra che anche la spedizione dei log potrebbe essere un'opzione, ma questa è un'altra di quelle cose di cui non so nulla. Sarebbe una soluzione a costi inferiori (implementazione e manutenzione) rispetto a qualsiasi altra cosa? Sulla base del commento di Remus "La spedizione dei registri consente l'accesso in sola lettura alla copia della replica, ma disconnetterà tutti gli utenti quando si applica il registro di backup successivo ricevuto (ad es. Ogni 15-30 minuti)." Non sono sicuro di quanto tempo si tradurrebbe in questo tempo di inattività che potrebbe causare angoscia agli utenti.

MS Sync

Ho sentito parlare dell'uso di Sync lo scorso fine settimana e non l'ho ancora investigato. Odierei introdurre una nuova tecnologia per qualcosa con alta visibilità come questo problema, ma se è l'approccio migliore, così sia.

SSIS

Facciamo un sacco di SSIS qui, quindi generare alcune centinaia di pacchetti SSIS per mantenere sincronizzato il secondario è un'opzione per noi, anche se brutta . Non sono un fan del fare questo perché c'è un sacco di spese generali di manutenzione che preferirei che il mio team non accettasse.

Istantanea "magica" di SAN

In passato, ho sentito parlare del nostro amministratore che utilizza una tecnologia SAN per eseguire backup istantanei di interi dischi. Forse c'è un po 'di magia EMC che potrebbe essere usata per fare copie superflue del mdf / ldf e possiamo quindi staccare / collegare il database di destinazione.

Backup e ripristino

Penso che eseguiamo backup completi una volta alla settimana, differenziali notturni e tlog ogni 15 minuti. Se gli utenti potessero vivere l'interruzione di 3-4 ore per il ripristino completo, suppongo che questo potrebbe essere un approccio.

vincoli

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, storage SAN EMC con unità mappate su file vmdk, commvault che gestiscono backup e .6 TB di dati nel catalogo di origine. Questa è un'applicazione di terze parti che ospitiamo internamente. La modifica della loro struttura è generalmente disapprovata. Gli utenti non possono andare senza interrogare il database e rifiutarsi di essere vincolati identificando in modo proattivo le tabelle che monitorano per svolgere il proprio lavoro.

I nostri DBA sono puramente appaltatori al momento. I full-timer sono salpati e non li abbiamo ancora sostituiti. Gli amministratori dell'applicazione non sono esperti di SQL Server e abbiamo un team di amministratori Storage / VM che potrebbe aiutare / ostacolare questo sforzo. I team di sviluppo non sono attualmente coinvolti ma possono essere arruolati in base all'approccio. Quindi sarebbe preferibile una soluzione più semplice da implementare e mantenere.

Io sono dal lato dello sviluppo di Hosue, quindi posso solo proporre approcci e non ho avuto a che fare con il lato amministrativo delle cose. Quindi, senza tempo in sella all'amministratore, sono titubante nel dire che un approccio sarebbe superiore a un altro, secondo i documenti sembra tutto perfetto. Sono pienamente disposto a seguire tutte le direzioni che tutti suggerirete perché, come lo vedo, mi renderà più prezioso come professionista del DB. Ho una carriola ma nessun mantello dell'olocausto disponibile .

Domande correlate

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Le modifiche

Per rispondere alle domande di @ onpnt

Accettazione della latenza dei dati

Al momento gli utenti visualizzano i dati con un ritardo massimo di 24 ore. I dati sono aggiornati solo a partire dal 2200

Quantità di modifica dei dati in un determinato minuto, ora e giorno Non sono sicuro di come quantificarlo. Orario di lavoro, forse centinaia di cambi all'ora. Elaborazione notturna, milioni di righe per giorno lavorativo

Connettività al secondario

Rete interna, host virtuale separato e memoria dedicata

Leggi i requisiti sull'istanza secondaria

Il gruppo Windows avrà accesso in lettura al secondario, tutte le tabelle

Tempo di attività dell'istanza secondaria

Non esiste una definizione forte di un requisito di uptime. Gli utenti lo vogliono sempre disponibile ma sono disposti a pagare per quello, probabilmente non così tanto. Realisticamente, direi che 23 ore al giorno sarebbero sufficienti.

Modifiche allo schema esistente e a tutti gli oggetti

Modifiche rare, forse una volta al trimestre per gli oggetti tabella. Forse una volta al mese per oggetti codice.

Sicurezza

Nessuna necessità di sicurezza speciale. Le autorizzazioni di produzione corrisponderebbero alle autorizzazioni della copia. Anche se ci penso, potremmo revocare agli utenti l'accesso in lettura a prod e consentire loro solo di leggere la copia ... Non è un requisito però.

@darin strait

Il ripristino dell'istantanea potrebbe essere un'opzione, ma penso che ci fosse qualche motivo per cui non l'hanno perseguito. Controllerò con l'amministratore

@cfradenburg

La mia ipotesi era che avremmo usato solo uno di questi approcci, ma è un buon punto che i ripristini rompano le "altre" tecnologie di sincronizzazione. Stanno indagando facendo usando la magia dell'istantanea EMC. Come descritto dall'amministratore, avrebbero scattato un'istantanea a 1900 e trasferito l'immagine nella zona del secondario. Ciò dovrebbe essere completato entro il 2200 e quindi avrebbero eseguito il distacco e il riattacco del database secondario.

Incartare

29-10-2012 Abbiamo valutato la magia dell'istantanea EMC e alcune altre opzioni di replica, ma i DBA hanno deciso che potevano capire meglio il mirroring. Ho valutato le risposte perché mi hanno aiutato e mi hanno dato molte opzioni e "compiti a casa" per indagare.

La modifica della loro struttura è generalmente disapprovata

La replica è più che probabile fuori e butterei fuori Sync prima di quello. (dai test transacitonali reali su Sync Framework)

Se 3-4 ore sono la tua eccezione di latenza dei dati, la spedizione dei log sarà probabilmente la soluzione migliore qui su una copia di sola lettura. Ma quanti cambiamenti stanno avvenendo nel registro? scoprilo monitorandolo per vedere quanto velocemente e quanto devi spingere.

Se non puoi andare al mirroring o aggiornare all'impresa 2012, questo è fuori sebbene sarebbe una buona strategia se puoi andare all'impresa se non su di essa.

SSIS non intende semplicemente scaricare i dati ma può farlo. Stai osservando troppo in termini di trasformazioni di ricerca e il compito sarebbe costoso in termini di tempo e risorse. Anche se, come ho detto, può farlo.

Davvero, ci sarà un netto restringimento delle scelte basato sulla risposta ad alcune domande

• Accettazione della latenza dei dati
• Quantità di modifica dei dati in un determinato minuto, ora e giorno Connettività al secondario
• Leggi i requisiti sull'istanza secondaria
• Tempo di attività dell'istanza secondaria
• Modifiche allo schema esistente e a tutti gli oggetti
• Sicurezza

Questa sarà una di quelle cose che devi provare per trovare ciò che funziona meglio. La replica può essere complicata, quindi mentre potrebbe non esserci un costo monetario diretto, ci sarà un sovraccarico amministrativo a mantenerlo.

Per espandere la distribuzione dei log, non è necessario ripristinare i log ogni 15-30 minuti. Se lo desideri, puoi farlo ogni quattro ore o una volta al giorno. Una soluzione simile a questa che ho implementato sta eseguendo un backup completo settimanale e il ripristino su un database di report (che può richiedere del tempo e si verifica durante il fine settimana). Durante la settimana vengono eseguiti backup differenziali e questi vengono ripristinati nel database di report notturno. Gli utenti devono eseguire l'avvio prima del ripristino, ma poiché il DB di report è un'applicazione per l'orario di ufficio, non esiste alcun problema. I dati risalgono a un giorno fa e non dovrebbero essere un problema in base alle tue esigenze.

Per utilizzare il mirroring del database per questo è necessario acquistare Enterprise per poter utilizzare le istantanee se non si sta già eseguendo Enterprise. Inoltre, non manterrebbe aggiornati i dati al 100% poiché l'istantanea deve essere eliminata (il che significa che tutti gli utenti devono essere fuori) e quindi ricreata per ottenere i nuovi dati. Tuttavia, ciò richiederebbe meno tempo rispetto ai ripristini dei registri o al metodo che ho spiegato sopra.

Se l'aggiornamento a SQL 2012 è un'opzione è possibile impostare un secondario di sola lettura che verrà aggiornato con il database primario. Lo dico solo perché è probabilmente la soluzione più semplice.

Per quanto la gente si preoccupi della replica transazionale, sembra una buona misura per la tua situazione. Un paio di note:

1. Non è necessario inizializzare l'abbonato con un'istantanea. Puoi fare un backup del publisher e inizializzare con quello.
2. È possibile sospendere il recapito dei comandi al sottoscrittore semplicemente interrompendo il processo di distribuzione (è solo un normale processo SQL Agent nel distributore o nel sottoscrittore a seconda che sia stato impostato come abbonamento push o pull, rispettivamente). Basta essere consapevoli della propria ritenzione presso il distributore in modo tale da mantenere una storia sufficiente da poter recuperare.
3. Puoi modificare l'indicizzazione nell'abbonato per adattarsi ai carichi di lavoro che verranno eseguiti lì (presumibilmente di tipo di reportistica) invece di accettare l'indicizzazione dal tuo editore (presumibilmente di tipo OLTP) se lo desideri.