UGISS Community

Buongiorno a tutti,

innanzitutto mi presento, mi chiamo Marco, ho 25 anni e sono "sviluppatore" (?? ).

Ora... passo al dunque...
Presso un mio cliente, che utilizza il nostro gestionale ed un programma sviluppato internamente per delle loro particolari esigenze, ho realizzato un semplice aggiornamento dati tra il mio database ed il database del programma interno, tramite un semplice trigger che viene scatenato all'inserimento delle fatture.

Il problema è che ora questa azienda ha spostato parte dei suoi uffici, e mi trovo nella condizione di avere due server separati, collegati tramite una VPN che si appoggia a due ADSL...
Ovviamente non credo che modificare il trigger per farlo funzionare da un server all'altro sia problematico... ma è problematica la gestione dell'ipotesi di una delle due adsl non funzionante...
In questo caso il trigger darebbe errore (tra l'altro bloccherebbe il salvataggio delle fatture...)

Ho pensato che potesse fare al caso mio la distribuzione dei log del DB...
Premetto che non ho ancora approfondito l'argomento, del quale ho solo sentito parlare... quindi scusatemi in anticipo se dirò qualche cazzata... :)

A livello teorico, se gestisco una replica del mio DB sul server sul quale è residente il DB da aggiornare. Nel momento in cui il log viene inviato ed acquisito dal server di destinazione, le operazioni in esso contenute vengono eseguite sul DB... in questo modo dovrei riuscire a scatenare il trigger (?!?!).

Una cosa di questo tipo è fattibile? Sapreste consigliarmi delle soluzioni migliori?

Vi ringrazio anticipatamente per qualsiasi aiuto saprete darmi!

Marco.

Ciao Marco,

dipende che tipo di aggiornamento devi fare. Se chiamiamo il database presso il cliente A e quello presso la tua azienda B devi aggiornare solo da A a B o viceversa?.

Il meccanismo del log shipping e del mirroring ti permettono di avere "una copia" esatta del database di partenza e probabilmente non è quello che tu vuoi.

A mio giudizio i due sistemi che puoi utilizzare sono :

repliche

Service Broker per gestione messaggistica asincrona su SQL Server.

Nel secondo caso è necessario che almeno una delle macchine SQL Server 2005 abbia una versione licenziata del software e non SQL server.

Se vuoi utilizzare il service broker c'è un bellissimo tutorial di Davide Mauri che trovi sul sito eti descrive passo passo cosa fare anche da un punto di vista di sicurezza considerando che le due macchine si trovano su IP pubblico. (quindi la sicurezza non è da sottovalutare).

 se decidi di utilizzare le repliche  sono possibili repliche di tipo merge che quindi mantengono sincronizzati i due sistemi anche nel caso di modifica da una parte o dall'altra. Purtroppo sulle repliche ti posso aiutare molto poco perchè ho iniziato solo adesso ad analizzare l'argomento. L'impressio che ho avto comunque è che il meccanismo delle repliche utilizza molte risorse. A suovantaggio ha, rispetto al service broker, che minimizza (se non azzera) quasi completamento la parte di sviluppo. Si fa tutto tramite SQL Server Management tramite wizard guidato (anche qui, per il problema della sicurezza, ci potrebbe volere un pòpiù tempo)

Utilizzando il service broker, il tuo trigger cambia semplicemente perchè effettuerà un inserimento nella coda del servizio di "sincronizzazione" e, in maniera asincrona il messaggio è trasferito all'altro database dove una procedura si preoccuerà di gestirlo. Tutto è garantito e soltanto quando un messaggio è stato elaoato dal destinatario viene eliminato.

dacci qualche informazioni in più e magari ti possiamo aiutare meglio.  

Ciao

Luca

Ciao Marco

come prima cosa: Benvenuto!

Per quanto riguarda il tuo problema:

Harlock83:

Il problema è che ora questa azienda ha spostato parte dei suoi uffici, e mi trovo nella condizione di avere due server separati, collegati tramite una VPN che si appoggia a due ADSL...
Ovviamente non credo che modificare il trigger per farlo funzionare da un server all'altro sia problematico... ma è problematica la gestione dell'ipotesi di una delle due adsl non funzionante...

Oltre ad un'ADSL non funzionante devi tenere anche conto che la velocità dell'ADSL non potrà essere sicuramente paragonabile a quella della LAN interna...quindi in questo caso un trigger che fa un'aggiornamento su un DB remoto collegato via ADSL mostrerà senza dubbio problemi di performance. Tieni conto che è un trigger è parte della transazione (il comando INSERT, UPDATE o DELETE) che lo ha scatentato ed sincrono, pertanto una letenzza associata al trigger si riperquoterà *sicuramente* su tutta l'applicazione.

Harlock83:

Una cosa di questo tipo è fattibile?

Direi di no. Per lo scenario che descrivi la soluzione ideale è l'implementazione di una soluzione SOA, che utilizzi il Service Broker. Mi spiego meglio

1. la tua applicazione fa scrivere la fattura sulla tabella locale
2. il trigger invia un messaggio XML (e non fa un insert) al server remoto
3. il server remoto riceve il messaggio e scatena l'azione associata, aggiornando il db remoto

Questa soluzione, utilizzando il Service Broker per l'inivio di messaggi in asincrono ti protegge da eventuali lentezze o disconessioni dell'ADSL o del server remoto, garantendoti cmq la transazionalità dell'operazione.

Ho appena implementato una soluzione simile da un cliente che aveva uno scenario molto simile al tuo ed il tutto funziona alla perfezione.