ПРИЛОЖЕНИЕ
1
MicroSOFT ВЫПУСКАЕТ
SQL SERVER 6.5
Рекордные
показатели
по соотношению
"цена—производительность"
на платформе
Windows NT Server; новые возможности
по поддержке
Internet и интрасетей
(intranet)
В апреле на
выставке DB Expo в
Сан-Франциско
компания Microsoft
Corp. объявила о
выходе Microsoft SQL Server 6.5.
Эта СУБД, ориентированная
на платформу
Windows NT Server, представляет
собой значительный
шаг вперед по
сравнению с
Microsoft SQL Server 6.0.
Microsoft SQL Server 6.5, клиент-серверная
система управления
базами данных,
предоставляет
богатый спектр
новых возможностей,
которые облегчают
процесс создания,
внедрения и
управления
распределенными
клиент-серверными
прикладными
программами.
Основные новые
возможности:
встроенная
поддержка
приложений
Internet, усовершенствованные
механизмы
распределенных
транзакций,
тиражирование
в разнородных
средах, расширенные
распределенные
средства управления
и новая архитектура
динамической
блокировки
(Dynamic Locking).
"Microsoft SQL Server 6.5 представляет
собой значительный
прорыв в области
клиент-серверных
баз данных",-
сказал Джим
Оллчин (Jim Allchin),
вице-президент
Microsoft по настольным
системам и
системам для
бизнеса. "Начиная
с версии 6.0, а
теперь и в виде
версии 6.5, система
Microsoft SQL Server всегда
являлась одним
из базовых
компонентов
семейства
серверных
прикладных
программ Microsoft
BackOffice. Microsoft SQL Server обеспечивает
производительность,
безопасность
и взаимодействие
с другими системами,
которые так
необходимы
для организации
работы предприятия.
В то же время
эта система
весьма экономична
и проста в
управлении,
что делает ее
идеальным
решением для
компаний любого
размера".
Microsoft SQL Server 6.5 является
лучшей СУБД
для Windows NT Server и тесно
интегрируется
с Microsoft BackOffice. В Microsoft SQL Server 6.5
полностью
используются
такие возможности
Windows NT, как механизмы
обеспечения
защиты, регистрация
событий, контроль
за производительностью,
использование
потоков и асинхронный
ввод-вывод.
Система
Microsoft SQL Server 6.5 продемонстрировала
беспрецедентную
производительность
на платформе
Windows NT Server. По результатам
стандартного
тестирования
TPC-С Benchmark, которые
были объявлены
в начале апреля,
Microsoft SQL Server 6.5 обошел
Oracle 7 и Sybase System 11 по пропускной
способности,
продемонстрировав
скорость 3,641
транзакций
в минуту (tpmC). Таким
образом, система
заняла первое
место среди
всех баз данных,
при работе на
основе Windows NT Server и
на аналогичной
аппаратной
платформе. СУБД
Microsoft SQL Server 6.5 также
установила
рекорд по показателю
"цена- производительность",
который достиг
$147.62 за транзакцию.
Таким образом,
впервые база
данных преодолела
барьер в $150 за
транзакцию.
ПОВЫШЕННАЯ
ПРОИЗВОДИТЕЛЬНОСТЬ
БЛАГОДАРЯ
ДИНАМИЧЕСКОЙ
БЛОКИРОВКЕ
Высокую
скорость работы
Microsoft SQL Server 6.5 обеспечивают:
усовершенствованный
процессор баз
данных, расширенные
возможности
параллельной
работы на основе
потоков Windows NT, а
также новая
возможность
динамической
блокировки
(Dynamic Locking). Dynamic Locking - это новая
технология
Microsoft, благодаря
которой Microsoft SQL
Server может выбирать
наиболее оптимальный
уровень блокировки
на уровне строки,
таблицы или
базы данных,
что позволяет
максимизировать
скорость работы.
Только Microsoft SQL Server
обладает возможностью
динамического
выбора того
варианта блокировки,
который больше
всего подходит
для каждого
конкретного
случая.
ПРИКЛАДНЫЕ
ПРОГРАММЫ ДЛЯ
INTERNET НА ОСНОВЕ
БАЗ ДАННЫХ
Microsoft SQL Server 6.5 облегчает
создание и
управление
прикладными
программами
для внутренних
корпоративных
сетей (так называемые
"интрасети")
и Internet. Новая утилита
Microsoft SQL Server Web Assistant использует
интерфейс,
типичный для
программ-мастеров,
и шаг за шагом
помогает
администратору
базы данных
или Web-мастеру
помещать данные
из Microsoft SQL Server в сети
World Wide Web. Таким образом
можно легко
создавать
интерактивные
Web-узлы, основу
которых составляют
базы данных.
При помощи
утилиты Web Assistant,
Microsoft SQL Server автоматически
создает страницы
на основе
гипертекстового
языка описания
документов
(HTML) или заполняет
HTML- шаблоны данными
из Microsoft SQL Server, причем
это может
осуществляться
либо каждый
раз при изменении
данных, либо
в установленные
моменты времени.
В сочетании
Microsoft SQL Server 6.5 и Microsoft Internet Information
Server позволяют
при помощи
программ просмотра
Web, включая Microsoft
Internet Explorer и Netscape Navigator, создавать
запросы по
данным, хранящимся
на сервере
Microsoft SQL Server. Используя
встроенные
возможности
ODBC, Microsoft SQL Server и Microsoft Internet Information
Server обеспечивают
безупречную
работу интерактивных
Web-узлов, основанных
на базах данных.
Кроме того,
новые возможности
тиражирования
данных типа
"image" или "text" позволяют
использовать
Microsoft SQL Server в качестве
мощной платформы
для управления
информационным
наполнением
Web-узлов.
УПРОЩЕНИЕ
РАБОТЫ С РАСПРЕДЕЛЕННЫМИ
ПРИЛОЖЕНИЯМИ
БЛАГОДАРЯ
УТИЛИТЕ DTC
Microsoft SQL Server 6.5 включает
утилиту Distributed
Transaction Coordinator (DTC), которая
позволяет более
легко создавать
на нескольких
системах Microsoft
SQL Server распределенные
приложения
и обеспечивает
их автоматическое
обновление.
Таким образом
гарантируется
согласованность
и целостность
программ,
распределенных
между несколькими
серверами. DTC
также поддерживает
XA- совместимые
мониторы обработки
транзакций,
такие как Encina
компании Transarc,
Top End компании NCR
и TUXEDO компании
Novell, что делает
возможным
включение
Microsoft SQL Server 6.5 в распределенные,
разнородные
транзакции.
ТИРАЖИРОВАНИЕ
В РАЗНОРОДНЫХ
СРЕДАХ
В Microsoft SQL Server 6.5 за основу
взяты возможности
тиражирования,
представленные
в версии 6.0. Информацию
из Microsoft SQL Server можно
теперь тиражировать
в базы данных
Oracle, IBM DB2, Sybase и Microsoft Access, а также
в другие ODBC-совместимые
базы данных.
Таким образом,
Microsoft SQL Server может легко
функционировать
в смешанных
средах.
ДРУГИЕ НОВЫЕ
ВОЗМОЖНОСТИ
Дополнительные
новые возможности
включают
усовершенствованные
средства
администрирования,
повышенную
надежность
и механизмы
восстановления,
а также расширенную
поддержку
хранилищ данных.
Microsoft SQL Server 6.5 включает
усовершенствованный
интерфейс
администратора
SQL Enterprise Manager, который
используется
для управления
распределенными
системами
Microsoft SQL Server. Новая возможность
DBA Assistant автоматизирует
рутинные задачи
по обслуживанию
системы, расширенная
панель задач
и меню позволяют
легко интегрировать
средства управления
других компаний,
а интегрированные
механизмы
передачи данных
упрощают перемещение
информации.
Новые возможности
по обеспечению
помехоустойчивости
и восстановления
включают резервное
копирование
и восстановление
отдельных
таблиц, а также
восстановление
БД после сбоя
с указанием
момента времени,
по которое
выполняется
восстановление.
Помимо этого,
Microsoft SQL Server 6.5 является
первой базой
данных, в которой
реализована
поддержка
системы Compaq Online
Recovery Server, которая
обеспечивает
автоматическое
переключение
на резервный
компьютер в
случае сбоя.
К новым возможностям
организации
хранилищ данных
относятся
операторы
запросов OLAP,
утилиты CUBE и
ROLLUP, которые облегчают
поиск и выборку
многомерных
показателей.
Новая функциональность
под названием
"канал данных"
("data pipe") позволяет
Microsoft SQL Server 6.5 программно
собирать данные
из разнородных
источников,
включая Microsoft SQL
Server и другие базы
данных, и объединять
их в единое
хранилище на
основе Microsoft SQL Server.
Microsoft SQL Server 6.5 можно
бесплатно
загрузить с
FTP- узла Microsoft в России.
После загрузки
программу можно
будет использовать
в течение 120 дней.
Необходимо
набрать
http://www.microsoft.com/backoffice/sql/sqlinfo1.htm или
http://microsoft.com, а затем
выбрать соответствующий
продукт - SQL. После
чего пользователя
попросят
зарегистрироваться
и выбрать ближайший
сервер в Восточной
Европе для
загрузки программы.
(В России это
сервер по адресу
ftp://ftp.quarta.msk.ru. Он обслуживается
фирмой Quarta, которая
имеет статус
Microsoft Solution Provider).
Источник:
пресс-релиз
компании Microsoft
ПРИЛОЖЕНИЕ
2
ТЕХНОЛОГИЯ
ХРАНЕНИЯ ДОКУМЕНТОВ
В MS SQL SERVER
SQL Server позволяет
решить большинство
проблем при
создании
распределенных
систем обработки
документов
в архитектуре
клиент/сервер.
Однако реализуемые
структуры баз
данных несколько
отличаются
от классических.
КОНЦЕПЦИЯ
ДОКУМЕНТА В
РЕЛЯЦИОННЫХ
БД
Любой документ
в системе
представляет
из себя набор
записей в одной
или нескольких
таблицах. Документы
не пересекаются
и однозначно
идентифицируются
по коду (номеру)
документа. Это
означает, что
во всех таблицах
БД одним из
полей первичного
ключа является
код документа.
Служебная
информация
о документе
хранится в
специальной
таблице, включающей
в себя такие
поля как название,
дата заведения
и последней
модификации
документа и
др.
Вся прочая
информация,
составляющая
документ, хранится
в других таблицах.
Набор этих
таблиц определяется
для каждого
из типов документов
на стадии
проектирования
системы.
Документ
отличается
от простого
набора записей
в таблицах тем,
что может
быть обновлен
только в ходе
одной протяженной
транзакции.
Это объясняется
тем, что документ
имеет свои
собственные
правила целостности.
Например важна
не только
корректность
ссылок таблиц
"Покупатели",
"Заказ" и "Спецификация
заказа", но и
то, чтобы количество
товаров в
спецификации
заказа было
именно то, которое
было указано
покупателем.
Поддержание
целостности
документа
позволяет
произвести
денормализацию
структуры БД
с целью повышения
ее производительности.
КЛАССИФИКАЦИЯ
И АТРИБУТИКА
ДОКУМЕНТОВ
Документы
разделяются
на типы. Тип
определяет,
в каких таблицах
хранится тело
документа.
Набор типов
определяется
на стадии
проектирования
БД.
Для того,
чтобы не требовалось
перепрограммирование
при добавлении
к документам
дополнительных
атрибутов
(полей), применяется
следующий
механизм.
Документы
делятся на
классы (иерархическое
деление). Для
каждого из
классов задается
набор дополнительных
атрибутов,
хранящихся
в специальной
таблице.
Как показывает
практика, наиболее
эффективный
способ поиска
в больших
массивах информации,
структура
которой известна
пользователю
- способ поиска
с уточнением
критериев, т.е.
поиск по иерархическому
справочнику.
Для этого
применяется
механизм, подобный
механизму
фолдеров (папок)
в файловой
системе. Для
расширения
возможностей
системы папок
разрешено
использование
в ней ссылок
на документы
(шорткатов,
ярлыков, линков)
ПРИЛОЖЕНИЕ
3
СОПРОВОЖДЕНИЕ,
ОПТИМИЗАЦИЯ
И НАСТРОЙКА
MicroSOFT SQL SERVER
На основе
этой информации
вы сможете сами
справляться
с большинством
задач и решать
большинство
возможных
проблем.
1. Заранее
планируйте
инсталляцию
SQL Server;
2. Уделяйте
большое внимание
проектированию
баз данных,
запросов и
индексов;
3. Старайтесь
получить как
можно больше
информации
о загрузке
ресурсов сервера;
Планируйте
и автоматизируйте
регламентные
работы;
Управляйте
риском - готовьтесь
к возможным
сбойным ситуациям.
ИНСТАЛЛЯЦИЯ
MicroSOFT SQL SERVER
Инсталляция
Microsoft SQL Server в общем
случае очень
проста. Но к
ней надо подойти
ответственно,
так как во время
инсталляции
устанавливаются
несколько
параметров,
изменить которые
в дальнейшем,
при уже работающем
сервере и внесенной
в базы данных
информации,
бывает непросто.
Так что если
вы хотите выполнить
инсталляцию
только один
раз, не спешите.
SQL Server инсталлируется
при помощи
программы
setup, которая также
используется
для замены
предыдущей
версии SQL Server (например,
4.21) на новую, а
также для последующей
до-установки
некоторых
компонент
сервера и изменения
некоторых
параметров.
Требования
к аппаратуре
Вам необходим
для работы с
Microsoft SQL Server компьютер
архитектуры
Intel с процессором
486 или Pentium (SQL Server также
поставляется
в версиях для
RISC-процессоров
Alpha и MIPS). Минимально
необходимый
объем памяти
- 16 Мб, рекомендуется
начинать с 32
Мб. Если вы
соберетесь
использовать
ваш SQL Server в качестве
сервера-распространителя
при тиражировании
данных, вам
понадобится
минимум 16 Мб
для собственно
SQL Server, а ведь еще
нужна память
собственно
для Windows NT Server.
Также, естественно,
необходим
жесткий диск
с 75 Мб свободного
места. Это в
случае, если
вы установите
электронную
документацию
по SQL Server на жесткий
диск. Вы можете
не устанавливать
ее на жесткий
диск и читать
ее с CD-ROM, что сэкономит
вам 15 Мб дисковой
памяти. Я рекомендую
использовать
электронную
документацию,
т.к. очень удобно
осуществлять
в ней быстрый
поиск интересующей
вас информации.
Ну и, конечно,
необходима
операционная
система Windows NT Server
версии 3.5 или
выше (рекомендуется
3.51).
Перечисленные
требования
являются
минимальными.
О том, какая
аппаратура
нужна, чтобы
добиться оптимальной
производительности,
мы поговорим
в части, посвященной
оптимизации
и настройке
SQL Server.
Кодовая страница
Выбранная
кодовая страница
определяет,
какие символы
будут рассматриваться
сервером как
пригодные для
печати и наименования,
например, дней
недели и месяцев.
Также кодовая
страница, совместно
с выбранным
порядком сортировки,
определяет,
как будут
сортироваться
и сравниваться
между собой
символьные
строки. Очень
рекомендуется
устанавливать
на всех клиентах
и сервере одну
и ту же кодовую
страницу. SQL Server
6.0 позволяет
установить
страницу №
1251, используемую
для работы с
русским языком
в Windows, так что тут
никаких проблем
нет. Если вы не
предполагаете
работать с
русским языком,
то можно установить
страницу № 850
(многоязычная)
или № 437 (U.S. English).
Порядок сортировки
Порядок
сортировки
определяет:
Как будут
сортироваться
записи при
использовании
в запросе ORDER BY
2. Как будут
сравниваться
между собой
символьные
строки 3.Скорость
выполнения
операций сортировки.
Существует
два основных
типа порядков
сортировки:
двоичный и по
словарю.
При двоичном
символы сравниваются
и сортируются
в соответствии
с их двоичными
кодами. Это
самый быстрый
порядок сортировки,
но он имеет
один недостаток.
Большие буквы
будут в отсортированном
порядке идти
раньше маленьких,
то есть большая
буква "Я" - раньше
маленькой "а".
Это может породить
некоторые
проблемы в
вашем конкретном
приложении,
хотя в некоторых
случаях двоичный
порядок оказывается
вполне приемлемым.
Но если вы хотите,
чтобы символы
сортировались
в более удобном
для вас порядке,
вам надо использовать
один из порядков
сортировки
по словарю.
Их существует
несколько,
имеет смысл
рассмотреть
т.н. регистро-независимый
порядок
(Case-Insesitivity), при котором
буквы сортируются
независимо
от того, большие
они или маленькие.
Именно он
предлагается
при инсталляции
по умолчанию.
При использовании
этого порядка
операции сортировки
работают примерно
на 20% медленнее,
чем при двоичном.
Сетевые установки
Microsoft SQL Server 6.0 может
взаимодействовать
с клиентами
по многим протоколам
сеансового
уровня. Это:
• Named Pipes
• NWLink IPX/SPX
• TCP/IP Sockets
• Banyan VINES
• AppleTalk ADSP
• DECnet
Надо отметить,
что работа по
одному протоколу
не исключает
работы по другому
и сервер может
взаимодействовать
с клиентами
по нескольким
протоколам
одновременно.
Для этого загружаются
одна или несколько
сетевых библиотек
(Net-Libraries).
Кроме того,
протокол Named Pipes
работает над
тремя протоколами
транспортного
уровня - NetBEUI, IPX/SPX и
TCP/IP. Так что он
устраивал в
большинстве
случаев использования
SQL Server 4.2 и устанавливается
по умолчанию
именно он.
Выбор сетевой
поддержки при
инсталляции
не является
критическим,
т.к. всегда вы
можете добавить
или снять
какую-нибудь
сетевую библиотеку.
Выбор сетевой
поддержки
влияет на выбор
режима секретности,
о чем речь пойдет
чуть позже.
В версии SQL
Server 6.0 появилась
новая сетевая
библиотека
"Multi-Protocol", работающая
сразу с тремя
протоколами
сеансового
уровня - Named Pipes,
NWLink IPX/SPX, TCP/IP Sockets. Эта
сетевая библиотека
позволяет
кодировать
информацию,
передаваемую
между клиентом
и сервером.
Режим секретности
Существует
три режима
секретности
SQL Server:
Интегрированный
с Windows NT;
Стандартный;
3. Смешанный.
Интегрированный
режим позволяет
пользователю,
зарегестрировавшемуся
в домене Windows NT,
подключаться
к серверу, не
указывая имени
и пароля - для
определения
его прав на SQL
Server будет использовано
его регистрационное
имя в Windows NT. То есть
существует
единая регистрация
- в домен и на
SQL Server. Этот режим
возможен при
подсоединении
пользователя
по т.н. "доверительным
соединениям",
которые осуществляются
при использовании
сетевых библиотек
"Named Pipes" и "Multi-Protocol". По
другим соединениям
клиенты работать
в этом режиме
не могут.
Стандартный
режим требует
от пользователя
указывать имя
и пароль при
подключении
к SQL Server, независимо
от того, под
каким именем
он зарегистрировался
в Windows NT.
Основное
преимущество
интегрированного
режима состоит
в следующем.
Секретность
Windows NT имеет такие
мощные средства,
как устаревание
пароля и ограничение
на минимальную
длину пароля.
Этих средств
нет в SQL Server, но они
могут быть
использованы
для контроля
доступа к SQL Server
при использовании
интегрированного
режима секретности.
Смешанный
режим допускает
к SQL Server пользователей,
подсоединяющихся
по доверительным
соединениям
и не указавших
имени и пароля.
Если пользователь
указал имя,
отличное от
своего имени
в Windows NT, то он должен
указать соответствующий
этому имени
пароль. То же
относится к
клиентам,
подсоединяющимся
по обычным, не
доверительным
соединениям.
Имена пользователя
для SQLExecutive и SQL Server
Сервис, называемый
SQLExecutive, выполняет
очень большую
работу, связанную
с выполнением
плановых заданий,
реакцией на
происходящие
события и
тиражированием
данных. Каждый
сервис в Windows NT
функционирует
в т.н. контексте
секретности,
определяемом
именем, под
которым он
регистрируется
в Windows NT. По умолчанию
SQLExecutive регистрируется
под именем
LocalSystem, т.е. как локальный
системный
сервис. Но для
ряда процессов,
связанных с
соединением
вашего SQL Server с другими
серверами, в
первую очередь
для тиражирования,
необходимо
регистрировать
SQLExecutive под именем,
обеспечивающим
ему доступ к
другим серверам.
Это имя должно:
• относиться
к группе администраторов;
• иметь не
устаревающий
пароль;
• иметь право
регистрироваться
как сервис.
Вполне возможно
(и даже более
удобно) присвоение
сервису SQLExecutive одного
и того же имени
на разных серверах.
Хотя ипрограмма
setup и не требует
задания имени,
под которым
буде регистрироваться
сам SQL Server, лучше
после установки
сменить это
имя с LocalSystem на "нормальное"
имя. Это пригодится
при создании
резервных копий
на жестких
дисках других
компьютеров,
а также при
работе с Microsoft
Exchange.
Удаленная
и автоматическая
инсталляция
Есть два
способа облегчить
себе работу
по установке
SQL Server.
Первый
— это удаленная
инсталляция,
используя
которую вы
можете не переходить
от компьютера
к компьютеру,
и при этом установить
SQL Server на несколько
серверов.
Второй способ
— автоматическая
инсталляция,
при которой
вы заранее
создаете текстовый
файл, содержащий
параметры
инсталляции
и освобождающий
вас от необходимости
отвечать на
вопросы программы
setup.
ПРОБЛЕМЫ ПРИ
УСТАНОВКЕ?
Если вы проверили
соответствие
вашего компьютера
требованиям,
о которых мы
говорили выше,
то проблем,
скорее всего,
не будет. Но
лучше быть
готовыми ко
всему и знать,
что делать,
если они появятся.
Где можно
найти информацию
о том, что случилось
во время инсталляции:
1. Журнал
регистрации
событий Windows NT.
Журнал ошибок
SQL Server (находится
в каталоге
'SQL60LOG').
3.Выходные
файлы инсталляционных
скриптов. В
директории
'SQL60INSTALL' вы найдете
около 20 файлов
с расширением
'.SQL' (скрипты) и
соответствующих
им файлов с
теми же именами
и расширением
'.OUT' (выходные
файлы). В процессе
инсталляции
SQL Server выполняет
скрипты (они
же сценарии)
и результаты
выполнения
записываются
в выходные
файлы. Просматривая
выходные файлы,
вы можете обнаружить
сообщения об
ошибках.
ОПТИМИЗАЦИЯ
И НАСТРОЙКА
MICROSOFT SQL SERVER
Применительно
к современным
системам обработки
данных в архитектуре
клиент-сервер,
вопрос о качестве
той или иной
СУБД так или
иначе сводится
к вопросу о ее
производительности.
Ибо средства
разработки
как серверной,
так и клиентской
части позволяют
сегодня вложить
в систему практически
любую функциональность
и создать самый
удобный пользовательский
интерфейс,
хранить данные
любых мыслимых
объемов. И только
одного нельзя
гарантировать
- приемлемой
скорости выполнения
запросов. И
большая часть
усилий разработчиков
сводится к
тому, чтобы
обеспечить
эту самую приемлемую
скорость. Поэтому
большую часть
нашего семинара
мы посвятим
тому, как спроектировать
оптимальное
приложение
и затем настроить
SQL Server так, чтобы
приложение
работало с
достойной вашей
фирмы производительностью.
Ключи к производительности
• Структура
базы данных;
• Пути доступа
к данным;
• Аппаратура;
• Физическое
распределение
данных;
• Настройка
параметров
среды и SQL Server
Проектирование
базы данных
- фундамент
производительности
Грамотное
проектирование
баз данных, по
мнению многих
специалистов
и моему собственному,
является наиболее
критическим
моментом в
оптимизации
производительности
системы, построенной
на SQL Server. Если система
медленно работает
- скорее всего,
дело в плохом
проектировании
структуры
таблиц, запросов
и индексов. И
именно этому
следует уделять
главное внимание.
Следует принимать
проектные
решения, постоянно
задаваясь
вопросом - как
это решение
скажется на
производительности?
И в первую очередь,
здесь важно
оптимальное
логическое
проектирование
баз данных.
Логическое
проектирование
базы данных
Оптимальное
логическое
проектирование
баз данных
базируется
на применении
трех основных
методологий:
Моделирование
данных;
Нормализация;
3. Разумная
денормализация
Моделирование
данных
Для моделирования
данных традиционно
применяется
методология
диаграмм
"Сущность-Связь",
которая позволяет
построить
законченную
логическую
модель данных,
то есть представление
в виде связанных
таблиц. Существуют
различные
модификации
этой методологии,
как правило
реализуемые
фирмами-производителями
CASE-инструментов
в своих продуктах.
Базовая методология
построения
диаграмм
"Сущность-Связь"
зафиксирована
в стандарте
IDEF1X. Некоторые
CASE-инструменты
основаны на
методологиях,
расширяющих
возможности
этого стандарта.
К таким инструментам
относится, в
частности,
S-Designor фирмы Powersoft.
Есть и другие
методологии,
в частности
Объектно-Ролевое
моделирование,
которое позволяет
описывать
предметную
область на
более абстрактном
уровне, чем
моделирование
"Сущность-Связь",
по крайней мере
базовый вариант
последней.
Объектно-Ролевое
моделирование
реализовано
в CASE-инструменте
InfoModeler фирмы Asymetrix. Применение
S-Designor и InfoModeler рассмотрено
в докладе
"Проектирования
структур баз
данных с использованием
CASE-инструментов
S-Designor и InfoModeler".
Нормализация
В процессе
построения
логической
модели осуществляется
также нормализация,
т.е. построенная
модель удовлетворяет
требованиям
трех уровней
нормализации:
1. Первая нормальная
форма - отсутствие
многозначных
полей.
Вторая нормальная
форма - каждое
неключевое
поле в таблице
должно зависеть
от всего первичного
ключа, а не от
какой-либо его
части.
3. Третья нормальная
форма - неключевое
поле не должно
зависеть от
другого неключевого
поля.
В сущности,
нормализация
приводит к
большему количеству
более узких
таблиц в логической
модели. Соблюдение
правил нормализации
снижает избыточность
данных и, соответственно,
сложность их
обновления
и занимаемый
ими объем на
носителе. Связи
между полученными
таблицами
разрешаются
через построение
сложных соединяющих
запросов. Оптимизатор
запросов SQL Server
умеет строить
эффективные
планы выполнения
запросов, связывающих
высоко нормализованные
таблицы. Этому
способствует
также построение
индексов, основанное
на связи первичных
и внешних ключей
таблиц.
CASE-инструменты,
как правило,
строят логическую
модель в третьей
нормальной
форме.
Денормализация
Однако зачастую,
разумная, именно
разумная,
сознательная
денормализация
логической
структуры может
повысить скорость
выполнения
определенных
запросов. Если
проектирование
нормализованной
структуры идет,
так сказать,
"от данных",
то денормализация
идет "от процессов".
То есть, денормализация
должна быть
основана на
знании того,
какие действия
будут осуществляться
с данными при
работе с ними
клиентских
приложений.
Вот несколько
практических
советов по
денормализации:
• Если спроектированная
база данных
требует связывания
в одном запросе
4-х и более таблиц,
стоит ввести
избыточность,
добавляя поля
в таблицы или
целые таблицы.
• Замените
длинные ключи
на искусственно
введенные
короткие ключи
и текстовые
поля на символьные
строки ограниченной
длины.
• Если определенная
группа запросов
затрагивает
только часть
полей широкой
таблицы, ее
можно разбить
на несколько
более узких
таблиц, продублировав
в них первичный
ключ исходной
таблицы. Это
может уменьшить
количество
операций ввода-вывода
и облегчить
одновременную
работу разных
пользователей.
• Если определенная
группа запросов
затрагивает
только часть
строк таблицы
большого объема,
ее можно разбить
по горизонтали
на несколько
таблиц, особенно
если определенные
группы пользователей
обращаются
к разным горизонтальным
подмножествам
таблицы.
Противоречия
логического
проектирования
Нормализация
и денормализация
- две диалектически
противоречивые
стратегии,
которые необходимо
применять при
проектировании
логической
структуры. И
это не единственное
противоречие
в этом процессе.
Например -
использование
типов данных
с переменной
длиной приводит,
с одной стороны,
к сокращению
занимаемого
дискового
пространства,
к меньшему
количеству
операций чтения
и, таким образом,
к сокращению
времени на
чтение таблицы.
С другой стороны,
обновление
таких строк
происходит
путем удаления
старой и вставки
новой, в то время,
как строки с
полями фиксированной
длины могут
обновляться
"на месте", что
значительно
быстрее. Еще
один пример
- использование
большого числа
индексов сокращает
время выполнения
запросов, соединяющих
несколько
таблиц и сортирующих
полученные
строки. Но в то
же время, индексы
замедляют
операцию вставки
новых записей.
Приложения
по обработке
данных можно
условно разделить
на два класса:
• Системы
оперативной
обработки
транзакций,
характеризующиеся
большой интенсивностью
вставки и обновления
записей.
• Системы
поддержки
принятия решений,
характеризующиеся
сложной обработкой
больших объемов
данных. Эти
приложения,
как правило,
не обновляют
данные, но производят
различные
суммирования,
сортировки
и связывают
данные из
многочисленных
таблиц.
Поняв, к какому
классу относится
ваше приложение,
можно делать
выбор из противоречивых
альтернатив
при проектировании
логической
структуры.
Правда, часто
приложения
должны сочетать
качества как
одной, так и
другой системы,
так что приходится
находить компромиссы.
В этом случае
может выручить
разделение
приложения
на две подсистемы,
каждая из которых
функционирует
на своем SQL Server'е,
и обеспечение
информационной
связи подсистем
при помощи
тиражирования
данных.
Проектирование
путей доступа
Когда создана
структура базы
данных, можно
проектировать
запросы, при
помощи которых
клиентские
приложения
будут манипулировать
данными на
сервере, осуществляя
операции выборки,
вставки, изменения
и удаления
данных. Каждый
запрос характеризуется
определенным
путем доступа
к данным. В понятие
пути доступа
входит:
• структура
таблицы, к которой
обращается
запрос;
• поля, по
которым происходит
поиск;
• индексы,
которые можно
использовать
для ускорения
поиска;
• состав полей,
которые обновляются
в процессе
выполнения
запроса.
Цель проектирования
оптимальных
путей доступа
- минимизация
количества
операций
чтения/записи
при выполнении
клиентских
запросов. Основа
для этого должна
быть заложена
на этапе проектирования
структуры базы
данных.
Оптимизация
путей доступа
Главный вопрос
в оптимизации
путей доступа
- использование
индексов. Если
некий запрос
выбирает строки
в таблице по
полю "field1", то при
отсутствии
индекса по
этому полю
сервер будет
сканировать
всю таблицу,
что может быть
очень "дорого"
в терминах
операций чтения.
Если по полю
"field1" построен
индекс, то количество
операций чтения
может сократиться
в несколько
тысяч раз. Индексы
существенны
также при операциях
соединения
таблиц (JOIN) и операциях
сортировки.
Какие еще
моменты необходимо
учитывать при
проектировании
путей доступа?
Это
• обращение
клиента к серверу
через SQL-запрос
или через вызов
хранимой процедуры.
Второй вариант
работает немного
быстрее, но
необходимо
учитывать один
важный нюанс.
План выполнения
хранимой процедуры
составляется
при ее первом
(после создания)
вызове и затем
хранится в
кэше. Этот план
оптимизируется
для набора
параметров
и индексной
статистики,
имевших место
именно при
первом вызове.
При дальнейших
вызовах этот
план может
оказаться
неоптимальным,
то есть может
потребоваться
перекомпиляция
процедуры,
например, путем
вызова с опцией
"WITH RECOMPILE".
• проведение
операций обновления
"на месте" или
путем удаления
с последующей
вставкой - обновление
"на месте"
проходит гораздо
быстрее.
• наличие
триггеров,
срабатывающих
на вставку или
изменение
записи, может
существенно
замедлить
соответствующие
операции.
Очевидно,
что в процессе
проектирования
путей доступа
может возникнуть
необходимость
пересмотреть
решения, принятые
при проектировании
структуры
данных.
Также очевидно,
что при разработке
крупных приложений
бывает невозможно
проанализировать
все пути доступа.
Сосредоточиться
нужно на критических
путях доступа,
учитывая размер
таблиц, частоту
обращений к
ним и требования
к времени выполнения
запроса
Аппаратура
и производительность
Не случайно
аппаратура
стоит у нас на
3-м месте среди
ключей к
производительности.
Этим я хотел
подчеркнуть
важность хорошей
структуры и
путей доступа.
На самом деле,
конечно, аппаратура
важна не меньше.
Прошу простить
несколько
банальную
аналогию, но
грамотный
проект базы
данных, оптимальные
пути доступа
и быстрый сервер
так важны для
производительности
системы, как
опытные водитель
и штурман и
мощный автомобиль
для победы на
авторалли.
Процессор
Процессор,
как правило,
достаточно
интенсивно
используется
SQL Server'ом.
Чтобы хотя
бы качественно
оценить нагрузку
на процессор,
необходимо
ответить на
следующие
вопросы:
• Будет ли
компьютер
выделен для
SQL Server?
• Сколько
клиентов будут
работать с
сервером?
• Каково
ожидаемое число
транзакций
в единицу времени?
• Велика ли
доля агрегативных
операций?
Количественно
оценить загрузку
процессора
можно, проводя
тестовые испытания
и отслеживая
параметры
производительности
при помощи
Windows NT Performance Monitor.
Лучше, конечно,
не скупиться
на процессоре
и ограничить
свой выбор
снизу хотя бы
486/50.
Память
Память используется
SQL Server'ом очень
интенсивно
и многообразно.
Память расходуется
на кэширование
данных и процедур,
на поддержку
подсоединений
клиентов, открытых
баз данных,
открытых таблиц,
блокировок
таблиц и т.д.
Из всех этих
пунктов подробно
остановиться
имеет смысл
на кэшировании.
Все остальные
расходы памяти
при 50 одновременно
работающих
клиентах и
достаточно
большом количестве
открытых объектов
не превышают
3.5 Мб. Вся остальная
память, доступная
SQL Server, используется
под кэш. Настраиваемый
параметр "procedure
cache" регулирует
соотношение
между кэшем
данных и кэшем
процедур. По
умолчанию
данные занимают
80% кэша. Приведенная
ниже таблица
содержит рекомендации
по распределению
памяти между
SQL Server и остальной
системой на
выделенном
компьютере.
SQL Server использует
память в количестве,
отведенном
ему настраиваемым
параметром
"memory".
| Machine Memory, (MB) | SQL Server Memory, (MB) |
|
|
Не следует
выделять SQL Server
слишком много
памяти (относительно
общего объема
памяти компьютера),
т.к. это может
привести к
интенсивному
вытеснению
страниц оперативной
памяти на диск
("paging"), что резко
понижает
производительность.
Диски
Эффективность
дисковой подсистемы
может стать
критической
для производительности
вашей системы,
особенно если
речь идет об
объемах данных,
значительно
превышающих
объем памяти,
отведенной
под кэш. Вот
какие свойства
и компоненты
дисковой подсистемы
помогут в повышении
производительности:
Быстрый
интеллектуальный
SCSI-2 контроллер
Кэш-память
на контроллере
Bus Master card - процессор
на плате снижает
нагрузку на
CPU
Поддержка
асинхронного
чтения и записи
32-битные EISA или
MCA
Аппаратная
поддержка RAID
Быстрые SCSI-2
диски
Кэширование
с опережающим
чтением
Минимальный
рекомендуемый
вариант дисковой
подсистемы
- SCSI-контроллер
и два SCSI-диска
- один для баз
данных и другой
для журнала
транзакций.
Абсолютно
верных рекомендаций
быть не может
и в каждом конкретном
случае необходимо
учитывать все
требования
и подбирать
оптимальную
дисковую
конфигурацию.
Сеть
Так же как
и с дисками,
лучше иметь
интеллектуальную
сетевую карту,
которая сэкономит
процессорное
время и расходы
памяти. Вот
некоторые
рекомендации:
• 32-битные
EISA или MCA •Bus Master card - процессор
на плате снижает
нагрузку на
CPU;
• Кэш-память
на адаптере
Физическое
распределение
данных
Распределение
баз данных,
журналов транзакций,
логических
групп таблиц
и индексов по
различным
физическим
устройствам
должно обеспечить
равномерную,
и значит, оптимальную
загрузку устройств
ввода-вывода.
При планировании
физического
распределения
данных следует
учитывать
следующие
рекомендации:
• Распределение
баз данных и
журналов транзакций
на разные физические
устройства
повышает
производительность.
• Размещение
большой таблицы
и ее некластеризованного
индекса на
разных устройствах
может повысить
производительность.
• Распределение
большой, активно
используемой
таблицы по
нескольким
устройствам
может повысить
производительность.
• Использование
чередования
данных в виде
RAID 0 или RAID 5 повышает
производительность.
Даже хорошо
спланированное
физическое
распределение
данных нуждается
в последующем
отслеживании
реальных нагрузок
на физические
устройства
и корректировке
схемы распределения.
Параметры
среды и SQL Server
Настройка
параметров
среды и самого
SQL Server - еще один ключ
к производительности.
Однако, он
действительно
может помочь
лишь в том случае,
если правильно
подобраны
ключи, описанные
выше - структура
базы данных,
пути доступа,
аппаратура
и физическое
распределение
данных. Можно
ожидать, что
оптимальный
подбор параметров
среды и SQL Server даст
прирост производительности
на 5-10%.
Операционная
система и
производительность
Вот несколько
советов по
настройке
Windows NT Server для повышения
производительности
SQL Server:
• Установка
режима "Foreground and
Background Applications Equally Response" (Control Panel -
System - Tasking).
• Установка
режима "Maximize Throughput
for Network Applications" (Control Panel - Network - Server -
Configure).
• Размещение
файла подкачки
"pagefile.sys" на физическом
диске, не занятом
данными SQL Server. Еще
лучше, если эти
диски обслуживаются
разными контроллерами.
• Файловая
система может
быть любой (FAT
или NTFS). Небольшой
выгоды можно
ожидать, если
разместить
слабо обновляемые
базы данных
на NTFS, а журнал
транзакций
- на FAT.
• Желательно
отключить все
ненужные сервисы
Windows NT.
Параметры
инсталляции
и настройки
SQL Server
Из всех параметров
инсталляции
SQL Server, которые трудно
изменить в
дальнейшем,
на производительность
влияет только
порядок сортировки,
о чем мы уже
говорили при
обсуждении
инсталляции
SQL Server. Выбор двоичного
порядка сортировки
может на 20-30% повысить
производительность
некоторых
операций по
сравнению с
другими порядками,
использующими
словарный
порядок символов.
Следующие
параметры SQL
Server могут повысить
производительность:
• 'priority boost' (может
понизить скорость
выполнения
других процессов
на сервере).
Чтобы иметь
возможность
задать этот
параметр, следует
сначала установить
в 1 параметр
'show advanced option'
• 'memory' - задает
размер памяти,
доступной SQL
Server. Чем больше,
тем лучше, но
в рекомендованных
пределах (см.
выше)
• 'user connections' - следует
избегать
неоправданного
завышения этого
параметра ,
т.к. это уменьшает
объем кэша.
Увеличение
этого параметра
на 1 "стоит"
примерно •24
Кбайт памяти
для кэша
• 'procedure cache' - процент
кэша, отведенный
по хранимые
процедуры. При
большом числе
используемых
хранимых процедур
можно повысить.
• 'tempdb in RAM' - может
существенно
( иногда в несколько
раз) повысить
скорость выполнения
выборок, требующих
сортировки
или группирования
строк.
Кроме того,
определенное
влияние на
производительность
могут иметь
сетевые установки
- выбор транспортных
и сеансовых
протоколов.
Замечено, например,
что работа по
Named Pipes более всего
эффективна
над TCP/IP. Это связано
с тем, что TCP/IP более
эффективно
наполняет
передаваемые
по сети кадры,
что снижает
общее число
передаваемых
кадров и, соответственно,
повышает
производительность.
Стратегия
настройки
Под настройкой
понимаются
изменения
параметров
SQL Server, операционной
системы, аппаратуры,
физического
размещения
данных, путей
доступа и даже
логической
структуры базы
данных - то есть
всех параметров
системы и приложения
с целью улучшения
производительности.
Настройка
обычно включает
в себя следующие
шаги:
1. Мониторинг
параметров
производительности;
Предположение
о причине низкой
производительности;
Выбор параметра
для изменения;
Изменение
выбранного
параметра;
5. Переход к
шагу 1.
Очень важно
собрать максимум
информации,
чтобы делать
обоснованные
предположения
о том, что является
узким местом
в производительности
системы. Узким
местом может
быть как аппаратный
ресурс, так и
структура
запросов и
индексов. Сделав
предположение,
можно вновь
вернуться к
мониторингу,
чтобы собрать
уточняющую
информацию.
Следует
учитывать, что
если SQL Server работает
не на выделенной
машине, то работа
других приложений
и сервисов
может поглощать
существенную
долю ресурсов
машины, отбирая
их у SQL Server. В любом
случае следует
оценивать
производительность
и загрузку
ресурсов всей
системы.
Мониторинг
Собирать
информацию
о параметрах,
характеризующих
производительность
SQL Server удобнее всего
с помощью Windows NT
Performance Monitor, который
позволяет
отследить более
30 параметров
работы SQL Server. Также
важно наблюдать
некоторые
параметры
Windows NT. Основными
являются следующие:
• Processor: %Processor Time - преобладающее
значение выше
80% говорит о том,
что процессор
является узким
местом. Это
может быть
вызвано, в частности,
неоптимальной
структурой
базы данных.
• Memory: Pages/sec - должен
быть не выше
5-10. Этот параметр
характеризует
интенсивность
вытеснения
страниц оперативной
памяти на диск
(paging).
• SQLServer: Cache Hit Ratio - (процент
нахождения
требуемой
страницы памяти
в кэше, а не на
диске); должен
быть не ниже
80%
• SQLServer: I/O - Page Reads/sec - высокое
значение этого
параметра
говорит о
недостаточном
размере кэша.
• Physical Disk: Disk Queue Length или
Logical Disk: Disk Queue Length - значение
выше 2 говорит
о том, что узким
местом является
диск.
• Собирать
информацию
по данным параметрам
следует как
в среднем за
продолжительный
период времени,
так и в моменты
пиковой нагрузки.
Удобным может
оказаться
запись отслеживаемых
параметров
в журнальный
файл (что позволяет
сделать Performance
Monitor) с последующим
анализом в
спокойной
обстановке.
Кроме этого,
могут помочь
такие предложения
языка Transact-SQL:
• DBCC MEMUSAGE - информация
об использовании
кэша данных
и процедур
• SET SHOWPLAN ON - просмотр
плана выполнения
запроса, информация
об использовании
индексов
• SET STATISTICS TIME ON - показывает,
сколько времени
было затрачено
на выполнение
каждой стадии
запроса
• SET STATISTICS IO ON - показывает,
сколько операций
логического
и физического
чтения было
произведено
над каждой
таблицей при
выполнении
запроса.
Настройка.
Память
Если параметр
SQL Server: Cache Hit Ratio (процент
попаданий в
кэш), доступный
для наблюдения
через Windows NT Performance Monitor,
по величине
меньше 80%, то
увеличение
размера кэша
должно повысить
производительность.
Оценить необходимый
размер кэша
для процедур
и данных можно,
выполняя самые
часто встречающиеся
запросы и хранимые
процедуры и
анализируя
содержимое
кэша при помощи
предложения
DBCC MEMUSAGE. Следует
помнить, что
хранимые процедуры
в SQL Server не являются
реентерабельными,
т.е. если несколько
клиентских
процессов
одновременно
вызывают одну
и ту же хранимую
процедуру, то
в кэше окажется
несколько ее
копий.
Если же параметр
Memory: Pages/sec постоянно
выше 5-10, то памяти
не хватает
системе в целом
и нужно либо
остановить
какие-либо
приложения
или сервисы,
или добавить
памяти в компьютер.
Настройка.
Запросы и индексы
Предположим,
у нас есть запрос,
который медленно
выполняется.
Мы собрали
информацию
о нагрузке на
процессор,
память, диски
и сеть и выяснили,
что узким местом
является процессор,
т.к. он используется
на 100% при выполнении
запроса, а остальные
ресурсы явно
недогружены.
Можно, конечно,
заменить процессор
или перейти
на многопроцессорную
платформу, но
сначала мы
проанализируем
пути доступа.
Задав перед
выполнением
запроса опцию
"SET SHOWPLAN ON", мы получим
информацию
об использовании
индексов. В
первоначальном
варианте запроса
индексы не
используются.
Построив индекс
по полю, являющемуся
аргументом
поиска в запросе,
мы существенно
сокращаем
количество
операций чтения
и, соответственно,
время выполнения
запроса.
Следует
учесть, что
оптимизатор
запросов SQL Server
делает вывод
об использовании
того или иного
индекса при
выполнении
запроса на
основании
статистических
данных о распределении
значений ключей
индекса. Эти
статистические
данные не обновляются
при обновлении
данных в таблице.
Для обновления
статистики
можно или перестроить
индекс, или
использовать
предложение
"UPDATE STATISTICS".
СОПРОВОЖДЕНИЕ
MICROSOFT SQL SERVER
В последнем
разделе мы
рассмотрим
задачи, которые
приходится
выполнять
администратору
SQL Server в процессе
ежедневной
эксплуатации
сервера. Их
можно разбить
на две основные
группы:
1) работы, которые
можно и должно
планировать
заранее - назовем
их регламентными
работами
2) обработка
различных
сбойных ситуаций,
которые планировать
невозможно,
но можно все-таки
быть к ним готовым.
Регламентные
работы (Планировщик)
В Microsoft SQL Server 6.0 есть
все возможности
довести выполнение
регламентных
работ до такой
степени автоматизации,
что администратор
может на них
практически
не тратить
время - все будет
выполнять
специальный
сервис, который
называется
Планировщик
(Scheduling Engine). Вы можете
давать ему
задания, которые
будут выполняться
по расписанию,
периодически
или однократно
в назначенное
время и о выполнении
которых вы
можете узнавать,
просматривая
историю заданий
или получая
от Планировщика
сообщения по
электронной
почте.
Планировщик
используется,
в частности,
для поддержки
тиражирования
данных. Он может
выполнять
несколько типов
заданий, из
которых нас
интересуют
два - выполнение
последовательности
команд на языке
Transact-SQL и выполнение
команд операционной
системы Windows NT Server.
Мы рассмотрим
использование
планировщика
на примере
типичных и
наиболее частых
задач - резервного
копирования
и обновления
статистики.
Резервное
копирование
Базы данных
необходимо
периодически
копировать
- это объяснять
не нужно. Копировать
нужно как
пользовательские
базы данных,
так и системные
- в SQL Server 6.0 к ним относятся,
помимо базы
"master", еще и появившиеся
в SQL Server 6.0, "msdb" и, для
серверов-распространителей
в процессе
тиражирования,
- "distribution".
Базу данных
"master" следует
копировать
после таких
действий, как
создание новой
базы данных,
нового устройства
или сегмента,
заведения
нового пользователя.
Вполне разумно
выполнять ее
резервное
копирование
периодически
(например,
ежедневно),
также как и
копирование
пользовательских
баз данных или
их журналов
транзакций.
Поэтому имеет
смысл поручить
это занятие
Планировщику.
Работа с Планировщиком
осуществляется
при помощи
средства SQL
Enterprise Manager. Планирование
резервного
копирования
можно задать
и не в обычном
интерфейсе
Планировщика,
а в специальной
форме, для этого
предназначенной.
В SQL Server 4.21 тоже можно
было сконфигурировать
автоматическое
резервное
копирование,
но это было
единственное
автоматическое
действие.
Обновление
статистики
Обновление
индексной
статистики,
как мы уже говорили,
может существенно
повлиять на
производительность
сервера. Поэтому
его тоже имеет
смысл делать
регулярно и
поручить
Планировщику.
Что мы сейчас
и сделаем. Создадим
задание типа
'TSQL' (выполнение
предложения
языка Transact-SQL), выполняющее
в базе данных
'pubs' вызов хранимой
процедуры
'update_all_stats', которая
обновляет
статистику
по всем таблицам.
Пусть статистика
обновляется
еженедельно,
по воскресеньям
в 3:00. Сообщения
о неудачном
завершении
задания будут
записываться
в системный
журнал, а также
отправляться
по электронной
почте оператору.
Предвидение
сбойных ситуаций
Сбойные
ситуации всегда
неприятны, но
если вы заботитесь
о сохранности
ваших данных
и работоспособности
ваших приложений,
то вы будете
выходить из
неприятных
положений
спокойно. Заранее
оцените возможные
сбойные ситуации,
ваш вероятный
ущерб при этом
и, исходя из
этих оценок,
разработайте
стратегию
резервирования
данных и оборудования,
составьте план
действий по
восстановлению
работоспособности
системы в случае
наступления
сбойной ситуации.
Основным критерием
оценки вашей
защищенности
от сбоев может
служить время
восстановления
работоспособности
системы после
наступления
сбойной ситуации.
Так, например,
если вы используете
SQL Server в приложении,
"жизненно
важном" для
деятельности
вашей фирмы,
то вам, скорее
всего, необходимо
будет делать
резервное
копирование
баз данных
минимум раз
в день. Копировать
данные можно
на стриммер
или на жесткий
диск. Кроме
того, следует,
очевидно, иметь
резервный
компьютер с
установленным
на нем SQL Server и конфигурацией
баз данных,
полностью
соответствующей
основному
серверу. Тогда
в случае выхода
из строя основного
сервера можно
будет с минимальными
потерями времени
перевести
систему на
обслуживание
резервным
сервером. Можно
делать резервное
копирование
баз данных
основного
сервера на
жесткий диск
резервного
сервера. Для
этого нужно,
чтобы сервис
SQL Server регистрировался
в Windows NT под именем
пользователя,
который имеет
права на запись
на этот диск.
Менеджер
событий
Еще один
компонент
системы управления
SQL Server - менеджер
событий (Alert Manager),
позволяет
запланировать
реакцию сервера
на все возможные
сбойные ситуации.
События фиксируются
в системном
журнале, менеджер
событий постоянно
читает этот
журнал и, при
обнаружении
заданного кода
сообщения,
выполняет
запланированное
администратором
действие. Это
действие оформляется
в виде задания
планировщику,
аналогичного
рассмотренному
заданию на
обновление
статистики,
только выполняется
оно не по расписанию,
а "по требованию".
Конфигурируя
реакцию на
события, администратор
указывает,
какое задание
выполнить в
случае наступления
этого события.
Например, при
переполнении
журнала транзакций
можно вызвать
задание, которое
осуществит
резервное
копирование
журнала и тем
самым очистит
его.
Событие можно
настроить на
конкретное
сообщение об
ошибке, а можно
на группу ошибок,
относящихся
к одному т.н.
"уровню серьезности".
Реакция на
событие также
предусматривает
уведомление
указанного
списка операторов
средствами
электронной
почты или
пэйджинговой
связи. Для того,
чтобы SQL Server мог
отправлять
и принимать
почту, работая
с Microsoft Exchange, необходимо
при конфигурировании
SQL Mail указать в
качестве имени
пользователя
имя профиля
("profile"), а в качестве
пароля - сетевой
пароль владельца
профиля. При
этом необходимо,
чтобы SQL Server регистрировался
в Windows NT не под именем
"Local System", а под именем
владельца
вышеупомянутого
профиля.
Анализ сбойной
ситуации
Что делать,
если сервер
или клиентское
приложение
выдает сообщение
об ошибке? Прежде
всего, необходимо
собрать максимум
точной информации
- номер сообщения,
поясняющий
текст, какое
действие
производилось
в момент, когда
произошла
ошибка. Просмотрите
журнал ошибок
SQL Server и системный
журнал Windows NT Server. Затем
нужно выяснить,
какой компонент
вашего клиент-серверного
приложения
вызывает эту
ошибку. Компоненты
нужно рассмотреть
следующие:
• Клиентское
приложение;
• Сеть;
• SQL Server
Если вы выяснили,
какой запрос
привел к сбойной
ситуации, то
изолировать
клиентское
приложение
можно, послав
этот же запрос
к SQL Server через интерактивную
утилиту ISQL/W. Если
ошибка повторяется,
значит клиентское
приложение
ни при чем. Послав
этот же запрос,
но не с рабочей
станции, а
непосредственно
с компьютера,
на котором
работает SQL Server,
можно выяснить,
виновата ли
сеть.
Анализ проблем
с блокировками
Если вы
предполагаете,
что есть проблемы
с блокировками,
то удобно выяснить,
так ли это, используя
SQL Enterprise Manager и, конкретно,
режим просмотра
текущей активности
("current activity"). В этом
режиме наглядно
представлена
информация
о том, какой
процесс блокирует
другие процессы
и из-за блокирования
каких таблиц
происходит
конфликт. Вы
имеете возможность
перестроить
запросы так,
чтобы они не
приводили к
конфликтам
и, в крайнем
случае, "убить"
нежелательный
процесс.
СОДЕРЖАНИЕ:
Введение 2
Архитектура
MS SQL Server 6.5 4
Производительность 5
Распределенная
среда управления 6
SQL-DMO (Distributed
Management Objects) 9
Интеграция
с электронной
почтой 10
Характеристики
языка Transact-SQL 11
MS Distributed
Transaction Coordinator (DTC) и распределенные
транзакции 13
Блокировки 16
Надежность
хранения
информации 19
Тиражирование 22
Вопросы
безопасности
доступа 25
Некоторые
вопросы использования
MS SQL Server в Internet/intranet-приложениях 26
Заключение 29
Список
литературы: 30
Введение
Коль скоро
этот обзор
посвящен серверу
баз данных,
невозможно
не упомянуть
о том, что создание
машин для хранения
и управления
данными является,
пожалуй, одним
из самых значимых
достижений
человечества
со времени
изобретения
письменности.
Как известно,
в начале было
слово. Слово,
ознаменовавшее
переход от
рефлексии в
восприятии
окружающего
мира к абстрактному
мышлению. Возможно,
именно этот
переворот в
сознании нарушил
первозданную
гармонию и
противопоставил
человека природе.
Как бы то ни
было, при всей
ограниченности
и имманентной
неполноте
вербального
общения именно
слово служит
основным способом
передачи информации
по сравнению,
например, с
музыкой, танцем,
живописью,
архитектурой
и т. д. В рамках
той парадигмы,
в которой сегодня
работает наш
мозг, представляется
иррациональной
возможность
просветления,
озарения, т. е.
мгновенного
получения
необходимых
знаний. Остается
процесс постепенного
познания
действительности,
и для этого
человек вынужден
был научиться
сохранять
информацию,
полученную
на предыдущих
этапах. Ключевым
моментом стало
возникновение
знакового
письма, которое,
несмотря на
большие или
меньшие потери,
смогло обеспечить
должное хранение
формализованных
знаний. Как
утверждают
антропологи,
за последние
несколько
десятков тысяч
лет физиологические
параметры 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.
| Название | Краткое описание |
| Исполняемый файл |
| Мощный централизованный инструмент полного управления серверами в масштабах предприятия, включая базы данных, их объекты, предупреждения (alerts), спланированные во времени задачи, тиражирование и запросы. | Графический |
|
|
| Командная строка | sqlexec.exe |
|
|
| sqlmaint.exe |
| SQL Service Manager Sqlservr |
спользуется для запуска, останова, приостановки и возобновления деятельности сервера и агента SQL Executive. Сам MS SQL Server может быть запущен из командной строки, аргументы которой определяют его текущую настройку. |
|
|
| Средство построения запросов, анализа плана выполнения, просмотра статистической информации и одновременного управления многими запросами в различных окнах. |
|
|
| Средство интерактивного ввода операторов Transact-SQL, вызова системных процедур, запуска скриптов. |
| isql.exe |
SQL | Управление интегрированным режимом безопасности. |
|
|
| Средство мониторинга пользовательской активности. Позволяет отлавливать операторы Transact-SQL, вызовы процедур, инициируемые каждым клиентом, в реальном времени или записывать в журнал. Обладает возм-стями фильтрации. |
|
|
| Использует для мониторинга событий и сбора статистики по MS SQL Server стандартный perfmon.ехе Windows NT на основе предоставляемого им списка объектов и счетчиков. | Графический | sqlalrtr.exe |
| Интеграция механизма предупреждений с соответствующими службами Windows NT Performance Monitor. |
| |
SQL | Управление переносом данных и объектов с различных платформ SQL Server. | Графический | sqlxfr.exe |
BCP | Перенос данных между MS SQL Server и файлами операционной системы (например, текстовыми). | Командная строка | bcp.exe |
SQL | Применяется для начальной установки, удаления, upgrade, инсталляции дополнительных компонентов и изменения настроек в конфигурации: поддержки сетевых протоколов, изменения языка, выбора кодовой страницы и порядка сортировки, модели безопасности, а также для перестройки базы данных master. | Графический | setup.exe |
Language | Установка поддержки дополнительной языковой информации (например, локализованных сообщений). Используется в setup.exe. | Командная строка | langinst.exe |
Sort | Установка кодовой страницы символов, чувствительности к регистру и отношения порядка над символами. Используется в setup.exe. | Командная строка | charset.exe |
Check | Используется MS SQL Server во время upgrade для проверки совместимости существующих пользовательских баз. | Командная строка | сhkupg65.exe |
| SQL Client Configuration Utility | Настройка клиента DB-Library, различных сетевых библиотек и/или пользовательских поименованных каналов. | Графический | windbver.exe |
Makepipe, | Пытаются открыть и использовать поименованный канал между сервером и клиентом. | Командная строка | makepipe.exereadpipe.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-файл для
устранения
ошибки, а также
зафиксировать
появление этого
события в системном
журнале. В целом
можно сказать,
что распределенная
среда управления
позволяет
существенно
упростить жизнь
администратора
базы данных.
(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) тип ссылочной
целостности.
| Тип целостности | Пояснения | Механизмы контроля |
| Определяет запись как уникальную для таблицы сущность |
|
| Определяет область допустимых значений для поля |
|
| Поддержка ссылочной целостности связей |
|
| Все прочие бизнес-правила на уровне столбца и таблицы |
Stored |
Таблица 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 представляет
собой достаточно
удобный способ
работы с распределенными
данными без
необходимости
внесения изменений
в клиентскую
часть приложения.
Distributed Transaction Coordinator (DTC) и распределенные
транзакции
Создание
распределенных
приложений
приводит к
тому, что транзакции
также приобретают
распределенный
характер.
Структуризация
приложения
в виде многих
самостоятельных
компонентов
способна существенно
повысить
масштабируемость
и повторную
используемость,
а также упростить
его разработку.
Однако при этом
необходимо
иметь в виду,
что сбой в работе
одного из компонентов
(например, в
результате
выхода из строя
компьютера,
на котором она
была запущена)
не должен сказываться
на целостности
функционирования
всего приложения
в целом, т. е.
компонент может
временно выключиться
из согласованной
работы приложения,
но связанные
с ней сообщения
должны быть
обработаны
корректно.
Участниками
распределенной
транзакции
являются приложение,
менеджеры
транзакций,
менеджеры
ресурсов и сами
ресурсы, затрагиваемые
транзакцией.
В этой цепочке
MS DTC выполняет
роль менеджера
транзакций.
Тот DTC, к первому
из которых
обратилось
приложение,
инициировавшее
транзакцию,
называется
первичным1
менеджером
транзакций.
Пусть
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) не допускает
аналогичные
блокировки
на протяжении
периода своего
действия по
отношению к
блокированным
им данным.
| Тип блокировки |
|
|
|
| OK | OK | X |
| OK | X | X |
| X | X | X |
Таблица 3.
Уровень
блокировки
может распространяться
на:
• запись (для
операций insert);
• cтраницу
- 2-килобайтный
фрагмент данных
или индексов;
• расширение
(extent) - 8 последовательных
страниц, используется
при размещении
или высвобождении
страниц (например,
в командах
create/drop или когда
операция вставки
insert требует выделения
новых страниц
памяти);
• таблицу,
включая все
входящие в нее
данные и индексы2.
В следующей
версии блокировка
уровня записи
будет возможна
для всех типов
транзакций.
Блокировка
уровня записи
на операции
вставки позволяет
в первую очередь
решить задачу
уменьшения
вероятности
конкуренции
в 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, т. е. просто
запрещает
различным
транзакциям
изменять одни
и те же данные
в одно и то же
время, но допускает
грязное и
неповторяющееся
чтение и фантомы3;
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 =
'ntalexeyshdisk_dsql_experimentspubs.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 =
"http://www.microsoft.com", @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.
Например, публикация
результата
запроса может
быть выполнена,
как:
Курсы
валют
Курсы
валют
Код
Курс
Интерфейс
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".
1
В разных
источниках
он может также
называться
глобальным
(global) или корневым
(root).
2
Иногда выделяют
еще блокировку
intent. Однако intent не
является блокировкой
в строгом смысле
слова, это метка
в цепочке табличных
блокировок,
предупреждающая
другие транзакции
о том, что текущий
процесс намерен
произвести
эскалацию
масштаба
блокирования
до уровня таблицы.
3
Напомним, что
под грязным
чтением (dirty read)
понимается
ситуация, когда
транзакция
Т1 модифицирует
запись, транзакция
Т2 ее читает,
Т1 тем временем
откатывает
изменения и
Т2 работает с
записью, которая
реально никогда
не существовала.
Неповторяющееся
чтение (unrepeatable read)
возникает в
случае, если
Т1 читает запись,
Т2 ее изменяет
и Т1 снова прочитывает
ту же запись.
Т1, дважды прочитав
одну и ту же
запись, фактически
видела два
разных значения.
Фантомы: Т1 читает
записи, удовлетворяющие
определенному
условию, после
этого Т2 добавляет
или удаляет
записи. Если
Т1 опять произведет
выборку по
тому же условию,
она может получить
множество
записей, не
совпадающее
с предыдущим.