Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
07.09.2012, 11:23
|
|||
|---|---|---|---|
|
|||
Ускорение оперативных запросов |
|||
|
#18+
Подскажите наиболее правильное архитектурное решение по следующей задаче: Приложение работает с БД (DB2 v 9.7). Определены 2 типа запросов к БД - оперативные и расчетные (на одних таблицах). Требуется определить более высокий приоритет для оперативных запросов. То есть при выполнении расчетных запросов не должна страдать производительность оперативных. Так же требуется периодически сбрасывать устаревшие данные из таблиц для ускорения оперативных запросов. Вижу пока 2 пути решения, но не знаю какой будет эффективнее: 1. создать новый экземпляр БД (архивный) и настроить репликацию данных с удалением из основной БД и накоплением в архивную БД. Настроить приложение для работы с 2 БД, все оперативные запросы выполнять в основной БД, расчетные - в архивной. 2. в БД создать новую архивную схему, где будут копии таблиц. Схема (вместе с таблицами) будет размещена на других разделах, что не будет влиять на работу основной схемы. А дальше как с 1 вариантом - периодическое вытеснение с разделением запросов. Возможно есть более простые решения,используя возможности DB2 (например, перераспределение табличных пространств между таблицами). Но в этом слабо разбираюсь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.09.2012, 11:43
|
|||
|---|---|---|---|
|
|||
Ускорение оперативных запросов |
|||
|
#18+
Rust(), Репликации создают дополнительную нагрузку на сервер и на сопровождение, это нужно тоже учитывать. Вместо репликации можно использовать копию, которую поднимать к определенному моменту. Сценарий простой - 2 базы, одна доступна, вторая в режиме наката логов. В момент Х переводим базу из роллфорворда в онлайн, перекаталогизируем, вторую восстанавливаем и переводим в накат журналов. И так по кругу, все это легко скриптуется и время недоступности архивной копии минимально. Разделить по нагрузке отчеты и оперативные запросы можно с помощью WLM. Если есть задача разделения данных на оперативные-архивные, то ESE позволяет сделать table partitioning. В этом случае задача с переносом в архив резко упрощается и не требует реоргов. Плюс можем получить ощутимый выигрыш в работе оперативных запросов. Andy ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=43&mobile=1&tid=1601729]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
35ms |
get tp. blocked users: |
2ms |
| others: | 10ms |
| total: | 159ms |

| 0 / 0 |
