Устранение неполадок в Microsoft OLE DB Driver for SQL Server

Область применения:SQL ServerБаза данных SQL AzureУправляемый экземпляр SQL AzureAzure Synapse AnalyticsБаза данных SQL в Microsoft Fabric

Используйте эту статью, чтобы определить неисправную стадию работы OLE DB, выбрать следующую проверку и найти подробные инструкции по устранению неполадок. Руководство использует текущего поставщика, MSOLEDBSQL19. Для специфических дефектов и изменений обновлений, специфичных для релиза, см. раздел Известные проблемы и Основные различия в версиях.

Определите симптом

Зафиксируйте полное описание ошибки и все доступные записи об ошибках перед изменением настроек. Верхний HRESULTуровень , например DB_E_ERRORSOCCURRED, сам по себе не определяет причину. Записывайте, произошёл ли сбой при загрузке провайдера, открытии соединения, выполнении команды, получении данных или фиксации транзакции.

Симптом Начните здесь
Провайдера не удаётся найти, или класс не зарегистрирован. Регистрация провайдера и архитектура
Вход неудачный, доступ запрещён или интегрированная аутентификация проваливается. Ошибки входа и аутентификации
Цепочка сертификатов недоверена, или название сертификата не совпадает. Сбои сертификатов TLS
Сервер или экземпляр не могут быть найдены, либо соединение отклонено. Сбои обнаружения сети и экземпляров
Параметры не работают, значения усечаны или данные не могут быть преобразованы. Ошибки преобразования параметров и данных
Соединение обрывается, восстановление не происходит или истёкает тайм-аут. Потеря соединения и тайм-ауты
Отсутствуют детали ошибок или вам нужна трассировка для поддержки. Диагностика и отслеживание

Для сбоев соединения сравните приложение с тестом соединения Universal Data Link (UDL). Используйте один и тот же компьютер, провайдера, архитектуру процесса, идентификацию аутентификации, сервер, базу данных и настройки шифрования. Успешный тест с другим провайдером или идентификатором не доказывает, что конфигурация приложения работает.

Регистрация провайдера и архитектура

Ошибки, такие как Поставщик не найден или REGDB_E_CLASSNOTREG (0x80040154, Класс не зарегистрирован), указывают на то, что загрузка провайдера выполняется до аутентификации SQL Server.

  1. Проверьте провайдера, которого запрашивает заявка. MSOLEDBSQL19 и MSOLEDBSQL обозначают разные основные версии. Установка текущего драйвера не меняет выбор провайдера в приложении. Следуйте шагам миграции , если приложение всё ещё запрашивает другого провайдера.
  2. Проверьте архитектуру процесса, на котором размещено приложение. 32-битное приложение нуждается в 32-битном провайдере, даже на 64-битной Windows. Для сервисной или запланированной задачи проверьте исполняемый файл и аккаунт, используемые этим хостом, а не только вашей средой разработки.
  3. Установите или отремонтируйте драйвер с помощью поддерживаемого установщика на компьютере, где запускается приложение. Установщик x64 включает как 64-битные, так и 32-битные драйверы. Проверьте необходимые зависимости в разделе «Установить драйвер OLE DB » и системные требования. Не копируйте библиотеки драйверов с другого компьютера вместо установки.
  4. Повторите тест UDL с соответствующей архитектурой и провайдером. Если всё работает, но приложение всё равно не может загрузить провайдера, сравните эффективный выбор провайдера и архитектуру хоста с тестом.

Если в тексте ошибки явно указан adal.dll, проверьте известную проблему библиотеки аутентификации, а не рассматривайте это как отсутствие поставщика SQL Server.

Ошибки входа и аутентификации

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

  1. Для ошибки SQL Server 18456 попросите администратора базы данных проверить соответствующую запись и состояние ошибок сервера. Проверьте режим аутентификации, статус входа, запрошенную базу данных и доступ к базе данных с помощью MSSQLSERVER_18456. Не думайте, что каждое отклонение входа означает неправильный пароль.
  2. Для интегрированной аутентификации подтвердите идентичность, под которой работает приложение. Аккаунт службы или аккаунт запланированных задач может отличаться от пользователя, успешно протестировавшего соединение. Если сообщение содержит Cannot generate SSPI context, см. устранение неполадок интерфейса поставщика поддержки безопасности (SSPI) и поддержку основного имени субъекта-службы (SPN).
  3. Для Microsoft Entra ID проверьте, что выбранный метод аутентификации соответствует среде выполнения приложения и что его идентификация имеет доступ к целевой базе данных. Ознакомьтесь с настройками, специфичными для метода, и ограничениями токена доступа в разделе Use Microsoft Entra ID. Не комбинируйте токен доступа с конфликтующими свойствами аутентификации или учетных данных.
  4. Сравните действующие параметры с соответствующей таблицей ключевых слов строки подключения. IDBInitialize::Initialize, IDataInitialize::GetDataSourceи объекты данных ActiveX (ADO) используют разные таблицы ключевых слов. Проверьте в таблице интерфейс, который использует ваше приложение.

Текст «Неверно указано основное имя целевого субъекта» может появляться в разных контекстах. Если это сопровождается сообщением Cannot generate SSPI context, проверьте проверку подлинности Windows и SPN. Если ошибка идентифицирует сертификат или рукопожатие при шифровании, используйте следующий раздел.

Сбои сертификатов TLS

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

  1. Для Цепочка сертификатов была выдана недоверенным органом, проверьте сертификат, который предоставляет SQL Server, и цепочку выдающих сертификатов, которой доверяет клиентский компьютер. Настройте действительный серверный сертификат и установите необходимые доверенные корневые и промежуточные сертификаты через процесс управления сертификатами вашей организации.
  2. При несовпадении имени сертификата сравните имя сервера или слушателя, используемое приложением, с именами в сертификате. Используйте сертификат, который охватывает предполагаемое имя соединения. Если приложение намеренно использует другое имя соединения, ознакомьтесь с задокументированным свойством HostNameInCertificate , прежде чем настраивать ожидаемое имя сертификата.
  3. Проверьте настройки эффективного шифрования и валидации, включая настройки реестра. Проверьте таблицы шифрования и проверки сертификатов на наличие приоритета и Strict поведения. В Strict режиме драйвер проверяет сертификат независимо от настройки trust-server-certificate.
  4. Если сбой начался во время миграции, проверьте раздел устранения неполадок при переходе на основную версию, включая тип значения свойства шифрования и ограничение на использование ServerCertificate вне режима Strict.

Используйте требования к сертификатам для SQL Server и устранение неполадок, связанных с недоверенной цепочкой сертификатов для получения подробных сведений. Сохраняйте включенные шифрование и валидацию сертификатов в производстве. Отключение любого из них не решит проблему с развертыванием сертификатов.

Сбои обнаружения сети и экземпляра

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

  1. Проверьте имя сервера, имя экземпляра и настроенный порт прослушивания у администратора базы данных. Убедитесь, что сервис базы данных работает и что назначенный протокол и слушатель включены. Не предполагайте, что каждый экземпляр слушает на порте 1433.
  2. Для удалённого соединения с протоколом управления передачей (TCP) тестируйте известную конечную точку, используя формат серверного имени tcp:<server>,<port> драйвера. Сохраняйте те же настройки аутентификации, базы данных и шифрования. См. Ключевые слова строки подключения для ключевого слова сервера, применимого к вашему интерфейсу.
  3. Если явный хост и порт работают, а именованный экземпляр — нет, проверьте браузер SQL Server и поиск экземпляра. Проверьте сервис браузера и путь порта User Datagram Protocol (UDP) 1434, где используется обнаружение браузера.
  4. Если явно указанная конечная точка также недоступна, проверьте разрешение имён DNS, маршрутизацию и доступ через брандмауэр к фактическому прослушиваемому порту с хоста приложения. Устраняйте ошибки подключения, связанные с сетью или конкретным экземпляром, а не меняйте сразу несколько параметров подключения.

Для слушателей группы доступности также ознакомьтесь с поддержкой высокой доступности и восстановления после катастроф. Для LocalDB используйте поддержку LocalDB для проверки локального экземпляра и пользовательского контекста вместо применения удалённых шагов обнаружения TCP.

Ошибки преобразования параметров и данных

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

  1. Сравните каждый маркер параметра ? с его порядковым номером привязки, направлением и метаданными. Когда вы используете ICommandWithParameters::SetParameterInfo, сопоставьте тип источника SQL с командой или хранимой процедурой. Не думайте, что метаданные параметров всегда получаются автоматически. Проверьте параметры команды на предмет ограничений вывода и поведения параметров выхода.
  2. Проверьте статусы привязки аксессоров, а также статус и длину каждого возвращённого значения, а не только общий статус HRESULT. При сбоях при задании свойств проверьте dwStatus каждого свойства. Частично успешный результат возврата, такой как DB_S_ERRORSOCCURRED, может потребовать проверки массива статусов, даже при отсутствии объекта ошибки. См. коды возврата.
  3. Для преобразования или усечения сравните тип и размер буфера потребителя с фактическими метаданными столбца или параметра. Проверьте точность и масштаб для числовых значений, допустимых диапазонов и дробных секунд для значений даты и времени, а также длины байтов для буферов символов. Изучите DBSTATUS_E_CANTCONVERTVALUE, и не считайте DBSTATUS_S_TRUNCATED полным значением. Используйте сопоставление типов данных, получение строк и преобразования даты и времени для применимых правил.
  4. Если связанные выходные параметры отсутствуют, исчерпайте возвращённые наборы строк перед их чтением. Следуйте: Используйте IMultipleResults для обработки нескольких наборов результатов. Для потоковых выходных параметров обработайте или закройте незавершённые потоки перед запросом следующего результата, как описано в разделе Поддержка потоковой передачи для выходных параметров.

Для сопоставлений, специфичных для ADO, ознакомьтесь с разделом Использование ADO с драйвером OLE DB и ограничениями аутентификации для DataTypeCompatibility в разделе Использование Microsoft Entra ID. Не добавляйте настройки совместимости, не проверив обе параметры.

Для повреждённых узких строк в столбце sql_variant после обновления драйвера проверьте существующую известную проблему и процедуру восстановления SSVARIANT перед изменением сохранённых данных.

Потеря соединения и тайм-ауты

Запишите, когда соединение в последний раз работало, какая операция не получилась и как долго она длилась. Различайте эти случаи перед изменением настроек повтора или тайм-аута.

Этап сбоя Проверки и подробные рекомендации
Открытие подключения. Сначала проверьте ошибки провайдера, сети, аутентификации и TLS. Проверьте действующее значение DBPROP_INIT_TIMEOUT или соответствующее ключевое слово подключения. См. раздел «Устранение неисправности при тайм-ауте соединения».
Выполнение команды. Проверьте DBPROP_COMMANDTIMEOUT или параметр тайм-аута команд в приложении. Изучите блокировки и производительность запросов с помощью средства устранения неполадок тайм-аута запросов. Увеличение тайм-аута соединения не меняет тайм-аут команд.
Повторное использование холостого соединения. Проверьте условия восстановления, настройки повторных попыток и ожидаемые ошибки в устойчивости соединения в режиме простоя. Восстановление может быть неудачным, если тайм-аут команды истечёт до завершения повторного подключения.
Потеря соединения во время выполнения или фиксации. Сопоставьте события клиента и сервера, чтобы проверить наличие прерывания сети, перезагрузки сервера или отказа. Определите результат операции, прежде чем решать, безопасно ли повторять её повторение.

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

Предостережение

Если соединение обрывается во время записи или коммита, клиент может не знать, зафиксировал ли SQL Server эту транзакцию. Не повторяйте операцию вслепую. Проверьте результат или используйте дизайн приложения, который предотвращает дублирование эффектов, прежде чем пробовать снова.

Диагностика и отслеживание

Собирайте диагностические данные в момент сбоя, прежде чем другие, не связанные с ним вызовы поставщика заменят информацию об ошибке.

  1. Зафиксируйте неудачную операцию, временную метку и часовой пояс, затраченное время и HRESULT. Для нативных клиентов OLE DB извлекайте все доступные записи через IErrorInfo и IErrorRecords, а не только первое описание. Включите SQLSTATE, а также собственный номер ошибки SQL Server, если он доступен через ISQLErrorInfo. См. Получение сведений об ошибке и Подробные сведения об ошибке SQL Server. Для ADO фиксируйте коллекцию Errors соединения.
  2. Собирайте статусы по свойству, по привязке и по значению для методов, которые таким образом сообщают об ошибках. Отсутствие объекта ошибки не делает результат с частичным успехом безопасным для игнорирования.
  3. Сопоставьте сбой клиента с журналом ошибок сервера или расширенными событиями. Когда доступно, записывайте ClientConnectionID и ActivityID. Сбой перед входом может произойти без идентификатора клиентского соединения.
  4. Если записи об ошибках недостаточны, используйте диагностическую информацию Access в журнале расширенных событий для трассировки драйверов и настройки корреляции. Соберите ограниченный след вокруг репродукции и прекратите обводить после этого.

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

Удалите пароли, токены доступа и другие секреты из настроек соединения и логов. Проверяйте трассировки на наличие текста запроса и конфиденциальных данных, храните их с ограниченным доступом и передавайте только через утверждённый канал поддержки.