AnkoriПроблема на платформе 5.0.21. Изначально проблема была в том, что при однотипных задачах и работе пользователей после начала работы с постоянной периодичностью полностью останавливается работа базы из-за высокой активности процесса демона записи WRTDMN который полностью загружает процессор. Убирать журналирование не хочется. База весит 150 Гб. Возможно от большого объема данных. Причем при сжатии базы утилитой GBLOCKCOPY аналогичная ситуация происходит - сжатие останавливается и объем новой базы достигает всего 4-5 Гб. Каким образом можно выйти из данной ситуации? Возможно ли вариации на тему приоритетов процессов Cache в настройках платформы?
Сервер: Windows Server 2003 SP2 R2 SE x64 Eng, 2x Intel Xeon 3,2 Ghz, 3x SAS 15k 300 Gb in RAID5, 3xSAS 10k 140 Gb in RAID5, память 16 Гб
У нас Cache 5.0 с базами по 100+ Гб работает нормально, правда они не журналируются (базы фактически для сбора статистики по периодам, критический код всегда можно обрамить транзакцией).

1. В cconsole.log какие записи появляются в моменты "зависания"?
2. Места достаточно на диске с установленным Cache? (С включенным журналированием и активной работой с базой журналов накапливается много. Если место кончится, то сначала встанет процесс WRTDMN, затем через некоторое время отключится журналирование, а дальше (после ручного освобождения места на диске) Cache будет нестабильно работать до перезапуска службы.)
3. Попробуйте перед GBLOCKCOPY отключить журналирование на новой базе.