Когда совершать изменения?

Question

Используя Oracle 10g, доступ к которому осуществляется через Perl DBI, у меня есть таблица с несколькими десятками миллионов строк, которые обновляются несколько раз в секунду, при этом они гораздо чаще читаются из другого процесса.

Скоро частота обновления увеличится на порядок (возможно, два). Кто-то предположил, что выполнение каждого N обновлений, а не после каждого обновления, будет способствовать повышению производительности.

У меня есть несколько вопросов:

• Будет ли это быстрее или медленнее, или это зависит от этого (планирование тестирования в обоих направлениях, как только можно получить достойную симуляцию новой нагрузки)
• Почему это поможет / ухудшит производительность.
• Если "это зависит ...", от чего?
• Если это поможет, каково лучшее значение N?
• Почему мой местный администратор базы данных не может дать полезный прямой ответ, когда он мне нужен?
  (На самом деле я знаю ответ на этот вопрос) :-)

EDIT:

@ codeslave: Спасибо, кстати, проиграл незапущенные изменения не проблема, я не удаляйте использованные исходные данные для обновления, пока я не уверен, что все ладно, кстати уборщица сделала ДВАЖДЫ отключает сервер: -)

Какой-то поиск в Google показал, что это может помочь из-за проблемы, связанной с откатом сегменты, но я до сих пор не знаю, эмпирическое правило для N каждые несколько десятков? сотни? тысяч?

@ diciu: Отличная информация, я определенно буду посмотрите на это.

Answer 1

В результате фиксации Oracle записывает данные на диск, т. Е. В файл журнала повторов, так что любая сделанная транзакция может быть восстановлена ​​в случае сбоя питания и т. Д. Запись в файл медленнее записи в память, поэтому фиксация будет выполняться медленнее, если она выполняется для многих операций подряд, а не для набора объединенных обновлений.

В Oracle 10g есть асинхронный коммит, который делает его намного быстрее, но менее надежным: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

PS Я точно знаю, что в сценарии, который я видел в определенном приложении, изменение количества объединенных обновлений с 5К до 50К ускоряет его на порядок (в 10 раз быстрее).

Answer 2

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

Answer 3

Сокращение частоты коммитов, безусловно, ускорит процесс, однако, поскольку вы часто читаете и пишете в эту таблицу, есть вероятность блокировок. Только вы можете определить вероятность одновременного обновления одних и тех же данных. Если вероятность этого мала, фиксируйте каждые 50 строк и следите за ситуацией. Боюсь проб и ошибок: -)

Answer 4

@ CodeSlave на ваши вопросы отвечает @stevechol, если я уберу ВСЕ добавочные коммиты, будут блокировки. Думаю, если ничего не получится, я последую его совету, выберу случайное число, отследю нагрузку и отрегулирую соответственно. При применении @diciu Twaks.

PS: транзакция поверх транзакции просто случайна, я получаю файлы, используемые для обновлений по FTP, и вместо того, чтобы немедленно их удалять, я задаю задачу cron, которая удаляет их через неделю (если никто, использующий приложение, не жаловался ) это означает, что если что-то пойдет не так, у меня есть неделя, чтобы поймать ошибки.

Answer 5

Если вы «не удаляете исходные данные, использованные для обновления, до тех пор, пока [вы] не будете уверены, что все в порядке», то почему бы вам не удалить все эти добавочные коммиты между ними и выполнить откат в случае возникновения проблемы? Похоже, вы фактически построили транзакционные системы поверх транзакций.

Answer 6

Быстрее / Медленнее?

Вероятно, будет немного быстрее. Тем не менее, вы рискуете столкнуться с тупиками, потерять незафиксированные изменения в случае катастрофического события (уборщица отключит сервер), FUD, Fire, Brimstone и т. Д.

Почему это поможет?

Очевидно, меньше операций фиксации, что, в свою очередь, означает меньше операций записи на диск и т. Д.

БД и прямые ответы?

Если бы это было просто, он тебе не понадобился.