====== Рекомендуемая структура БД QBIS.Bank ======

Структура БД описывается в файле ''bisquit.st''. Формат st-файла:
   <тип> "код области":<# области>,RPB;BPC <размещение>
   где:
      RPB - records per block - максимальное количество записей в блоке
      BPC - blocks per cluster - количество блоков в одном кластере
В данной статье пойдет речь только об областях типа "d", содержащие данные.

Параметр **RPB** рекомендуется выбирать исходя из среднего размера записи для всех таблиц в области данных. Для размера блока 8 КБ оптимальны следующие значения этого параметра:
  * 32 - большой размер записи (от 227 байт)
  * 64 - средний размер записи (до 227 байт)
  * 128 - малый размер записи (до 104 байт)
  * 256 - сверхмалый размер записи (до 42 байт)

Параметр **BPC** рекомендуется выбирать исходя из скорости роста области данных. Если область данных большая и растет очень быстро, то желательно, чтобы и размер кластера был большим. Возможные значения - 8, 64, 512.

===== Рекомендуемый файл bisquit.st =====

Рекомендуемая структура в файле ''bisquit.st'' основана на анализе нескольких клиентских баз данных, работающих в многофилиальном режиме. В конкретном Банке характер данных может отличаться от проанализированных, поэтому значения RPB необходимо подбирать индивидуально (например, для однофилиального режима размер записей в области "pos" меньше, поэтому значение RPB для этой области можно установить равным 256).
  # Описание области Before Image
  b .
  # Служебная область (добавление таблиц в эту область запрещено)
  d "Schema Area":6,64;1 .
  #
  # Транзакционные данные (быстрый рост, средний размер записи)
  d "op":7,128;512 .
  d "op-i":27,1;64 .
  #
  # История изменений (очень быстрый рост, средний размер записи)
  d "history":8,128;512 .
  d "history-i":28,1;64 .
  #
  # Допреквизиты (в т.ч. темпоральные), связи (быстрый рост, средний размер записи)
  d "signs":9,128;512 .
  d "signs-i":29,1;64 .
  #
  # Аналитические данные (очень быстрый рост, средний размер записи)
  d "olap":10,128;512 .
  d "olap-i":30,1;64 .
  #
  # Справочники, небольшие таблицы (медленный рост, малый/средний размер записи)
  d "other":11,128;64 .
  d "other-i":31,1;8 .
  #
  # Права доступа (медленный рост, малый размер записи)
  d "perm":12,256;64 .
  d "perm-i":32,1;8 .
  #
  # Клиентская база, счета, договоры (средний рост, средний размер записи)
  d "acct":13,128;64 .
  d "acct-i":33,1;8 .
  #
  # Остатки по счетам, субаналитика по счетам и договорам (быстрый рост, малый размер записи)
  d "pos":14,128;512  .
  d "pos-i":34,1;64 .
  #
  # Сообщения импорта-экспорта, заголовки отчетных данных (быстрый рост, большой размер записи)
  d "msg":15,32;512  .
  d "msg-i":35,1;8 .
  #
  # Справочники, текстовая информация (медленный рост, большой размер записи)
  d "text":16,64;64  .
  d "text-i":36,1;8 .
  #
  # Витрины данных (быстрый рост, большой размер записи)
  d "mart":17,64;512  .
  d "mart-i":37,1;8 .
При анализе учитывались следующие требования:
  * таблицы и индексы располагаются  в разных областях, это необходимо для указания меньших значений BPC для областей с индексами, чтобы минимизировать размер малозаполненных таблиц, а также для удобства администрирования;
  * области olap, history, op, signs, msg, mart растут быстрее остальных;
  * в областях msg, text и mart средний размер записи значительно превосходит средний средний размер записей в БД, а область perm содержит записи с наименьшей длиной.

===== Перенос данных между областями =====
Одним из параметров БД, влияющих на производительность, является размещение таблиц БД по областям. Для эффективного доступа к данным таблица должна быть размещена в той области, которая больше всего ей подходит как по величине среднего размера записи, так и по скорости роста объемов данных.
Для переноса таблиц и индексов из одной области в другую есть несколько способов:
  * Использование [[unix:progress:dump-load|методики двоичного dump/load]] для передампливания всей БД целиком либо по частям. Эту технологию эффективно выполнять вместе с переходом на новую структуру хранения данных Type Area II, которая значительно увеличивает производительность БД.
  * Использование штатной утилиты [[http://documentation.progress.com/output/OpenEdge112/oe112html/Data%20Management/wwhelp/wwhimpl/common/html/wwhelp.htm#href=Database%20Administration/30dmadmch22.041.67.html&single=true|PROUTIL TABLEMOVE]]
Для автоматизации процесса переноса таблиц между областями можно воспользоваться процедурой ''genscript.p'', которая создаёт скрипт переноса таблиц и индексов, находящихся не в "своих" областях. Она использует информацию о структуре из текущей БД и специальный файл ''table.cfg''. Этот файл конфигурации имеет следующую структуру:
   <area-name>:<table-name1>,<table-name2>,...
   ...
Файл ''table.cfg'' регулярно обновляется  и выходит в составе патчей.

Процедура ''genscript.p'' создает скрипт ''movetable'' для переноса таблиц в новые области данных. Таблицы, не включенные в конфигурационный файл, будут помещены в область ''other''. Если в текущей базе данных существует область с наименованием ''<area name>-i'', то индексы будут автоматически перенесены в эту область, в противном случае индексы будут перенесены в одну область с данными.

Вызов:
   bq41d -p genscript.p -param "table.cfg,movetable"

Учтите, что штатная утилита PROUTIL TABLEMOVE осуществляет перенос данных в рамках одной транзакции. Записи одна за одной читаются в исходной таблице, копируются в новую таблицу, а затем исходные записи удаляются. Поэтому размер BI-файла может вырасти до 10 раз от размера самой таблицы.
===== Дополнительная информация =====

  * Progress Knowledgebase: [[http://knowledgebase.progress.com/articles/Article/P77017|How to move tables faster with tablemove?]]
  * OpenEdge Database Administration Guide: [[http://documentation.progress.com/output/OpenEdge112/oe112html/Data%20Management/wwhelp/wwhimpl/common/html/wwhelp.htm#href=Database%20Administration/22dmadmch15.033.10.html&single=true|Maintaining indexes and tables]]

{{tag>progress prodb}}