![](https://habrastorage.org/r/w780/getpro/habr/upload_files/919/577/647/919577647901ed82de133a642d05c420.jpeg)
Эта статья будет интересна в первую очередь архитекторам и консультантам по решениям на основе популярного продукта компании SAP – корпоративного хранилища данных SAP BW.
Если вы отвечаете за развитие корпоративного хранилища данных на базе SAP BW on HANA или SAP BW/4 HANA, вы рано или поздно (лучше – рано) задумаетесь о контроле роста объемов данных «колоночных» таблиц, которые загружаются в оперативную память сервера БД SAP HANA. По рекомендации SAP, суммарный объем табличных данных («поколоночных» и «строчных») таблиц в памяти не должен превышать эмпирического значения 50% от выделенной на SAP HANA памяти сервера(ов). В противном случае, процессы в SAP HANA станут выполняться менее предсказуемо в части длительности, а порой и просто стабильности. Это относится и к процессам трансформации данных в BW (т.н. DTP), и к выполнению пользовательских отчетов.
Столкнувшись с нехваткой памяти, SAP HANA инициирует процессы вытеснения из памяти сегментов (колонок поколоночных таблиц или их партиций), которые использовались наиболее давно и имеют более высокий приоритет к вытеснению. В SAP HANA за это отвечает параметр UNLOAD PRIORITY, который устанавливается на “поколоночную» таблицу и может быть изменен впоследствии. Однако, в ситуации, когда одновременно десяткам, а порой и сотням параллельных процессов требуется больше памяти, внутренним методам выделения и освобождения памяти в HANA приходится «в авральном режиме» решать задачу определения, сколько нужно вытеснить, что именно можно вытеснить и выполнить само вытеснение. Очевидно, что это не добавляет производительности процессам, ради которых это вытеснение и выполняется. И даже при наличии таких совершенных алгоритмов возникают ошибки нехватки памяти в HANA (OOM), что приводит к проблемам уже на уровне приложения SAP HANA, а именно – SAP BW. Это выражается в аварийном прерывании процесса. И хорошо еще, если этот процесс- некритичный пользовательский отчет. Совсем другое дело, если это ночная загрузка. Без должного реагирования пользователи утром могут не увидеть в отчетах свежие данные.