Переход с Paradox на InterBase за 30 дней

© Скип Роуланд Skip Rowland
Президент r3 Software, Inc.
Подробные данные об авторе

Настоящий документ представляет собой техническую статью, подготовленную на основе выступления Скипа Роуланда (Skip Rowland), президента фирмы r3 Software Inc., на 10-ой ежегодной конференции Inprise & Borland.

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

Обзор

Рассмотрим ситуацию на примере многофункциональной морской компании, занимающейся перевозками пассажиров, грузов и буксировкой по всему миру и являющейся в течение уже долгого времени моим клиентом. В 1993 году у них была установлена электронная система выписки счетов и определения загрузки на базе Paradox для Dos. В январе 1997 года они обратились ко мне с просьбой предложить что-нибудь, более полно отвечающее их требованиям к базе данных. Они чувствовали как внутреннее давление, вызываемое возросшими потребностями в управлении, так и внешнее, связанноес возросшими требованиями со стороны промышленности. Им требовалась система, которая могла бы объединить деятельность всех отделов (продаж, отправки, расчетного, операционного, отдела кадров, HR, и отдела управления рисками) в одну центральную базу данных.

В это время они имели сеть на базе Novell 3.11, включающую около 30 рабочих станций и использовали Paradox для Dos, Professional File, Excel, Word Perfect, а также ряд других инструментов. Тогда же были определены пять основных приложений:

• Распределение/расчеты
• Операционный
• Работа с кадрами
• HR
• управление рисками

Позднее было выявлено еще три приложения:

• управление продажами
• управление операциями
• общее администрирование

И я уверен, что по мере продвижения вперед будут всплывать все новые приложения.

Первоначально был предложен переход на Windows95, что, в свою очередь, потребовало обновления почти всего аппаратного и программного обеспечения компании. И хотя это было абсолютно неизбежно, в компании пытались максимально отодвинуть сроки модернизации. Мы предложили архитектуру клиент/сервер, но предложение было отвергнуто как нечто преждевременное; в результате в качестве хранилища данных был выбран Paradox v7.

Разработка началась в феврале 1997 года и шла обычным чередом: мы создавали базу данных, строили прототип, а затем снова возвращались к чертежам. И на каждом витке мы все ближе подходили к тому, что заказчики хотели получить, но не могли четко сформулировать.

По мере разработки в нее включались все новые направления, каждое из которых вызывало появление все новых и новых таблиц соответствий. База данных, включавшая изначально 25 таблиц, выросла до 400 таблиц.

Сначала все шло гладко. Приложение по распределению/расчетам было самой простой задачей, так как оно было полностью определено и работало уже в течение 4 лет. К несчастью, дела пошли значительно хуже в июне 1998 года, когда мы приступили к работе над HR-приложением.

Проблемы

Каждое приложение могло выполняться автономно и работало вполне приемлемо. Однако, как только приложения начинали работать параллельно, возникали противоречия, и все начинало разваливаться. Проблема усугублялась, когда пользователи с 16 Мб- ОЗУ пытались одновременно запускать Word, Excel, электронную почту и ряд других приложений. В результате иногда блокировались только приложения с базами данных, а иногда вся система. Иногда приложения с базами данных загружались полностью, а иногда загрузка не удавалась вообще. А сколько мы получили этих ужасных сообщений "insufficient memory to complete operation" (недостаточно памяти для завершения операции)! В общем, мы были свидетелями самых различных случаев несообразного, непонятного и абсолютно неприемлемого поведения.

Band-Aids

Как я уже упоминал, каждое приложение могло выполняться самостоятельно в качестве решения на уровне отдела. Но так как это разрушало целостное представление решения на уровне предприятия, ни о каком разбиении и слиянии данных на хоть сколько-нибудь регулярной основе не могло быть и речи. Первоначально я сам выполнял всю работу, используя Delphi вместо Paradox. Я проработал каждое приложение вдоль и поперек, исключая все внешние накладные расходы и урезая все, что было возможно. Базовую архитектуру я взял без изменения из KnowledgeBase:

• исполняемые программы и данные размещались в разных каталогах
• в исполняемой программе устанавливались сетевые и локальные директории
• значение dbiSetLockRetry было установлено на 20

Но этого было не достаточно. Сначала мы обновили BDE, с 3.51 на 4.01, а затем изменили установки BDE-конфигурации.

В течение некоторого времени это работало. К сожалению, из-за циклов тестирования и создания прототипов, полностью использовалось только приложение по распределению/расчетам. Однако к сентябрю 1998 начали оперативно функционировать и использовать приложения HR- и операционный отделы. И вот наступило "Черное воскресенье". 21 сентября, около 10 часов утра, произошел сбой во всех четырех приложениях одновременно. Очевидно, что меры предосторожности были явно недостаточными.

Решения

Единственным приемлемым решением был бы переход на архитектуру клиент/сервер. InterBase была при этом логичным выбором, исходя из ее стоимости, доступности, сопровождения, а также моей предрасположенности к ней. Так как многие люди зависели от работы приложений, все необходимо было сделать в максимально короткие сроки. Фактически, сначала мне было дано на это 30 дней.

