Подготовленный оператор против хранимой процедуры с RefCursor

Question

Я вызываю хранимые процедуры Oracle, которые возвращают RefCursors в моем приложении C #. Пример хранимой процедуры приведен ниже.

CREATE OR REPLACE
PROCEDURE "DOSOMETHING"(
    P_RECORDS OUT SYS_REFCURSOR)
AS
BEGIN
    OPEN P_RECORDS FOR
    SELECT SOMETHING FROM SOMETABLE;
END;

При использовании OracleDataReader для чтения результатов для этого, каждый раз, когда процедура вызывается, база данных анализирует процедуру. После долгих поисков я обнаружил, что с помощью .NET при использовании RefCursor.

исключить этот вызов синтаксического анализа невозможно.

Однако, если я просто вызову процедуру с использованием подготовленного оператора, как показано ниже, этого вызова синтаксического анализа можно избежать.

public void DoSomething()
{
    var command = ServerDataConnection.CreateCommand();
    command.CommandType = CommandType.Text;
    command.CommandText = "SELECT SOMETHING FROM SOMETABLE";
    command.Prepare();

    using (var reader = command.ExecuteReader())
    {
        while (reader.Read())
        {
            DoSomethingToResult();
        }
    }
}

Мой вопрос: какой из этих методов окажет минимальное влияние на производительность? Повлияет ли изменение процедур на подготовленные операторы во избежание вызовов синтаксического анализа еще более негативно на производительность приложения?

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

Answer 1

Использование курсора ref в PL / SQL будет вызывать синтаксический анализ при каждом открытии курсора.Один и тот же вызов разбора будет выдаваться каждый раз, когда вы звоните command.Prepare().Как и сейчас, ваш .NET-код будет анализировать запрос так же, как и код PL / SQL.

Вы можете повторно использовать объект команды без дополнительных вызовов синтаксического анализа, если вам нужно выполнить точно такой же запрос (простоизменение параметров).Однако эти разборы будут мягкими, поэтому производительность может быть незаметной (большая часть работы выполняется в режиме разборки, когда база данных впервые сталкивается с запросом).Поскольку ваш запрос возвращает много строк, объем работы, связанной с мягким анализом, безусловно, ничтожен по сравнению с объемом работы для фактического извлечения этих строк.