|   |   | 
| 
 | OFF: Посоветуйте курс по MS SQL в МСК | ☑ | ||
|---|---|---|---|---|
| 0
    
        slitov 21.12.18✎ 17:18 | 
        Поступило предложение от руководителя выбрать курс, на который я желаю сходить в следующем году. Есть желание разобраться более глубоко с MS SQL. Как настраивать планы обслуживания баз, писать простые запросы (SELECT ... FROM ...) я итак умею, как я понимаю только про это и рассказывают в стандартных курсах для 1С-ников )))
 Может кто посоветует хороший курс в МСК или дистанционно. Главное, хочу разобраться как правильно шринковать таблицы(например таблицы остатков и оборотов старше 2х лен нам вообще не нужны), как находить узкие места, например когда пользователь заблокировал таблицу и никто не может к ней обратиться... Но как определить, какая таблица например не дает провести расчет з.п., когда 5 человек одновременно по разным подразделениям делают расчет и всем надо сделать их срочно выполнить. Подозреваю, есть ошибка в коде и думаю есть возможность просмотреть, кто блокирует или нагружает базу в текущий момент средствами MS SQL. Надеюсь хотели понятно изложил, коллеги, жду советов по делу, пока дед мороз не передумал дарить подарки ))) | |||
| 1
    
        palsergeich 21.12.18✎ 17:20 | 
        (0) Так все таки курс по МССКЛ или по тому как сделать так, что бы людаям комфортно было в 1с работать?     | |||
| 2
    
        slitov 21.12.18✎ 17:39 | 
        (1) Скорее курс по администрированию баз на МССКЛ. Т.е. мониторинг загруженности базы (например 3 базы на одном сервере, какую из них загружает сервер больше всего и насколько более производительный сервер нужен, чтобы ускорить работу БД), какие таблицы в базе данных на текущий момент заблокированы какими пользователями и в идеале кто из пользователей еще обращался к этой таблице и получал отказ. Как правильно шринковать таблицы, как определить, какие не используются.
 Наверно я слишком много хочу, но хочется понять, можно это увидеть средствами MSSQL, если нет, то тогда скорее всего скачаю курс "Ускорение и оптимизация систем на 1С:Предприятие 8.3", просто у автора курса есть проблема с дикцией, слух режет... | |||
| 3
    
        Вафель 21.12.18✎ 17:41 | 
        (2) тогда все-таки нужны курсы а ля эксперт по 1с     | |||
| 4
    
        mexanik_96 21.12.18✎ 18:26 | 
        (2) чтобы ускорить работу БД -  есть уверенность что проблема там?
 смысл подкручивать сиквел, железо, если основная проблема в не оптимальный запросах(код в 1с) или в построении (платформа) ?? | |||
| 5
    
        palsergeich 21.12.18✎ 19:42 | 
        (2) 1с выпустил свои курсы подготовки к эксперт, аж 2 штуки. То что ты хочешь в (2) это оно     | |||
| 6
    
        palsergeich 21.12.18✎ 19:55 | 
        (2) Пойми правильно в мире 1с 90% проблем с производительностью - кривой код.
 Ну увидишь ты корявый запрос в профайлере - как ты его в коде найдешь? Для расследований проблем с производительностью первой что надо уметь - работать с ТЖ. Второе - уметь работать с планами запросов - понимать что такое хорошо а что такое плохо, и когда это хорошо, а когда та же самая ситуация это плохо. А уже потом можно глубоко в скуль нырнуть | |||
| 7
    
        palsergeich 21.12.18✎ 19:57 | 
        Как говорит тот же самый Богачев - еще не было задачи где SQL был слабое место     | |||
| 8
    
        palsergeich 21.12.18✎ 20:00 | 
        Сформулирую точнее: где именно в итоге SQL был слабое место.
 Подавляющее большинство проблем исцеляется после оптимизации топ 10 проблемных мест по анализу ТЖ. | |||
| 9
    
        palsergeich 21.12.18✎ 20:04 | 
        Но как определить, какая таблица например не дает провести расчет з.п., когда 5 человек одновременно по разным подразделениям делают расчет и всем надо сделать их срочно выполнить.
 Этого скорее всего ты на уровне SQL и не увидишь - проблема будет вероятнее всего на уровне сервера приложений на ожидании на управляемых блокировках. Главное, хочу разобраться как правильно шринковать таблицы(например таблицы остатков и оборотов старше 2х лен нам вообще не нужны) Частная проблема которая быстро решается средствами SQL, но может быть решена и средствами 1с, не так быстро конечно. | |||
