|
|
Основы баз данных с OpenEdge
Введение
Прежде чем приступить к администрированию OpenEdge баз данных, Вам необходимо хотя бы в общих чертах понимать все основные концепции реляционных баз данных. В книги не ставится цель обучить использованию команд и утилит OpenEdge RDBMS. Цель данной книги, это формирование у читателя понимания принципов работы механизмов OpenEdge, а так же, в ней будут описаны концепции реляционных базы данных на примере OpenEdge RDBMS.
Характеристики базы данных
База данных, это структурированный организованный набор данных, которая предлагает вам определенные преимущества. А именно:
- Централизация хранения данных – ввод и хранение всех данных выполняется на компьютере. Это минимизирует использование бумаги, файлов, папок, а так же уменьшает вероятность их потери. К данным, находящимся на компьютере, могут получить множество пользователей, используя сеть, при этом физическое или географическое их месторасположение не имеет значения.
- Актуальность данных – изменения, внесенные пользователями, мгновенно становятся доступны другим пользователям.
- Скорость и производительность – вы можете искать, сортировать, извлекать, вносить изменения и печатать данные, а так же выполнять различные подсчеты, значительно быстрее, чем если бы это делалось в ручную.
- Точность и согласованность – вы можете обеспечивать проверку вводимых данных на корректность, тем самым обеспечивая непротиворечивость и правильность данных. Например, пользователь не сможет удалить карточку клиента, если у этого клиента имеются заказы.
- Анализ – базы данных могут хранить, отслеживать и обрабатывать огромные объемы данных из разнообразных источников.
- Безопасность – для обеспечения безопасности данных, вы можете определять списки авторизованных пользователей, у которых доступ к данным будет закрыт паролем. Например, вы можете ограничить пользователя в выполнении определенных действий с данными.
- Восстановление данных – системные сбои неизбежны. Целостность данных в результате таких сбоев гарантируются базой данных. Системы управления базами данных (СУБД) используют транзакционный журнал (transaction log) для того чтобы проверять правильность восстановления данных после аварии.
- Транзакции – концепция транзакции, это обеспечение восстановления после различных ошибок. Транзакция гарантирует, что набор изменений связанных с базой данных всегда будут выполняться по принципу, либо все изменения будут сохранены, либо ни одно из них. Это позволяет восстановить базу данных в предыдущее состояние, если сбой произошел после того, как изменения начали вноситься, или если вы просто решили отменить эти изменения. Чтобы удовлетворять определению транзакции, СУБД должна придерживаться следующих четырех свойств:
Атомарность (atomicity) – транзакция должна быть полностью завершена или полностью отменена. Не может быть частичных транзакций;
Последовательность (consistency) – транзакция должна преобразовывать базу данных из одного непротиворечивого состоянии в другое.
Изолированность (isolation) – каждая транзакция должна выполняться независимо от любой другой транзакции.
Долговечность (durability) – постоянность завершенных транзакций, т.е. изменения внесенные завершенной транзакцией, не могут быть отменены.
Использование первых символов английского варианта этих свойств, при удовлетворении всех свойств, характеризует транзакции вашей базы данных как ACID устойчивые.
Теперь, когда понятны все преимущества базы данных, рассмотрим элементы реляционных баз данных.
Планирование административных задач
Реляционная база данных основана на реляционной модели. Реляционная модель это набор правил основанных на математических принципах реляционной алгебры, которые определяют каким образом системы управления базами данных должны функционировать. Основными структурами реляционных баз данных в реляционной модели, являются таблицы (tables), поля (column или field), записи (row или record) и ключи (key).
Таблицы
Таблица, это логически связанная информация рассматриваемая как единое целое. Таблица состоит из столбцов и строк. Ниже приведен пример таблицы Customer из базы данных Sports.
 |
