Мне нужно одновременно загружать данные в таблицу и запускать запросы на нее. Из-за характера данных я могу торговать целостностью для производительности. Как можно минимизировать накладные расходы на транзакции?Как минимизировать накладные расходы на транзакции в Oracle?
К сожалению, альтернативы, подобные MySQL, не могут быть использованы (по нетехническим причинам).
Помимо общих методов оптимизации, которые применяются ко всем базам данных, таким как устранение полного сканирования таблицы, удаление неиспользуемых или неэффективных индексов и т. Д. И т. Д., Вот несколько вещей, которые вы можете сделать.
No Archive Log режиме. Это жертвует способностью к восстановлению скорости./*+ APPEND */ hint. Это помещает данные в таблицу выше отметки о высокой воде, которая не создает UNDO. Недостатком является то, что существующее свободное пространство не используется.RAID 0 на большее количество дисков меньшего размера даст вам лучшую производительность вставки, но в зависимости от вашего использования RAID 10 с лучшей производительностью чтения может обеспечить лучшую подгонку.Это говорит о том, что я не думаю, что вы многое выиграете от любых этих изменений.
Вы хотите, чтобы изоляция транзакции считалась незафиксированной. Я не рекомендую это, но это то, о чем вы просили :)
Это позволит вам нарушить изоляцию транзакций и прочитать незафиксированные вставленные данные.
Прочтите эту статью Ask Tom: http://www.oracle.com/technology/oramag/oracle/05-nov/o65asktom.html.
UPDATE: Я действительно ошибался, Oracle действительно не поддерживает чтение незафиксированного уровня изоляции, они просто говорят об этом :).
Возможно, мне что-то не хватает, но поскольку читатели Oracle не блокируют писателей, а авторы не блокируют читателей, что именно проблема вы пытаетесь решить?
С точки зрения сеансов, которые читают данные, сеансы, которые делают вставки, на самом деле не добавляют каких-либо издержек (обновления могут добавить немного накладных расходов, так как читателю придется смотреть на данные в табличном пространстве UNDO в чтобы восстановить согласованное чтение данных). С точки зрения сеансов, вставляющих данные, сеансы, которые делают чтение, на самом деле не добавляют никаких накладных расходов. Конечно, ваша система в целом может иметь узкое место, которое заставляет различные сеансы бороться за ресурсы (т. Е. Если ваши вставки используют до 100% доступной пропускной способности ввода-вывода, это замедлит запросы, которые необходимо выполнить физический ввод-вывод), но это напрямую не связано с типом операций, выполняемых разными сеансами - вы можете наводнить подсистему ввода-вывода кучей пользователей отчетов так же легко, как и с несколькими сеансами вставки ,
В каких объемах вы смотрите? Вставляются ли вставки или многочисленные маленькие?
Прежде, чем ударить головой о стену, пытаясь придумать умные способы иметь хорошую производительность, создали ли вы простейшие прототипы, которые дадут вам лучшее представление о готовой производительности? Легко оказалось, что вам не нужно делать ничего особенного для достижения целей.
Как насчет того, чтобы попытаться отключить все ограничения в таблице, а затем вставить все данные, а затем снова включить их?
т. Е. Изменение ограничений набора сеансов = деффед;
Однако, если вы не устанавливали ограничения в таблице, которые можно было бы сделать возможными во время создания таблицы, может возникнуть небольшая проблема.
Как упоминается в этой статье, Oracle не поддерживает техническую поддержку READ UNCOMMITTED, только ее дух. – 2008-11-03 23:42:04
Я стою исправлены. – Bogdan 2008-11-05 15:58:55