| 10
    
        palsergeich 21.12.18✎ 20:08 | 
        например когда пользователь заблокировал таблицу и никто не может к ней обратиться - скорее всего будет управляемая блокировка и в SQL ты ничего не увидишь проблемного.
 Подозреваю, есть ошибка в коде и думаю есть возможность просмотреть, кто блокирует или нагружает базу в текущий момент средствами MS SQL. Там может ничего не быть критичного, а проблема в коде на уровне сервера приложений. http://edu.1c.ru/expert/ http://edu.1c.ru/expert2/ Более полно помогут решить те проблемы, которые озвучены в (0) | |||
| 11
    
        palsergeich 21.12.18✎ 20:10 | 
        например когда пользователь заблокировал таблицу и никто не может к ней обратиться.
 Пример из головы: Начали транзакцию. Поставили управляемую блокировку на таблицу какую нибудь и начали читать и парсить какой нибудь файл. В SQL будет вообще ничего. | |||
| 12
    
        Филипп Богачев 21.12.18✎ 20:23 | 
        (8) В скуле уж сто лет есть статистика ожиданий и нормальные средства диагностики, в отличие от 1С с его убогим ТЖ который предполагается на курсе иксперда парсить регулярками, потому что сраный ЦУП который надо покупать за 200 штук не справляется, бгг     | |||
| 13
    
        Филипп Богачев 21.12.18✎ 20:29 | 
        И да, даже в самом дешманском скуле есть дедлок репорт в system health. А в 1С надо покупать КИП чтобы поймать  дедлок, и то не факт что получится.     | |||
| 14
    
        palsergeich 21.12.18✎ 20:35 | 
        (13) а как Вы отловите дедлок на управляемых блокировках в SQL, расскажите, мне очень интересно     | |||
| 15
    
        Филипп Богачев 21.12.18✎ 20:39 | 
        (14) чего-чего? я про то что дедлок это обычная хрень там где есть блокировки и много юзеров, и если скуль для своих дедлоков предоставляет норм репорт штатно, то для 1С для поиска дедлоков на упр блокировках надо вызывать иксперда.     | |||
| 16
    
        palsergeich 21.12.18✎ 20:40 | 
        (15) тухло как то.     | |||
| 17
    
        Филипп Богачев 21.12.18✎ 20:41 | 
        (16) да, в 1С с диагностикой все тухло     | |||
| 18
    
        Филипп Богачев 21.12.18✎ 20:42 | 
        (16) мне кажется ты даже не знаешь что такое дедлок репорт в скуле и где его искать     | |||
| 19
    
        palsergeich 21.12.18✎ 20:43 | 
        (15) В плане развития срача - и вы думаете те люди, которые пишут запросы в SQL напрямую или через ORM в своих православных языках в бОльшей своей массе вообще в курсе?
 Там нанимают специальных DBA за тыщи баксов которые точно так же, корячась с страдая ищут. Ок в SQL есть deadlock graph А как быть в православном Postgres&) | |||
| 20
    
        palsergeich 21.12.18✎ 20:44 | 
        а там херак и костыли) 
 https://habr.com/company/wargaming/blog/323354/ | |||
| 21
    
        palsergeich 21.12.18✎ 20:47 | 
        А возьмем кровавый ентерпрайз N1 Oracle и увидим еще более корявые костыли. http://citforum.ru/database/oracle/deadlock/6.shtml     | |||
| 22
    
        Филипп Богачев 21.12.18✎ 20:48 | 
        (16) И мне кажется что ты не знаешь что блокировки и таймауты на скуле бывают и в режиме упр блокировок и даже на 8.3
 (19) при чем тут другие языки и другие люди? я говорю про продукты и средства их диагностики одинаковых по сути проблем. И да, DBA is dead в 2019 https://www.sql.ru/forum/1305605/dba-is-dead-v-2019-kto-kak-dumaet | |||
| 23
    
        palsergeich 21.12.18✎ 20:49 | 
        (22) Знаю, а так же знаю что дедлок может быть и без какой либо информации в SQL     | |||