Кроме того, были некоторые дополнительные соображения, касающиеся клиента, а именно, обновление их сетевой операционной системы. Они использовали NetWare 3.11 и знали, что придется перейти на новую ОС. Рассматривались варианты NT4, ожидаемая NT5, NW4.11, или NW5. В конце концов, единственным жизнеспособным вариантом оказалась NW4.11. Так как у фирмы не было собственного сетевого администратора, вариант NT4 казался слишком рискованным; что касается NT5, то они опасались, что не успеют развернуть ее до 2000. На тот момент не было сертифицированной версии InterBase для NW5, следовательно, оставалась только NW4.11.

Некоторые дополнительные Band-Aids

Прежде чем начать перенос, от меня, как минимум, требовалось сделать текущие приложения доступными. Самая большая проблема заключалась в том, что размер блокировочных файлов увеличился до такой степени, что их стало просто невозможно переносить с помощью BDE (более 2.5 Мбайт). Рассматривались следующие промежуточные решения:

• Разделение данных на несколько директорий и использование нескольких псевдонимов
• Написание "диспетчера блокировочных файлов", который отслеживал бы размеры больших блокировочных файлов. При достижении любым из них размера в 700, ему предлагалось бы покинуть приложение с базой данных. Обычно блокировочные файлы приходилось бы удалять вручную - BDE не выполняла обычные служебные действия.
• Мы снова обновили BDE на 4.51, и еще более изменили конфигурацию.

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

Фактический процесс переноса

Можно выделить четыре фазы переноса Delphi-приложения с Paradox на InterBase:

• Установка и настройка
• Перенос базы данных
• Перенос кода базы
• Оптимизация сервера

Установка и настройка включает инсталляцию InterBase, ознакомление и использование WISQL, а также конфигурирование BDE.

Для "чистого" запуска я демонтировал InterBase, установленную при инсталляции Delphi. Я выполнил полную инсталляцию IBLocal с установками по умолчанию. За тем я создал каталог под именем PDox2IB, в котором разместил "горячие" клавиши для InterBase Server Manger, WISQL, Database Desktop и BDEAdministrator.

В первую очередь я хотел изменить пароль входа в InterBase на более короткий. Для этого я:

• запустил Server Manager
• вошел в систему как User SYSDBA с универсальным паролем
• выбрал User Security и изменил пароль SYSDBA на "bo"

Примечание: для просмотра изменений паролей необходимо выйти из системы, а затем снова войти в нее

Затем, чтобы создать новую базу данных в InterBase, в которую затем будет осуществлен перенос, я запустил WISQL.

• Из меню, File|Create Database
• DatabaseName: C:Program FilesBorlandIntrBaseVMXVM.gdb
• Пароль: bo

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

Затем, чтобы создать новые псевдонимы для исходной и целевой баз данных, я запустил BDEAdmin.

• В закладке Database, щелкнул правой кнопкой мыши и выбрал New. Оставил тип STANDARD
• Изменил имя на VMS
• Изменил PATH на C:Apps3EESBigData
• Снова в закладке Database, щелкнул правой кнопкой мыши и выбрал New. На этот раз выбрал INTRBASE
• Изменил имя на VMX
• Изменил имя сервера на C:Program FilesBorlandIntrBaseVMXVM.gdb
• Закрыл BDEAdmin

Теперь все было настроено для переноса данных.

Перенос базы данных

В первую очередь хочу отметить, что это НЕ одношаговый процесс. Если Вы предполагаете, что все произойдет мгновенно каким-либо сказочным образом, то Вас ожидает глубокое разочарование. В состав Delphi C/S входит программа с именем Datapump.exe; она установлена в BDE-каталоге и называется "Data Migration Wizard" ("Мастер переноса данных"). Datapump - хороший инструмент, но он имеет свои ограничения - не ожидайте от него невозможного и не воспринимайте как "панацею". Иногда вам придется закатать рукава и самим написать тот или иной инструмент. Если у вас нет Datapump, то придется написать его самим. Но в данном случае, предположим, что есть уже готовый.

Самые большие проблемы: имена полей и типы полей.

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

Подробнее: вам придется сделать ее, КАК МИНИМУМ, ДВАЖДЫ: один раз для разработки, а второй для эксплуатационной базы данных! Вы обязательно должны документировать весь процесс преобразования. Помните, что процесс переноса эксплуатационной части пройдет гладко только при идеальной отработке этого процесса.

Самые большие изменения в базе данных придется вносить в:

• Имена полей
• Вторичные индексы

Можете попытаться предварительно выполнить эти операции, или же в несколько циклов с использованием datapump. Datapump создает две paradox-таблицы -одну перед "переносом", а вторую после. В первой таблице отображаются изменения, которые будут внесены в вашу базу данных, а во второй - изменения, которые произошли.

Давайте рассмотрим изменения в именах файлов

Лучше всего, если исходные таблицы, а затем код, будут модифицированы до выполнения окончательного переноса. В этом случае, можно быть уверенным, что ваш код будет работать после переноса.

