База данных из группы доступности AlwaysOn восстановлена ​​как обычная база данных

У меня проблема с обычной базой данных SQL, восстановленной из базы данных, установленной в группе высокой доступности AlwaysOn в SQL Server 2017.

Я восстановил копию производственной базы данных на другом сервере для использования в качестве тестовой базы данных QA, также с другим именем - MyDB_demo.

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

Даже если мой conn str указывает на MyDB_demo, я получаю следующую ошибку

[SqlException (0x80131904): целевая база данных («MyDB») находится в группе доступности и в настоящее время доступна для подключений, когда намерение приложения установлено только для чтения. Дополнительные сведения о намерении приложения см. в электронной документации по SQL Server.]

Есть ли какая-либо ссылка во вновь восстановленной БД (теперь именуемой MyDB_demo), которая хранит исходное имя рабочей БД и почему она пытается получить к ней доступ?

Любое предложение приветствуется.

ИЗМЕНИТЬ

На самом деле сервер, используемый для восстановления MyDB_demo, является одним из вторичных узлов для группы доступности AlwasyOn; он также содержит копию RO рабочей базы данных, MyDB.

Итак, на сервере есть:

Следовательно, я понимаю сообщение об ошибке - было бы разумно, если бы я попытался напрямую получить доступ к вторичной, RO-копии производственной базы данных из строки подключения.

  • нормальная автономная БД восстановлена ​​для контроля качества - MyDB_demo
  • ошибка вылетает в SQLHelper классе, вспомогательном классе от MS для работы с SQL Server, в функции ExecuteDataset

Но я этого не делаю: строка подключения (которую я перепроверил) пытается подключиться к QA db, MyDB_demo.

Вот дополнительная информация:

Итак, похоже, что строка подключения МОЖЕТ быть изменена (!!!) каким-то образом самим NET-приложением и только для этой хранимой процедуры?

  • ошибка возникает ТОЛЬКО в одной хранимой процедуре - множество других хранимых процедур, а также прямые операторы SQL работают нормально
  • Я проверил хранимую процедуру, думая, что она может случайно содержать жестко закодированную ссылку на имя БД - это не так.
  • и странная часть - я запускаю хранимую процедуру с теми же параметрами, которые вызываются из приложения в SSMS - и она работает нормально - без ошибок
  • Из-за странной (читай: глупой) ситуации, когда виновник SP терпит неудачу только при вызове из приложения, но работает нормально при попытке в SSMS, я попробовал «глупый» подход: я проверил его код, закомментировал два поля, которые были установлены с дополнительными выборками, такими как MyDB_demo (на самом деле я заменил эти значения фиктивными), и я изменил поле Order By, которое изначально было указано как MyDB_demo, из которого я удалил кавычки.

Кто-нибудь когда-нибудь сталкивался с чем-то подобным?

Спасибо

RO копия производственной БД (MyDB)


database-restore sql-server-2017 alwayson
person bzamfir    schedule 10.06.2018    source источник

Ответы (1)


arrow_upward
0
arrow_downward

При этом SP внезапно начал нормально работать даже при вызове из приложения. Затем я вернул все изменения к исходным (добавил кавычки и вернул подвыборки), и SP продолжал работать нормально.

Итак... проблема решена. Глупый подход к глупой проблеме (!?!?!)

В любом случае, если у кого-то есть лучшая идея или объяснение того, что могло произойти, я был бы рад это услышать.

ИЗМЕНИТЬ

Я думаю, что я понимаю исправление. Путем редактирования и сохранения хранимой процедуры ее план запроса был перекомпилирован. Таким образом, исходная ошибка могла быть вызвана старым планом запроса. Но почему он ссылался на имя базы данных? Упоминается ли фактическое имя базы данных в планах запросов? Это выглядит немного странно для меня.

И еще вопрос (открытый):

Определяет ли оптимизатор SQL Server, работает ли БД в режиме высокой доступности, и при оптимизации запросов определяет, является ли запрос режимом только для чтения, и автоматически перенаправляет его на узел только для чтения? Даже если параметр ApplicationIntent только для чтения отсутствует в строке подключения? Потому что в данном случае этого не было, даже в продакшене — мы только что реализовали функциональность AlwaysOn и находимся в процессе обновления приложения, чтобы воспользоваться преимуществами узлов R/O.

Любые комментарии приветствуются

System.Data.SqlClient.SqlConnection.OnError(исключение SqlException, логическое значение breakConnection, действие 1, wrapCloseInAction) +2444190
System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose) +285
System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady) +4169
System.Data.SqlClient.SqlDataReader.TryConsumeMetaData() +58
System.Data.SqlClient.SqlDataReader.get_MetaData() +89
System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption) +409
System.Data.SqlClient.SqlComm and.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, логическое значение returnStream, логическое значение async, тайм-аут Int32, задача и задача, логическое значение asyncWrite, логическое значение inRetry, SqlDataReader ds, логическое описаниеParameterEncryptionRequest) +2127
System.Data.SqlCommanhClient.SqlExmand.Run cmdBehavior, RunBehavior runBehavior, логическое значение returnStream, метод String, завершение TaskCompletionSource`1, время ожидания Int32, задача и задача, логическое значение и usedCache, логическое значение asyncWrite, логическое значение inRetry) +911
runBehavior, логический returnStream, метод String) +64
System.Data.SqlClient.SqlCommand.ExecuteReader(поведение CommandBehavior, метод String) +240
System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(поведение CommandBehavior) +41< br> System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader(поведение CommandBehavior) +12
System.Data.Common.DbDataAdapter.Fi llInternal(набор данных DataSet, таблицы данных DataTable[], Int32 startRecord, Int32 maxRecords, String srcTable, команда IDbCommand, поведение CommandBehavior) +139
System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, команда IDbCommand, поведение CommandBehavior) +136
System.Data.Common.DbDataAdapter.Fill(DataSet dataSet) +88
MyApp.SqlHelper.ExecuteDataset(соединение SqlConnection, CommandType commandType, String commandText, SqlParameter[] commandParameters ) +163
MyApp. PermitFunctions.GetSystemMessages(String sp, Int32 iPermitID, Int32 iAppID, SqlConnection cn) +219
MyApp.Municipality.LoadSystemMessage() +3869
MyApp.Municipality.Page_Load(Отправитель объекта, EventArgs e) +101
System.Web.UI.Control.OnLoad(EventArgs e) +95
System.Web.UI.Control.LoadRecursive() +59
System.Web.UI.Control.LoadRecursive() +131
System.Web.UI.Page.ProcessRequestMain (логическое значение includeStagesBeforeAsyncPoint, логическое значение includeStagesAfterAsyncPoint) +678

person bzamfir    schedule 10.06.2018