Тиражирование в Microsoft SQL Server версии 7.0


Информация, содержащаяся в этом документе, представляет текущую точку зрения корпорации Microsoft на обсуждаемые вопросы на момент публикации. Поскольку Microsoft должна реагировать на изменяющиеся условия на рынке, документ не следует рассматривать как обязательство со стороны Microsoft; корпорация Microsoft не может гарантировать, что вся представленная информация сохранит точность после даты публикации.

Настоящий документ предназначен только для информационных целей. MICROSOFT НЕ ДАЕТ В ЭТОМ ДОКУМЕНТЕ НИКАКИХ ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ.

©1998 Microsoft Corporation. Все права защищены.

Microsoft, ActiveX, BackOffice, Windows и Windows NT представляют собой зарегистрированные торговые марки либо торговые марки корпорации Microsoft в США и/или других странах.

Другие упоминаемые здесь торговые марки и названия продуктов являются собственностью соответствующих владельцев.

Microsoft Part Number: 098-80829


Содержание

Введение...................................................................................................................................................................

Что такое тиражирование?..........................................................................................................................

Модель тиражирования......................................................................................................................................

Компоненты системы тиражирования SQL Server................................................................................

Масштабируемые решения для тиражирования......................................................................................

Тиражирование снимком..............................................................................................................................

Транзакционное тиражирование...............................................................................................................

Режим немедленного обновления слиянием[KT1] ....................................................................................

Как работает немедленное обновление [KT2] с..........................................................................................

Транзакционное тиражирование с опосредованным обновлением [KT3] на подписчике.....................................

Тиражирование слияния[KT4] .............................................................................................................................

Как работает тиражирование [KT5] слияния..........................................................................................

Разрешение конфликтов на основе приоритетов.........................................................................

Настраиваемое разрешение конфликтов.......................................................................................

Снижение сложности.........................................................................................................................................

Мастера тиражирования............................................................................................................................

Replication Monitor.......................................................................................................................................

Слежение за издателями, публикациями и подписками............................................................

Слежение за агентами тиражирования..........................................................................................

Слежение за сигналами тиражирования.......................................................................................

Протокол событий в приложениях Windows NT..........................................................................

Тиражирование в гетерогенных средах[KT6] .....................................................................................................

Тиражирование в гетерогенные источники данных...........................................................................

Тиражирование из гетерогенных источников данных......................................................................

Вопросы проектирования тиражирования..............................................................................................

Согласованность транзакций...................................................................................................................

Срочная гарантированная согласованность...............................................................................

Несрочная гарантированная согласованность...........................................................................

Сходимость............................................................................................................................................

Пример согласованности транзакций............................................................................................

Автономность узлов.....................................................................................................................................

Разбиение данных для избежания конфликтов....................................................................................

Выбор подходящего типа тиражирования...........................................................................................

Другие распределенные технологии...........................................................................................................

Гетерогенные распределенные запросы...............................................................................................

Microsoft Distributed Transaction Coordinator........................................................................................

Data Transformation Services.....................................................................................................................

Заключение...........................................................................................................................................................

 


Введение

Тиражирование (replication) обеспечивает быстрый и надежный способ распространения корпоративной информации по нескольким пунктам назначения в условиях распределенной компании, что позволяет организациям приблизить данные к нуждающимся в них работникам в штаб-квартирах, филиалах и мобильных офисах. Этот документ содержит информацию о том, какие средства тиражирования доступны в Microsoft® SQL Server версии 7.0 и каким образом они помогают увеличить возможности пользователей, улучшить принятие решений и повысить производительность и надежность существующих систем за счет снижения зависимости от централизованных данных.

Что такое тиражирование?

Что общего у хранилища данных, корпоративной интрасети и приложения автоматизации отдела продаж? Помимо использования баз данных для хранения информации, все эти типы приложений требуют быстрого и надежного перемещения данных в рамках организации. Например, хранилище данных получает сведения о продажах из системы обработки заказов, приложение для корпоративной интрасети передает финансовые данные с узла в Нью-Йорке на узел в Японии, а система автоматизации службы продаж копирует информацию о клиенте на блокнотный компьютер местного торгового представителя.

Сегодня все больше и больше бизнес-приложений проектируется для работы в распределенной вычислительной среде. Помимо использования распределенных вычислений в сетях с рабочими станциями, серверами и унаследованными системами, например, мэйнфреймами, организации все чаще начинают предоставлять доступ к прикладным программам, работающим в центральном офисе, своим региональным представительствам, партнерам и мобильным офисам, т.е. переносным компьютерам сотрудников. [KT7] 

Географическая распределенность офисов и сотрудников требует круглосуточного доступа и развитых систем контроля, а также более жесткого обеспечения целостности данных. Ситуация осложняется тем, что в большинстве организаций сформировалась запутанная смесь разнородных сетей и вычислительных платформ. Таким образом, сегодня администратору приходится решать, как  лучше всего осуществить своевременное распространение больших объемов данных по гетерогенным системам.

С помощью тиражирования пользователи могут копировать данные из одной базы данных SQL Server в другие базы по всей компании. Система тиражирования SQL Server 7.0 преследует следующие цели:

·     Масштабируемые решения для тиражирования

Полный набор масштабируемых средств тиражирования, удовлетворяющих весь спектр потребностей приложений.

·     Более низкая сложность тиражирования

Снижение [KT8] затрат и сложности, облегчается построение, управление и применение тиражирования.

·     Гетерогенность и интегрируемость

Возможность [KT9] двунаправленного тиражирования для гетерогенных источников данных, а также легкую интеграцию с приложениями третьих фирм.

Модель тиражирования

Система тиражирования Microsoft SQL Server версии 7.0 опирается на модель публикации и подписки (publish and subscribe), впервые появившуюся в SQL Server версии 6.0. Эта модель включает издателей, подписчиков и дистрибуторов, публикации и статьи, а также подписку в режиме оповещения (push) и опроса (pull). Процессом тиражирования в SQL Server 7.0 управляют четыре новых интеллектуальных агента — агент  тиражирования снимком (Snapshot Agent), агент анализа протокола тиражирования (Log Reader Agent), агент распространения (Distribution Agent) и агент тиражирования слиянием (Merge Agent). [KT10] Все они могут работать в рамках агента SQL Server (SQL Server Agent) и допускают полноценное администрирование с помощью SQL Server Enterprise Manager. Агенты тиражирования снимком и анализа протоколов выполняются на сервере-дистрибуторе, тогда как агенты распространения и слияния при подписке в режиме оповещения работают на сервере-дистрибуторе, а при подписке в режиме опроса — на сервере-подписчике. Система тиражирования SQL Server использует стандартные для отрасли интерфейсы доступа к данным OLE DB и ODBC, что открывает богатые возможности интеграции с широким спектром реляционных и нереляционных источников данных.

Компоненты системы тиражирования SQL Server

Издатель (Publisher)

Это сервер, который предоставляет доступ к данным для копирования на другие серверы. Издатель определяет, какие данные необходимо скопировать, а также обнаруживает изменение данных и поддерживает информацию о всех публикациях данного узла. Любой подвергающийся тиражированию элемент данных имеет лишь одного издателя, хотя его может обновлять любое число подписчиков, а любой подписчик может снова опубликовать данные.

Подписчики (Subscribers)

Это серверы, которые сохраняют копии данных и получают обновленную информацию. В предыдущих версиях SQL Server обновление можно было осуществить только на сервере-издателе, однако SQL Server 7.0 позволяет обновлять данные подписчикам (хотя подписчик, выполняющий обновление, не является издателем). В свою очередь, подписчик может стать издателем для других подписчиков.

Публикация (Publication)

Представляет собой просто набор статей, а статья (article) — это группа данных для тиражирования. В качестве статьи может выступать вся таблица целиком, только определенные ее столбцы (при использовании вертикального фильтра), только определенные строки (при использовании горизонтального фильтра) или даже хранимая процедура (в некоторых типах тиражирования). Публикация часто содержит несколько статей.

Дистрибутор (Distributor)

Это сервер, который содержит базу данных распространения. Точная роль дистрибутора в SQL Server зависит от конкретного типа тиражирования.

Агент тиражирования снимком (Snapshot Agent)

Готовит схему и исходные файлы данных для публикуемых таблиц и хранимых процедур, сохраняет этот снимок (snapshot) на сервере-дистрибуторе и заносит в базу данных распространения информацию о синхронизации. Каждая публикация обслуживается своим собственным агентом тиражирования снимком, который работает на дистрибуторе и связывается с издателем.

Агент анализа протоколов (Log Reader Agent)

Перемещает отмеченные для копирования транзакции из протокола транзакций на издателе в базу данных распространения. Каждая база данных, опубликованная с помощью транзакционного тиражирования, обслуживается своим собственным агентом анализа протоколов. Он выполняется на сервере-дистрибуторе и связывается с издателем.


Агент распространения (Distribution Agent)

Передает подписчикам транзакции и снимки, хранящиеся в базе данных распространения. Транзакционные и тиражируемые снимком публикации, для которых при создании новой подписки задан режим немедленной синхронизации, обслуживаются своим собственным агентом распространения, работающим на сервере-дистрибуторе и связывающимся с подписчиком. Публикации, не использующие немедленную синхронизацию, обслуживаются одним общим агентом распространения для каждой пары издатель-подписчик. Он также выполняется на сервере-дистрибуторе и связывается с подписчиком. При подписке в режиме опроса агенты распространения как для снимочных, так и для транзакционных публикаций работают на подписчике, а не на дистрибуторе. Как правило, агент распространения выполняется под SQL Server Agent и допускает непосредственное управление с помощью SQL Server Enterprise Manager.

Агент слияния (Merge Agent)

Осуществляет перенос и согласование инкрементальных изменений данных, которые произошли после создания первоначального снимка. При тиражировании слияния данные перемещаются либо в обоих (сначала от подписчика к издателю, а затем от издателя к подписчику), либо только в одном направлении. Каждая публикация слияния обслуживается своим собственным агентом слияния, связывающимся с издателем и подписчиком и обновляющим информацию на обоих серверах. При подписке на такие публикации в режиме оповещения агент слияния выполняется на издателе, а в режиме опроса — на подписчике. Тиражируемые снимками и транзакционные публикации не используют агенты слияния. С помощью управляющего элемента Microsoft ActiveX® агент слияния также можно встроить в приложение, управляющее его работой.

Подписка в режиме опроса (Pull subscription)

В этом случае подписчик периодически запрашивает информацию о всех изменениях данных на издателе. Подписка в режиме опроса лучше всего подходит для публикаций, имеющих большое число подписчиков (например, если подписчики используют Интернет). Кроме того, она очень удобна для самостоятельных мобильных пользователей, поскольку позволяет им самим определять момент синхронизации изменений в данных. Для доступа к одной и той же публикации можно использовать подписку как в режиме оповещения, так и в режиме опроса.

Подписка в режиме оповещения (Push subscription)

В этом случае издатель передает изменения подписчику без специального запроса с его стороны. Подписка в режиме оповещения применяется, когда изменения необходимо распространять сразу после их возникновения или когда график обновления должен задаваться издателем.

Масштабируемые решения для тиражирования

В задачах тиражирования не существует универсальных решений. Компании предъявляют к приложениям различные требования, и Microsoft SQL Server 7.0 предлагает широкий набор решений для тиражирования, которые позволяют их удовлетворить. Давайте представим себе спектр таких требований. На одном его конце находится автономность узла (все узлы работают без связи друг с другом), а на другом — согласованность транзакций (гарантируется, что все узлы будут располагать в точности одинаковыми значениями данных точно в одно и то же время).

consist.gif

Выбор подходящего решения для тиражирования будет определяться положением приложения в этом спектре требований. Например, давайте сопоставим требования к системе автоматизации службы продаж и системе учета счетов. Оба этих приложения используют тиражирование для распространения данных. Тем не менее мобильные торговые представители компании могут принимать заказы у клиентов с помощью блокнотных компьютеров, без подключения к сети центрального офиса. Отсутствие связи с сетью (и точной информации о складских запасах) не мешает представителю принять и передать заказ. Таким образом, в приложении службы продаж необходимость автономии перевешивает риск принять заказ на товар, отсутствующий на складе (предварительные заказы допускаются). Напротив, рассылаемые отделом учета счета должны быть совершенно точными и содержать текущую информацию для проверки. В этом случае согласованность транзакций перевешивает потребность в автономии сотрудников.

SQL Server включает три типа тиражирования, которые вы можете использовать при проектировании своих приложений:

·     Тиражирование снимком (Snapshot replication)

·     Транзакционное тиражирование (Transactional replication)

