базы данных credo. работаем эффективно и безопасно

БАЗЫ ДАННЫХ CREDO. РАБОТАЕМ ЭФФЕКТИВНО И БЕЗОПАСНО
Д.М. ВАСИЛЬКОВ,
руководитель группы программистов,
Кредо-Диалог, г. Минск
И.А. КУЧКОВА,
инженер-программист,
Кредо-Диалог, г. Минск
Вся внешняя информация систем, разработанных на базе платформы CREDO III, включая геометрию и семантику прикладных объектов, справочную информацию – классификаторы, условные знаки,
шаблоны чертежей, стили заполнения, штриховки и т.д. хранится в базах данных (БД). Это испытанный и
надежный инструмент, специально предназначенный для решения задач по хранению, организации и динамической загрузке данных. Кроме того, специальные функции администрирования БД обеспечивают
высокий уровень защиты информации.
В нашем журнале мы рассматривали вопросы, связанные с принципами хранения и организации
внешних данных. Однако, судя по количеству вопросов, поступающих в службу технического и технологического сопровождения компании «Кредо-Диалог», назрела необходимость в систематическом изложении особенностей эксплуатации и правил по сервисному обслуживанию БД CREDO. Рассмотрим наиболее типичные затруднения, возникающие у пользователей при эксплуатации баз данных.
ПРОЕКТ ЗАБЛОКИРОВАН. ЧТО ДЕЛАТЬ?
При работе с корпоративными базами данных приложение CREDO осуществляет контроль доступа
к общим ресурсам, в том числе к проектам. Проект, открытый одним пользователем для записи, может
быть открыт другим пользователем только для чтения, и если один пользователь сохраняет данные проекта, то другой пользователь не может начать его загрузку. К слову, аналогичные правила справедливы и
для файловой системы Windows. Рассмотрим подробнее механизм блокировки.
При подключении к базе данных приложение CREDO сохраняет в ней свой сетевой адрес и идентификатор. После этого периодически, один раз в 3 минуты приложение посылает в БД информацию о
том, что оно по-прежнему активно (зачем это нужно станет ясно несколько позднее). Непосредственно
перед открытием проекта приложение пытается заблокировать доступ к нему со стороны других приложений. В случае успеха проект помечается в БД как открытый для модификации. Перед закрытием приложение, открывшее проект, снимает установленную им блокировку.
Все прекрасно работает до первого аварийного завершения приложения, в результате чего проекты,
открытые этим приложением, на некоторое время остаются заблокированными (напомним, что при нормальном закрытии проекта блокировку снимает само приложение). Здесь на помощь приходит функционирующее на сервере специальное задание (job), которое с периодичностью в 5 минут сравнивает текущее время со временем, когда приложение в последний раз подтвердило свою активность (рисунок). Если последнее подтверждение произошло раньше, чем 5 минут назад, то job справедливо полагает, что
данное приложение не активно и все установленные им блокировки могут быть удалены.
Сервер БД Каждые 5минут Job Каждые 3 минуты PID: 1405 (15:31:32)
Кунцево
CREDO ТОПОПЛАН 15:28:32
Приложение подтверждает свою актуальность, обновляя временную отметку на сервере, в то время
как job проверяет актуальность приложений и установленные ими блокировки
Итак, если в результате аварийного завершения приложения открытые им проекты оказались заблокированными, то автоматическое снятие блокировок должно произойти не позднее, чем через 5 минут.
Если же проекты остаются заблокированными и через 5, и через 10 минут, то необходимо обратиться к
администратору БД, который должен проверить работоспособность задания с именем <имя БД>_CleanClients.
Если оно отсутствует или отключено (такое может произойти при переносе базы на другой сервер, при
восстановлении из резервной копии и т.д.), то его необходимо создать и запустить, задав ему указанное
имя. Скрипт задания можно получить со старого сервера (в случае переноса) или у службы поддержки
компании. Администратор MS SQL Server должен кроме этого проверить, функционирует ли на сервере
служба SQL Server Agent и при необходимости ее перезапустить.
ПОЧЕМУ РАЗМЕР БАЗЫ БЫСТРО УВЕЛИЧИВАЕТСЯ?
В приложениях CREDO III совмещены функции проектных и геоинформационных систем, что
предполагает выполнение двух, на первый взгляд, конфликтующих требований. С одной стороны, данные проекта должны находиться в оперативной памяти (это необходимо для быстрой их обработки при
решении геометрических задач). С другой стороны, требуется исключить из оперативной памяти элементы проекта, которые в данный момент не используются (например, проекты профилей или семантическое
описание топографических объектов).
Для выполнения этих условий, данные проекта разделены на блоки, хранящиеся в разных таблицах.
Часть данных (статическая), содержащая геометрию объектов, хранится как набор бинарных полей
(BLOB) и загружается один раз целиком при открытии проекта. Другие элементы проекта, такие как проекты профилей и семантические значения, загружаются динамически по мере необходимости. Суммарный размер данных проекта может достигать десятков и сотен мегабайт, причем большую часть из них
составляет содержимое бинарных полей. При сохранении проекта обновляются все бинарные поля проекта (если модифицирована статическая часть данных), и модифицированные динамически подгружаемые элементы. Таким образом, единичная транзакция, выполняющая сохранение проекта, во-первых,
включает обновление большого блока бинарных данных (обновление бинарного поля включает удаление
старого значения и запись нового), а во-вторых, повторяется часто (особенно при одновременной работе
нескольких клиентов корпоративной БД).
Зная о такой особенности, специалист по БД сделает однозначный вывод: база будет быстро увеличиваться в размерах. Дело в том, что при удалении элементов БД они не удаляются физически, а лишь
помечаются как удаленные, в результате чего размер файла БД изменяется только в сторону увеличения.
Более того, корпоративные БД поддерживают так называемый журнал транзакций, содержащий список
модификаций всех полей БД, включая бинарные поля проектов. Получается, что при однократном сохранении проекта размером 50 Мб размер журнала транзакций также увеличивается на 50 Mб! От ведения
журнала транзакций можно отказаться, но расплатой за это может стать потеря данных за период от создания последней резервной копии БД до момента аварии.
Функции сжатия файла БД и управления журналом транзакций (для корпоративных БД) входят в
состав любой информационной системы. Существуют удобные и надежные средства администрирования, позволяющие настраивать и выполнять резервное копирование данных.
Некоторые сервисные функции реализованы в менеджере БД CREDO. Помимо неактуальной блокировки проектов, аварийные завершения приложений могут приводить к накоплению в БД временной
или служебной информации, которая при нормальном завершении обычно удаляется. Для очистки корпоративных БД от таких данных в Корпоративном Менеджере предусмотрена функция «Сервис», которую рекомендуется выполнять не реже раза в неделю. Заметим, что эта функция не производит сжатия
файла БД.
Очистка и сжатие персональной БД производится с помощью Персонального Менеджера при выполнении команды «Сжать и восстановить БД». При этом элементы, помеченные как удаленные, удаляются физически. Непосредственно перед сжатием файла БД менеджер предлагает удалить резервные копии проектов.
КАК НАСТРОИТЬ РЕЗЕРВНОЕ КОПИРОВАНИЕ КОРПОРАТИВНОЙ БД?
Одна из основных функций администратора БД состоит в обеспечении сохранности информации.
Прежде чем приступить к промышленной эксплуатации системы, хранящей данные в корпоративной БД,
необходимо разработать эффективную схему восстановления и копирования данных. В частности, для
приложений CREDO III такая схема должна учитывать динамику роста размера БД и журнала транзакций. Ниже приведены рекомендации для администратора БД MS SQL Server:
− Чтобы ограничить размер журнала транзакций, можно выполнять дифференциальное копирование БД
относительно часто, а резервное копирование самого журнала – редко, либо не выполнять вообще.
Частота зависит от интенсивности работы с базой, оптимальные интервалы обычно подбираются в зависимости от роста объема базы за неделю, включая системные таблицы.
− В случае переполнения сервера можно (но нежелательно) произвести усечение журнала транзакций с
помощью инструкции BACKUP LOG с параметром TRUNCATE_ONLY. После того как журнал транзакций усечен, выполните полное резервное копирование базы данных master и пользовательской базы данных.
− После резервного копирования необходимо выполнить удаление из файлов БД неиспользуемого пространства. Это можно сделать с помощью инструкции
o DBCC SHRINKDATABASE
− Необходимо периодически просматривать SQL Server Logs, Event Viewer. Можно настроить службу
оповещения Alerts, которая будет присылать сообщение о переполнении сервера.
− Для автоматизации обслуживания базы данных можно воспользоваться утилитой Database Maintenance Plan Wizard.
Рекомендации для администратора БД Oracle:
− В Oracle существует набор инструментов для восстановления данных (Recovery Manager или RMAN),
позволяющий восстанавливать базы данных в автоматическом режиме с помощью режима командной
строки или менеджера восстановления из утилиты Oracle Enterprise Manager (OEM). Любой из этих
методов можно использовать для резервного копирования и восстановления файлов базы данных.
− Для создания резервной копии можно воспользоваться логическим резервным копированием, которое
читает записи базы данных и записывает их в файл дампа экспорта. Этот тип копирования и восстановления БД выполняют утилиты экспорта/импорта. Можно осуществлять экспорт на уровне табличного пространства, чтобы экспортировать все содержащиеся в нем объекты.
− С помощью команд alter database и alter tablespace можно изменять размеры существующих
файлов данных. Для каждого файла данных в БД можно задать значения параметров расширения
памяти.
− Корпорация Oracle поставляет дополнительные пакеты, которые могут использоваться совместно
с утилитой OEM для контроля настройки и менеджмента и для генерации диагностики системы и
базы данных (Tuning Pack, Diagnostics Pack).
КАК ОРГАНИЗОВАТЬ ЭФФЕКТИВНУЮ РАБОТУ С ПЕРСОНАЛЬНОЙ БД?
Все СУБД имеют ограничения по объему хранимой информации. Для настольной СУБД MS Jet
(Access) максимальный размер файла mdb составляет 1 Гб для MS Access 97 и 2 Гб – для MS Access
2000–2003, 2007. Ниже приведены рекомендации, выполнение которых позволит организовать эффективную работу в рамках указанных ограничений:
− Регулярно выполняйте сжатие и восстановление БД, в ходе которого происходит физическое удаление записей из файла БД.
− Приложения CREDO III позволяют сохранять в БД резервные копии проектов. Значительное уменьшение объема БД может быть достигнуто либо путем отказа от создания резервных копий, либо регулярным удалением резервных копий при сжатии и восстановлении БД.
− Выбирайте оптимальный вариант хранения больших растровых подложек. Учтите, что внутренняя
подложка сохраняется каждый раз при сохранении проекта, в результате чего база данных быстро переполняется.
− Помните, что удаление набора проектов не приводит к удалению входящих в него проектов. Ненужные проекты можно удалить только в браузере проектов.
− Если в рамках предприятия предполагается работа с большим числом проектов, то по возможности
организуйте переход на работу с корпоративными БД.
− Для неиспользуемых проектов создавайте архивы в виде файлов PRX. Периодически выполняйте резервное копирование файлов MDB и храните их на другом компьютере или электронном носителе.
ИМПОРТ И ЭКСПОРТ
Обеспечить сохранность информации можно еще одним способом – с помощью операций импорта/экспорта элементов данных. Для обмена общими данными служат файлы в формате DBX (напомним,
что к общим данным относятся классификатор, библиотека УЗ и стилей, растровые подложи, шаблоны
чертежей и т.д.). Если необходимо, например, дополнить персональную базу новыми объектами классификатора, созданными в корпоративной БД, то сначала с помощью Персонального Менеджера БД выполните экспорт общих ресурсов из корпоративной БД в файл DBX, а затем импортируйте его в персональную БД. При импорте файла DBX в корпоративную базу администратор должен позаботиться о том,
чтобы на время импорта к ней не были подключены никакие клиентские приложения CREDO.
Обмен проектами выполняется через файлы в формате PRX. При экспорте в файл сохраняются все
данные одного проекта, включая его семантику и проекты профилей. Кроме того, файл содержит синхронизирующую информацию, необходимую для корректного импорта в новую базу.
Файлы обоих форматов хорошо пакуются архиваторами, что часто используется при пересылке
данных по электронной почте. Не стоит, однако, забывать, что формула «БД Кредо = DBX + все PRX» не
всегда верна. Во-первых, она не учитывает наборы проектов, обмен которыми через файлы пока не реализован. Во-вторых, импорт файла DBX в базу данных, версия которой старше версии базы-экспортера,
сопряжен с определенными трудностями: необходимо сначала выполнить импорт файла DBX в БД старой версии, затем обновить версию этой БД, выполнить из нее экспорт в DBX, и наконец, импортировать
полученный файл в нужную базу.
Разумеется, в одной статье невозможно рассмотреть весь спектр проблем, встающих перед пользователями при решении практических задач. Но мы надеемся, что приведенные выше рекомендации окажутся полезными и помогут наладить эффективную и безопасную технологию работы с БД CREDO.