Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Настраиваемая логика повторных попыток (CRL) — это механизм на основе правил, который автоматически повторяет неудачные инструкции или начальные попытки подключения на основе выбранного вами номера ошибок SQL Server с параметрами времени, которые вы управляете. CRL появился в Microsoft JDBC Driver 12.10 для SQL Server.
CRL не связано с устойчивостью неактивного соединения и свойствами connectRetryCount / connectRetryInterval. Механизм восстановления при простое прозрачно восстанавливает разорванные соединения, а connectRetryCount повторяет первоначальную аутентификацию через фиксированные интервалы при ошибках из встроенного списка временных ошибок. CRL позволяет решить , какие ошибки можно повторить, сколько раз и сколько времени ожидать между попытками. Все три механизма можно использовать вместе.
Что такое повторные попытки CRL
CRL обрабатывает два отдельных сценария, каждый из которых управляется собственным свойством подключения:
| Сценарий | Недвижимость | При выполнении повторной попытки | Активировано |
|---|---|---|---|
| Сбой выполнения инструкции | retryExec |
При выполнении инструкции (например, , executeQueryexecuteUpdate, executeили пакетного выполнения) |
Число SQLServerException ошибок которого совпадает с настроенным правилом инструкции |
| Начальный сбой подключения или проверки подлинности | retryConn |
Внутри цикла повторных попыток подключения драйвера (который зависит от connectRetryCount и loginTimeout) |
SQLServerException во время проверки подлинности, номер ошибки которого совпадает с настроенным правилом подключения, или, по умолчанию, любая временная ошибка, уже охваченная встроенным списком повторных попыток |
Для инструкций драйвер повторно выполняет только команду, завершившуюся сбоем. Драйвер не сбрасывает текущее состояние транзакции, поэтому правила следует строить с учётом ошибок, после которых сеанс остаётся пригодным для использования, например ошибки «жертва взаимоблокировки» (1205) или «время ожидания блокировки» (1222).
Для соединений CRL дополняет или заменяет встроенный в драйвер список временных ошибок соединения. См. правила повторных попыток подключения для + семантики префикса.
Включить CRL
CRL имеет два уровня:
- Уровень повторных попыток подключения включен по умолчанию: если
connectRetryCount > 0(значение по умолчанию равно 1), драйвер повторяет встроенный список ошибок временного подключения. - Слой настройки (ваши собственные правила
retryExecиretryConn) по умолчанию отключен. Оба свойства являются пустыми строками, если они не заданы. Их можно задать с помощью URL-адреса JDBC,Propertiesобъекта или объектаSQLServerDataSource. Драйвер удаляет необязательные{...}оболочки во всех трех формах.
Фрагменты кода на Java в этой статье для краткости опускают импорты и объявления классов.
В URL-адресе JDBC
Каждое правило (или весь список правил) должно быть упаковано в фигурные скобки ({...}), так как URL-адрес JDBC используется ; в качестве разделителя:
jdbc:sqlserver://server;databaseName=db;retryExec={1205,1222:3,2*2:select,update}
jdbc:sqlserver://server;databaseName=db;retryConn={+<customErrorNumber>}
С объектом Properties
Properties props = new Properties();
props.setProperty("user", "...");
props.setProperty("password", "...");
props.setProperty("retryExec", "1205,1222:3,2*2:select,update");
props.setProperty("retryConn", "+<customErrorNumber>");
Connection c = DriverManager.getConnection("jdbc:sqlserver://server;databaseName=db", props);
С SQLServerDataSource
Те же методы задания существуют в интерфейсе ISQLServerDataSource :
SQLServerDataSource ds = new SQLServerDataSource();
ds.setServerName("server");
ds.setDatabaseName("db");
ds.setRetryExec("1205,1222:3,2*2:select,update");
ds.setRetryConn("+<customErrorNumber>");
Синтаксис правила
Одно правило имеет до трех разделов, разделенных двоеточием:
<errorNumbers> : <retryTimings> : <queryFilter>
| Секция | Обязательно? | Значение |
|---|---|---|
errorNumbers |
Yes | Один SQL Server номер ошибки или несколько разделенных запятыми (например, 1205 или1205,1222). В правилах подключения необязательный начальный элемент + управляет тем, будут ли сохраняться существующие временные ошибки. |
retryTimings |
Требуется для правил инструкции . Опустить правила подключения. |
retryCount[,initialRetryTime[<op>retryChange]] где <op> — + (аддитивный) или * (мультипликативный). |
queryFilter |
Необязательные правила инструкции | Разделенный запятыми список ключевых слов SQL. Драйвер преобразует значение в нижний регистр при разборе и приводит ранее выполненный SQL-запрос к нижнему регистру во время выполнения. Правило запускается, когда список присоединенных фильтров содержит первый маркер выполняемого SQL. Опустить третий раздел, чтобы отключить фильтрацию. |
Чтобы использовать несколько правил в одном свойстве, разделяйте их с помощью ; и заключайте каждое правило в {...} при указании их в URL JDBC.
Параметры времени
Для правила оператора с временными параметрами retryCount, initialRetryTime <op> retryChange:
-
retryCount: количество дополнительных попыток, которые драйвер выполняет после первого сбоя. Значение0отключает повторную попытку. Отрицательные значения недопустимы. -
initialRetryTime: количество секунд, ожидаемых до первого повтора. Значение по умолчанию —0. -
<op>: оператор, который может быть+или*. Значение по умолчанию —+. -
retryChange: сумма, примененная к вычислению последующих времени ожидания. Значение по умолчанию —2. Если операнд —*, аretryChangeопущен в правиле, драйвер задаетretryChange = initialRetryTime.
Important
Если вы указываете initialRetryTime без явного операнда (например, 3,5), драйвер использует значения по умолчанию для операнда и retryChange (+ и 2). Задержки не являются постоянными. Они увеличиваются на 2 при каждой повторной попытке. Чтобы задать фиксированную задержку, используйте явную форму retryCount,N+0 (например, 3,5+0).
Драйвер вычисляет время ожидания попытки i (на основе 0) во время синтаксического анализа:
| Операнд | Подождите попытку i |
|---|---|
+ (аддитивная) |
initialRetryTime + (retryChange * i) |
* (умножение) |
initialRetryTime * (retryChange ^ i) |
Примеры строк времени:
| String | Число повторных попыток | начальное время повторной попытки | Операнд | повторная попыткаChange | Последовательность ожидания (секунды) |
|---|---|---|---|---|---|
3 |
3 | 0 (по умолчанию) |
+ (по умолчанию) |
2 (по умолчанию) | 0, 2, 4 |
3,5 |
3 | 5 |
+ (по умолчанию) |
2 (по умолчанию) | 5, 7, 9 |
3,5+5 |
3 | 5 | + |
5 | 5, 10, 15 |
3,2*2 |
3 | 2 | * |
2 | 2, 4, 8 |
4,1* |
4 | 1 | * |
1 (равно initialRetryTime, поскольку операнд — *, а retryChange опущен) |
1, 1, 1, 1 |
Раздел retryTimings может содержать не более одной запятой. Более одной запятой вызывает R_invalidParameterNumber.
Правила повторных попыток инструкции (retryExec)
Правила для инструкций повторяют неудавшееся выполнение инструкции. Когда оператор вызывает SQLServerException, драйвер:
- Ищет номер ошибки, вызвавшей сбой, в наборе правил для разобранной инструкции.
- Если правило существует и текущее число попыток меньше
retryCount, при необходимости проверяется, соответствует ли последний выполненный SQL значениюqueryFilterправила. - Если все совпадает, драйвер ожидает
waitTimes[retryAttempt]секунд (в зависимости отqueryTimeout, см. Взаимодействие с queryTimeout и connectRetryCount) и повторно выполняет инструкцию. - Если не подходит ни одно правило, драйвер повторно генерирует исключение.
Формат (инструкции)
{errorNumber(s):retryCount[,initialRetryTime[<op>retryChange]][:queryFilter]}
Правила инструкции должны содержать раздел времени.
retryCount обязателен. Правило, содержащее только номер ошибки, интерпретируется как правило для соединения, поэтому в операторах всегда указывайте как минимум retryCount.
Примеры (инструкции)
| Правило | Эффект |
|---|---|
{1205:3} |
Повторная блокировка жертвы (1205) до 3 раз, не подождите между повторными попытками. |
{1205,1222:3,5+5} |
Повторите попытку взаимоблокировки жертвы и тайм-аут блокировки до 3 раз, ожидая 5, 10 и 15 секунд. |
{2714:2,1*2} |
Повторите попытку "объект уже существует" до 2 раз, ожидая 1 и 2 секунды. |
{1205:4,2+2:select,update} |
Повторите попытку, только если оператор сбоя начинается с select или update. |
{1205:3,5+5};{1222:2,2} |
Два независимых правила, разделённые ;. |
Перечисление нескольких номеров ошибок (например, 1205,1222) — это сокращённая запись. Драйвер разворачивает правило в отдельную запись для каждой ошибки, при этом все записи используют одни и те же временные параметры и фильтр запроса.
Правила повторных попыток подключения (retryConn)
Правила подключения работают с существующим циклом повтора подключения. Этот цикл активен только в том случае, если connectRetryCount > 0 значение по умолчанию равно 1. Цикл уже повторяет попытки при возникновении ошибок из встроенного списка временных ошибок подключения с интервалом в connectRetryInterval секунд, не более connectRetryCount дополнительных попыток, и ограничен значением loginTimeout.
Правило подключения содержит только раздел с номером ошибки. В нём нет таймингов или фильтрации запросов:
{[+]errorNumber(s)}
- Если не указано
+, настроенные правила заменяют встроенный список временных ошибок. Повторно обрабатываются только те ошибки, которые вы перечислили. - С
+(например,{+4060}), настроенные правила добавляются во встроенный список. Повторно выполняются как ваши ошибки, так и параметры драйвера по умолчанию.
Режим замены или добавления является глобальным для всего retryConn значения. Если в каком-либо правиле в этом значении отсутствует +, драйвер переключается в режим замены для всех правил в этом значении. Например, retryConn={+4060};{40143} не добавляет 4060 и 40143 в встроенный список. Правило 40143 не включает +, поэтому встроенный список отбрасывается, и повторные попытки выполняются только для 4060 и 40143. Чтобы добавить оба, напишите retryConn={+4060};{+40143} (или retryConn={+4060,40143}).
Цикл подключения по-прежнему использует connectRetryInterval и connectRetryCount для управления интервалами и ограничения. Правило CRL расширяет или заменяет набор ошибок, которые имеют право на повторную попытку.
Примеры (подключения)
| Правило | Эффект |
|---|---|
{+<customErrorNumber>} |
Добавьте настраиваемый номер ошибки в встроенный временный список ошибок. |
{+<customError1>,<customError2>} |
Добавьте несколько пользовательских номеров ошибок в встроенный временный список ошибок. |
{4060} |
Повторите попытку только при ошибке 4060. Встроенные временные ошибки больше не извлекаются CRL. |
Note
retryConn не изменяет loginTimeout семантику. Существующий цикл повторных попыток подключения по-прежнему ограничивает общее прошедшее время и досрочно прекращает попытки, если следующая connectRetryInterval приведёт к тому, что прошедшее время превысит loginTimeout.
Встроенный временный список ошибок подключения
Цикл повторных попыток подключения уже повторяет попытки при следующих ошибках без какой бы то ни было настройки CRL, при условии, что connectRetryCount > 0. Указание любой из этих ошибок в правиле retryConn с + не имеет эффекта (они уже охватываются). Используйте правило retryConn, когда нужно добавить ошибку, которой нет в этом списке, или когда нужно полностью убрать список, используя форму no-+ replace.
Note
Не нужно добавлять распространенные Azure SQL временные ошибки подключения, такие как 40197, 40501, 40613, 49918, 49919 или 49920. Встроенный список уже повторяет их.
| Ошибка | Message | Troubleshooting |
|---|---|---|
| 64 | Подключение к серверу успешно установлено, но затем произошла ошибка при входе. (поставщик: поставщик TCP, ошибка: 0 — указанное сетевое имя больше недоступно.) | TCP-соединение оборвалось во время рукопожатия. Это не ошибка учетных данных. Если проблема сохраняется, проверьте, нет ли нестабильности сети на стороне клиента, ошибок аппаратной разгрузки сетевого адаптера или промежуточного устройства, которое разрывает полуоткрытые соединения. |
| 233 | Клиенту не удалось установить подключение из-за ошибки во время процесса инициализации подключения перед входом. | Сбой транспорта предварительного входа или TLS. Сервер обычно возвращает это, если он не может принять подключение (исчерпание ресурсов, максимальное число подключений или неподдерживаемый клиент). Это не ошибка учетных данных. Проверьте работоспособность сервера, а затем проверьте loginTimeoutпараметры TLS и совместимость версий TLS клиента и сервера. |
| 4060 | Не удается открыть базу данных database_name , запрошенную именем входа. Вход не удался. | Вход прошел проверку подлинности, но не мог открыть запрошенную базу данных. К временным причинам относятся переходное состояние базы данных (переключение при отказе, восстановление, масштабирование) или ее автоматическая приостановка. Постоянные причины (база данных не существует, логин не имеет доступа) не будут устранены повторной попыткой; проверьте имя базы данных, сопоставление логина и состояние базы данных. |
| 4221 | Не удалось выполнить вход в read-secondary из-за длительного ожидания на HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING. |
Вторичный экземпляр, доступный для чтения, не смог принять вход, так как версии строк по-прежнему отсутствуют в незавершённых транзакциях на момент повторной инициализации реплики. Чтобы смягчить проблему, избегайте длительных транзакций записи на первичном сервере; повторная попытка обычно завершается успешно после того, как на первичном сервере будут зафиксированы или отменены открытые транзакции. |
| 10053 | При отправке запроса на сервер произошла ошибка транспортного уровня. (поставщик: поставщик TCP, ошибка: 0 — установленное соединение было прервано программным обеспечением на хост-компьютере.) |
Локальная сторона прервала соединение (Windows Sockets WSAECONNABORTED). Часто причиной является сбой keepalive или закрытие локальным сетевым стеком неактивного или полуоткрытого соединения. Проверьте состояние сети на стороне клиента, таймеры keepalive в ОС, а также локальный брандмауэр или VPN-клиент. |
| 10054 | При отправке запроса на сервер произошла ошибка уровня транспорта. (поставщик: поставщик TCP, ошибка: 0 — существующее подключение было принудительно закрыто удаленным узлом). |
Удалённая сторона отправила TCP-сброс (сокеты Windows WSAECONNRESET). Распространенные причины: сбой однорангового процесса, брандмауэр ввел сброс или шлюз Azure SQL закрыл неактивное подключение. Для сценариев сброса простаивающих соединений включите TCP keepalive на стороне клиента или сократите тайм-аут простоя пула подключений. |
| 10928 | Идентификатор ресурса: N. Ограничение типа для базы данных равно N и достигнуто. См. sys.dm_exec_sessions для получения сведений об использовании. |
Достигнут предел управления ресурсами для базы данных (сеансы, рабочие потоки или запросы). Определите тип ограничения из сообщения, а затем уменьшите параллелизм, масштабируйте базу данных или сократите длительные операции хранения ресурса. |
| 10929 | Идентификатор ресурса: N. Минимальная гарантия типа ограничения — N, максимальное ограничение — N , а текущее использование базы данных — N. Однако сервер в настоящее время слишком занят для поддержки запросов больше N для этой базы данных. | База данных превысила минимально гарантированный уровень, и лежащий в ее основе сервер ограничивает производительность. Повторная попытка обычно бывает успешной, когда нагрузка на соседний узел снижается. Постоянное повторение таких случаев означает, что вам нужен более высокий тарифный план или менее шумная среда. |
| 40020 40143 40166 40540 |
Сообщение в слоте Error code %d об ошибке 40197 во время переключения при отказе. |
Встроенные в сообщение об аварийном переключении 40197 подкоды, которые в некоторых путях появляются как основной код ошибки. Драйвер перечисляет каждую форму по отдельности, поэтому повторяет попытку для любого из двух вариантов. Обработайте их так же, как 40197. |
| 40197 | При обработке вашего запроса служба обнаружила ошибку. Повторите попытку. Код ошибки N. | Обновление программного обеспечения, сбой оборудования или другое событие переключения при отказе в Azure SQL. Повторное подключение маршрутизирует вас к работоспособной реплике. Встроенный код ошибки определяет тип переключения при отказе. О повторяющихся случаях следует сообщать с указанием идентификатора трассировки сеанса. |
| 40501 | Служба занята. Повторите запрос через 10 секунд. Идентификатор инцидента: guid. Код: N. | Ограничение производительности ядра Azure SQL. Рекомендуемая минимальная задержка перед повторной попыткой — 10 секунд. Постоянное ограничение производительности означает, что вы превысили допустимый лимит DTU/vCore; увеличьте объем ресурсов или уменьшите уровень параллелизма. |
| 40613 | В настоящее время база данных database_name на сервере server_name недоступна. Повторите попытку подключения позже. Если проблема сохраняется, обратитесь в службу поддержки клиентов и укажите ему идентификатор трассировки сеанса guid. | База данных недоступна, как правило, во время переключения при отказе или ненадолго во время операции масштабирования. Повторите попытку с увеличивающейся задержкой; если проблема сохраняется дольше нескольких минут, запишите идентификатор трассировки сеанса и создайте обращение в службу поддержки. |
| 42108 | Не удается подключиться к пулу SQL, так как он приостановлен. Возобновите пул SQL и повторите попытку. | Выделенный пул SQL (Synapse) находится в приостановленном состоянии. Повторная попытка помогает только в том случае, если что-то параллельно возобновляет пул. Возобновите пул явным образом или запланируйте рабочую нагрузку после возобновления. |
| 42109 | Пул SQL разогревается. Повторите попытку. | Выделенный пул SQL возобновляется. Повторите попытку в обратном режиме, пока он не будет в сети; Разогревание обычно занимает несколько минут. |
| 49918 | Не удается обработать запрос. Недостаточно ресурсов для обработки запроса. | Плоскость управления не смогла выделить ресурсы для запроса в данный момент. Повторите попытку на обратном выходе. Постоянно повторяющиеся случаи указывают на нехватку ресурсов в регионе. |
| 49919 | Не удается обработать запрос на создание или обновление. Для подписки N выполняется слишком много операций создания или обновления. | Ограничение параллелизма на уровне подписки для операций управления. Уменьшите количество параллельных вызовов создания и обновления или разнесите их по времени. |
| 49920 | Не удается обработать запрос. Слишком много операций, выполняемых для подписки N. | Ограничение параллелизма на уровне подписки для операций в полете. Уменьшите параллелизм или дождитесь завершения выполняющихся операций. |
Канонический список драйвера — это перечислениеTransientError в SQLServerError.java. Текст сообщения об ошибке взят из временных ошибок подключения к Azure SQL. Ошибки на уровне инструкций (например, ошибка 1205 «жертва взаимоблокировки» или ошибка 1222 «истечение времени ожидания запроса на блокировку») не входят в этот список, поскольку цикл повторных попыток подключения срабатывает только при первоначальном подключении. Чтобы повторить эти ошибки, используйте retryExec правило.
Загрузка правил из файла свойств
Если для подключения не заданы retryExec или retryConn, CRL ищет файл с именем mssql-jdbc.properties рядом с JAR-файлом драйвера в classpath. В файле используется базовый key=value синтаксический анализ. Строки, начинающиеся с retryExec= или retryConn=, обрабатываются. Значения используют тот же синтаксис, который описан в этой статье, при этом ; разделяет несколько правил.
Используйте точные имена ключей (retryExec и retryConn), без ведущих пробелов. Файл не анализируется как полный файл свойств Java. Драйвер выполняет литеральную startsWith проверку каждой строки, поэтому:
- Строки, начинающиеся с
#или любого другого префикса, кромеretryExec, / иretryConn, игнорируются. - Строки, ключ которых начинается только с
retryExecилиretryConn(например,retryExec2=...), обрабатываются как соответствующее свойство и могут вызывать ошибки синтаксического анализа. Не вводите пользовательские варианты.
Пример:mssql-jdbc.properties
retryExec=1205:3,5+5;1222:2,2
retryConn=+4060,40143
Если файл отсутствует, CRL записывает сообщение FINE в журнале com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic и продолжает работу без правил. Путь к файлу, используемый для поиска, указывается в этом сообщении журнала.
Значения строки подключения имеют приоритет. Если retryExec или retryConn не пусты в параметрах подключения, драйвер не обращается к файлу для этого свойства.
Поведение при обновлении правила
CRL поддерживает один набор правил на уровне JVM. После строительства драйвер обновляет правила лениво:
- Драйвер оценивает возможности обновления во время выполнения инструкции и повторных попыток подключения.
- Обновление происходит только через 30 секунд после предыдущего чтения.
- Если правила изначально поступили из
mssql-jdbc.properties, драйвер сравнивает метку времени последнего изменения файла с меткой времени, которую он сохранил при предыдущем чтении. Если файл изменился, драйвер повторно анализирует его. - Если правила изначально были получены из строка подключения, драйвер повторно применяет ранее сохраненное значение строки подключения.
Это означает, что изменения в mssql-jdbc.properties автоматически подхватываются примерно через 30 секунд без перезапуска приложения.
Important
Так как набор правил — это одноэлементный набор JVM, открытие второго соединения, которое задает другое retryExec или retryConn значение, заменяет правила для первого подключения. Считайте конфигурацию CRL параметром уровня процесса, а не параметром отдельного подключения, если несколько подключений в одной и той же JVM используют конфликтующие настройки.
Взаимодействие с queryTimeout и connectRetryCount
Повторные попытки инструкции и queryTimeout
При срабатывании правила инструкции драйвер сравнивает следующее время ожидания со значением уровня queryTimeout подключения:
- Если
queryTimeout >= 0иtimeToWait > queryTimeout, драйвер выдаётR_InvalidRetryIntervalвместо повторной попытки. Драйвер не повторно выполняет исходную ошибку. Это вызывает ошибку конфигурации. - Свойство подключения
queryTimeoutпо умолчанию имеет значение-1, поэтому по умолчанию сравнение пропускается и допускается любое ожидание. - Параметр
queryTimeout=0не отключает эту проверку, так как0 >= 0имеет значение true. ЛюбойtimeToWait > 0вызываетR_InvalidRetryInterval.
Если задано queryTimeout положительное значение, сохраните initialRetryTime + (retryCount - 1) * retryChange (аддитивное) или initialRetryTime * retryChange^(retryCount-1) (умножающее) значение под ним.
Повторные попытки подключения и connectRetryCount и loginTimeout
retryConn само по себе не активирует повторные попытки аутентификации. Существующие свойства остаются в силе:
-
connectRetryCount(по умолчанию 1, диапазон 0–255) — это количество дополнительных попыток проверки подлинности. Установите значение0, чтобы отключить повторные попытки аутентификации.retryConnне влияет, когдаconnectRetryCount = 0драйвер вызывает первый сбой. -
connectRetryInterval(по умолчанию 10 секунд, диапазон 1–60) — это ожидание между попытками. Первая повторная попытка выполняется немедленно. -
loginTimeout— общая граница. Драйвер прекращает работу заранее, если следующий интервал приведёт к тому, что прошедшее время превыситloginTimeout.
Дополнительные сведения см. в разделе "Устойчивость подключений( JDBC)".
Examples
Как справиться с взаимоблокировками и тайм-аутами блокировок при записи
jdbc:sqlserver://server;databaseName=db;retryExec={1205,1222:4,2*2:insert,update,delete,merge}
До четырех попыток для жертвы взаимоблокировки (1205) или времени ожидания блокировки (1222), с обратным выходом 2, 4, 8 и 16 секунд, но только для инструкций записи.
Повторное создание схемы при выполнении операций в режиме онлайн
retryExec={2714:2,1+1};{3702:2,1+1}
Повторите ошибку 2714 (object already exists) и 3702 (cannot drop database currently in use) дважды каждый, с 1 и 2 секундами ожидания.
Добавление пользовательской ошибки в список временных ошибок
retryConn={+<customErrorNumber>}
Добавляет пользовательский номер ошибки, который еще не указан в встроенном списке. Если добавить встроенную Azure SQL временную ошибку, например 40197, 40501, 40613, 49918, 49919 или 49920, ничего не изменится, так как драйвер уже повторяет его.
Настройте CRL через файл свойств
Поместите mssql-jdbc.properties рядом с JAR-файл драйвера:
retryExec=1205:3,5+5:select,update
retryConn=+<customErrorNumber>
Не задавайте retryExec или retryConn для подключения. Драйвер считывает правила из файла и перечитает после каждого изменения (проверяется каждые 30 секунд).
Устранение неполадок CRL
Включите логирование уровня FINE (или более детализированное) для логгера com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic, чтобы увидеть попытки чтения файлов и решения при разборе:
com.microsoft.sqlserver.jdbc.ConfigurableRetryLogic.level=FINE
Распространенные ошибки конфигурации:
| Ключ сообщения об ошибке | Причина |
|---|---|
R_invalidParameterNumber |
Ненумерный маркер появился, когда драйвер ожидал номер ошибки или параметр времени или retryTimings содержал несколько запятой. |
R_InvalidRuleFormat |
Правило содержит более 3 разделов, разделенных двоеточием. |
R_InvalidRetryInterval |
Вычисленное время ожидания правила инструкции превышает queryTimeout. Сократить время ожидания или увеличить queryTimeout. |
R_PathInvalid или R_URLInvalid |
Драйвер не смог определить путь для поиска mssql-jdbc.properties. |
R_errorReadingStream |
Ошибка ввода-вывода при чтении mssql-jdbc.properties. |
Note
Текст сообщения R_invalidParameterNumber выглядит так: Номер параметра {0} недопустим, и это та же ресурсная строка, которую драйвер использует для ошибок привязки параметров подготовленного оператора. Когда CRL выдаёт эту ошибку, недопустимым значением является токен правила повторных попыток (например, номер ошибки или элемент времени, который не является числом), а не индекс параметра PreparedStatement.
Что следует проверить, если правило не срабатывает:
- На самом деле исключение
SQLServerError.getErrorNumber()соответствует числу в правиле. SQL Server может упаковать некоторые сбои в разные числа в зависимости от контекста (например, взаимоблокировки и времени ожидания блокировки). - Для правил операторов с
queryFilterпервый токен SQL-запроса, который вы выполнили, отделённый пробельными символами и приведённый к нижнему регистру, находится в списке фильтров. Примечания иWITHCTEs изменяют первый маркер. -
retryCountПовторные попытки являются дополнительными попытками. Первое выполнение не учитывается. - Для правил соединения
connectRetryCountбольше 0, аloginTimeoutоставляет место как минимум ещё для одногоconnectRetryInterval. - Правило имеет правильную форму. Для правил инструкций требуется раздел времени. Правила подключения не должны.