Wprowadź zmiany schematów w bazach publikacji

Dotyczy:SQL Server Azure SQL Managed Instance

Replikacja obsługuje szeroką gamę zmian schematu w opublikowanych obiektach. Jeśli wprowadzisz dowolną z następujących zmian schematu w odpowiednim opublikowanym obiekcie w programie Microsoft SQL Server Publisher, ta zmiana jest domyślnie propagowana do wszystkich subskrybentów programu SQL Server:

ALTER TABLE
ALTER TABLE SET LOCK ESCALATIONNie powinno być używane, jeśli replikacja zmian schematu jest włączona, a topologia obejmuje subskrybentów SQL Server 2005 (9.x) lub SQL Server Compact 3.5.
ALTER VIEW
ALTER PROCEDURE
ALTER FUNCTION
ALTER TRIGGER

ALTER TRIGGER mogą być używane wyłącznie do wyzwalaczy języka manipulacji danymi (DML), ponieważ wyzwalaczy języka definicji danych (DDL) nie mogą być replikowane.

Ważna

Musisz wprowadzać zmiany schematu w tabelach, używając Transact-SQL lub SQL Server Management Objects (SMO). Gdy wprowadzasz zmiany schematu w SQL Server Management Studio, Management Studio próbuje usunąć i odtworzyć tę tabelę. Nie możesz usunąć opublikowanych obiektów, więc zmiana schematu się nie udaje.

W przypadku replikacji transakcyjnej i replikacji łączącej zmiany schematu są stopniowo propagowane, gdy działa Agent dystrybucji lub Agent łączenia. W przypadku replikacji migawki, zmiany schematu są propagowane po zastosowaniu nowej migawki u subskrybenta. W przypadku replikacji migawki nowa kopia schematu jest wysyłana do subskrybenta za każdym razem, gdy następuje synchronizacja. Dlatego wszystkie zmiany schematu (nie tylko te wymienione wcześniej) do wcześniej opublikowanych obiektów są automatycznie propagowane przy każdej synchronizacji.

Aby uzyskać informacje o dodawaniu i usuwaniu artykułów z publikacji, zobacz Dodawanie artykułów do istniejących publikacji i usuwanie ich z nich.

Aby replikować zmiany schematu

Zmiany schematu wymienione wcześniej są domyślnie replikowane. Aby uzyskać informacje na temat wyłączania replikacji zmian schematu, zobacz Replikowanie zmian schematu.

Rozważania dotyczące zmian schematu

Podczas replikowania zmian schematu należy wziąć pod uwagę następujące zagadnienia.

Zagadnienia ogólne

Zmiany schematu podlegają wszelkim ograniczeniom narzuconym przez Transact-SQL. Na przykład ALTER TABLE nie pozwala modyfikować kolumn klucza podstawowego.
Mapowanie typów danych odbywa się tylko dla początkowej migawki. Zmiany schematu nie odzwierciedlają poprzednich wersji typów danych. Na przykład, jeśli używasz ALTER TABLE ADD datetime2 column w SQL Server 2012 (11.x), typ danych nie tłumaczy się na nvarchar dla subskrybentów SQL Server 2005 (9.x). W niektórych przypadkach zmiany schematu są blokowane na Publisher.
Jeśli ustawisz publikację tak, aby umożliwiała propagację zmian schematu, propaguje ona zmiany schematu niezależnie od tego, jak ustawisz powiązaną opcję schematu dla artykułu w publikacji. Jeśli na przykład zdecydujesz się nie replikować ograniczeń klucza obcego dla artykułu tabeli, ale następnie wydasz polecenie ALTER TABLE, które doda klucz obcy do tabeli u wydawcy, klucz obcy zostanie dodany do tabeli u subskrybenta. Aby zapobiec temu zachowaniu, wyłącz propagację zmian schematu przed wydaniem ALTER TABLE polecenia.
Zmiany schematu dokonywaj tylko u Publisher, nie u Subskrybentów (w tym ponowne publikowanie Subskrybentów). Replikacja scalania uniemożliwia wprowadzanie zmian w schemacie u subskrybenta. Replikacja transakcyjna nie zapobiega zmianom, ale mogą one powodować niepowodzenie replikacji.
Zmiany propagowane do Subskrybenta ponownie publikującego są domyślnie propagowane do jego Subskrybentów.
Jeśli zmiana schematu odwołuje się do obiektów lub ograniczeń istniejących u publikującego, ale nie u subskrybenta, zmiana schematu powiedzie się u publikującego, ale zakończy się niepowodzeniem u subskrybenta.
Wszystkie obiekty na Subscriber, do których odwołujesz się przy dodawaniu klucza obcego, muszą mieć tę samą nazwę i tego samego właściciela jak odpowiadające im obiekty na Publisher.
Jawne dodawanie, usuwanie lub zmienianie indeksów nie jest replikowane. Każdą zmianę obejmującą indeks określony jawnie należy wykonać osobno dla każdego zestawu replik. Indeksy tworzone niejawnie dla ograniczeń (takich jak ograniczenie klucza podstawowego) są obsługiwane.
Nie jest wspierane zmienianie lub usuwanie kolumn tożsamości, którymi zarządza replikacja. Aby uzyskać więcej informacji na temat automatycznego zarządzania kolumnami tożsamości, zobacz Replikowanie kolumn tożsamości.
Zmiany schematu obejmujące funkcje niedeterministyczne nie są wspierane, ponieważ mogą powodować różnice danych w Publisher i Subscriber (nazywane niezbieżnością). Jeśli na przykład wydasz w Publisher następujące polecenie: ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE(), wartości różnią się, gdy polecenie zostanie zreplikowane do Subscriber i wykonane. Aby uzyskać więcej informacji na temat funkcji niedeterministycznych, zobacz Funkcje deterministyczne i niedeterministyczne.
Jawnie określ ograniczenia. Jeśli nie podajesz wyraźnej nazwy ograniczenia, SQL Server generuje nazwę dla tego ograniczenia, a te nazwy są różne na Publisher i każdym subskrybentze. Ta różnica może powodować problemy podczas replikacji zmian schematu. Na przykład jeśli usuniesz kolumnę u Publikującego i zostanie usunięte powiązane ograniczenie, replikacja podejmuje próbę usunięcia tego ograniczenia u Subskrybenta. Operacja DROP u subskrybenta kończy się niepowodzeniem, ponieważ nazwa więzu jest inna. Jeśli synchronizacja nie powiedzie się z powodu problemu z nazwą ograniczenia, ręcznie usuń ograniczenie u Subskrybenta, a następnie ponownie uruchom Agenta scalania.
Jeśli publikujesz tabelę do replikacji, nie możesz zmienić kolumny w tej tabeli na typ danych XML, jeśli już wygenerowałeś migawkę publikacji. Aby zmienić kolumnę, najpierw trzeba usunąć replikację.
Odczyt niezatwierdzonych danych nie jest obsługiwanym poziomem izolacji podczas wykonywania operacji DDL na opublikowanej tabeli.
Nie używaj SET CONTEXT_INFO do modyfikowania kontekstu transakcji, gdzie zmiany schematu są wykonywane na opublikowanych obiektach.