·     Тиражирование слияния (Merge replication)

Каждый из этих типов предоставляет разные возможности и обладает различными характеристиками с точки зрения автономии узлов и согласованности транзакций. Тем не менее эти технологии не являются взаимоисключающими, и весьма часто в одном и том же приложении используется несколько типов тиражирования.


Тиражирование снимком

Как следует из названия, тиражирование снимком фиксирует “моментальный снимок” опубликованных данных из базы данных в один определенный момент времени. Оно представляет собой простейший тип тиражирования и гарантирует несрочную согласованность данных между издателем и подписчиком. Тиражирование снимком лучше всего подходит для ситуаций “только для чтения”, например, при использовании таблиц поиска или кодов, а также для систем поддержки принятия решений, где требования к задержке обновления данных не слишком строги, а объем данных не очень велик. "Снимки" данных могут формироваться в соответствии с заданным графиком или по мере необходимости.

Тиражирование снимком требует меньших накладных расходов на обработку по сравнению с транзакционным тиражированием, поскольку здесь не нужно непрерывно следить за изменениями данных на серверах-источниках. Вместо копирования операторов INSERT, UPDATE и DELETE (как в транзакционном тиражировании) или изменений данных (как в тиражировании слияния) здесь происходит полное обновление всего набора данных на подписчике. Таким образом, при тиражировании снимком подписчику пересылаются все данные, а не только их изменения. Если статья очень велика, для ее передачи могут понадобиться значительные сетевые ресурсы. Решая, следует ли использовать  тиражирование снимком, вы должны сопоставить размер полного набора данных и их изменчивость.

Если обновление данных на подписчике не производится,  тиражирование снимком обеспечивает большую автономию узла. Но если обновления необходимы, то автономия оказывается малой, что снижает полезность этого типа тиражирования при отсутствии связи с сетью. Чем выше частота обновлений, тем более ограниченным оказывается это решение. Во всех случаях  тиражирование снимком поддерживает мягкую согласованность транзакций (loose transactional consistency).

Транзакционное тиражирование

Второй способ тиражирования носит название транзакционного тиражирования. При таком тиражировании отслеживаются изменения данных сервера-издателя на уровне транзакций, т.е. операций вставки, обновления или замены. Эти изменения непрерывно или через заданные промежутки времени передаются на один или несколько серверов-подписчиков. Как правило, распространение изменений происходит почти в реальном времени и задержка обычно составляет всего несколько секунд. При использовании транзакционного тиражирования все изменения данных должны осуществляться на издательском узле, что позволяет избежать конфликтов и гарантировать согласованность транзакций.

Издатель передает на серверы-подписчики только завершенные транзакции, причем гарантируется их пересылка в том порядке, в каком происходило завершение. Это обеспечивает мягкую согласованность транзакций, поскольку в конце концов все узлы-подписчики достигнут таких же значений данных, как на издателе. Данные на всех узлах-участниках будут выглядеть так же, как если бы все операции осуществлялись на одном узле.

Если подписчикам необходимо, чтобы изменения данных распространялись почти в реальном времени, им потребуется сетевое соединение с издателем. В условиях хорошей сети транзакционное тиражирование может обеспечить очень низкие величины задержки. Подписчики, использующие режим оповещения, часто будут получать изменения в течение 5-10 секунд после того, как они произошли на издателе (при условии, что сетевое соединение остается доступным).


Поскольку транзакционное тиражирование основано на том, что у определенного элемента данных может быть только один издатель, оно чаще всего применяется в приложениях, допускающих логическое разбиение данных и определение их владельца. Примером удачного использования транзакционного тиражирования может служить система филиалов с централизованной отчетностью (сводной информацией по корпорации). В этом сценарии данные принадлежат серверу филиала, который публикует их, предоставляя центральному серверу доступ в режиме чтения для подготовки отчетов. Транзакционное тиражирование также хорошо подходит для периодической загрузки данных “только для чтения” как при хорошем сетевом соединении, так и без постоянного соединения. Например, мобильный торговый представитель каждую ночь мог бы из своего номера в отеле получать лишь инкрементальные изменения к прайс-листу, причем вносить эти модификации имеет право только центральный офис корпорации.

Режим немедленного обновления слиянием

В простейшей форме как тиражирование снимком, так и транзакционное тиражирование опирается на модель одностороннего тиражирования, когда изменения вносятся в данные только на издателе и распространяются вниз, к серверу-подписчику. Тем не менее в некоторых приложениях требуется возможность обновлять данные на подписчиках и обеспечивать передачу этих изменений вверх. Режим немедленного обновления слиянием (Immediate Updating Subscribers), доступный для тиражирования снимком и транзакционного тиражирования, позволяет осуществлять обновление данных на узлах-подписчиках.

Этот режим задается в момент создания статьи и разрешает подписчику обновлять локальную копию данных при условии, что эти изменения можно немедленно учесть на издателе с помощью протокола двухфазной фиксации (2PC — two-phase commit). Если обновление информации между подписчиком и издателем прошло успешно, то во время следующего распространения данных издатель передаст изменения всем остальным подписчикам. Поскольку подписчик, осуществляющий обновление, уже располагает измененной версией локальных данных, пользователь может продолжать работу с обновленными данными, будучи уверен, что данные издателя также отражают внесенные модификации.

Режим немедленного обновления слиянием особенно хорошо подходит для использования в хороших и надежных сетях, когда конкуренция приложений за данные относительно низка. Например, распределенная система продажи билетов поддерживает локальные копии базы данных по билетам, чтобы обеспечить быстрый доступ к информации о доступных местах. Однако каждое место можно продать лишь один раз, поэтому очень важно, чтобы локальная транзакция (например, продажа билета) приводила к немедленному обновлению и завершению на центральном сервере (издателе). Затем эта транзакция при следующем распространении данных копируется во все другие местные билетные кассы, так что любая попытка продать то же самое место будет блокирована.

Как работает немедленное обновление слиянием

Когда для публикации включена поддержка режима немедленного обновления слиянием, узел-подписчик может модифицировать копию данных, если эту транзакцию удается осуществить с помощью двухфазной фиксации между ним и издателем. Этот подход обеспечивает несрочную гарантированную согласованность (latent guaranteed consistency) для других подписчиков, но не требует, чтобы обновления проводились только на узле-издателе. Обратная транзакция 2PC от подписчика к издателю выполняется автоматически, так что приложение можно писать так, как если бы оно обновляло только один узел. Такой подход свободен от ограничений по доступности, возникающих при проведении 2PC со всеми узлами-участниками, поскольку здесь нам нужен доступ только к издателю. Если в данные издателя с помощью 2PC внесено изменение, то оно в конце концов будет получено всеми остальными подписчиками публикации, что поддерживает несрочную гарантированную согласованность данных.

