Поздравляем! Вы наконец-то решили присоединиться к современном миру Progress и воспользоваться областями хранения второго типа (Type II или SAT-II, можно просто SAII). Лучше поздно, чем никогда!

По этой теме существует много устаревшей или просто неверной информации, поэтом забудьте это всё и давайте посмотрим, что же всё-таки действительно имеет значение.

Основные утверждения

1. Вам нужна версия OpenEdge не ниже 10, а лучше самая свежая (на август 2018 года это OE 11.7.3).
2. Размер блока БД: довольно просто – 8Кб для UNIX, 4Кб для Windows и Linux.
3. BPC = Blocks Per Cluster: количество каждый раз форматируемых блоков, когда объекту необходимо больше места. Допустимые значения: 8, 64, 512.
4. RPB = Records Per Block: количество идентификаторов записей (ROWID) зарезервированных для каждого блока базы данных. Допустимые значения: 1, 2, 4, 8, 16, 32, 64, 128, 256.
5. Храните данные, индексы и LOB отдельно.
6. Описание областей хранения находится в файле с именем dbname.st.

Спорные предположения

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

1. Используйте большие файлы. В современных системах нет влияния на производительность, связанного с объёмом экстентов базы данных (1Гб или 10Гб или 100 Гб).
2. Используйте экстенты переменной длины везде (AI, BI, D). Если вы не согласны, приведите математический расчёт в разделе комментариев. Возможно, для AI-экстентов вы сможете придумать что-то умное, но даже в этом случае это не повлияет на бизнес или пользователей в 99% случаев. Т.е. 2% выигрыша в производительности составят всего 2 миллисекунды для пользователя и 2 секунды для пакетного процесса. Незначительно улучшение!
3. Разместите всё (AI, BI, D) на одной и той же файловой системе и дисках, если вы не можете доказать, почему они должны быть разделены.
   1. В большинстве случаев всё сохраняется на один и тот же SAN [кеш] в любом случае.
   2. Большинство из вас не сможет восстановить последние 3 минуты жизни базы данных из AI-заметок. Именно по этой причине многие рекомендуют хранить AI-файлы на отдельных дисках.
4. Если у вас небольшой физический сервер с небольшим количеством дисков (скажем, менее дюжены или около того), то не заморачивайтесь с RAID, выделяя два диска для ОС, два для AI, два для BI и шесть для БД – какая трата IOPS! Хорошо – если у вас их 8-10, можно допустить зеркаллирование для ОС. Но на этом всё. Или просто купите диски SSD.
5. Не буду сейчас обсуждать альтернативный буферный пул (-B2) в этой статье. Есть некоторые изменения в рекомендациях, но это для отдельной статьи в другой раз.
6. Также не буду сейчас обсуждать фрагментацию и лимиты CREATE/TOSS. Это тоже для другой статьи.

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

Структурный файл

Отдел обеспечения качества (QA – Quality Assurance) Progress Software был в отпуске, когда придумали формат структурного файла для экстентов данных:

d “GL_History Data”:22,32;64 .

Да, это тип области (d = данные), затем имя области в кавычках, далее следует двоеточие, затем номер области, затем запятая, после которой RPB, затем точка с запятой, затем BPC и наконец, пробел и каталог (где «.» означает «текущий рабочий каталог»). После каталога можно дополнительно добавить «f» (fixed), а затем указать размер файла, но вы ведь не будете этого делать, верно?

Номер области должен начинаться с 7 и быть уникальным для каждой области хранения. Просто. Но что на счёт RPB и BPC? Чтобы ответить, мне нужен анализ базы данных (DB Analys). Для примера используем базу sports2000:

Table     Records   Size    Min   Max   Mean   Count   Factor   Factor

PUB.POLine   5337   217.5K   40    44     41    5337     1.0     1.0

Здесь средний размер записи составляет 41 байт, поэтому в 4Кб блоке я могу разместить около 100 таких записей. Заметьте, я говорю «около», так как существует заголовок блока, который тоже потребляет пространство, но его существование, вероятно, не изменит нашего решения в 99,9% случаев. Теперь я хочу выбрать значение RPB близкое к 100, у меня есть варианты, 64 или 128. Если я выберу 64, то с большой вероятностью я будут использовать только 64 * 41 = 2624 байта в блоке, оставив примерно 14000 байт не используемыми. Если я выберу 128, то я заполню блок моими +/- 100 записями, но «растрачу» около 25-30 идентификаторов записей (ROWID). 128 ROWID будут зарезервированы для каждого блока, поэтому если вы их не задействуете, то они просто не будут использоваться. Благодаря 64-битным ROWID максимальное количество записей в каждой области хранения исчисляется триллионами, поэтому большинству из вас, вероятно, не стоит беспокоиться от том, что ROWID закончатся.

Хорошо, но как на счёт индексных областей? Ответ – 64. На самом деле RPB не имеет смысла для индексных объектов, НО! Если вы будете следовать наиболее часто цитируемому утверждению RPB=1, и если вы случайно создадите таблицу в такой области, то вам станет очень «весело», причём очень быстро. Таблица POLine со 100 тыс. записей и с 1 RPB для 4Кб блока займёт 400 Мб вместо 4 Мб! Согласитесь, не очень будет весело, когда 10 млн. записей превратятся в 40 Гб.

А как на счёт BPC? Тоже просто: используйте 512 или 8.

Любой крошечный объект, скажем, меньше 5Мб, должен храниться в области с BPC = 8. Всё остальное должно отправиться в области с BPC=512. Но у нас появится много пустых блоков в базе данных? Да. Станет ли база данных намного больше, чем раньше? Вероятно. Должен ли я или вы об этом беспокоиться? Нет. Просто обязательно используйте параметр «-com» в команде probkup.

Что к чему?

Я уже упоминал, что вы должны разделять данные, индексы и LOB. Давайте сделаем следующий шаг:

1. Каждая область данных должна иметь соответствующую индексную область.
2. Действительно большие и/или наиболее активные таблицы (относительно вашей БД), очевидно должно иметь собственные области второго типа.
3. Небольшие таблицы, должны хранится в одной области, например, с именем «Misc Data», но тоже обязательно второго типа.
4. Всё что между ними, может храниться в одной или двух и более областях данных. Но это не обязательное правило.

Возьмём типичную базу данных ERP, размер которой составляет 100 Гб и в которой есть 750 таблиц. Таблица History и несколько других таблиц будут иметь размер в несколько Гб каждая. Каждая из них получит собственную область второго типа с соответствующими RPB и BPC=512. 700 из 750 таблиц могут быть пустыми или иметь незначительное количество записей – поместите все эти данные в область «Misc Data» с RPB=128 и BPC=8. Остальные 45 таблиц могут храниться в одной или двух областях «Data Areas» с RPB=128 и BPC=512.

Стоп! Что? Это безумие!

Расслабьтесь. Если вы делаете это по-другому, то возможно это не неправильно. Наиболее важное значение имеет разделение данных, индексов и LOB и сам факт использования областей второго типа. Если вы всё сделаете правильно, то вы получите девяностопроцентное улучшение реализовав только эти две вещи.

Paul Koufalis
White Star Software

Оригинальная статья здесь