Столкнулся со следующей ситуацией при создании кластера в IDCAMS. Создаю VSAM н.д., указав распределение кластера с параметром KILOBYTES (0002200275) Задание генерируется следующее: DEFINE - CLUSTER - (NAME (FASPILOT.DATA.FIORUDBD.FIORU080) - DATACLAS(FASPILOT) - NONINDEXED - KILOBYTES (0002200275) - CONTROLINTERVALSIZE (00512) - RECORDSIZE (00505,00505) - SPEED) - CATALOG (CATALOG.FASPILOT) DATACLAS ссылается на storage group, содержащую диски 3390-9.
Согласно геометрии диска 3390-9 (56664 байт на дорожку или 849960 байт на цилиндр) ожидалось распределение 2 GB на примерно 2600 cyl. По факту же распределилось порядка 5600 cyl. Почти в два раза больше.
Если указываю в цилиндрах, то распределение в цилиндрах происходит согласно параметру: CYLINDERS (0000003000), 3000 cyl.
Вопрос: почему такое распределение, если указан параметр KILOBYTES? IDCAMS пересчитывает в дорожки и цилиндры, учитывая какую-нибудь другую геометрию дисков?
Особенно не вдаваясь в теорию. Если вы указываете в CYL, то и распределяется в них и ничего не пересчитывается Килобайты распределяются с учетом длины записи, а для длины 505 байт коэффициент утилизации дорожки будет как раз примерно 50 процентов. Оптимальная длина записи около 27000, как раз две записи на дорожку и утилизация порядка 98 процентов
Дык просто так 27999 мы взять не можем - это VSAM под базу IMS, CI 512, 7 байт на заголовок, запись 505 - под этот размер записи баи расчитаны вся иерархическая структура, размер root segment и его дочерних сегментов. То есть просто увеличив размер CI и соответственно record size мы получим опять же потерю места - не наберётся столько сегментов, чтобы заполнить CI. Если только тогда две иерархические структуры класть в один CI. Что потребует соответсвенного отражения в randomizer, чтобы он правильно распределял... То есть два root segment в один CI. Мда, задачка. Оно то возможно. Наверное, так и придётся, не терять же 50% дискового пространства - не поймут-с. Спасибо за ответ, помогли нащупать путь движения.
Сообщение отредактировал ggv - Пт, 11.03.2016, 12:50
не увидел, что CONTROLINTERVALSIZE задан Не для случая IMS... Я бы его совсем убрал, пусть VSAM сам примет решение о его размере, так как файл не индексированный, могу предположить, что доступ будет не по ключу. Следовательно для лучшего чтения - больший CI лучше. А за счет оптимального размера и память дисковую можно сэкономить (для вашего случая CISIZE будет 18432) почти 100% утилизация дорожки А как IMS-у лучше - это у IMS-а надо спросить
Для IMS в DBDGEN задаётся именно что Control Interval, это мы изменить не можем, потом после генерации DBDGEN мы получаем в sysout рекомендуемые параметры DEFINE CLUSTER, но да ладно, не в этом суть - мы должны указать CI size, должны знать его. Для рандомного доступа слишком большой CI нам тоже не очень нужно, много лишнего будет прочитываться при доступе по отдельным случайным записям. Тут можно только одним способом повысить утилизацию - увеличить размер CI в некотором допустимом пределе, и писать в него не одну, а больше записей IMS, они тогда по рутовым сегментам в цепочку выстрятся. Теряем на чём - при операции I/O читаем лишние (не нужные нам) записи, ну, не знаю, можно на это не обращать внимание, не думаю, что это критично, и немного теряем уже на проходе по цепочке рутовых сегментов до нужного сегмента, но это не операции ввода/вывода, это уже инструкции процессорные, совсем другой уровень. Можно, в принципе, попробовать - терять 50% пространства никто не разрешит.
Мда, компромис между утилизацией и производительностью. Выбирай, но осторожно, вот жешь. Но можно будет поиграть параметрами и посмотреть, даже интересно будет сравнить, пока тестируем, есть возможность.
Посмотрел на тетирование IMS V13,где был достигнут рекорд. Там IBM поступилро двояко - основная база, счетов банковских карт, имеет CI 2048, и по 12 записей IMS в CI А другие две базы, заблокированных карт и ещё какая-то, так там CI по 512 байт, и тоже по нескольку записей в CI, по шесть, что ли. То есть с базой акаунтов увеличило размер CI,а с остальными оставили с неэфективным CI, но там и размеры несопоставимы - база аккаунтов 4400 цилиндров, а остальные две 84 и 60 цилиндра, так что плюнули на такую мелкую потерю пространства. Ну, вот, в принципе, и алгоритм действий - пример, как действовать.
не увидел, что CONTROLINTERVALSIZE задан
