База данных из группы доступности AlwaysOn восстановлена ​​как обычная база данных - PullRequest
0 голосов
/ 11 июня 2018

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

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

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

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

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

System.Data.SqlClient.SqlConnection.OnError (исключение SqlException, логическое прерывание соединения, действие 1 wrapCloseInAction) + 2444190
System.Data.SqlClient,TdsParser.TryRun (runBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader DATASTREAM, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, булева & 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, логический isInternal, логическое значение forDescribeParameterEncryption) + 409
System.Data.SqlClient.SqlCommand.RunExecuteReaderTds (CommandBehavior cmdBehavior, RunBehavior runBehavior, логический возвратный поток, Booleout, логический запрос на возврат данных, логический запрос на повторный вызов класса+ 2127
System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior runBehavior, логическое значение returnStream, метод String, завершение TaskCompletionSource`1, тайм-аут Int32, задание и задача, логическая переменная типа Boolele, используется логическое преобразование с логическим и логическим значением, Boolean 9);1020 * System.Data.SqlClient.SqlCommand.RunExecuteReader (CommandBehavior cmdBehavior, RunBehavior runBehavior, логический returnStream, метод String) + 64
System.Data.SqlClient.SqlCommand.Ex22 * метод поведенияSystem.Data.SqlClient.SqlCommand.ExecuteDbDataReader (поведение CommandBehavior) + 41
System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader (поведение CommandBehavior) + 12
System.Data.Common.DbDataAdapter.FillInternal (набор данных DataSet, таблицы данных DataTable [], Int32 startRecord, команда IntR maxRecords, команда String srcTable, IDbCommand, поведение CommandBehavior 10)System.Data.Common.DbDataAdapter.Fill (DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, команда IDbCommand, поведение CommandBehavior) + 136
System.Data.Common.DbDataAdapter.Fill (DataSet dataSet 1027et) + 88* MyApp.SqlHelper.ExecuteDataset (соединение SqlConnection, CommandType commandType, String commandText, SqlParameter [] commandParameters) + 163
MyApp.PermitFunctions.GetSystemMessages (String sp, 2132 iPermitppAnPACIDID, Int32, IDN32An32P, Int32, SIP, IDID, Int32, IntA, ID32, Int32, S32, iPNID, Int32, SIP, ID32, Int32, Int32, SIP, Int32, SIP, ID32, Int32, Int32, Int32, S32, ip32, Int32, Int32, Int32, Int32, Int32, Int32, Int32, Int32, Int 32, iPNID), Int32, SIP, ID32, Int..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

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

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

EDIT

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

. Таким образом, на сервере имеется:

  • копия RO производственной базы данных (MyDB)
  • нормальная, автономная БД, восстановленная для QA - MyDB_demo

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

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

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

  • ошибка выдается в SQLHelper классе, вспомогательном классе от MS для работы с SQL Server, в ExecuteDataset функции
  • ошибка выдается ТОЛЬКО для одной хранимой процедуры - много другиххранимые процедуры, а также прямые операторы SQL работают просто отлично
  • Я проверил хранимую процедуру, думая, что она может случайно содержать жестко запрограммированную ссылку на имя БД - это не
  • и странную часть - Iзапустить хранимую процедурус теми же параметрами, которые вызываются из приложения в SSMS - и он работает нормально - без ошибок

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

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

Спасибо

1 Ответ

0 голосов
/ 11 июня 2018

Из-за странной (читай: глупой) ситуации, что виновник SP не работает только при вызове из приложения, но работает нормально при попытке в SSMS, я попробовал «глупый» подход: я проверил его код, закомментировал два полякоторые были установлены с помощью подвыборов, таких как select top 1 from ..... where.... (на самом деле я заменил их значения на фиктивные), и я изменил поле Order By , которое было изначально указано как "InspectionType" Desc, из которого я удалил кавычки.

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

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

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


РЕДАКТИРОВАТЬ

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

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

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

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

...