Replica sql server

domenica 15 giugno 2014 - 13.16

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

Elenco Tags SQL Server Express

86Marco Profilo | Expert

889 messaggi | Data Invio: dom 15 giu 2014 - 13:16

Buongiorno ragazzi e buona domenica,
volevo porVi una domanda circa la ufunzionalità di replica in SQL Server.

Mi sto avvicinando da poco a questo DB.

Quando nello specifico è consigliabile utilizzare una replica?

Inoltre, ho installato SQL Server Express, non è possibile poter utilizzare questa versione per provare a creare delle repliche di un DB?

Grazie a tutti

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 16 giu 2014 - 09:50

>Buongiorno ragazzi,
ciao

>Quando nello specifico è consigliabile utilizzare una replica?
Per capire un po' come si muove la replica, parti da qui: http://msdn.microsoft.com/it-it/library/3a5f4592-3c61-4b4d-9ceb-39716aeeba41(v=sql.110)
In generale, la replica è molto efficace quando vuoi replicare (anche geograficamente):
- porzioni di dati
- porzioni di oggetti
- dati in base a logiche

cose che con altre metodologie di replica del dato (vedi i vari log shipping e mirroring) non puoi fare (bensì puoi considerare solo l'intero database).
Inoltre con la replica puoi scegliere la frequenza di sincronizzazione:
- merge
- transactional
- snapshot
approfondisci qui: http://msdn.microsoft.com/it-it/library/ms152531(v=sql.110)

>Inoltre, ho installato SQL Server Express, non è possibile poter
>utilizzare questa versione per provare a creare delle repliche di un DB?
solo come subscriber, ma non come publisher.
Qui hai una tabella comparativa delle features per edizione di SQL Server:
http://msdn.microsoft.com/en-us/library/cc645993.aspx#Replication

>Grazie a tutti
di nulla!

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 16 giu 2014 - 10:02

Sempre perfetto... mi metto all'opera e ti faccio sapere :)

Grazie alex

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 16 giu 2014 - 12:01

Ciao ALex,
sempre parlando della replica, non mi è chiara una cosa:

Io mi ritrovo in questa condizione:
- Un server A dove sta il database SQL (il vero SQL server in cui pubblico la replica)
- Un secondo server B (su un'altra macchina e su un'altra LAN) che fa da sottoscrittore alla replica
- Un gestionale da me creato che alla installazione viene connesso ad un database sql con cui scambiare dati

Lo scenario in cui utilizzare una replica potrebbe essere questo?

- L'ufficio centrale si trova a Palermo (sede in cui gira il server A),
- L'ufficio succursale con sede a Catania.

Ho creato un programmino gestionale che viene installato su ogni client di Catania e che si collega alla spostazione sql locale (quindi server B) che poi si preoccupa automaticamente di replicare all'ufficio centrale i dati.

E' corretto? E' corretto quindi impostare come database di origine e di destinazione il database che si trova in locale per avere più velocità sapendo che la replica si preoccuperà di mandare tutto al server centrale automaticamente?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 16 giu 2014 - 12:34

>Io mi ritrovo in questa condizione:
>- Un server A dove sta il database SQL (il vero SQL server in cui pubblico la replica)
>- Un secondo server B (su un'altra macchina e su un'altra LAN) che fa da sottoscrittore alla replica
>- Un gestionale da me creato che alla installazione viene connesso ad un database sql con cui scambiare dati

>Lo scenario in cui utilizzare una replica potrebbe essere questo?
>- L'ufficio centrale si trova a Palermo (sede in cui gira il server A),
>- L'ufficio succursale con sede a Catania.

>Ho creato un programmino gestionale che viene installato su ogni
>client di Catania e che si collega alla spostazione sql locale (quindi server B)
>che poi si preoccupa automaticamente di replicare all'ufficio centrale i dati.

>E' corretto? E' corretto quindi impostare come database di origine
>e di destinazione il database che si trova in locale per avere
>più velocità sapendo che la replica si preoccuperà di mandare
>tutto al server centrale automaticamente?
fammi capire una cosa.. chi scrive a chi? Il gesionale immagino legga e modifichi i dati..
e le operazioni sul database centrale di che tipo sono? i dati a Palermo li cambia qualcuno?

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 16 giu 2014 - 12:39

I dati su Palermo sono dati che servono esclusivamente a creare report pivot e report di produzione facendo delle query dal database.

I dati non li modifica nessuno.
Servono solo per amministrazione / gestione

Domanda: eventualmente se i dati sull'sql di Palermo venissero scritti risulterebbe un problema con la replica??

Naturalmente questo scenario è una posizione ancora da definire... non c'è nulla di operativo è ancora in fase di progettazione.. ma volevo capire...

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 16 giu 2014 - 12:48

>Domanda: eventualmente se i dati sull'sql di Palermo venissero
>scritti risulterebbe un problema con la replica??
dal momento in cui scrivi nei due nodi della replica, diventa un problema gestire le sincronizzazioni. Sconsigliato e sconsigliabile per non andare a "cercarsi il freddo per il letto"

>Naturalmente questo scenario è una posizione ancora da definire...
>non c'è nulla di operativo è ancora in fase di progettazione.. ma volevo capire...
In linea di massima, i gestionali di Catania cambiano i dati, e la replica si occupa di portare a Palermo le situazioni aggiornate.
Questo è buono come design a mio avviso.
Rimane un problema, che potrebbe diventare grosso. Se sono i gestionali a cambiare dati, è importante anche capire che porzione di dati cambiano. Nel senso, se possono cambiare dati comuni a tutti, tienine conto, perchè rischi di non voler recepire certi cambiamenti sui client (alcuni gestionali sono molto rigidi sui cambiamenti dei dati di dominio comune). In tal caso puoi decidere di tenere SEMPRE FISSI i dati di dominio, e se essi cambiano, sincronizzarli on demand. La replica verrebbe poi fatta solo sui dati generati DISTINTAMENTE da ogni client, senza che le modifiche vadano ad impattare i comportamenti dei gestionali dislocati a Catania.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 16 giu 2014 - 13:05

Ciao alex.
Scusami ma non ho capito l'ultima parte che mi hai spiegato :) quale potrebbe essere il problema?

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 16 giu 2014 - 14:00

>Scusami ma non ho capito l'ultima parte che mi hai spiegato :)
>quale potrebbe essere il problema?
i gestionali che supportano il multiazienda (di solito) hanno cose in comune come, ad esempio, le causali, i centri di costo e quant'altro..
Siccome sono dati modificabili e qualora fossero modificabili, vi è da fare attenzione.
Immagina di avere due "filiali", Catania 1 e Catania 2.
Immagina che la prima aggiunga una causale ed un centro di costo che DEVE ESSERE VISIBILE solo a Catania 1, appunto.
Nessun problema, tu vai a inviare i dati al centrale e nulla più. I report a Palermo girano con le nuove info.
Ma Catania 2, non ha quella nuova causale.. quindi, i report di Palermo, come devono considerare questo?
Oppure, immagina di dover riflettere anche a Catania 2 il cambiamento su un centro di costo.. visto che invii solo a Palermo, come fai ad allineare Catania 2?
Queste sono considerazioni a mio avviso da fare..

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 16 giu 2014 - 14:12

Ah ora ci sono...
bhe effettivamente è corretto...

La replica quindi dovrebbe essere fatta se la base di dati è comune a tutti...

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: lun 16 giu 2014 - 14:43

>La replica quindi dovrebbe essere fatta se la base di dati è comune a tutti...
no perchè puoi replicare anche solo parte di dati.. il concetto è che alcune info sono legate ad altre che magari decidi di non replicare..
Ti sto dicendo di fare molta attenzione a valutare tutto quanto DEVE ESSERE portato nella replica, e le eventuali trasformazioni da apportare al processo di default.

Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

http://blogs.dotnethell.it/suxstellino
http://suxstellino.wordpress.com
http://mvp.microsoft.com/profiles/Alessandro.Alpi

86Marco Profilo | Expert

889 messaggi | Data Invio: lun 16 giu 2014 - 14:45

Ok chiarissimo :)

Mi metto in studio e ti faccio sapere!!

Mille grazie! :)

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !