После дефрагментации БД и сжатии глобалов с 75% до 95% получил не рост скорости чтения, а замедление.
Кто-то сталкивался с этим?
Может есть рекомендуемое оптимальная, максимально допустимое величина сжатия, при превышении которой скорость чтения падает?
p.s. глобалы архивные, запись в них не планируется, только чтение.
Последовательность действий:
1. GBLOCKCOPY
2. GCOMPACT

Alexey MaslovУпомянут GBLOCKCOPY, значит, они как раз в другую БД данные перегоняли. После этого GCOMPACT не нужен, этот шаг явно лишний. Стать хуже могло по 2 причинам:
- в БД все-таки временами что-то пишется
- сервер долго работал без перезагрузок, нужные данные закэшировались, а тут вдруг новая БД... начинай кэшировать по-новой.
1. После перегонки GBLOCKCOPY, проверили сжатие глобалов. Сжатие осталось в тех же пределах т.е. 75% т.к. на оригинале GCOMPACT запускался. (75% это тот максимум, что удалось выжать на не дефрагментированной базе)
2. На дефрагментированной БД, только после GCOMPACT произошло сжатие до 95%
3. База тестовая, ничего в нее не пишется в принципе. Проверялось как раз скорость чтения, после сжатия.
4. Насчет кэширования. Последовательно (именно несколько раз) запускался тест на скорость чтения в оригинале (БД до дефрагментации) и новой БД (после дефрагментации-сжатии).

NMNИз документации "Руководство по администрированию Caché версии 5.2" стр.59:
"Перед тем, как принять решение о дефрагментации первого или второго вида,
необходимо понимать, что производительность работы БД после проведенной
дефрагментации может снизиться, а не повыситься. Такое может случиться, если
дефрагментуемые глобалы находятся в постоянной модификации пользовательскими
процессами. Поэтому дефрагментация приведет к тому, что при «плотном» блоке система
будет каждый раз расщеплять блок при его модификации. Поэтому дефрагментацию
рекомендуется проводить только для тех глобалов, для которых заведомо известно их
дальнейшее поведение – они не должны меняться. Скорость чтения после
дефрагментации возрастет."

Тема именно о скорости чтения, а не записи.
Оговорено, что глобал=архив, доступ только на чтение.

ser_shu-Serg-,

Что подразумевается под "скоростью чтения"?
Перебор данных в глобалах?
Выполнение sql запросов?

Если строятся рабочие массивы во время выполнения запросов внутри этой же бд - то будет замедление на расширения файла БД. Проверьте - увеличивается ли файл БД.

прямой доступ к глобалу т.е. перебор данных на cos. Ни каких sql (свят, свят, свят)

Блок А.Н.Вот мне тоже интересно, GCOMPACT это действительно дефрагментация? а то подозрительно быстро походит.

По теме - когда-то давно на относительно небольших базах всякие операции типа выгрузить все глобалы и загрузить их в чистую базу - очень сильно тормозили работу на день-два.

GCOMPACT - кажется немного уменьшал производительность, но не уверен, давно это было.
Нет, это не дефрагментация. Блоки как были разбросаны по дисковому пространству, так и будут.
Дефрагментацию (но не сжатие глобалов) даст GBLOCKCOPY

nvp
Только вот результат не всегда предсказуем. Сжатая БД может оказаться в каталоге tmp или в рабочем каталоге остается временный файл cache.dat.tmp

Так ведь там же явно указывается имя новой базы (создается стандартно, перед сжатием).
cache.dat.tmp нет.
Или скорость на чтения сжатой базы миф или есть ограничение (по скорости чтения) на степень сжатия.