Что же делать, если Progress Explorer так и не начал нормально работать? Выход есть. Начиная с версии 10.1C SP3 свободно доступен продукт OpenEdge Explorer. Это урезанная часть OpenEdge Management, которая дублирует функционал Progress Explorer.
Данный продукт легко скачивается с сайта www.psdn.com. Если у вас стоит OpenEdge win32 (неважно, на какой ОС, важна разрядность продукта) — качать следует именно версию для win32.
После того, как архив скачан и вы записали серийный номер, находящийся в личном кабинете на сайте, приступим к установке и настройке. Перед установкой продукта необходимо убедиться, что вы располагаете лицензией, которая позволяет работать с базой данных (в том числе пойдут и разработческие лицензии).
Read the rest of this entry »
Самое первое, с чем придется столкнуться разработчику – это установка и настройка среды OpenEdge на своём компьютере. Рассмотрим установку на примере версии OpenEdge 10.1C, продукта OE Studio и ОС Vista. Конкретно у меня – Vista x64, так что на её примере мы это и посмотрим. Всё написанное выше справедливо и для других версия Windows , включая Windows 7 .
Если мы планируем использовать WebSpeed (а мы ведь планируем? Если нет – то при установке можно отказаться) – необходима настройка IIS, встроенного web-сервера Windows. В Windows Vista версия IIS имеет номер 7, что несколько отличается от рекомендуемой версии 6 для 10.1C, но это не страшно – нам поможет Progress Knowledge Base и статья P125146 “How to configure IIS 7 on Vista for WebSpeed ?”.
Кстати, советую сразу скачать по ссылке http://download.progress.com/open/products/prokb/prokb.zip оффлайн-версию ProKB и периодически её обновлять.
Перед установкой проверим, что IIS установлен. Достаточно установить компоненты указанные на картинке.
Read the rest of this entry »
Posted
on 30.01.2011, 23:57,
by Dmitry Lishafaev,
under
OE Management.
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Оптимизируем структуру данных.
В этом разделе представлен общий обзор структуры базы данных и подчеркивается важность грамотного подхода к проектированию физической структуры базы данных. База данных состоит из областей хранения (storage area), каждая из которых может содержать от одного до множества объектов. Под объектами в данном случае понимаются таблицы или индексы. Кроме них есть и другие объекты, такие как последовательности (sequences) и схема БД (schema). На текущий момент мы не можем управлять размещением этих двух последних объектов.
Каждая область хранения при размещении на диске делится на один или несколько экстентов (extent) (иногда их называют томами (volume)). Экстент — это обычный файл. Каждый экстент состоит из блоков и системный администратор определяет размер блока. Выбрать размер можно их следующих величин – 1KB, 2KB, 4KB и 8KB. Выбранное значение распостраняется на всю базу данных, но каждая область хранения может иметь свое значение количества записей на блок (records per block, RPB).
Правильное проектирование базы данных несомненно важно – ведь при проектировании определяются характеристики областей хранения. При проектировании базы данных надо учитывать ряд факторов, самый важный из которых – размер записи в базе данных. Это очень легко, если у нас уже есть база данных – необходимо запустить процедуру dbanalys и просмотреть ее вывод. Другие же факторы, которые надо учитывать не так легко увидеть администратору БД, так как необходимо знать – каким образом работает приложение. Это могут знать только разработчики. Например, важно знать ответы — к каким таблицам происходит последовательный доступ, а к каким – случайный. Какие таблицы используются постоянно, а какие таблицы являются хранилищами архивной информации? Какие таблицы используются большинство времени суток, а какие редко? Обновляются ли существующие записи в таблице или они статичны? Ответы на такие вопросы помогают определить размер и расположение базы данных на дисках. Кроме всего прочего станет ясно как наилучшим образом утилизировать производительность дисковой подсистемы.
Read the rest of this entry »
Posted
on 28.01.2011, 01:10,
by Dmitry Lishafaev,
under
оффтопик.
Перевод оказался не таким простым — основная проблема в нехватке времени. Правда, HALO: Reach я уже прошёл и теперь постараюсь уделять сайту больше времени. Сегодня я закончил приводить предыдущий материал в более-менее читабельный вид и начну дальше переводить остальные части. В начале есть один непереведенный кусок про память, его я сделаю позже.
Кроме всего прочего я готовлю статью по настройке OpenEdge 10.1C 64-bit на операционной системе AIX, где в основном будет затрагиваться тема управления памятью. Поскольку там не работает параметр pin shared memory, то настройка системы имеет свои ньюансы.
/dmi
ps: и да, с новогодними праздниками :)))
Posted
on 22.11.2010, 00:31,
by Dmitry Lishafaev,
under
Без рубрики.
Вернулся из отпуска. В более-менее понятном виде переведено около половины книги. Дальнейший план действий — исправить ужасный перевод на литературный. 🙂 До конца ноября, я полагаю, управлюсь.
Upd: скорее всего — до конца года 🙂
Более-менее выверенный перевод помечен тегом «выполнено»
Posted
on 05.11.2010, 00:02,
by Dmitry Lishafaev,
under
OE Management.
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется
Как происходит работа с блоками
Операций по манипуляции с блоками БД практически не видно и над этими операциями у нас существует только ограниченный контроль (кроме, конечно же, момента создания базы данных). Мы не можем управлять выполнением, но всегда можем настроить базу данных таким образом, чтобы эти операции выполнялись максимально эффективно.
Работа с блоками записей
Процесс добавления новой записи в базу данных очень важен — нужно соблюдать баланс между плотностью и фрагментацией данных. Высокий уровень компактности данных позволит считать за одну операцию ввода-вывода больше записей. Это увеличивает быстродействие. А если у вас много фрагментированных записей, то быстродействие уменьшается, так как чтение каждой фрагментированной записи требует чтения множества блоков.
Добавление новой записи в базу данных
Если в базу добавляется новая запись, то физическое размещение записи в базе выполняется по специальному алгоритму
Read the rest of this entry »
Posted
on 03.11.2010, 15:13,
by Dmitry Lishafaev,
under
OE Management.
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется.
Использование памяти
Процесс primary broker выделяет для пользователей разделяемую (shared) память. Пользователи используют структуры в этой памяти в режиме параллельного доступа к данным. Доступ предоставляется таким образом, что повредить данные невозможно.
К примеру, если бы два пользователя захотели одновременно обновить одну и ту же область памяти различным содержимым, то в базе данных было бы отражено обновление только одного пользователя. Это неверно и приводит к неполному обновлению памяти. Рассмотрим механизм, который не допускает таких повреждений.
Read the rest of this entry »
Posted
on 03.11.2010, 14:40,
by Dmitry Lishafaev,
under
OE Management.
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется.
Области хранения Type I и Type II
Области хранения Type II (известны как кластеризуемые области хранения) позволяют группировать данные в кластерах. Размер этих кластеров является настраиваемым для каждой области. Глава «Оптимизация размещения данных» подробнее освещает необходимость использования областей Type II. А этот раздел описывает различия между областями Type I и Type II. Области Type I имеют блок контроля области (Area Control Block), который отслеживает выделенный для области объем и максимальное количество пространства внутри области. Области второго типа имеют кластер контроля области (Area Control Cluster), который содержит блок контроля области и блоки объектов, хранящие цепочки распределения пространства для каждого объекта (таблица, индекс, BLOB, CLOB). Такой кластер является всегда первым в области хранения Type II. Поскольку эти объекты теперь обрабатываются отдельно друг от друга, то существует понятие множественных цепочек свободных блоков. Каждый объект в области типа II будет иметь достаточно пространства для своего роста в пределах кластера. Если пространства нет — выделяется следующий кластер. Индивидуальные цепочки свободных блоков дополняют цепочки свободных блоков области. Каждый кластер объединен в цепочку — на его начало указывает предыдущий кластер, а сам он в конце указывает на следующий кластер. Таким образом только первые и последние блоки кластеров в области Type II физически отличаются друг от друга, так как содержат информацию об указателях. Все остальные блоки остаются такими же, как и в Type I, но их последовательность основана на настройке количества блоков на кластер области.
Posted
on 02.11.2010, 23:42,
by Dmitry Lishafaev,
under
OE Management.
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется.
Управление ресурсами БД OpenEdge
Управление производительностью БД состоит, главным образом в выявлении потенциальных узких мест и их переносе на самые быстрые ресурсы системы. Среда OpenEdge пытается сделать этот процесс максимально простым и понятным, но есть некоторые вопросы, которые необходимо проработать перед тем как приступать к настройке.
Эта глава рассказывает о внутреннем устройстве БД OpenEdge и о различных путях оптимизации OpenEdge для наиболее полного использования ресурсов системы. Глава состоит из следующих разделов:
- Внутренняя структура БД OpenEdge
- Управление блоками данных
- Оптимизация размещения данных
- Оптимизация областей БД
- Репликация БД OpenEdge
- Оптимизация использования памяти
- Оптимизация использования CPU
Read the rest of this entry »
Posted
on 13.10.2010, 00:06,
by Dmitry Lishafaev,
under
OE Management.
Продолжение перевода Adam Backman «OpenEdge Revealed:Mastering the OpenEdge Database with OpenEdge Management».
Перевод публикуется в виде статей и постоянно редактируется.
Управление загрузкой процессора
Все ресурсы влияют тем или иным образом на загрузку процессора. К примеру, медленные дисковые устройства заставляют CPU выполнять холостые циклы в ожидании завершения операции ввода/вывода. Смена контекста (context switch) аналогичным образом увеличивает время отклика системы.
Что такое загрузка процессора
Чтобы понять, чем занят процессор необходимо знать — из каких компонент состоит его загрузка. На UNIX-системах работу процессора разделяют на следующие компоненты:
- User Time (время пользователя)– время, которое процессор тратит на выполнение задач пользователя. Это основное, за что вы платите при покупке процессора.
- System time (время системы) — количество времени, которое система тратит на подкачку, смену контекста, запуск задач по расписанию и другие системные задачи. Вы никогда не избавитесь от этого времени, но вы можете минимизировать его. Подробности — глава 3, “Системное администрирование” ,страница 129
- Wait on I/O (ожидание ввода-вывода) – время, которое CPU простаивает в ожидание запрошенного ресурса, например — ожидание выполнения дисковой операции.
- Idle Time (время простоя) – сумма времён, когда CPU простаивает. Если нет команд в очереди инструкций и процессор не ждет отклика ресурсов, то такое время отмечается как время простоя. Некоторые операционные системы могут учитывать как время простоя и время ожидания ввода-вывода. Ведь по сути, во время такого ожидания процессор не выполняет никаких операций и ждет отклика устройства ввода-вывода. Поэтому опираться только лишь на показатель Idle Time во время оценки производительности системы не стоит — будут погрешности
Read the rest of this entry »