DeepEdit!

Начнем эту главу с цитаты из руководства администратора JNeto версии 8.1.5, изданного корпорацией Oracle. В разделе "Обзор Net8" говорится следующее: "Nei.8 — это фундамент для семейства сетевых продуктов Oracle, позволяющий службам и их приложениям размещаться на разных компьютерах и взаимодействовать как равноправные приложения. Основной функцией Net8 является установление сетевых сеансов и передача данных между клиентской машиной и сервером или между двумя серверами". Просто и ясно, не правда ли?

В некоторых отношениях средства Net8 действительно весьма просты. В то же время работа с сетями в Oracle может стать очень сложной. Рассматривая Net8, я постараюсь сохранять максимальную простоту и понятность изложения.

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

Корпорация Oracle впервые выпустила свою реляционную систему управления базами данных (РСУБД) примерно в 1979 году. Однако в ноябре 1983, когда я была нанята в качестве программиста-аналитика категории С для работы над научным приложением, наша компания использовала всего лишь версию 2.0. Мы писали программы для управления аппаратурой сбора данных и их обработки. Созданные нами программы на языке FORTRAN обрабатывали информацию, хранившуюся в базе данных. Продукты Oracle были еще очень незрелыми, а их совершенствование велось крайне медленно.

Для диалога с базой данных Oracle мы использовали языки (User Friendly Interface — дружественный пользователю интерфейс) и Procedural UFI (процедурный UFI), которые были предшественниками SQL и PL/SQL. Я работала в системе Digital VAX, поддерживавшей графические дисплеи. Наши формы представляли собой графические программы, использовавшие модуль интерактивных форм (Interactive Forms, Oracle. Сначала мы создавали исходные файлы с расширением .inp. Затем формы компилировались с помощью команд интерактивной графики
(Interactive Graphics,        и полученные выполняемые файлы (.iap) запускались командой runform.

Для создания базы данных мы использовали команду ccf (create contiguous file — создать непрерывный задавая имя и размер файла.
Когда места в файле начинало не хватать, мы выгружали данные с помощью утилиты экспорта, создавали новый файл большего размера и импортировали в него данные. Для загрузки информации в базу данных можно было использовать загрузчик данных Oracle (Oracle Data Loader, ODL), а ее мониторинг осуществлялся с помощью системы ODS (Oracle Display System), которую мы в шутку называли "odious". (Odious — ненавистный, отвратительный. Произносится также, как и сокращение ODS. — Прим пер.) Для запуска базы данных нужно было вводить команду ior (initialize Oracle — инициализировать Oracle). Для отслеживания состояния данных до и после изменений существовали файлы журналов исходного вида (before image, BI) и журналов изменений (after image, AI). Работа с базой данных велась через "немые" терминалы. Непосредственно обращаться к базе данных с удаленного компьютера было невозможно.

По мере совершенствования Oracle в нашем распоряжении оказались три утилиты: ставшая стандартным генератором блоков в SQL*Forms; crt, предназначенная для управления экранной средой; и генератор отчетов rpt, позже названный Oracle Report, позволявший отображать отчеты в гибком формате. Утилита rpt представляла собой интерпретатор, а не компилятор, работала медленно и была сложна в использовании. Отчет требовалось предварительно скомпоновать и отформатировать, чтобы точно знать, в каком месте страницы будет располагаться каждый элемент. Изменение размера одного столбца могло потребовать повторной генерации всего отчета.

В РСУБД Oracle с очень давних пор существует учетная запись SCOTT с паролем TIGER. Ее удобно использовать для изучения структурированного языка запросов (Structured Query Language, SQL) и тестирования сетевых соединений с базой данных. В первых версиях вы должны были самостоятельно создать эту учетную запись, указав соответствующий пароль, присвоить ей необходимые права доступа и только потом запускать сценарии создания демонстрационных объектов. Сценарии хранились (и по-прежнему хранятся) в каталоге SQL*Plus/demo. В более

поздних версиях учетная запись SCOTT и связанные с ней объекты стали создаваться автоматически.

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

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