none
Replica dati tra Istanze MSSQLServer 2005 Vs MSSQLServer 2012 RRS feed

  • Domanda

  • Ciao a tutti.

    Devo configurare una replica programmata da un Database attualmente su MSSQLServer 2015 in casa del Cliente , verso una istanza dedicata configurata in DataCenter MSSQLServer 2012.

    Sono alla ricerca di una guida step by step "ben fatta" per poter implementare la procedura. Avreste qualche consiglio preventivo da fornirmi in merito ? Particolari attenzioni / scelte / raccomandazioni di cui devo tener di conto ? Mi ricordo che quando implementai una procedura di replica con tra due ormai fossili SQLServer 2000,  il bagno di sangue fu abbondante ma sono anche certo che le tecnologie in merito siano cambiate e migliorate sensibilmente.

    Grazie a tutti in anticipo per i pareri in merito che potrete fornirmi.


    Hunternet

    lunedì 10 ottobre 2016 15:07

Risposte

  • "Serenità", e "Repliche" son due parole che mal si conciliano :D

    Scherzo...dunque, così di primo acchito direi che la replica transazionale fa al caso nostro.

    Dato che parliamo di SQL 2005 e SQL 2012, mi affiderei a questo link:

    Fonte: https://msdn.microsoft.com/en-us/library/ms143699(v=sql.110).aspx

    1)Non ci sono problemi di versione, un publisher 2005 può avere subscribers 2012.

    2)Dato che il publisher è SQL 2005, il distributor può essere di qualsiasi versione purchè sia successiva al 2005. Potrai scegliere quindi di implementare una replica push o pull. La differenza è data dal server che sceglierai come distributor, tale istanza ospiterà il database distribution e i job di replica, pertanto avrà maggior carico. Di solito in uno scenario come questo, scelgo la push, con un solo subscriber il carico di lavoro per la macchina è irrisorio. Valuta tu, in ogni caso troverai altre info nel seguente link:

    https://msdn.microsoft.com/en-us/library/ms151170.aspx

    3)Il piccolo volume di dati, e il fatto che solo alcuni articoli (tabelle) saranno replicati, confermerebbe la transazionale come scelta ottimale.

    4)L'agent di replica può girare sempre (continuously), ondemand, o avere una schedulazione: quest'ultima opzione fa al caso tuo.

    5)Sono contento sia monodirezionale. In caso contrario le opzioni (P2P, merge) avrebbero aumentato un poco il coefficiente di difficoltà, e il troubleshooting...altrochè "serenità indotta" eheh ;)

    6)Per la VPN non ci sono problemi, fintantochè le macchine si vedono...

    Come mai vuoi installare un'altra istanza? Pensavi ad un distributor dedicato?

    (non mi sono dimenticato che vorresti un tutorial, attendo riscontro della tua ricerca per un confronto!)

    • Contrassegnato come risposta HunterNet79 mercoledì 12 ottobre 2016 14:16
    mercoledì 12 ottobre 2016 13:28

