Как разрешить изменение таблиц в sql server management

Внесение изменений в схемы баз данных публикации

Репликация поддерживает широкий диапазон изменений схем для опубликованных объектов. При внесении любого из следующих изменений схемы на соответствующий опубликованный объект на издателе Microsoft SQL Server это изменение распространяется по умолчанию ко всем подписчикам SQL Server:

• ALTER TABLE
• ALTER TABLE SET LOCK ESCALATION не следует использовать, если включена репликация изменений схемы, а топология включает в себя SQL Server 2005 (9.x) или подписчиков SQL Server Compact 3.5.
• ALTER VIEW
• ALTER PROCEDURE
• ALTER FUNCTION
• ALTER TRIGGER Параметр ALTER TRIGGER можно использовать только для триггеров языка обработки данных DML, поскольку триггеры языка описания данных DDL не могут быть реплицированы.

Изменения схемы в таблицах должны вноситься с помощью объектов Управления Transact-SQL или SQL Server (SMO). При внесении изменений схемы в SQL Server Management Studio среда Management Studio пытается удалить и повторно создать таблицу. Опубликованные объекты невозможно удалить, поэтому изменения схемы завершаются ошибкой.

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

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

Репликация изменений схемы

Перечисленные выше изменения схемы реплицируются по умолчанию. Сведения об отключении репликации изменений схемы см. в разделе Replicate Schema Changes.

Вопросы изменений схемы

При репликации изменений схемы учитывайте следующее.

Общие рекомендации

• Изменения схемы подвергаются любым ограничениям, введенным Transact-SQL. Например, ALTER TABLE не позволяет изменять первичные ключевые столбцы.
• Сопоставление типов данных выполняется только для исходного моментального снимка. Изменения схемы не сопоставляются с предыдущими версиями типов данных. Например, если инструкция ALTER TABLE ADD datetime2 column используется в SQL Server 2012 (11.x), тип данных не преобразуется в nvarchar для подписчиков SQL Server 2005 (9.x). В некоторых случаях изменения схемы блокируются на издателе.
• Если в публикации разрешено распространение изменений схемы, то изменения схемы распространяются независимо от того, как установлен соответствующий параметр схемы для статьи в публикации. Например, если вы указываете не реплицировать ограничения внешних ключей для статьи таблицы, а затем выполняете команду ALTER TABLE, которая добавляет внешний ключ в таблицу на издателе, внешний ключ будет добавлен в таблицу на подписчике. Чтобы предотвратить это, отключите распространение изменений схемы перед выполнением команды ALTER TABLE.
• Изменения схемы должны выполняться только на издателе, а не на подписчиках (включая переиздающих подписчиков). Репликация слиянием предотвращает изменения схемы на подписчиках. Репликация транзакций не предотвращает изменения, однако изменения могут быть причиной ошибки репликации.
• Изменения, распространяемые на переиздающего подписчика, по умолчанию распространяются на его подписчиков.
• Если изменение схемы ссылается на объекты или ограничения, существующие на издателе, но отсутствующие на подписчике, изменение схемы будет успешно выполнено на издателе, а на подписчике оно завершится ошибкой.
• Любой объект на подписчике, на который имеются ссылки, при добавлении внешнего ключа должен иметь то же имя и того же владельца, что и соответствующий объект на издателе.
• Явное добавление, удаление или изменение индексов не реплицируются, и любое изменение, включающее явный индекс, должно выполняться отдельно для каждого набора реплик. Поддерживается неявное создание индексов для ограничений (например, для ограничения первичного ключа).
• Изменение или удаление столбцов идентификаторов, управляемых репликацией, не поддерживается. Дополнительные сведения об автоматическом управлении столбцами идентификаторов см. в статье Репликация столбцов идентификаторов.
• Изменения схемы, включающие недетерминированные функции, не поддерживаются, поскольку они могут привести к разным данным на издателе и на подписчике (эта разница данных называется расхождением). Например, если на издателе выполнить команду ALTER TABLE SalesOrderDetail ADD OrderDate DATETIME DEFAULT GETDATE() , значения будут отличаться от случая, когда команда реплицируется на подписчик и выполняется. Дополнительные сведения о недетерминированных функциях см. в разделе Deterministic and Nondeterministic Functions.
• Рекомендуется именовать ограничения явным образом. Если ограничение не имеет явного имени, SQL Server создает имя ограничения, и эти имена будут отличаться на издателе и каждом подписчике. Это может стать причиной проблем во время репликации изменений схемы. Например, если на издателе удаляется столбец и зависимое ограничение, то во время репликации будет произведена попытка удалить ограничение на подписчике. Эта попытка удаления на подписчике завершится ошибкой, так как имена ограничения на издателе и на подписчике различаются. Если синхронизация завершается сбоем из-за различия имен ограничения, то удалите ограничение на подписчике вручную, а затем перезапустите агент слияния.
• При публикации какой-либо таблицы для репликации невозможно изменить данные столбца в этой таблице на данные типа XML, если моментальный снимок публикации уже создан. Перед изменением столбца необходимо вначале удалить репликацию.
• Уровень изоляции «read uncommitted» не является поддерживаемым уровнем изоляции при выполнении DDL в опубликованной таблице.
• АргументSET CONTEXT_INFO не следует использовать для изменения контекста транзакций, изменения схемы выполняются для опубликованных объектов.

Добавление столбцов

• Чтобы добавить новый столбец в таблицу и включить этот столбец в существующую публикацию, выполните инструкцию ALTER TABLE <> TABLE ADD . По умолчанию этот столбец затем реплицируется на все подписчики. Столбец должен допускать использование значений NULL или содержать ограничение по умолчанию. Дополнительные сведения о добавлении столбцов см. в подразделе «Репликация слиянием» этого раздела.
• Чтобы добавить новый столбец в таблицу и не включить этот столбец в существующую публикацию, отключите репликацию изменений схемы, а затем выполните инструкцию ALTER TABLE <> ADD .
• Чтобы включить существующий столбец в существующую публикацию, используйте sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) или диалоговое окно «Свойства публикации — Дополнительные сведения см. в разделе Define and Modify a Column Filter. Это потребует повторной инициализации подписок.
• Добавление столбца идентификаторов в опубликованную таблицу не поддерживается, поскольку это может привести к расхождению данных при репликации столбца на подписчик. Значения в столбце идентификаторов на издателе зависят от порядка, в котором строки изменяемой таблицы хранятся физически. Строки могут храниться по-разному на подписчике. Поэтому значение для столбца идентификаторов может быть разным для одинаковых строк.

