Транзакции SQL: TSQL против VB.NET?

Question

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

Я хотел бы узнать, какие (если они есть) различия между использованием транзакции SQL в приложении и записью в хранимую процедуру с помощью оператора TSQL. Нам нужно было бы реструктурировать хранимые procs и vb-код, чтобы заставить это работать, и я не уверен, что это стоило бы усилий в это время.

Public Sub RetrieveTData(ByVal cID As String, ByVal cnn As SqlConnection) As Boolean

    Dim sqlTran As SqlTransaction
    cnn.Open()
    sqlTran = cnn.BeginTransaction

    Try
        If Not DataAlreadyTransferred(cID) Then

            Dim Command As New SqlCommand("usp_BigNasty_CopyDataFromDB1toDB2")
            Command.CommandType = CommandType.StoredProcedure
            Command.Transaction = sqlTran
            Command.Parameters.AddWithValue("@cID", cID)
            Command.Connection = cnn

            Command.ExecuteNonQuery()
            sqlTran.Commit()
        Endif

    Catch ex As Exception
        sqlTran.Rollback()
        Throw
    Finally
        cnn.Close()
    End Try

End Sub

Мы не уверены, происходит ли тайм-аут в DataAlreadyTransferred() или usp_BigNasty_CopyDataFromDB1toDB2 из-за того, как написано try / catch. Мы можем реструктурировать этот код, но потребуется около недели, чтобы запустить его в производство (сегодня в test / dev ошибок не возникает)

DB1 - постоянное хранилище, используемое и другими приложениями
DB2 - рабочий набор, используемый только Web App

DataAlreadyTransferred(cID) сначала проверяет, есть ли у DB2 какие-либо копии записей, если DB2 делает и эти записи чистые, она удаляет их (данные могли измениться в DB1, и нам нужна самая последняя версия). Если данные DB2 загрязнены, они остаются одни и никакие данные не удаляются.

usp_BigNasty_CopyDataFromDB1toDB2 копирует строки приблизительно из 20-30 различных таблиц и копирует перманентные копии из DB1 в DB2, создавая, по сути, рабочий набор, из которого Web App может получить доступ

Мы знаем, что это неэффективно, и изучаем способы его улучшения, просто еще не успели ...

Я считаю, что транзакции в коде приложения блокируют гораздо больше таблиц, чем действительно необходимо. Если мы переместим их в хранимые процедуры, за один раз будет заблокировано меньше таблиц, что повысит наши шансы на устранение условий тупиковой ситуации / проблем тайм-аута, которые мы наблюдаем сегодня. Просто не уверен в этом ..

Спасибо за любой вклад.

Answer 1

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

Я бы предложил один хранимый процесс, который проверяет и , очищает и пишет = один атомарный вызов на сервер.

Я бы также подумал о репликации, чтобы данные работали в реальном времени или даже зеркалировались, если в DB2 много DB1. Пусть движок БД сделает это?

Answer 2

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

Я все еще собираюсь заняться оптимизацией всего этого процесса, так как он все еще довольно медленный для объема данных, которые он обрабатывает ...