Tutte le risposte

  • Ciao,

    le possibili opzioni per configurare un sistema di distribuzione dei dati basato su SQL Server sono molteplici.

    Saremmo felici di poterti consigliare la strada migliore, se potrai chiarire alcuni punti sui tuoi requisiti.

    - i dati cambiano frequentemente nell'arco della giornata?

    - le modifiche avvengono frequentemente in piccoli volumi, o di rado in grosse quantità? 

    - per il tuo cliente è accettabile che l'istanza non venga aggiornata in tempo reale?

    - il volume dei dati da spostare è considerevole?

    - la replica dei dati deve essere monodirezionale?

    Come avrai potuto intuire, le risposte a queste domande possono aiutare a capire se ciò di cui hai bisogno è una replica snapshot, una transazionale, o una merge.

    Aggiungo che, in caso i dati debbano anche essere trasformati, valuterei una soluzione ETL (integration services), e in alcuni scenari ho visto clienti avvalersi di soluzioni di alta affidabilità per raggiungere questo scopo (i.e. logshipping).

    Luca


    PS Chiedo venia, non avevo fatto caso alla versione del publisher (2005). In tal caso, una volta chiarita l'esigenza, bisognerà fare i conti anche con il possibile vincolo tecnico di versione (se non sbaglio potremmo già scartare la replica merge)
    • Modificato Luca Bruno lunedì 10 ottobre 2016 20:05
    lunedì 10 ottobre 2016 19:17
  • Ciao, grazie della risposta e della "serenità indotta" ! :-)

    Domani avrò una call con il Cliente nella quale potrò fare una panoramica completa della situazione, rispondere esattamente alle domande poste e confermare le versioni dei prodotti in essere.

    Grazie infinite.


    Hunternet

    martedì 11 ottobre 2016 09:50
  • Eccomi qua, dunque... apparecchio la situazione: 

    • Il Publisher è un MSSQLServer 2005.
    • La replica coinvolgerà soltanto alcune tabelle.
    • Le modifiche previste saranno di lieve entità  (pochi record per volta)
    • La replica dovrà avere cadenza doppia in giornata: pausa pranzo e chiusura.
    • La replica dovrà essere monodirezionale.
    • Tra i due MSSQLServer ci sarà una VPN punto punto.

    Ora dovremmo avere tutti i dati necessari per fare la scelta.

    Come prima cosa mi chiedo se posso installare tranquillamente un MSSQLServer di ultima versione 
    (2014 , 2016?) per poter raccogliere i dati provenienti dal 2005 .

    Sto studiando i tipi di repliche possibili ... per poi confrontarmi con voi .

    Vi ringrazio tutti anticipatamente.


    Hunternet

    mercoledì 12 ottobre 2016 09:41
  • "Serenità", e "Repliche" son due parole che mal si conciliano :D

    Scherzo...dunque, così di primo acchito direi che la replica transazionale fa al caso nostro.

    Dato che parliamo di SQL 2005 e SQL 2012, mi affiderei a questo link:

    Fonte: https://msdn.microsoft.com/en-us/library/ms143699(v=sql.110).aspx

    1)Non ci sono problemi di versione, un publisher 2005 può avere subscribers 2012.

    2)Dato che il publisher è SQL 2005, il distributor può essere di qualsiasi versione purchè sia successiva al 2005. Potrai scegliere quindi di implementare una replica push o pull. La differenza è data dal server che sceglierai come distributor, tale istanza ospiterà il database distribution e i job di replica, pertanto avrà maggior carico. Di solito in uno scenario come questo, scelgo la push, con un solo subscriber il carico di lavoro per la macchina è irrisorio. Valuta tu, in ogni caso troverai altre info nel seguente link:

    https://msdn.microsoft.com/en-us/library/ms151170.aspx

    3)Il piccolo volume di dati, e il fatto che solo alcuni articoli (tabelle) saranno replicati, confermerebbe la transazionale come scelta ottimale.

    4)L'agent di replica può girare sempre (continuously), ondemand, o avere una schedulazione: quest'ultima opzione fa al caso tuo.

    5)Sono contento sia monodirezionale. In caso contrario le opzioni (P2P, merge) avrebbero aumentato un poco il coefficiente di difficoltà, e il troubleshooting...altrochè "serenità indotta" eheh ;)

    6)Per la VPN non ci sono problemi, fintantochè le macchine si vedono...

    Come mai vuoi installare un'altra istanza? Pensavi ad un distributor dedicato?

    (non mi sono dimenticato che vorresti un tutorial, attendo riscontro della tua ricerca per un confronto!)

    • Contrassegnato come risposta HunterNet79 mercoledì 12 ottobre 2016 14:16
    mercoledì 12 ottobre 2016 13:28
  • Simpatico e non presuntuoso oltre che competente e disponibile , San Luca ? :-)

    Veniamo a noi :

    • Sicuramente Replica Transazionale 
    • Il SQL Server "nuovo" deve essere ancora installato (ecco perchè parlavo di nuova istanza) e sinceramente più che un 2012 pensavo ad un MSSQL 2014 se non un addirittura 2016 (standard)  (te che dici ? oso?). :-)
      Su questa istanza , in datacenter e quindi facilmente più potente/potenziabile, penserei di installare anche il ruolo di "distributor".
    • Riguardo la guida "step by step" sto leggendo questa: 
      http://www.codeproject.com/Articles/715550/SQL-Server-Replication-Step-by-Step
      e questa: 
      http://blog.extreme-advice.com/2012/11/26/setup-transaction-replication-in-sql-server-2012/

    Intanto installo il SQLServer e mi faccio configurare la VPN ... poi sono "quasi certo" che ci risentiremo in merito ... :-)

    Mille grazie ...  per ora ! 


    Hunternet

    mercoledì 12 ottobre 2016 13:53
  • Ahimè, purtroppo con SQL 2014/2016 avresti un salto superiore a due versioni (dal 2005)...

    A Subscriber to a transactional publication can be any version within two versions of the Publisher version. For example: a SQL Server 2005 Publisher can have Subscribers running SQL Server 2005, SQL Server 2008 (including SQL Server 2008 R2), or SQL Server 2012; and a SQL Server 2012 Publisher can have Subscribers running SQL Server 2005, SQL Server 2008 (including SQL Server 2008 R2), or SQL Server 2012.

    Mi sa che ti dovrai accontentare di SQL 2012, pena cambio di strategia/tool...

    mercoledì 12 ottobre 2016 14:10
  • ehhh gggià... ! lo stavo proprio leggendo in questo momento ! 

    Confermo la versione 2012 e i ringraziamenti per tutte le preziose informazioni fornite .

    GRAZIE.

    p.s.
    se credi che possa/debba seguire uno "step by step"  migliore, consiglia pure ... anzi ! :-)


    Hunternet

    mercoledì 12 ottobre 2016 14:16
  • Parto subito con un paio di "consigli" ancora in fase di pianificazione:

    • La lingua delle due istanze può essere diversa vero ? 
      (quella attualmente installata è in italiano, quella che installerò è, ovviamente, in inglese).
    • Mi consigli di creare una utenza "apposita" per far girare la procedura ? 

    • Le operazioni che dovrò andar a fare sul server attualmente in produzione non sono di alcun tipo "impattanti" sulla disponibilità, ne rischio di compromettere altro , corretto ? 

    Ancora grazie in anticipo per quanto potrai rispondermi , intanto sto pensando di creare un ambiente di test per provarla "a freddo" ... :-)


    Hunternet

    mercoledì 12 ottobre 2016 16:49
  • - Sì, la lingua può essere diversa. Quello che conta è la collation del database/dei campi di testo che faranno parte degli articoli in replica, che deve essere identica.

    - Dunque, gli attori in gioco sono fondamentalmente tre, e lavorano in modo indipendente. La best practice al solito è fornire ad ogni servizio un Windows Account con i requisiti minimi necessari per espletare le proprie funzioni...ti elenco i tre profili least privilege per ogni account:

    1)Snapshot Agent -> Deve avere il login su distributor e publisher. Deve essere db_owner nei database contenuti nella pubblicazione. Deve avere accesso in lettura\scrittura nello snapshot folder.

    2)Log Reader Agent -> Deve avere il login su distributor e publisher. Deve essere db_owner nei database contenuti nella pubblicazione.

    3)Distribution Agent -> Deve essere db_owner nel database contenuto nella sottoscrizione. Deve fare parte della PAL (Publication Access List) della pubblicazione.

    Mi sembra di non aver dimenticato niente...al solito, ho visto utilizzare di tutto configurando questi scenari...capisco che avere un unico account a volte possa essere più veloce, però con tre account distinti riduci la superficie di attacco...

    Per quanto concerne l'impatto in produzione, puoi stare tranquillo. Quello che può succedere è che si spacchi (in senso figurato) la replica, se portata verso l'estremo (milionate di update in un'unica transazione, centinaia di articoli in pubblicazione, DML scriteriati che non tengono conto del flusso dei dati). La replica SQL è pur sempre un processo vulnerabile, in quanto composto da più "moving parts" che hanno le proprie criticità (hai un distribution db da curare, la connettività delle istanze da assicurare, dei processi windows - gli agent - da agevolare, i.e. verifica che l'antivirus non rompa le scatole, etc). 

    Un annetto fa mi sono fatto una bella lettura sulle repliche, ti consiglio questo ebook (al momento resta la mia unica "bibbia" sull'argomento):

    The Fundamentals of SQL Server Replication

    Buon appetito!


    • Modificato Luca Bruno giovedì 13 ottobre 2016 05:06
    giovedì 13 ottobre 2016 05:05
  • G R A Z I E 

    Hunternet

    giovedì 13 ottobre 2016 08:47
  • Ciao. 

    Un collega mi suggeriva , per l'esigenza sopra descritta, di non "disturbare" le repliche ma di creare più semplicemente un linked server dal 2012 in DataCenter vs il 2005 del Cliente ed utilizzare uno script di MERGE.

    https://stackoverflow.com/questions/13613983/sql-server-synchronizing-2-tables-on-2-different-databases

    Te che ne pensi ? Opzione valutabile oppure le repliche sono una soluzione piu "standard"  e, forse, verificabile?? 

    Grazie.


    Hunternet

    venerdì 21 ottobre 2016 13:14
  • Hola!

    Certamente è una opzione, però il criterio con il quale costruirai le condizioni nello script di merge saranno sempre valide(*)? I rischi sono di aggiornare tutti i record, tutti i giorni, o di mancare qualche aggiornamento perchè i campi che usi come discriminante non sono stati toccati da un eventuale DML incompleto...una replica transazionale aggiorna SOLO quello che è necessario, e si accorge di QUALSIASI modifica fatta sul record.

    (*)es 1.

    fai lo script di merge che controlla i campi A e B. Arriva un UPDATE sul campo C...tale campo non viene controllato e le due basi dati diventano disallineate...

    (*)es 2.

    fai lo script di merge che controlla solo la chiave, e se esiste vai sempre in aggiornamento. Ogni giorno farai un sacco di update non necessari...

    venerdì 21 ottobre 2016 13:40
  • Ciao e nuovamente grazie.

    In realtà , questa proposta , era volta proprio allo scopo di rendere più snello l'aggiornamento ed evitare che venissero "trasferite" tutte le transazioni comprese anche quelle inutili, non avere le eventuali problematiche di Log da gestire ecc... 

    La necessità è quella di avere alcune tabelle aggiornate "solo" per essere utilizzate da un applicativo WEB che le utilizza per il sito internet.  In realtà se venisse modificato lo schema della tabella lato sorgente , la procedura andrebbe in errore diversamente se fatto con la replica. Sinceramente ho un po di timore a iniziare le configurazione subito in produzione ... come prima cosa, se non sbaglio, devo passare il DB da Recovery model simple a FULL ... schedulando i vari backup del log per non rischiare di saturare lo storage, giusto ? 

    Tu consigli quindi, comunque, la strada della replica ? Giusto ? GRAZIE.


    Hunternet


    • Modificato HunterNet79 venerdì 21 ottobre 2016 15:08
    venerdì 21 ottobre 2016 14:43
  • Le repliche in sé non richiedono full recovery model (un'efficiente backup strategy lo prevede, ma questo è un altro discorso). Il log in entrambi gli scenari non sarà troncato finché i comandi nel transaction log non saranno marcati come processati.

    Quali transazioni consideri inutili nel processo di distribuzione?

    Ti consiglio di lavorare con la metodologia che ti è più affine, con quale ti senti più sicuro e potrai fare troubleshooting in modo più sereno. Se vorrai configurare la replica transazionale, pagherai il costo di dover affrontare  una configurazione più complessa, ma la discrezionalità su cosa distribuire sarà demandata a SQL Server. Se deciderai per un linked server + merge, abbasserai la complessità di realizzazione (forse), ma pagherai il prezzo di dover lavorare molto su criteri\filtri\performance per rendere efficiente il processo.

    domenica 23 ottobre 2016 13:16
  • Assolutamente concorde con te ... mi fa piacere che la tua risposta contenga le stesse valutazione che stavo facendo . Da "sistemista" preferirei sicuramente implementare le repliche e ... non avendole mai configurate sarebbe anche un ottima "scusa" per imparare a farlo .

    Sono forse solo un po' "spaventato" dal farlo, soprattutto in "produzione" ... e non ho ancora trovato una guida "step-step" semplice e chiara in grado di darmi serenità anche sulle tempistiche e messa a punto della configurazione :-) 

    P.s. pensavo ad eventuali transazioni di aggiunta, cancellazione, riaggiunta che poi producono magari gli stessi dati in tabella che non andrebbero quindi replicati a fine giornata con il merge... ma si tratta di ipotesi piuttosto remota.



    Hunternet


    • Modificato HunterNet79 domenica 23 ottobre 2016 13:52
    domenica 23 ottobre 2016 13:40
  • VADA PER LE REPLICHE : Replica transazionale come identificata precedentemente.

    Una cortese precisazione sui "ruoli" e su dove agire con le configurazioni :

    • il SQL2012 in DataCenter sarà il primo sul quale "mettere mano" per battezzarlo "distributor" (è il più personalizzabile tra i due) e  ovviamente "subscriber".
    • Il SQL2005 sarà il secondo sul quale agire per battezzarlo "publischer"
    • I due server non sono ovviamente in dominio tra di loro ma dovranno avere delle utenze  (spero di SQL) in comune ?

    Continuo a cercare e inizio a studiare la procedura ... in settimana sicuramente inizierò la configurazione. Ho trovato questa guida che mi pare molto ben fatta: 

    http://www.sql-server-performance.com/2010/transactional-replication-2008-r2/

    GRAZIE


    Hunternet



    • Modificato HunterNet79 domenica 23 ottobre 2016 14:30
    domenica 23 ottobre 2016 14:23
  •  il SQL2012 in DataCenter sarà il primo sul quale "mettere mano" per battezzarlo "distributor" (è il più personalizzabile tra i due) e  ovviamente "subscriber".

    Il SQL2005 sarà il secondo sul quale agire per battezzarlo "publischer"

    I due server non sono ovviamente in dominio tra di loro ma dovranno avere delle utenze  (spero di SQL) in comune ?

    • Sì, i ruoli sono quelli che avevi definito e sono coerenti con la tua strategia.
    • Puoi usare tranquillamente SQL Authentication (sempre che tu abbia mixed mode abilitato...in caso contrario la faccenda si complica un pochino, ma c'è ugualmente una soluzione...let me know)
    • Domandina: riesci a creare un db fake con una tabella su entrambi i server, e a metterlo in replica prima di toccare i veri db? Potrebbe essere un esercizio utilissimo!
    lunedì 24 ottobre 2016 07:28
  • Assolutamente concorde con il DB di test ! 

    Studiando un po' mi è parso di capire che la Transazionale non puo essere "schedulata" ma replica le singole modifiche senza rischiare di impattare sulla banda... mentre , per poterla schedulare , dovrei usare una Shapshot... che ha il rischio di saturare un po' la banda ma di essere "schedulata/controllata" magari con una email di Log ? 

    Grazie ancora ... per la pazienza sopratutto :-) ... questo post sta diventando un "Manuale" :-)


    Hunternet

    martedì 25 ottobre 2016 10:57
  • Figurati :)

    No, la transazionale può essere schedulata. Lo definisci quando la configuri la prima volta (nel wizard, hai 3 opzioni: onDemand, Continuosly o Define a Schedule), o anche a posteriori, vedi qui 

    Con la snapshot replichi l'intero database, non è quello che cerchi, se ho capito bene...giusto? :)

    martedì 25 ottobre 2016 11:29
  • Perfettissimo: Transazionale 100%.

    Inizi la configurazione e... iniziano  i problemi ! :-)

    Appena provato a configurare il ruolo di Publischer sull'istanza "remota" , uscito il seguente errore: 

    Faccio una ricerca e scopro che lanciando il comando

    Select @@servername mi esce il "vecchio" nome server... che aveva il server probabilmente al momento dell'installazione si SQLServer ! che bello !!!

    Ho trovato come probabilmente risolvere:
    http://www.cryer.co.uk/brian/sqlserver/replication_requires_actual_server_name.htm

    ma sono un po' "preoccupato" per il riavvio necessario (e questo basta schedularlo) ma piu che altro per una possibile mancata raggiungibilità da parte di applicazioni o addirittura me stesso dopo la modifica... :-( per tua esperienza, cambiando questo parametro non si pregiudica connettività "esterne" da parte di applicazioni o ... altro , giusto ??? TEMPO la parola DROP in un comando .... specie accanto a "servername" ... :-( GRAZIE 


    Hunternet

    martedì 25 ottobre 2016 13:31
  • Operazione di "cambio nome" svolta e conclusa con esito positivo . Peccato che stavo configurando erroneamente il publischer come distributor e quindi è stata un operazione "inutile" ma è tutta esperenza" :-)

    Iniziata la configurazione delle repliche . 

    Due domanduccie , visto che sono già "fermo" : 

    • La "share di rete" , deve per forza essere "share" anche se il Distributor e il Subscriber stanno sulla stessa macchina SQL2012 ? e in questo caso che tipo di autorizzazioni e a quali utenti devono essere date ? Stavo rileggendo il tuo post precedente riguardo gli Agent e sinceramente non ho capito che intendi con "AGENT" ... non riconosco i tre ruoli durante la configurazione... e se l'utente deve avere accesso sia al DB che al File System si parla quindi di utenti Windows ... ed essendo due server non in dominio avrò utenze comunque "diverse" .... Aiuto, confusione in testa ... :-(

    • La password richiesta al momento della configurazione del distributor, è utilizzata solo per utilizzo interno delle repliche e non legata ad alcun utente vero ? Ho provato ad impostarla ma quando la setto sul Publischer mi da errore come se non fosse quella corretta.... ma credo sia un problema causato da quanto ho scritto sopra ...

    Hunternet


    • Modificato HunterNet79 mercoledì 26 ottobre 2016 09:00
    mercoledì 26 ottobre 2016 08:54
  • Aggiornamenti: 

    1. Ho terminato la procedura di configurazione del Distributor: apparentemente tutto ok.
    2. Ho terminato la procedura di configurazione del Publischer: appartentemente tutto ok.
      Tranne che devo chiedere al Cliente di inserire PRIMARY KEY COLUMN in ogni tabella che intende replicare pena l'impossibilità di fare replica, GIUSTO ? (Ho continuato al procedura con una di prova avente la chiave)

    3. Ho terminato la procedura di creazione del Subscriber: errore e angoscia ! :-(
      Al termine della configurazione ho ricevuto il seguente errore: 
      Ho verificato e sotto "Local SUBSCRIBER" non ho niente ... così ho provato a ricreare , ma ricevo quest'altro errore: 


      Adesso non so più da che parte "rifarmi" :-(  
      Corretto intanto chiedere al Cliente di creare gli indici per tutte le tabelle interessate ? 
      Mi sai dare una strada (diversa dal cappio) per tentare di risolvere quella che spero potrebbe essere l'ultima fase delle configurazione  ?

    GRAZIE INFINITE.


    Hunternet

    mercoledì 26 ottobre 2016 12:27
  • Scusa, ma ieri non sono riuscito a darti assistenza immediata :)

    Sì, la chiave primaria è un requisito fondamentale e obbligatorio!

    Fai refresh sulle sottoscrizioni e rifai solo la parte di subscription.

    Due domandine:

    Quando hai creato la pubblicazione, hai creato subito uno snapshot?

    Nel wizard, quando ti chiede quando inizializzare la sottoscrizione, hai risposto "Immediately" o "At first Synchronization"?

    mercoledì 26 ottobre 2016 12:47
  • ?? Data la tua competenza in materia, per la tua "assistenza immediata" sarei disposto a cederti una parte di stipendio !!

    Chiave primaria richiesta ! 

    Ho fatto refresh e rifatto la subsription proprio perchè non vedevo niente al riguardo, l'errore che ricevo anche dopo un riavvio del servio è quello sopra.

    Due rispostine per le quali mi scuso subito per come iniziano : 

    "Mi sembra" di si 

    "Mi sembra" immediately  

    Che faccio ??? :-(


    Hunternet

    mercoledì 26 ottobre 2016 13:38
  • Riprovato adesso:

    Non esistono SUBSCRIBER e, rifacendo la sottoscrizione, ricevo lo stesso identico errore .

    HELP, sono nel fango ! :-(

    Dal Replication monitor :


    Hunternet


    • Modificato HunterNet79 giovedì 27 ottobre 2016 09:54
    giovedì 27 ottobre 2016 09:44
  • Hai fatto la prova con il db di test o sei andato direttamente in prod?

    Rifai tutto da capo, vedo che anche la pubblicazione è in errore.

    Scarica questo libro e segui i passi esposti:

    Pag 80 Cancella la Publication.

    Pag 84 Configura il Distributor.

    Pag 106 Crea la Publication.

    Pag 136 Configura la PAL.

    Pag 143 Configura la Subscription.

    Deve funzionare, se non va è perchè manca qualche dettaglio rilevante (tipo quel servername non aggiornato mi inquieta non poco).

    PS se non dovesse funzionare, dovremo procedere step by step. Ricorda gli attori e la topologia:

    Permessi Richiesti

    • Modificato Luca Bruno giovedì 27 ottobre 2016 12:26
    giovedì 27 ottobre 2016 11:06
  • Ciao, aggiornamento:
    Ho distrutto e rifatto tutto con attenzione.

    Pur non avendo ricevuto ALCUN ERRORE (a differenza di prima) mentre vedo l'oggetto sotto "LocalPubblications" del Cliente, non vedo ancora NIENTE sotto Local Subscriptions del server in DataCenter (Distributor e Subscriber).
    E' normale e mi sto incaponendo in una cosa che non dovrei vedere o c'è qualche problema secondo te ? 

    Riguardo invece lo "Snapshot Folder" lo vedo ancora e continuamente "vuoto" , regolare cosi ? 

    Riguardo il Monitor delle Repliche dove sto cercando di capire qualcosa, invece, la situazione è anomale :-( :
    Inizialmente l'ho trovata in errore: 

    Dopo aver stoppato , riavviato il servizio e avviata la sincronizzazione in apparenza le cose SEMBRA che inizino a funzionare: 


    Dopo qualche minuto, però, torna in errore. 

    Un ultima domanda: il SQLServer AGENT, di uno e dell'altro server , devono partire con un utente specifico di quelli impostati ??  Mi sembra di essere vicino all'uscita ... ma di non riuscire a vederla ... 
    (quel libro non ho purtroppo le "tempistiche" per acquistarlo e studiarlo , prometto che lo farò appena possibile).

    Grazie ancora.


    Hunternet

    giovedì 27 ottobre 2016 14:47
  • L'ebook che ti sto suggerendo è gratuito, non ti proporrei mai qualcosa a pagamento.

    Cercalo qui, c'è anche il link per il download:

    Se segui da pag 34 ci sono tutti gli screenshots per completare una replica transazionale da zero.

    Comunque: se hai fatto lo snapshot subito dopo la pubblicazione, dovresti vedere dei files nello share folder.

    Quando hai creato la replica, nel tab security cosa hai messo?

    (per intenderci, qui)

    Che errore ti dà il replication monitor?


    • Modificato Luca Bruno giovedì 27 ottobre 2016 14:59
    giovedì 27 ottobre 2016 14:58
  • Libro scaricato! Grazie mille, mi ero fermato all'apparenza e non avevo visto che era gratis in PDF.

    Net TAB ho messo l'utente Windows che ho creato appositamente (per ora uno soltanto) che è sysadmin (solo per ora) di SQLServer. Sotto invece l'utente "SQL" creato per lo stesso scopo e sempre sysadmin...

    L'errore te lo "incollerò" non appena mi sarà possibile lavorare nuovamente a questa configurazione.

    Grazie ancora infinite. Questa replica devo riuscire a completarla in ogni modo ... :-(

    P.s.

    Stavo leggendo il book e... a parte aver utilizzato diversamente le autorizzazioni (non usando l'utente del SQLAgent e non impersonando l'account del processo) mi pare di aver fatto esattamente gli stessi step (mi riservo di rileggere con cura per darti certezza pero). Una cosa su tutte che forse non ti detto e che non capisco è che... sotto SUBSCRIBER (nel distributor) io non vedo ancora niente ! :-( 


    Hunternet


    • Modificato HunterNet79 martedì 1 novembre 2016 17:20
    martedì 1 novembre 2016 17:11
  • Ho replicato l'intera configurazione ... ed ho anche capito che il fatto di "vedere" o meno il suscriber nel mio SQLSRV 2012 dipendeva dalla modalita PULL o PUSH (lo vedo con la seconda).

    Fatto sta che pur seguendo step by step tutte le indicazioni anche del prezioso libro e NON ricevendo errori durante la configurazione se non soltanto il solito warning riguardante lo snapshot al termine della sottoscrizione: 

    La replica non funziona ... e il servizio SnapShot è sempre in "starting" senza partire mai.

    1) mi daresti un tuo parare dove "cercare" l'errore ?? Ho imparato anche modificare i parametri "gia configurati" senza rifare tutto da capo ma non riesco ad uscirne.

    2) Io ho il sospetto si tratti di un problema di permessi.  Che utente deve far partire il servizio SQLSERVERAGENT su un server e sull'altro (pur avendo utilizzato i giusti utenti con le dovute autorizzazioni in configurazione delle repliche) ? 

    3) La password che imposto per la REPLICA mi confermi essere una password NON LEGATA ad alcun utente , univoca e indipendente ? (avevo trovato un articolo che la legava ad sa o altro utente ma mi pare molto strano).


    In oltre ho trovato, nel tasto detro di Replication,  anche UPDATE REPLICATION PASSWORD che, invece, sembra permettere di impostare un set di credenziali utente/password ???

    4) quale è un modo per FORZARE una replica se verificare che succede??
    devo lanciare l'apposito job creato dentro SQLServerAgent e che mi trovo schedulato come avrei desiderato e lo posso forzare per test ? 

    Non so piu dove sbattere il capo :-( questo è l'errore : 

    INFINITE GRAZIE PER TUTTA QUESTA PAZIENZA E TEMPO DEDICATO


    Hunternet



    • Modificato HunterNet79 mercoledì 2 novembre 2016 15:19
    mercoledì 2 novembre 2016 14:27
  • Io credo che l'errore "di tutto" sia qua, nello start dello Snapshot Agent ... che sta in "starting" ma non parte , crolla in errore (come sopra) e non riempe mai il folder di snapshot ....


    Hunternet

    mercoledì 2 novembre 2016 16:40
  • DOVREI AVER RISOLTOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO !

    Sono sfatto, piu tardi posto un feed back in merito... ma gli errori erano due, di base. ;-)


    Hunternet

    mercoledì 2 novembre 2016 17:48
  • Ottimo!!! :-)

    Quali erano gli errori, e come ne sei uscito? Permessi mancanti per lo snapshot agent?

    mercoledì 2 novembre 2016 18:30
  • Mi spiace il ritardo nella risposta ma da allora, non sono ancora riuscito nemmeno a ricollegarmi sulla macchina.

    Ne sono uscito, per ora solo replicando una tabella di test ma non vedrei "sorprese" attivando le altre, rivedendo sia i permessi che le utenze utilizzate in tutti gli Agent e le permission concesse alla cartella di SnapShot. Al momento ho lasciato molta "apertura" di permission, provvederò a restringerle poco alla volta , non appena possibile.  Di tutta la configurazione applicare le corrette permission ed utilizzare le opportune utenze credo sia l'unica parte "complessa" e  che richiede una certa attenzione e precisione. Se il rapporto tra banda di comunicazione e numero di modifiche lo permette, proverei a lasciare una replica "continua" (come è impostata al momento) per evitare picchi di performance in un momento specifico. Vorrei ora riuscire ad approfondire le possibilità di "alert" che posso impostare. 

    In caso decidessi per una replica "on demand" , per "forzarla" , devo eseguire il relativo Job che troverò schedulato nell' Agent, corretto  ?

    E se quanto chiesto è corretto, e quindi la replica ragiona "per job" , come gira la replica continua ? 

    Gli alert a mia disposizione sono sempre legati agli esiti dei Job ? 

    Quanti/quali job mi consigli di monitorare per avere la situazione sotto controllo ? 

    Grazie ancora.

    Hunternet

    martedì 8 novembre 2016 11:24
  • In caso decidessi per una replica "on demand" , per "forzarla" , devo eseguire il relativo Job che troverò schedulato nell' Agent, corretto  ?

    Esattamente, ma sconsiglio questo tipo di configurazione...meglio automatizzare, ove possibile...


    E se quanto chiesto è corretto, e quindi la replica ragiona "per job" , come gira la replica continua ? 

    Gira con dei job che non si interrompono mai, salvo quando vogliono rovinarti la giornata ;)

    Gli alert a mia disposizione sono sempre legati agli esiti dei Job ? 

    Se vai in replication monitor, tab warnings, puoi settare un numero predefinito di alerts basati su KPI o eventi legati alla distribuzione dei dati. Alcuni alerts sono complessi da configurare (imho), io partirei con cose semplici - vedi sotto.

    Quanti/quali job mi consigli di monitorare per avere la situazione sotto controllo ? 

    Il mio consiglio è di configurare ogni job di SQL Server per notificare a uno o più operatori l'eventuale fallimento, a prescindere dalla repliche...in condizioni ottimali non dovresti ricevere emails :)

    Per maggiori info, clicca qui  


    • Modificato Luca Bruno mercoledì 9 novembre 2016 10:33
    mercoledì 9 novembre 2016 10:33