Система управления базами данных

Именно в этом сечении - между репликационными серверами - связь может быть медленной или  недостаточно надежной. Передаваемые данные в составе транзакции при  недоступности узла-получателя записываются в стабильные очереди на диске  и затем передаются по мере возможности. Данные могут передаваться в удаленный  узел по маршруту, содержащему несколько  репликационных серверов. В частности, такая возможность лежит в  основе построения иерархических систем репликации.

В одной базе данных могут  содержаться как первичные данные, так и данные-копии. Приложение-клиент, работающее со своей СУБД, может  вносить изменения напрямую (операторами INSERT, DELETE, UPDATE) только в первичные данные. Для изменения копии данных предназначен механизм асинхронного вызова процедур. Для работы этого механизма в нескольких базах данных создаются процедуры с одинаковым именем и параметрами, но, возможно, с различным текстом. В одной базе данных процедура помечается как предназначенная к репликации. Вызов этой процедуры вместе со значениями параметров через журнал и механизм репликации передается к узлам-подписчикам, и в их базах данных вызывается одноименная процедура с теми же значениями параметров.

СУБД, хранящая вторичные  данные, может быть любой из ряда доступных через шлюз: будь то Oracle, Informix, DB2, RMS, ISAM и т.п.. СУБД, хранящая первичные данные, требует наличия менеджера журнала транзакций (Log Transfer Manager - LTM). Сейчас разработаны LTM для Sybase SQL Server и Oracle; на очереди другие СУБД. Интерфейс LTM является открытым, и в скором времени, возможно, подобные модули будут созданы для нестандартных источников данных.

Вообще, тиражирование данных может найти самое разнообразное  применение:

- для разгрузки сервера,  выполняющего активное обновление  данных (OLTP) от сложных запросов, связанных с поддержкой принятия  решений (decision-support);

- для консолидации данных  от подразделений в центре;

- для обмена данными  по медленным или ненадежным  линиям связи; 

- для поддержания резервной  базы данных;

-для построения сети  равноправных узлов, обменивающихся  данными. 

Следует подчеркнуть, что  репликационный сервер тиражирует транзакции, а не отдельные изменения в  базе данных. Метод тиражирования  транзакций гарантирует целостность  внутри транзакции и, как следствие, невозможность нарушения ссылочной  целостности. Схема обновления первичных  данных и копий данных исключает  возможность возникновения конфликтов; последние могут быть вызваны  только неправильным проектированием  системы или сбоем.

Большинство производителей современных промышленных СУБД в  той или иной мере обеспечивают поддержку  распределенной обработки транзакций. Распределенная обработка данных основывается на синхронных или асинхронных механизмах обработки распределенных транзакций. Эти механизмы могут использоваться и совместно. Поскольку каждый механизм обладает своими сильными и слабыми  сторонами, выбор его зависит  от требований конкретной подзадачи.

Исторически первым появился метод синхронного внесения изменений  в несколько БД, называемый двухфазной фиксацией (2РС, two- phase commit). Этот механизм реализован сейчас практически всеми производителями СУБД. Суть метода двухфазной фиксации состоит в том, что при завершении транзакции серверы БД, участвующие в ней, получают команду «приготовиться к фиксации транзакции». После получения подтверждений от всех серверов транзакция фиксируется на кадом из них. Таким образом, в любой момент времени обеспечивается целостность данных в распределенной системе. Платой за это являются требование доступности всех участвующих серверов и линий связи во время проведения транзакции, а также невозможность работы приложений-клиентов при недоступности, например, удаленного сервера. Кроме того, необходимо высокое быстродействие линий связи для обеспечения приемлемого времени реакции у приложения-клиента.

В распределенной системе  идеальным являлось бы состояние, когда  каждая программа-клиент обращается только к тем серверам, которые находятся  в пределах ее локальной сети, а  передача данных и обеспечение целостности  осуществляются системными средствами и не требуют специальных действий со стороны прикладной программы. Такое  распределение функций возможно и на практике реализуется с помощью  механизма асинхронного тиражирования  транзакций.

