Proteggere il Sottoscrittore
Si applica a: SQL Server database SQL di Azure
Gli agenti di merge e di distribuzione si connettono al Sottoscrittore. Queste connessioni possono essere stabilite nel contesto di un account di accesso di SQL Server o di Windows. È importante specificare un account di accesso appropriato per questi agenti, attenendosi al principio di concedere i diritti minimi necessari e proteggere l'archiviazione di tutte le password. Per informazioni sulle autorizzazioni necessarie per ogni agente, vedere Replication Agent Security Model.
Nota
Istanza gestita di SQL di Azure può essere un server di pubblicazione, un server di distribuzione e un Sottoscrittore per la replica snapshot e transazionale. I database nel database SQL di Azure possono essere solo sottoscrittori push per la replica snapshot e transazionale. Per altre informazioni, vedere Replica transazionale con il database SQL di Azure e con Istanza gestita di SQL di Azure.
Agente di distribuzione
È possibile utilizzare un agente di distribuzione per sottoscrizione, ovvero un agente indipendente in base all'impostazione predefinita per le pubblicazioni create nella Creazione guidata nuova pubblicazione, oppure un agente di distribuzione per coppia di database di pubblicazione e database di sottoscrizione, ovvero un agente condiviso. T
Per specificare le informazioni di connessione per le sottoscrizioni push, vedere Creare una sottoscrizione push.
Per specificare le informazioni di connessione per le sottoscrizioni pull, vedere Creare una sottoscrizione pull.
Agente di merge
Per ogni sottoscrizione di tipo merge è disponibile un agente di merge specifico che si connette sia al server di pubblicazione che al Sottoscrittore, aggiornandoli entrambi.
Per specificare le informazioni di connessione per le sottoscrizioni push, vedere Creare una sottoscrizione push.
Per specificare le informazioni di connessione per le sottoscrizioni pull, vedere Creare una sottoscrizione pull.
Sottoscrizioni ad aggiornamento immediato
Quando si configura una sottoscrizione ad aggiornamento immediato, si specifica un account nel Sottoscrittore con cui vengono stabilite le connessioni al server di pubblicazione. Le connessioni vengono utilizzate dai trigger che si attivano presso il Sottoscrittore e propagano le modifiche al server di pubblicazione. Sono disponibili tre opzioni per il tipo di connessione:
Server collegato creato dalla replica. La connessione viene stabilita con le credenziali specificate in fase di configurazione.
Un server collegato creato dalla replica. La connessione viene eseguita con le credenziali dell'utente che apporta la modifica presso il Sottoscrittore.
Un server collegato o remoto già definito.
Importante
Per specificare le informazioni di connessione, usare la stored procedure sp_link_publication (Transact-SQL). È possibile utilizzare anche la pagina Account di accesso per sottoscrizioni aggiornabili della Creazione guidata nuova sottoscrizione che chiama sp_link_publication. In alcune condizioni, questa stored procedure può avere esito negativo se nel Sottoscrittore è in esecuzione SQL Server 2005 (9.x) Service Pack 1 (SP1) o versioni successive e nel server di pubblicazione è in esecuzione una versione precedente. In caso di esito negativo della stored procedure in questo scenario, aggiornare il server di pubblicazione a SQL Server 2005 (9.x) Service Pack 1 o versioni successive.
Per altre informazioni, vedere Creare una sottoscrizione aggiornabile di una pubblicazione transazionale e Visualizzare e modificare le impostazioni di sicurezza della replica.
Importante
È consigliabile concedere all'account specificato per la connessione solo le autorizzazioni necessarie per l'inserimento, l'aggiornamento e l'eliminazione dei dati delle viste create dalla replica nel database di pubblicazione. Concedere autorizzazioni per le viste del database di pubblicazione con nomi nel formato syncobj_<NumeroEsadecimale> all'account configurato in ogni Sottoscrittore.
Sottoscrizioni ad aggiornamento in coda
Quando si configurano sottoscrizioni ad aggiornamento in coda, è necessario tenere in considerazione due aspetti relativi alla sicurezza.
Esiste un solo agente di lettura coda per ogni server di distribuzione. Per ogni server di distribuzione è consigliabile configurare al massimo una pubblicazione abilitata per le sottoscrizioni ad aggiornamento in coda.
L'agente di lettura coda stabilisce connessioni al server di distribuzione, al server di pubblicazione e a ogni Sottoscrittore:
L'account con cui l'agente viene eseguito e stabilisce connessioni al server di distribuzione viene specificato al momento della creazione dell'agente. Se si utilizza la Creazione guidata nuova pubblicazione, l'agente viene creato quando si crea una pubblicazione abilitata per le sottoscrizioni aggiornabili.
L'account con cui l'agente stabilisce connessioni al server di pubblicazione viene specificato quando si configura la distribuzione per un server di pubblicazione. Specificare l'account di Windows con cui l'agente viene eseguito oppure un account di SQL Server.
L'account con cui l'agente stabilisce connessioni al Sottoscrittore viene specificato quando si crea la sottoscrizione.
Importante
Utilizzare l'autenticazione di SQL Server per le connessioni ai Sottoscrittori e specificare un diverso account per la connessione a ogni Sottoscrittore. Se si utilizza una sottoscrizione pull, la connessione viene sempre impostata dalla replica in modo da utilizzare l'autenticazione di Windows. Per le sottoscrizioni pull, la replica non può infatti accedere ai metadati nel Sottoscrittore necessari per utilizzare l'autenticazione di SQL Server. In questo caso, modificare la connessione in modo da utilizzare l'autenticazione di SQL Server dopo la configurazione della sottoscrizione.
Per altre informazioni, vedere "Procedura: Creare una sottoscrizione aggiornabile di una pubblicazione transazionale (SQL Server Management Studio)" e Visualizzare e modificare le impostazioni di sicurezza della replica.