Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#234<< #235 |
СОДЕРЖАНИЕ Уважаемые подписчики! Неожиданно для себя, мы узнали, что наша рассылка учувствовала в первом этапе фестиваля золотых рассылок Subscribe.ru и в своей конкурсной номинации по итогам голосования вышла в следующий круг. Осталось определить "лучших из лучших". Пригашаем Вас, если Вы сочтёте нашу рассылку этого достойной, проголосовать за неё. С уважением, А. Гладченко и В. Степаненко
Репликация слиянием - ручное управление диапазоном identity
По материалам статьи Paul Ibison:
Merge Replication - Manual Range Handling Для репликации транзакций и репликации моментальных снимков закономерно, что свойство identity, существующее на изданной таблице, не передается подписчику. Просто это не требуется, поскольку подписчик не предназначен для того, чтобы добавлять строки самостоятельно. Репликация слиянием, однако, предназначена для независимого, автономного добавления данных, и в этом случае, свойство identity будет передаваться. Поэтому возникает вопрос - как управлять диапазонами identity и гарантировать, что не будет наложений в значениях identity при синхронизации. Существует 2 варианта - автоматическое и ручное управление диапазонами. SQL Server может автоматически управлять диапазонами identity в репликации слиянием, но этот способ имеет плохую репутацию так как может повлечь за собой некоторые проблемы. Хотя верно то, что когда выделенный диапазон заканчивается раньше, чем произойдёт синхронизация, могут быть осложнения, в большинстве случаев их можно просто избежать: свойство identity накладывается на колонку с целочисленным типом данных int, который принимает значения в диапазоне от -2 147 483 648 до 2 147 483 647, тогда действительно, если у вас нет невероятно большого числа подписчиков, выбор большого диапазона значений на подписчике должен гарантировать, что выделенный диапазон не закончится. Однако в форумах часто задается вопрос - как вручную администрировать диапазоны identity и таким образом брать управление ими на себя. Эта статья представляет собой пошаговую инструкцию применения подобного алгоритма на практике. (1) Метод без первоначальной синхронизации данных
Во-первых, выберите алгоритм, который Вы будете использовать для гарантии того, что диапазоны каждого
из узлов не будут пересекаться. Существует несколько методов (см. сайт Michael Hotek's). Например,
предположим, что Вы имеете издателя и трёх подписчиков. Издатель может иметь положительные четные номера,
первый подписчик положительные нечетные номера, второй подписчик отрицательные четные номера, третий
подписчик отрицательные нечетные номера. Используя этот метод, каждый узел имеет примерно один миллиард
возможных значений. [Рис. 1.1] Если после публикации таблицы Вы попробуете изменить значение identity на издателе или подписчике это закончится сообщением об ошибке.
'tCompany' table
На издателе начальное значение (seed) и шаг приращения (increment) применяются, как только таблица
опубликована, и это происходит раньше, чем у него появляется первый подписчик. [Рис. 1.2] Затем перенесите таблицу на подписчика. Вы можете использовать DTS, резервное копирование/восстановление, BCP, прилинкованные сервера - в зависимости оттого, что Вы предпочитаете. Таблица может быть передана, как только у неё будет столбец uniqueidentifier, с установленным свойством rowguid, в противном случае при синхронизации Вы получите ошибку, приведенную ниже: Error: Invalid column name 'rowguidcol'.
Пока с публикуемой статьёй всё нормально, эта ошибка не может проявиться, поскольку таблица уже имеет
столбец rowguid или публикация этой таблицы добавит его к таблице.
Если издатель имеет начальное значение (seed) = 2 и приращение (increment) = 2, а первый подписчик имеет начальное значение = 1 и приращение = 2, в обоих случаях, следующая запись будет иметь ID 6. Это потому, что текущее значение identity - 4, таким образом, в обоих случаях, следующее значение будет 4 + 2. Значит, нужно запустить на подписчике: DBCC CHECKIDENT (tCompany, RESEED, 5)
чтобы начать правильный отсчет. Это можно сделать, используя скрипт из моментального снимка, после
того как он был применён, но начальное значение и приращение должны быть изменены вручную, и мы, в
таком случае имеем один дополнительный ручной шаг - это самое легкое решение. Фактически этот шаг
может быть сделан вручную, и начальное значение с приращением на подписчике можно оставить такими же,
как и на издателе, а так как в этом примере значение identity повышается парами, то будет достаточно
переопределения текущего значения identity. Однако это может запутать администратора, так как потом
всегда придётся анализировать начальное значение и приращения таблицы, чтобы определить значения
устанавливаемых границ. [Рис. 1.3] Следует помнить о том, что все статьи, опубликованные для репликации слиянием вместе с рассматриваемой таблицей, в этом случае будут так же без первоначальной синхронизации. Поэтому имеет смысл изолировать эту статью, и любые связанные с ней публикации. (2) Использование @creation_script в sp_addmergearticle Второй метод GUI полностью не поддерживается. Он требует разработки отдельного сценария для создания таблицы на подписчике: exec sp_addmergearticle @publication = N'TestIdentitiesXXX', @article = N'tCompany', @source_owner = N'dbo', @source_object = N'tCompany', @type = N'table', @description = null, @column_tracking= N'true', @pre_creation_cmd = N'drop', @creation_script = 'C:\misc\tCompany.sql', @schema_option = 0x00, @article_resolver = null, @subset_filterclause =null, @vertical_partition = N'false', @destination_owner = N'dbo', @auto_identity_range= N'false', @verify_resolver_signature = 0, @allow_interactive_resolver =N'false', @fast_multicol_updateproc = N'true', @check_permissions = 0 Список аргументов стандартный, за исключением аргумента @creation_script, который определяет файл, используемый при создании таблицы, и аргумента @schema_option, который предписывает использование упомянутого выше файла. Этот скрипт(C:\misc\tCompany.sql), созданный с помощью Enterprise Manager на издателе, просто создаёт скрипт таблицы, но с начальным значением (seed) identity, отличным от издателя: [ID] [int] IDENTITY (2, 2) NOT FOR REPLICATION NOT NULL
После инициализации текущее значение identity необходимо изменить еще раз, чтобы повторно определить
отправную точку. Заключение Были представлены два альтернативных метода, позволяющие организовать ручное управление диапазоном identity. Первый, в отличие от второго, легко настроить при помощи графических инструментов. В то время как второй метод позволяет более гибко добавлять новые статьи к существующей публикации. Обзор SQL Server 2005 для разработчика баз данных
По материалам статьи Matt Nunn, Microsoft Corporation:
An Overview of SQL Server 2005 for the Database Developer
Microsoft Corporation Июль 2004
Относится к: Описание: этот документ содержит обзор новых возможностей разработки баз данных в SQL Server 2005 (14 печатных страниц). Содержание
Новая парадигма разработки баз данных Новая парадигма разработки баз данных С выходом Microsoft SQL Server 2005 Beta 2 в мире разработки баз данных начинаются изменения. Если Вы разработчик баз данных, то теперь Вы можете создавать код в соответствии с его функциональностью, иметь доступ к данным во встроенных форматах, таких, как XML, и создавать сложные системы, управляемые сервером баз данных. Разработка баз данных становится более интегрированной, чем это было раньше, и все необходимые инструменты находятся прямо у Вас под рукой. Эта статья обсуждает некоторые новые возможности SQL Server 2005, которые позволят Вам создавать приложения базы данных другого уровня. С выходом Microsoft SQL Server 2005 Beta 2 программисты баз данных могут использовать все преимущества библиотеки классов Microsoft .NET Framework и современных языков программирования для внедрения новой функциональности на сервере. Используя интеграцию с common language runtime (CLR), Вы можете создавать Ваши хранимые процедуры, функции и триггеры на языке .NET Framework, если захотите. Языки программирования Microsoft Visual Basic .NET и C# дают возможность работать с объектно-ориентированными конструкциями, структурированным управлением исключениями, массивами, пространствами имен и классами. Кроме того, .NET Framework предоставляет тысячи классов и методов, имеющих большие встроенные возможности, которые Вы легко можете использовать на стороне сервера. Многие задачи, которые было тяжело выполнить в Transact-SQL, могут выполняться гораздо легче с использованием управляемого кода; кроме того, теперь доступны два новых типа объектов базы данных - агрегаты и пользовательские типы. Теперь Вы сможете лучше использовать знания и навыки, которые Вы приобрели во время написания встроенного кода. Одним словом, SQL Server 2005 Beta 2 позволяет вам расширять возможности сервера базы данных для более простого выполнения вычислений и операций. Статьи на русском языке
Использование SQLParameters в VB.NET/C#
Writing to a File Using the sp_OACreate Stored Procedure and OSQL Самые популярные темы недели
Ваше мнение об упражнениях SELECT на http://sql.ipps.ru
установка сервера используя iss файлы |
#234<< #235 |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||