Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#239<< #240 |
СОДЕРЖАНИЕ Знакомьтесь - SQLOS
По материалам статьи Slava Oks:
SQLOS - unleashed Если Вы изучали SQL Server 2005 Beta 1 и Beta 2 Вы могли заметить, что в каталоге bin больше нет файла ums.dll. Причина этого проста, его больше не существует. В SQL Server 2000 библиотека ums.dll обеспечивала работу SQL Server в непривилегированным режиме и неприоритетное планирование ресурсов (non-preemptive scheduling). Так что же произошло с ней в новой версии? Теперь больше не используется неприоритетное планирование? Ответом на это будет - "Нет", SQL Server 2005 по-прежнему использует такое планирование ресурсов и, как показывают многие исследования в области реляционных баз данных, для повышения производительности и обеспечения требований масштабирования, нужно и дальше развивать возможности использования неприоритетного планирования. Примечание переводчика: В SQL Server реализована кооперативная, неприоритетная модель потоков, согласно которой они обслуживаются периодически, а также могут ожидать снятия блокировок или очереди ввода-вывода. Кооперативная многозадачность подразумевает, что каждая программа должна сама предоставлять другим программам возможность использования процессора, для чего она отслеживает в своём коде циклы передачи управления другим, активным программам. Эта модель была присуща 16-ти битным версиям Windows, современные операционные системы используют модель приоритетной многозадачности. Видимо поэтому автор в своих статьях называет используемую SQLOS модель - неприоритетной.
В SQL Server 2005 разработчики сохранили модель неприоритетного планирования, создав новую
библиотеку компонент SQLOS, которую иногда называют SOS. SQLOS - это операционная система
непривилегированного режима, в которой реализованы механизмы планирования приоритетов,
управления памятью, контроля ресурсов, обработки исключений, обслуживания ввода-вывода,
обеспечение синхронизации и функций хостинга. Имейте в виду, что для SQL Server возможности
SQLOS не представляют собой ещё один уровень абстракции операционной системы, и она не
подменяет ни одного из интерфейсов Windows API, ни в целях повышения мобильности ни по другим
причинам. Наоборот, она служит для связи SQL Server с Windows, опираясь на возможности
масштабирования и обеспечения высокой производительности операционной системы. Примечание переводчика: NUMA - архитектура (non-uniform memory access) применяется для платформы Intel и отличается от широко распространенной SMP - архитектуры многопроцессорных серверов тем, что процессоры разбиваются на группы по два или четыре процессора, и каждой такой группе - узлу предоставляется своя выделенная область памяти, доступ к которой для группы будет быстрым, в отличие от остальной памяти, доступ к которой будет медленнее. Каждый узел имеет свою шину, которая соединяет его процессоры с платформой через специализированный контроллер, обеспечивающий при необходимости когерентность кэшей узлов и переключение задач между узлами. Появление этой платформы обусловлено тем, что платформа Intel не поддерживала более 4-х процессоров, а также тем, что необходимо было решение для повышения пропускной способности системной шины, которая становиться "узким местом" в симметричных многопроцессорных системах. Редактируя системный реестр Windows можно изменить число узлов. Программное обеспечение, умеющее это делать, разработчики называют поддерживающими NUMA - архитектуру программами. Как Вы могли догадаться, каждый такой узел представляет собой несколько планировщиков. Планировщик - это абстракция процессора. Планировщики имеют дело с задачами/процессами (tasks), которые исполняются т.н. обработчиками, которые в свою очередь оперируют системными потоками и нитями. Примечание переводчика: Под обработчиком имеется в виду UMS worker - представляющий собой некую абстракцию концепции поток/нить, позволяющую скрыть от программы такие тонкости, как потоки или нити.
Описанию планирования SQLOS можно посвятить очень много времени, так что автор вернётся к
более глубокому описанию этой темы в следующих статьях. Репликация пользовательского кода в SQL Server
По материалам статьи Baya Pavliashvili:
Replicating Code Modules in SQL Server
Репликация стаей - таблиц помогает синхронизировать данные в нескольких базах данных. Но что относительно
хранимых процедур, представлений, и пользовательских функций? Вы должны применить те же самые изменения
кода на множестве серверов, которыми управляете? К счастью, есть способ синхронизировать схему статей,
основанных не на таблице; а репликация исполнения хранимых процедур может обеспечить более высокую
производительность, чем репликация отдельных команд при добавлении, изменении или удалении строк в
таблице. Продолжайте читать, чтобы узнать, как это сделать! Реплицирование Статей, основанных не на таблицах
Каждая публикация SQL Server состоит из статей. Статья - объект базы данных: таблица, представление,
хранимая процедура, или UDF. Реплицирование пользовательского кода базируется на той же самой концепции,
что и реплицирование таблиц; однако, есть существенное отличие. Установка
Настройка репликации представлений, UDFs и хранимых процедур очень похожа на настройку репликации
транзакций для статей таблицы. Пожалуйста, обратитесь к более ранним статьям автора для детализации
краткого обзора установки репликации транзакций. Рис. 1 Обратите внимание, что к базе данных Pubs были добавлены хранимая процедура populate_discounts и UDF udf_check_business_day специально для этой статьи. Если Вы хотите опробовать примеры, показанные здесь, запустите следующий скрипт в вашей базе данных Pubs:
Каждый тип пользовательского кода имеет различные опции репликации, которые Вы можете выбрать в ходе установки. Все объекты позволяют Вам включить расширенные свойства вместе со схемой статьи. Если Вы не знакомы с расширенными свойствами - это способ четко отследить специфические для приложения метаданные базы данных. При репликации представлений, Вы также можете реплицировать и триггеры, построенные на представлениях. Обратите внимание, что хотя триггеры - по существу особый случай хранимых процедур, Вы не можете явно реплицировать исполнение или схему триггеров. Хранимые процедуры позволяют Вам реплицировать каждое выполнение процедуры или только исполнение в рамках сериализуемой транзакции (serializable transaction). Все эти варианты репликации формируются, используя закладку статей "Other". Следующий рисунок демонстрирует закладку"Other" окна Stored Procedure Article Properties (См. Рис. 2). Рис. 2
Когда Вы издаете пользовательский код, Мастер Создания Публикации (Create Publication Wizard) предупреждает
Вас, что вашему приложению потребуются изменения, чтобы оно правильно работало. Для создания представлений,
определяемых пользователем функций и хранимых процедур на подписчике необходимо наличие всех таблиц,
представлений или UDFs, на которых базируются эти модули кода. После того, как Вы убедитесь, что все
необходимые объекты существуют на подписчике (ах), Вы можете завершить работу мастера. ПРИМЕЧАНИЕ: Пожалуйста, обратитесь к статье автора "Setting Up Transactional Replication with SQL Server" на сайте InformIT для более подробного изучения вышеизложенного. Несмотря на то, что Вы можете реплицировать исполнение хранимых процедур, которые только читают данные, Вы должны реплицировать только такое исполнение ваших хранимых процедур, которое вносит изменения в данные. Если процедура не вносит никаких изменений в данные, то действительно не имеет смысла реплицировать ее исполнение, если только Вы не хотите имитировать нагрузку на тестовый компьютер аналогичной промышленному серверу в целях тестирования производительности. Если это так, то рассмотрите возможность использования механизмов нагрузочного тестирования, доступных в SQL Profiler вместо того, чтобы реплицировать хранимые процедуры. Синхронизация реплицируемых модулей кода
Статьи, основанные не на таблицах, будут синхронизированы только когда Snapshot agent запущен, и
инициализированы базы данных подписчика. Для этой статьи, была созданы хранимая процедура и UDF,
которые Вы видели ранее, так же как представление titleview, включенное в базу данных Pubs. Рис. 3
После того, как Вы запустите Snapshot agent, он создаст сценарии, чтобы сгенерировать реплицируемые
статьи для подписчика. Эти сценарии находятся в папке снимка, которую Вы определили в процессе установки
публикации. (По умолчанию, это папка - Program Files\Microsoft SQL Server\MSSQL\REPLDATA\UNC\server_name_publication_name_subscription_name).
После того, как отработают log reader agent и distribution agent, SQL Server удалит сценарии снимка.
Когда снимок будет доставлен, колонка Status примет значение "Active". Рис. 4
Вы могли подумать о том, что если Вы измените определение реплицируемого пользовательского кода,
то SQL Server автоматически реинициализирует подписки, но если Вы измените реплицируемую хранимую
процедуру и запустите Snapshot agent вручную - Вы получите то же самое сообщение. Кроме того, если
Вы проверите код реплицируемой процедуры на подписчике, Вы заметите, что изменения там не были применены. Рис. 5 Если Вы проверите реплицируемые статьи, Вы увидите, что на подписчике изменения были сделаны. ПРИМЕЧАНИЕ: Вы также можете реинициализировать подписчиков для проверки свойств публикации, наведя курсор на Subscriptions и выбрав Re-initialize. Варианты выполнения хранимой процедуры Статьи, основанные на хранимых процедурах, могут реплицироваться каждый раз, когда они выполняются на издателе или только когда они исполняются в рамках сериализуемой транзакции (serializable transaction). Если Вы вернётесь к экрану свойств публикации и попытаетесь изменить свойства статьи, Вы увидите, что Вы не можете изменить опции выполнения хранимой процедуры - они недоступны (см. рис. 6). Рис. 6
Чтобы сделать опции выполнения хранимой процедуры доступными, Вы должны удалить все подписки на
эту публикацию и удалить статью из публикации. После того, как Вы снова вернёте статью в публикацию,
все опции опять будут Вам доступны. EXEC populate_discounts 'great discount', 6380, 10, 90, 20 Результатом стали бы следующими три команды, переданные в базу данных дистрибутора и затем далее серверу подписчика:
{CALL sp_MSupd_sales (NULL, NULL, NULL, NULL, 'Net 120',NULL,'6380','6871','BU1032',0x10)} Обратите внимание, что для каждой строки, измененной в таблице sales, репликация сделает отдельный вызов процедуры sp_MSupd_sales; точно так же каждая строка, добавленная в таблицу discounts, приведёт к вызову процедуру sp_MSins_discounts. Теперь давайте посмотрим, что происходит, если мы реплицируем только выполнение хранимой процедуры populate_discounts. Сначала, как только мы выберем репликацию выполнения хранимой процедуры, SQL Server выдаст следующее разумное предупреждение (См. Рис. 7). Рис. 7 Пока, выберите Yes, что бы продолжить. После того, как мы подписались на публикацию, содержащую процедуру populate_discounts, выполним процедуру на издателе следующим образом: EXEC populate_discounts 'fabulous discount', 7067, 100, 1000, 25 Если мы проверим базу данных дистрибутора, исполнение приведенной выше процедуры превращается в единственную команду на подписчике: {call "dbo"."populate_discounts" ('fabulous discount', 7067, 100, 1000, 25)}
Поскольку мы имеем меньше команд, для перемещения от издателя дистрибутору и затем подписчику,
реплицируемые транзакции будут доставляться более эффективно. Результатом станет более масштабируемое
приложение, которое может поддерживать больше транзакций, чем, если бы мы должны были тиражировать
изменения в таблицах индивидуально. Выполнение процедур внутри сериализуемых транзакций Вспомните, что Вы можете реплицировать каждое выполнение хранимой процедуры или только то выполнение, которое происходит в пределах сериализуемой транзакции (serializable transaction). Сериализуемые транзакции требуют (и это не удивительно), чтоб уровень изоляции транзакции был установлен в значение SERIALIZABLE. ПРИМЕЧАНИЕ: Пожалуйста, обратитесь к статье автора "SQL Server: Details of Locking", чтобы узнать о различных уровнях изоляции транзакций, поддерживаемых SQL Server. Если мы реплицируем каждое выполнение хранимой процедуры, SQL Server будет делать попытку реплицировать даже такое исполнение, которое закончилось ошибкой на издателе. Например, предположим, что выполняется процедура populate_discounts с неправильным значением store id: EXEC populate_discounts 'special special discount', 134567, 100, 1000, 25 В результате получим:
Server: Msg 547, Level 16, State 1, Procedure populate_discounts, Line 10 Даже если выполнение процедуры потерпело неудачу на издателе, SQL Server все еще пытается выполнять это на подписчике. Процедура sp_browsereplcmds, выполненная на базе данных дистрибутора сообщает о следующем: {call "dbo"."populate_discounts" ('special special discount', 134567, 100, 1000, 25)}
Кстати, этот вызов хранимой процедуры также потерпит неудачу на сервере подписчика, потому что store
id = 134567 также не существует в базе данных подписчика.
Выполнение приведенного выше скрипта потерпит неудачу, потому что store id = 114251 не существует. Если Вы проверите базу данных дистрибутора - эта команда никогда не рассматривалась для репликации. Log reader agent просто сообщил, что нет транзакций, доступных репликации. Теперь выполним ту же самую процедуру с существующим store id:
Выполнение приведенного выше скрипта отработает на издателе и реплицируется подписчику. Таким образом, репликация исполнения процедур только в рамках сериализуемой транзакции (serializable transaction) гарантирует, что они будут выполнены на подписчике, только если они достигли цели на издателе. Имейте в виду, однако, что SERIALIZABLE уровень изоляции - самый ограничивающий способ блокировки и может иметь отрицательное воздействие на производительность вашего приложения. Резюме
Цель этой статьи состоит в том, чтобы продемонстрировать пошаговую инструкцию применения репликации
транзакций для тиражирования схемы и исполнения хранимых процедур, а так же схемы представлений и
UDFs. Репликация пользовательского кода, хотя и похожа на репликацию данных таблицы, имеет
существенное отличие, потому что требует переинициализации подписок. В отличие от репликации данных
таблицы, схема пользовательского кода реплицируется только, когда Snapshot agent запущен и генерирует
снимок для инициализации подписок. Статьи на русском языке
SQL Server 2005: версии, лицензии и стоимость
Inside the SQL Server 2000 User Mode Scheduler Самые популярные темы недели
ХП против View
Оператор INSERT |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||