Dodawanie kolumn

Aby dodać nową kolumnę do tabeli i uwzględnić ją w istniejącej publikacji, wykonaj ALTER TABLE <Table> ADD <Column>. Domyślnie kolumna jest następnie replikowana do wszystkich subskrybentów. Kolumna musi dopuszczać NULL wartości lub zawierać domyślne ograniczenie. Więcej informacji o dodawaniu kolumn można znaleźć w sekcji "Merge Replication" w tym artykule.
Aby dodać nową kolumnę do tabeli i nie uwzględniać jej w istniejącej publikacji, wyłącz replikację zmian schematu, a następnie wykonaj ALTER TABLE <Table> ADD <Column>.
Aby uwzględnić istniejącą kolumnę w istniejącej publikacji, użyj sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) lub okna dialogowego Właściwości publikacji — <publikacja> .

Aby uzyskać więcej informacji, zobacz Definiowanie i modyfikowanie filtru kolumny. Ta akcja wymaga ponownego uruchomienia subskrypcji.
Dodanie kolumny tożsamościowej do opublikowanej tabeli nie jest obsługiwane, ponieważ może to prowadzić do rozbieżności, gdy kolumna jest replikowana do subskrybenta. Wartości w kolumnie tożsamości w programie Publisher zależą od kolejności, w której wiersze tabeli, których dotyczy problem, są fizycznie przechowywane. Wiersze mogą być przechowywane inaczej u subskrybenta; dlatego wartość kolumny identity może być inna w przypadku tych samych wierszy.

Zrzucanie kolumn

Aby usunąć kolumnę z istniejącej publikacji i usunąć kolumnę z tabeli w Publisher, wykonaj ALTER TABLE <Table> DROP <Column>. Domyślnie kolumna jest następnie usuwana z tabeli u wszystkich subskrybentów.
Aby usunąć kolumnę z istniejącej publikacji, ale zachować ją w tabeli u Wydawcy, użyj sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) lub okna dialogowego Właściwości publikacji — <Publikacja>.

Aby uzyskać więcej informacji, zobacz Definiowanie i modyfikowanie filtru kolumny. Ta akcja wymaga wygenerowania nowego snapshota.
Nie możesz użyć kolumny do wrzucania klauzul filtrujących żadnego artykułu lub publikacji w bazie danych.
Usuwając kolumnę z opublikowanego artykułu, należy uwzględnić wszelkie ograniczenia, indeksy lub właściwości kolumny, które mogą wpłynąć na bazę danych. Przykład:
- Nie można usuwać kolumn używanych w kluczu głównym z artykułów w publikacjach transakcyjnych, ponieważ replikacja ich używa.
- Nie można usunąć kolumny rowguid z artykułów w publikacjach scalonych ani kolumny mstran_repl_version z artykułów w publikacjach transakcyjnych, które obsługują aktualizację subskrypcji, ponieważ replikacja ich używa.
- Zmiany indeksu nie są przekazywane subskrybentom. Jeśli usuniesz kolumnę u wydawcy, a powiązany indeks zostanie usunięty, usunięcie indeksu nie jest replikowane. Przed usunięciem kolumny u Publikującego należy usunąć indeks u Subskrybenta, aby usunięcie kolumny zakończyło się powodzeniem, gdy zostanie zreplikowane z Publikującego do Subskrybenta. Jeśli synchronizacja nie powiedzie się z powodu indeksu u Subskrybenta, ręcznie usuń indeks, a następnie ponownie uruchom Merge Agent.
- Wyraźnie określ ograniczenia, aby móc z nich zrezygnować. Więcej informacji można znaleźć w sekcji "Ogólne rozważania" wcześniej w tym artykule.

