Рассылка закрыта
При закрытии подписчики были переданы в рассылку "Вопросы и ответы по MS SQL Server" на которую и рекомендуем вам подписаться.
Вы можете найти рассылки сходной тематики в Каталоге рассылок.
MS SQL Server - дело тонкое...
Информационный Канал Subscribe.Ru |
#249<< #250 |
СОДЕРЖАНИЕ SQL Server 2005 & Повышение доступности данных & SQLiMail
Дата: 29.04.2005г. 18:30
Для регистрации на семинар, необходимо заполнить РЕГИСТРАЦИОННУЮ ФОРМУ, с указанием Вашей фамилии, имени, отчества и адреса электронной почты Количество мест в аудитории семинара ограничено, поэтому просим Вас не откладывать регистрацию. В день проведения семинара, всем кто был успешно зарегистрирован, по электронной почте придёт письмо с подтверждением регистрации. Для того, что бы пройти в помещение проведения семинара, при себе необходимо иметь паспорт или другое удостоверение личности. Карта проезда в представительство Microsoft
Основы I/O в SQL Server 2000 (продолжение)
По материалам статьи Bob Dorr:
SQL Server 2000 I/O Basics Планирование I/O в Microsoft SQL Server
Для полного понимания дизайна ввода - вывода в SQL Server важно знать основные
принципы операций I/O с файлами баз данных, журналами транзакций и последовательность
обслуживания транзакций. Протокол Write-Ahead Logging (WAL)
Ключевым элементом обеспечения правил ACID является протокол WAL. Протокол WAL
требует, чтобы все записи журнала транзакций, связанные с относящимися к ним
страницами данных, были сброшены на диск долговременного носителя до того, как
сами страницы данных будут сброшены на диск. SQL Server 7.0 and SQL Server 2000 Logging and Data Storage Algorithms Extend Data Reliability Рассмотрим на примере, как SQL Server поддерживает протокол WAL для инструкции INSERT. В этом примере предполагается, что индексы не используются и страница, которая будет задействована, имеет номер 150.
Блокировка и краткая блокировка являются обособленными вопросами при поддержке протокола
WAL. Блокировка поддерживает целостность данных в транзакциях, в то время как краткая
блокировка поддерживает физическую целостность данных. В предыдущем примере, SQL
Server 7.0 и SQL Server 2000 используют краткую блокировку страницы 150 только в
течение того времени, которое необходимо для физических изменений на странице, а
не на всё время исполнения транзакции. Соответствующий тип блокировки устанавливается
по мере необходимости для защиты строки, блока строк, страницы или таблицы целиком.
Обратите внимание на то, что в последнем примере не исполняется команда COMMIT.
Если страница помечена, как "грязная", записи журнала могут быть сброшены на диск,
а за ними и соответствующая страница данных, как это положено по протоколу WAL.
Блокировки защищают завершение транзакции и, если произойдёт откат операции, процесс
recovery компенсирует эти действия, восстановив страницу в надлежащее состояние.
Если бы всё это не работало описанным выше способом, SQL Server не смог бы выполнить
больше изменений, чем позволила бы разместить его физическая память.
Значение порядкового номера журнала (LSN) состоит из трех частей и представляет
собой уникальное инкрементальное возрастающее значение. Оно используется для организации
последовательности записей журнала транзакций базы данных. Это позволяет SQL Server
соблюдать правила ACID и правильно выполнять операцию recovery.
SQL Server использует краткие блокировки во время синхронизации данных. Блокировки
такого типа создаются SQL Server в непривилегированном режиме, для выполнения
операций записи или чтения. Каждая, находящаяся в памяти страница данных имеет
идентифицирующую буфер структуру (BUF). Массив BUF структур содержит информацию
о состоянии (Dirty, On LRU, In I/O), и так же о кратких блокировках.
![]() Рис. 1 ПРОДОЛЖЕНИЕ СЛЕДУЕТ Репликация таблиц с различной структурой
По материалам статьи Hilary Cotter :
Replicating to Tables of Different Schemas В данной статье рассмотрены вопросы тиражирования таблиц с различной структурой в SQL SERVER 2000. Рассмотрим четыре случая:
Случай 1 - Репликация таблицы, в случае если в таблице подписчика меньше столбцов,
чем в таблице издателя.
Случай 2 - Репликация таблицы, в случае если в таблице подписчика больше
столбцов, чем в таблице издателя.
Другая опция (An indexed view) создает пользовательский синхронизирующий объект,
который является просто представлением. Пользовательский синхронизирующий объект -
просто представление, которое подсистема репликации использует, чтобы генерировать
bcp и файлы схемы, необходимые для создания структуры таблицы и данных относительно
подписчика. С помощью Мастера Создания Публикации Вы не можете создать пользовательские
синхронизирующие объекты; они создаются, используя хранимые процедуры репликации.
Хранимые процедуры, которые используются для репликации транзакций издателя подписчику,
будут сформированы также, основываясь на этом пользовательском синхронизирующем объекте.
Случай 3 - Репликация одной таблицы издателя к двум или более таблицам подписчика
Бывают случаи, когда Вам нужно реплицировать таблицу издателя более чем одной
таблице подписчика. Например, друг автора, который работает в инвестиционном банке,
тиражировал таблицу на подписчике. Триггеры на таблице подписчика должны были писать
во вторую таблицу на издателе. Эти триггеры вызывали проблемы со временем исполнения,
поскольку транзакции реплицировались подписчику. Решение, которое предложила автор,
состояло в том, чтобы реплицировать таблицу издателя в обе таблицы, и использовать
стратегии, обсужденные ранее, чтобы обработать отличающиеся схемы.
Случай 4 - Репликация двух и более таблиц на издателе в одну таблицу на подписчике
Из всех ранее рассмотренных случаев, случай 4 - самый сложный случай. Тривиальное
решение состоит в том, чтобы вновь использовать индексированное представление. Если
Вы не можете использовать индексированное представление, то ваши варианты решения
будут более сложными. Проблема состоит в том, что когда подкомпоненты репликации
создают хранимые процедуры, используемые в репликации транзакций, происходящих на
издателе, подписчику, они могут реплицировать только транзакции, происходящие на
одной из базовых таблиц одновременно; другими словами, есть на таблице граница,
которую компоненты репликации не могут переступить. Тогда как же добавить транзакции второй таблицы в репликацию при помощи хранимых процедур?
Когда Вы реплицируете две таблицы как одну, между ними должны быть реляционные
отношения (то есть, таблицы присоединяются или являются перекрестными, или же между
ними родительские/дочерние связи). Если Вы имеете дело с реляционными отношениями
(связями таблиц), это подразумевает, что все строки одной таблицы требуют наличия
записей в других. Например, в родительских/дочерних связях, дочерняя таблица
определяет полную родительскую/дочернюю строку. Записи из пересечения или соединенные
таблицы определят полную родитель/дочка - строку. Без дочерней или перекрестной
строки, Вы не будете иметь целостных реляционных отношений. Сохраните это как c:\test.sql См. приложение 7, демонстрирующее пользовательский синхронизирующий объект. А также, приложение 8 со скриптом публикации. Затем необходимо создать свои реплицируемые хранимые процедуры, которые не представлены в этой статье из-за их очень большого размера. Заключение В завершении обзора вариантов репликации таблиц с различными схемами данных хочется отметить, что простые решения (индексированное представление или подписки с преобразованием данных) - не всегда оптимальный выбор и, потратив небольшое количество времени на размышление над этим вопросом, Вы можете придумать более масштабируемые решения.
Статьи на русском языке
Как изменился рынок OLAP за прошедший год
PRB: Additional SQL Server Diagnostics Added to Detect Unreported I/O Problems Самые популярные темы недели
Кто на чем пишет клиентов под SQL Server?
ИНТЕРНИТЬ 2005. ПРИЗНАНИЕ ГОДА |
Вопросы, предложения, коментарии, замечания, критику и т.п. оставляйте Виталию Степаненко и Александру Гладченко в форуме: Обсуждение рассылки
|
http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.winsoft.sqlhelpyouself |
Отписаться |
В избранное | ||