Kru пишет:

> Есть большая таблица (пусть будет несколько десятков миллионов записей)
> которая читается 24 часа 7дней в неделю.
>
> Таблица реплицируется.
>
> Данные в неё нужно помещать из текстовых файлов, при этом данные должны
> синхронизоваться, т.е. добавляться или обновляться.
>
> Как наиболее оптимально осуществить помещение данных?
> Если их много, то как не залочить таблицу обновлениями, и при этом ещё
> обеспечить, чтобы все изменения нормально реплицировались?

RLL тут рулит, я считаю. На Insert конкурентные пользователи вообще
ничего не чувствуют, а на UPDATE -- хуже, конечно, потому как
там надо ещё и о плане запроса думать, но всё же тоже должно быть
хорошо.

> Чисто в теории, на ум приходит создать отдельную базу и в ней
> прмежуточную партиципрованную таблицу. В базе выставить select into
> bulkcopy, чтобы небыло логирования, после чего грузить данные пачками
> определённого размера использую параллельную BCP c ключами First and
> Last и проставляя в таблице номер пачки.
> Как только пачка загрузится, выполнить синхронизацию данных для этой
> пачки с основной таблицей - сначала обновление и потом добавление, после
> чего таким же образом обарботать следующую пачку.

Что-то намудрено. Попробуй просто тупо в лоб решение сначала,
с таблицей на DOL/RLL.



Я не очень понял с репликацией.

Если это источник, то репликация сосёт данные из лога, таблица
тут будет не задействована. Елси она -- приёмник, то, в общем,
будет всё то же самое, что я выше описал -- т.е. тоже всё ОК.


Ну и, на DOL не забывай REORG пускать периодически.
Posted via ActualForum NNTP Server 1.4

Kru пишет:

> Я боюсь, что если делать UPDATE на большое количество записей (скажем
> миллион), то RLL, скорее всего не поможет. Произойдёт эскалация
> блокировки до табличного уровня.

Так в том и трюк, чтобы эскалацию не допускать.
Я конечно не знаю, сдюжит ли ваш сервер такую большую транзакцию
без эскалации. Ну и можно кусками делать.


> Загружаемая таблица - это источник.
>
> Но такой вопрос - если сразу обновить/вставить миллион записей, то
> выдержит ли репликация?

Чаще всего, она это не выдерживает.

К тому же учти, что один UPDATE на миллион записей на реплике
превратиться в миллион UPDATE-ов по 1-ой записи.

> Как-то чутьё подсказывает, что не надо такие большие транзакции делать,
> отсюда и идея, разбить данные на пачки.

Ну, очень хорошая идея. У нас на продакшн серверах например
запрещено большими пачками менять данные (разработчикам).


> Т.к. в реальной жизни пока не получается получить опыт работы с реально
> большими объемами, то хотелось бы узнать мнение практикующих спецов.

Ну, я не могу сказать, что мы такое вот часто делаем, но
в общем ты движешься правильной дорогой.

Маленькие пачки транзакций, RLL, настройка эскалации.

А в идеале хорошо бы вообще эти UPDATE-ы раздельно провести
на двух или сколько у тебя там серверах, чтобы через
очередь репликации не тащить миллион записей.
Posted via ActualForum NNTP Server 1.4