Configurazione della replica eterogenea del database:da SQL Server a Oracle

Introduzione

Replica di SQL Server è una funzionalità di SQL Server che consente di trasferire i dati da un'istanza all'altra per scopi quali il consolidamento dei dati in un ambiente di reporting o le migrazioni. Personalmente non considererei la replica di SQL Server come una tecnologia ad alta disponibilità anche se alcune persone lo considerano.

La replica di SQL Server utilizza termini simili a quelli del settore editoriale per descrivere il modo in cui i dati vengono gestiti dall'origine alla destinazione. I termini chiave sono i seguenti:

• Publisher:un'istanza di SQL Server che rende i dati disponibili per essere replicati in altre istanze (impacchettate come pubblicazioni).
• Pubblicazione:un'unità pronta per essere passata all'istanza ricevente composta da una raccolta di articoli che sono in realtà oggetti di database.
• Distributore:un'istanza di SQL Server responsabile della memorizzazione dei dati associati a uno o più editori in un database denominato database di distribuzione . Un Distributore locale viene archiviato nella stessa istanza dell'editore mentre è un Distributore remoto si trova in un'altra istanza.
• Subscriber:un'istanza che riceve un database replicato. Un abbonamento per abbonati è una richiesta di una copia di pubblicazione che si aspetta di ricevere dall'editore.
• Istantanea.

Nell'articolo condividerò alcuni punti che ho imparato dalla configurazione della replica di SQL Server per supportare un abbonato eterogeneo. Creerò una pubblicazione e successivamente un abbonamento Oracle che dipenderà da questa pubblicazione. Dimostrerò anche alcuni punti insieme al flusso del processo che sono molto importanti per la risoluzione dei problemi.

I passaggi per configurare una sessione di replica snapshot sono i seguenti:

1. Configura un distributore
2. Configura un editore (insieme alla pubblicazione, inclusi gli articoli in fase di pubblicazione)
3. Configura un abbonato

Fornirò una breve spiegazione di ogni passaggio.

Configurazione di un distributore

Un Distributor è un'istanza responsabile della memorizzazione delle informazioni utilizzate durante la replica. Quando si tenta di creare una pubblicazione nell'istanza per la prima volta, SQL Server suggerisce di configurare un distributore. In questo articolo, il nostro Distributore è un Distributore Locale .

Creazione di una pubblicazione

Identifichiamo il database che contiene gli oggetti che vorremmo replicare. Questo sarà un database di pubblicazione .

Per creare un database di pubblicazione, segui le istruzioni negli screenshot seguenti.

Questo passaggio consente di selezionare un tipo di pubblicazione che si desidera configurare. Ciascun tipo di pubblicazione è descritto nel riquadro inferiore. Per motivi di semplicità e compatibilità, scegliamo una pubblicazione snapshot. Tieni presente che intendiamo replicare oggetti su un'istanza Oracle. In questo caso, Transazionale e Pubblicazioni snapshot sono supportati. Esistono altri buoni casi d'uso per una replica peer-to-peer e di tipo merge.

A questo punto, scegliamo gli articoli che vogliamo pubblicare. SQL Server ci consente di pubblicare quattro tipi di oggetti chiave come:

1. Tabelle
2. Procedure archiviate
3. Viste
4. Funzioni definite dall'utente

Come puoi vedere, pubblicheremo due tabelle:Orders e OrderLines. Allo scopo di dimostrare la flessibilità della replica di SQL Server, filtreremo i record come mostrato di seguito.
Nota: Ci interessa che il numero di OrderID sia maggiore di 1000.

Per escludere righe indesiderate dalle tabelle pubblicate, fai clic su Aggiungi... e poi Avanti .

Gli screenshot seguenti mostrano come filtrare le colonne per la tabella OrderLines.

Quindi, configura le proprietà dell'agente snapshot. Definiamo uno snapshot iniziale e l'intervallo durante il quale viene generato un nuovo snapshot. I dati estratti in questo passaggio vengono archiviati in una directory specificata durante la configurazione iniziale del distributore.

Innanzitutto, imposta una pianificazione per l'avvio di un agente snapshot. Fai clic su Avanti .

Per ogni agente snapshot, specifica l'account con cui verrà eseguito.