• Чаще всего необходима замена пробелов символами "_" (Delivery Date будет выглядеть как DELIVERY_DATE)
• Вторым наиболее частым случаем будет наличие поля с именем "Date", которое является зарезервированным словом
• Проблему составят также и другие зарезервированные слова: VALUE, ORDER, GROUP, SET
• И, наконец, проконтролируйте отсутствие запрещенных символов (#, @, и так далее).

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

Базовый процесс, выполняемый вручную

Выполните:

• С помощью Windows Explorer, запустите Datapump


• Выберите исходный псевдоним (VMS)
  
• Выберите целевой псевдоним (VMX) Войдите в систему с паролем SYSDBA


• Выберите все таблицы


• Нажмите кнопку upsize


• Запишите копию данного отчета в файл, создающий Paradox-таблицу


• Закройте Datapump
  
• Используя Database Desktop, посылайте запрос о наличии сбоев до тех пор, пока не будут выявлены все сбои

Чтобы просмотреть результаты, запустите WISQL, затем выберите File|Connect to Database

• C:Program FilesBorlandIntrBaseVMXVM.gdb
• Войдите в систему с паролем SYSDBA

Чтобы просмотреть, что сделала программа Datapump,

• Extract|SQL Metadata for Database
• Для просмотра содержания таблицы, SELECT * FROM [tablename]
• Закройте WISQL

Примечание: если Вы выполнили "select" один раз, программа запросит, следует ли продолжать работу. Можно ответить и "да" и "нет".

Преобразование эксплуатационных данных

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

• будет дублировать в новый каталог мою paradox-базу данных без самих данных
• позволит собрать все исходные данные в каталог преобразуемых исходных данных
• переместит преобразуемую исходную базу данных в мою IB-базу данных
• (используя пакетный перенос).

Между шагами 2 и 3, я запустил Datapump, чтобы создать IB-базу данных из пустой продублированной базы данных, полученной в шаге 1.

Перенос кода базы

Здесь перед нами стоят простые задачи:

• скомпилировать;
• сделать, чтобы он работал,
• и сделать так, чтобы он работала корректно.

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

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

Сначала создайте каталог для нового проекта, ibProjects.

• В ibProjects, создайте каталог для данного проекта (мой назывался ees).
• В каталоге проекта, создайте каталог данных и исходный каталог.
• Если Вы используете w2w, скопируйте главный каталог w2w в каталог ibProjects. Проделайте то же самое для всех сторонних компонентов, имеющих собственные каталоги. Помните, что Вы осуществляете перенос, перемещение. Первоначально переносится все, но затем остается только необходимое.
• Удалите файлы с расширением .dof, .dsm и .dsk.

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

Регистрационное имя приложения

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

  В BDE (при закрытом Delphi) измените Paradox-псевдоним своего приложения на другой.

Затем, находясь в Delphi,

• File|New Datamodule
• Вставьте TDatabase -компонент
• Измените его имя на DBConnection
• Установите в Alias новый BDE-псевдоним для своей IB-базы данных
• Установите DatabaseName на старый Paradox BDE-псевдоним
• Дважды щелкнув по нему мышью, откройте редактор свойств
• Нажмите кнопку Defaults
• Приведите Defaults в соответствие с указанными ниже

SERVER NAME=c:apps4eesvm.gdb
USER NAME=SYSDBA
PASSWORD=mypassword

• Пометьте галочками, не разрывая соединения
• Проверьте, чтобы приглашение не было помечено
• Задайте блоку имя dmKey
• Сохраните блок как IBKey

Откройте свой проект. Если Вы действительно все из него удалили, то откроется только исходный файл (.dpr). Просмотрите менеджер проекта. Нажмите кнопку Add и добавьте в проект IBKey. В исходном файле (.dpr), в первую очередь следует создать модуль данных.

И что действительно замечательно, так это то, что другие модули данных смогут использовать это соединение, НЕ обращаясь к модулю данных в операторе uses!!!

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

В КОДЕ (И dfms-, и pas-файлы)

Проблемы и их решение

Если Вы используете Woll2Woll-компоненты, следует внести еще некоторые изменения.

wwDBComboLookup восстановить параметры поиска Lookup Property проверить ВСЕ псевдонимы и имена таблиц в поисковых строках, особенно в DFMs. В противном случае, ваша форма не откроется даже, если будет скомпилирована!

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

Оптимизация сервера

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

Предупреждение: Ваша первостепенная задача - сделать так, чтобы приложение заработало; вторая задача - оптимизировать код так, чтобы он мог использовать все преимущества серверной части системы. Очень заманчиво не выполнять эту последовательность и начать оптимизировать код еще во время переноса. Что же, но пусть это не собьет вас с верного пути...

Продолжение статьи

Дополнительная информация

• Borland InterBase
• Информация об Interbase 6
• FAQ по IB DataBase 5
• Учебные курсы
• Приобрести InterBase в Интернет-магазине Itshop.ru

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме Inprise/Borland