| 24
    
        Филипп Богачев 21.12.18✎ 20:49 | 
        Про пиздгрес который через полвека своего существования так и не сделал норм бэкапы я даже слышать не хочу     | |||
| 25
    
        Филипп Богачев 21.12.18✎ 20:52 | 
        (23) Ты слишком много слушал Богачева и Морозова. Будь мужиком, послушай, почитай Короткевича и Пилюгина     | |||
| 26
    
        palsergeich 21.12.18✎ 20:52 | 
        (24) А как же прогрессивные стартапы и супер IT гиганты которые массово отказываются от MSSQL и Oracle  и толпами валят на Postgres https://habr.com/post/321756/
 Почему то в большом IT считается незазорным скриптик для парса написать) | |||
| 27
    
        Филипп Богачев 21.12.18✎ 20:57 | 
        (26) Вроде убер свалил на мускул с пиздгеса. Но суть же не в этом. Мы же 1С-ники и у нас много реальных проблем, нам надо работать а не херней с регулярками заниматься. А 1С нам предлагает для борьбы с дедлоками Морозова вызванивать, проект цктп открывать? Я пенсию 10 тыщ получаю, половину за квартплату отдаю, Ёлочка мне нравится?     | |||
| 28
    
        palsergeich 21.12.18✎ 20:58 | 
        (27) Ну дык чо беда в том же скуль случится - в ответ платежка прийдет. И она не на 300 к отнють будет     | |||
| 29
    
        palsergeich 21.12.18✎ 20:59 | 
        Там у ребят совсем другие аппетиты     | |||
| 30
    
        rsv 21.12.18✎ 21:15 | 
        (26) судя по статье уход с ora это из денех.
 Плюс было много логики серверной на хранимках. | |||
| 31
    
        rsv 21.12.18✎ 21:19 | 
        Автор пишет что цель была отойти и куда то перейти..и на тотже мускул..но неиперешли из за организационных моментов     | |||
| 32
    
        rsv 21.12.18✎ 21:20 | 
        (0) askit.ru.     | |||
| 33
    
        H A D G E H O G s 21.12.18✎ 21:36 | 
        (26) Самое главное в статье:
 "Летом 2015 года мы перенесли свои ящики. Команда «Почты», которая её пишет, тестирует, админит и так далее, перенесла свои ящики. Это очень сильно ускорило разработку. Страдает абстрактный Вася, или страдаешь ты, но можешь это поправить, — это две разные вещи." | |||
| 34
    
        H A D G E H O G s 21.12.18✎ 21:49 | 
        (26) Ну а так - че, молодцы, переползли на postgreeSQL. Когда у тебя есть ресурс в 10человеко-лет, и воля руководства, че бы не переползти. Попинать бы его ногами за эту ущербную терминологию, типа "deploy, legacy, факапы", но он - далеко, а на улице - зима, холодно, лениво.     | |||
| 35
    
        rsv 21.12.18✎ 21:52 | 
        (33) Сами поправить ? Судя по статье постгри про допиливало диагностику плюс консалтинг решал другие задачи     | |||
| 36
    
        H A D G E H O G s 21.12.18✎ 21:57 | 
        (35) Ннуу, не знаю...
 "Мы не придумали ничего лучше и запатчили barman, вот pull request. Уже почти год прошел, как мы их просим запилить эту киллер-фичу, а они просят с нас денег, чтобы замержить её. Очень наглые ребята. Мой коллега Евгений, который всё это и запилил, рассказывал об этом на PGday в 2016 году. Оно правда сильно лучше жмёт бэкапы, их ускоряет, там честные инкременты." | |||
| 37
    
        H A D G E H O G s 21.12.18✎ 21:58 | 
        (35) "а они просят с нас денег, чтобы замержить её. "
 Я так понял, это Postgree просят денех с Яндекса, чтобы запилить разработку Яндекса в свой типовой функционал. | |||
| 38
    
        rsv 21.12.18✎ 22:02 | 
        +(35) 
 Нам очень не хватало способов диагностики PostgreSQL. Ребята из Postgres Pro запилили нам wait-интерфейс | |||
| 39
    
        slitov 25.12.18✎ 15:58 | 
        Только руки дошли почитать тему,  (10) спасибо за советы по курсу эксперта.     | 
| Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |