Конференция 2011. Приветственное слово Юрия Гусева
Итак, открытие конференции. С приветственным словом выступает генеральный директор Progress Technologies Юрий Алексеевич Гусев.
Конференция пользователей Progress 2011
Вот и закончилась юбилейная, десятая по счету, конференция российских пользователей продуктов Progress Software. Я поставил камеру и снял всё происходящее в зале Ярославль на видео. Как только я обработаю видео (примерно месяц), то выложу записи сессий:
Подробно о Before-image
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management». Перевод публикуется в виде статей и постоянно редактируется.
Подробно о Before-image
В базах данных с высокой частотой обновления данных важно самым оптимальным образом настроить выполнение операций ввод-вывода. Но при такой настройке следует обратить самое пристальное внимание на операции записи. Ниже будут даны советы по настройке механизма before-image.
Основные правила
Эти правила применимы как и к областям before-image, так и к областям данных
- Не делайте их слишком большими
- Количество областей должно лежать в разумных пределах, ими должно быть легко управлять
- Схема данных должна быть отделена от самих данных
- Для всех таблиц, кроме схемы и таблиц очень маленького размера, должны быть использованы области хранения Типа II
- Большие таблицы выносите в отдельные области, остальные таблицы сгруппируйте в отдельных областях хранения по среднему размеру записи
- Всегда обращайте внимание при выделении таблиц в отдельные области на то, каким образом чаще всего используются эти таблицы
- Всегда делайте последний экстент области экстентом переменного размера
- Включите возможность использования больших файлов в качестве дополнительной меры безопасности
Утилита Bulk Loader
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Утилита Bulk Loader
Утилита массовой загрузки записей Bulk Loader удобна в использовании, но является однопоточной и требует перестройки индексов после своего завершения. Пользоваться этой утилитой имеет смысл только для баз размером до 1 Гб или тогда, когда простота процесса — это самое главное. Нужно выгрузить содержимое таблиц, определение структуры БД и создать файл для описания процесса массовой загрузки (bulk load). После завершения дампа необходимо создать новую БД, скопировать туда базу empty и загрузить описание структуры БД. Следующий шаг — запуск утилиты Bulk Load и перестройка индексов после её завершения. В конце необходимо произвести сравнение исходной и полученной баз данных.
Утилита двоичной выгрузки и загрузки (binary dump & load)
Возможность binary dump & load присутствует в Progress достаточно длительное время, причем сначала эта возможность была недокументированной. В OpenEdge 10 эта утилита получила много новых возможностей: выгрузка данных по любому индексу или выгрузка определенных записей, описанных в параметре dumpspecified. Этот параметр позволяет выгружать большую таблицу по частям в многопоточном режиме. Затем эти части последовательно загружаются утилитой двоичной загрузки. Загружать таблицу следует в однопоточном режиме, ведь многопоточная загрузка увеличит логическую фрагментацию данных. Детальное описание параметра можно найти в книге OpenEdge Data Management: Database Administration.
Так же, как и впредыдущих способах необходимо:
- Увеличить размер кластера before-image
- Выполнять процесс загрузки в многопользовательском режиме, 1 тред на область
- Запустить Before-Image Writer
- Запустить достаточное количество процессов Asynchronous Page Writer
- Убедиться, что After Image выключен
- Сравнить исходную и полученную БД после процедуры загрузки
Миграция на области хранения Типа II
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Переход на области хранения Типа II
Переход на области хранения Типа II должен быть выполнен только тогда, когда он имеет смысл для бизнеса. Необходимо знать, как работать с такими областями, и уметь пользоваться их преимуществами. Существует довольно много способов такой миграции. Самый очевидный способ — это полная выгрузка ваших данных из существующей базы данных, создание новой базы с областями хранения Типа II и загрузка данных в эту базу. Есть и другие способы оперативной миграции. Все эти способы подразумевают простои в работе базы данных Наша цель — сделать такие простои минимальными. Самый очевидный подход (выгрузка и загрузка) влечет за собой самый длительный перерыв в работе. Есть способы постепенного перехода, которые сводятся к сериям относительно коротких перерывов. К примеру можно использовать триггеры базы данных для сохранения промежуточных изменений, но такой подход выходит за рамки данной книги. Этот способ — самый действенный для тех случаев, когда простой БД должен быть сведен к минимуму. (например — proD&L от BravePoint Software, прим /dmi)
Краткий план для выгрузки и загрузки данных.
Выбор оптимального размера блока
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Выбор оптимального размера блока
Соответствие размера блока базы данных и размера блока файловой системы является залогом наибольшей эффективности операций ввода-вывода. Если определить размер блока БД слишком маленьким, то операционная система считает больше блоков БД, чем необходимо и неизвестно, пригодятся ли дополнительно считанные данные или нет. Если нет, то эти дополнительные блоки прочитаны впустую. Блоки имеющие бОльший размер обычно лучше из-за механизма поведения индексов. Если каждый блок будет содержать оптимальное количество информации, то нам потребуется прочитать меньше индексных блоков и индексных уровней для того, чтобы найти и прочитать данные. Количество индексных уровней в двоичном дереве (B-tree) прямо влияет на эффективность извлечения данных. Если мы избегаем чтения одного уровня индекса, то мы экономим одну дополнительную операцию ввода-вывода на запрос записи.
Read the rest of this entry »
Оптимизируем области БД
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Области хранения базы данных: оптимизация
В этом разделе речь идет об оптимизации областей базы данных. В этом разделе принято решение обобщить и собрать воедино всю необходимую информацию из разделов данной книги и другой документации. Возможно, что здесь встретятся повторы, но это сделано ради удобства — всё необходимое можно найти в этом разделе.
Цель оптимизации — получить максимальную производительность используя все возможные решения архитектуры операционной системы и OpenEdge RDBMS.
Оптимизация областей хранения данных
Несколько простых правил помогут сделать области хранения данных легко обслуживаемыми и обеспечат оптимальную производительность при работе.
Области хранения
Основные причины для распределния данных по различным областям хранения:
- Управление размером отдельных областей хранения
- Уменьшение фрагментации
- Распределение данных по разным физическим устройствам (размещение областей хранения на разных устройствах)
В прошлых версиях Progress записи таблиц, находящихся в одной области, перемешивались между собой. С течением времени данные размазывались по области, поскольку содержимое таблиц постоянно изменяется. В OpenEdge появились средства для минимизации такой фрагментации, кроме того у базы данных появилась возможность быстрого удаления данных. Если нам необходимо удалить таблицу из области хранения Типа I, то OpenEdge должен обработать отдельно каждую запись в том порядке, в каком задано условие для удаления. В области хранения Типа II возможно выполнение команды «drop table». Таблица удаляется при этом в одну операцию: первый кластер объекта маркируется как свободный. Поскольку кластеры соединены в цепочку, то все остальные кластеры в цепочке также станут свободными. Это довольно редкая операция, но она демонстрирует возможности областей Типа II.
Read the rest of this entry »
Журнал before-image
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Журнал before-image
Нам следует побеспокоиться и о размере области, отведенной под журнал before-image (или — область primary recovery). Эта область постоянно ответственна за поддержку целостности базы данных и является очень важной. Основная нагрузка этой области — нагрузка на запись. Если область расположена на медленных дисках, то операции обновления данных в базе будут такими же медленными. Размер области зависит от активности по обновлению данных и от длины транзакций.
Область primary recovery состоит из кластеров, размер кластеров можно настроить. При обновлении записи БД создаются заметки об этом обновлении, которые и записываются в эту область . Если в транзакции возникла ошибка или пользователь решил отменить (undo) изменения этой транзакции, то эти заметки используются для корректного отката всех произошедших внутри транзакции изменений .
Для примера предположим, что нам надо увеличить на 10 процентов значение одного конкретного поля для всех записей в таблице. Для изменения надо использовать стратегию «всё-или-ничего» , так как мы не сможем определить на каком месте аварийно закончилось обновление. В этом случае нам необходима одна большая транзакция внутри которой мы будем производить изменения. Если произойдет ошибка, то все измененные поля в записях «откатятся» к своим первоначальным значениям. Важно знать, что если у нас выполняется одновременно несколько больших процессов, то размер области before-image может стать довольно значительным.
Давайте рассмотрим структуру и использование данной области подробнее. Эта структура представляет собой связанный список кластеров, размер которых может быть изменен в широких пределах — от 8Kb до более чем 256Mb.
Определение размера области хранения
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Определение размера области хранения
Следует определить количество дискового пространства, которое необходимо будет отдать под размещение области хранения. OpenEdge размещает данные и индексы с хорошим уровнем уплотнения. В самом лучшем случае большинство областей, содержащих данные используются с эффективностью 90 — 95%, а эффективность использования индексных областей лежит всегда около 95%. Для планирования желательно использовать показатель 85%. Это разумное решение. Используя пример из предыдущей главы мы рассчитаем действительный объем данных — 61 миллион байт.
Это — фактический объем данных. Теперь разделим его на ожидаемый процент заполнения. Чем ниже этот процент, тем больше будет занимаемый объем.
Теперь определим размер в килобайтах — поделим полученное значение на 1024. Этот шаг — необходим, так как при описании структуры БД в st-файле размер областей указывается всегда в килобайтах (независимо от размерности блока БД).
Итак — в st-файл мы поместим число 70083.
Если в области есть еще несколько объектов, то те же самые вычисления следует сделать для каждого объекта и определить общий размер для области хранения.
Распределение таблиц между областями хранения
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Распределение таблиц между областями хранения
После того, как мы узнали про оптимальное количество записей в блоке, пришло время поговорить о размещении таблиц в областях хранения. При распределении обычно руководствуются следующими мотивами:
- возможность управлять операциями ввода/вывода (т.е. нагрузкой на дисковую подсистему)
- соответствовать требованиям приложения
- желание ускорить «тяжелые» офф-лайновые утилиты для обслуживания БД
Пока еще не все утилиты для обслуживания БД OpenEdge могут быть запущены в онлайне, но их число увеличивается с каждой версией.
Другой критерий при выносе таблицы в отдельную область — оценка активностей по записи и по чтению. Если таблица растет линейно и используется индекс по первичному ключу таблицы,то большинство чтений из неё происходит в последовательном порядке по этому индексу. При изолировании этой таблицы в другую область можно добиться некоторого прироста производительности. Если эта таблица — большая, то прирост будет значительный.
Улучшения производительности мы добиваемся по двум причинам:
- Чтение одной записи извлекает на самом деле не одну, а множество записей из базы данных. Вероятность того, что эти извлеченные записи будут запрошены следующими операциями чтения будет высока. Таким образом, мы увеличиваем показатель попадания в буферный пул БД (buffer hit)
- Большое количество дисковых систем обладают возможностью упреждающего чтения, т.е. следующие блоки файловой системы поднимаются в кэш дискового устройства. При этом скорость последовательного чтения из БД сильно возрастает.