Денисов Александр

364
Рейтинг

Филин
Александр Денисов



  •   Регистрация: 30.10.2008 (15 лет назад)

  •   Был(а) на сайте: 16.04.2024

Друзья
  • Екатерина Макаровв
  • cdmannnn cdmannnn
  • Elena Duyun
  • Леонид Мельников
  • Дмитрий Малышев
  • Алексей Кирин
  • Гордей Голиков
  • Дмитрий Чел
  • Евгений Зайцев
  • Sergey S
  • Юрий Былинкин
  • Андрей Волин
  • Александр Кузиков
  • Станислав Малютин
  • Григорий Шатров
Подписчики 36
Группы

Профессиональный разработчик

IE 2018 Докладчик

IE 2019 Докладчик

Докладчик Meetup

IE 2021 Докладчик

IE2021_msk Докладчик

IE2022 Докладчик

Рейтинг 364

Обслуживание индексов MS SQL Server: как, когда и, главное, зачем?
+46 –

Статья Системный администратор Программист Бесплатно (free) Нет файла Администрирование СУБД

Казалось бы, базовое знание: «индексы надо обслуживать, чтобы запросы выполнялись быстро». Но обслуживание индексов выполняется долго и может мешать работе пользователей. Кроме того, в последнее время популярны разговоры о том, что индексы можно вообще не обслуживать – насколько это оправданно? Рассмотрим: на что влияет обслуживание индексов, когда надо и когда не надо его выполнять, и если надо – как это сделать так, чтобы никому не помешать?

16.01.2024    6724    Филин    13       

46

MS SQL Server: изучаем планы запросов
+114 –

Статья Программист Запросы Бесплатно (free) Нет файла HighLoad оптимизация Запросы

Многие знают, что для ускорения работы запроса нужно «изучить план». При этом сам план обычно обескураживает: куча разноцветных иконок и стрелочек; ничего не понятно, но очень интересно! Аналитик производительности Александр Денисов на конференции Infostart Event 2021 Moscow Premiere рассказал, как выполняется план запроса и что нужно сделать, чтобы с его помощью находить проблемы производительности.

20.06.2023    17416    Филин    37       

114

MS SQL Server: ваши статистики не работают! Так ли все плохо на самом деле?
+43 –

Статья Программист MS SQL Бесплатно (free) Нет файла HighLoad оптимизация

Состояние и качество статистик критически важны для эффективной работы системы. Но у заметной части типовых конфигураций статистики просто не могут работать эффективно. О том, почему так происходит и что с этим делать, на конференции Infostart Event 2021 Post-Apocalypse рассказал Александр Денисов.

27.09.2022    6045    Филин    11       

43

Нестандартные блокировки при работе с OLAP-нагрузкой
+31 –

Статья Программист Платформа 1С v8.3 Бесплатно (free) Нет файла HighLoad оптимизация

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    4025    Филин    7       

31

Неочевидные проблемы производительности: важность системного подхода при анализе
+57 –

Статья Программист Платформа 1С v8.3 Россия MS SQL Бесплатно (free) Нет файла HighLoad оптимизация

Часто программисты и 1С-ники сталкиваются с совершенно необъяснимыми на первый взгляд проблемами. Но это потому, что их внимание направлено только на один сегмент системы, а не на всю систему полностью. О том, почему нужно стараться смотреть на ситуацию комплексно, рассказал специалист по производительности компании SOFTPOINT Александр Денисов.

19.07.2019    10715    Филин    12       

57

Обработка для определения ip и имени пользователя ОС на клиенте
+4 –

Инструменты и обработки Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Windows Абонемент ($m) Внешняя обработка (ert,epf) Инструменты администратора БД

Настоящий программист, а тем более админ, никогда не бегает по кабинетам, а все вопросы решает по "удаленке". Но вот когда источников таких вопросов становится больше десяти, начинаются определенные проблемы: к сожалению, не все пользователи могут быстро объяснить, за каким компьютером они работают. А когда в дело вступают терминальные сервера с автоматической балансировкой нагрузки, попытка выяснить, где работает пользователь превращается в непроходимый квест.

1 стартмани

19.09.2012    9562    27    Филин    11       

4

КД: Передача параметров из 7.7 в 8.x
+69 –

Инструменты и обработки Системный администратор Программист Платформа 1С v7.7 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv7 1С:Конвертация данных Абонемент ($m) Архив с данными Файловый обмен (TXT, XML, DBF), FTP Перенос данных 1C

В «Конвертации Данных» заложен удобный механизм передачи параметров – по сути переменных конвертации – между базами. Одна проблема: передача эта работает только если обмен происходит между двумя «восьмерками». По какой-то причине «семерочная» сторона обмена вообще обделена всякими интересными плюшками КД. Тем не менее, если нельзя, но очень хочется, всегда можно найти выход. Обработка загрузки читает файлы из семерки и из восьмерки одинаково, не проверяя версию платформы-источника, так что никто не мешает нам создать нужную структуру тегов для «параметров» своими силами!

1 стартмани

04.01.2012    34386    88    Филин    28       

69
Смотреть все

Комментарии

Публикации › Обслуживание индексов MS SQL Server: как, когда и, главное, зачем? › #9 18.01.24 18:54
(8) Если это реструктуризация из конфигуратора - то она делает совершенно другие вещи. Она просто пересоздаёт таблицы со всеми индексами. Формально результат будет тот же, но лишних действий больше, плюс статистики скорее всего окажутся устаревшими (потому что они будут просто пересчитываться по триггеру автопересчета - в процессе наполнения новой таблицы). В общем, крайне сомнительное мероприятие.

Без данных о размере файла, о нагрузке на сервер, о модели восстановления (и частоте бэкапа логов транзакций) сложно о чем-то судить. Но я бы в первую очередь правда посмотрел на нагрузку на лог транзакций. И на нагрузку на диски - справляются или нет.
Публикации › Обслуживание индексов MS SQL Server: как, когда и, главное, зачем? › #7 18.01.24 16:04
(6) Наверное, единственное, что стоит сразу указать - это имя базы:

EXEC dbo.usp_AdaptiveIndexDefrag @dbScope = 'AdventureWorks2014'

чтобы скрипт проходил не по всем базам на сервере, а только по нужной.
Остальные дефолты там достаточно разумные. Дальше уже из практики можно подкручивать пороги срабатывания, добавлять таблицы в исключения и т.п. - но это уже когда статистика накопится и понятно будет, что что-то надо менять
Публикации › Обслуживание индексов MS SQL Server: как, когда и, главное, зачем? › #5 16.01.24 17:47
(4) Если честно, все три проблемы - достаточно эфемерные. Их надо было подсветить, чтобы было понятно, что они существуют. Но в то же время, я пытался показать, что большой погоды они не делают - может быть тут не хватило силы убеждения))
Публикации › Обслуживание индексов MS SQL Server: как, когда и, главное, зачем? › #0 16.01.24 13:21
Казалось бы, базовое знание: «индексы надо обслуживать, чтобы запросы выполнялись быстро». Но обслуживание индексов выполняется долго и может мешать работе пользователей. Кроме того, в последнее время популярны разговоры о том, что индексы можно вообще не обслуживать – насколько это оправданно? Рассмотрим: на что влияет обслуживание индексов, когда надо и когда не надо его выполнять, и если надо – как это сделать так, чтобы никому не помешать?
HighLoad › MS SQL Server: изучаем планы запросов › #34 29.06.23 13:34
(33)
1. Это плавающая ошибка, для которой надо дождаться "парада планет". Такие штуки по определению плохо моделируются, лучший способ найти такое - набрать побольше статистики и найти аномалии. Например, если есть система мониторинга, которая хранит снимки кэша планов - по таким данным эту проблему можно диагностировать. И тут, пардон, я сольюсь - доступа к такой статистике у меня больше нет.
2. Еще раз, для воспроизведения ошибки нужно, чтобы сошлось много факторов. Поэтому я не могу привести надёжное repro
HighLoad › MS SQL Server: изучаем планы запросов › #32 29.06.23 12:24
(31) Слушайте, это какой-то диалог про проблемы шаманизма на крайнем севере - только наоборот. Вам со ссылками объясняют ситуацию - да, редкую, но все же возможную - а вы встаете в позу "я проблемы не вижу, значит её нет!".
История с кэшем временных таблиц действительно тянет на отдельное исследование. Может быть, в свежих версиях СУБД что-то поменялось со статистиками, но я помню, что видел похожие ситуации. Все это решалось точечными патчами "по месту", потому что в общем случае всё работает как надо. Поэтому у меня рука не поднимается огульно говорить "всё это ерунда и отмазки криворуких программистов".
HighLoad › MS SQL Server: изучаем планы запросов › #30 29.06.23 11:43
(28)
Цитата
оказывается любой запрос с временными таблицами работает как попало.

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

Подобью для краткости
- простая ВТ (например, из одной колонки - для списка ссылок)
- два уровня кэширования временных таблиц
- вероятность, что в ВТ действительно попадёт большое число строк (несколько сотен)

Ситуация не такая уж частая, но если этот парад планет сошёлся, то тут действительно можно переписать запрос в угоду большей стабильности
HighLoad › MS SQL Server: изучаем планы запросов › #17 22.06.23 12:38
(16)
Временные таблицы кэшируются на двух уровнях. И SQL Server вместо удаления хранит их в кэше, а потом просто возвращает при необходимости, если структура совпадает. И 1С делает практически то же самое - точно так же сохраняет ссылки на временные таблицы и потом переиспользует по возможности.

Теоретически, после truncate статистики должны обновиться (на самом деле, всё немного сложнее https://littlekendra.com/2016/12/08/does-truncate-table-reset-statistics/) - но тут действительно есть, где ошибиться оптимизатору
HighLoad › MS SQL Server: изучаем планы запросов › #15 21.06.23 23:16
(13)
Цитата
Попробуйте тут обновить статистику на временной таблице...
Вообще-то можно попробовать. Если создать во временной таблице индекс по полям соединения, то при наполнении таблицы несколько раз должен сработать порог автообновления статистики - и статистика-таки пересчитается. Это может помочь стабилизировать запрос, а может и не помочь - в данном случае это не главное. Потому что...

Потому что цель статьи совершенно в другом. Это не сборник рецептов "как нам писать запросы". Это введение в диагностику проблем с запросами - то есть, в методологию, как при помощи плана найти проблемное место. Вот вы в план посмотрели, увидели Table Spool - и теперь знаете, какое место лечить. А методов лечения, как правило, больше, чем один и разбирать их - совсем другая история.
HighLoad › MS SQL Server: изучаем планы запросов › #10 21.06.23 10:29
(6)
Цитата
на собеседованиях, как это принято, начнут задавать тупой вопрос

Пардон, play stupid games - win stupid prizes.

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

Ну и вообще, по опыту, когда у меня на собесе (с обеих сторон) начинало происходить что-то непонятное, я просто начинал обсуждение. "вы спрашиваете, в какую сторону выполняется запрос - это зависит от того, как мы его представим. Давайте разберем на примере, вот я на салфетке нарисовал простенький план, вот тут будут прочитаны первые строки...." Как правило, через 5-10 минут всё становится понятно. И собеседующим про меня - и мне про собеседующих