Индивидуальные задания к лабораторным работам по курсу «Введение в СУБД HyTech»

1) Разработать ПО, реализующую протокол двухфазной фиксации для распределенной транзакции для БД HyTech. Распределенная транзакция должна работать на 3-ех узлах.
Описание.
В системе есть 1 узел-координатор и 2 подчиненных узла (лучше, что бы это было не 2 узла, а N, параметры узлов тогда нужно хранить в отдельной таблице в БД узла - координатора). Каждый узел имеет собственную БД. Из узла координатора подчиненные узлы должны быть доступны через DB-LINK. На узел координатор от клиента поступает текст нескольких запросов на удаление, модификацию или изменение данных. Этот текст воспринимается как единая распределенная транзакция. Текст запросов разбивается на N блоков кода (способ разметки на блоки – на собственное усмотрение). Для каждого блока указывается, для какого узла он должен быть применен. Требуется реализовать протокол двухфазной фиксации, который состоит в следующем:
- начать транзакцию на каждом узле;
- выполнить блоки кода на узлах (на каждом узле - свой);
- если все блоки завершились успешно - завершить транзакции на каждом узле (commit work);
- если хотя бы один блок завершился неудачей - выполнить откат транзакции на всех узлах (rollback work).
Также необходимо генерировать ошибку для клиента.
Должны быть реализованы клиентское приложение, позволяющее ввести запросы для распределенной транзакции и сервер узла-координатора.

2) Реализовать утилиту мониторинга производительности.
Описание.
Утилита мониторинга производительности должна быть реализована в виде двух компонент (сервиса Windows для сбора индикаторов производительности) и приложения для просмотра значений индикаторов. Сервис сбора индикаторов должен анализировать лог работы серверов HyTech (возможно, следует также воспользоваться встроенными функциями - Будет ясно после консультаций с разработчиками) и собирать индикаторы производительности. Интересны следующие индикаторы:
- общее число синтаксически одинаковых запросов за период времени;
- для каждого синтаксически одинакового запроса: среднее время выполнения, максимальное и минимальное время выполнения;
- список запросов по убыванию среднего времени выполнения;
- средняя, минимальная и максимальная загрузка процессора при работе сервера;
- запросы, выполняемые при максимальной загрузке;
- среднее количество пользователей;
- распределение нагрузки сервера по пользователям и по запросам;
- скорость роста таблиц (список таблиц упорядочен по скорости роста);
- список блокировок;
.... Список следует продолжить.
Кроме того, сервис сбора индикаторов должен контролировать пороговые значения для индикаторов и в случае превышения (или меньшего заданного порогового значения) индикатора посылать e-mail администратору с сообщением о проблемах производительности.
Приложение для просмотра значений индикаторов должно иметь графический интерфейс и возможности:
- указать параметры индикаторов, измеряемых для конкретного сервера, задавать для них минимальные и максимальные допустимые значения;
- отображать текущие значения индикаторов;
- задавать адрес e-mail для администратора, для информирования администратора о выходе за пределы допустимых значений индикаторов.

3) Реализовать компонент для работы с HyTech в среде .Net.
Описание.
СУБД HyTech имеет программный интерфейс на языке C. На основе этого интерфейса нужно реализовать компонент по работе с СУБД HyTech в среде .Net. Интерфейс компонента должен быть похож на интерфейс уже существующих компонентов доступа к данным в среде .Net, например, для MS SQL Server или Oracle.

4) Реализовать хранимую процедуру HyTech по сбору данных в распределенной БД из 3-ех узлов.
Описание.
В системе есть 1 главный узел и 2 подчиненных узла (лучше, что бы это было не 2 узла, а N, параметры узлов тогда нужно хранить отдельной таблице в БД главного узла). Каждый узел имеет собственную БД. Запрос на выборку данных поступает в хранимую процедуру главного узла. Главный узел выполняет одинаковый запрос к подчиненным узлам и собирает все полученные данные в временную таблицу. Строки временной таблицы возвращаются на клиент в качестве результата. Должна быть реализована корректная обработка ошибок с точки зрения работы с распределенной БД, т.е. возможности получить в клиенте информацию о недоступности БД или возникновении ошибок при выполнении запроса.