2phase.gif

Этот режим позволяет избежать написания приложений, которые выполняют операции модификации данных на издателе, а операции чтения — на подписчике. Приложение работает с данными на одном узле, а транзакция 2PC осуществляется автоматически. Приложение должно быть готово обработать неудачу транзакции точно так же, как и в среде без тиражирования. Если транзакция прошла успешно, подписчик может немедленно начинать работу с измененными данными, зная, что обновление было без конфликтов принято издателем и в конце концов будет скопировано на каждый узел-подписчик публикации. Впрочем, осуществляющий обновление подписчик не обладает полной автономией, поскольку в этот момент ему необходим доступ к издателю. Тем не менее степень автономии здесь гораздо выше, чем в случае полной двухфазной фиксации, когда все узлы должны быть доступны, чтобы любой из них смог произвести изменения.

Транзакционное тиражирование с опосредованным обновлением слиянием

Транзакционное тиражирование в режиме немедленного обновления слиянием представляет собой хорошее решение для приложений, требующих обновления копий данных и согласованности транзакций. В то же время оно зависит от качества и надежности сетевых соединений, которое можно гарантировать не всегда. В некоторых приложениях необходим способ тиражирования, поддерживающий согласованность транзакций при периодических отключениях от сети. Следующая версия SQL Server после SQL Server 7.0 будет включать новый режим опосредованного обновления слиянием (Queued Updating Subscriber), позволяющий удовлетворить эту потребность. (Примечание: все остальные возможности, рассматриваемые в этом документе, входят в SQL Server 7.0.)

При использовании опосредованного обновления слиянием транзакция двухфазной фиксации применяется к локальным данным, а также к Microsoft Message Queue — встроенному в Microsoft Windows NT® Server серверу управления очередями сообщений[KT11] . Когда узел снова станет доступен, изменения будут извлечены из очереди в исходной последовательности и переданы на узел-издатель. Если он не выявит конфликтов, то внесение изменений будет завершено. Однако если конфликт обнаружен, то текущая и все последующие транзакции отвергаются, чтобы обеспечить согласованность транзакций, а сообщение об этом направляется вносящему изменения подписчику. Таким образом приложение может гарантировать согласованность транзакций при отключении сети.


Тиражирование слияния

Тиражирование слияния обеспечивает наивысший уровень автономии среди всех решений для тиражирования. Издатели и подписчики могут работать совершенно независимо и периодически связываться друг с другом, чтобы объединить результаты. Конфликты, возникающие при изменении одного и того же элемента данных на нескольких узлах, будут разрешены автоматически. Эти характеристики делают тиражирование слияния идеальным решением для таких приложений, как автоматизация службы продаж, где пользователям необходим полный доступ к локальным копиям данных для чтения и записи при отсутствии связи с сетью.

В случая возникновения конфликтов (несколько узлов обновили одни и те же значения данных) тиражирование слияния автоматически осуществляет их разрешение. Победитель конфликта может определяться по заданным значениям приоритета, по тому, кто первым представил изменение, или по комбинации этих двух критериев. Значения данных копируются и применяются к другим узлам только после завершения процессов согласования, для чего могут потребоваться часы, дни или даже недели. Конфликты можно обнаруживать и разрешать на уровне строк таблицы или даже на уровне конкретных ячеек.

В процессе тиражирования слияния участвуют агенты тиражирования снимком и слияния. Агент тиражирования снимком готовит файлы-снимки, содержащие схему и данные для публикуемых таблиц, сохраняет эти файлы на сервере-дистрибуторе и заносит в базу данных публикации информацию о заданиях на синхронизацию. Агент слияния применяет к подписчику первоначальные снимки данных, хранящиеся в базе данных распространения, а также осуществляет слияние инкрементальных изменений данных, которые произошли после создания такого снимка, и устраняет конфликты с помощью заданных вами правил или созданной вами специализированной процедуры разрешения конфликтов.

Как работает тиражирование слияния

При публикации таблицы с помощью тиражирования слияния SQL Server вносит в схему базы данных три важных изменения. Во-первых, он определяет столбец, имеющий для всех строк копируемой таблицы уникальные значения, что позволяет однозначно идентифицировать строку в нескольких копиях таблицы. Если базовая таблица уже содержит уникальный столбец идентификатора со свойством ROWGUIDCOL, то SQL Server автоматически использует его в качестве идентификатора строк для копируемой таблицы. В противном случае SQL Server добавляет к базовой таблице столбец rowguid (со свойством ROWGUIDCOL), а также индекс по этому столбцу.

Во-вторых, SQL Server устанавливает триггеры, которые отслеживают изменения данных в каждой строке или (при необходимости) в каждом столбце. Эти триггеры фиксируют изменения в базовой таблице и заносят их в системные таблицы слияния. Для статей могут генерироваться различные триггеры, следящие за изменениями на уровне строк или столбцов. Поскольку SQL Server в состоянии поддерживать для базовой таблицы несколько триггеров одного типа, триггеры тиражирования слияния не мешают триггерам, определенным в приложении. Другими словами, триггеры приложения и триггеры тиражирования могут сосуществовать друг с другом.

В-третьих, SQL Server включает в базу данных несколько системных таблиц, обеспечивающих слежение за данными, эффективную синхронизацию, а также обнаружение, разрешение и оповещение о конфликтах. Таблицы msmerge_contents и msmerge_tombstone отслеживают обновления, вставки и удаления данных в рамках публикации. Для связи с базовой таблицей они используют уникальный столбец идентификатора rowguid. Столбец генерации выступает в роли “логических часов”, показывающих, когда эта строка последний раз обновлялась на данном узле. Фактические значения времени не применяются ни для фиксации момента изменения, ни для разрешения конфликтов, так что система не зависит от синхронизации часов между разными узлами. На каждом конкретном узле генерируемые числа соответствуют порядку, в котором изменения вносились агентом слияния или пользователями узла.

Разрешение конфликтов на основе приоритетов

