Содержание статей:
- Как нам живется с Yandex Cloud Managed Service?
- Yandex Cloud Managed Service: создание и перенос баз.
- Yandex Cloud Managed Service: мониторинг, планы обслуживания, бэкапы и выводы.
Скажу так: - Нам досталась конфигурация отменно плохого качества, и проблем было не миновать. Без мониторинга не было ясно, что с этим куском легаси делать. Я до сих пор поражаюсь, как такой продукт продают и покупают. Я, конечно, в 1с всего 9 лет, но хуже купленной конфигурации не видел. Рекламировать не буду, эта поделка на совести создателей, хотя про совесть, наверно, нет смысла упоминать…
Зайдя в мониторинг, мы видим настроенные дашборды с возможностью их настроить. Можно менять моменты времени. Можно менять временной период.
Все наглядно и удобно.
Если мы нажмем на кнопку «Открыть в Мониторинге», мы попадем в основное меню Мониторинга.
Меню Мониторинга выглядит так:
Из меню мы можем у дашбордов настроить алерты
Посмотреть метрики более детально, убрать дашборды, создать новые дашборты
Нужна информация о проблемах?
Все просто!
Создаем канал
Настраиваем Алерт
И все.
Реально очень удобно сделано.
Алерт рассказал нам про беду. Как ловить тяжелые запросы?
Вот такие письма счастья стали приходить на почту:
Мы решили посмотреть через MS SQL Management Studio и увидели нехватку прав:
Мы спросили, почему нет прав, и получили ответ:
Мы, естественно, попросили права и нам права дали, но они могут слетать при обновлениях, такое с нами случалось. Когда права слетали, мы просили их вновь.
«Монитор» от Андрея Бурмистрова
Параллельно я хотел попробовать «Монитор» от Андрея Бурмистрова, рассказывать про данную конфигурацию не буду, так как он сам расскажет на Инфостарт Ивент 12 ноября.
Скажу только одно, на Yandex Cloud Managed Service for SQL он, к сожалению, не взлетит из-за ограничений.
Понадобится право «alter any event session», а его не дадут. Выпросить можно, но только на время.
В любом случае я обязан подойти и сказать Андрею лично огромное спасибо!
Параллельно мы настроили сервис от gilev.ru. Ну про этот сервис точно все знают.
Он, кстати, отработал нормально.
С другой стороны, есть инструмент, на который прав хватает и его достаточно для отлова и анализа запросов.
Хранилище запросов (Query store):
Прочитать можно тут -> Monitoring Performance By Using the Query Store - SQL Server | Microsoft Docs
Копировать инфу с первоисточника не буду.
Включаем и выставляем режим только запись.
Режим только запись собирает данные, после можно перевести в только чтение.
Как вы видите инструмент сам подсказывает, что не хватает индекса, остается только по запросу найти виновника и добавить индексы.
Что могу сказать? Забудьте про планы обслуживания!
Сразу вспоминается MS SQL Express и те же проблемы. Как вариант можно через Windows Task Manager запускать скрипты.
Я, естественно, на всякий случай поинтересовался:
Как видите из переписки:
Планируется возможность выбора скриптов и скорее всего скрипты будут от Ola Hallengren:
GitHub: https://github.com/olahallengren/sql-server-maintenance-solution
Awards:
 |
 |
 |
[UPD 2021/10/01] При настройке регламента на все ли хватит прав?
Сегодня пришла новая информация. Прав хватит не навсе!
Администратор спросил у Яндекс:
Занимаюсь задачей организации maintenance plan через sqlcmd, столкнулся с проблемой, для их реализации нужны права выше чем db owner, пример:
1. Обновление статистики - EXEC sp_updatestats;
Для запуска sp_updatestats пользователь должен быть владельцем базы данных (dbo, а не только членом роли db_owner) или быть членом фиксированной роли сервера sysadmin.
2. Очистка процедурного КЕШа - DBCC FREEPROCCACHE;
Требуется разрешение ALTER SERVER STATE на сервере.
Ответы Яндекс:
1 Нехватка прав по статистике :
2 Нехватка прав "ALTER SERVER STATE" :
По регламенту сейчас выполняется только создание бэкапов. Но все ли гладко с ними?
- Нельзя сделать бэкап конкретной базы средствами Yandex Cloud Managed Service for SQL
- Созданные автоматически бэкапы изолированы от вас. Вы не можете просто их скопировать.
- Можно запустить создание бэкапа кластера, но прервать создание бэкапа нельзя.
- При создании бэкапа может случиться ошибка и без техподдержки вы не узнаете, что пошло не так.
- В Yandex Cloud Managed Service for PostgreSQL нет возможности восстановить отдельную базу, можно восстановить лишь кластер.
- В Yandex Cloud Managed Service for SQL есть возможность восстановления базы, но у меня дело закончилось ошибкой и очередным отловленным багом…
Информация по ошибке:
Продукт пока сыроват, при этом сыроват не только Managed Service for SQL, но и Managed Service for PostgreSQL. Я общался с командой, использующей Managed Service for PostgreSQL, услышал те же проблемы, что и на Managed Service for SQL, а местами даже проблем больше. Я вижу, как продукт развивается, и понимаю, что он может улучшаться только если его используют. Огорчает, что не всегда есть гарантия того, что функционал отработает должным образом, часто чувствуешь себя бета-тестером. С другой стороны, нам ли привыкать? У нас с каждой новой версией платформы происходят чудеса. Мне нравится поддержка Яндекс, я вижу, как латаются баги и появляется новый функционал, мне нравится, что есть планы по развитию продукта и продукт меняется. Огорчает то, что некоторые вещи из простых превратились в марафон преодоления сложностей, это касается бэкапов и планов обслуживания. Я верю в то, что продукт будет вкусный и года через 2-3 появится интерес, и мы будем видеть доклады про внедрения с использованием Managed Service for SQL.
В плане масштабирования есть понятные ограничения (https://cloud.yandex.ru/docs/managed-sqlserver/concepts/limits) и, если капнуть глубже в плане масштабируемых систем я бы смотрел на Yandex Database (YDB), правда эта тема уже не совсем 1С, она около 1С. Хотя кто его знает, может быть, когда-нибудь 1С подружат с Yandex Database? Но это уже совсем другая история.
На этом заканчиваю, надеюсь статьи будут Вам полезны! Удачи в работе и интересных задач.
