Newsgroup: it.comp.software.database
Titolo: Domanda su replica merge

Ciao a tutti, ho letto le faq di questo sito sulla replica e parecchia
documentazione ma non riesco a trovare risposta su alcuni punti, spero
possiate aiutarmi. Dunque vorrei sapere se con la replica in oggetto è poi
possibile andare a modificare la struttura di una rabella, tipo inserendo
egli indici o delle chiavi ecc?
Inoltre vorrei sapere se anche con la replica merge ci sono gli stessi
problemi che con quella transazionale ovvero che nel db secondario non
vengono riporati le chiavi primarie e gli indici della tabelle originali
chele hanno. 
Sarei grato se poteste rispondermi o indirizzarmi a qualche link
sconosciuto che spieghi queste cose.
grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 grazie
Bye
-- 
Luca Bianchi
Microsoft MVP - SQL Server
http://mvp.support.microsoft.com

 Log Shipping...
Ciao Luca, veramente grazie per la mole d'informazioni e la tua
disponibilità. In effetti si parla di SQL e il log shipping lo conosco
molto bene essendo atualmente implementato nel DBServer che gestisco.
L'unica pecca che riscontro è purtroppo il tempo di latenza e il fatto che
ad ognir "restore" gli uteti vengono sconnessi.Gestendo un db di commercio
elettronico quindi online h24 il meglio sarebbe avere una replica di dati
sul secondario istantanea, figurati che ho settatto il log shipping per un
backup ogni 5 minuti( a proposito un tempo così breve può creare problemi
di prestazioni al primario?) che genera un TLog di circa 2 mega ogni volta.
Per questo motivo mi stavo avvicinando alla replica ma credo che, da
quanto letto, ci potrebbero essere più contro che pro (campi identity mal
gestiti, server principale molto più appesantito, disaster recovery più
complesso che con il log shipping, ecc...). Forse è meglio restare sul
LogShipping che dici?


 che dici?
...con frequenze di ship così brevi il server secondario puoi utilizzarlo 
ben poco ed anche uno scenario di replica con aggiornamenti frequenti o 
peggio con "immediate update" si traduce in un onere non indifferente per il 
server principale. A questo punto valuterei di rivedere la tua architettura 
in funzione dell'obiettivo che vuoi realizzare e di cui non fai traccia nei 
precedenti post. Quali sono i motivi per cui vuoi "duplicare" i dati per 
mezzo della replica o del log shipping?
Tipicamente una soluzione basata sul log shipping si mette su al fine di 
dirottare su di esso tutte quelle attività di query intensive (attività DSS 
o di reporting) che non necessitano di informazioni aggiornate all'ultimo 
minuto (tipicamente si analizzano i dati delle vendite dei mesi/settimane 
precedenti) e che quindi rendono più che sufficiente un allineamento 
giornaliero o settimanale con il primary server. Un'altro possibile utilizzo 
è per ridurre il traffico wan tra le sedi periferiche e la sede centrale 
permettendo di utilizzare il server locale (secondario) per tutte quelle 
attività che non richiedono dati real-time e dirottare alla sede centrale 
sulla rete wan le query che richiedono dati in tempo reale...
Come vedi quindi la scelta migliore dipende in primo luogo dalle ragioni che 
ti spingono a cercare una soluzione...


 mezzo della replica o del log shipping?
Certo, mi spiego meglio. Essendo il db di produzione aggiornato
costantemente (anche 30 insert al minuto per 24 ore al giorno)ho 2 tipi di
necessità, la prima è quella di avere un backup il più aggiornato
possibile con la produzione, minore infatti è il divario di dati tra il
primario e il secondario e minore saranno i danni dovuti alla conseguente
perdita di dati.
Inoltre è anche fondamentale ce il secondario possa prendere il posto del
primario nel più breve tempo possibile.
Il secondo è quello di avere un secondario il più aggiornato possibile con
la produzione che mi permetta di eseguire delle select, in modo da evitare
di sovraccaricare il primario delegando appunto al secondario tutto quello
che concerne la reportistica (ricerche, statisctiche ecc..).
Immagino però che uno strumento di "scrivi e copia"  istantanea non sia
disponibile su SQL2000, forse qualcosa di simile ci sarà sul SQL2005 mi
pare di aver capito. 


 SQL2005 mi pare di aver capito.
Oggi hai a disposizione le transazioni distribuite, log shipping e replica 
(queste ultime 2 introducono un tempo di latenza che va negoziato). SQL 
Server 2005 metterà a disposizione anche il DB-Mirroring.


 di backup e non sovrapponendosi ad essa...
Certo, faccio il backup completo della produzione 2 volte al giorno.
Ovviamente avendo perň un db secondario, tramite il log shpping, che č 
ben piů aggiornato di qualsiasi backup mi appoeggerei su quello in caso di
disaster. Grazie per la preziosa collaborazione.