|
Cust Number
|
Name |
Street
|
| 101 |
Jones, Sue |
2 Mill Ave. |
|
| 102 |
Hand, Jim |
12 Dudley St. |
| 103 |
Lee, Sandy |
45 School St. |
| 104 |
Tan, Steve |
77 Main St. |
Обычно таблицы делятся на три типа:
- Основные (kernels) – таблицы, являющиеся независимыми сущностями. Они часто обозначают или моделируют объекты, существующие в реальном мире. Например: клиенты, продавцы, сотрудники, товары и прочее.
- Ассоциативные (Associations) – таблицы которые представляют связи между объектами. Например: заказ (Order) связан с клиентом и товарами.
- Таблицы характеристик - чья цель состоит в том, чтобы квалифицировать и описывать некоторые другие объекты. Эти таблицы сами по себе не имеют ни какого значения, они используются только относительно описываемого объекта. Например: таблица order-lines могла бы описывать таблицу Order, без таблицы Order таблица order-lines будет бесполезна.
Таблицы состоят из строк (row), или записей (record). В строке содержатся данные, и каждая строка рассматривается как отдельный модуль. В таблице Customer, представленной выше, содержится четыре строки, каждая из которых содержит информацию о конкретном клиенте. Точно так же, каждая строка таблицы Order содержит информацию о размещенных заказах клиента.
Строки состоят из наборов столбцов (column) или полей (field). Все строки в таблице состоят из одинаковых столбцов. В таблице Customer, представленной выше, имеется три столбца: Cust Number, Name и Street.
Существует два типа ключей (key): primary и foreign. Primary Key, это столбец или группа столбцов, которые содержат уникальные значения, однозначно идентифицирующие строку в таблице. Поскольку ключ всегда уникален, он используется для исключения дублирования данных. Хороший Primary Key должен обладать следующими характеристиками:
- Обязательность (mandatory), т.е. столбец не может содержать не нулевые/не пустые значения. Если столбец будет оставлен пустым, то есть вероятность возникновения дублирования записей.
- Уникальность (unique). Например, таблица Student должна содержать уникальный идентификатор для каждого студента. Столбец Cust Number, в таблице Customer, это уникальный идентификатор каждого клиента. Более практично использовать именно это поле, чем поле Name, так как разные клиенты могут иметь одинаковые имена. Так же, база данных не определяет различие в именах как дубликаты, например, Cathy для Catherine или Joe для Joseph. Кроме того, иногда люди могут менять имена, например после вступления в брак.
- Стабильность (stable), т.е. когда значение вряд ли может измениться. Как в предыдущем примере, Cust Number это хороший ключ, так как он может принимать значение равное социальному индивидуальному коду человека, которое не только является уникальным, но и вряд ли когда изменится, в то время как имя клиента может поменяться.
- Краткость (short), т.е. ключ не должен содержать много символов. Маленькие столбцы занимают меньше места, они быстрее будут искаться в базе, и менее склонны к ошибкам. Например, столбец Cust Num состоит из 9 цифр, обратиться к нему намного легче, чем обратиться к полю Name, которое содержит имя из 30 символов.
Foreign key – это значение столбца в одной таблице, которое должно соответствовать значению Primary Key столбца в другой таблице. Другими словами, это ссылка одной таблицы на другую. Если значение foreign key не нулевое, то значение primary key в другой таблице должно существовать. Такие связи одного столбца таблицы с другим столбцом другой таблицы образуют реляционную базу данных, способную объединять таблицы.
Существуют еще ключи называемые composite key или составные ключи. Такие ключи состоят из более чем одного столбца.
Индексы
Индекс, это объект базы данных, создаваемый с целью повышения производительности выполнения запросов. Таблицы в базе данных могут иметь большое количество строк, которые хранятся в произвольном порядке, и их поиск по заданному значению путем последовательного просмотра таблицы строка за строкой, может занимать много времени. Индекс формируется из значений одного или нескольких столбцов таблицы, и из указателей на соответствующие строки таблицы и, таким образом, позволяет находить нужную строку по заданному значению. Ускорение работы с использованием индексов достигается в первую очередь за счёт того, что индекс имеет структуру, оптимизированную под поиск (например, би-дерево). Индексы могут быть объявлены как уникальные и как неуникальные. Уникальный индекс реализует ограничение целостности таблицы, исключая возможность вставки повторяющихся значений.
Индексы имеют следующие преимущества:
- Более эффективный быстрый поиск.
- В ABL приложениях, записи упорядочиваются автоматически согласно указанного индекса, т.е. не зависимо от того, каким образом выполняется изменение таблицы, при ее просмотре или печати, строки будут отображаться в индексированном порядке, вместо их реального порядка сохранения относительно диска.
- Когда индекс определяется как уникальный, то каждая строка будет уникальной. Это гарантирует отсутствие дублирования информации. Уникальный индекс может содержать пустые значения, но, Primary Key, хоть он тоже уникальный, не может содержать их.
- Вы можете комбинировать столбцы, создавая по ним индекс, таким образом вы сможете сортировать таблицу несколькими различными способами сразу.
- Эффективный доступ к данным в таблицах, имеющих множество связей.
- Движок базы данных контролирует уникальность индекса, поэтому когда вы попытаетесь сохранить дубликат строки в таблице с уникальным индексом, вам будет отказано в этом, тем самым обеспечивается защита от дублирования.
Применение принципов реляционной модели
Реляционная модель организовывает данные в таблице и позволяет создавать связи между ними с помощью primary и foreign key. Самым простым способом понять её, это рассмотреть обычный бизнес пример, в котором требуется отслеживать информацию по клиентам и их заказам. Такая база данных может состоять из следующих таблиц:
- Таблица клиентов (Customer) – таблица состоит из четырех строк, по одной на каждого клиента. Каждая строка состоит из двух столбцов: Cust Num и Name. Для того чтобы однозначно идентифицировать каждого клиента, клиент должен иметь уникальный номер. Каждый столбец содержит единственное значение. Primary key будет поле Cust Num.
- Таблица заказов (Order) – таблица содержит пять строк о размещенных клиентами заказов. Каждая строка состоит из двух столбцов: Cust Num, из таблицы Customer и Order Num. Primary Key это поле Order Num. Столбец Cust Num это foreign key, который связан с двумя таблицами. Такая связь позволяет находить все заказы размещенные конкретными клиентами, а так же информацию по клиенту для конкретного заказа.
- Таблица Order-Line – таблица содержит семь строк с описанием линии заказа для каждого заказа. Каждая строка состоит из трех столбцов: Order-Line Num; Item Num, из таблицы Item; Order Num из таблицы Order. Primary Key это комбинация из столбцов Order Num и Order-Line Num. Имеется два foreign key, Order Num и Item Num, связывающие таблицы Customer, Order и Item, для поиска такой информации как: все строки заказа в заказе; информацию о заказе по конкретной строке заказа; элемент (item) каждой строки заказа; информацию о каждом элементе заказа.
- Таблица элементов заказа (Item) – содержит четыре строки для каждого отдельного элемента. Каждая строка состоит из двух столбцов: Item Num и Description. Каждый элемент заказа имеет уникальный номер. Поле Item Num это primary key.
Ниже приведено изображение описанных таблиц.
Предположим, что вы захотели найти всех клиентов, заказавших Ski Boots (лыжные ботинки). Чтобы получить эти данные из базы вы должны узнать, какой номер имеют эти ботинки и кто их заказывал. Поскольку не существует прямой связи между таблицами Item и Customer, Вам придется подключиться ко всем четырем таблицам используя для их связи primary/foreign key. Для этого следуйте следующим шагам:
1. Выберите строку в таблице Item, у которой столбец Description соответствует значению Ski Boots. Значение в столбце Item Num в нашем случае будет I1.
2. Теперь необходимо выбрать заказы (таблица Order) которые содержат элемент (Item) I1. Поскольку таблица Order не содержит информацию об элементах заказа (Item), вам сначала нужно сделать выборку из таблицы Order-Lines, содержащую I1, и определить связь Order с Order-Lines. В нашем случае, заказ 01 и 04 содержит Item Number I1.
3. Теперь вы знаете номера заказов (Order Num) и вы можете найти клиентов разместивших эти заказы. Выберите заказы 01 и 04 и определите связанные номера клиентов (Cust Num). Это C1 и C3.
4. В завершении определите имена клиентов C1 и C3, выполнив выборку строк из таблицы Customer, содержащих в поле Cust Num значения C1 и C2. Результат, лыжные ботинки купили Don Smith и Jim Cain.
Следующее изображение иллюстрирует эти шаги.
Организовывая ваши данные в таблицы, и связывая их по общим столбцам, вы можете выполнять мощные запросы. Структуры таблицы и столбцов сравнительно просты, чтобы создавать их и изменять, и достаточно независимы от запросов и приложений которые получают к ним доступ. Этот пример показывает значения primary key как символьные данные только для ясности. Использование числовых ключей (key) лучше и более эффективно.
База данных OpenEdge и реляционная модель
OpenEdge это система управления реляционной базой данных (RDBMS – Relational Database Management System). Поскольку ваши требования могут меняться, то вы можете добавлять, изменять, управлять или удалять данные и их структуру в вашей базе данных.
Схема и метасхема базы данных
Логическая структура OpenEdge базы данных состоит из элементов реляционной модели, о которых вы только что прочитали, т.е. из таблиц, столбцов и индексов. Описание структуры базы данных, таблиц, которые она содержит, столбцов в пределах таблиц и прочее, называется схема базы данных (Database Schema) или определения данных (Data Definitions).
Основная структура базы данных, которая дает возможность хранить и искать данные, называется метасхема базы данных (Database Metaschema). Т.е. метасхема определяет как структурные характеристики имеющихся в базе данных таблиц, столбцов и т.д. Иными словами, метасхемой называется описание структуры объектов базы данных. Объектами метасхемы являются классы, каждый класс описывает совокупность объектов, обладающих сходными характеристиками и одинаковым набором реквизитов. Все таблицы метасхемы OpenEdge базы данных начинаются на символ подчеркивания “_”.
Метасхема, это набор таблиц которые содержат описания самих себя. Следовательно, Вы можете выполнять обычные запросы по метасхеме, для того чтобы изучить не только таблицы и индексы пользовательской базы данных, но и таблицы и индексы самой метасхемы.
Физическая структура базы данных и её связи с логической структурой будут описаны в главе “OpenEdge RDBMS”.
Для иллюстрации различных документированных возможностей базы данных OpenEdge, включая программирование, часто используется стандартная база – пример Sports2000. Эта база данных поставляется в составе дистрибутива OpenEdge. Она построена на примере работы с клиентами, которые размещают свои заказы, которым выставляются счета и т.п. Для более детального её изучения, вы можете воспользоваться такими стандартными инструментами как Data Dictionary или Data Admin Tool, где вы сможете сформировать подробные отчеты по таблицам и их индексам базы данных Sports2000. Вообще говоря, эта база данных может использоваться для различных целей, начиная от изучения азов программирования и заканчивая моделированием различных проблемных ситуаций.
Основные моменты, которые нужно помнить
- База данных, это электронная файловая система, предназначенная для организации и хранения данных, которая может охватывать множество различных областей.
- База данных состоит из таблиц. Таблица, это совокупность строк относительно определенного объекта, например клиента.
- Строка, это совокупность частей информации относительно одного объекта, например, о конкретном клиенте.
- Столбец, это конкретная часть информации об объекте, например, имя клиента.
- Индекс, это набор указателей на строку, которые вы используете для поиска, сортировки или для иных целей обработки информации, например, индекс по номеру клиента.
- Первичный ключ (Primary Key), это столбец или набор столбцов, по которому можно однозначно идентифицировать строку в таблице. Поскольку значение ключа всегда уникально, вы можете использовать его для определения и защиты от дублирования строк. Этот ключ не может и не должен содержать неопределенных, нулевых значений.
- Индекс в базе данных работает подобной индексному указателю в папке файлов. Он позволяет легче искать информацию.
- Foreign Key, это столбец или группа столбцов в одной таблице, чье значение должно соответствовать Primary Key из другой таблицы
Проектирование баз данных
В этой главе будут описаны основные концепции, необходимые для правильного проектирования реляционных баз данных. Как только вы поймете основную структуру реляционной базы данных, вы можете приступить к процессу её проектирования. Проектирование базы данных, это повторяющийся процесс, который включает разработку и усовершенствование структуры базы данных, основываясь на информации и требованиях, которые диктует ваш бизнес. Глава содержит части, которые описывают каждый этап проектирования базы данных.
Анализ данных
Первым шагом проектного цикла является определение данных, которые требуются вашу бизнесу. Ответы на следующие вопросы помогут вам начать проектирование:
- Какие типы информации используются в настоящее время бизнесом? В каких типах информации сейчас нуждается бизнес?
- Какой тип информации я хочу получать из системы? Какие отчеты я хочу формировать из неё?
- Что я буду делать с этой информацией?
- Какой контроль и какая защита понадобится этой системе?
- Возможно ли расширение системы?
Для того чтобы ответить на некоторые из этих вопросов, перечислите все данные, которые вы намереваетесь вводить и изменять в вашей базе данных, так же как и все ожидаемые выходные данные. Например, некоторые из требований, которые могут быть необходимы розничному магазину, это способность:
- Ввода данных по клиентам, заказам и товарам
- Добавление, изменение и удаление строк
- Сортировка всех адресов клиентов по индексу
- Формировать алфавитные списки клиентов, с неоплаченными счетами более чем $1000
- Сформировать список всех оплаченных и неоплаченных заказов клиентов по регионам и по датам
- Список всех счетов по конкретному товару.
- Формирование списка товаров, которых осталось меньше чем 200 штук, и автоматическая генерации соответствующего сообщения для их заказа.
- Перечислить количество каждого товара
- Отследить информацию о клиенте, так чтобы иметь распечатку всех клиентских счетов и остатки баланса по ним.
- Отследить клиентские заказы. Распечатка клиентского заказа и счета для клиента и бухгалтерии.
- Проводить инвентаризацию, для того чтобы знать, сколько материалов находится в производстве, сколько нужно заказать, где они хранятся и т.п.
- Отслеживание возвратов товаров клиентами, чтобы предполагать, какие товары стоит прекратить производить, а какие нет.
Процесс идентификации задач бизнеса, это интервьюирование и сбор информации из различных источников, которые собираются использовать базу данных, он отнимает значительную часть времени, но тем не менее это очень существенный процесс. Только когда вы имеете на руках всю необходимую информацию, вы можете приступить к определению таблиц и их столбцов.
Логическое проектирование базы данных
Логический проект базы данных поможет вам определить и связать информацию требуемую вашему бизнесу. При его создании вы описываете каждый кусок информации, которая необходимо бизнесу, и определяете связи, а так же бизнес правила, которые управляют этой информацией. Как только проект готов, вам необходимо, совместно с пользователями, проверить, что проект завершен правильно, т.е. содержит все необходимые данные, и точно, т.е. обеспечивает корректные связи согласно требованиям бизнес правил.
Сбор информации для логического проекта, это итеративный процесс, который включает следующие шаги:
- Определение таблиц, основанных на информации, которая необходима вашему бизнесу.
- Определение связей между этими таблицами.
- Определение содержимого (столбцов) каждой таблицы.
- Нормализация таблиц, по крайней мере хотя бы до третьей нормальной формы.
- Определение первичных ключей (Primary Key) и доменов столбцов (column domain). Домен, это набор значений для каждого столбца. Например, домен для номера клиента должен содержать только положительные числа.
На этой стадии, вы не рассматриваете требования обработки, производительности или аппаратные ограничения.
Табличные взаимосвязи
В реляционных базах данных, таблицы связываются между собой с помощью одного или более столбцов. Эти столбцы, существующие в двух и более таблицах, и обеспечивают связь между ними. Когда вы проектируете базу данных, определение связей происходит на основании требований правил вашего бизнеса. Связи в основном осуществляются между Primary и Foreign ключами, тем не менее, таблицы так же могут быть связаны по другим, не ключевым полям.
В примере ниже, таблицы Customer и Order связаны между собой по Foreign Key (поле Customer Number).
Если поле Customer Number будет индексом в обоих таблицах, то вы сможете быстро выполнять следующие операции:
- Находить все заказы по конкретному клиенту, и выполнять запросы информации по каждому заказу (дата заказа, даты поставки, фактической отгрузки и т.п.).
- Находить информацию о клиенте (например адрес и его название), по каждому заказу, используя только номер клиента.
Существует несколько типов взаимосвязей между таблицами. Первый тип, это отношение “один к одному” (one-to-one). Т.е. когда каждая строка в одной таблице, имеет только одну связанную строку во второй таблице. Например, когда за одним сотрудником закреплен только один офис. Или когда каждый отдел имеет только одного начальника, т.е. один начальник может управлять только одним отделом. Эта связь представлена на следующем рисунке.
Так же, бизнес правила могут подразумевать, что за одним офисом может быть закреплен один, или вообще не закреплено сотрудников. Или, у одного отдела может быть один или не может быть вообще начальника. Такая связь еще называется как “ноль или один” (zero-or-one).
Второй тип, это связь “один ко многим” (one-to-many), которая имеет место, если каждая строка в одной таблице, имеет одну или более связанных строк в другой таблице. На следующем рисунке приведен пример такой связи. Здесь, один клиент может разместить множество заказов, или каждый коммерческий представитель может иметь множество клиентских счетов.
Тем не менее, бизнес правила могут складываться так, что у одного клиента может быть ноль или много заказов, один студент моет посещать ноль или более курсов, а коммерческий представитель может не иметь, а может и иметь счета. Такие отношения называются, ноль или много (zero-or-many).
Третий тип, это “много ко многим” (many-to-many), т.е. когда строка в одной таблице может иметь множество связанных строк во второй таблице, так же как строки из второй таблицы могут быть связаны со множеством строк в первой таблице. На следующем рисунке представлен пример, когда заказ содержит множество товаров, и в тоже время каждый товар может содержаться во множестве других отдельных заказах. Или, когда сотрудник может работать над несколькими проектами, в то время как над каждым проектом может работать множество сотрудников.
Доступ к информации в таких таблицах может быть затруднен и время затратным. Для достижения большей эффективности, вы должны конвертировать таблицы со связями “многие ко многим” в две таблицы с отношением “один ко многим”, соединяя эти две таблицы с помощью таблицы перекрестных ссылок, которая будет содержать связующие столбцы.
Например, для установки связи “один ко многим” между таблицами Order и Item, необходимо создать таблицу перекрестных ссылок Order-Line, как показано на рисунке ниже. Эта таблица будет содержать такие поля из обоих таблиц, как Order Number и Item Number. Без этой таблицы, вы были бы вынуждены сохранять дублирующую информацию или добавлять дополнительные столбцы в обоих таблицах Order и Item.
Нормализация
Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.
База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных практически не встречается.
Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.
Первая нормальная форма:
- запрещает повторяющиеся столбцы, содержащие одинаковую по смыслу информацию
- запрещает множественные столбцы, содержащие значения типа списка и т.п.
- требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку
Чтобы это понять, изучим не нормализованную таблицу Customer
Cust Num
|
Name |
Street
|
Order Number
|
| 101 |
Jones, Sue |
2 Mill Ave. |
M31, M98, M129 |
| 102 |
Hand, Jim |
12 Dudley St. |
M56 |
| 103 |
Lee, Sandy |
45 School St. |
M37, M40 |
| 104 |
Tan, Steve |
67 Main St. |
M41 |
Здесь, каждое поле столбца Order Number может имеет более чем одно значение. Это весьма затрудняет выполнение даже таких простых задач, как например, удаление заказа, подсчет общего количества заказов по клиенту, или выполнение печати заказов в отсортированном порядке. Чтобы выполнить любую из этих задач, вам придется придумывать сложные алгоритмы анализа каждого значения в таком поле. Поэтому, вы должны изменить таблицу так, чтобы каждое поле в ней содержало только одно конкретное значение.
На следующем примере показан другой вид этой таблицы, который по прежнему остается не нормализованным.
Cust Num
|
Name
|
Street |
Order
Number1
|
Order
Number2
|
Order
Number3
|
| 101 |
Jones, Sue |
2 Mill Ave. |
M31 |
M98 |
M129 |
| 102 |
Hand, Jim |
12 Dudley St. |
M56 |
Null |
Null |
| 103 |
Lee, Sandy |
45 School St. |
M37 |
M140 |
Null |
| 104 |
Tan, Steve |
67 Main St. |
M41 |
Null |
Null |
Здесь, вместо одного столбца Order Number создано целых три столбца с одинаковым назначением. Такой вид таблиц так же крайне не эффективен. Скажите, что будет, если клиент сделает еще один заказ, если у него уже есть три заказа? Вам придется или добавить новый столбец, или же заменить одно из значений в существующих столбцах. Довольно трудно определить максимально возможное количество клиентских заказов. Но допустим, что вы остановились на их количестве равным 200. Хорошо, но тогда получается, что если клиент в среднем будет иметь лишь 10 заказов, то у вас таблица будет содержать по крайней мере 190 пустых (Null) значений. Кроме того, достаточно трудно и долго выполнять извлечение данных из повторяющихся столбцов. Например, для того чтобы определить, какой клиент имеет заказ с номером M98, вам будет нужно просмотреть каждый такой столбец индивидуально на предмет наличия соответствующего значения, а их у нас ведь 200 штук.
Для того чтобы привести таблицу Customer к первой нормальной форме, разобьём её на две отдельные таблицы. В которых первая будет содержать информацию только о клиентах (Customer), а вторая только информацию о заказах (Order). То что у нас получилось смотрите ниже.
Таблица Customer приведенная к первой нормальной форме
| Cust Num (Primary key) |
Name |
Street
|
| 101 |
Jones, Sue |
2 Mill Ave. |
| 102 |
Hand, Jim |
12 Dudley St. |
| 103 |
Lee, Sandy |
45 School St. |
| 104 |
Tan, Steve |
67 Main St. |
Вновь созданная, в результате нормализации, таблица Order
Order Number (Primary key)
|
Cust Num (Foreign key)
|
| M31 |
101 |
| M98 |
101 |
| M129 |
101 |
| M56 |
102 |
| M37 |
103 |
| M140 |
103 |
| M41 |
104 |
Обратите внимание, что теперь в обеих таблицах не существует дублирующих столбцов, и теперь каждый их содержит только по одному значению. При этом, связь между таблицами осуществляется по общему полю Cust Num.
Таблица, приведенная к первой нормальной форме, имеет следующие преимущества:
- Позволит вам создавать любое количество клиентских заказом без необходимости добавление новых столбцов.
- Позволит быстро выполнять запросы и сортировку данных, поскольку теперь каждое поле Order Number содержит только одно значение.
- Дисковое пространство будет использоваться более эффективно, поскольку не будут хранится пустые поля.
Вторая нормальная форма требует, чтобы не ключевые столбцы таблиц зависели от первичного ключа в целом, но не от его части. Маленькое примечание: если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме.
Таблица Customer находится в первой нормальной форме, поскольку она не имеет дублирующих столбцов, и при этом каждый из столбцов содержит только одно значение.
Cust Num
|
Name |
Street
|
Order Number |
Order Date
|
Order Amount
|
| 101 |
Jones, Sue |
2 Mill Ave. |
M31 |
3/19/05 |
$400.87 |
| 101 |
Jones, Sue |
2 Mill Ave. |
M98 |
8/13/05 |
$3,000.90 |
| 101 |
Jones, Sue |
2 Mill Ave. |
M129 |
2/9/05 |
$919.45 |
| 102 |
Hand, Jim |
12 Dudley St. |
M56 |
5/14/04 |
$1,000.50 |
| 103 |
Lee, Sandy |
45 School St. |
M37 |
12/25/0425 |
$299.89 |
| 103 |
Lee, Sandy |
45 School St. |
M140 |
3/15/05 |
$299.89 |
| 104 |
Tan, Steve |
67 Main St. |
M41 |
4/2/04 |
$2,300.56 |
Тем не менее, таблица не находится во второй нормальной форме, поскольку имеются следующие проблемы:
- Первые три поля в таблице, содержат повторяющуюся информацию в столбцах Cust Num, Name и Stree. Это называется избыточностью (redundant data).
- Если клиент Sue Jones поменяет свой адрес, то вам прийдется внести изменения в остальные поля содержащие прежний адрес. В этом случае, вы будете должны изменить три строки. Если какая-либо из строк по каким-либо причинам не будет изменена, то это приведет к противоречивости данных (inconsistent data). Таким образом целостность (integrity) базы данных будет под вопросом.
- Например, если вы решили удалить все заказы до 1 Ноября 2004 года, то в процессе вы потеряете всю информацию по клиентам Jim Hand и Steve Tan. Непреднамеренное удаление строк во время операций изменения называется аномалией (anomaly).
Для решения этих проблем вы должны переместить данные. Т.е. обратите внимание, что эта таблица, должна содержать индивидуальные данные клиентов, такие как Cust Num, Name и Street. Эти данные всегда остаются одни и те же, когда клиент оформляет заказ. Столбцы Order Num, Order Date и Order Amount не относятся на прямую к клиенту, и не зависят от первичного клича (primary key) Cust Num. Поэтому, они должны располагаться в другой отдельной таблице. Таким образом, для того чтобы привести таблицу Customer ко второй нормальной форме, вы должны переместить эти столбцы в таблицу Order.
Таблица Customer
| Cust Num |
Name |
Street
|
| 101 |
Jones, Sue |
2 Mill Ave. |
| 102 |
Hand, Jim |
12 Dudley St. |
| 103 |
Lee, Sandy |
45 School St. |
| 104 |
Tan, Steve |
67 Main St. |
Таблица Order
Order Number
(Primary key)
|
Order Date
|
Order Amount
|
Cust Num
(Foreign key)
|
| M31 |
3/19/05 |
$400.87 |
101 |
| M98 |
8/13/05 |
$3,000.90 |
101 |
| M129 |
2/9/05 |
$919.45 |
101 |
| M56 |
5/14/04 |
$1,000.50 |
102 |
| M37 |
12/25/04 |
$299.89 |
103 |
| M140 |
3/15/05 |
$299.89 |
103 |
| M41 |
4/2/04 |
$2,300.56 |
104 |
Таблица Customer теперь содержит только одну строку по каждому из клиентом, в то время как таблица Order содержит строки по каждому клиентскому заказу, и его первичный ключ (primary key) состоит из поля Order Number. Эта таблица так же содержит общий столбец Cust Num, который обеспечивает связь заказа с клиентом.
Таблица, находящаяся во второй нормальной форме имеет следующие преимущества:
- Вы cможете изменять информацию о клиенте только в одной строке
- Вы можете удалять клиентские заказы не беспокоясь, что удалите информацию о самом клиенте
- Дисковое пространство будет использоваться более эффективно, так как исключена повторяющаяся и избыточная информация.
Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы не ключевые столбцы в ней не зависели от других не ключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте - это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить.
Ниже представлена таблица Order, которая содержит столбец Total After Tax. Значение этого столбца рассчитывается на основании добавления 10% к значению столбца Order Amount.
Order Number
(Primary key)
|
Order Date
|
Order Amount
|
Total After Tax |
Cust Num
(Foreign key)
|
| M31 |
3/19/05 |
$400.87 |
$441.74 |
101 |
| M98 |
8/13/05 |
$3,000.90 |
$3,300.99 |
101 |
| M129 |
2/9/05 |
$919.45 |
$1,011.39 |
101 |
| M56 |
5/14/04 |
$1,000.50 |
$1,100.55 |
102 |
| M37 |
12/25/04 |
$299.89 |
$329.87 |
103 |
| M140 |
3/15/05 |
$299.89 |
$329.87 |
103 |
| M41 |
4/2/04 |
$2,300.56 |
$2,530.61 |
104 |
Для того чтобы привести эту таблицу к третьей нормальной форме, необходимо избавиться от столбца Total After Tax, поскольку его значение зависит от значение в столбце Order Amount, а так же от ставки самого налога, которая со временем может поменяться. А для того чтобы получить значения Total After Tax в своих отчетах, вам лучше создать небольшой алгоритм, который будет выполнять соответствующие расчеты. Или например, взять таблицу сотрудников, вам не нужно хранить в ней возраст сотрудника, поскольку в ней уже есть поле с датой его рождения, а значит вы всегда сможете вычислить его возраст с помощью простого алгоритма.
Преимущества таблицы в третьей нормальной форме заключаются в следующем:
- Эффективное использование дискового пространства, т.е. в базе не хранятся не обязательные данные, которые всегда быстро можно рассчитать.
- База содержит только обязательные столбцы – не обязательные удалены.
Хотя состояние базы данных, нормализованной до третьей нормальной формы желательно состояние, так как обеспечивается высокий уровень её стабильности, иногда, это может усложнить работы при физическом создании такой базы данных. Поэтому, в таких случаях иногда приходится прибегать к денормализации. Денормализация означает, сознательное введение избыточности в базу данных, с целью обеспечения выполнения требований по обработки этих данных. Приведу пример. В предыдущей таблице, мы удали поле Total After Tax. Но как оказалось, его значение довольно часто используется в различных отчетах, и в результате его расчета при каждом формировании такого отчета, система испытывает значительные нагрузки. Поэтому, в такой ситуации логичнее будет сохранить значение в базе данных один раз, т.е. восстановить столбец Total After Tax, так как обратиться к уже рассчитанному значению проще и быстрее. Поэтому иногда приходится жертвовать правилами нормализации для обеспечения хорошей производительности.
Далее, будут описаны оставшиеся формы нормализации до пятого уровня. Но заметьте, что это описание приведено только для общего понимания.
Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.
Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка / удаление любой строки таблицы не требовала бы вставки / удаления / модификации других строк этой же таблицы.
Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной декомпозиции таблицы, и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.
Итог: разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме.
Определение индексов
Подобно индексной странице в книге, которая позволяет быстро находить информацию по интересующей теме, в базах данных индексы так же позволяют выполнять быстрый поиск и сортировку строк с интересующей нас информацией. В принципе, искать и выполнят сортировку можно конечно и без индексов, но с индексами этот процесс будет выполняться гораздо быстрее. Их использование позволяет ограничить операции сканирования строк и исключить необходимость дополнительной сортировки полученных данных. Индексы в основном создаются для столбцов, по котором наиболее часто выполняется поиск конкретных данных и их сортировка, или же для общих столбцов, обеспечивающих связь между несколькими таблицами.
С другой стороны, индексы используют дополнительное дисковое пространство для хранения, а так же увеличивают время выполнения таких операций как ввод данных, выполнение резервного копирования, и прочих административных задач. Каждый раз, когда вы изменяете индексированный столбец, OpenEdge изменяет и сам индекс, а так же все связанные с ним индексы. Когда вы создаете или удаляете строку, OpenEdge изменяет каждый индекс в соответствующих таблицах.
Когда вы создаете индексы, помните, что создание индекса, это не только одна операция. Это целый процесс, который довольно сложно связан с методами кодирования. Не корректный код, может испортить всю схему индексации, и любой такой код запросов, может работать очень плохо, если он не эффективно будет использовать индексы. Поэтому, еще не стадии разработки, а так же на стадии развития вашего проекта, вы должны уделить особое внимание индексированию базы данных.
Попробуем понять, как же работают индексы
Как уже говорилось ранее, индексы базы данных подобны книжным индексам. Для того чтобы найти какую-либо тему, вы сначала просматриваете индексную страницу в книге, идентифицируете тему, и затем используя полученные данные о её расположении переходите на страницу с интересующей информацией. Сами по себе, индекс не содержит интересующей нас темы, он лишь указывает на нужную нам страницу с этой информацией. Если бы индекса не было, вам бы пришлось просмотреть всю книгу страницу за страницей, пока бы вы не обнаружили нужные данные.
Аналогично этому, когда вы запрашиваете конкретные данные из базы данных, её движок использует индексы для их поиска. Информация, содержащаяся в индексе, состоит из двух частей, это index key и row pointer, которая является точкой входа связанной со строкой в таблице. Ниже, представлен рисунок, иллюстрирующий это на примере таблицы Order базы данных Sports 2000.
Индексные данные, всегда отсортированы в цифровом, алфавитном или хронологическом порядке. Используя эти указатели, система всегда может получить доступ к строкам данных непосредственно и в порядке сортировки определенной индексом.
Каждая таблица, должна иметь хотя бы один индексы, primary index. Когда вы создаете первый индекс для таблицы, OpenEdge определяет его как Primary Index и устанавливает ему соответствующий флаг. На рисунке выше, индекс Order-Num является первичным индексом (primary index).
Существует четыре важных причины для создания индексов в таблице:
1. Прямой доступ и быстрый поиск строк
Строки таблицы физически хранятся в базе данных в той последовательности, в которой их вводят пользователи. Если вам нужно найти конкретную строку, движок базы данных должен сканировать каждую строку во всей таблице, пока не обнаружен одну или более строк, соответствующих заданным вами критериям. Такое сканирование весьма не эффективно и занимает довольно много времени, особенно когда таблица имеет большие размеры. Когда вы создаете индекс, все индексные указатели сохраняются отсортированными, тем самым обеспечивая быстрый поиск.
Например, когда вы запрашиваете информацию о заказе с номером 4, OpenEdge не переходит напрямую к таблице. Вместо этого, он обращается к индексу Order-Num для поиска указанного значения. Для чтения строки, он использует указатель на эту строку в таблице Order. Поскольку индекс хранится в числовом порядке, то его поиск и поиск строки выполняется очень быстро.
Аналогично, имея индекс для столбца даты, вы можете напрямую перейти к нужной дате, указанной в вашем запросе. Система использует соответствующий указатель для чтение строки, содержащей эту дату в таблице Order. Кроме того, так как индекс по дате хранится в хронологическом порядке, то доступ к нужной строке тоже будет осуществлен очень быстро.
2. Автоматическая сортировка строк
Индекс определяет сортировку строк. Так как индекс автоматический последовательно сортирует строки (вместо того порядка в котором они были созданы и сохранены на диске), вы можете быстро получать необходимые отчеты в пределах определенного диапазона дат. Например, когда вы формируете запрос, «найти все заказы сформированные с 09/06/04 по 09/20/04», все строки с такими заказами будут отображены в хронологическом порядке.
Примечание: хотя индекс и навязывает строкам определенный порядок, данные хранимые на диске, всё равно расположены в том порядке, в котором они были созданы. Т.е. индексы, не контролируют порядок расположения данных на диске. Вы можете создавать сколько угодно индексов, тем самым определяя любой порядок для отображения данных, но не хранения их.
3. Обеспечение уникальности.
Когда вы определяете уникальный индекс для таблицы, то система гарантирует, что ни какие две строки с одинаковыми значениями не могут быть созданы для этого индекса. Например, в индексе Order-Num существует значение 4, и если вы попытаетесь создать еще один заказ с номером 4, то вы получите сообщение об ошибки, информирующее вас о том, что строка с таким номером уже существует. Это произойдет, потому что Order-Num это уникальный индекс для таблицы Order.
4. Быстрая обработка межтабличных связей.
Две таблицы связаны, если вы определяете столбец (или столбцы) в одной таблице, которые вы можете использовать для доступа к строкам в другой таблице. Если таблица к которой вы обращаетесь, содержит индекс, основанный на связывающем столбце, то доступ к строке будет осуществлен более эффективно. Столбцы, которые вы используете, для связи двух таблиц, не обязательно должны иметь одинаковые названия в этих таблицах.
Но у использования индексов есть и свои недостатки. Поэтому, всегда помните две вещи при создании индекса в своей базе данных:
- Индексы поглощают дисковое пространство.
- Индексирование может замедлять работу других процессов. Т.е. например, когда пользователь изменяет индексированный столбец, то OpenEdge должен выполнить изменение всех связанных с ним индексов. Так же, когда пользователь создает или удаляет строки, OpenEdge тоже выполняет изменение всех индексов в этой таблице.
Следовательно, определяете только те индексы, которые действительно требуются вашему приложению, и не создавайте индексы, которые несут не значительную пользу или которые редко используются вообще. Например, например, если вы данные не выводите часто в конкретном порядке, например, по почтовому индексу (ZIP), то вам лучше выполнять упорядочивание таких данных в момент формирования отчета, вместо того чтобы добавлять индекс для автоматической сортировки.
Как же выбрать таблицы и столбцы, по которым нужно создать индексы?
Если вы часто выполняете добавление, удаление и изменение данных в сравнительно не большие таблицы, то не имеет смысла создавать для них много индексов, из-за того, что много индексов могут значительно снизить производительность этих операций, достаточно будет создать только один первичный индекс. Но если вы в основном вы осуществляете поиск данных по таблице, то дополнительные индексы здесь могут оказать кстати. Вы должны индексировать те столбцы, по которым наиболее часто выполняется поиск и сортировка данных.
Не нужно создавать индексы, если вы одновременно извлекаете большую часть строк из таблицы, например 19 000 из общего количества равного 20 000, так как эффект от такого индексированного извлечения будет аналогичен полному перебору таблицы. Тем не менее, создание индекса даст значительный эффект, если данные извлекаются не большими порциям, например, по 100 из 20 000 строк. В этом случае, OpenEdge будет сканировать только индексную таблицу вместо полного сканирования всей таблицы.
Индексы и ROWID
Индекс, это список из индексных значений и идентификаторов строк (ROWID). ROWID это физические указатели на таблицы базы данных, которые обеспечивают вам самый быстрый доступ к строкам. ROWID не изменяется в течении всё “жизни” строки, он может поменяться только в результате перезагрузки (dump/load) данных в базе. Так же, если вы удалите строку, и создадите, идентичную удаленной, новую строку, ROWID тоже будут отличаться. Индексные блоки базы данных для обеспечения быстрого доступа организованы в древовидную структуру. OpenEdge размещает индексы строки в пределах индексного дерева. Как только строка будет размещена, доступ к данным по ROWID будет открыт. Во время поиска строки, OpenEdge не блокирует всё индексное дерево. Блокируется только тот блок, который содержит нужную строку. Поэтому другие пользователи могут свободно обращаться к строкам, в той же самой таблице базы данных.
Расчет размера индекса
Для приблизительной оценки необходимого дискового пространства, которое займет вновь создаваемый индекс, вы можете воспользоваться следующей формулой:
Количество строк * (7 + количество столбцов в индексе + размер индексируемого столбца) * 2
Например, если у вас есть индекс для символьного столбца со средним количеством символом равным 21 (размер индексируемого столбца), и в таблице имеется 500 строк, то размер индекса будет следующим:
500 * (7 + 1 + 21) * 2 = 29,000 байт
Размер индекса зависит от четырех моментов:
- От количества вхождение или строк
- От количества столбцов в индексе
- От размера значений в столбце, т.е. строковое значение “абвгдежзиклмн” займет больше места чем строка из “абвгд”. Дополнительно, специальные символы и многобайтные символы (Unicode) так же занимают много места.
- Количества аналогичных ключевых значений.
Однако, вы ни когда не достигнете максимума, потому что OpenEdge использует алгоритм сжатия данных, для уменьшения количества дискового пространства используемого индексами. Фактически для индексов используется на 20-60%% меньше дискового пространства, чем вы вычислили по выше описанной формуле.
Процент сжатия данных зависит от самих данных. Сжимаются в основном идентичные данные и их входы сводятся к одному входу. Поэтому неуникальные индексы сжимаются лучше, чем уникальные. Сжатие ключевых значений в индексе, организовано так, чтобы как можно больше избавиться от избыточных данных. На следующем рисунке показано как OpenEdge сжимает данные.
Здесь, индекс City создан для городов, а ROWID определен в порядке возрастания. Для самого первого входа индекса “Bolonia” сжатия нет. Но для последующих данных, устраняет все символы, которые идентичны ведущим символам в слове Bolonia. Поэтому для второго входа, “Bolton”, не имеет смысла сохранять первые три символа “Bol”, так как они идентичны ведущим символам от Bolonia. В замен, Bolton сжимается до “ton”. И в последствии, OpenEdge не будет сохранять следующие входы Bolton. Аналогично, первые два символа в словах “Bonn” и “Boston” (“Bo”) тоже не будут сохранены.
Для ROWID, OpenEdge удаляет идентичные ведущие цифры. Он сохраняет последнюю цифру ROWID отдельно и объединяет ROWID, которые отличаются последней цифрой, в один вход (entry). Например здесь, OpenEdge сохраняет ведущие три цифры от ROWID 333 как ROWID, а последнюю цифру сохраняет как “nth byte”. Далее по списку обратите внимание, что первое вхождение Boston имеет ROWID 1111, а второе вхождение с ROWID 1118. Ведущие три цифры (111) от второго ROWID не сохранены, т.к. они идентичным первому ROWID, которые уже сохранены, и только последняя цифра (8) осталась в индексе.
Из-за таких особенностей сжатия, OpenEdge может существенно уменьшить количество пространства, используемого индексами. В выше приведенном примере, для индекса используется всего 65 байт, вместо расчетных 141 байт. Т.е. сэкономлено примерно 54% дискового пространства. Таким образом, мы видим, что используемое индексами дисковое пространство зависит от данных напрямую. И с не уникальными индексами вы можете сэкономить больше.
Устранение избыточных индексов. Если два индекса, содержат одинаковые компоненты расположенные в том же порядке для одной и той же таблицы, то такие индексы называются избыточными. Избыточные индексы, занимают место, и замедляют работу, при этом не неся полезной нагрузки. От таких индексов нужно избавляться.
Индексы, которые редко используются, могут вызвать ухудшение производительности. Но иногда бывают ситуации, когда вы не хотели бы их удалять. Поэтому у вас есть возможность деактивировать их. Но имейте ввиду, деактивация индексов приведет к улучшению работы, но не уменьшит используемое пространство.
Физический проект базы данных
Физический проект базы данных, это завершающая стадия логического проекта. В этой стадии, вы определяете как пользователи будут обращаться к базе. Здесь вы должны задать себе, и ответить на следующие вопросы:
- Как обычно будут использоваться данные?
- Какие столбцы в таблицах нужно проиндексировать для доступа к этим данным?
- Нужно ли учитывать гибкость и рост базы данных?
- Нужно ли де-нормализовать базу данных для улучшения производительности?
Возможно, что на этом этапе вам придется де-нормализовать базу данных чтобы удовлетворить требованиям производительности. Как только вы завершите физический проект, вы будете должны определить как спроецировать базу данных на ваши аппаратные средства. Поддержание работоспособности физической базы данных, это есть первичная задача и ответственность администратора базы данных. В следующее главе будет обсужден вопрос физической организации OpenEdge баз данных.
СУБД Progress OpenEdge
Управляя OpenEdge базой данных, важно понимать её архитектуру и настройки конфигурации, которые она поддерживает. Данная глава содержит информацию о базе данных OpenEdge версии 10.
Структура базы данных
OpenEdge база данных состоит из множества компонентов, которые проиллюстрированы на приведенном ниже рисунке. Описание каждого из них будет приведено далее.
Файл описания структуры (.st), содержит описание структуры базы данных. Это текстовый файл, который имеет расширение .st. Информацию, которую он содержит, использует административная утилита PROSTRCT CREATE для создания областей хранения и их экстентов. За создание .st файла несет ответственность администратор базы данных.
Журнал событий базы данных (далее лог - файл). Это текстовый файл с расширение .lg. Файл содержит информацию о значимых для базы данных событиях, включая запуск и останов сервера, подключение и отключение пользователей, и прочая информация о действиях с базой данных.
Контрольная область базы данных, или Control Area. Это один бинарный файл с расширением .db, который содержит информацию у структуре экстентов базы данных. Контрольная область и ее .db файл, работают как таблица оглавления для движка базы данных, которая содержит имя и размещение каждой области и её экстентов в базе.
Область Primary Recovery или Before image. Она может состоять из одного или более экстентов, каждый файл которой имеет расширение .bn. Файл BI содержит заметки о всех изменениях в данных. В случае возникновения какого-либо сбоя, движок базы данных использует эти заметки для отката не завершенных транзакций, тем самым обеспечивая целостность базы данных.
Область Schema Area. Эта область содержит минимум один экстенты переменной длинны, файл которого имеет расширение .dn. Область содержит мастер блок и sequence блоки, а так же таблицы схемы и индексы. Рекомендуется размещать все данные ваших приложений в отдельных областях хранения, в противном случае, все пользовательские данные будут храниться в этой области, что по определенным причинам затрудняет управление этими данными.
Дополнительные области хранения данных. Дополнительная область может содержать от одного до нескольких экстентов как переменной, так и фиксированной длины, файлы этих экстентов имеют расширение .dn. Эти области предназначены для хранения пользовательских данных, таких как таблицы, индексы, BLOB или CLOB.
Другая дополнительная, но не обязательная область, это After-Image Area (.ai), экстенты этой области имеют расширение .an, и могут быть как фиксированной, так и переменной длины. Области необходимы для работы механизма After-imaging. В случае возникновения системного сбоя, благодаря этой области, вы сможете восстановить базу данных на любой момент времени.
Область Transaction Log (.tl), используется если активирован механизм Two-Phase Commit. Она может состоять из одного и более экстентов фиксированной длины, которые имеют расширение .tn. Экстенты переменной длинны этой областью не поддерживаются. Transaction Log содержит информацию по завершенным транзакциям механизма two-phase commit.
OpenEdge база данных это и есть все перечисленные файлы вместе взятые: Control Area, Schema Area, области данных, файлы восстановления, файлы журналов. Все они должны рассматриваться как неделимое целое. Т.е. фраза “создать резервную копию базы данных” означает, что необходимо резервировать все данные базы, включая .lg, .dn, .tl, .ai и .bi файлы.
Во время эксплуатации базы данных, вы наверняка столкнетесь с другими файлами, которые используются базой данных. Список таких файлов приведен в следующей таблице:
Файл
|
Описание
|
| .abd |
Архивный бинарный дамп данных аудита |
| .bd |
Файл бинарного дампа данных (таблиц) |
| .bld |
Файл данных для BLOB или CLOB |
| .cf |
Файл кеша схемы (Schema Cashe) |
| .cp |
Файл содержащий двоичный код скомпилированной кодовой страницы |
| .dfsql |
Описание данных в SQL формате |
| .dsql |
Дамп данных в SQL формате |
| .d |
Дамп таблицы в ABL формате |
| .df |
Описание данных в ABL формате |
| .fd |
Файл описания для ABL bulkload |
| .lic |
Файл лицензии |
| .lk |
Файл блокировки |
| .repl.properties |
Файл настроек OpenEdge Replication |
| .repl.recovery |
Файл OpenEdge Replication, содержащий информацию о состоянии копирования |
| .rpt |
Файл отчета об использовании лицензий |
Архитектура OpenEdge
На текущий момент, архитектура OpenEdge баз данных известна по название Type II. А до версии 10 поддерживалась архитектура Type I. Версия 10 по прежнему поддерживает архитектуру Type I, но имейте ввиду, что Type II обеспечивает наибольшее преимущества по отношению к прежней архитектуре как по эффективности хранения данных, так и по эффективности доступа к ним. Поэтому, ваше решение о необходимости перехода на использование архитектуры Type II, не должно подвергаться ни каким сомнениям.
Архитектура Type II состоит из следующих элементов, которые и будут описаны в этой главе:
- Области хранения (Storage areas)
- Экстенты (Extents)
- Кластеры (Clusters)
- Блоки (Blocks)
Области хранения
Области хранения это набор файлов физически расположенных на диске. Область хранения это самое большое физическое устройство базы данных. С их помощью вы можете физически управлять размещением объектов базы данных: вы можете разместить каждый объект базы в своей собственной области или разместить множество однотипных объектов базы в одной области хранения или разместить в ней все объекты базы. Но к сожалению, вы не можете размещать таблицу или индекс сразу в нескольких областях хранения. Но при необходимости, из-за больших размеров этих объектов, вы можете использовать множество экстентов области хранения.
Некоторые области имеют определенные ограничения по типам экстентов которые они поддерживают. Например, экстенты области Transaction Log, используемые механизмом two-phase commit, могут быть только фиксированной длины. Другие области хранения могут использовать множество экстентов фиксированной длинны и только один экстент переменной длинны, который должен быть последнем в списке экстентов этой области.
Области хранения определяются по их именам. Количество и типы областей хранения зависят от базы данных, и могут отличаться даже у баз имеющих одинаковое назначение. Тем не менее, все они, обязательно содержат такие области как Control Area, Schema Area и Primary Recovery Area. Краткое назначение каждой области приводится далее.
Control Area
Control Area содержит только один экстент переменной длины. Это бинарный файл с расширением .db. Он содержит таблицы _area и _area-extent, которые указывают на имя каждой области в базе данных, а так же на ее размещение и на размеры каждого из ее экстентов.
Schema Area
Эта область может состоять из такого количества фиксированных экстентов какое вам необходимо, тем не менее, как мы уже знаем, каждая область должна содержать один экстент переменной длины, являющийся последним в списке экстентов. Область хранит всю системную и пользовательскую информацию, а так же любые другие объекты, которые не были закреплены за отдельной областью хранения. Если вы не создадите дополнительных областей хранения, то все объекты базы данных, включая секвенции (sequences), будут размещаться в области Schema Area.
Primary Recovery Area. Область может содержать сколько угодно экстентов фиксированной длинны, но последний экстент так же должен быть переменным. Область Primary Recovery так же называется Before-image Area, поскольку в её файлы (.bn) записываются все изменения в данных. В случае сбоя базы данных, сервер базы воспользуется содержимым этих файлов для того чтобы выполнить восстановление (crash recovery) во время следующего запуска базы данных. Crash recovery, это процесс отмены (отката) не завершенных транзакций.
Application Data Area. Application data area, это область содержащая все связанные с приложением объекты базы данных. Создавая множество различных таких областей, вы можете улучшать производительность за счет размещение различных объектов на различных дисках. Каждая такая область хранения может содержать один и более экстентов с расширением .dn.
After-Image Area. Область After-image является не обязательной, и может состоять из множества экстентов фиксированной или переменной длинны. After-image (AI) файлы используются для наката на базу данных всех изменений сделанных с момент формирования последней резервной копии. Если потеря данных для вашего бизнеса является критичным, то вам следует включить механизм After-imaging.
Transaction Log Area. Область Transaction Log необходима если включен механизм two-phase commit. Он может состоять из одного или множества экстентов фиксированной длинны, файлы которых имеют расширение .tn. Экстенты переменной длины этой областью не поддерживаются.
Основные принципы размещения областей хранения
Когда вы будете решать, как и где разместить новую область хранения, то следующие утверждения помогут вам определиться:
- Чтобы защитить себя и базу от дисковых сбоев, область After-Image лучше разместить на физическом диске, отдельно от тех дисков, которые используются областями базы данных Control Area и Primary Recovery.
- Так же, можно улучшить производительность за счет размещения области Primary Recovery на диске, отдельном от дисков на которых размещены область Control Area и ее экстенты.
- Если вы собираетесь использовать механизм two-phase commit, то для упрощения управления им, область Transaction Log стоит разместить в том же каталоге, где расположена область Control Area.
Экстенты
Экстенты, это файлы на диске, которые хранят физические блоки объектов базы данных. Они позволяют базе данных OpenEdge расширяться на более чем одну файловую систему или физические тома (physical volume).
Существует два типа экстентов: фиксированной и переменной длины (размера). С помощью экстентов фиксированной длинны можно контролировать занимаемое им пространство на диске, указав в .st файле для каждого из них максимально допустимый размер. В противоположность им, экстентам переменной длины предварительно не ограничивается размер в .st файле, и их размер будет расти до тех пор, пока не будет использовано все доступное пространство на диске или пока не будет достигнуто ограничение на размер файлов в файловой системе.
Кластеры
Кластер, это выделенное непрерывное пространство для одного типа объекта базы данных. Кластеры данных значительно уменьшают фрагментацию и позволяют базе данных более эффективно использовать файловую систему.
Кластеры данных настраиваются для каждой области данных. При этом размер кластера действует на все экстенты этой области. Минимально возможный размер кластера равен 8 блоков. Но вы можете увеличить его, указав для области 64 или 512 блоков на кластер. Все блоки в пределах кластера данных будут содержать один тип объекта. High-water mark для экстента каждый раз увеличивается на размер кластера.
В архитектуре Type I, блоки размещались по одному. В архитектуре Type II, за один раз размещается целый кластер состоящий из множества блоков. В этой архитектуре, данные поддерживаются на уровне кластера, и блоки содержат данные связанные только с одним конкретным объектом. В версии OpenEdge 10 существуют области, использующие архитектуру Type I, такие как область Schema Area. Вновь создаваемые области могут использовать обе архитектуры, по умолчанию же они используют архитектуру Type I. Для того, чтобы создать новую область с архитектурой Type II, вам нужно указать размер кластера данных для области в структурном файле, равным 8, 64 или 512 блоков, по умолчанию он равен 1, т.е. Type I.
Блоки
Блок, это самое маленькое устройство в базе данных. В базе существует множество различных типов блоков. Основные действия с ними в базе данных выполняются в автоматически в фоновом режиме. Однако, вам будет полезно знать, как эти блоки хранятся в базе, для того чтобы вы могли наиболее оптимально создавать и настраивать свои базы данных.
Большая часть блоков базы данных может быть разделена на три группы:
- Блоки данных (data blocks)
- Индексные блоки (index blocks)
- Прочие типы блоков
Блоки данных
Блоки данных, это основные и наиболее распространенные блоки в базе данных. Существует два типа этих блоков, это: RM блоки и блоки RM цепочки (RM chain blocks). Единственное различие между ними заключается в том, что RM блоки считаются полностью заполненными, а блоки RM цепочки заполнены не до конца. Их внутренняя структура абсолютно одинаковая. Оба типа блоков являются общими. Общие блоки (Social blocks) могут содержать записи из различных таблиц. Другими словами, RM блоки предназначены для информации из множества таблиц, которая может быть размещена в одном блоке. В противоположность этому, индексные блоки содержат только индексные данные для одного индекса только одной таблицы.
Количество записей, которые можно сохранить в одном блоке, это настраиваемое значение в пределах области хранения. О том как это его рассчитать, будет рассказано далее в этой книге.
Каждый RM блок содержит четыре типа различной информации, а именно:
- Заголовок блока (block header)
- Записи (Records)
- Поля (Fields)
- Свободное пространство (Free space)
Заголовок блока содержит: адрес блока (dbkey), тип блока, тип цепочки (chain type), счетчик резервного копирования (backup counter), адрес следующего за ним блока, счетчик изменений (используется для изменения схемы), указатели свободного пространства (free space pointers) и указатели на записи (record pointers). Для областей хранения Type I, размер заголовка блока равен 16 байт. А для областей Type II, размер заголовка переменный, т.е. заголовки первого и последнего блоков в кластере равным 80 байт, а все остальные заголовки внутри кластера имеют размер 64 байта. Каждая запись содержит указатель фрагмента (fragment pointer), который используется указателями записи в индивидуальных полях, таких как, в поле размера записи (Length of Record) и в поле Skip Table (используется для увеличения поля для улучшения поиска). Каждой записи минимум необходимо 15 байт памяти для хранения, и содержит поле Length, поле Miscellaneous Information и сами данные.
Формат RM блока приведен на следующем рисунке:
Индексные блоки
Индексные блоки содержат ту же самую заголовочную информацию что и блоки данных, а так же у них те же самые требования к их размеру, т.е. 16 байт для Type I и 64 или 80 байт для областей хранения Type II. Индексные блоки могут хранить столько информации, сколько поместится в блоке, а так же эта информация для большей эффективности сжимается в нем. Как говорилось ранее, индексный блок может содержать информацию связанную только с одним конкретным индексом.
Индексы используются для того, чтобы быстро находить записи в базе данных. Каждый индекс в OpenEdge RDBMS, это структурированное B-дерево, которое всегда находится в сжатом состоянии. Это уменьшает необходимость сравнения ключей, что приводит к улучшению производительности. База данных может содержать до 32 767 индексов. Каждое B-дерево начинается от корня (root). А корень хранится в виде записи в системной таблице _storageobject. Для обеспечения большей эффективности, индексы являются многопоточными, тем самым предоставляется параллельный доступ к ним. Ускорение происходит за счет того, что при доступе к B-дереву блокируются не всё дерево, а только те узлы (их еще называют “листья” или nodes), которые требуются процессу в текущий момент.
Прочие типы блоков
Существуют еще несколько типов блоков, которые стоит описать для обеспечения наилучше понимания базы данных. Эти блоки следующие:
- Мастер блоки (Master blocks)
- Блоки объектов хранения (Storage object blocks)
- Свободные блоки (free blocks)
- Пустые блоки (Empty blocks)
Мастер блок содержит те же 16 байт заголовочной информации как и другие блоки, но этот блок используется для хранение данных о статусе всей базы данных. Он всегда является самым первым блоком в базе данных и размещается в области с номером 6, т.е. в Schema Area, которая всегда имеет тип Type I. Он содержит такие данные как, номер версии базы данных, общее количество размещенных блоков, временную метку и статусные флаги. Для излечения дополнительной информации из мастер блока, вы можете воспользоваться виртуальной системной таблицей (VST) _mstrblk.
Блоки объектов хранения (storage object blocks) содержат адреса первой и последней записей для каждого индекса таблицы. Поэтому, когда пользователь запускает программу, которая запрашивает первую или последнюю запись в таблице, то нет необходимости использования индекса. Вместо этого, движок базы данных получает информацию из блока объектов хранения и непосредственно переходит к записи. Блоки объектов хранения очень часто используются, поэтому они всегда находятся в памяти, что обеспечивает улучшение эффективности запросов.
Свободные блоки (free blocks) имеют заголовок, но они не содержат данных внутри. Такие блоки предназначены для формирование других возможных блоков в базе данных. Они всегда расположены ниже уровня high-water mark. High-water mark, это указатель на последний отформатированный блок в пределах области хранения базы данных. Свободные блоки могут быть созданы автоматически когда уровень high-water mark поднимается, когда база данных растет (расширяется) или когда происходит переформатирование боков во время перестройки индекса. Если пользователь удаляет множество записей, то RM блоки помещаются в RM цепочку. Однако, индексные блоки могут быть восстановлены только через перестройку индекса или через сжатие индекса.
Пустые блоки (empty blocks) не содержат заголовочной информации. Поэтому, перед использованием они должны быть отформатированы. Они располагаются выше уровня high-water mark, но ниже общего количества блоков в области хранения. Общее количество блоков (total blocks), это общее количество размещенных блоков в области хранения.
Проектирование областей хранения
Проект областей хранения в OpenEdge RDBMS делится на две части, а именно, на физическую и логическую модели. У вас есть возможность управлять физической моделью с помощью ABL, OpenEdge SQL, а так же с помощью административных утилит. На следующем рисунке показано, как области могут размещаться и распределяться между файлами. Обратите внимание, что экстенты областей могут быть размещены во множестве файлах на разных дисках, но в то же время, каждый экстент может быть связан только с одной областью.
Физическая модель областей хранения:
Логическая модель хранения перекрывает физическую модель. Логические объекты базы данных описаны в схеме базы и включают таблицы, индексы и секвенции, которыми манипулирует ваше приложение. На следующем рисунке показано, как логические объекты распределяются в пределах физической модели.
Логическая модель хранения:
Создавая оптимальные области хранения и соответствующие связи между ними и объектами, вы тем самым повышаете уровень производительности вашей базы данных. Вы можете размещать по одному объекту в каждой области хранения, а можете наоборот комбинировать различные объекты в одной области. Информация из следующей таблице поможет вам определиться с этим вопросом.
Если база данных содержит…
|
То вы должны…
|
| Много больших или часто обновляемых таблиц. |
Создать область хранения для каждой такой таблицы. Это позволит вам
легче выполнять администрирование и улучшит производительность. |
| Много маленьких таблиц |
Создайте области хранения для представления конкретных предметов
(например, Sales, Inventory и т.п.), и разместите в них связанные с
этим предметом таблицы. Это обеспечит вам легкое администриование. |
| Смесь больших и маленьких таблиц |
Используйте две вышеописанные рекомендации |
| Много индексов для больших или часто изменяемых таблиц |
Создайте область хранения для каждого индекса. Это обеспечит вам
гибкость в администрировании и потенциально улучшит производительность |
| Множество маленьких индексов |
Создайте области хранения для индексов, принадлежащих объектам из общей группы. Это обеспечит вам простоту администрирования |
Определение параметров конфигурации
Архитектура OpenEdge RDBMS и широкий диапазон поддерживаемых ею платформ, предоставляет вам различные опции конфигурирования. Самая простая конфигурация может поддерживать только одного пользователя на обычном персональном компьютере. Более сложные могут входить в состав гетерогенных сетевых систем, поддерживая работу сотен и тысяч пользователей, которые работают с множеством баз данных, включая и базы данных OpenEdge.
Требования вашего бизнеса определяют выбор для таких переменных окружения как:
- Системная платформа
- Режимы подключения
- Тип клиентов
- Размещение базы данных
- Подключения к базе данных
Далее будет описано как эти переменные могут влиять на вашу конфигурацию.
Системные платформы.
OpenEdge RDBMS поддерживает многопоточный сервер базы данных, который способен обслуживать множество сетевых клиентов. Каждый такой сервер может обрабатывать множество одновременных запросов от этих клиентов. Чтобы обеспечить быстрый ответ на простые запросы, процесс сервера обрабатывает их как одну операцию, т.е. происходит деление сложных запросов на более маленькие задачи, чтобы минимизировать их влияние на других пользователей базы данных. Для того чтобы удовлетворить требованиям любой конфигурации, OpenEdge поддерживает большое разнообразие аппаратных и программных платформ.
Режимы подключения
OpenEdge база данных может быть запущена в одном из двух режимов подключения: в однопользовательском (single-user) и в многопользовательском (multi-user). Эти режимы определяют, какое количество пользователей может получить одновременный доступ к базе данных.
База данных, запущенная в однопользовательском режиме, поддерживает только одного пользователя, который может получить доступ к ней в один момент времени. Если в это время к базе будет подключен другой пользователь, то вы не сможете получить к ней доступ из другой сессии.
Такой доступ может вам понадобиться, например, для выполнения некоторых административных задач, которые требуют получения эксклюзивного доступа к базе данных.
База данных, запущенная в многопользовательском режиме обеспечивает одновременный доступ к ней более чем одному пользователю. Брокер координирует все запросы на подключение к базе данных, а сервер извлекает и сохраняет данные от имени этих клиентов. Чтобы предотвратить запуск второго брокера или от её открытия однопользовательским процессом, брокер блокирует базу данных на время своей работы.
Когда клиент запускается в фоновом режиме (batch mode), то вся работа выполняется без взаимодействия с пользователем. Такой режим удобен для выполнения крупномасштабных изменений в базе данных или для автоматически запускаемых процедур. В фоновом режиме могут работать как однопользовательские, так и многопользовательские процессы. Интенсивное использование многопользовательских фоновых процессов, может отрицательно сказаться на времени ответа на запросы интерактивных пользователей, поэтому запуск таких процессов лучше планировать на время, когда наблюдается наименьшая активность в базе данных, за частую, этим временем является ночь.
Когда клиенты работают в интерактивном (диалоговом) режиме, они непосредственно взаимодействуют с приложением подключенным к базе данных. Так же как и для фонового режима, в интерактивном режиме могут работать как однопользовательские, так и многопользовательские процессы.
Типы клиентов
OpenEdge поддерживает как самообслуживающихся (self-service), так и сетевых клиентов.
Самообслуживающийся клиент, это многопользовательская сессия, которая запущена на той же машине где и брокер базы данных. Такие клиенты получают доступ к базе данных напрямую через разделяемую память (shared memory) и не используют сервер. Самообслуживающиеся клиенты в одном процессе исполняют функции как сервера, так и клиента, поскольку код сервера это часть самообслуживающегося клиента. Движок базы данных обеспечивает этим клиентам практически одновременный доступ к базе данных.
Сетевые клиенты (network client) могут быть локальными (local) и дистанционными (remote), но поскольку они не могут напрямую обращаться к базе данных, они для этих целей используют сервер базы. Эти клиенты обращаются к базе данных через запущенный брокером процесс сервера. Сетевые клиенты ни каким образом не могут обратиться напрямую к разделяемой памяти базы данных, вместо этого за них это делает сервер.
Размещение базы данных
OpenEdge база данных может быть или локальной (local), или дистанционной (remote). База данных, которая расположена на той же машине, что и сессия приложения, называется локальной. А база данных, которая расположена на машине, доступ к которой приложением осуществляется через сеть из другой машины, называется дистанционной (remote).
Подключения к базе данных
Для подключения пользователя к более чем одной базам данных, существует две базовые конфигурации:
Федеративная (federated) – это когда все базы данных являются локальными. Следующий рисунок демонстрирует федеративные связи баз данных.
Распределенная (distributed) – это когда одна или более баз данных находятся на одной или более дистанционных машинах в сети, и OpenEdge сессии подключаются к ним с помощью сетевого протокола. Следующий рисунок демонстрирует распределенные связи баз данных.
Многоуровневая конфигурация (multi-tier configuration) – это более сложная модель, чем федеративная и распределенная. Она состоит из уровня базы данных, который поддерживает самообслуживающихся клиентов, прикладного уровня, который поддерживает дистанционных клиентов и уровня “тонких” клиентов. Такая конфигурация может обеспечить улучшение производительности для больших систем. Следующий рисунок демонстрирует пример многоуровневой конфигурации.
Архитектура OpenEdge RDBMS обеспечивает различные пути к базе данных. Каждый самообслуживающийся клиенты может получить доступ к базе и обсуживать самостоятельно свои запросы. Каждый сетевой сервер, может выполнять запросы от одного и более сетевых клиентов. Брокер базы данных, инициализирует разделяемую память, и запускает новый сервер для каждого дополнительного клиента или набора клиентов для обеспечения их доступом к базе данных. Иногда сервера могут стать узким местом в архитектуре OpenEdge, поэтому избавившись от них, т.е. сделав всех клиентов самообслуживающимися, вы можете улучшить производительность системы. Но такой подход не всегда приветствуется, поскольку дистанционные сервера, так же часто бывают весьма полезны, например, с точки зрения надежности системы.
Абсолютные и относительные пути базы данных
OpenEdge база данных может использовать как относительный так и абсолютный пути:
База данных с относительным путем – это самая простая форма базы. Она состоит из минимального количества файлов и хранит все экстенты базы данных в той же самой директории где расположена Control Area, которая содержит относительные пути ко всем экстентам. Вы можете использовать базу данных с относительным путем в следующих ситуациях:
· Когда база данных в целях демонстрации должна быть открыта через сеть.
· Когда база данных должна быть скопирована инструментальными средствами операционной системы, как при установке демонстрационной базы данных.
· Когда база данных это мастер база данных, которая должна быть связана с новым приложением базы данных.
Для создания базы данных с относительными путями из empty базы данных используется утилита PRODB. Если вы воспользуетесь утилитой PROSTRCT с классификатором LIST после создания базы данных с относительным путем, то вы увидите, что каждый ее экстент начинается с точки. Точка, это индикатор относительного пути.
Чтобы сделать базу с относительным путем работоспособной, в нее должна быть загружена схема. Для этого может быть использована любая стандартная техника, например такая как, Dump и Load или PROCOPY. База данных содержит относительные пути до тех пор, пока ее структура не будет изменена. Как только в нее будут добавлены новые области или дополнительные экстенты, он превратится в базу данных с абсолютным путем.
База данных с абсолютным путем – такая база данных используется в промышленной среде. Ее экстенты могут располагаться где угодно в системе. Поэтому, Control Area содержит абсолютные пути каждого экстента базы данных. База данных с абсолютными путями не может быть скопирована средствами операционной системы. Для обеспечения правильность резервного или обычного копирования, предпочтительно пользоваться утилитами PROBKUP или PROCOPY.
Планирование административных задач
Как администратор базы данных, вы должны поддерживать и управлять вашей OpenEdge базой. Хорошо спланированная база данных может упростить вашу работу, уменьшая затрачиваемое время на поддержку её структуры. Далее будет рассказано о том, как это сделать.
Формат данных
Качественный проект базы данных весьма необходим, поскольку все данных исходят из областей хранения. Вам необходимо рассмотреть следующие важные факты:
- База данных состоит из областей хранения
- Каждая область хранения содержит один или более объектов
- Объекты базы данных это таблицы или индексы.
- Существуют другие объекты, такие как секвенции и схема. Размещением этих объектов вы не можете управлять.
- Каждая область хранения может состоять из одного или более экстентов, которые могут размещаться на различных дисках.
- Экстент является физическим файлом, хранящимся на уровне операционной системы.
- Каждый экстент состоит из блоков, вы можете определить размер блока для вашей базы данных. Размер может быть выбран из следующих значений: 1Кб, 2Кб, 4 Кб и 8Кб
- Вы можете использовать только один размер блока для всей базы данных, но каждая область может иметь различное количество записей в блоке (records per block – RPB).
Существует несколько моментов, которые необходимо рассмотреть для определения формата базы данных. Первое о чем стоит подумать, это размер записи. Его легко узнать, если у вас уже есть действующая база данных. И получить его можно сформировав анализ базы данных (dbanalys), который будет содержать эту информацию. Для получения другой информации, вы должны ответить на некоторые вопросы, и в основном, администратору базы данных это не так уж и легко сделать, поскольку здесь требуется знать как приложение использует базу. Иногда, даже сами разработчики приложения не могут четко сказать, как пользователи используют преимуществами проекта. Вопросы, на которые нужно ответить, следующие:
- Доступ к таблицам осуществляется последовательно или произвольно?
- Таблица используется часто или она является архивной, а потому используется редко?
- Пользователи обращаются к таблице в течении всего дня или только для формирования отчета?
- Конкретные записи имеют свойство расти или они в основном статичны по размеру?
Ответы на эти вопросы помогут вам определить размер и формат базы данных, и обеспечат наилучше использование всех преимуществ ваших дисков.
Расчет необходимой памяти для базы данных
Движок базы OpenEdge сохраняет все поля и индексы базы данных в формате переменной длинны, и не сохраняет конечные пробелы в символьных полях и ведущие нули в числовых полях. Выгоды от такой методики хранения следующие:
- Уменьшается использовании дисковой памяти
- Приложению проще выполнять изменения, так как вы можете увеличить максимальное пространство памяти для поля без того, чтобы выполнять копирование или полную реструктуризацию базы данных. Вы можете размещать больше символов во вновь создаваемой записи, не влияя на существующие записи.
Ниже приведена таблица, которая содержит формулы для расчета размера полей в байтах для различных типов данных.
Тип данных ABL
(аналог в SQL)
|
Значение
|
Размер поля в байтах
|
CHARACTER
(VARCHAR) |
Символьная строка |
1 + количество символов, за исключением конечных пробелов. Если количество символов больше чем 240, то вместо 1 прибавляйте 3. |
DECIMAL
(DECIMAL или NUMERIC)
|
Zero
Nonzero
|
1
2+(# significant digits + 1)/2
|
INTEGER
(INTEGER)
|
1 - 127
128 – 32 511
32 512 – 8 323 071
8 323 072 – 2 147 483 647
|
1
2
3
4
|
INT64
(BIGINT)
|
1 - 127
128 – 32 511
32 512 – 8 323 071
8 323 072 – 2 147 483 647
2 147 483 648 – 545 460 846 591
545 460 846 592 - ~139 636 000 000 000
~139 636 000 000 000 -
~35 750 000 000 000 000
Более чем ~35 750 000 000 000 000
|
1
2
3
4
5
6
7
8
|
DATE
(DATE)
|
Дата |
Так же как в INTEGER
Дата хранится как целое число, которое представляет количество дней
начиная с базовой даты, определенной как начало координат для типа DATE
в ABL
|
| DATE-TIME |
Дата и время |
DATE + 4
|
DATE-TIME-TZ
|
Дата, время и временная зона |
DATE + 8 |
LOGICAL
(BIT)
|
False
True
|
1
2
|
Рассмотрим пример расчета размера таблицы, представив, что мы имеем базу данных с одной таблицей и тремя полями:
- Cust-num – целочисленное поле, которое всегда содержит три цифры.
- Name – символьное поле, содержащее от 12 до 30 символов, в среднем 21 символ.
- Start-date – поле даты.
Таблица проиндексирована по одному полю (Name) и содержит примерно 500 000 записей. На следующей таблице приведены формула расчета её размера.
| Компонент базы данных |
Размер
|
| Память для полей |
= Cust-num + Name + Start-date
= 3 + 21 + 3
= 27 |
| Таблица |
= количество записей x память для полей x 1.5
= 500,000 x 27 x 1.5
= 20,250,000 |
| Индекс Name |
= количество записей x (7 + количество полей в индексе + память для полей ) x 2
= 500,000 x (7 + 1 + 21) x 2
= 29,000,000 |
Эти формулы консервативны, обычно результат их расчета соответствует размеру вашей базы данных.
Когда вы планируете размер базы данных, используйте формулы из следующей таблицы для приблизительного расчета дискового пространства в байтах, необходимых базе данных.
| Размер |
Формула |
| Размер базы данных |
schema size + data table size + index size. |
| Размер схемы |
Обычно, от 1 до 100 Мб. Для точного определения размера схемы, создайте
empty базу данных, и загрузите в нее свою схему, проверьте получившийся
размер базы, это и будет размер вашей схемы. |
| Размер таблиц данных |
Сумма размеров конкретных таблиц |
| Размер конкретной таблицы |
количество записей х память для полей х 1.5 |
| Размер индекса |
Сумма размеров конкретных индексов |
| Размер конкретного индекса |
количество записей в индексируемой таблице х (7 + количество полей в индексе + память для полей) х 2 |
Вы так же должны учитывать дисковое пространство, которое будет использоваться базой данных для временных целей, а именно:
- для сортировки (обычно это пространство, необходимое таблице, помноженное на два)
- временной пространство для Primary Recovery Area (BI)
- хранение Before-Image данных
- хранение After-image данных
Установка размеров для областей хранения
При попытке определить размер области, вы должны посмотреть на характер информации, которая загружена в эту область. Как утверждалось ранее, область может содержать одну или более таблиц и/или индексов. Для упрощения различных преобразований в будущем, по умолчанию область создается с зарезервированным пространством под схему и определение секвенций. Первым шагом в этом процессе, если у вас есть готовая база данных, вы должны сделать табличный анализ области с помощью утилиты PROUTIL с классификатором TABANALYS. Следующий пример показывает часть результата такого анализа.
Здесь вы должны обратить внимание на столбцы количества записей (Records) и средний размер записи (Mean). Просмотрите все таблицы и разделите их на группы по среднему размеру записи. Каждая запись в таблице содержит примерно по 20 байт дополнительной памяти (record overhead), которая включена в результат вычисления среднего размера.
Размер блока
Размер блока, в подавляющем большинстве случаев, имеет значение для Unix систем равное 8Кб, а для Windows – 4 Кб. И обычно, для обеспечения наилучшей производительности, он должен соответствовать или быть кратным размеру блока файловой системы. Старайтесь придерживаться этого утверждения. Такое соответствие размера блока базы размеру бока файловой системы позволит значительно избежать лишние операции ввода/вывода (I/O), примером этому может послужить следующий рисунок:
В Windows, операционная система предполагает, что файлы и память разбиты на куски по 4Кб. Это означает, что все перемещения между диском и памятью будут осуществляться по 4Кб. Операционная система Windows сильно оптимизирована под использования 4Кб блоков, и ее производительность уменьшится, если выбрать размер блока 8Кб.
В Unix подобных операционных системах, обычно размер блока равен или кратен 8Кб. Поэтому, размер блока можно настраивать. Но обычно, размер блока равный 8Кб, это лучшее решение в таких системах.
Конечно, в каждых правилах есть исключения, поэтому ваши действия должны заключаться в том, что бы выполнить оценку производительности при различных размерах блоков для вашей системы, и выбрать наилучшее значение.
Количество записей в блоке (Records Per Block – RPB)
OpenEdge позволяет вам указывать максимальное количество записей, которое может быть размещено в одном блоке области. Значение может быть установлено от 1 до 256. Количество записей в блоке должно быть кратно двум. В зависимости от фактического размера вашей записи, возможно, что максимальное значение количества записей в блоке не сможет быть достигнуто.
Для того, чтобы определить количество записей в блоке нужно:
1. взять средний размер записи из табличного анализа базы данных (tabanalys)
2. добавьте к этому размеру 2 для directory entry overhead. Средний размер включает record overhead, но в него не включен directory entry overhead.
3. для блока с размером 8Кб, разделите 8192 на число из шага 2. Для блока 4Кб, делите 4096 на число из шага 2.
4. округлите полученной число из шага 3, до ближайшего значения кратного двум.
В большинстве случаев, длина записи не будет делиться на полученной значение из шага 4, поэтому, вам придется подбирать наилучшее значение. Если вы определите слишком много записей в блоке, то можете подвергнуться риску фрагментации (когда одна запись распределена между несколькими блоками). Если же вы определите слишком мало записей в блоке, то вы можете просто впустую тратить некоторое пространство внутри блока. Так как оно не будет заполняться. В результате, вам необходимо подбирать оптимальное значение на сколько это возможно, но в то же время, нужно следить, чтобы ваша структура базы данных не оказалась слишком сложной.
Пример расчета RPB
Следующий пример демонстрирует, как определить наилучшее значение для RPB.
1. допустим, что из табличного анализа (tabanalys) мы извлекли следующую информацию:
a. база данных содержит 1 миллион записей;
b. средний размер записей равен 59 байт.
2. добавляем directory entry overhead (2 байта) для определения актуального размера хранимых записей:
Mean record size + overhead = actual storage size
59 + 2 = 61
3. Разделите полученным числом размер блока базы данных, для определения оптимального RPB:
Database block size / actual storage size = optimal records per block
8192 / 61 = 134
4. Вот здесь, вам придется принимать решение. Вы должны выбрать ближайшее значение кратное 2 в пределах от 1 до 256. В данном случае у вас есть два выбора: 128 и 256. Если вы выберите 128, вы исчерпаете слоты записей прежде, чем закончится место в блоке. Если же вы выберите 256, то появляется риск возникновения фрагментации записей. Выбор нужно сделать соответственно характеру записей. Если записи растут динамически, то нужно выбрать меньшее значение (128), чтобы избежать фрагментации. Если записи добавляются, но обычно не изменяются, т.е. статичны в размере, то лучше выбрать большее значение RPB (256). В основном OpenEdge старается вставлять записи так, чтобы не создавать фрагментов, фрагментация обычно возникает когда запись изменяется. Вероятность роста размера записи, которая часто изменяются, достаточно велика.
Если вы выберите маленькое значение, вы можете оценить это с точки зрение дискового пространства. Для этого, возьмите количество записей в таблице, и разделите его на RPB, чтобы определить количество блоков, которые будут размещены для хранения этих записей:
Number of records / records per block = allocated blocks
1,000,000 / 128 = 7813
Затем, вычислите количество неиспользованных байт в блоках, умножив физический размер памяти записи на RPB и отнимите полученное число от размера блока базы данных:
Database block size – (Actual storage size * records per block) = Unused space
per block
8192 – (61 * 128) = 384
Возьмите количество размещенных блоков, и перемножьте его на неиспользованное пространство в блоке, чтобы определить общее количество неиспользованного пространства:
Allocated blocks * unused space per block = total unused space
7813 * 384 = 3000192
В нашем случае, общее количество неиспользованного пространства, которое является последствием выбора маленького значения RPB, равно чуть меньше 3Мб. С точки зрения дискового пространства, цена достаточно низкая для устранения фрагментации. Однако, для статичных записей, предпочтение лучше отдать более высокому значению, так как это позволит полностью заполнить блоки и получить в результате большее количество записей считанных в буферный пул базы данных.
Неиспользуемые слоты
Другая причина, чтобы выбрать RPB равным 256, заключается в том, что все еще не все слоты в блоки использованы. Поскольку количество записей определяет количество блоков в области, важно, чтобы можно было использовать все слоты, тем самым получив максимальное количество записей в таблице.
Определение пространства для размещения области
Вам необходимо определить количество пространства, которое может занять область. OpenEdge довольно хорошо справляется с хранением данных и индексов, которые уплотняет в разумных пределах. В большинство областей данных заполнены на 90 – 95 %%, а индексы поддерживаются на уровне 95%, что гарантирует наилучшую эффективность. Но обычно, достаточно и коэффициента 85%. Используя пример с одним миллионом записей, который приводился выше, вы можете увидеть, что записи, плюс некоторое значение overhead, должны использовать 61 миллион байт для хранения:
(Mean record size + overhead) * Number of records = record storage size
(59 + 2) * 1,000,000 = 61 million bytes
Фактически это значение только для хранения актуальных записей. Теперь, возьмите это значение, и разделите его на ожидаемый коэффициент заполнения. Более низкий коэффициент дает более консервативную оценку:
Record storage size / Fill ratio = Total storage needed
61,000,000 / .85 = 71,764,706 bytes
Чтобы определить размер в блоках, разделите полученное число по 1 Кб(1024 байт). Этот шаг необходим поскольку количество пространства необходимо отразить в структурном файле (dbname.st) в килобайтах, не зависимо от размер блока базы данных:
71,764,706 / 1024 = 70083 (1KB blocks)
Если имеются другие объекты, которые будут хранится вместе с этой таблицей в этой области, вы должны выполнить такие же вычисления для каждого объекта и сложить все вычисления, чтобы определить общий размер области. Не забывайте и о том, что по мимо текущего необходимого пространства, не стоит забывать о факторе возможного роста, т.е. стоит заложить в общий размер некоторое дополнительное пространство.
Размещение таблиц по областям
Теперь, когда вам известно, сколько записей оптимально могут разместиться в блоке, мы можем приступить к рассмотрению вопроса о размещении таблиц по областям хранения. Приведем некоторые основные причины необходимости разделения информации по областям хранения:
- Управляемое распределение ввода/вывода (I/O) с помощью областей
- Сегментация приложения
- Улучшение производительности offline утилит
Фрагментация таблицы в пределах области влияет на размещение и доступ к ней. В случаях, когда записи добавляются в таблицу в порядке, определенном первичным индексом, доступ к базе будет лучше при обращении к ней по первичному индексу. Если таблицу изолировать от других в отдельную область, то это могло бы дать значительное преимущество. А если эта таблице еще и достаточно большая, то польза от отдельного ее размещения будет очень значимой. Есть две причины для такого улучшения:
- Одно чтение из базы данных, извлечет из нее множество записей, а значит вероятность их обнаружения в буферном пуле повышается. Это улучшает показатель buffer hit.
- Многие дисковые системы имеет механизмы опережающего чтения и размещения прочитанных элементов в памяти. Последовательно чтение имеет наибольшее преимущество для использование этой возможности.
Наконец, база данных может содержать множество различных типов данных, которые так же влияют на производительность. Некоторые данные читаются часто, а некоторые имеют архивный характер, и к ним обращение происходит довольно редко. Поэтому, наиболее часто читаемые данные, с помощью областей хранения, вы можете разместить на более быстрых дисках. Тем не менее, для выполнения этого, вам придется изучить приложение, чтобы понять интенсивность использования данных.
Использование экстентов
Наиболее часто администраторы используют минимум 2 экстента, поскольку легко выполнять их мониторинг на уровне операционной системы. Каждая область должна содержать один экстент переменной длины, который должен быть последним в области, это связанно с ростом размера области.
Для предыдущего примера, мы можем определить один экстент размером 102 400 Кб для хранения данных, с учетом пространства для расширения, и один экстент переменной длинны. Но здесь так же можно использовать больше экстентов, например, выбрав восемь экстентов по 10 Мб и один экстент переменной длинны.
Экстенты позволяют распределять данные между множество физических дисков, если вы не используете RAID в системе. Например, если выбрано восемь экстентов по 10 Мб и один переменный экстент, вы можете выполнить “страйпинг” (stripe) ваших экстентов между тремя дисками, как показано на рисунке ниже. Разместите первый, четвертый и седьмой экстенты на первом диске, второй, пятый и восьмой экстенты на втором диске, и третий, шестой и переменный экстенты на третьем диске. OpenEdge по прежнем будет заполнять эти экстенты по порядку. Используя “страйпинг” вы получите смешивание старых и новых данных, относительно их хранения на дисках. Хоть такой “страйпинг” не так эффективен как “страйпинг” на уровне аппаратных средств, это все равно поможет вам устранить не равномерное использование дисков.
Но даже если у вас работает аппаратный “страйпинг”, вам все равно может понадобиться использование множества экстентов. По умолчанию, экстент ограничен размером файла в пределах 2 Гб. Если вам будет необходимо сохранить больше данных чем это ограничение, вам придется создать дополнительные экстенты в области, или вы можете включить поддержку больших файлов, которая теоретически может позволить вам разметить в одном экстенте до 1 Тб данных.
Возможность иметь очень большой по размерам экстент, все равно не гарантирует вам хорошую производительность. Наилучший размер экстенты, который стоит устанавливать, может меняться в зависимости операционной системы, но как показывает практика, обычно не зависимо от ОС, достаточно чтобы размер экстента был равнее 1 Гб.
Хранение индексов
Если размеры пространства для хранения записей достаточно легко вычислить, то с индексами ситуация совершенно другая. Алгоритмы сжатия делают вычисление труднее. При попытке сделать расчет легче, для принятия решения вы можете использовать информацию из анализа базы данных. Не забывайте добавлять дополнительное пространство для возможно роста и для прочих издержек хранения, на подобие расчета пространства для записей.
Если у вас есть готовая база данных, для определения размеров индексной памяти вы можете взять ее статистику. Если такой базы нет, вам придется выполнить оценку предполагаемого размера самостоятельно. Количество и природа индексов могут значительно меняться от приложения к приложению. Word - индексы и индексы по символьным полям занимают достаточно много места, в то время как числовые индексы менее емкие и более эффективны. Иногда встречаются базы данных, где индексы занимают больше пространства чем данные, но это скорее исключение из правил.
В основном, индексы занимают примерно 30 % от общего объема хранимых данных. Следовательно, за основу, для примерной оценки пространства для индексов, вы можете взять, скажем, 50% от пространства, занимаемого данными. Но помните, этот процент может существенно поменяться в зависимости от конкретной схемы базы. Примите это значение за отправную точку, и постоянно выполняйте ее мониторинг.
На следующем примере показана часть анализа базы данных, которая содержит информацию о части индексов существующей базы. Используйте ее, чтобы распределять области между дисковыми ресурсами, которые будут содержать данные:
Область Primary Recovery
Надлежащее установка размеров области Primary Recovery, также известной как Before-Image file (BI), является очень важным моментом для вашей базы данных. Она отвечает за процесс восстановления базы данных, причем на постоянной основе. Область Primary Recovery довольно часто изменяется, если точнее, в нее очень много пишется информации, поэтому, если она расположена на медленном диске, то все попытки улучшения производительности могут быть сведены на нет. Размер этой области изменяется в зависимости от размера транзакций и активности пользователей в вашей системе.
Область состоит из кластеров, размер которых является настраиваемым. Когда запись подвергается изменениям, в область записываются соответствующие заметки. Если возникает какая-либо проблема, или если пользователь решает отменить (undo) свои изменения, эта область используется для того, чтобы гарантировать, что в базе не появятся частичные изменения.
Например, допустим, что мы хотим изменить все записи в таблице так, чтобы их значения увеличили на 10%. Мы хотим, чтобы в процессе, изменению подверглись все записи, или не одна из них, в случае возникновения сбойной ситуации. Тогда мы должны создать одну большую транзакцию, в пределах которой и будут выполняться изменения. Если во время работы транзакции возникнут проблемы, то все изменения будут отменены и записям будет возвращено исходное состоянии (этот процесс называется rolled back). Почему это важно? Если у одновременно будут работать несколько процессов, то область Primary Recovery может сильно вырасти в размерах.
Структура области, это связанный список кластеров. При маленьком размере кластера, будут более часто выполняться контрольные точки (checkpoints). Контрольная точка (Checkpoint) – это точка синхронизации между памятью и диском. Выгода от наличия нечастых контрольных точек, пропорциональна времени, которое будет требоваться для восстановления базы данных. Большие размеры кластеров могут значительно увеличить время запуска и останова базы данных, когда ей требуется “откатить” (back out) не завершенные транзакции, или чтобы выполнить Crash Recovery.
Наилучшим способом, для определения размер BI кластера, является ежедневный мониторинг базы данных в те моменты времени, когда в базе происходит наибольшее количество изменений. Обратить внимание нужно на длительность, возникающих в это время, контрольных точек.
В идеале, контрольные точки должны возникать не более чем один раз в две минуты. Если наблюдается более частое их возникновение, то вам следует увеличить размер BI кластера. Но если они возникают менее часто, то это не означает, что вы должны уменьшить размер кластера. Значение по умолчанию, равное 512Кб, является хорошим для систем с низким объемом изменений, в то время как значения от 1024Кб до 4096Кб, больше подходят для более загруженных систем. Размер кластера, может быть изменен от самого маленького (8Кб) до очень большого (более 256Мб).
Почему размер кластера влияет на частоту возникновения контрольных точек? Поскольку пользователи заполняют кластеры заметками об изменениях, они так же изменяют разделяемую память. Процесс APW постоянно выполняют сканирование памяти, в поисках модифицированных буферов, которые можно записать на диск. В первой контрольной точке, все модифицированные буфера будут помещены в очередь, которая будет записана до возникновения следующей контрольной точки. Буферы, которые находятся в этой очереди, будут записаны на диск процессами APW с более высоким приоритетом, чем другие буфера. Когда все буферы в очереди будут записаны до возникновения следующей контрольной точки, тогда APW займутся поиском буферов, измененных к текущему моменту. И это хорошо. Но если не все буферы успеют записаться, то придется дождаться их записи и только потом приступать к текущим измененным буферам. Если контрольные точки возникают часто, и сброс буферов в контрольных точках продолжается, то вам следует добавить дополнительный APW, и продолжить мониторинг. Если это не устранило проблему, то добавьте еще один APW. Если это все таки не помогло, то стоит обратить внимание на сами диски, и искать причину узкого места именно в них.
Мы обсудили формат Primary Recovery области, но не ее размер. Не существует формулы для определение размеров этой области, поскольку ее размер сильно зависит от конкретного приложения. Progress Software Corporation рекомендует изолировать эту область от всех других частей базы данных, этим вы можете улучшить производительность. Если у вас только одна база данных, то вы можете переместить все экстенты области на отдельный диск (зеркальную пару), поскольку запись в область выполняется последовательно, вы можете получить значительную выгоду от такого размещения. Если же у вас имеется несколько баз данных, то производительность можно увеличить разместив их области (Primary Recovery) не на один диск, а на набор из дисков, объединенных с помощью RAID10.
Области базы данных
Эта глава описывает оптимизацию областей базы данных. Хотя некоторая информация из этой главы была представлена в других частях книги, здесь она повторяется с целью представить наиболее общие решения по оптимизации областей. Цель оптимизации областей, это получение всех преимуществ архитектуры OpenEdge и операционной системы.
Оптимизация областей данных
Следующие несколько простых правил помогут вам легко поддерживать ваши области хранения и обеспечат оптимальное их использование пользователями.
Разделение схемы
Отделяя схему и секвенции от других частей базы данных, вы можете сделать будущие модернизации OpenEdge и вашего приложения более прозрачным для пользователей. Одно из возможных действий, которые выполняются во время основных изменений в версиях OpenEdge, это изменение метасхемы. Метасхема (Metaschema) – это набор определений для внутренней структуры данных. Ваше определение схемы создает правила с помощью которых данные могут быть добавлены или измены вашим приложением. Метасхема имеет туже цель, но для вашей собственной схемы. Отделяя такую информацию как ваше определение схемы и секвенций от области метасхемы, вы тем самым упрощаете задачу изменения этой информации.
Выбор походящего размера блока
Сопоставление размера блока базы данных с блоком операционной системы, вы тем самым обеспечиваете более эффективное перемещение данных между ними. Если размер блока будет слишком мал, операционная система будет вынуждена извлекать много блоков по вашим запросам, если считанная лишняя информация не будет востребована приложением, то это означает, что время на извлечение было потрачено зря. Большие блоки могут быть лучше, из-за того, как устроены индексы. Если каждый считанный блок будет содержать больше информации, то извлекать будет необходимо меньшее количество блоков и меньшее количество индексных уровней, чтобы получить доступ к данным. Индексные уровни в B-дереве очень важны. Если вы сможете устранить лишний уровень из индекса, вы тем самым сохраните одну дополнительную операцию ввода/вывода (I/O) при запросе каждой записи.
Использование фиксированных экстентов и I/O
В нежурналлированных файловых системах, когда единственная inode-таблица не может адресовать все адреса в пределах файла, возникает так называемое I/O indirection. Inode – это преобразование логических адресов в физические в пределах файла. Представьте inode-таблицу как таблицу с описанием содержимого в файле. Теоретически, файл может стать большим до того как произойдет indirection, но для этого нужны хорошие условия. Inode indirection не представляет интереса для журналлируемых систем.
В реальном мире, indirection может возникнуть в файлах при размерах 500Мб, но в внекоторых системах вы можете не наблюдать его возникновения до 1Гб и выше. Потери от использование маленьких экстентов областей хранения довольно малы. Обычно, вам достаточно только контролировать количество доступных файловых дескрипторов в операционной системе, чтобы была возможность держать открытыми все экстенты.
Использование небольших областей offline утилитами
Сегодня существует множество утилит, которые способны работать с базой данных OpenEdge в online, но к сожалению, еще остаются такие утилиты, которые могут работать только на остановленной базе данных. Для таких утилит, чем меньше информации будет хранится в области, тем меньше будет время простоя утилиты перед началом ее работы.
Наилучший пример здесь, это перестройка индексов. Если вам необходимо перестроить только один индекс, будет необходимо просканировать всю область, чтобы убедиться что для каждой записи существует соответствующий указатель. Если все таблицы находятся в одной области, на это может быть потрачено значительно много времени. Намного меньше времени понадобится, чтобы просканировать область, в которой хранится только одна таблица.
Наличие экстента переменной длины для каждой области
Последний экстент каждой области хранения, включая область Primary Recovery, и за исключением After-image областей, должен быть переменной длины. Жесткий контроль за хранением и ростом области, может исключить необходимость иметь такой экстент. Но иногда, все фиксированный экстенты могут быстро заполниться, а выключение базы данных для добавления экстента будет весьма проблематичным. Экстент переменной длинны, в таких ситуациях, позволит базе данных расти столько, сколько нужно, пока не появится возможность добавления нового экстента.
Включение поддержки больших файлов
Для вашей базы данных всегда должна быть включена поддержка больших файлов. Тем не менее, так же как и с фиксированными экстентами, когда вы не хотите иметь переменный экстент, возможно вы не захотите использовать файлы больших размеров, но всё равно, вы должны включить эту поддержку, которая бы работала как предохранительный клапан, на случай непредвиденного роста.
Включение поддержки больших файлов позволит экстентам базы достигать размеров до 1 ТБ (терабайта), при условии, что операционная система поддерживает работу с файлами такого размера. На Unix системах, каждую файловую систему необходимо настроить для этого. В Windows, файл может заполняться пока не заполнится весь диск. По умолчанию, в базе данных поддержка больших файлов отключена.
Разделение данных
Разделение данных по функциональным областям, это разумное решение по разделению информации на небольшие части, чтобы уменьшить размер областей. Это так же позволит вам отслеживать расширение каждой части приложения независимо от других частей.
Информация по Primary Recovery (before-image)
В системах, где изменения выполняются часто, важно, чтобы чтение и записи в эту область базы данных выполнялись как можно более эффективно. Доступ для записи наиболее важен.
Далее будут даны некоторые простые советы, позволяющие создать эффективную окружающую среду для области Primary Recovery.
Размер экстентов
Следующие правила относятся как к области Primary Recovery, так и областям данных:
- Не делайте экстенты слишком большими
- Всегда делайте последний экстент переменным
- Включите поддержку больших файлов, в качестве предохранительного клапана
Поддержка больших файлов особенно важна для это области (Primary Recovery), поскольку она как ни какая другая может неожиданно вырасти до больших размеров. Программа с большим количеством изменений в пределах одной транзакции или просто открытая транзакция в приложении и оставленная на длительное время в таком состоянии, могут привести к чрезмерному росту этой области. Если фиксированный экстент достигнет размер более 2Гб, то работа транзакции продолжится, так как у вас будет в наличии экстент переменной длинны. Только в этой ситуации, может понадобиться пространство большее чем 2 Гб на случай отката транзакции. Если у вас включена поддержка больших файлов, и у вас достаточно свободного дискового пространства, то это не будет проблемой. Но если поддержка больших файлов не включена, то база данных может оказаться поврежденной, поскольку нет способа расширить базу данных для выполнения восстановления, без соответствующей остановки базы данных.
Последовательный доступ
Доступ к области Primary Recovery осуществляется последовательно. Элементы записываются и считываются из нее линейным методом. Если есть возможность изолировать Primary Recovery от других файлов базы данных и прочих баз данных, то это нужно сделать, разместив область на одном диске (“зеркале”).
“Страйпинг” увеличивает потенциал производительности файловой системы, что особенно эффективно при произвольном доступе. Поэтому, если область не будет изолирована от базы данных, или если на одном диске хранятся области Primary Recovery от нескольких баз, то вам лучше использовать “страйпинг”, поскольку использование ввода/вывода будет довольно сильно перемешано между базами данных.
Наращивание BI
В утилите PROUTIL существует опция BIGROW, которая позволяет предварительно отформатировать BI кластера перед запуском в базу данных пользователей. Это позволяет избегать необходимость форматирование новых кластеров в online. Поскольку форматирование в online крайне негативно отражается на производительности базы данных. Для того чтобы выполнить форматирование с помощью BIGROW, база данных должна быть остановлена.
Информация по After-image
Продолжение следует...
|
|
|
|
Главная