При разрешении конфликтов на основе приоритетов каждой публикации присваивается значение приоритета от 0 (минимальный приоритет) до 100 (максимальный приоритет). Приведенная ниже иллюстрация представляет самый простой случай. В этом сценарии все три узла согласны, что узел A создал первую версию строки и после этого обновлений не происходило. Если эту строку обновит и узел A, и узел B, то победителем конфликта окажется обновление узла A, потому что он обладает более высоким приоритетом.

3phase.gif

Рассмотрим более сложный сценарий, когда со времени последнего слияния одна и та же строка претерпевает несколько изменений. В этом случае победитель конфликта определяется максимальным значением приоритетов узла для изменений по сравнению с общей версией данных. Например, пусть узел A создал версию 2 и переслал ее на узел B, который строит версию 3 и отправляет ее обратно на узел A. Теперь узел C также создает версию 2 и согласовывает ее с узлом A. Максимальное значение приоритета изменений по сравнению с общей версией равно 100 (приоритет узла A). Совместные изменения узлов A и B выигрывают по приоритету, так что победителем конфликта оказывается узел A.

Настраиваемое разрешение конфликтов

Тиражирование слияния спроектировано с учетом потребности приложений в использовании гибких схем разрешения конфликтов. Приложение может перекрыть используемую по умолчанию схему на основе приоритетов, создав свою собственную специализированную процедуру разрешения. Такие процедуры представляют собой объекты COM или хранимые процедуры, написанные в соответствии с публичным интерфейсом разрешения. Агент слияния вызывает их, обеспечивая поддержку бизнес-правил при согласовании данных.

Например, предположим, что несколько узлов участвуют в контроле [KT12] определенного химического процесса и фиксируют минимальную и максимальную температуру, которая достигалась в ходе испытания. Стратегия разрешения конфликтов на основе приоритетов или принципа “побеждает первый” не позволит получить “наименьшее минимальное” и “наивысшее максимальное” значения. Опираясь на шаблоны программ и примеры кода, можно очень просто создать специализированную процедуру для решения этой задачи.


Тиражирование слияния представляет собой прекрасное решение для приложений, работающих без подключения к сети и требующих очень большой автономии узлов, если такие приложения допускают разбиение или не нуждаются в согласованности транзакций. Слияние будет неудачным решением, если нам необходима согласованность транзакций и приложение не может гарантировать такую целостность посредством разбиения данных. Согласованность транзакций подразумевает строгое соблюдение условий ACID (Atomicity, Consistency, Isolation, Durability — атомарность, согласованность, изоляция, устойчивость) и в особенности требования устойчивости транзакций. Любое решение для тиражирования, допускающее возникновение конфликтов, по определению не может достичь характеристик ACID. Разрешение конфликтов каждый раз приводит к “отмене” каких-то из уже завершенных транзакций, что нарушает требование устойчивости.

Снижение сложности

Одна из основных целей системы тиражирования Microsoft SQL Server версии 7.0 состоит в том, чтобы облегчить построение, управление и использование тиражирования. Microsoft достигла этой цели, предложив набор мастеров и изощренных инструментов проектирования и контроля. SQL Server Enterprise Manager включает несколько новых мастеров, упрощающих установку и обслуживание тиражирования. Пользуясь одним сервером или рабочей станцией, где установлен Microsoft SQL Server, вы можете с помощью SQL Server Enterprise Manager создать полную среду тиражирования, которая охватывает столько серверов по всей вашей организации, сколько необходимо. Replication Monitor позволяет просматривать и модифицировать характеристики тиражирования, а также устранять возникающие проблемы.

Мастера тиражирования

Microsoft SQL Server включает различные мастера тиражирования и многочисленные диалоговые окна, которые упрощают операции, необходимые для организации тиражирования и  управления им.

Мастер настройки публикации и распространения (Configure Publishing and Distribution Wizard)

Помогает задать сервер для использования в качестве дистрибутора, а при желании и другие компоненты среды тиражирования.

Мастер создания публикации (Create Publication Wizard)

Помогает создать публикацию из данных, находящихся в вашей базе данных.

Мастер подписки в режиме оповещения (Push Subscription Wizard)

Помогает “протолкнуть” подписку на публикацию с одного сервера на один или несколько серверов или серверных групп.

Мастер подписки в режиме опроса (Pull Subscription Wizard)

Помогает “вытащить” подписку на публикацию с одного сервера в базу данных на другом сервере.

Мастер отключения публикации и распространения (Disable Publishing and Distribution Wizard)

Помогает отключить на данном сервере функции публикации, распространения или и те, и другие одновременно.

Мастер разрешения конфликтов тиражирования (Replication Conflict Reconciler Wizard)

Помогает проанализировать и разрешить конфликты, возникшие в процессе тиражирования слияния.

Воспользовавшись мастерами для первоначальной настройки тиражирования и создания публикаций и статей, вы можете изменить большинство параметров с помощью диалоговых окон свойств.


Replication Monitor

После создания среды тиражирования с помощью Replication Navigator вы можете использовать Replication Monitor для наблюдения за состоянием агентов тиражирования и устранения потенциальных проблем на сервере-дистрибуторе. Replication Monitor запускается в SQL Server Enterprise Manager в качестве компонента сервера только тогда, когда сервер может выполнять функции дистрибутора, а текущий пользователь входит в фиксированную серверную роль sysadmin. Работа всех агентов тиражирования должна планироваться через SQL Server Agent. Система тиражирования и Replication Monitor не будут работать, если SQL Server Agent в данный момент не запущен[KT13] .

Вы можете использовать Replication Monitor в SQL Server Enterprise Manager, чтобы:

·     Просмотреть список поддерживаемых дистрибутором издателей, публикаций и подписок на публикации.

·     Узнать, выполнение каких агентов тиражирования запланировано, и проверить текущее состояние и историю работы каждого агента.

·     Устанавливать и контролировать сигналы, связанные с событиями тиражирования. При возникновении события SQL Server ответит на него автоматически, запустив определенную вами задачу или отправив указанному оператору сообщение по электронной почте или с помощью пейджера.

Слежение за издателями, публикациями и подписками

Replication Monitor представляет собой мощный инструмент для получения детальной информации об издателях, публикациях и подписках. Например, монитор может выдать список всех издателей, использующих данный сервер в качестве дистрибутора, показать все публикации для конкретного издателя или выявить все подписки на определенную публикацию.

Слежение за агентами тиражирования