5) Реализовать хранимую процедуру HyTech по агрегации данных в распределенной БД из 3-ех узлов.
Описание.
Развитие задания 4), с небольшими усложнениями.
В системе есть 1 главный узел и 2 подчиненных узла (лучше, что бы это было не 2 узла, а N, параметры узлов тогда нужно хранить отдельной таблице в БД главного узла). Каждый узел имеет собственную БД. Запрос на выборку данных поступает в хранимую процедуру главного узла. Главный узел выполняет одинаковый запрос к подчиненным узлам и собирает все полученные данные в временную таблицу. Запрос содержит инструкции по агрегации данных (функции SUM, COUNT, MIN и т.п., возможно, используются переменные с накоплением данных). Далее выполняется запрос по агрегации данных из исходного запроса, но уже на временной таблице. Результат возвращается клиенту. Должна быть реализована корректная обработка ошибок с точки зрения работы с распределенной БД, т.е. возможности получить в клиенте информацию о недоступности БД или возникновении ошибок при выполнении запроса.

6) Реализовать средства для выполнения архивирования в оперативном режиме по расписанию.
Описание.
В среде Windows требуется реализовать следующие приложения: сервис по архивированию данных по расписанию (в виде службы Windows) и приложение (с графическим пользовательским интерфейсом) по настройке параметров сервиса архивирования данных.
Должны настраиваться следующие параметры:
- каталог (каталоги) для архивирования данных по умолчанию;
- адрес электронной почты, для отправки сообщения администратору в случае возникновения ошибки;
- перечень источников данных (задается строкой соединения) для которых выполняется архивирование;
- для каждого источника данных задается перечень таблиц, подлежащих архивированию;
- для каждой таблицы задается:
- разовое архивирование или периодическое;
  - для разового архивирования задается дата и время, когда архивирование должно быть выполнено;
  - для периодического архивирования задается период архивирования:  раз в час, раз в N часов, раз в сутки, раз в неделю, раз в месяц  (здесь собственный удобный способ задания периодов архивирования только приветствуется);
  - каталог, куда помещается архив (может быть задан каталог по умолчанию, куда должны помещаться таблицы).
Должны быть возможности корректировки (изменения, удаления) всех вышеперечисленных данных.
По наступлению времени архивирования, само архивирование должно выполняться при помощи встроенных функций СУБД HyTech и/или утилит, входящих в состав дистрибутива. Результаты архивирования (включая ошибки) должны протоколироваться в отдельном журнале. В случае возникновения ошибки по указанному адресу электронной почты должно передаваться сообщения с описанием ошибок, возникших при архивации. Журнал должен быть доступен для чтения из приложения настройки параметров сервиса архивирования.

7) Реализовать утилиту с графическим интерфейсом для выполнения архивирования в автономном режиме по расписанию.
Описание.
Задание похоже на 6) за исключение того, что архивирование должно выполняться не в оперативном режиме, а в автономном.
В среде Windows требуется реализовать следующие приложения: сервис по архивированию данных по расписанию (в виде службы Windows) и приложение (с графическим пользовательским интерфейсом) по настройке параметров сервиса архивирования данных.
Должны настраиваться следующие параметры:
- каталог (каталоги) для архивирования данных по умолчанию;
- адрес электронной почты, для отправки сообщения администратору в случае возникновения ошибки;
- перечень источников данных (задается строкой соединения) для которых выполняется архивирование;
- для каждого источника данных задается перечень таблиц, подлежащих архивированию, либо указывается, что архивирование выполняется целиком;
- для каждой таблицы задается:
  - разовое архивирование или периодическое;
  - для разового архивирования задается дата и время, когда архивирование должно быть выполнено;
  - для периодического архивирования задается период архивирования:  раз в час, раз в N часов, раз в сутки, раз в неделю, раз в месяц  (здесь собственный удобный способ задания периодов архивирования только приветствуется);
  - каталог, куда помещается архив (может быть задан каталог по умолчанию, куда должны помещаться таблицы).
Должны быть возможности корректировки (изменения, удаления) всех вышеперечисленных данных.
По наступлению времени архивирования, само архивирование должно выполняться при помощи встроенных функций СУБД HyTech и/или утилит, входящих в состав дистрибутива.
Результаты архивирования (включая ошибки) должны протоколироваться в отдельном журнале. в случае возникновения ошибки по указанному адресу электронной почты должно передаваться сообщения с описанием ошибок, возникших при архивации. Журнал должен быть доступен для чтения из приложения настройки параметров сервиса архивирования.