Quindi, configurare le impostazioni di sicurezza dell'agente snapshot. La tabella Impostazioni di sicurezza apre un'altra finestra in cui definiamo chi esegue il processo dell'agente snapshot e determiniamo i dettagli di accesso di SQL Server da collegare all'editore. Ci sono alcune autorizzazioni richieste da questi principali che possono essere un po' insicure nella produzione. L'utilizzo dell'account del servizio di SQL Server Agent è una soluzione alternativa per evitare complicazioni, ma in realtà NON è consigliato da Microsoft.

Verso la fine, dovrai decidere se salvare la configurazione come script per un uso successivo o creare immediatamente la pubblicazione.

Il passaggio successivo (Fig. 16) riassume tutte le opzioni selezionate. Si consiglia di fare una rapida revisione prima di fare clic su Fine pulsante.

Viene avviato il processo di creazione della pubblicazione. Puoi fare clic su Interrompi per interrompere il processo.

Una volta completato il processo, la pubblicazione diventa visibile nel riquadro Esplora oggetti in SQL Server Management Studio.

Aggiunta di un abbonato

Un abbonato riceve le pubblicazioni messe a disposizione dall'editore . La copia della pubblicazione da consegnare a un abbonato è denominata Abbonamento . Un editore può avere molti iscritti. Ciascun
abbonato riceve gli articoli pubblicati da questo Editore come un'unità denominata pubblicazione per quanto riguarda l'editore e considerata l'abbonamento per l'Abbonato.

Creando un abbonamento, diciamo semplicemente all'editore:"Voglio avere copie di questa pubblicazione". Per quanto un editore possa avere molte pubblicazioni, possono esserci anche molti abbonati a una
pubblicazione. Pertanto, la relazione tra editori e abbonati è una relazione uno-a-molti.

La procedura guidata per la nuova sottoscrizione ci consente di decidere a quale pubblicazione vorremmo abbonarci. Possiamo scegliere da un elenco delle pubblicazioni precedentemente create come mostrato in Fig. 20.

Successivamente, decidiamo se vogliamo eseguire un abbonamento push anziché un abbonamento pull. Sebbene una sottoscrizione pull sia migliore per le prestazioni quando prevedi più abbonati, non funzionerà per una replica di database eterogenea. Gli abbonati non SQL Server devono utilizzare una sottoscrizione pull. Vale la pena ricordare che anche gli articoli pubblicati in questo scenario sono limitati a tabelle e viste indicizzate.

Aggiungi un abbonato Oracle utilizzando un nome origine dati (DSN). Questo DSN deve essere già stato creato, testato e scoperto che funziona in termini di possibilità di connessione all'istanza Oracle tramite Oracle Net. Ciò significa che è necessario un client Oracle installato sull'host SQL Server con una voce in un file chiamato tnsnames.ora definire la destinazione del collegamento. Questa voce TNS viene a sua volta utilizzata per configurare il nome dell'origine dati richiesto dalla procedura guidata per la nuova sottoscrizione in questa fase.

La voce che ho creato nel mio file tnsnames.ora è simile a questa:

ORCL10G =
 (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = IGIRI-LP)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = orcl10g)
    )
 )

La parte evidenziata è l'alias mentre gli altri dettagli definiscono la destinazione della connessione. Possiamo confermare se questa voce funziona correttamente e se le mie variabili di ambiente Oracle sono configurate correttamente utilizzando tnsping utilità come mostrato di seguito.

Una volta confermata, questa voce TNS viene utilizzata per configurare il DSN che intendiamo utilizzare. Il nome del nostro servizio TNS si chiama ORCL10G mentre il DSN si chiama ORCLDC . È il DSN che utilizziamo nella procedura guidata per la nuova sottoscrizione.

Si noti che abbiamo utilizzato la versione a 64 bit di ODBC per configurare il DSN ed è un DSN di sistema, non un DSN utente. La configurazione non dipende da chi ha effettuato l'accesso al computer.

Selezionare un tipo di abbonato da aggiungere e immettere il nome dell'origine dati. Fai clic su OK .

Scegli uno o più abbonati e specifica un database per ogni abbonamento.

Una volta aggiunto il DSN, possiamo procedere con la configurazione della sicurezza dell'agente di distribuzione. Scopriamo che questo è simile al caso in cui abbiamo configurato un Snapshot Agent Security nella Creazione guidata nuova pubblicazione.