Для целей устранения проблем Replication Monitor позволяет следить за активностью в графическом представлении для всех агентов тиражирования (агентов тиражирования снимком, анализа протоколов, распространения и слияния). Выбрав сервер-дистрибутор и щелкнув на Replication Monitor, вы увидите информацию о четырех агентах. Раскрывая узел для конкретного агента, можно выяснить детали его состояния и историю выполненных агентом заданий.

Слежение за сигналами тиражирования

Replication Monitor и SQL Server Agent предлагают мощный механизм управления средой тиражирования в отсутствие операторов. Агент следит за протоколом событий в приложениях Windows NT, ожидая события, которое соответствует параметрам для одного из заданных сигналов. Если такое событие происходит, SQL Server Agent автоматически отвечает на него, запуская определенную вами задачу или отправляя указанному оператору сообщение по электронной почте или с помощью пейджера.

Вы можете выбрать сервер-дистрибутор и воспользоваться монитором тиражирования, чтобы просмотреть список всех возникших на нем сигналов, связанных с тиражированием.


Протокол событий в приложениях Windows NT

Для просмотра протокола событий в приложениях Windows NT применяется утилита Windows NT Event Viewer. Если вы входите в группу Windows NT Administrators, то сможете просматривать также и протоколы событий для удаленных систем. Протокол событий содержит сообщения об ошибках SQL Server, а также информацию о всех других выполняемых на компьютере действиях. При работе с протоколом событий Windows NT каждый сеанс SQL Server записывает новые события в существующий протокол, причем вы можете осуществить его фильтрацию, чтобы найти конкретные события. В отличие от протокола ошибок SQL Server, здесь новый протокол не создается при каждом запуске сервера, однако вы можете указать, сколько времени события будут сохраняться в протоколе.

Тиражирование в гетерогенных средах

Во многих распределенных приложениях необходимы возможности интеграции со специализированными решениями и различными хранилищами данных. SQL Server 7.0 удовлетворяет это требование двумя способами. Во-первых, все программные интерфейсы тиражирования доступны и документированы, что позволяет разработчикам тесно интегрировать свои программы с системой тиражирования SQL Server. Например, независимый производитель программ, специализирующийся на создании решений для тиражирования, легко может реализовать эти функции как надстройку над системой тиражирования SQL Server, обеспечив поддержку копирования в несколько и из нескольких хранилищ данных. А разработчику приложений автоматизации службы продаж с помощью наших открытых интерфейсов будет очень просто встроить тиражирование SQL Server непосредственно в свое приложение и дать клиентам прозрачное решение. Во-вторых, система тиражирования SQL Server 7.0 опирается на ведущие стандарты доступа к данным OLE DB и ODBC, что обеспечивает встроенные возможности гетерогенного тиражирования.

Тиражирование в гетерогенные источники данных

SQL Server поддерживает тиражирование в гетерогенные источники данных, которые предоставляют 32-разрядные драйверы ODBC или OLE DB в операционных системах Microsoft Windows NT или Microsoft Windows® 95. В стандартной поставляемой конфигурации SQL Server поддерживает в качестве гетерогенных подписчиков Microsoft Access, Pocket Access, Oracle и DB2 с Microsoft BackOffice®. Кроме того, SQL Server 7.0 работает с любыми другими серверами баз данных, соответствующими требованиям ODBC или OLE DB Subscriber.

Простейший способ опубликовать данные для подписчика, не использующего SQL Server, предполагает применение ODBC/OLE DB и создание подписки в режиме оповещения от издателя к подписчику ODBC/OLE DB Subscriber. Впрочем, в качестве альтернативы вы также можете создать публикацию, а затем построить приложение со встроенным управляющим элементом распространения. Этот элемент реализует подписку в режиме опроса от подписчика к издателю. При работе с подписчиками ODBC/OLE DB база данных подписчика не обладает никакими возможностями управления по отношению к производимому тиражированию.

Тиражирование из гетерогенных источников данных

Microsoft SQL Server позволяет гетерогенным источникам данных выступать в качестве издателей в рамках архитектуры тиражирования SQL Server. Microsoft обеспечила доступ к интерфейсам тиражирования и опубликовала их, так что разработчики могут использовать все возможности транзакционного тиражирования SQL Server.

Гетерогенным источникам данных доступны, в частности, следующие службы тиражирования:

·     Программируемые объекты тиражирования SQL-DMO для управления и слежения за тиражированием.

·     Интерфейс Replication Distributor Interface для хранения копируемых транзакций.

·     Агент распространения, осуществляющий пересылку транзакций подписчикам.

·     Утилита SQL Server Enterprise Manager, обеспечивающая графическое управление и контроль за тиражированием.


Следующая диаграмма иллюстрирует, как гетерогенный источник данных может интегрироваться в архитектуру тиражирования в качестве издателя.

3ptypub.gif

Microsoft активно пропагандирует интерфейсы агента распространения в сообществе разработчиков, чтобы обеспечить возможность тесной интеграции создаваемых ими гетерогенных решений для тиражирования с SQL Server 7.0. Несколько производителей, в том числе Platinum и Praxis, на основе интерфейсов дистрибутора строят системы, позволяющие включать публикации из баз данных третьих фирм непосредственно в архитектуру тиражирования Microsoft. Когда гетерогенная публикация включена в процесс тиражирования, за ней легко можно следить прямо из инструментов независимых производителей, поддерживающих объекты тиражирования SQL-DMO.

Вопросы проектирования тиражирования

Тиражирование данных — это сложная технология, и архитектура тиражирования SQL Server учитывает, что ни одно решение не может подойти для всех приложений. В отличие от других продуктов для тиражирования, продвигающих единый подход под лозунгом “обновление в любом месте в любое время”, SQL Server предлагает различные технологии тиражирования, которые можно адаптировать к конкретным потребностям вашего приложения. В зависимости от ваших требований каждая технология сможет обеспечить различные преимущества и потребности по трем важным измерениям:

·     Согласованность транзакций

·     Автономность узлов

·     Разбиение данных для избежания конфликтов

Согласованность транзакций

Применительно к тиражированию согласованность транзакций означает, что данные на любом узле-участнике будут такими же, как если бы все операции выполнялись на одном узле. Иначе говоря, акт тиражирования данных сам по себе не выявляет ситуации, связанные с изменениями данных, которые не состоялись бы без использования тиражирования. При работе с распределенными приложениями, осуществляющими модификацию данных, можно выделить три основных уровня согласованности транзакций:

·     Срочная гарантированная согласованность (Immediate guaranteed consistency)

·     Несрочная гарантированная согласованность (Latent guaranteed consistency)

·     Сходимость (Convergence)

Срочная гарантированная согласованность

При обеспечении срочной гарантированной согласованности (в SQL Server 6.x она называлась жесткой (tight) согласованностью) система гарантирует, что все участники в любой определенный момент времени располагают в точности одинаковыми значениями данных, а сами данные находятся в состоянии, которое было бы достигнуто, если бы вся обработка выполнялась на публикующем узле. Единственный способ добиться срочной гарантированной согласованности в среде с распределенным обновлением (где изменения в одни и те же данные могут быть внесены в любом месте) связан с использованием двухфазной фиксации между всеми узлами-участниками. Каждое изменение должно завершаться одновременно на всех узлах, а в противном случае его не может завершить ни один узел. Очевидно, что при большом числе узлов такое решение невозможно реализовать из-за различных непредвиденных ситуаций, например, отключений сети.


Несрочная гарантированная согласованность

В случае несрочной гарантированной согласованности (в SQL Server 6.x она называлась мягкой (loose) согласованностью) система гарантирует, что все узлы-участники располагают одинаковыми значениями данных, которые в какой-то момент времени были достигнуты на публикующем узле. Однако узлы-подписчики могут отражать значения данных с некоторой задержкой, поэтому нельзя гарантировать, что все узлы в любой момент времени будут содержать в точности одинаковые значения. Если бы удалось приостановить все модификации данных на достаточно долгое время, чтобы каждый узел смог догнать публикующий и учесть все изменения, то все узлы содержали бы одинаковые значения данных. Но простой одинаковости значений еще недостаточно для несрочной гарантированной согласованности. Эти значения также должны быть такими же, какие были бы получены при выполнении всей работы на одном узле. Различие между срочной и несрочной гарантированной согласованностью связано с тем, являются ли данные согласованными в один и тот же момент времени. Если позволить системе завершить обновление, то значения в конце концов станут одинаковыми независимо от того, основана ли она на срочной или на несрочной гарантированной согласованности.

Сходимость

При использовании сходимости все узлы в конце концов могут получить одинаковые значения, но не обязательно такие, какие были бы получены при выполнении всех операций только на одном узле. Все узлы могут свободно работать без связи друг с другом, а при синхронизации узлов они сходятся к одним и тем же значениям. Lotus NOTES может служить примером продукта, основанного на технологии сходимости и применяемого для создания полезных распределенных приложений, однако он не обеспечивает ни атомарные транзакции, ни какую-либо модель гарантированной согласованности.

Другие поставщики баз данных, которые также поддерживают атомарные транзакции лишь на одном узле, продвигают свои решения для тиражирования под лозунгом “обновление в любом месте”. Большинство из них предлагает возможность разрешения конфликтов посредством отбрасывания или изменения последствий транзакции в связи с тем, что на другом узле была выполнена конкурирующая транзакция. Как утверждает реклама, эти решения обеспечивают полную автономность узла. Однако реклама не привлекает внимания к тому, что акт разрешения конфликта означает отсутствие гарантированной согласованности транзакций.

Пример согласованности транзакций

Пусть в сценарии тиражирования участвуют три узла, и узел 3 представляет для синхронизации с двумя другими узлами пять транзакций T1, T2, T3, T4 и T5. Транзакции T1 и T2 не приводят к конфликтам и поэтому принимаются. Пока все идет замечательно, однако транзакция T3 вызывает конфликт, и механизм согласования отбрасывает ее. Часто не понимают, что транзакции T4 и T5 также нужно отбросить, поскольку эти транзакции могли прочитать и использовать данные, модифицированные транзакцией T3. Поскольку впоследствии эта транзакция была отброшена, с логической точки зрения ее никогда не существовало, так что транзакции T4 и T5 тоже оказываются сомнительными. Их принятие создает ситуацию, когда результаты могут отличаться от тех, которые были бы получены при выполнении всех обновлений на одном узле, а это нарушает правила согласованности транзакций.

Должно быть очевидно, что даже компенсирующей транзакции (например, удаления — delete[KT14] , если была принята операция вставки — insert[KT15] ) недостаточно, чтобы гарантировать согласованность транзакций. Проблема вызывается не конкретной транзакцией, а скорее возможными изменениями в ходе последующих транзакций из-за неустойчивого состояния данных после устранения конфликта. Чтобы сохранить состояние, гарантирующее согласованность транзакций, мы должны отбросить не только транзакцию T3, но и всю дальнейшую работу, выполненную на этом узле, включая транзакции T4 и T5.

Автономность узлов

Автономность узлов связана с тем, насколько серьезно один узел влияет на работу другого. Полная автономность узла достигается, если его способность выполнять нормальную работу не зависит от связи с другим узлом (узлами) и их рабочего состояния. Например, при использовании двухфазной фиксации любое изменение данных зависит от того, в состоянии ли все остальные узлы-участники немедленно и успешно принять транзакцию. Если один из узлов недоступен, то вся работа оказывается невозможной. На другом конце спектра находится тиражирование слияния, где каждый узел работает совершенно независимо и может быть полностью отключен от всех других узлов. Тиражирование слияния обеспечивает высокую автономность узлов, но не гарантированную согласованность. Двухфазная фиксация гарантирует жесткую согласованность, но приводит к полному отсутствию автономности узлов. Другие решения находятся где-то посередине по обоим этим измерениям.

Разбиение данных для избежания конфликтов

Вы можете разделить данные на нескольких узлах, чтобы обеспечить свои собственные гарантии согласованности транзакций. Обратите внимание, что отсутствие гарантированной согласованности транзакций совсем не означает гарантированной их несогласованности. Если вы можете спроектировать приложение так, что каждый узел-участник будет работать с данными, жестко отделенными от других узлов, это позволит поддерживать согласованность транзакций. Например, чтобы гарантировать отсутствие конфликтов между заказами, постройте систему их ввода так, чтобы каждый торговый представитель обслуживал свою собственную, четко определенную территорию.