8) Реализовать утилиту с графическим интерфейсом для упаковки (добавления переменной таблицы части в постоянную) по расписанию или событийно, при достижении журнальным файлом заданного размера.
Описание.
В среде Windows требуется реализовать следующие приложения: сервис по упаковке данных по расписанию (в виде службы Windows) и приложение (с графическим пользовательским интерфейсом) по настройке параметров сервиса упаковки данных.
Должны настраиваться следующие параметры:
- адрес электронной почты, для отправки сообщения администратору в случае возникновения ошибки при упаковке данных;
- перечень источников данных (задается строкой соединения) для которых выполняется упаковка;
- для каждого источника данных задается перечень таблиц, подлежащих упаковке;
- для каждой таблицы задается:
  - разовая упаковка или периодическая;
  - для разовой упаковки задается дата и время, когда упаковка должна   быть выполнена (в том числе, должен быть предусмотрен режим выполнения упаковки "немедленно");
  - для периодической упаковки задается период упаковки: раз в час, раз в N часов, раз в сутки, раз в неделю, раз в месяц (здесь собственный удобный способ задания периодов упаковки  только приветствуется) и/или размер максимальный размер  дифференциального файла, при котором выполняется упаковка. Кроме того,  могут быть заданы периоды, когда упаковка не должна выполняться при  превышении максимального размера (например, в течение рабочего дня).
Должны быть возможности корректировки (изменения, удаления) всех вышеперечисленных данных.
По наступлению времени упаковки, сама упаковка должна выполняться при помощи встроенных функций СУБД HyTech и/или утилит, входящих в состав дистрибутива. Результаты упаковки (включая ошибки) должны протоколироваться в отдельном журнале. В случае возникновения ошибки по указанному адресу электронной почты должно передаваться сообщения с описанием ошибок, возникших при упаковке. Журнал должен быть доступен для чтения из приложения настройки параметров сервиса упаковки.

9) Реализовать прокси-сервер доступа, позволяющий работать с БД HyTech без дополнительной аутентификации на уровне СУБД, только с использованием информации о пользователе из Active Directory. Фактически, предлагается реализовать политику доступа к СУБД HyTech по технологии SSO в среде Windows.
Описание.
В среде Windows требуется реализовать прокси-сервер (возможно, набор приложений), который должен выполнять следующие функции:
- "прозрачно" транслировать запросы от клиента к СУБД HyTech;
- при помощи специальной утилиты настройки позволять сопоставить пользователя ActiveDirectory и пользователя СУБД HyTech;
- при изменении пароля пользователя в ActiveDirectory синхронизовать изменения в словаре данных СУБД HyTech (удобно это делать, например, при входе пользователя в систему);
- при доступе из клиента HyTech поддерживать клиентские сессии, обнаруживать первый запрос клиента в сессии выполнять аутентификацию пользователя на основе информации из ActiveDirectory, без запроса имени пользователя и пароля, в случае невозможности сопоставить имя пользователя или неправильном пароле предлагать ввести имя пользователя и пароль (возвращать соотв. сообщение об ошибке);
- на основе периодического контроля списка пользователей, удалять из БД HyTech пользователей, которые ранее были сопоставлены с информацией из ActiveDirectory, а потом из ActiveDirectory были удалены.

10) Реализовать прокси-сервер доступа, контролирующий сложность пароля при соединении с СУБД HyTech. 
Описание.
В среде Windows требуется реализовать прокси-сервер (возможно, набор приложений), который должен выполнять следующие функции:
- "прозрачно" транслировать запросы от клиента к СУБД HyTech;
- при помощи специальной утилиты настройки позволять указать критерии сложности пароля (длина, регистры символов, чередование букв разных алфавитов и т.п.);
- распознавать попытки входа в систему и анализировать сложность пароля в соответствие с заданными критериями. В случае ошибок - отказывать в соединении с БД.

По 1-2 человека на вариант, с вариантами надо определиться до следующего четверга и сказать мне номера, кто этого не сделает будет распределен принудительно:) Удачи)))

Климов просил передать что завтра после лекции буэля будет еще и его лекция. Подробностей не знаю, он просил всех явиться

По Иванову к следующему четвергу (12.10.2009) необходимопринести реферат. Темы рефератов:

1. Объектно-реляционный маппинг и программные средства, которые его реализуют.
2. Кибернетика как пример ОРМ.
3. Entity Framework как пример ОРМ.
4. Персистанс, реализованный в framework Ipatis.

Объем реферата  5 страниц без учета титульного листа. Вконце должен быть список литературы.
Защита будет проходить следующим образом: он по рефератузадаст вопрос, на которых необходимо будет ответить.