MS SQL Server 6.5

СОДЕРЖАНИЕ:
ВВЕДЕНИЕ 2
АРХИТЕКТУРА MS SQL SERVER 6.5 3
ПРОИЗВОДИТЕЛЬНОСТЬ 4
РАСПРЕДЕЛЕННАЯ СРЕДА УПРАВЛЕНИЯ 5
SQL-DMO (DISTRIBUTED MANAGEMENT OBJECTS) 7
ИНТЕГРАЦИЯ С ЭЛЕКТРОННОЙ ПОЧТОЙ 8
ХАРАКТЕРИСТИКИ ЯЗЫКА TRANSACT-SQL 9
MS DISTRIBUTED TRANSACTION COORDINATOR (DTC) И РАСПРЕДЕЛЕННЫЕ
ТРАНЗАКЦИИ 11
БЛОКИРОВКИ 14
НАДЕЖНОСТЬ ХРАНЕНИЯ ИНФОРМАЦИИ 16
ТИРАЖИРОВАНИЕ 18
ВОПРОСЫ БЕЗОПАСНОСТИ ДОСТУПА 20
НЕКОТОРЫЕ ВОПРОСЫ ИСПОЛЬЗОВАНИЯ MS SQL SERVER В
INTERNET/INTRANET-ПРИЛОЖЕНИЯХ 21
ЗАКЛЮЧЕНИЕ 24
СПИСОК ЛИТЕРАТУРЫ: 25
Введение
Коль скоро этот обзор посвящен серверу баз данных, невозможно не упомянуть о том,
что создание машин для хранения и управления данными является, пожалуй, одним из са-
мых значимых достижений человечества со времени изобретения письменности. Как из-
вестно, в начале было слово. Слово, ознаменовавшее переход от рефлексии в восприятии
окружающего мира к абстрактному мышлению. Возможно, именно этот переворот в соз-
нании нарушил первозданную гармонию и противопоставил человека природе. Как бы то
ни было, при всей ограниченности и имманентной неполноте вербального общения имен-
но слово служит основным способом передачи информации по сравнению, например, с
музыкой, танцем, живописью, архитектурой и т. д. В рамках той парадигмы, в которой
сегодня работает наш мозг, представляется иррациональной возможность просветления,
озарения, т. е. мгновенного получения необходимых знаний. Остается процесс постепен-
ного познания действительности, и для этого человек вынужден был научиться сохранять
информацию, полученную на предыдущих этапах. Ключевым моментом стало возникно-
вение знакового письма, которое, несмотря на большие или меньшие потери, смогло
обеспечить должное хранение формализованных знаний. Как утверждают антропологи, за
последние несколько десятков тысяч лет физиологические параметры homo sapiens прак-
тически не изменились - образно говоря, мы не стали лучше думать или глубже чувство-
вать. Единственное, что отличает современного человека от его предшественников - это
объем накопленной информации и усовершенствованные способы ее обработки. Именно
владение информацией обеспечило прогресс человеческого общества, позволив каждому
последующему поколению опереться на объем знаний и опыта, собранный предшествен-
никами, и в общем случае не изобретать заново велосипед.
Нелинейный рост во времени совокупной базы знаний цивилизации вызвал к жизни
прогрессирующую эволюцию средств хранения, обработки и представления информации
как инструментов умножения ее интеллектуальной мощи. В этом ряду применение по-
следних достижений в области компьютерных технологий сравнимо по степени важности
с изобретением печатного станка или даже его превосходит. Наблюдается и обратная за-
висимость: чем более изощренные средства используются для обработки информации,
чем быстрее растут ее объемы, тем большее значение она приобретает практически во
всех аспектах человеческой деятельности, в частности в экономике. Роль информации, как
товара или предмета труда, носит совершенно особый характер. Информация
сравнительно легко копируется без ущерба для своих потребительских свойств. В
отличие, например, от тонны нефти, одна и та же информация может быть потреблена
неоднократно, в том числе одновременно различными участниками товарных отношений.
Все мы еще с уроков обществоведения усвоили, что труд является основным источником
создания материальных благ. Однако даже у авторов учения о прибавочной стоимости
можно встретить мысль о том, что по мере развития науки главная доля прироста
общественного благосостояния будет обуславливаться ускоренными темпами обновления
основного капитала в силу роста технического прогресса. Многие современные западные
экономисты склонны считать, что человечество вступило в постиндустриальный период
своего развития, основным средством производства в котором будет выступать
информация и по отношениям собственности на которую в обществе уже начал
определяться новый правящий класс - когнитариат. Можно принимать или оспаривать эти
выводы, очевидно одно - в деятельности современного предприятия информация
становится одним из важнейших производственных ресурсов, выделяясь в
самостоятельный фактор успешного бизнеса из традиционных составляющих, таких как
кадры, клиенты, каналы сбыта, технологии. Наконец, информация не может потребляться
непосредственно: например, чтобы усвоить текст, нужно, как минимум, уметь читать.
Отсюда с ростом значения информации возрастает роль средств ее обработки. Если
зачастую стоимость информационной базы корпорации оказывается выше производимой
ею продукции и услуг, если информация - это всегда деньги (и в общем-то немалые), то
неудивительно, что рынок СУБД на сегодня оценивается в десятки миллиардов долларов.
Хотя предки нынешних СУБД существовали на мэйнфреймах еще до появления в
1969 г. знаменитой статьи Э. Кодда, положившей начало теории реляционных баз данных,
их поистине массовое распространение и беспрецедентный рост популярности
обеспечили "настольные" варианты одновременно с мировой экспансией персональных
компьютеров. Однако требования корпоративного доступа к ресурсам и появление
локальных вычислительных сетей на базе ПК привели к созданию наиболее
многочисленных на сегодня решений на базе технологии "клиент-сервер". В последнее
время необходимость поддержки мультимедийных проектов (изображений, видео, звука)
и работы с другими видами неструктурированной бизнес-информации (временные ряды,
географические карты) вызвала к жизни внедрение объектной идеологии в старые добрые
реляционные базы независимо от того, достигалось ли это полным переписыванием ядра
или интеграцией готовых реляционных и объектных баз данных. Классическую же в
терминах реляционной теории СУБД, как известно, в первом приближении можно
описать как комплекс из инструментария для поддержки таблиц и отношений между
связанными таблицами, пользовательского интерфейса для ввода, поиска данных и их
представления и высокоуровневых средств разработки приложений. Выделение в этой
среде своеобразного исполнительного информационного центра, принимающего короткие
запросы от клиентов, отыскивающего оптимальный путь их выполнения и передающего в
ответ результирующие множества, приводит к разделению функций СУБД, часть из
которых закрепляется за сервером, а часть - за клиентом. Традиционно на сервер
возлагаются обязанности по оперативному исполнению транзакций, поддержке
целостности данных, обеспечению безопасности хранения и доступа, обеспечению
пользовательских соединений и соблюдению части логики приложения, большей или
меньшей в зависимости от самого конкретного приложения. Естественно, самая
минимальная часть серверной логики должна обеспечивать проектирование структурной
схемы базы вместе с соответствующими ограничениями. На стороне клиента у нас, таким
образом, остаются другая (как правило, все-таки меньшая) часть бизнес-логики
приложения и пользовательский интерфейс. Исходя из всего сказанного выше о значении
и цене информации в современном мире не будет большим преувеличением сказать, что в
серверах баз данных (во всяком случае, для "большой шестерки") воплотились лучшие
достижения в области информационных технологий. Microsoft SQL Server 6.5 является
одним из наиболее стремительно развивающихся серверов баз данных на рынке
корпоративных СУБД. Разумеется, в рамках данной статьи невозможно подробно остано-
виться на характеристиках этого продукта в той мере, в какой это хотелось бы сделать и
какой он, безусловно, заслуживает. Поэтому мы ограничим нашу задачу рассмотрением
хотя бы некоторых базовых возможностей Microsoft SQL Server 6.5 применительно к пе-
речисленным выше функциям сервера баз данных.
Архитектура MS SQL Server 6.5
Симметричная мультипроцессорная архитектура MS SQL Server предусматривает ис-
пользование "родных" сервисов операционной системы Windows NT для управления пото-
ками (threads), памятью, операциями дискового чтения/записи, сетевыми службами, функ-
циями безопасности, а также для поддержки параллельного выполнения потоков на не-
скольких CPU. Использование потоков Windows NT позволяет MS SQL Server автомати-
чески масштабироваться при работе на многопроцессорных платформах, что исключает
необходимость дополнительной конфигурации или программной настройки. Например,
на Comdex была продемонстрирована работа MS SQL Server на платформе AlphaServer
8400 производства Digital, оснащенным 12 процессорами, 28 Гбайт памяти и 39-ти
терабайтным хранилищем. В отличие от большинства распространенных СУБД,
вынужденных иметь в своем составе механизмы дублирования ядра операционной
системы для обеспечения кросс-платформенной переносимости, MS SQL Server обладает
достаточно легковесной прозрачной архитектурой, не перетяжеленной несвойственными
ей функциями. В результате, например, при смене типа процессора не требуется заново
приобретать MS SQL Server для новой аппаратной платформы. Он ставится, по
определению, на все, на чем работает Windows NT (на сегодня это Intel, Alpha, MIPS и
PowerPC). По мере того как Windows NT завоевывает все большее признание и все
ведущие производители СУБД уже выпустили версии своих продуктов под этой
операционной системой или уже заявили о своей готовности это сделать в ближайшее
время, изначальная ориентированность MS SQL Server 6.5 на тесную интеграцию с
Windows NT выступает в качестве одного из серьезных преимуществ.
На каждое пользовательское соединение в MS SQL Server назначается отдельный ра-
бочий поток (порядка 55К) в рамках единого серверного процесса. Так как каждый из
этих потоков в действительности является потоком Win32, на них распространяются соот-
ветствующие функции контроля операционной системы, включая защиту памяти, правила
доступа к оборудованию и планирование выполнения потоков во времени (thread
scheduling). Это предоставляет улучшенные способности к масштабированию при росте
числа одновременно работающих пользователей, динамическую балансировку при загруз-
ке процессоров и повышенную надежность, так как пользовательские запросы, испол-
няющиеся на разных потоках, защищены друг от друга. Несмотря на то что пул соедине-
ний ограничен 1024 потоками, динамическое управление пользовательскими соединения-
ми и свободными потоками позволяет увеличить эту величину до 32 767. Кроме этого,
другие пулы потоков могут использоваться для параллельного выполнения операций ска-
нирования данных, удаления и обновления, резервного копирования, проверки целостно-
сти базы, индексирования, асинхронного опережающего чтения данных в кэш на основе
алгоритмов предсказания, создания и управления курсорами и т. д.
Сетевые службы Windows NT обеспечивают MS SQL Server поддержку протоколов
TCP/IP, NWLink IPX/SPX, Named Pipes (NetBEUI), Banyan Vines, AppleTalk (ADSP) и
DECNet. В версии 6.5 к ним добавилась дополнительная сетевая библиотека -
multiprotocol network library, которая "умеет слушать" порты TCP/IP, сокеты SPX или
поименованные каналы (named pipes), которые обычно выбираются динамически.
Несомненным достоинством multiprotocol является наличие сетевого сервиса,
обеспечивающего взаимодействие между процессами при помощи вызовов удаленных
процедур, что позволяет, например, использовать шифрование при передаче данных.
Производительность
Многопоточное ядро и интеграция со службами планирования потоков Windows NT
обеспечивает высокую производительность MS SQL Server при обработке OLTP- и DSS-
запросов, что особенно заметно при одновременной работе нескольких сотен пользовате-
лей. В опубликованных результатах по тестированию MS SQL Server 6.5 на максимальное
число одновременно работающих пользователей приводится цифра 3500, хотя известны
реально работающие приложения, где нагрузка доходила до 5000 одновременных пользо-
вательских соединений. За период с октября 1995 г. по декабрь 1996 г. производитель-
ность MS SQL Server, измеренная по тестам TPC-C (см. http://www.tpc.org), выросла с 2454
до 7521 транзакции в минуту, т. е. более чем в 3 раза. Для сравнения заметим, что
ежедневный объем транзакций в расчетной системе VISA составляет от 10 до 40 млн.
Темп 7,5 тыс. транзакций в минуту означает, что один MS SQL Server способен при ре-
жиме работы 24х7 обслужить немногим менее 11 млн. транзакций в сутки. Существует
еще один параметр, тесно связанный с производительностью, который, не являясь в стро-
гом смысле слова техническим, очень популярен на Западе при оценке возможностей того
или иного сервера баз данных, так как от него существенно зависит стоимость владения
продуктом (cost of ownership). Речь идет об удельной цене за транзакцию в минуту, иными
словами, сколько придется заплатить за достижение такой скорости обработки запроса. За
тот же самый период, в течение которого мы рассматривали рост производительности, по-
казатель "цена/производительность" снизился с 242 до 65 долл. за транзакцию в минуту,
что говорит о разумной стоимости систем на базе MS SQL Server при высоких требовани-
ях к скорости обработки.
Распределенная среда управления
В состав MS SQL Server 6.5 входит свыше 20 графических средств управления и ути-
лит командной строки, которые кратко охарактеризованы в табл.1.
Название
Краткое описание
Интерфейс
Исполняемый
файл
SQL Enerprise
Manager
Мощный централизованный инструмент
полного управления серверами в масшта-
бах предприятия, включая базы данных,
их объекты, предупреждения (alerts),
спланированные во времени задачи, ти-
ражирование и запросы.
Графический
sqlew.exe
SQL Executive
Локальный административный агент для
планирования задач, управления преду-
преждениями и мониторинга активности
MS SQL Server. Может быть вызван из
SQL Enterprise Manager.
Командная
строка
sqlexec.exe
Sqlmaint
Определяет план необходимых рутинных
действий по поддержке базы данных: ре-
гулярная проверка целостности, резерв-
ное копирование, перестройка индексов и
т. Д., который впоследствии будет вы-
полняться автоматически. Аналогичный
мастер включен в SQL Enterprise
Manager.
Командная
строка
sqlmaint.exe
SQL Service
Manager Sqlservr
Используется для запуска, останова, при-
остановки и возобновления деятельности
сервера и агента SQL Executive. Сам MS
SQL Server может быть запущен из ко-
мандной строки, аргументы которой оп-
ределяют его текущую настройку.
Графический,
Командная
строка
sqlmgr.exe
sqlservr.exe
ISQL/w
Средство построения запросов, анализа
плана выполнения, просмотра статисти-
ческой информации и одновременного
управления многими запросами в различ-
ных окнах.
Графический
isqlw.exe
Isql
Средство интерактивного ввода операто-
ров Transact-SQL, вызова системных про-
цедур, запуска скриптов.
Командная
строка
isql.exe
SQL Security
Manager
Управление интегрированным режимом
безопасности.
Графический
sqsecmgr.exe
SQL Trace
Средство мониторинга пользовательской
активности. Позволяет отлавливать опе-
раторы Transact-SQL, вызовы процедур,
инициируемые каждым клиентом, в ре-
альном времени или записывать в жур-
нал. Обладает возм-стями фильтрации.
Графический
sqltrace.exe
SQL Performance
Monitor
Использует для мониторинга событий и
сбора статистики по MS SQL Server стан-
дартный perfmon.ехе Windows NT на ос-
нове предоставляемого им списка объек-
тов и счетчиков.
Графический
sqlalrtr.exe
SQL Alerter
Интеграция механизма предупреждений с
соответствующими службами Windows
NT Performance Monitor.
Командная
строка
SQL Transfer
Manager
Управление переносом данных и объек-
тов с различных платформ SQL Server.
Графический
sqlxfr.exe
BCP (bulk copy)
Перенос данных между MS SQL Server и
файлами операционной системы
(например, текстовыми).
Командная
строка
bcp.exe
SQL Setup
Применяется для начальной установки,
удаления, upgrade, инсталляции дополни-
тельных компонентов и изменения на-
строек в конфигурации: поддержки сете-
вых протоколов, изменения языка, выбо-
ра кодовой страницы и порядка сорти-
ровки, модели безопасности, а также для
перестройки базы данных master.
Графический
setup.exe
Language
installation
Установка поддержки дополнительной
языковой информации (например, лока-
лизованных сообщений). Используется в
setup.exe.
Командная
строка
langinst.exe
Sort order
installation
Установка кодовой страницы символов,
чувствительности к регистру и отноше-
ния порядка над символами. Использует-
ся в setup.exe.
Командная
строка
charset.exe
Check upgrade
Используется MS SQL Server во время
upgrade для проверки совместимости су-
ществующих пользовательских баз.
Командная
строка
сhkupg65.exe
SQL Client
Configuration
Utility
Настройка клиента DB-Library, различ-
ных сетевых библиотек и/или пользова-
тельских поименованных каналов.
Графический
windbver.exe
Makepipe,
readpipe
Пытаются открыть и использовать по-
именованный канал между сервером и
клиентом.
Командная
строка
makepipe.exere
adpipe.exe
Odbcping
Проверка правильности установки
ODBC-соединения с MS SQL Server.
Командная
строка
odbcping.exe
Console
Используется вместе с оператором
DUMP для резервного копирования, если
устройством является дискета.
Командная
строка
console.exe
Printdmp
Форматированный дамп стека для нужд
отладки.
Командная
строка
printdmp.exe
Таблица 1.
Кроме этого, MS SQL Server 6.5 включает Web-assistant - программу-мастер для под-
готовки публикации на Web-cтраницах данных из базы, SQL Mail - утилиту, обеспечи-
вающую интеграцию с электронной почтой MS Mail или MS Exchange, MS Distributed
Transaction Coor-dinator (MS DTC) для проведения распределенных транзакций и некото-
рые другие средства. SQL Server, MS DTC и SQL Executive функционируют как сервисы
операционной системы. Согласованная работа этих компонентов достигается благодаря
трехуровневой архитектуре SQL-DMF (Dist-ributed Management Frame-work).
Легко масштабируемая распределенная среда управления позволяет значительно уп-
ростить процессы централизованного контроля над многими серверами, которые могут
объединяться в группы по соображениям безопасности или с административными целями,
и их объектами, к которым относятся:
• устройства (devices), на которых физически располагаются базы данных;
• резервные устройства, содержащие страховочные копии баз данных и объектов
внутри нее;
• базы данных:
• пользователи и группы пользователей;
• таблицы;
• представления;
• хранимые процедуры;
• правила (rules);
• ограничения типа default;
• типы данных, определенные пользователем;
• logins для соединения с сервером.
SQL Enterprise Manager интегрирует в себе все функции управления, включая
создание баз данных и объектов внутри них, назначение прав доступа, резервное
копирование, тиражирование и т. д. При желании имеется возможность автоматизировать
процесс составления плана поддержки базы при помощи специальной программы-
помощника (Data-base Main-tenance Wizard). Различные подходы к системному
администрированию зачастую могут содержать ряд малоприятных моментов, например
необходимость выполнять резервное копирование базы в субботу вечером. По тем же
причинам руководитель бывает вынужден командировать сотрудников в какой-нибудь
удаленный филиал, где отсутствует должным образом подготовленный IT-персонал. MS
SQL Server 6.5 позволяет решить эти проблемы, во-первых, за счет централизованного
управления удаленными серверами, во-вторых, за счет наличия мощного средства
диспетчеризации задач во времени, предоставляемого SQL Executive. Для каждой
административной функции может быть назначен временной график ее выполнения.
Практически все СУБД содержат развитые средства по ликвидации тех или иных
неблагоприятных последствий. Microsoft SQL Server, помимо этого, предоставляет
обширный инструментарий диагностики, позволяющий своевременно предотвратить
причины сбоев. Утилиты SQL Performance Monitor и Alert Manager могут использоваться
для программирования реакции сервера на различные классы событий, возникающих в
системе, в том числе и на бизнес-события. Если, например, уровень заполнения журнала
транзакций превзошел некоторое пороговое значение или по корреспондентскому счету
возникло "красное" сальдо, MS SQL Server может послать вам (или указанным вами
лицам) по электронной почте или на пейджер соответствующее предупреждение и/или
выполнить предусмотренный вами скрипт, cmd- или exe-файл для устранения ошибки, а
также зафиксировать появление этого события в системном журнале. В целом можно
сказать, что распределенная среда управления позволяет существенно упростить жизнь
администратора базы данных.
SQL-DMO (Distributed Management Objects)
В качестве промежуточного слоя в архитектуре распределенной среды управления вы-
ступают распределенные объекты управления (DMO), которые играют исключительно
важную роль в концепции построения MS SQL Server и потому заслуживают более тща-
тельного рассмотрения. По мере того как приложения приобретали все менее централизо-
ванный характер, поддержка распределенных баз данных становилась одним из самых ак-
туальных вопросов построения современных СУБД. Мы уже имели возможность убедить-
ся, что SQL Enterprise Manager позволяет осуществлять удобное администрирование рас-
пределенных серверов из единого центра, однако наряду с этим хотелось бы иметь воз-
можность программного обращения к административным функциям из высокоуровневых
языков. Обычно использовавшимся для этих целей в других СУБД сценарным языкам ти-
па REXX или PERL недоставало функциональных возможностей, библиотек классов, от-
ладчика и т. д.
Поэтому в случае с Microsoft SQL Server был избран более открытый подход: сервер
был разработан как cовместно с набором объектов управления, которые могли быть вы-
званы из любого языка программирования, поддерживающего технологию СОМ
(Component Object Model). MS SQL Server 6.5 предоставляет интерфейс OLE Automation с
более, чем 70 объектами, обладающими 1500 свойствами.
Это означает, что фактически любая из перечисленных нами в предыдущем пункте
административных задач, включая операции над базами данных, ограничениями
(constraints), триггерами, таблицами, представлениями, полями, индексами, пользователя-
ми, группами, публикациями и пр., может быть оформлена как вызов соответствующего
метода соответствующего объекта и выполнена (при наличии прав доступа) из Visual
Basic, Visual C++, Visual J++, Visual FoxPro и т. д. Как и для всякого OLE Automation
Server, при распространении приложения, использующего вызовы SQL-DMO, на клиенте
с помощью regsrv32.exe должна быть зарегистрирована библиотека поддержки объектов
sqlole65.dll. Вот, например, как можно организовать просмотр содержимого таблицы MS
SQL Server из MS Visual FoxPro 5.0:
FoxPro 5.0:
oSQLServer=CreateObject("SQLOLE.SQLServer")
oSQLServer.Connect("ntalexeysh", "sa")
oQueryResults=oSQLServer.Databases("mydb").ExecuteWithResults(
"select * from anytable")
?
for each oColumn in oSQLServer.
Databases("mydb").Tables("anytable").Columns
?? padc(oColumn.Name,oColumn. Length)+' '
next
for i=1 to oQueryResults.Rows
?
for j=1 to oQueryResults.Columns
?? oQueryResults.GetColumnString(i,j)+' '
next
next
oSQLServer.Close
Объектная модель оказалась настолько мощной, полной и гибкой, что даже SQL
Enterprise Manager (одна из основных утилит в составе MS SQL Server) был написан с ис-
пользованием DMO.
Интеграция с электронной почтой
Рассматривая функции администрирования MS SQL Server 6.5, мы упоминали о воз-
можности автоматической отправки сообщений по электронной почте в случае возникно-
вения предупреждения, превышения порогового значения одного из показателей в SQL
Performance Monitor или периодически на основе запланированного графика. В состав сер-
вера входит утилита SQLMail, которая позволяет организовать взаимодействие с Microsoft
Exchange Server для отправки и приема сообщений через расширенные хранимые
процедуры, использующие вызовы функций MAPI. К этим процедурам относятся
xp_startmail и xp_stopmail для запуска и остановки SQLMail, xp_sendmail для отправки
сообщения, xp_findnextmsg для поиска следующего сообщения в почтовом ящике,
xp_readmail для чтения сообщений и вложенных в них файлов, xp_deletemail для
удаления. Все они находятся в библиотеке sqlmap60.dll и могут использоваться в скриптах
на Transact-SQL, хранимых процедурах, триггерах и т. д. Например, в триггере на update
можно предусмотреть непосредственную отправку сообщения (без вызова raiserror, как
это было при работе с Alert Manager), если происходит попытка изменить какие-либо
важные значения в базе данных. Приведенная ниже хранимая процедура осуществляет
сканирование ящика входящих сообщений и запись параметров, поступивших сообщений
в таблицу.
create procedure scaninbox as
declare @msg_id varchar(64), @originator varchar(255),
@recipients varchar(255)
declare @cc_list varchar(255), @subject varchar(255),
@date_received varchar(255)
declare @msg_body varchar(255)
truncate table mysqldb..inbox
while (1=1) begin
exec master..xp_findnextmsg @msg_id=@msg_id output
if @msg_id is null break
exec master..xp_readmail
@msg_id=@msg_id,
@originator=@originator output,
@recipients = @recipients output,
@cc_list=@cc_list output,
@subject=@subject output,
@date_received = @date_received output,
@message=@msg_body output,
@suppress_attach='true',
@peek='false'
insert into mysqldb..inbox (msg_id, originator, recipients,
cc_list, subject, date_received, msg_body) values
(@msg_id, @originator, @recipients, @cc_list, @subject,
@date_received, @msg_body)
end
SQLMail может быть сконфигурирован для автоматического запуска одновременно со
стартом сервиса SQLExecutive. Сервис MS SQL Server должен быть стартован под учетной
записью пользователя Windows NT (user account), которая обладает локальными админи-
стративными правами и имеет соответствующие права в домене. Имя данного пользовате-
ля, под которым тот входил в Windows NT, должно совпадать с названием почтового
ящика (mailbox name) MS Exchange.
Характеристики языка Transact-SQL
В основе практически всех вышеперечисленных утилит лежит код языка Transact-
SQL. MS SQL Server 6.5 был первой СУБД, прошедшей сертификационные испытания
Правительства США на соответствие входному уровню (entry level) федеральных стандар-
тов обработки информации (FIPS) 127.2. Эти тесты основываются на известных стандар-
тах ANSI SQL92 и включают дополнительные требования, в частности по поддержке
трехуровневых архитектур. MS SQL Server 6.5 содержит большое количество черт и
функций, относящихся к более высоким уровням стандарта ANSI SQL92 (intermediate и
full), например скроллируемые в обоих направлениях курсоры с абсолютным и относи-
тельным позиционированием. Насколько мне известно, ни одна из СУБД на сегодня не
достигла полного соответствия уровню ANSI SQL92, более высокому, чем входной.
Transact-SQL включает операторы для изменения настроек сервера, пользовательской
сессии, просмотра и редактирования данных, создания и модификации баз и их объектов.
Способы обеспечения целостности данных представлены в табл. 2. В настоящее время в
MS SQL Server поддерживается только строгий (restrict) тип ссылочной целостности.
Тип целостности
Пояснения
Механизмы контроля
Entity
Определяет запись как уникаль-
ную для таблицы сущность
Primary key,
Unique key,
Identity
Domain
Определяет область допустимых
значений для поля
Default, Check,
Foreign key
Referential
Поддержка ссылочной целостно-
сти связей
Check, Foreign key,
Trigger
User-defined
Все прочие бизнес-правила на
уровне столбца и таблицы
Trigger, Rule,
Stored procedure
Таблица 2.
Вся информация об ограничениях, наложенных на таблицу, может быть просмотрена
при помощи хранимой процедуры sp_helpconstraint. Ограничения всегда вызываются
перед триггерами. Последовательность обработки выглядит следующим образом: rules,
references, check, referenced by и затем triggers. Подробная характеристика черт Transact-
SQL сама по себе могла бы составить отдельную статью или даже несколько статей, по-
этому мы ограничимся констатацией лишь некоторых его новшеств по сравнению с пре-
дыдущей версией MS SQL Server:
• операторы CUBE и ROLLUP для создания аналитических запросов при построении
систем поддержки принятия решений;
• оператор CREATE SCHEMA (создание концептуального контейнерного объекта);
• возможность временной отмены ограничений при тиражировании;
• дополнительные хранимые процедуры для настройки процесса тиражирования;
• возможность тиражирования данных типа text и image;
• возможность резервного копирования и загрузки отдельной таблицы;
• возможность использования операторов DDL внутри транзакции;
• новые опции DBREINDEX, PROCCACHE, ROWLOCK, UPDATEUSAGE для DBCC;
• оператор INSERT-EXEC позволяет осуществить непосредственную вставку резуль-
татов выполнения процедуры;
• поддержка распределенных транзакций.
Помимо обычных хранимых процедур MS SQL Server предоставляет возможность ди-
намической загрузки и выполнения функций, которые называются расширенными храни-
мыми процедурами и выполнены в виде dll-библиотек. Пример такой библиотеки, содер-
жащий расширенные процедуры для работы с электронной почтой, мы видели, когда рас-
сматривали интеграцию MS SQL Server с MS Exchange. Расширенные процедуры объеди-
нены в dll-библиотеки в целях повышения производительности по сравнению с оформле-
нием в виде отдельных процессов. Кроме расширенных процедур, входящих в Transact-
SQL, MS SQL Server позволяет создавать пользовательские расширенные процедуры c ис-
пользованием кода на C при помощи MS Open Data Service (ODS) API. MS ODS является
мощным средством разработки и применяется также для создания шлюзов к неподдержи-
ваемым штатно пользовательским ресурсам, программирования задач аудита, извещения о
событиях и пр. Добавление новых расширенных процедур осуществляется командой
sp_addextendedproc 'xp_proc', 'xp.dll', где xp_proc - новая процедура, содержащаяся в биб-
лиотеке xp.dll. Удаление ненужных процедур производит команда sp_dropextendedproc.
Так как расширенная процедура исполняется в адресном пространстве MS SQL Server,
право на ее добавление имеет только системный администратор. Дополнительный
уровень защиты обеспечивается обработчиком исключений MS SQL Server, который
предотвращает сервер от сбоя в случае нарушений защиты памяти в расширенной
процедуре.
В версии 6.5 в Transact-SQL вошли хранимые процедуры для работы с объектами OLE
Automation. Таким образом, фактически появилась возможность писать расширенные хра-
нимые процедуры на любом языке программирования, поддерживающем создание cерве-
ров OLE Automation: Visual Basic версии 4 и выше, Visual FoxPro 5.х и т. д. Экземпляр со-
ответствующего объекта создается непосредственно в коде Transact-SQL при помощи хра-
нимой процедуры sp_OACreate. Доступ к свойствам осуществляется через sp_OAGet-
Property, sp_OASetProperty. Вызов метода организует процедура sp_OAMethod. sp_
OAGetErrorInfo сообщает информацию о последней произошедшей ошибке, наконец,
sp_OADestroy высвобождает объект после его использования.
Механизм вызовов удаленных хранимых процедур (RPC) позволяет организовать
межсерверное взаимодействие и является мощным средством построения распределенных
баз. RPC означает вызов с одного сервера процедуры, принадлежащей другому серверу
баз данных. Клиентское приложение может вызывать процедуру на своем основном
сервере, которая неявно для клиента может порождать каскад вызовов удаленных
хранимых процедур на других серверах. RPC представляет собой достаточно удобный
способ работы с распределенными данными без необходимости внесения изменений в
клиентскую часть приложения.
MS Distributed Transaction Coordinator (DTC) и распределенные
транзакции
Создание распределенных приложений приводит к тому, что транзакции также при-
обретают распределенный характер. Структуризация приложения в виде многих самостоя-
тельных компонентов способна существенно повысить масштабируемость и повторную
используемость, а также упростить его разработку. Однако при этом необходимо иметь в
виду, что сбой в работе одного из компонентов (например, в результате выхода из строя
компьютера, на котором она была запущена) не должен сказываться на целостности функ-
ционирования всего приложения в целом, т. е. компонент может временно выключиться
из согласованной работы приложения, но связанные с ней сообщения должны быть обра-
ботаны корректно.
Участниками распределенной транзакции являются приложение, менеджеры транзак-
ций, менеджеры ресурсов и сами ресурсы, затрагиваемые транзакцией. В этой цепочке MS
DTC выполняет роль менеджера транзакций. Тот DTC, к первому из которых обратилось
приложение, инициировавшее транзакцию, называется первичным менеджером транзак-
ций. Пусть
HRESULT hr; ITransactionDispenser *pTxDispenser;
тогда hr = DtcGetTransactionManager(
NULL,
// имя хоста DTC, NULL
// означает данный хост
NULL,
// имя менеджера транзакций
IID_ITransactionDispenser,
// требуемый интерфейс
0,
// зарезервировано
0,
// зарезервировано
(void *)NULL,
// зарезервировано
(void **)&pTxDispenser);
возвращает указатель на первичный менеджер транзакций. После того как приложе-
ние установило соединение с соответствующим DTC-сервисом, все остальные экземпляры
DTC, поднявшиеся на хостах менеджеров ресурсов, являются подчиненными. В ответ на
вызов приложения первичный менеджер транзакций создает объект "транзакция", указа-
тель на который можно получить как
ITransaction *pTx;
hr = pTxDispenser->BeginTransaction (
NULL,
// управляющий интерфейс
ISOLATIONLEVEL_BROWSE,
// уровень изоляции
0,
// флаги изоляции
NULL,
// зарезервировано
&pTx);
// Ptr на объект "транзакция"
Как видно из примера, приложение начинает распределенную транзакцию, вызывая
метод BeginTransaction объекта "первичный менеджер транзакции". После этого оно мо-
жет работать с менеджерами ресурсов. Первое обращение к менеджеру ресурсов из при-
ложения однозначно идентифицирует текущую транзакцию. Менеджеры ресурсов, участ-
вующие в данной транзакции, должны прописаться в объекте "транзакция" при помощи
менеджеров транзакций.
RETCODE rc; HDBC hSrv1, hSrv2;•
rc = SQLSetConnectOption( hSrv1, SQL_COPT_SS_ENLIST_IN_DTC,
pTx);
rc = SQLSetConnectOption( hSrv2, SQL_COPT_SS_ENLIST_IN_DTC,
pTx);
После этого все обращения к базам данных от менеджеров ресурсов через установлен-
ные соединения выполняются от имени транзакции, пока она не завершит свое действие.
DbExecSQL(hSrv1,"INSERT INTO...");
DbExecSQL(hSrv2,"INSERT INTO..."); ...
hr=pTx->Commit(0,0,0);•hr=pTx->Release()
Инициация распределенных транзакций сервером имеет ряд дополнительных пре-
имуществ по сравнению с только что рассмотренной инициацией на стороне клиента.
К ним относятся меньшие сетевые затраты при управлении транзакциями, а также то,
что ошибка на клиенте не "подвешивает" транзакции в состоянии in-doubt. Кроме то-
го, вызовы Transact-SQL достаточно просты в использовании. При явном определении
все вызовы удаленных процедур наследуют контекст распределенной транзакции.
BEGIN DISTRIBUTED TRANSACTION
INSERT INTO ACCOUNTS VALUES (100,20)
EXEC RMTBRANCH.ACCOUNTS.DBO.DEPOSIT
100,20
COMMIT TRANSACTION
При неявном определении при помощи установок sp_configure "remote proc trans", 1
(уровень сервера) или set remote_ procedure_transactions on (уровень сессии) MS SQL
Server по умолчанию рассматривает локальные транзакции, начатые begin transaction, как
распределенные с подключением DTC, если в них содержатся вызовы удаленных
хранимых процедур.
Корректное завершение транзакции выполняется при помощи протокола двухфазной
фиксации. Когда приложение вызывает метод commit, менеджер транзакций оповещает
зарегистрировавшиеся менеджеры ресурсов подготовиться к фиксации данной
транзакции, и, после того как все они известили о своей готовности, менеджер транзакций
рассылает широковещательное сообщение зафиксировать транзакцию. Если хотя бы один
менеджер ресурсов не сообщил о готовности фиксировать транзакцию, она повсеместно
откатывается. После сообщения о готовности менеджер ресурсов пребывает в состоянии
сомнения (in-doubt) относительно общего исхода. Так как менеджеры ресурсов
регистрируются в транзакции, то менеджеры транзакций имеют возможность отслеживать
все их операции и хранят журналы о решениях фиксировать или откатить транзакцию. В
свою очередь менеджер ресурсов также ведет у себя такой журнал. Следовательно, если
имел место сбой в сети, то после его ликвидации менеджер транзакций связывается с
вышестоящим менеджером транзакций и запрашивает его об исходах. После этого
менеджер ресурсов идет на свой менеджер транзакций и получает у него информацию о
том, что делать с зависшими транзакциями. Кроме этого, если исход транзакции известен,
DTC предоставляет возможность "ручного" разрешения транзакций, чтобы слишком долго
не держать данные блокированными.
MS DTC содержит компоненты клиентской и серверной настройки. Установка кли-
ентского компонента требуется только в том случае, если данный клиент будет сам ини-
циировать распределенные транзакции, а не использовать транзакции, начатые на сервер-
ной стороне как begin distributed transaction. MS DTC достаточно легок и удобен в на-
стройке и управлении. Он имеет окна:
• в разных источниках он может также называться глобальным (global) или корневым
(root);
• конфигурации, позволяющее задать темп обновления информации, транзакции
какой давности должны показываться, место и емкость журнала, статус DTC;
• трассировки, отображающие сообщения от DTC;
• транзакций, отображающие статус текущих транзакций:
• статистики по текущим и суммарным транзакциям.
В рассмотренном примере инициации распределенной транзакции на стороне клиента
мы проиллюстрировали использование интерфейсов, соответствующих стандарту OLE
Transaction. OLE Transaction выгодно отличается от некоторых других распространенных
стандартов тем, что построен на основе объектной модели и поддерживает приложения,
работающие одновременно со многими потоками. OLE Transaction обладает улучшенными
характеристиками по сравнению с ранее разработанными стандартами, лишенными, на-
пример, возможности восстановления (recovery), инициированного менеджером ресурсов.
Тем не менее при помощи процесса XA Mapper MS DTC, выполняющего роль переводчи-
ка между XA и OLE Transaction, обеспечивается определенное взаимодействие с продук-
тами, совместимыми со стандартом X/Open DTP XA. MS DTC может участвовать в тран-
закциях, координируемых мониторами транзакций Encina, TopEnd и Tuxedo, для которых
он выглядит как некоторый менеджер ресурсов. Стандарт OLE Transaction содержит воз-
можности расширения для работы с широким спектром транзакционно защищенных ре-
сурсов, к которым могут быть отнесены документы, образы, очереди сообщений и другие
виды плохо структурированной информации.
Блокировки
MS SQL Server использует следующие типы блокировок:
shared - для операций, не изменяющих содержимое данных, например select;
update - когда сервер намеревается изменить данные, во время непосредственной записи
обновлений этот тип блокировки изменяется на exclusive (для таблиц см.intent);
exclusive - при модификации данных (insert, update, delete).
Совместимость блокировок различных типов приводится в табл. 3. Основными типа-
ми являются shared и exclusive. Блокировку типа update можно рассматривать как некий
механизм для сочетания первых двух типов блокировок в одной операции в целях предот-
вращения взаимного блокирования транзакций (deadlock). Как правило, большинство про-
цессов, модифицирующих данные, состоят из двух частей: поиск (чтение) необходимой
информации и внесение изменений. Заметим, что при наличии кластеризованного индекса
на таблицу операция вставки тоже относится к подобным процессам - сервер должен сна-
чала отыскать правильное местоположение новых записей. Разумно во избежание излиш-
ней конкуренции разрешить другим транзакциям читать данные во время первой фазы та-
кого процесса. Тогда возникает вопрос: зачем вообще вводить дополнительный тип бло-
кировки и почему нельзя обойтись первыми двумя? Ответ очевиден, если рассмотреть од-
новременно несколько таких процессов. Они будут прекрасно уживаться на стадии поис-
ка, но ни один из них не сможет монопольно запереть данные для записи, так как другие в
это время их читают. Для исключения взаимной блокировки в MS SQL Server при выпол-
нении первой фазы вводится тип блокировки update, который (см. табл. 3) не допускает
аналогичные блокировки на протяжении периода своего действия по отношению к блоки-
рованным им данным.
Тип блокировки
shared
update
exclusive
shared
OK
OK
X
update
OK
X
X
exclusive
X
X
X
Таблица 3.
Уровень блокировки может распространяться на:
• запись (для операций insert);
• cтраницу - 2-килобайтный фрагмент данных или индексов;
• расширение (extent) - 8 последовательных страниц, используется при размещении
или высвобождении страниц (например, в командах create/drop или когда операция
вставки insert требует выделения новых страниц памяти);
• таблицу, включая все входящие в нее данные и индексы .
В следующей версии блокировка уровня записи будет возможна для всех типов тран-
закций. Блокировка уровня записи на операции вставки позволяет в первую очередь ре-
шить задачу уменьшения вероятности конкуренции в OLTP-системах с массированным
одновременным вводом информации (типичный пример - операционный день банка), где
таблицы содержат только некластерные индексы или кластерный индекс построен по мо-
нотонно возрастающему ключу. По умолчанию эта опция выключена. В текущей базе
данных ее можно задействовать командой sp_tableoption ,
'insert row lock', 'true'.
Существует диалектическое противоречие, с которым наверняка сталкивался каждый
администратор базы данных или разработчик. С одной стороны, хочется уменьшить до
минимума вероятность столкновения интересов пользователей при доступе к одним и тем
же ресурсам и потому блокировать все на как можно более детальном уровне. С другой -
очень не хочется перегружать менеджер блокировок, который фиксирует информацию о
том, кто наложил блокировку, какого типа, кто ждет, пока она освободится и т. д. Напри-
мер, в MS SQL Server 6.5 каждая блокировка обходится в 32 байта. Для разрешения этого
противоречия сервер умеет автоматически повышать уровень блокировки в случае, если
блокировок предыдущего уровня детализации становится слишком много (lock escalation).
"Слишком много" - это LE Threshold Maximum в настройках конфигурации сервера, т. е.
максимальная пороговая величина числа страничных блокировок, при достижении кото-
рой происходит эскалация до уровня таблицы. По умолчанию она равна 200. Для этих же
целей используется настройка LE Threshold Percentage - в относительном выражении к
размеру таблицы (но не меньше, чем LE Threshold Minimum, что полезно для небольших
таблиц). В перспективе возможна обратная стратегия динамической деэскалации уровня
блокировки, когда блокируется заведомо больший фрагмент данных, чем требуется, но,
как только появляется транзакция, конкурирующая за данные внутри данного фрагмента,
уровень первой транзакции будет автоматически уменьшен.
Управление уровнем изоляции транзакций на протяжении всего соединения
(пользовательской сессии) осуществляется при помощи установки set transaction isolation
level , где уровень изоляции может принимать значения:
read uncommitted соответствует уровню изоляции 0 стандарта ANSI, т. е. просто за-
прещает различным транзакциям изменять одни и те же данные в одно и то же время, но
допускает грязное и неповторяющееся чтение и фантомы ;
read committed (устанавливается по умолчанию) соответствует уровню изоляции 1
стандарта ANSI, т. е. предотвращает грязное чтение;
repeatable read или serializable соответствует уровню 3 по стандарту ANSI - предот-
вращает грязное чтение, а также гарантирует, что два оператора select в разных местах од-
ной транзакции будут возвращать одинаковый результат, т. е. исключает неповторяющее-
ся чтение и фантомы.
Последний, самый надежный уровень защиты транзакций является самым неопти-
мальным с точки зрения быстродействия, так как за все приходится платить. Для более
гибкого управления уровнем изоляции для каждого оператора select может явно
задаваться опция настройки;
nolock то же, что read uncommitted, - дает возможность чтения грязных (еще не за-
фиксированных) данных, которая перекрывает аналогичные параметры конфигурации
пользовательской сессии. В операторе select можно также оговорить продолжительность
блокировки данных;
holdlock инструктирует сервер держать блокировки до завершения транзакции (по
умолчанию блокировки снимаются сразу же по прочтении требуемых данных;
Тип и уровень блокировки:
updlock заставляет применить блокировку update вместо обычной shared, использует-
ся, когда следом идет оператор update, основанный на прочитанных значениях, чтобы за-
претить update из других транзакций;
paglock заставляет сервер при любых условиях использовать блокировки уровня стра-
ницы;
tablock принудительно блокирует таблицу (shared);
tablockx принудительно блокирует таблицу (exclusive).
Просмотр текущих блокировок выполняется при помощи хранимой процедуры
sp_lock или через включение флага трассировки 1200 на клиента: dbcc traceon (3604,1200).
Также полезным являются флаги 1204 и 1205, которые выдают информацию о cитуациях
взаимной блокировки (deadlocks). MS SQL Server обладает возможностью
автоматического обнаружения deadlocks как циклов в цепочке блокировок. Он находит
первый процесс, который мог бы разорвать цикл, убивает его и откатывает все транзакции
этого процесса, находившиеся в стадии выполнения. Как правило, им оказывается тот
самый процесс, который запросил блокировку, послужившую причиной зацикливания.
После этого сервер генерирует сообщение об ошибке 1205. Если клиентское приложение
имеет обработчик ошибок, отлавливающий ошибку 1205, то оно может предпринять
соответствующие действия по исправлению ситуации, и конечный пользователь, скорее
всего, даже не узнает, что имела место взаимная блокировка.
Надежность хранения информации
В критических для бизнеса приложениях, когда сервер СУБД должен быть постоянно
доступен для клиентов, большинство профилактических работ по поддержке базы данных
приходится выполнять фактически в режиме on-line. MS SQL Server обладает возможно-
стями динамического резервного копирования данных, т. е. даже когда эти данные ис-
пользуются и изменяются клиентами. В случае сбоя оборудования, отключения питания и
т. д. механизм автоматического восстановления MS SQL Server восстанавливает все базы
данных до их последнего целостного состояния без вмешательства администратора. Все
завершенные, но не отраженные в базе транзакции из журнала транзакций применяются к
базе данных (это фактически то, что происходит при событии chekpoint), а незавершенные
транзакции, т. е. те, которые были активными на момент сбоя , вычищаются из журнала.
Как мы уже отмечали, говоря о симметричной архитектуре, операции резервного ко-
пирования и восстановления могут распараллеливаться на несколько потоков и выпол-
няться одновременно, используя преимущества асинхронного ввода/вывода. На каждое
резервное устройство отводится свой поток. Параллельное резервное копирование под-
держивает до 32 одновременных резервных устройств (backup devices), что позволяет бы-
стро создавать страховочные копии баз данных даже очень большой емкости. Возмож-
ность резервного копирования и восстановления отдельных таблиц, о чем мы упоминали,
рассматривая Transact-SQL, позволяет экономить место и время, не выполняя копирова-
ние всей базы ради только некоторых ее объектов. Однако резервное копирование отдель-
ной таблицы требует наложения на нее блокировки exclusive в отличие от резервного ко-
пирования всей базы или журнала транзакций, которые могут выполняться независимо от
степени активности пользователей. Резервным копиям может быть назначен предельный
срок хранения или дата утраты актуальности, до наступления которой место, занятое на
устройстве этими копиями, не может использоваться для размещения других резервных
копий при инициализации устройства. В качестве резервных устройств могут также при-
меняться временные устройства, не входящие в состав базы и не имеющие записей в сис-
темной таблице sysdevices:
DECLARE @tomorrow char(8)
SELECT @tomorrow = CONVERT(char(8), DATEADD(dd, 1, GETDATE())
, 1)
DUMP DATABASE pubs
TO DISK = '\\ntalexeysh\disk_d\sql_experiments\pubs.dmp'
WITH INIT, EXPIREDATE=@tomorrow, STATS
Для небольшой базы данных ее журнал транзакций обычно хранится на том же уст-
ройстве, что и сама база, и архивируется вместе с ней. Журналирование транзакций ведет-
ся по принципу write-ahead, что означает, что любое изменение сначала отражается в жур-
нале транзакций и лишь потом попадает собственно в базу. В случае нахождения журнала
транзакций на отдельном устройстве существует возможность отдельного резервного ко-
пирования журнала транзакций. Как правило, резервное копирование базы данных орга-
низуется с меньшей частотой, чем журнала транзакций. Например, сохранение журнала
транзакций выполняется ежедневно, а страховая копия всей базы может делаться раз в не-
делю, так как архивирование журнала транзакций происходит значительно быстрее по
времени и занимает меньше места, чем дамп целой базы. В отличие от резервирования ба-
зы данных дамп журнала транзакций очищает его неактивную часть, т. е. все завершив-
шиеся (зафиксированные или абортированные) с момента последнего дампа транзакции,
если только не использована опция NO_TRUNCATE. Команда DUMP TRANSACTION
TRUNCATE_ONLY, очищающая журнал транзакций, полезна в случае его переполнения,
которое можно контролировать, например, оператором DBCC SQLPERF (LOGSPACE).
Если степень переполнения журнала очень высока, можно при его очистке отказаться от
журналирования факта самого этого события: DUMP TRANSACTION NO_LOG. Если ре-
зервное копирование транзакций не представляет интереса, можно включить опцию очи-
стки последних завершенных транзакций в базе по наступлению события checkpoint.
Cмысл механизма checkpoint состоит в периодической записи данных из кэша на диск,
чтобы не допускать грязных данных. Такого рода события постоянно генерируются MS
SQL Server или возникают по инициативе пользователя. Включенная опция truncate log on
checkpoint гарантирует выполнение с определенной частотой обработчиком события дей-
ствий, приблизительно эквивалентных команде DUMP TRANSACTION
TRUNCATE_ONLY.
При восстановлении журнала транзакций соответствующие транзакции применяются
к базе данных. Это означает, что если в начале недели была сделана резервная копия всей
базы, а потом ежедневно архивировались транзакции за каждый день, то при необходимо-
сти восстановления поднимается состояние базы на начало недели и на него последова-
тельно накатываются дампы журнала транзакций за все дни, предшествующие моменту
восстановления. MS SQL Server 6.5 имеет возможность восстановления данных из журна-
ла транзакций на произвольный момент времени (разумеется, отраженный в журнале) при
помощи команды LOAD TRANSACTION STOPAT или в окне database backup and
restore выбором опции until time. Все содержащиеся в этом дампе транзакции, отмеченные
завершившимися после этого момента, будут откачены.
Возможность планирования задач резервного копирования во времени и отсылки со-
общений по e-mail в случае успешного/неуспешного завершения рассматривалась нами
при обсуждении SQL Executive.
MS SQL Server 6.5 предусматривает возможность зеркалирования устройств, пере-
ключения на зеркальные устройства в качестве основных, выключения зеркалирования и
уничтожения зеркального устройства также "на лету", т. е. без остановки штатной работы
сервера по обслуживанию пользовательских запросов. Зеркалирование и дуплексирование
устройств для работы с MS SQL Server может быть также выполнено средствами Windows
NT, а также на аппаратном уровне (поддержка различных RAID-систем и т. д.). По-
видимому, следует предполагать, что реализация первого этапа кластерной технологии
WolfPack будет поддерживать MS SQL Server 6.5 в отказоустойчивых кластерах из двух
узлов. Появление следующей версии MS SQL Server должно обеспечить работу серверов в
кластере как единого виртуального сервера.
Transfer Manager используется для экспорта/импорта объектов и данных БД на MS
SQL Server между разными аппаратными платформами, например между процессорами
Intel и Alpha, а также между разными версиями MS SQL Server, в частности из более ран-
них в более поздние или между равноценными (имеются в виду 4.х и 6.х). Очень часто
проектирование объектов базы ведется с помощью различных графических средств, но
проектная документация может требовать структуру объектов с точностью до операторов
DDL. Для получения скриптов, описывающих создание отдельного объекта базы данных,
можно использовать команду transfer из контекстного меню объекта или выбрать соответ-
ствующий класс и имя объекта в Transfer Manager. Кроме этого, содержимое данных мо-
жет быть выгружено/загружено при помощи утилиты bcp (см. табл. 1).
Тиражирование
Наличие развитого механизма тиражирования в любой серьезной системе управления
базами данных обуславливается необходимостью приближения данных к местам их непо-
средственного потребления, что является особенно важным фактором при построении
витрин данных в системах принятия решений, разгрузки приложений от избыточных
функций чтения/поиска при создании отчетов и т. д. Создание распределенных приложе-
ний с использованием средств тиражирования положительно сказывается на относитель-
ной автономии сайтов, повышении масштабируемости и производительности. Традицион-
но в построении распределенных систем данных существуют два основных подхода. Один
из них основан на плотной целостности данных (loose consistency) и рассматривался нами
в пункте, посвященном MS Distributed Transaction Coordinator. Протокол двухфазной
фиксации гарантирует идентичность данных в любой момент времени на всех узлах сети,
однако необходимо иметь в виду, что этот подход требует наличия высокоскоростных
каналов передачи данных и постоянной доступности каждого узла. Другой подход,
основанный на слабой целостности (loose consistency), допускает, вообще говоря,
некоторый временной интервал между внесением изменений в оригинал и их отражением
в образе. Приложения, основанные на принципе слабой целостности, являются
значительно менее чувствительными к доступности узлов, а также пропускной
способности и надежности каналов передачи данных. Тиражирование в MS SQL Server
построено на использовании именно второго подхода.
Основными действующими лицами в процессе тиражирования служат издатель
(publisher), дистрибьютор (distributor) и подписчик (subscriber). Поскольку тиражирование
является неотъемлемой составной частью MS SQL Server, последний может выступать в
роли каждого из них. Конфигурирование и управление каждой ролью осуществляется из
SQL Enterprise Manager через уже знакомые нам SQL-DMO или с помощью операторов и
хранимых процедур языка Transact-SQL. Репликационной единицей в плане распростра-
нения и подписки является публикация (publication). Публикация состоит из одной или
нескольких статей (articles). Статьей публикации называется отдельная таблица или ее
вертикальный и/или горизонтальный фрагмент. Вертикальное фрагментирование
осуществляется выбором соответствующих полей таблицы, горизонтальное - при помощи
условия where или специальной процедуры горизонтальной фильтрации (CREATE
PROCEDURE - FOR REPLICATION). Таблица обязана иметь первичный ключ. Как только
на издателе созданы статьи, все тиражируемые объекты отмечаются специальным
признаком в одном из полей системной таблицы sysobjects. Кроме этого, в тиражируемой
базе ведется еще три справочные таблицы. Syspublications в отдельной строке хранит
информацию о каждой новой публикации. Она связана отношением один-ко-многим с
таблицей sysarticles, содержащей информацию о статьях и их принадлежностью
публикациям. Наконец, последняя, в свою очередь, связана отношением один-ко-многим с
таблицей syssubscriptions, где содержится информация о том, каким подписчикам ад-
ресована каждая статья.
Тиражирование в MS SQL Server основано на журнале транзакций (log-based). На ка-
ждую тиражируемую базу данных на дистрибьюторе запускается процесс под названием
log reader, который читает журнал транзакций на издателе, выбирает оттуда все завершен-
ные транзакции, помеченные к тиражированию и передает их дистрибьютору, на который
с того момента возлагается вся дальнейшая ответственность по доведению этих транзак-
ций до подписчика. Издатель, таким образом, высвобождается от всякой заботы по рас-
пространению транзакций и не расходует на это свои ресурсы. Каждый подписчик обслу-
живается отдельным потоком дистрибьютора. Клиент, первым запустивший sp_replcmds
на публикуемой базе данных, рассматривается ею как log reader, все остальные попытки
это сделать вызовут сообщение об ошибке. Процедура sp_repltrans позволяет получить
список завершенных транзакций базы данных, еще не переданных дистрибьютору
(идентификатор ряда, страница и отметка времени поступления). sp_replcmds содержит
еще информацию о самих командах, связанных с этой транзакцией, и к какой статье пуб-
ликации она относится. Log reader читает эти операции, определяет соответствующие им
sql-команды и пишет их в базу данных распространения (distribution database) на дист-
рибьюторе. База данных распространения имеет таблицы MSjobs, содержащую информа-
цию о транзакциях для тиражирования, связанную как один-ко-многим с таблицей
MSjob_commands, которая разбивает каждую транзакцию на отдельные команды. Каждая
команда должна быть передана определенному подписчику, что определяется в таблице
MSsubscriber_jobs. На издателе прочитанные транзакции отмечаются как переданные на
распространение, и только после этого они могут быть оттуда уничтожены при резервном
копировании журнала транзакций (см. выше). Например, процедура sp_repldone, опреде-
ляя транзакцию в журнале базы издателя по ряду и странице, помечает ее как распростра-
ненную. Процесс синхронизации (sync task), один на публикацию, всякий раз при появле-
нии нового подписчика создает мгновенный снимок (snapshot) данных на издателе, подле-
жащих тиражированию этому подписчику. При этом создаются файлы схем данных и,
собственно, содержания (bcp-типа), которые будут переданы подписчику при распростра-
нении для обеспечения первоначальной идентичности данных.
На дистрибьюторе существуют еще два вида процесса: распространение и очистка. За-
дача распространения создается для каждой пары "тиражируемая база/подписавшаяся ба-
за", а задача очистки - для пары "издатель/подписчик". Распространение (distribution task)
применяет прочитанные из базы данных распространения sql-команды к базе данных под-
писчика. Процесс очистки (cleanup task) уничтожает все выполненные работы (т. е. тран-
закции) из базы данных распространения через некоторый настраиваемый интервал
(retention period) после того, как они были доведены до подписчика. Задача очистки может
быть создана вручную при помощи sp_addsubscriber, a задача распространения - как
sp_addsubscription (sp_subscribe). Несмотря на то что организация всего процесса тиражи-
рования может быть записана в кодах при помощи вызовов специальных хранимых про-
цедур, эта черта используется на практике крайне редко и главным образом в целях отлад-
ки. В обычных ситуациях настройка и управление тиражированием осуществляются из
графической среды SQL Enterprise Manager и планировщика задач SQL Executive.
Все задачи репликации на дистрибьюторе работают под управлением SQL Executive
(msdb...systasks) и под его контекстом безопасности. Процесс выполнения любой из них
можно контролировать в окне task history. Дополнительным средством контроля служит
SQL Performance Monitor, куда передается необходимая статистическая информация о ти-
ражировании (sp_replcounters). Соединение дистрибьютора с издателем происходит на ос-
нове DB-Library, а с подписчиком - через ODBC. Таким образом, в качестве подписчиков
MS SQL Server может выступать широкий спектр ODBC-достижимых ресурсов, к кото-
рым, например, относятся другой Access, Sybase, Oracle, DB2 и т. д. Тиражирование в MS
SQL Server основано на интегрированном режиме безопасности (см. Безопасность), следо-
вательно, между дистрибьютором и подписчиком должны быть установлены доверитель-
ные соединения (trusted connections) с использованием поименованных каналов (named
pipes) или мультипротокола. Если серверы находятся в разных доменах, между доменами
должны быть установлены двусторонние доверительные отношения. В случае небольших
объемов тиражируемых данных издатель часто совмещает с дистрибьютором на одном
MS SQL Server. Отметим также, что серверы, участвующие в тиражировании, должны
использовать одни и те же кодовые страницы.
MS SQL Server обладает обширными возможностями настройки процесса тиражиро-
вания. Мы уже упоминали о горизонтально-вертикальных фрагментах таблиц в качестве
статей публикаций. Отметим, что для каждой статьи имеется возможность назначить к
тиражированию только необходимые типы транзакций. Например, можно запретить пере-
дачу подписчикам транзакции типа "delete" в рамках данной статьи. Более того, на
каждый тип транзакций можно настроить вид пользовательских действий на стороне
подписчика. Например, при поступлении подписчику транзакций вставки и удаления они
будут отрабатываться, как обычно, а по приходе транзакции типа "update" на подписчике
будет вызываться некоторая хранимая процедура. Некоторые ограничения в
тиражируемых данных бывает нецелесообразно передавать подписчику. В этом случае
они помечаются как not for replication. Процесс синхронизации как самый дорогой в
смысле трафика предусматривает возможность ручного выполнения синхронизации или
полного отказа от синхронизации данных и передачу исключительно транзакций.
Существует и обратная возможность: подписчику с определенной периодичностью будут
поступать только мгновенные снимки данных, а не их изменения.
В зависимости от административного акцента MS SQL Server позволяет организовать
подписку на стороне издателя либо на стороне подписчика. Первый вид подписки (push
subscription) используется при централизованном распространении, когда подписки созда-
ются "выталкиванием" статей на те или иные серверы-подписчики, которые могут не
иметь своих администраторов. Второй вид (pull subscription) предполагает известную
автономию сервера-подписчика, администратор которого определяет, какие публикации
ему принимать. По умолчанию все публикации создаются со статусом безопасности
"неограничено", они видны и на них могут подписаться любые зарегистрированные серве-
ры подписки. Ограниченная публикация может быть выписана только теми серверами,
которые имеют на это соответствующие права.
Вопросы безопасности доступа
Как мы уже отмечали, говоря о преимуществах интеграции с операционной системой,
MS SQL Server использует в своей работе сервисы безопасности Windows NT. Напомним,
что Windows NT на сегодня сертифицирована по классам безопасности С2/Е3. MS SQL
Server может быть настроен на работу в одном из трех режимах безопасности. Интегриро-
ванный режим предусматривает использование механизмов аутентификации Windows NT
для обеспечения безопасности всех пользовательских соединений. В этом случае к
серверу разрешаются только трастовые, или аутентифицирующие, соединения (named
pipes и multiprotocol). Администратор имеет возможность отобразить группы
пользователей Windows NT на соответствующие значения login id MS SQL Server при
помощи утилиты SQL Security Manager. В этом случае при входе на MS SQL Server login
name и пароль, переданные через DB-Library или ODBC, игнорируются. Стандартный
режим безопасности предполагает, что на MS SQL Server будут заводиться
самостоятельные login id и соответствующие им пароли. Смешанный режим использует
интегрированную модель при установлении соединений по поименованным каналам или
мультипротоколу и стандартную модель во всех остальных случаях.
MS SQL Server обеспечивает многоуровневую проверку привилегий при загрузке на
сервер. Сначала идентифицируются права пользователя на установление соединения с вы-
бранным сервером (login name и пароль) и выполнение административных функций: соз-
дание устройств и баз данных, назначение прав другим пользователям, изменение пара-
метров настройки сервера и т.д. Максимальными правами обладает системный админист-
ратор. На уровне базы данных каждый пользователь, загрузившийся на сервер, может
иметь имя пользователя (username) базы и права на доступ к объектам внутри нее. Имеет-
ся возможность отобразить нескольких login id на одного пользователя базы данных, а
также объединять пользователей в группы для удобства администрирования и назначения
сходных привилегий. По отношению к объектам базы данных пользователю могут быть
назначены права на выполнение различных операций над ними: чтение, добавление, уда-
ление, изменение, декларативная ссылочная целостность (DRI), выполнение хранимых
процедур, а также права на доступ к отдельным полям. Если этого недостаточно, можно
прибегнуть к представлениям (views), для которых сказанное остается справедливым. На-
конец, можно вообще запретить пользователю непосредственный доступ к данным, оста-
вив за ним лишь права на выполнение хранимых процедур, в которых будет прописан
весь сценарий его доступа к базе. Хранимые процедуры могут создаваться с опцией WITH
ENCRYPTION, которая шифрует непосредственный текст процедуры, хранящийся
обычно в syscomments. Права на выполнение некоторых команд (создание баз, таблиц,
умолчаний, правил, представлений, процедур, резервное копирование баз и журналов
транзакций) не являются объектно-специфичными, поэтому они назначаются системным
администратором сервера или владельцем (создателем) базы данных при редактировании
базы данных. Администрирование пользовательских привилегий обычно ведется в SQL
Enterprise Manager, тем не менее в Transact-SQL имеются хранимые процедуры
(sp_addlogin, sp_password, sp_revokelogin, sp_addalias, sp_adduser) и операторы (GRANT,
REVOKE), которые позволяют осуществлять действия по созданию пользователей,
назначению и отмене прав при выполнении скриптов. Дополнительную возможность
администрирования привилегий предоставляют рассмотренные нами выше SQL-DMO.
Некоторые вопросы использования MS SQL Server в
Internet/intranet-приложениях
Как мы уже отмечали, SQL-DMO являются одним из наиболее мощных инструментов
доступа к информации, хранящейся на MS SQL Server, и решения административных за-
дач из клиентских приложений. Традиционные вопросы клиентского доступа к MS SQL
Server достаточно подробно освещались в литературе как по отношению к средствам раз-
работки Microsoft Visual Tools (по крайней мере применительно к Visual C++, Visual Basic,
Visual FoxPro), так и к программным продуктам фирм Borland, Powersoft и т. д. Программ-
ные модели, основанные на Microsoft Jet Database Engine (Data Access Objects), Remote
Data Objects, DB-Library, ODBC API хорошо известны и широко используются. Поэтому
мы акцентируем наше внимание на способах работы c MS SQL Server 6.5 через Internet.
Времена статических страниц объявлений и рекламы миновали - бурное развитие биз-
неса в Internet предполагает непосредственное участие клиента в совершении сделок. Го-
воря об использовании MS SQL Server при построении активных Internet/intranet-
приложений, мы снова должны обратиться к преимуществам его тесной интеграции со
всеми продуктами семейства Microsoft BackOffice. На этот раз речь пойдет об Internet
Information Server (IIS).
Помимо исполнения CGI-скриптов MS IIS предоставляет разработчикам возможность
создания с помощью соответствующего прикладного программного интерфейса (ISAPI)
приложений в виде динамических библиотек, запуск которых происходит в ответ на ко-
манду или выбор линка на Web-странице. В отличие от CGI, где каждый скрипт исполня-
ется как иной, нежели Web-сервер, процесс, что быстро "съедает" ресурсы даже достаточ-
но мощной машины при большом количестве заходов на сервер, ISAPI-приложение вы-
полняется в адресном пространстве Web-сервера, что, естественно, повышает скорость
работы и существенно экономит машинные ресурсы. В зависимости от сложности сайта и
приложений, dll могут быть предзагружены одновременно с запуском сервера, либо под-
гружаться/выгружаться из памяти по мере необходимости. К наиболее известным средст-
вам разработки приложений на основе ISAPI относятся входящий в состав MS IIS Internet
Database Connector (IDC), а также свободно распространяемый dbWeb.
Microsoft dbWeb представляет собой шлюз между 32-битными ODBC-ресурсами и MS
IIS. dbWeb предусматривает создавание схемы, содержащей описание данных и связанных
с ними Web-страниц. Он поддерживает исполнение запросов в реальном режиме времени
на основе "pull"-модели публикации, позволяя тем самым создавать активные Web-
страницы. Microsoft dbWeb структурно состоит из двух основных компонентов: dbWeb
Service и dbWeb Administrator. dbWeb Service является типичным ISAPI-приложением, ко-
торое обрабатывает пользовательские запросы, направляемые посетителем страницы
через броузер, и управляет соединениями между броузером, ODBC-ресурсом и IIS. К
функциям dbWeb Administrator относится создание HTML-страниц, содержащих
результаты выполнения запросов на основе уже упоминавшихся схем, с помощью
которых осуществляется управление публикуемыми данными. Схемы определяют сам
запрос и структуру страниц. При этом не требуется знания HTML или ISAPI, так как в
состав dbWeb Administrator входит интерактивный мастер-построитель схем (Schema
Wizard), который в традиционной для любой программы-мастера манере позволяет задать
поля поиска по методу Query-by-Example (QBE), выбрать поля для отображения в таблице
страницы результатов и определить переходы из списка записей в отдельные страницы,
содержащие развернутую информацию по текущей записи. Настройкой соответствующих
свойств можно разрешать или запрещать операции вставки, удаления и редактирования.
Для проверки прав пользователя используется система безопасности той СУБД, к которой
происходит доступ.
IDC входит в состав MS IIS. С помощью вызовов функций ODBC API он обеспечивает
прямую связь между полями HTML-формы и соответствующим ODBC-достижимым ис-
точником данных. Для доступа к данным и публикации на Web IDC использует файлы
двух типов - .idc и .htx. Файл с расширением idc (см. пример) содержит всю необходимую
информацию о соединении с источником данных, текст запроса, а также ссылку на соот-
ветствующий htx-файл. Файл с расширением htx (см. пример) служит шаблоном
страницы, на которой будут опубликованы данные из базы, а также элементы оформления
в виде статического текста, графики, видео и т. п. MS IIS распознает расширение .idc как
вызов httpodbc.dll, которая считывает http-заголовки из управляющего блока ISAPI для
определения параметров запроса. Httpodbc.dll читает и разбирает idc-файл, указанный в
URL. Имя источника, имя пользователя, пароль и пр. используются для подключения к
соответствующему ресурсу ODBC, после чего httpodbc передает на выполнение SQL-
запрос и получает результаты. Результаты используются для наполнения заготовки в виде
htx-файла, затем полученный HTML-документ MS IIS передает броузеру.
SQL Web Assistant, входящий в состав MS SQL Server 6.5, в отличие от двух только
что рассмотренных инструментов, не является ISAPI-приложением и работает только с
MS SQL Server. Web Assistant имеет интерфейс мастера (wizard), т. е. состоит из ряда по-
следовательных форм с вопросами, отвечая на которые, администратор может сэкономить
время по выполнению рутинного HTML-кодирования и получить готовую (в HTML-
кодах) страницу, содержащую результаты опубликования произвольного запроса к базе.
Полученная страница не является активной в строгом смысле этого слова, так как публи-
куется при помощи push-метода, т. е. обновление происходит по инициативе сервера и не
допускает обновления со стороны клиента. Однако сервер может производить обновление
(перегенерацию) страницы на триггерной основе или на основе расписаний задач под
управлением SQL Executive. Мастер работает только с базами данных MS SQL Server и
использует три хранимые процедуры sp_makewebtask, sp_runwebtask и sp_dropwebtask.
При необходимости они могут использоваться самостоятельно в кодах Transact-SQL.
Предположим, мы имеем каталог товаров или справочник курсов валют и хотим, чтобы
все изменения в нем автоматически отражались на Web. Для этого мы определяем задачу
публикации:
sp_makewebtask @outputfile = 'c:\rates.htm', @query = 'select
kod, kurs from rates',
@procname=web_rates, @resultstitle = 'Курсы валют',
@URL = , @reftext = 'Microsoft Home
Page', @whentype=9,
а на соответствующую таблицу "вешаем" триггер
if exists (select * from sysobjects where id =
object_id('dbo.tr') and sysstat & 0xf = 8)
drop trigger dbo.tr
go
create trigger tr on dbo.rates for insert,update,delete
as exec sp_runwebtask @procname=web_rates
go,
который будет вызывать перегенерацию страницы всякий раз, как только в таблицу
будут вноситься какие-либо изменения.
Active Data Objects (ADO) в достаточно грубом приближении служат VB-интерфейсом
к OLE DB. Их роль видится особенно важной в развитии компонентного подхода и техно-
логий универсального доступа к данным. В данном случае мы рассмотрим их использова-
ние в Microsoft Active Server Pages (ASP). Активные серверные страницы представляют
собой инструмент для эффективной разработки серверных Web-приложений, интегри-
рующих в своем составе HTML-код, VBScript и компоненты ActiveX. С их помощью в уже
существующие наработки легко могут быть встроены фрагменты кода на VBScript или
JavaScript, а также вызовы соответствующих объектов ActiveX. Помимо базовых объектов
(Application, Request, Response, Server, Session) ASP поддерживают многочисленные ком-
поненты ActiveX, которые упрощают создание и значительно повышают функциональ-
ность активных Web-страниц. Среди них нас в первую очередь будут интересовать компо-
ненты, позволяющие организовать доступ к базам данных, т. е. ADO. Например, публика-
ция результата запроса может быть выполнена, как:
<% set c=Server.CreateObject ("ADODB.Connection")
c.Open "rates","sa",""
set RS=c.Execute("select * from rates")%>
Интерфейс ADO из данного примера практически без изменений может быть исполь-
зован при работе с MS SQL Server из VB, Visual FoxPro и т. д. Таким образом, с помощью
ADO могут быть построены пользовательские компоненты для обращения к серверу баз
данных как со стороны "толстого" (Win32), так и со стороны тонкого (броузер) клиента.
Заключение
MS SQL Server 6.5 представляет собой мощный полнофункциональный сервер баз
данных, отличающийся высокой производительностью, быстротой освоения и удобным
интерфейсом администрирования. Под его управлением могут работать базы данных в
широком диапазоне от уровня среднего звена предприятия до распределенных баз мас-
штаба корпорации. Доступ к MS SQL Server возможен из большого числа средств разра-
ботки клиентских front-end, настольных баз данных и офисных продуктов. MS SQL Server
изначально ориентирован на интеграцию с другими серверами MS BackOffice, что позво-
ляет непосредственно охватить решение комплексных задач автоматизации хранения и
обработки информации, электронной почты и документооборота, построения
Internet/intranet приложений и т. д. MS SQL Server работает в как в традиционных клиент-
серверных платформах, так и в многоуровневых средах. Одним из основных
инструментов при создании распределенных многокомпонентных приложений является
Microsoft Transaction Server.
Список литературы:
1. Системы Управления Базами Данных #1/97 стр. 30-50. А.В. Шуленин.
2. Microsoft SQL Server 6.5. Комплект документации.
3. MS SQL Server 6.5 Unleashed, by David Solomon, Ray Rankins, et al,
ISBN 0-672-30956-4.
4. Microsoft SQL Server 6.5 DBA Survival Guide, by Mark Spenik & Orryn
Sledge, ISBN 0-672-30797-9.
5. Hitchhiker's Guide to Visual Basic & SQL Server, by William.R.Vaughn,
ISBN 1-55615-906-4.
6. Clustering Support for Microsoft SQL Server. White Paper.
7. Кастер Х. "Основы Windows NT и NTFS", Microsoft Press. "Русская Ре-
дакция", 1996.
8. Transaction Processing,by Jim Gray & Andreas Reuter,ISBN 1-55860-190-
2
9. Круглински Д. "Основы Visual C++", части IV-V, Microsoft Press.
"Русская Редакция", 1997.
10. Inside COM, by Dale Rogerson, Microsoft Press, ISBN 1-57231-349-8.
11. Шуленин А. "Microsoft SQL Server и активный Internet". Материалы
Форума "Информационные Технологии'97".
В разных источниках он может также называться глобальным (global) или корневым (root).
Иногда выделяют еще блокировку intent. Однако intent не является блокировкой в строгом
смысле слова, это метка в цепочке табличных блокировок, предупреждающая другие транзакции о
том, что текущий процесс намерен произвести эскалацию масштаба блокирования до уровня
таблицы.
Напомним, что под грязным чтением (dirty read) понимается ситуация, когда транзакция Т1
модифицирует запись, транзакция Т2 ее читает, Т1 тем временем откатывает изменения и Т2 ра-
ботает с записью, которая реально никогда не существовала. Неповторяющееся чтение
(unrepeatable read) возникает в случае, если Т1 читает запись, Т2 ее изменяет и Т1 снова прочиты-
вает ту же запись. Т1, дважды прочитав одну и ту же запись, фактически видела два разных зна-
чения. Фантомы: Т1 читает записи, удовлетворяющие определенному условию, после этого Т2
добавляет или удаляет записи. Если Т1 опять произведет выборку по тому же условию, она может
получить множество записей, не совпадающее с предыдущим.
25