Синхронное проведение изменений  в участвующих в распределенной транзакции базах данных не всегда является необходимым требованием. Рассмотрим, например, случай ввода  данных с измерительного оборудований в цехе и последующего анализа  этой информации на уровне управления. Здесь очень важно обеспечить достаточно малый (но, возможно, ненулевой) интервал времени между изменениями  в исходных данных и в их копии  на другом узле системы, где происходит построение отчетов.

Механизм асинхронного тиражирования  транзакций (репликации) гарантирует  доставку измененных данных на вторичные  серверы непосредственно после  завершения транзакции, если сервер доступен, или же тотчас после подключения  сервера к сети. Такой способ предполагает хранение дублирующей информации в  различных узлах сети и по сравнению  с другими подходами к репликации существенно разгружает трафик сети, минимизирует время отклика системы, а также позволяет оптимизировать нагрузку на серверы.

В зависимости от условий, специфицированных разработчиком, репликация может производиться  либо сразу после наступления  некоторого события (скажем, модификации  строки таблицы), либо через заранее  заданные интервалы времени (каждую минуту, каждый час и т.д.), либо в  определенный момент времени (например, ночью, когда загрузка и стоимость  линий связи минимальная). Если узел, в который выполняется репликация, в данный момент недоступен, информация об этом сохраняется в вызывающем узле, и репликация осуществляется после восстановления связи. Более  того, гарантируется сохранение заданного  вызывающим узлом порядка ее выполнения.

Основные преимущества такого решения - повышение надежности системы (за счет контролируемого дублированмя данных) и увеличение ее производительности из-за существенного снижения сетевого трафика. Причем для уменьшения объема передаваемых данных обычно реплицируется не полный образ таблицы (или ее подмножества), а только информация об изменениях, происшедших с момента последней репликации.

Надо отметить, что асинхронная  репликация не делает линии связи  более надежными или скоростными. Она лишь перекладывает задачи трансляции данных и обеспечения их целостности  «с плеч» прикладной программы и  пользователя на системный уровень.

Асинхронная репликация, в  отличие от 2РС, не гарантирует полной синхронности информации на всех серверах в любой момент времени. Синхронизация  происходит через некоторый, обычно небольшой интервал времени, величина которого определяется быстродействием  соответствующего канала связи. Для  большинства задач кратковременное  наличие устаревших данных в удаленных  узлах не критично и вполне допустимо.

Вместе с тем асинхронная  репликация транзакций принципиально  обеспечивает целостность информации, так как объектом обмена данными  здесь является логическая единица  работы - транзакция, а не просто данные из измененных таблиц.

Все современные серверы  БД используют блокировки, чтобы обеспечить параллелизм в многопользовательской  среде. Речь может идти о блокировках  на уровне страниц, строк или таблиц, причем характер используемой блокировки чаще всего определяется в момент описания таблиц. Действительно, пользователи и разработчики корпоративных информационных систем все больше внимания уделяют  эффективности базовой СУБД. В  частности, речь идет о способах реализации систем блокировки, которые в значительной степени влияют на качество исполнения проектов. Система блокировок синхронизирует доступ пользователей к базе данных, а в идеале гарантирует непротиворечивость данных и истинность результатов  выполнения запросов. В то время  как один пользователь блокирует  область базы данных, например, для  просмотра и·возможной модификации  данных, последние должны быть защищены от воздействия со стороны других пользователей, возможно пытающихся вносить  изменения в той же области  данных.

Задача масштабирования  рано или поздно встает в любой  организации, и это вполне объяснимо. Никто и никогда не покупает аппаратуру про запас, с большими резервами  по вычислительной мощности. В то же время объемы хранимых данных и количество реально работающих приложений имеют  тенденцию к неуклонному увеличению. Поэтому лучше всего изначально остановить свой выбор на такой аппаратной конфигурации, которая в дальнейшем будет легко наращиваться и развиваться.

В настоящее время этому  требованию в наибольшей степени  отвечают компьютеры с симметричной многопроцессорной (SMP) или массивно-параллельной (МРР) архитектурой, на которых при  увеличении количества процессоров  обеспечивается практически линейный рост производительности. Обработка  нескольких запросов, вложенных циклов внутри одного запроса, загрузка и сортировка данных, создание индексов и т.д. - все  это выполняется параллельно  на различных процессорах. Более  того, одновременно реализуется эффективная  динамическая балансировка загрузки системных  ресурсов (процессоров, оперативной  и дисковой памяти).

