Share via

Amministrazione di una topologia peer-to-peer (programmazione Transact-SQL della replica)

  • Articolo

L'amministrazione di una topologia peer-to-peer è simile all'amministrazione di una tipica topologia di replica transazionale, sebbene diverse aree richiedano speciali considerazioni. La differenza principale nell'amministrazione di una topologia peer-to-peer consiste nella necessità di mettere il sistema in stato di inattivitàin caso di determinate modifiche. Mettere in stato di inattività un sistema significa arrestare le attività sulle tabelle pubblicate in tutti i nodi e verificare che ogni nodo abbia ricevuto tutte le modifiche dagli altri nodi. Per altre informazioni, vedere Come mettere una topologia di replica in stato di inattività (programmazione Transact-SQL della replica).

Nota

In una topologia peer-to-peer il server di distribuzione non può usare una versione precedente di SQL Server rispetto a un sottoscrittore pull.

Per aggiungere un articolo a una configurazione esistente

  1. Mettere in stato di inattività il sistema.

  2. Arrestare l'agente di distribuzione in ciascun nodo nella topologia. Per altre informazioni, vedere Concetti relativi ai file eseguibili dell'agente di replica o Avviare e arrestare un agente di replica (SQL Server Management Studio).

  3. Eseguire l'istruzione CREATE TABLE per aggiungere la tabella nuova a ogni nodo nella topologia.

  4. Effettuare manualmente la copia bulk dei dati per la nuova tabella in tutti i nodi utilizzando l' utilità bcp.

  5. Eseguire sp_addarticle per creare il nuovo articolo in ogni nodo nella topologia. Per altre informazioni, vedere definire un articolo.

    Nota

    Dopo l'esecuzione di sp_addarticle , la replica aggiunge automaticamente l'articolo alle sottoscrizioni nella topologia.

  6. Riavviare gli agenti di distribuzione in ciascun nodo nella topologia.

Per apportare le modifiche dello schema nel database di pubblicazione

  1. Mettere in stato di inattività il sistema.

  2. Eseguire le istruzioni DLL (Data Definition Language) per modificare lo schema delle tabelle pubblicate. Per altre informazioni sulle modifiche dello schema supportate, vedere Modifiche allo schema nei database di pubblicazione.

  3. Prima di riprendere l'attività nelle tabelle pubblicate, mettere di nuovo il sistema in stato di inattività. Ciò garantisce che le modifiche dello schema siano ricevute da tutti i nodi prima che venga eseguita la replica di nuove modifiche dei dati.

Esempio

Nell'esempio seguente è illustrato come aggiungere un nuovo articolo di tabella a una topologia di replica peer-to-peer esistente con due nodi.

-- Create the new table at both nodes.
CREATE TABLE AdventureWorks2012.dbo.ProductTest (column1 int, Column2 int);
CREATE TABLE AdventureWorks2012Replica.dbo.ProductTest (column1 int, Column2 int);
GO

REM Bulk insert data into both the publication and subscription databases.
REM The BCP format depends on the snapshot format (native or character).
REM Execute at the command prompt.

bcp AdventureWorks2012..ProductTest in NewTable.bcp -T -SMYPUBLISHER n/c
bcp AdventureWorks2012Replica..ProductTest in NewTable.bcp -T -SMYPUBLISHER n/c

--- Add the article to the publication.
DECLARE @publication AS sysname;
DECLARE @newtable AS sysname;
SET @publication = N'AdvWorksProductTran';
SET @newtable = N'ProductTest';

USE AdventureWorks2012

EXEC sp_addarticle 
  @publication = @publication,
  @article = @newtable,
  @source_table = @newtable,
  @destination_table = @newtable,
  @force_invalidate_snapshot = 0;
GO

Vedere anche

Domande frequenti sull'amministrazione della replica
Backup e ripristino di database SQL Server
Peer-to-Peer Transactional Replication