Приложение непрерывно пишет в БД SQL данные, приблизительно каждые 10 секунд выполняя одну и ту же процедуру. Так продолжается много часов. Внезапно, при очередном вызове происходит сбой operation timeout expired.
Место на диске есть. С чем это м. б. связано?
Recovery = simple
Auto close = off
Auto shrink = off
Auto create statistic = on
Auto update statistic = on
Auto update statistic asynchronously = on
Здравствуйте, john_silver, Вы писали:
_>Приложение непрерывно пишет в БД SQL данные, приблизительно каждые 10 секунд выполняя одну и ту же процедуру. Так продолжается много часов. Внезапно, при очередном вызове происходит сбой operation timeout expired. _>Место на диске есть. С чем это м. б. связано?
Если связь с базой по сетке — то она могла сбойнуть.
Я бы посмотрел содержимое sys.messages, что происходило в то же время в субд. А если там пусто, то добавил бы трассировку https://msdn.microsoft.com/ru-ru/library/hh245121.aspx.
Здравствуйте, john_silver, Вы писали:
_>Приложение непрерывно пишет в БД SQL данные, приблизительно каждые 10 секунд выполняя одну и ту же процедуру. Так продолжается много часов. Внезапно, при очередном вызове происходит сбой operation timeout expired. _>Место на диске есть. С чем это м. б. связано? _>Recovery = simple _>Auto close = off _>Auto shrink = off _>Auto create statistic = on _>Auto update statistic = on _>Auto update statistic asynchronously = on
С блокировками: кто-то или что-то залочило объект, к которому обращается твоя процедура. Если это так, что даже если conn.CommandTimeout = 0, то ты всё равно будешь получить timeout expired, притом мгновенно, без всякого ожидания
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>С блокировками: кто-то или что-то залочило объект, к которому обращается твоя процедура. Если это так, что даже если conn.CommandTimeout = 0, то ты всё равно будешь получить timeout expired, притом мгновенно, без всякого ожидания
Не, сбой происходит не мгновенно, реально проходит время ожидания, а потом таймаут.
Здравствуйте, Философ, Вы писали: Ф>С блокировками: кто-то или что-то залочило объект, к которому обращается твоя процедура. Если это так, что даже если conn.CommandTimeout = 0, то ты всё равно будешь получить timeout expired, притом мгновенно, без всякого ожидания
И с каких это пор? С дедлогом не путаем?
А по факту — либо блокировка, либо сеть, либо диски. Если приложение непрерывно пишет данные в БД,
то проверь, нет ли в эти моменты автоматического приращения размера файлов, — это может быть причиной.
Здравствуйте, john_silver, Вы писали:
_>Это в логах сервера можно посмотреть?
На 100% сейчас не скажу, не помню уже. Но предупреждение о том, что автоприращение заняло слишком много времени точно есть.
Поищи в логах по фильтру 'autogrow'.
Здравствуйте, _ABC_, Вы писали:
_AB>На 100% сейчас не скажу, не помню уже. Но предупреждение о том, что автоприращение заняло слишком много времени точно есть. _AB>Поищи в логах по фильтру 'autogrow'.
Здравствуйте, john_silver, Вы писали:
_>А вообще это норма, что приращение размера БД занимает десятки секунд?
Я бы не сказал, что это норма. Но это часто встречается, особенно при установках по умолчанию.
Если размеры приращения файла поставлены большие, то потребуется время как ни крути.
По умолчанию автоприрост задан в 10 процентов от размера файла, что в итоге выливается
в совершенно неразумные цифры. Размер файла 300 ГБ — прирост файла будет 30 ГБ.
Надо ставить фиксированный разумный размер приращения, давать логину сервиса SQL Server права
Perform Volume Maintenance Tasks (aka instant file initialization). Эти права помогут быстро
приращать файлы данных, без предварительной инициализации выделенного места нулями.
Файл лога всё равно будет при приращении инициализироваться нулями, тут ничего не поделаешь, специфика
архитектуры. Логу поможет только установка разумного фиксированного размера автоматического приращения.
Ну и регулярный мониторинг свободного места и ручное приращение в тех. окно, разумеется, чтобы избежать
проблем в горячие часы.
_>Железо, вроде, нормальное.
Железо-то нормальное может быть. Но, допустим, 50 ГБ приращения, да еще с инициализацией, и на отличном железе не
мгновенно произойдет.
Здравствуйте, _ABC_, Вы писали:
_AB>Если размеры приращения файла поставлены большие, то потребуется время как ни крути. _AB>По умолчанию автоприрост задан в 10 процентов от размера файла, что в итоге выливается _AB>в совершенно неразумные цифры. Размер файла 300 ГБ — прирост файла будет 30 ГБ.
Параметры приращения стоят по умолчанию, 1Мб для базы и 10% для лога. Размеры базы и лога сейчас где-то по 5Гб каждый.
Вероятно, надо поэкспериментировать с настройками.
Здравствуйте, john_silver, Вы писали:
_>Параметры приращения стоят по умолчанию, 1Мб для базы и 10% для лога.
1 МБ — это не по умолчанию, ЕМНИП. И оба параметра неразумные стоят.
1МБ — слишком мало, тем более для базы в которую постоянно пишут.
_>Вероятно, надо поэкспериментировать с настройками.
Надо. Почитай best practices, почитай про VFL size и адаптируй под себя.
В любом случае это надо сделать — чтения на час-полтора, работы минут на... ну двадцать от силы
на первый раз.
