Совместное использование курсора является (или было) большим преимуществом по сравнению с конкурентами.
По сути, тот же план запросов используется для сопоставления запросов. Приложение будет иметь стандартный набор запросов (например, получить заказы для этого идентификатора клиента). Простой способ состоит в том, чтобы обрабатывать каждый запрос индивидуально, поэтому, если вы видите «SELECT * FROM ORDERS WHERE CUSTOMER_ID =: b1», вы посмотрите, имеет ли таблица ORDERS индекс CUSTOMER_ID и т. Д. В результате вы можете потратить столько же времени на поиск метаданные, чтобы получить план запроса, как на самом деле получение данных. С простыми поисками по ключевым словам, план запроса легко. Сложные запросы с несколькими таблицами, объединенными в перекошенных столбцах, сложнее.
Oracle имеет кэш планов запросов, а старые / менее используемые планы устаревают, поскольку требуются новые.
Если вы не кэшируете планы запросов, существует предел того, насколько умным вы можете сделать свой оптимизатор, поскольку чем больше умных программ вы в него кодируете, тем большее влияние вы оказываете на каждый обрабатываемый запрос. Кэширование запросов означает, что эти накладные расходы возникают только при первом просмотре запроса.
Недостатком является то, что для совместного использования курсора необходимо использовать переменные связывания. Некоторые программисты не понимают этого и пишут код, который не передается, а затем жалуются, что Oracle не так быстр, как mySQL.
Еще одним преимуществом Oracle является журнал UNDO. После внесения изменений «старая версия» данных записывается в журнал отмены. Другая база данных хранит старые версии записи в том же месте, что и запись. Это требует операций по очистке в стиле VACUUM или вы сталкиваетесь с проблемами пространства и организации. Это наиболее актуально в базах данных с высокой активностью обновления или удаления.
Также у Oracle нет реестра с центральным замком. Бит блокировки хранится в каждой отдельной записи данных. SELECT не берет блокировку. В базах данных, где SELECT блокируется, у вас может быть несколько пользователей, считывающих данные и блокирующих друг друга или предотвращающих обновления, вводящих пределы масштабируемости. Другие базы данных блокировали запись, когда выполнялся SELECT, чтобы никто другой не мог изменить этот элемент данных (поэтому было бы согласованно, если бы тот же запрос или транзакция снова посмотрели на таблицу). Oracle использует UNDO для своей модели согласованности чтения (т. Е. Ищет данные в том виде, в котором они появились в определенный момент времени).