Виртуальным-процессором (ВП) называется процесс сервера баз данных. ВП можно сравнить с операционной системой - поток по отношению к нему выступает как процесс, подобно тому как сам ВП является процессом с точки зрения операционной системы.

В отличие от операционной системы, которая должна обеспечивать выполнение произвольных процессов, ВП подразделяются на несколько классов, каждый из которых спроектирован  для наиболее оптимального выполнения задач определенного вида. Например, ВП CPU работают на потоки обслуживания клиентов, реализующие оптимизацию  и логику выполнения запросов; ВП АIO выполняют операции асинхронного обмена с диском; ВП TLI контролируют сетевое взаимодействие.

Сервер поддерживает очереди  потоков для каждого класса ВП. Как только ВП освобождается, он выбирает из очереди следующий поток, тем  самым достигается равномерная  загрузка. Переключение же ВП с одного потока на другой выполняется значительно  быстрее, чем переключение ОС с одного процесса на другой. Кроме того, многопотоковая архитектура способствует более рациональному использованию ресурсов ОС, поскольку потоки разделяют ресурсы ВП, на котором они выполняются, - память, коммуникационные порты, файлы.

Начальное число ВП каждого  класса задается в конфигурационном файле. Но если потребности в каких-то видах увеличиваются, то инструменты  администрирования позволяют динамически, не останавливая сервер, запустить  дополнительные ВП. Например, если растет очередь потоков к ВП CPU, то можно  увеличить их число. Точно так  же возможно добавление виртуальных  процессоров обмена с дисками, сетевых  процессоров.

Разделение данных между  виртуальными процессорами и потоками сервера реализовано на основе разделяемой  памяти - механизма, обеспечиваемого  операционной системой. Разделение данных позволяет:

- снизить общее потребление  памяти, поскольку участвующим в  разделении процессам, то есть  виртуальным процессорам, нет  нужды поддерживать свои копии  информации, находящейся в разделяемой  памяти;

- сократить число обменов  с дисками, потому что буферы  ввода-вывода сбрасываются на  диск не для каждого процесса  в отдельности, а образуют один  общий для всего сервера баз  данных пул; виртуальный процессор  зачастую избегает выполнения  операций ввода с диска, поскольку  нужная таблица уже прочитана  другим процессором; 

- организовать быстрое  взаимодействие между процессами; через разделяемую память, в частности,  обмениваются данными потоки, участвующие  в параллельной обработке сложного  запроса; разделяемая память используется  также для организации взаимодействия  между локальным клиентом и  сервером.

2. БАЗА ДАННЫХ MS ACCESS

2.1. Microsoft Access - функционально полная реляционная СУБД

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

Microsoft Access - это функционально полная реляционная СУБД. В ней предусмотрены все необходимые вам средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Что касается легкости использования, то Microsoft Access совершил здесь настоящий переворот, и многие для создания своих собственных баз данных и приложений обращаются именно к нему.

Система управления базами данных предоставляет вам возможность  контролировать задание структуры  и описание своих данных, работу с ними и организацию коллективного  пользования этой информацией. СУБД также существенно увеличивает  возможности и облегчает каталогизацию  и ведение больших объемов  хранящейся в многочисленных таблицах информации. СУБД включает в себя три основных типа функций: определение (задание структуры и описание) данных, обработка данных и управление данными. Все эти функциональные возможности в полной мере реализованы в  Microsoft Access. В практике, как правило, необходимо решать и задачи с использованием электронных таблиц и текстовых процессоров. Например, после подсчета или анализа данных необходимо их представить в виде определенной формы или шаблоны. В итоге пользователю приходится комбинировать программные продукты для получения необходимого результата. В этом смысле все существенно упростят возможности, предоставляемые Microsoft Access.

2.2. Предназначение  СУБД Access

СУБД Access предназначена для разработки баз данных реляционного типа для локального их использования на персональных компьютерах и для работы с этими базами.