Разбиение данных вносит очень важное третье измерение, которое нужно рассматривать при проектировании и развертывании распределенных приложений. Некоторые технологии тиражирования SQL Server обеспечивают обнаружение и разрешение конфликтов, однако разбиение позволяет их избежать. Если возможно, всегда лучше избегать конфликтов до обновления, а не устранять их впоследствии. Разрешение конфликта всегда приводит к перезаписи или откату [KT16] результатов работы какого-то узла и к потере гарантированной согласованности транзакций. Большое число конфликтов требует значительных вычислительных затрат в ходе разрешения, затрудняет управление и может приводить к совершенно непредсказуемым и не допускающим проверки состояниям данных. С практической точки зрения, если выбранная вами распределенная технология не гарантирует целостности транзакций, то вы должны быть уверены, что построение и развертывание приложения не приведет к большому числу конфликтов. Конфликты должны быть исключением, а не правилом, а для разрешения этих исключений можно использовать процедуры согласования.

Выбор подходящего типа тиражирования

Ваши требования к этим трем измерениям и соотношениям между ними будут изменяться при переходе от одного распределенного приложения к другому. Возможно также, что требования по одному из измерений будут противоречить требованиям по другому. Например, обычно считается, что приложение должно использовать протокол обновления с двухфазной фиксацией (2PC), чтобы гарантировать полную согласованность и атомарность транзакций, а также отсутствие конфликтов при модификации одних и тех же данных в нескольких местах. Однако 2PC требует полной доступности всех узлов-участников и надежной связи между ними, что делает этот протокол непригодным для многих распределенных приложений, поскольку такими “хорошими связями” располагают не все узлы.


Эта иллюстрация представляет различные варианты тиражирования SQL Server 7.0 на линейной шкале, причем автономность узлов находится на одном ее конце, а согласованность транзакций — на другом. Такая схема в сочетании с индивидуальными характеристиками каждого варианта поможет вам выбрать подходящее решение для тиражирования. Кроме того, разбиение приложения позволяет одновременно обеспечить согласованность транзакций и автономность узлов.

consist.gif

Другие распределенные технологии

Система тиражирования Microsoft SQL Server 7.0 предлагает мощные технологии для создания и поддержки широкого спектра распределенных приложений. Тем не менее существуют приложения, в которых тиражирование может оказаться не самым лучшим решением. Для таких приложений в SQL Server включено несколько других технологий распределенных баз данных:

·     Гетерогенные распределенные запросы

·     Microsoft Distributed Transaction Coordinator

·     Data Transformation Services

В зависимости от потребностей вашего приложения эти технологии SQL Server можно применять в сочетании с тиражированием или вместо него.

Гетерогенные распределенные запросы

Основанная на OLE DB технология распределенных запросов SQL Server 7.0 допускает запросы к гетерогенным источникам данных. В распределенном запросе может участвовать любой источник данных, поддерживаемый интерфейсом ODBC/OLE DB. Например, пусть международная компания имеет восемь региональных офисов, причем все они применяют для хранения информации о продажах разные системы управления базами данных (Oracle, Microsoft Access, Microsoft Excel, SQL Server и т.д.). Используя распределенные запросы, менеджер по продажам может прочитать данные из каждого источника и подготовить квартальный отчет со значениями продаж, заработной платы и комиссионных за три последних года.

SQL Server позволяет обращаться к базам и источникам данных с помощью одного оператора SELECT, что открывает доступ ко всей мощи SQL, включая гетерогенные связи и подзапросы. Если приложению в самом деле нужно работать с распределенными данными, но конкретный элемент данных требуется не очень часто, распределенные запросы могут оказаться более разумным решением, чем тиражирование.

Microsoft Distributed Transaction Coordinator

Microsoft Distributed Transaction Coordinator (координатор распределенных транзакций) поддерживает распределенное обновление данных в приложении. Это единственный способ обеспечить жесткую согласованность данных (все копии данных в один и тот же момент времени содержат в точности одинаковые значения), а также гарантировать, что данные находятся в состоянии, которое было бы достигнуто при выполнении всей работы на одном узле. SQL Server поставляется со службой Distributed Transaction Coordinator (DTC), поддерживающей жесткую согласованность при обновлении данных в реальном времени.


Data Transformation Services

Служба преобразования данных SQL Server Data Transformation Services (DTS) облегчает импорт, экспорт и преобразование данных между несколькими гетерогенными источниками при использовании архитектуры, основанной на интерфейсе OLE DB. DTS позволяет переносить и выполнять преобразования данных между:

·     Естественными источниками данных OLE DB, например, Microsoft SQL Server, Microsoft Excel, Microsoft Works и Microsoft Access.

·     Такими источниками данных ODBC, как Microsoft Access, Oracle и DB2, с помощью OLE DB Provider for ODBC.

·     Текстовыми файлами ASCII с фиксированной длиной поля и с разделением полей.

Заключение

Тиражирование играет ведущую роль при создании хранилища [KT17] данных, корпоративной интрасети, системы автоматизации службы продаж или любого другого распределенного приложения, обеспечивая быструю и надежную передачу данных в рамках компании. SQL Server 7.0 позволяет добиться этой цели с помощью масштабируемого набора решений для тиражирования, которые удовлетворяют самый широкий спектр потребностей приложений. Эти масштабируемые решения обладают большой мощностью, но не отличаются высокими затратами и сложностью[KT18] , характерной для конкурирующих технологий тиражирования. В результате тиражирование оказывается жизнеспособной основой инфраструктуры распределенных приложений. Кроме того, система тиражирования SQL Server 7.0 опирается на промышленные стандарты и поэтому сразу может взаимодействовать с гетерогенными источниками данных, что позволяет компаниям легко интегрировать новые приложения и использовать инвестиции в другие платформы приложений.


 [KT1] на подписчике

 [KT2] на подписчике

 [KT3] на подписчике

 [KT4] слиянием

 [KT5] слиянием

 [KT6]Не очень понятный перевод. Я бы сказал: «Тиражирование в гетерогенных средах»

 [KT7]Абзац, однако. Вообще не нравится. Речь идет о тенденции роста распределенных вычислительных систем и их усложнения. Распространение приложений – это материал для BSA J

 [KT8]см. заметку 1 - Заменить на «снижение»

 [KT9]Заменить на «возможность»

 [KT10] В случае новых терминов и инструментов должно даваться и английское название в скобках в месте их первого употребления и в одноименных заголовках

 [KT11]Сервер управления очередями сообщений

 [KT12]«за» - излишне

 [KT13]запущен

 [KT14] удаления - delete

 [KT15]операция вставки - insert

 [KT16]откату

 [KT17]хранилища или витрины

 [KT18]Стиль – «не отличаются»