Тормоза начались внезапно. Без каких либо видимых причин. Никаких изменений не вносилось, ничего не обновлялось.

MSSQL 2014. Windows Server 12. Все находится на облаке. Три разных сервера. 1C, RDP, MSSQL
Дефрагментация логического диска - 0%
Регламент база проходит еженедельно.

Везде загрузка процессоров до 30-50% Память также до 30% загрузка

Очень ужасно медленно работает на любой стадии, даже просто скролинг журнала документов.

Вот ошибка, с которой иногда вообще вываливается база:
http://i.piccy.info/i9/f5260e9eabe277494c12fb0454593c39/1565865928/15734/1281046/Error_MsSql.png

Что делать, не пойму.
Может подскажите мысли какието?

(0) ставлю на говнокод)
Анализ ТЖ делай

10 лет все работало, а тут вдруг говнокод всплыл? Мало того, никто ничего не проводит и не запускает никаких тяжелых отчетов, после перезагрузки всех серверов сразу идут торможения (просто в открытом журнале документов скролинг, к примеру). Ну и если-бы какой-нибудь говно-запрос тормозил-бы базу (нагружал) - то и загрузка процессорного времени MSSQL была-бы до 100% а так все 12 процессоров 1-2% загрузки

(2) и хотите сказать 10 лет изменений в конфигурацию не вносились совсем совсем?

(2) нет, корявый код кстати процессор то особо и не кушает

(2) Настало время тех самых историй

(4) достаточно вместо внутреннего внешнее соединение сделать и будут такие проблемы, я уже сталкивался.
По этому запись и анализ ТЖ

и ветки такие стали возникать попарно : если есть одна с постгри, то вскорости возникает почти такая же с мс скулем

(7) франчи взялись не рассчитав силенок

(4) (5) Нет конечно, просто началось вчера вечером с наростающим темпом, и сегодня пришло практически до колапса. Ничего не изменяли ни в 1С ни в серверх точно неделю или больше.

"Дефрагментация логического диска - 0%" у вас рейд посыпался или бэды)

(10) Ну на диске где лежит база, находится ТОЛЬКО файлы базы и все. Они не фрагментированы

16% фрагментация где системные файлы Win.server 2012 и MSSQL

Свободное место проверил?

Размер журнала какой?

(10) +1. Ставлю на сыплющийся рэйд.

(10) И как определить, что посыпался Рейд или бед блоки, если мы на облаке у сторонней организации? Как можно проверить скорость доступа к дискам и скорость чтения/записи?

(16) Ну тогда вопрос к сторонней организации. Почему они снижают IOPS?

(16) Проверить производительность SQL сервера

http://www.sql.ru/forum/11245/proverka-proizvoditelnosti-sql-server

http://www.sql.ru/forum/1111422/test-na-proizvoditelnost

Проверь SQL, как он реагирует.
Зайди на удаленный хост и посмотри, как там дела с ресурсами :)

(16) Спросить низзя?

+ Бекапы надеюсь вы на удаленке не храните? :)

(22) Храним :-(

(23) Расстрелять

https://support.microsoft.com/en-us/help/2545989/fix-a-time-out-occurred-while-waiting-for-buffer-latch-error-when-many

(24) И техжурнал не настроен, как я понял. Я, просто, не сильный спец в этих нюансах (производительности), но нагибают именно меня сейчас.

(26) Ну на боевой базе может и не нужен постоянно.

Тут, выяснилось, что на Облаке есть нюансы у поставщика услуг, которые они не сильно хотели афишировать...уроды. Но объяснили, что у них что-то происходит сейчас с дисковыми массивами, и возможны!!! тормоза. Как по мне - ТОРМОЗИЩА

(28) Бэкапы быстрее копируйте! Чудики :-)

(24) А бекапить на сетевой ресурс - это проблема? Всмысле - настроить бекапирование на удаленный диск (сеть 100 мегабит VPN) - есть проблема или нюансы? С локальным диском проблем не возникало.
И еще каждую ночь делается "снимок" всех серверов, который хранится 6 дней.

Тут у нас тоже в бухгалтерии начались необъяснимые тормоза в бухгалтерии в регламентированной отчетности. Так выяснилось, что какой-то умной голове пришла умная мысль сделать значение "предъявлять НДС" у признака договора рассчитываемым значением.

(30) Главное чтобы после тормозов осталось что бэкапить)

// И еще каждую ночь делается "снимок" всех серверов, который хранится 6 дней.

Это так обещали или проверили и действительно этими "снимками" можно спасти базу в ее ночном варианте?

(33) Снимки поднимали - работают

(34) Ну... ясное дело, что инфа там будет не вся... а на момент снимка.

ТЖ - если настроить на рабочей базе - то это также замедляет работу?

(30) какой нибудь Syncthing поставьте, там есть возможность вроде ограничить поток чтобы юзеры не страдали

Короче - у провайдера облака "рассыпалась" логическая целостность дисковых массивов (рейдов или как оно там)... Сейчас идет их "сборка"...

Шо оно такое, хрен пойму... но пока оно не "соберется"... наверное нет смысла что-то и делать со своей стороны

(38) Это примерно на сутки. Я бы скопировал бэкап... :-)

(38) Если Rebuild raid тогда тормоза на долго.
(39) Вообще взять бы статистику у этого провайдера по таким событиям. И смотреть в  сторону другого. Раз прозевал такие вещи.

(39) С Бекапом уже позаботились, правда по каким-то причинам, во время бекапа завис сервер, вернее, подвис...потом отпустило его, но все базы перешли в режим "in recovery".

У меня другой вопрос:

Можете дать ссылку на хорошее описание и скрипты, для ежедневного/еженедельного регламентного обслуживания баз MS-SQL (дефрагментация, реиндексация, оптимизация и.т.д.). А то это настраивал не я, а хочется сравнить/убедиться, что с этой точки зрения все Ок.

ПС: Базы две штуки 250 гигабайт и 750 гигабайт каждая. Около до 500 пользователей.

(41) На ИТС смотрите. там есть описание

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

(6) Внешнее и левое много когда может быть быстрее внутреннего

админы случайно все по виртаулкам не распихали?

(45) Распихали конечно. Это нормально.

(46) Это когда нормальные админы