Решаем проблемы по мере поступления

[coolwolf0]

Вчерась собрался выезжать со стоянки на работе, глядь - на лобовом стекле какие-то потёки. Ну бывает, может с какой трубы накапало, как-никак стоянка крытая. Пытаюсь дворниками оттереть - фиг. Выехал на улицу, встал на обочине, оттираю тряпочкой из багажника. Результат абсолютно тот же. Причём налито что-то прозрачное, на ощупь чуть выступающее на поверхности стекла. Вот ведь вандализм какой, подумал Штирлиц и поехал дальше, под завывания "радио Шамс". Дома на проклятые потёки был применён специальный спрей для чистки окон - с нулевым результатом. И даже водка не помогла! Обидно, но деваться некуда, взял обычную мочалку для посуды, такую пушистую из синтетического волокна. Потёр, и о чудо: вся бяка начала сходить. Естественно, начинал с нижней части, вдруг поцарапаю, но ничего не случилось, а стекло снова как новое.

Вчера же пытался продолжить общение с Джемини по поводу моего приложения. Там уже давно такая простыня, что прокрутить в начало наверное физически не получится. Спрашиваю его как лучше всего расширить синтаксис Markdown для представления результата в виде HTML-тега с назначенным классом. Бездушный гугловский интерфейс крутит анимацию и ... ничего не происходит. И так раз 5. Пока до меня не дошло, что и у железного собеседника бывают пределы возможного. Наверное я до этого предела и дошёл. Ну и фиг с ним, открою новую ветку. Кстати, в новой ветке он мне персонажей нагенерировал словно под наркотиками: стиль ужасный, какие-то безумные цвета, несоответствие описанию. Еле уговорил привести хоть в какой-то приличный вид. Отправил сыну черновики, будем переводить в вектор и анимировать SVG, иншалла. Кстати, итоги раунда у меня в языковом приложении теперь объявляет анимированная голова "помошника" или "помошницы", включая рандомные ужимки.

Вчера же (вот совпадение) решил интересную проблему на работе. У пользователя BIRT репорт генерируется аж по три с лишним часа. И это после оптимизации и перехода на materialized view, когда SQL стал отрабатывать за доли секунды (вместо десяти минут). Как я ни пытал разные движки AI, ничего разумного они мне не посоветовали. Тогда я взялся сам, аккуратно разбил процесс на этапы и ... нашёл пару репортов в batch которые тянули основное время. Открываю их исходники, и что же вижу - мой старый знакомый SQL view вместо оптимизации. Только теперь не в коде на Пайтоне, а непосредственно как dataset внутри XML. Подправил источник и засор внезапно прорвало: все репорты собираются за каких-то 15 минут!

Comments

[brmail]

Ну в самом же деле - первый шаг, который делается при вопросе "почему там медленно" в SQL (как минимум в микрософтовском сервере) это попросить execution plan для выполнимого запроса или SP.
И там сразу видно, где порылась собака. И более того, оно часто само подсказывает, что поправить (например индекс добавить или перестроить) чтобы тормоза ушли.

[coolwolf0]

Естественно, я знаком с технологиями SQL уже более 30 лет. Сам по себе принцип "вытащить из апликации, отладить и вернуть обратно" очень удобен. И как работать с explain я тоже знаю, чай не одно приложение наваял в самых разных базах данных (MySQL, PostgreSQL, Oracle-SQL, sqlite). Проблема BIRT в том, что он триггерит запросы внутри себя, и отследить его логику дебагом практически невозможно (ну нет там дебага по определению). В дополнение ко всему, парочка eclipse+birt коряво работают в моей среде разработчика, а под виндой что-то поломалось в соединении с сервером (проклятый Oracle client должен быть установлен и настроен). Слава небесам, что хотя бы проблему клиента в DBeaver решили, но увы, до него надо сначала дойти с вытащенным из кода текстом query и оригинальными параметрами для binding.

По-хорошему, надо бы закрыть эту лавочку и посадить пользователя перед PowerBI: "вот тебе корова, вот тебе ведро, садись и дои". Тем более, что мои пользователи - программисты. Ну ничего, главное что проблема решена, хотя DBA и предупреждал меня насчёт фрагментации сегментов storage при активном применении materialized view.