Qui, tuttavia, abbiamo una sezione in cui stabiliamo una connessione con l'Abbonato piuttosto che all'editore (ricordiamo che questo è un abbonamento push). Questo account utente deve essere stato creato sull'istanza Oracle e deve disporre dei privilegi per creare tabelle e quote nel tablespace predefinito (qui potrebbe essere necessario un DBA Oracle).

Aggiungi parametri alla sicurezza dell'agente di distribuzione e fai clic su OK .

Specificare l'account e le opzioni di connessione per ciascun agente di distribuzione e fare clic su Avanti .

Definire la pianificazione della sincronizzazione per ciascun agente. Nel nostro caso, abbiamo scelto di sincronizzare continuamente. Fai clic su Avanti .

Selezionare l'opzione per inizializzare immediatamente l'abbonamento, ovvero copiare nuovamente TUTTI i dati disponibili nella cartella Snapshot. Si consiglia agli abbonati di NoSQL Server di reinizializzare la sottoscrizione quando vengono aggiunti nuovi articoli alla pubblicazione. Fai clic su Avanti .

Selezionare le opzioni da eseguire dopo che il processo è stato completato con successo. Fai clic su Avanti .

Verifica le informazioni che hai aggiunto e fai clic su Fine .

Viene eseguito il processo di creazione dell'abbonamento.

L'abbonamento che abbiamo appena creato mostra una voce in Esplora oggetti (sul Publisher) mappata alla pubblicazione principale. Tieni presente che non viene visualizzato nel nodo Sottoscrizioni locali che fornisce un elenco di sottoscrizioni create nell'istanza corrente che non è in questo caso.

Monitoraggio e risoluzione dei problemi

SQL Server fornisce il monitoraggio della replica per esaminare e monitorare i dettagli di tutte le sessioni di replica nell'istanza. Replication Monitor può informare l'amministratore quando l'agente snapshot viene eseguito e completato. Può anche mostrarci se gli abbonamenti sono inizializzati e se l'agente di distribuzione funziona correttamente.

Esistono otto processi di SQL Server Agent associati alla nostra configurazione corrente. La visualizzazione della cronologia di questi lavori fornisce anche dettagli sul fatto che tutto sia a posto.

Gli errori Oracle effettivi sono elencati in Replication Monitor e nel registro degli errori di SQL Server quando vengono rilevati. Questo livello di dettagli rende la replica di SQL Server interessante per la risoluzione dei problemi. Avere una conoscenza di Oracle (per il DBA di SQL Server) richiederà molto tempo per comprendere gli errori che potrebbero verificarsi.

Dai un'occhiata all'esempio dell'errore in Fig. 34. Questo errore si è verificato prima che gli ambienti Oracle Net e ODBC fossero configurati correttamente. Gli errori danno un'indicazione molto chiara di dove si trova il problema.

La visualizzazione Job Activity Monitor ci informa anche quali lavori riescono e quali lavori dobbiamo risolvere in dettaglio esaminando la Cronologia lavori.

Una volta che tutti gli errori precedenti sono stati risolti, l'apertura di un abbonamento facendo doppio clic su di esso ci offre una vista dettagliata di tutte le sessioni, gli errori e i risultati che ci aspettiamo di vedere quando tutto andrà bene. Osservare che Agent Bulk copia i dati dall'editore all'abbonato in batch. Possiamo anche interrogare le tabelle che sono state create nell'istanza Oracle e confrontare i record. (Fig. 37).

Come puoi vedere, SQL Server prepara la tabella escludendo lo schema di origine (Sales) prima di creare la tabella in Oracle e copiare i dati.

Il conteggio dei record nell'istanza Oracle corrisponde a quello nella tabella di origine e tiene conto del fatto che filtriamo la tabella OrderLines per OrderID maggiori di 1000.

Conclusione

Abbiamo brevemente eseguito il processo di configurazione della replica di database eterogenei con un'istanza Oracle come abbonato. Sebbene questa opzione venga gradualmente deprecata da Microsoft, esistono casi d'uso che potrebbero comunque trarre vantaggio dalle funzionalità fornite da questa vecchia funzionalità di SQL Server. La sezione Riferimenti fornisce una lettura più ampia sull'argomento che credo sarà utile per coloro che vogliono esercitarsi di più.

Riferimenti

Configura replica per gruppi di disponibilità sempre attivi
Abbonati non Oracle
Replica eterogenea del database
Abbonati Oracle