Replikacja transakcyjna

Zmiany schematu są propagowane do subskrybentów korzystających z wcześniejszych wersji programu SQL Server, ale instrukcja DDL powinna zawierać tylko składnię obsługiwaną przez wersję używaną u subskrybenta.

Jeśli subskrybent ponownie publikuje dane, jedynymi obsługiwanymi zmianami schematu są dodawanie i usuwanie kolumny. Wprowadzaj te zmiany na serwerze Publisher, używając sp_repladdcolumn (Transact-SQL) i sp_repldropcolumn (Transact-SQL) zamiast ALTER TABLE składni DDL.
Zmiany schematu nie są replikowane dla subskrybentów spoza SQL Server.
Zmiany schematu nie są propagowane od wydawców innych niż SQL Server.
Nie możesz zmieniać widoków indeksowanych, które są replikowane jako tabele. Możesz modyfikować widoki indeksowane, które są replikowane jako widoki indeksowane, ale ich modyfikacja powoduje, że stają się zwykłymi widokami zamiast widokami indeksowanymi.
Jeśli publikacja obsługuje subskrypcje z natychmiastową aktualizacją lub z aktualizacją kolejkowaną, przed wprowadzeniem zmian schematu wstrzymaj działanie systemu: zatrzymaj wszelką aktywność w publikowanej tabeli u Wydawcy i Subskrybentów oraz rozpropaguj wszystkie oczekujące zmiany danych do wszystkich węzłów. Po rozprzestrzenieniu się zmian schematu do wszystkich węzłów, aktywność może wznowić się na opublikowanych tabelach.
Jeśli publikacja znajduje się w topologii peer-to-peer, należy wstrzymać działanie systemu przed wprowadzeniem zmian w schemacie. Aby uzyskać więcej informacji, zobacz Quiesce a Replication Topology (Replication Transact-SQL Programming).
Dodanie kolumny znacznika czasu do tabeli oraz mapowanie znacznika czasu do binary(8) powoduje ponowną inicjalizację artykułu dla wszystkich aktywnych subskrypcji.

Replikacja scalająca

Sposób, w jaki replikacja scalania obsługuje zmiany schematu, zależy od poziomu zgodności publikacji, a także od tego, czy migawka jest ustawiona na tryb natywny (domyślny), czy na tryb znakowy:

Aby replikować zmiany schematu, ustaw poziom zgodności publikacji na co najmniej 90RTM. Jeśli subskrybenci używają wcześniejszych wersji SQL Server lub poziom kompatybilności jest poniżej 90RTM, użyj sp_repladdcolumn (Transact-SQL) i sp_repldropcolumn (Transact-SQL) do dodawania i usuwania kolumn. Jednak te procedury są przestarzałe.

Jeśli spróbujesz dodać do istniejącego artykułu kolumnę z typem danych wprowadzonym w SQL Server 2008 (10.0.x), SQL Server ma następujące zachowanie:

	100RTM, migawka natywna	100RTM, migawka znakowa	Wszystkie inne poziomy zgodności
hierarchyid	Zezwalaj na zmianę	Blokuj zmianę	Blokuj zmianę
geografia i geometria	Zezwalaj na zmianę	Zezwalaj na zmianę*	Blokuj zmianę
Filestream	Zezwalaj na zmianę	Blokuj zmianę	Blokuj zmianę
date, time, datetime2 i datetimeoffset	Zezwalaj na zmianę	Zezwalaj na zmianę*	Blokuj zmianę

*Subskrybenci SQL Server Compact konwertują te typy danych po stronie subskrybenta.

Jeśli wystąpi błąd podczas stosowania zmiany schematu (na przykład błąd wynikający z dodania klucza obcego, który odwołuje się do tabeli niedostępnej dla subskrybenta), synchronizacja nie powiedzie się, a subskrypcja musi zostać ponownie zainicjowana.
Jeśli w kolumnie używanej w filtrze złączenia lub filtrze parametryzowanym zostanie wprowadzona zmiana schematu, należy ponownie zainicjować wszystkie subskrypcje i ponownie wygenerować migawkę.
Replikacja scalająca udostępnia procedury składowane umożliwiające pomijanie zmian schematu podczas rozwiązywania problemów. Aby uzyskać więcej informacji, zobacz sp_markpendingschemachange (Transact-SQL) i sp_enumeratependingschemachanges (Transact-SQL).

Opinia

Czy ta strona była pomocna?

Last updated on 2026-09-24