Удаление столбцов

• Чтобы удалить столбец из существующей публикации и удалить столбец из таблицы на издателе, выполните инструкцию ALTER TABLE <> DROP . По умолчанию столбец затем удаляется из таблицы на всех подписчиках.
• Чтобы удалить столбец из существующей публикации, но сохранить столбец в таблице на издателе, используйте sp_articlecolumn (Transact-SQL), sp_mergearticlecolumn (Transact-SQL) или диалоговое окно «Свойства публикации — публикация». <> Дополнительные сведения см. в разделе Define and Modify a Column Filter. Это потребует создания нового моментального снимка.
• Удаляемый столбец не может использоваться в предложениях фильтра любой статьи любой публикации в базе данных.
• При удалении столбца из опубликованной статьи имейте в виду возможное влияние на базу данных ограничений, индексов и свойств столбца. Например:
  • Нельзя удалить столбцы, используемые первичным ключом, из статей в публикациях транзакций, потому что они используются репликацией.
  • Нельзя удалить столбец rowguid из статей в публикациях слиянием или столбец mstran_repl_version из статей в публикациях транзакций, поддерживающих обновляемые подписки, поскольку они используются репликацией.
  • Изменения индекса не распространяются на подписчики: при удалении столбца на издателе и зависимого индекса репликация удаления индекса не производится. Чтобы выполнить удаление столбца при его реплицировании с издателя на подписчик, следует удалить индекс на подписчике перед удалением столбца на издателе. Если выполнить синхронизацию не удалось из-за какого-либо индекса на подписчике, то удалите этот индекс вручную, а затем перезапустите агент слияния.
  • Ограничения следует именовать явным образом для удаления. Дополнительные сведения см. в подразделе «Общие вопросы» этого раздела.

  репликация транзакций

  • Изменения схемы распространяется на подписчиков, работающих с предыдущими версиями SQL Server, но инструкция DDL должна включать только синтаксис, поддерживаемый версией на подписчике. Если подписчик публикует данные повторно, поддерживаемые изменения схемы включают только добавление и удаление столбца. Эти изменения следует вносить на издателе с помощью sp_repladdcolumn (Transact-SQL) и sp_repldropcolumn (Transact-SQL), а не синтаксиса ALTER TABLE DDL.
  • Репликация изменений схемы не выполняется для подписчиков, отличных от подписчиков SQL Server.
  • Изменения схемы не распространяются от издателей, отличных от SQL Server.
  • Индексированные представления, которые реплицируются в виде таблиц, невозможно изменить. Индексированные представления, которые реплицируются как индексированные представления, могут быть изменены, однако их изменение приведет к тому, что они станут обычными, а не индексированными представлениями.
  • Если публикация поддерживает подписки с немедленным обновлением или обновляемой посредством очередей подписки, перед выполнением изменений схемы следует заморозить систему: любые действия в опубликованной таблице должны быть прекращены на издателе и подписчиках, а отложенные изменения данных должны быть распространены на все узлы. После распространения изменений схемы на все узлы можно возобновить действия в опубликованных таблицах.
  • Если публикация находится в одноранговой топологии, перед выполнением изменений схемы система должна быть приостановлена. Дополнительные сведения см. в статье Заморозить топологию репликации (программирование репликации на языке Transact-SQL).
  • Добавление в таблицу столбца типа timestamp и сопоставление типа timestamp с типом binary(8) вызывает повторную инициализацию статьи для всех активных подписок.

  Репликация слиянием

  • Способ обработки изменений схемы при репликации слиянием определяется уровнем совместимости публикации и режимом моментального снимка — собственным (по умолчанию) или символьным.
    • Для репликации изменений схемы уровень совместимости публикации должен быть не меньше 90RTM. Если подписчики выполняют предыдущие версии SQL Server или уровень совместимости меньше 90RTM, можно использовать sp_repladdcolumn (Transact-SQL) и sp_repldropcolumn (Transact-SQL) для добавления и удаления столбцов. Однако эти процедуры являются устаревшими.
    • Если вы попытаетесь добавить в существующую статью столбец с типом данных, представленным в SQL Server 2008 (10.0.x), SQL Server имеет следующее поведение:
      

      100RTM, собственный режим моментального снимка	100RTM, символьный режим моментального снимка	Все другие уровни совместимости
      hierarchyid	Разрешить изменения	Блокировать изменения	Блокировать изменения
      geography и geometry	Разрешить изменения	Разрешить изменения*	Блокировать изменения
      файловый поток	Разрешить изменения	Блокировать изменения	Блокировать изменения
      date, time, datetime2и datetimeoffset	Разрешить изменения	Разрешить изменения*	Блокировать изменения

      * Подписчики SQL Server Compact преобразуют эти типы данных на подписчике.

    Transact-SQL — изменение базы данных и таблиц

    

    Язык Transact-SQL поддерживает изменение структуры следующих объектов базы данных:

    • базы данных;
    • таблицы;
    • представления;
    • схемы;
    • хранимые процедуры;
    • триггеры.

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

    Изменение базы данных

    Для изменения физической структуры базы данных используется инструкция ALTER DATABASE. Язык Transact-SQL позволяет выполнять следующие действия по изменению свойств базы данных:

    • добавлять и удалять один или несколько файлов базы данных;
    • добавлять и удалять один или несколько файлов журнала;
    • добавлять и удалять файловые группы;
    • изменять свойства файлов или файловых групп;
    • устанавливать параметры базы данных;
    • изменять имя базы данных с помощью хранимой процедуры sp_rename.

    Эти разные типы модификаций базы данных рассматриваются далее.

    Добавление и удаление файлов базы данных, файлов журналов и файловых групп

    Добавление или удаление файлов базы данных осуществляется посредством инструкции ALTER DATABASE. Операция добавления нового или удаления существующего файла указывается предложением ADD FILE и REMOVE FILE соответственно. Кроме этого, новый файл можно определить в существующую файловую группу посредством параметра TO FILEGROUP.

    В примере ниже показано добавление нового файла базы данных в базу данных SampleDb:

    USE master; GO ALTER DATABASE SampleDb ADD FILE ( NAME=sampledb_dat1, FILENAME='D:\sampledb1.mdf', SIZE = 10, MAXSIZE = 100, FILEGROWTH = 5 );

    В этом примере инструкция ALTER DATABASE добавляет новый файл с логическим именем sampledb_dat1. Здесь же указан начальный размер файла 10 Мбайт и автоувеличение по 5 Мбайт до максимального размера 100 Мбайт. Файлы журналов добавляются так же, как и файлы баз данных. Единственным отличием является то, что вместо предложения ADD FILE используется предложение ADD LOG FILE.

    Удаления файлов (как файлов базы данных, так и файлов журнала) из базы данных осуществляется посредством предложения REMOVE FILE. Удаляемый файл должен быть пустым.

    Новая файловая группа создается посредством предложения CREATE FILEGROUP, а существующая удаляется с помощью предложения DELETE FILEGROUP. Как и удаляемый файл, удаляемая файловая группа также должна быть пустой.

    Изменение свойств файлов и файловых групп

    С помощью предложения MODIFY FILE можно выполнять следующие действия по изменению свойств файла:

    • изменять логическое имя файла, используя параметр NEWNAME;
    • увеличивать значение свойства SIZE;
    • изменять значение свойств FILENAME, MAXSIZE и FILEGROWTH;
    • отмечать файл как OFFLINE.

    Подобным образом с помощью предложения MODIFY FILEGROUP можно выполнять следующие действия по изменению свойств файловой группы:

    • изменять логическое имя файловой группы, используя параметр NAME;
    • помечать файловую группу, как файловую группу по умолчанию, используя для этого параметр DEFAULT;
    • помечать файловую группу как позволяющую осуществлять доступ только для чтения или для чтения и записи, используя для этого параметр read_only или read_write соответственно.

    Установка опций базы данных

    Для установки различных опций базы данных используется предложение SET инструкции ALTER DATABASE. Некоторым опциям можно присвоить только значения ON или OFF, но для большинства из них предоставляется выбор из списка возможных значений. Каждый параметр базы данных имеет значение по умолчанию, которое устанавливается в базе данных model. Поэтому значения определенных опций по умолчанию можно модифицировать, изменив соответствующим образом базу данных model.

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

    Опции состояния управляют следующими возможностями:

    • доступом пользователей к базе данным (это опции single_user, restricted_user и multi_user);
    • статусом базы данных (это опции online, offline и emergency);
    • режимом чтения и записи (опции read_only и read_write).

    Опции автоматических операций управляют, среди прочего, остановом базы данных (опция auto_close) и способом создания статистики индексов (опции auto_create_statistics и auto_update_statistics).

    Опции SQL управляют соответствием базы данных и ее объектов стандарту ANSI. Значения всех операторов SQL можно узнать посредством функции DATABASEPROPERTY, а редактировать — с помощью инструкции ALTER DATABASE.

    Опции восстановления full, bulk-logged и simple управляют процессом восстановления базы данных.

    Хранение данных типа FILESTREAM

    При описании типов данных T-SQL мы рассмотрели данные типа FILESTREAM и причины, по которым их используют. В этом разделе мы рассмотрим, как данные типа FILESTREAM можно сохранять в базе данных. Чтобы данные FILESTREAM можно было сохранять в базе данных, система должна быть должным образом инициирована. В следующем подразделе объясняется, как инициировать операционную систему и экземпляр базы данных для хранения данных типа FILESTREAM.

    Инициирование хранилища FILESTREAM

    Хранилище данных типа FILESTREAM требуется инициировать на двух уровнях:

    • для операционной системы Windows;
    • для конкретного экземпляра сервера базы данных.

    Инициирование хранилища данных типа FILESTREAM на уровне системы осуществляется с помощью диспетчера конфигурации SQL Server Configuration Manager. Чтобы запустить диспетчер конфигурации, выполните следующую последовательность команд по умолчанию Пуск —> Все программы —> Microsoft SQL Server 2012 —> Configuration Tools . В открывшемся окне Sql Server Configuration Manager щелкните правой кнопкой пункт SQL Server Services (Службы SQL Server) и в появившемся контекстном меню выберите команду Open. В правой панели щелкните правой кнопкой экземпляр, для которого требуется разрешить хранилище FILESTREAM, и в контекстном меню выберите команду Properties. В открывшемся диалоговом окне SQL Server Properties выберите вкладку FILESTREAM:

    

    Чтобы иметь возможность только читать данные типа FILESTREAM, установите флажок Enable FILESTREAM for Transact-SQL access (Разрешить FILESTREAM при доступе через Transact-SQL). Чтобы кроме чтения можно было также записывать данные, установите дополнительно флажок Enable FILESTREAM for file I/O streaming access (Разрешить использование FILESTREAM при доступе файлового ввода/вывода). Введите имя общей папки Windows в одноименное поле. Общая папка Windows используется для чтения и записи данных FILESTREAM, используя интерфейс API Win32. Если для возвращения пути для FILESTREAM BLOB использовать имя, то это будет имя общей папки Windows.

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

    Чтобы разрешить хранилище FILESTREAM, необходимо быть администратором Windows локальной системы и обладать правами администратора (sysadmin). Чтобы изменения вступили в силу, необходимо перезапустить экземпляр сервера базы данных.

    Следующим шагом будет разрешить хранилище FILESTREAM для конкретного экземпляра. Мы рассмотрим, как выполнить эту задачу с помощью среды SQL Server Management Studio. (Для этого можно также воспользоваться хранимой системной процедурой sp_configure с параметром FILESTREAM ACCESS LEVEL.) Щелкните правой кнопкой требуемый экземпляр в обозревателе объектов и в появившемся контекстном меню выберите пункт Properties, в левой панели открывшегося диалогового окна Server Properties выберите пункт Advanced (Дополнительно):

    

    После этого в правой панели из выпадающего списка выберите FILESTREAM Access Level (Уровень доступа FILESTREAM) одну из следующих опций:

    Disabled

    Отключено — хранилище FILESTREAM не разрешено.

    Transact-SQL Access Enabled

    Включен доступ с помощью Transact-SQL — к данным FILESTREAM можно обращаться посредством инструкций T-SQL.

    Full Access Enabled

    Включен полный доступ — к данным FILESTREAM можно обращаться как посредством инструкций T-SQL, так и через интерфейс API Win32.

    Добавление файла в файловую группу

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

    USE SampleDb; ALTER DATABASE SampleDb ADD FILEGROUP Employee_FSGroup CONTAINS FILESTREAM; GO ALTER DATABASE SampleDb ADD FILE ( NAME= employee_FS, FILENAME = 'D:\temp\emp_FS') TO FILEGROUP Employee_FSGroup 

    Первая инструкция ALTER DATABASE в примере добавляет в базу данных SampleDb новую файловую группу Employee_FSGroup. Параметр CONTAINS FILESTREAM этой инструкции указывает системе, что данная файловая группа будет содержать только данные FILESTREAM. Вторая инструкция ALTER DATABASE добавляет в созданную файловую группу новый файл.

    Теперь можно создавать таблицы, содержащие столбцы с типом данных FILESTREAM. Создание такой таблицы показано в примере ниже:

    CREATE TABLE EmployeeInfo ( Id UNIQUEIDENTIFIER ROWGUIDCOL NOT NULL UNIQUE, FilestreamData VARBINARY(MAX) FILESTREAM NULL )

    В этом примере таблица EmployeeInfo содержит столбец FilestreamData, тип данных которого должен быть VARBINARY(MAX). Определение такого столбца включает атрибут FILESTREAM, указывающий, что данные столбца сохраняются в файловой группе FILESTREAM. Для всех таблиц, в которых хранятся данные типа FILESTREAM, требуется наличие свойств UNIQUE ROWGUIDCOL. Поэтому таблица EmployeeInfo содержит столбец Id, определенный с использованием этих двух атрибутов.

    Данные в столбце типа FILESTREAM вставляются посредством стандартной инструкции INSERT. А для считывания данных используется стандартная инструкция SELECT.

    Автономные базы данных

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

    Разработчики Microsoft планируют решить эти проблемы посредством использования автономных баз данных (contained databases). Автономная база данных содержит все параметры и данные, необходимые для определения базы данных, и изолирована от экземпляра Database Engine, на котором она установлена. Иными словами, база данных данного типа не имеет конфигурационных зависимостей от экземпляра и ее можно с легкостью перемещать с одного экземпляра SQL Server на другой.

    По большому счету, что касается автономности, существует три вида баз данных:

    • полностью автономные базы данных;
    • частично автономные базы данных;
    • неавтономные базы данных.

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

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

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

    Рассмотрим, как создать частично автономную базу данных в SQL Server 2012. Если существующая база данных SampleDb является неавтономной (созданная, например, посредством инструкции CREATE DATABASE), с помощью инструкции ALTER DATABASE ее можно преобразовать в частично автономную, как это показано в примере ниже:

    EXEC sp_configure 'show advanced options' , 1; RECONFIGURE WITH OVERRIDE; EXEC sp_configure 'contained database authentication' , 1; RECONFIGURE WITH OVERRIDE; ALTER DATABASE SampleDb SET CONTAINMENT = PARTIAL; EXEC sp_configure 'show advanced options' , 0; RECONFIGURE WITH OVERRIDE;

    Инструкция ALTER DATABASE изменяет состояние автономности базы данных SampleDb с неавтономного на частично автономное. Это означает, что теперь система базы данных позволяет создавать как автономные, так неавтономные объекты для базы данных SampleDb. Все другие инструкции в примере являются вспомогательными для инструкции ALTER DATABASE.

    Функция sp_configure является системной процедурой, с помощью которой можно, среди прочего, изменить дополнительные параметры конфигурации, такие как ‘contained database authentication’. Чтобы изменить дополнительные параметры конфигурации, сначала нужно присвоить параметру ‘show advanced options’ значение 1, а потом переконфигурировать систему (инструкция RECONFIGURE). В конце кода этому параметру опять присваивается его значение по умолчанию — 0.

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

    Изменение таблиц

    Для модифицирования схемы таблицы применяется инструкция ALTER TABLE. Язык Transact-SQL позволяет осуществлять следующие виды изменений таблиц:

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

    Эти типы изменений рассматриваются в последующих далее разделах.

    Добавление и удаление столбцов

    Чтобы добавить новый столбец в существующую таблицу, в инструкции ALTER TABLE используется предложение ADD. В одной инструкции ALTER TABLE можно добавить только один столбец. Применение предложения ADD показано в примере ниже:

    USE SampleDb; ALTER TABLE Employee ADD PhoneNumber CHAR(12) NULL;

    В этом примере инструкция ALTER TABLE добавляет в таблицу Employee столбец PhoneNumber. Компонент Database Engine заполняет новый столбец значениями NULL или IDENTITY или указанными значениями по умолчанию. По этой причине новый столбец должен или поддерживать значения NULL, или для него должно быть указано значение по умолчанию.

    Новый столбец нельзя вставить в таблицу в какой-либо конкретной позиции. Столбец, добавляемый предложением ADD, всегда вставляется в конец таблицы.

    Столбцы из таблицы удаляются посредством предложения DROP COLUMN. Применение этого предложения показано в примере ниже:

    USE SampleDb; ALTER TABLE Employee DROP COLUMN PhoneNumber;

    В этом коде инструкция ALTER TABLE удаляет в таблице Employee столбец PhoneNumber, который был добавлен в эту таблицу предложением ADD ранее.

    Изменение свойств столбцов

    Для изменения свойств существующего столбца применяется предложение ALTER COLUMN инструкции ALTER TABLE. Изменению поддаются следующие свойства столбца:

    • тип данных;
    • поддержка значения NULL.

    Применение предложения ALTER COLUMN показано в примере ниже:

    USE SampleDb; ALTER TABLE Department ALTER COLUMN Location NCHAR(25) NOT NULL;

    Инструкция ALTER TABLE в этом примере изменяет начальные свойства (nchar(40), значения NULL разрешены) столбца Location таблицы Department на новые (nchar(25), значения NULL не разрешены).

    Добавление и удаления ограничений для обеспечения целостности (ключей и проверок)

    Для добавления в таблицу новых ограничений для обеспечения целостности используется параметр ADD CONSTRAINT инструкции ALTER TABLE. В примере ниже показано использование параметра ADD CONSTRAINT для добавления проверочного ограничения и определения первичного ключа таблицы:

    USE SampleDb; CREATE TABLE Sales ( Id INTEGER NOT NULL, OrderDate DATE NOT NULL, ShipDate DATE NOT NULL); -- Добавляем ограничение для дат (поля OrderDate и ShipDate) ALTER TABLE Sales ADD CONSTRAINT order_check CHECK(OrderDate 

    В этом примере сначала инструкцией CREATE TABLE создается таблица Sales, содержащая два столбца с типом данных DATE: OrderDate и ShipDate. Далее, инструкция ALTER TABLE определяет ограничение для обеспечения целостности order_check, которое сравнивает значения обоих этих столбцов и выводит сообщение об ошибке, если дата отправки ShipDate более ранняя, чем дата заказа OrderDate. Далее инструкция ALTER TABLE используется для определения первичного ключа таблицы в столбце Id.

    Ограничения для обеспечения целостности можно удалить посредством предложения DROP CONSTRAINT инструкции ALTER TABLE, как это показано в примере ниже:

    ALTER TABLE Sales DROP CONSTRAINT order_check, pkey_sales;

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

    Разрешение и запрещение ограничений

    Как упоминалось ранее, ограничение для обеспечения целостности всегда имеет имя, которое может быть объявленным или явно посредством опции CONSTRAINT, или неявно посредством системы. Имена всех ограничений таблицы (объявленных как явно, так и неявно) можно просмотреть с помощью системной процедуры sp_helpconstraint.

    В последующих операциях вставки или обновлений значений в соответствующий столбец ограничение по умолчанию обеспечивается принудительно. Кроме этого, при объявлении ограничения все существующие значения соответствующего столбца проверяются на удовлетворение условий ограничения. Начальная проверка не выполняется, если ограничение создается с параметром WITH NOCHECK. В таком случае ограничение будет проверяться только при последующих операциях вставки и обновлений значений соответствующего столбца. (Оба параметра - WITH CHECK и WITH NOCHECK - можно применять только с ограничениями проверки целостности CHECK и проверки внешнего ключа FOREIGN KEY.)

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

    USE SampleDb; ALTER TABLE Sales NOCHECK CONSTRAINT ALL;

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

    Переименование таблиц и других объектов баз данных

    Для изменения имени существующей таблицы (и любых других объектов базы данных, таких как база данных, представление или хранимая процедура) применяется системная процедура sp_rename. В примере ниже показано использование этой системной процедуры:

    USE SampleDb; -- Переименование таблицы Sales в BigSales EXEC sp_rename @objname = Sales, @newname = BigSales; -- Переименование столбца OrderDate в таблице BigSales EXEC sp_rename @objname = 'BigSales.OrderDate', @newname = date_order;

    Использовать системную процедуру sp_rename настоятельно не рекомендуется, поскольку изменение имен объектов может повлиять на другие объекты базы данных, которые ссылаются на них. Вместо этого следует удалить объект и воссоздать его с новым именем.

    Удаление объектов баз данных

    Все инструкции Transact-SQL для удаления объектов базы данных имеют следующий общий вид:

    DROP тип_объекта имя_объекта; 

    Для каждой инструкции CREATE object для создания объекта имеется соответствующая инструкция DROP object для удаления. Инструкция для удаления одной или нескольких баз данных имеет следующий вид:

    DROP DATABASE database1

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

    DROP TABLE table_name1

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

    Кроме объектов DATABASE и TABLE, в параметре objects инструкции DROP можно указывать, среди прочих, следующие объекты:

    • TYPE;
    • VIEW;
    • SYNONYM;
    • PROCEDURE;
    • SCHEMA;
    • INDEX;
    • TRIGGER.

    [ELMA3] Типичные ошибки запуска сервера и способы их устранения

    В этой статье мы рассмотрим часто встречающиеся ошибки и методы их устранения. 1. Ошибка: Ошибка инициализации конфигурации ELMA ---> System.InvalidOperationException: Cannot check database exists ---> System.Data.SqlClient.SqlException: Ошибка входа пользователя "IIS APPPOOL\Elma3-Standart". Причина: Авторизация на сервере IIS осуществлена под пользователем не имеющим прав администратора. Решение: Для устранения данной ошибки IIS сервера необходимо зайти в Диспетчер служб IIS (стандартно на сервере в Пуск – Администрирование). В нем на вкладке Пулы приложений у пула "ELMA3-Standart" выбрать в контекстном меню пунк Дополнительные параметры. В нем, в таблице Модель процесса, в поле Удостоверение указать учетную запись LocalSystem либо реальную учетную запись с правами администратора, после чего следует перезапустить веб-сервер. 2. Ошибка: The underlying connection was closed: An expected error occurred on a receive: Unable to read data from the transport connection: Удаленный хост разорвал существующее подключение: Удаленный хост разорвал существующее подключение. Причина: Сервер ELMA запущен с недостаточными правами доступа. Решение: В случае, если сервер располагается на базе Cassini, Вам необходимо нажать клавишу с логотипом Windows (флажок Microsoft) + R и ввести следующую команду в диалоговое окно: "services.msc" (без кавычек), после чего появится окно служб Windows. В нем Вы сможете найти строчку Веб-сервер ELMA, кликнуть правой кнопкой мыши и выбрать пункт Свойства, в котором и располагается искомая вкладка Вход в систему. Если же сервер основывается на базе IIS, то в этом случае необходимо так же открыть меню Выполнить (клавиша Windows + R) и ввести команду inetmgr. Откроется окно диспетчера служб IIS, в окне Подключения найдите пункт Пулы приложений, выделите его, откроется список текущего пула, где и должна быть запись о сервере ELMA. Также кликнув правой кнопкой мыши на записи, выберите пункт Дополнительные параметры. Нужная запись находится в строке Удостоверение указажите учетную запись LocalSystem либо реальную учетную запись с правами администратора, после чего следует перезапустить веб-сервер. 3. Ошибка: *System.UnauthorizedAccessException: Отказано в доступе по пути «С:\ELMA3-Express\UserConfig\configuration.packges». Решение: Удаление файла с расширением .packages из папки UserConfig. 4. Ошибка: Сервер не запущен из-за ошибки. Причина: Имена в SQL Server Management Studio базы и файле configuration.config не совпадают. Решение: Изменение названия БД в файле configuration.config. 5. Ошибка: Ошибка создания резервной копии данных. Причина:Недостаточно места на диске. Решение: Освободить место для корректного создания бекапа базы. 6. Ошибка: EleWise.ELMA.Runtime.Db.DbStructureException: Ошибка обновления структуры БД ---> System.Data.DataException: Не удалось выполнить запрос DROP INDEX UK_principal_name ON sysdiagrams ---> System.Data.SqlClient.SqlException: Явная инструкция DROP INDEX недопустима в индексе "sysdiagrams.UK_principal_name". Он используется для принудительного применения ограничения UNIQUE KEY. Причина: В SQL Server Management Studio, в разделе Системные таблицы не должно быть таблиц. Решение: Остановите сервер ELMA и откройте SQL Server Management Studio, в списке баз данных выберите нужную БД и разверните список таблиц. В разделе Системные таблицы не должно быть таблиц. Если они там есть, удалите их. Запустите сервер ELMA. 7. Ошибка: Ошибка из-за наличия активных подключений к БД. Причина: После восстановления базы из бекапа на сервере со временем отличным от предыдущего может остаться информация об активном подключении. Решение: Создание резервной копии и выполнение запроса в БД. Текст запроса: Delete from DB_ACTIVECONNECTIONS. 8. Ошибка: EleWise.ELMA.Runtime.Db.DbStructureException: Ошибка обновления структуры БД ---> NHibernate.TransactionException: Commit failed with SQL exception ---> FirebirdSql.Data.FirebirdClient.FbException: unsuccessful metadata update object INDEX is in use ---> FirebirdSql.Data.Common.IscException: unsuccessful metadata update Причина: Ошибка обновления. Решение: Сделайте резервное копирование базы и восстановите ее. (Для корректной работы системы на FireBird данную операцию необходимо производить с периодичностью раз в две недели). 9. Ошибка: *EleWise.ELMA.Runtime.Exceptions.ConfigurationInitializeException: Ошибка инициализации конфигурации ELMA ---> System.InvalidOperationException: Не удалось подключиться к базе данных ---> FirebirdSql.Data.FirebirdClient.FbException: Unable to complete network request to host "127.0.0.1". ---> FirebirdSql.Data.Common.IscException: Unable to complete network request to host "127.0.0.1". Причина: Ошибка в файле configuration.config в строке \base.fdb;user set=UNICODE_FSS;dialect=3;server type=0" />. Решение: Убедиться, что в строке\base.fdb;user set=UNICODE_FSS;dialect=3;server type=0" /> отсутствуют опечатки, соблюден регистр символов. 10. Ошибка: *EleWise.ELMA.Runtime.Exceptions.ConfigurationInitializeException: Ошибка инициализации конфигурации ELMA ---> System.InvalidOperationException: Не удалось подключиться к базе данных ---> System.Data.SqlClient.SqlException: Не удается открыть базу данных "ELMA", запрашиваемую именем входа. Не удалось выполнить вход.
    Ошибка входа пользователя "NT AUTHORITY\система". Причина: Авторизация на сервере Cassini осуществлена под пользователем не имеющим прав администратора. Решение: Необходимо запустить сервер Elma от имени учетной записи, обладающей правами администратора в Windows. Для этого зайдите в Панель управления – Администрирование – Службы, найдите там Веб-сервер Elma, щелкните по нему правой кнопкой мыши, выберите Свойства, в открывшемся окне перейдите на вкладку Вход в систему, установите флажок С учетной записью и введите данные учетной записи, обладающей правами администратора. Дополнение: Ошибка сервера MS SQL 2008 и выше Login failed for user ’NT AUTHORITY\система’. Причина: не удалось открыть явно указанную базу данных "ELMA". [КЛИЕНТ: ]. Ошибка: 18456, серьезность: 14, состояние: 38. Причина: Авторизация верная, запуск происходит с правами администратора, но база данных недоступна (или нет разрешения). Решение: Группе NT AUTHORITY\система необходимо добавить роль sysadmin на SQL сервере. Для этого зайдите Microsoft SQL Server Management Studio, раздел Безопасность – Имена входа и выберите свойства группы NT AUTHORITY\система. В меню Роли сервера установите флажок напротив роли sysadmin. 11. Ошибка: *EleWise.ELMA.Runtime.Exceptions.ConfigurationInitializeException: Ошибка инициализации конфигурации ELMA ---> System.InvalidOperationException: Не удалось подключиться к базе данных ---> System.Data.SqlClient.SqlException: Разрешение CREATE DATABASE запрещено в базе данных "master".
    Не удалось присоединить файл "F:\ELMA3-Standart\UserConfig\ELMA3.mdf" в качестве базы данных "ELMA3".
    Причина: Ошибка в файле configuration.config в строке AttachDbFilename=\ELMA3.mdf; Решение: Удалить строку "AttachDbFilename=\ELMA3.mdf" в конфигурационном файле configuration.config. После внесенных изменений файл необходимо сохранить и перезапустить веб-сервер. 12. Ошибка: При работе с веб-частью отображается всплывающее окно с ошибкой Не пройдена проверка предусловий запуска. Соответственно, при попытке авторизации в Дизайнере возникает ошибка. Причина: В окне ошибки виден пустой параметр – имя сервера. Решение: подключиться к серверу MSSQL от имени администратора и выполнить правильный SQL-запрос:

    EXEC sp_dropserver N'elma-local-loop' GO EXEC sp_addlinkedserver N'elma-local-loop', N' ', N'SQLNCLI', N'localhost\SQLSERVER2014' GO EXEC sp_serveroption [elma-local-loop], N'remote proc transaction promotion', 'false' EXEC sp_serveroption [elma-local-loop], N'rpc out', 'true' GO

    где localhost\SQLSERVER2014 – имя сервера базы данных. Чтобы убедиться, что ошибка исправлена, нужно выполнить запрос:

    select * from sys.servers where lower([name]) = 'elma-local-loop'

    

    Результат будет выглядеть следующим образом: 13. Ошибка: Ошибка Инициализации конфигурации ELMA: Версия БД не подходит по минимальным требованиям (предоставлена версия – , требуется как минимум Причина: версия используемой базы данных не подходит по минимальным системным требованиям для используемой редакции системы ELMA. Решение: необходимо обновить версию используемой базы данных до соответствующей минимальным системным требованиям для используемой редакции системы ELMA. 14. Ошибка: DbStructure files with the same GUID are found : ; – в модулях системы содержатся xml-преобразования базы данных с одинаковыми uid. Причина: в указанных модулях системы (модуль1, модуль2) содержатся xml-преобразования базы данных с одинаковыми uid. Решение: изменить дублирующийся uid в одном из модулей. 15. Ошибка: Npgsql.NpgsqlException: No password has been provided but the backend requires one (in MD5). Решение: Если отсутствуют права суперпользователя по умолчанию, если они не были указаны при установке, укажите их в файле configuration.config, который располагается в папке конфигурации ELMA, по умолчанию ..//UserConfig:

    • в секции main добавьте ключи sysUser и sysPassword со значениями для пользователя – владельца базы данных;
    • для этого случая желательно отключить автоматическое резервное копирование данных, добавив ключ backupEnabled со значением false.

    Пример настроек представлен на рисунке.

    

    16. Иногда при работе в системе могут возникнуть ошибки из-за прав, которые настраиваются в IIS.

    Например, если пул ELMA4 в IIS запускается под ApplicationPoolIdentity, то при импорте пакетов, требующем перезапуска сервера, возникает следующая ошибка:

    "ERROR 2021-03-04 16:02:13,055 [5] EleWise.ELMA.Logging.Logger - Во время выполнения автоматического импорта произошла ошибка: В процессе импорта произошла ошибка: Не удалось проверить статус запуска сайта 'ELMA-Enterprise-4_0_7' в IIS. Скорее всего, у пользователя, под которым запущен пул приложений IIS, отсутствуют необходимые привилегии".

    Оригинальный текст ошибки:
    "Имя файла: redirection.config
    Ошибка: Не удалось прочитать файл конфигурации из-за отсутствия необходимых разрешений".

    При этом группе IIS_IUSRS выданы полные права на папку с системой и C:\Windows\Temp\ELMA.

    В этом случае проблема возникает из-за отсутствия прав. Решение проблемы — это вопрос администрирования.

    ApplicationPoolIdentity — учётная запись с минимальными правами. То, что требует ELMA4 (управление сайтом, чтение данных пула и др.), эта учётная запись по умолчанию не обеспечивает.

    В этом случае варианта решения два:

    1. Если политика безопасности позволяет, изменить удостоверение пула приложений.

    2. Выдать права для работы под ApplicationPoolIdentity или той учётной записью, под которой работает администратор. Для IIS_IUSRS выдать права на %SystemRoot%\System32\inetsrv\config.

    17. Ошибка : *EleWise.ELMA.Runtime.Db.DbStructureException: Ошибка обновления структуры БД ---> Oracle.ManagedDataAccess.Client.OracleException: ORA-00054: ресурс занят и задано его получение с параметром NOWAIT, либо истекло время ожидания.

    Решение:

    1. Убедиться, что в схеме нет блокировок.

    2. Увеличить таймауты запросов в базу. Для этого в файле ~\Web\settings.config:

    • изменить значение value для ключа , например, выставить value=“7200”;
    • изменить значение value для ключа , например, выставить значение value=“120”.

    Особенности настройки nginx

    Если используется веб-сервер nginx, могут возникнуть следующие ошибки:

    1. Ошибки, связанные с обработкой заголовка __RequestVerificationToken в POST-запросе.

    Решение: в файле конфигурации веб-сервера nginx в части server добавьте строку underscores_in_headers on; или ignore_invalid_headers off;

    1. Ошибки, связанные с некорректными редиректами.

    Решение: в файле конфигурации веб-сервера nginx параметр proxy_set_header укажите в формате proxy_set_header Host $host:$server_port;

    Конфигурация репликации сервера SQL для главных серверов объединения

    Ivanti® Endpoint Manager использует оригинальную репликацию SQL Server для объединения данных из главных серверов на главном сервере объединения. Репликация SQL Server выполняется почти в режиме реального времени и очень эффективна, что, практически, позволяет вам использовать текущее состояние базы данных объединения в отличие от устаревших версий утилит объединения базы данных, предшествующих версии Endpoint Manager 9.6.

    Предварительные требования

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

    • Убедитесь, что параметр Репликация (Replication) программы установки Endpoint Manager присутствует на каждом сервере DBMS SQL Server (издатели и подписчики), который будет участвовать в процессе репликации. Вы можете проверить это, запустив файл setup.exe для SQL Server.
    • Одним из ограничений приложения SQL Express является то, что оно не может работать в качестве издателя в топологии репликации. Поэтому вы не сможете выполнить репликацию данных из главного сервера Endpoint Manager , на котором используется система управления базами данных SQL Express.
    • Обязательно установите исправление KB2840628v2 (для серверов издателей и подписчиков DBMS). В разделе обновлений "Клиентский профиль Microsoft .NET Framework 4". Если вы установили исправление KB2840628, убедитесь, что оно содержит статью KB2840628v2. Переустановка обновит его на версию 2.

    Действие 1. Создайте учетные записи Windows (серверы издатели и подписчики DBMS)

    Используя следующую таблицу, создайте учетные записи пользователей Windows на компьютерах, где вы установили ПО Microsoft SQL Server. "Издатель" - это SQL Server, содержащий базу данных главного сервера. "Подписчик" - это SQL Server, содержащий базу данных объединения.

    Имя пользователя	SQL Server	Примечания
    ldms_snapshot	Издатель	Используется агентом снимков репликации
    ldms_logreader	Издатель	Используется агентом чтения журналов репликации
    ldms_distribution	Издатель и подписчик	Пароли должны совпадать на сторонах издателя и подписчика или агент распространения издателей не сможет подключиться к базе данных подписчика.

    Действие 2: Создайте общий ресурс репликации и назначьте разрешения пользователям Windows (серверы издатели DBMS)

    На сервере SQL Server, содержащем базу данных главного сервера (издатели), перейдите в папку SQL Server и создайте папку с именем ReplData, если та еще не существует. Местоположение папки по умолчанию:

    C:\Program Files\Microsoft SQL Server\MSSQL.X\MSSQL\

    Сделайте эту новую папку ReplData общей и убедитесь, что следующие пользователи имеют перечисленные разрешения: дополнительные параметры общего доступа (на вкладке Общий доступ) и Группы или пользователи на вкладке Безопасность.

    C:\Program Files\Microsoft SQL Server\MSSQL.X\MSSQL\ReplData
    Имя учетной записи	Разрешения
    \ldms_snapshot	Полное управление
    \ldms_distribution	Чтение

    Действие 3. Назначьте разрешение изменения для распространяющего пользователя в каталоге SQL Server COM (сервер подписчик DBMS)

    На сервере SQL Server, содержащем базу данных главного сервера объединения (подписчик), перейдите в папку SQL Server и найдите каталог COM. Местоположение папки по умолчанию:

    C:\Program Files\Microsoft SQL Server\\COM

    Выделите папку COM, нажмите ее правой кнопкой мыши и выберите Свойства. На вкладке Безопасность добавьте распространяющего пользователя в раздел Группы или пользователи и нажмите Изменить, чтобы дать пользователю все права, за исключением Полный доступ.

    C:\Program Files\Microsoft SQL Server\\COM
    Имя учетной записи	Разрешения
    \ldms_distribution	Изменение | Чтение и Выполнение| Список содержимого папки | Чтение | Запись

    Действие 4. Сконфигурируйте агента SQL Server для автоматического запуска (серверы издатели и подписчики DBMS)

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

    1. Откройте диалог служб Windows, нажав Пуск > Выполнить и введите имя services.msc.
    2. Дважды нажмите службу SQL Server Agent (MSSQLSERVER) и измените значение Startup type на Automatic.
    3. Нажмите Старт для запуска службы.

    Действие 5. Разрешите порту SQL Server взаимодействовать через брандмауэр (серверы издатели и подписчики DBMS)

    На сервере издателе и на каждом сервере подписчике:

    1. На Панели управления Windows запустите брандмауэр Windows. На левой стороне нажмите Расширенные настройки для открытия диалога Брандмауэр Windows в режиме повышенной безопасности.
    2. Нажмите Правила для входящих подключений и справа нажмите Новое правило.
    3. Нажмите Порт, затем нажмите Далее.
    4. Нажмите TCP, а затем в поле Специальные порты введите номер порта TCP, который сконфигурирован для использования агентом SQL Server (порт по умолчанию - 1433). Нажмите Далее (Next).
    5. Нажмите Разрешить подключение и нажмите Далее.
    6. На странице Профиль убедитесь, что установлены параметры (Домен, Закрытый или Общий), которые необходимы в вашей инфраструктуре для обеспечения взаимодействия серверов SQL Server друг с другом. Нажмите Далее (Next).
    7. Дайте имя правилу, чтобы его можно было проще найти, например, "Репликация SQL Server". Щелкните Готово.

    Действие 6. Запустите утилиту определений репликации и введите учетные данные для базы данных и информацию издателя (сервер подписчик DBMS)

    На сервере подписчике запустите утилиту репликации Ivanti:

    

    Используйте эту утилиту для ввода учетных данных Windows сервера базы данных и определений издателя.

    IMPORTANT: Нажатие OK, и утилита репликации удалит все таблицы в базе данных объединения, чтобы можно было восстановить данные из всех издателей. В зависимости от размеров баз данных это может занять некоторое время. Если вы не сделали изменений в утилите, нажмите Отмена для выхода и предотвращения выполнения процесса восстановления данных.

    Для ввода учетных данных аутентификации Windows для сервера базы данных:

    1. В утилите определений репликации Ivanti нажмите Репликация паролей пользователей (Replication user passwords).

    

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

  Для ввода определений издателя:

  1. В утилите определений репликации Ivanti нажмите Добавить (Add).

  

  • В поле Главный сервер (Core server) введите описательное имя. Это поле используется только для помощи в организации ваших издателей.
  • Заполните остальные поля и нажмите OK. Если информация, которую вы ввели неверна, утилита отобразит сообщение об ошибке.
  • Повторите действия для каждого главного сервера издателя.

  Действие 7. Запустите репликацию в SQL Server Management Studio на серверах издателях

  В системе SQL Server Management Studio на серверах издателях:

  1. Разверните Сервер > Репликация > Локальные публикации. Нажмите правой кнопкой имя [базы данных]: LANDESK и выберите Просмотр состояния агента моментальных снимков.
  2. Если вы еще не сделали, нажмите Старт.
  3. Убедитесь в успешном завершении.
  4. Нажмите правой кнопкой Репликация и выберите Запустить монитор репликации. Убедитесь в его активности и в отсутствии ошибок.

  С этого момента репликация должна работать. Вы можете дополнительно проверить это с помощью запроса в безе данных объединения.

  Примечания

  • Если вы выполнили обновление главного сервере, чтобы он стал издателем, обновление прекратит репликацию базы данных главного сервера, и вы должны будете повторно запустить файл LANDesk.Database.Replication.exe для повторной инициализации процесса репликации.

  Изменение расписания репликации

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

  Для изменения расписания репликации издателя:

  1. На сервере подписчике откройте SQL Server Management Studio и нажмите Агент SQL Server > Задания.
  2. Нажмите правой кнопкой мыши нужное задание и выберите Свойства (Properties).
  3. На странице Расписания дважды нажмите расписание репликации и сделайте в нем изменения.

  Поиск и устранение неисправностей

  Я не могу открыть консоль Endpoint Manager после репликации из-за ошибки лицензирования.

  Вы должны, как минимум, иметь главный сервер версии 9.6 или новее, указанный как издатель. Этот главный сервер должен иметь авторизацию.

  Была ли эта статья полезна?

  Похожие публикации:
  1. Как ввести координаты в яндекс навигатор
  2. Какой самоблок лучше поставить на уаз патриот в задний мост
  3. Сколько весит toyota supra
  4. Что такое принцип открытой архитектуры компьютеров ibm pc