DI
Видимо еще не проснулся, серьезно ко всему отношусь, митинги и туда сюда работа поглотила.
Size: a a a
2021 June 17
MZ
С разработчком нет связи много лет, структура бд не ясна, пытаюсь понять по вьюшкам и хранимкам
MZ
Половина хпроцедур тоже закрыта
KT
Apex - все, они после покупки стали платными, поэтому лучше https://www.devart.com/dbforge/sql/sqldecryptor/ или просто скриптом https://github.com/ktaranov/sqlserver-kit/blob/master/Scripts/Decrypt%20T-SQL%20module.sql
MZ
Спасибо, попробую
DI
Ого, я его еще помню free, не знал, что они стали денег за это брать
KT
как все раздекриптите крайне рекомендую заюзать https://www.red-gate.com/products/sql-development/sql-dependency-tracker/, 14 дней пробного периода достаточно чтобы понять основные моменты
KT
да, все аддоны для SSMS тоже стали платными, все стало платным) капитализм в действии
DI
Вот жеж жадины...
Тогда уже точно redgate лучше заюзать на триале.
Тогда уже точно redgate лучше заюзать на триале.
KT
есть еще dbForge (их еще не успели купить) бесплатный) https://www.devart.com/dbforge/sql/sqldecryptor/
DI
В общем смысл такой, вам нужна нормализация вашей структуры + таблицы связей в которой вы будет организовывать необходимую вам уникальность.
Вот пример:
1. таблица стран
Id_country - unique
Name
2. таблица городов
Id_city - unique
Name
3. Таблица связей
id - incremental
id_country - fk на таблицу стран
id_city - fk на таблицу городов
unique key = id_country + id_city
4. таблица фактов
Person_id
Departmet_id
Role_id
....
....
Id из таблицы связей (п.3)
Вот пример:
1. таблица стран
Id_country - unique
Name
2. таблица городов
Id_city - unique
Name
3. Таблица связей
id - incremental
id_country - fk на таблицу стран
id_city - fk на таблицу городов
unique key = id_country + id_city
4. таблица фактов
Person_id
Departmet_id
Role_id
....
....
Id из таблицы связей (п.3)
A
https://docs.dbatools.io/Invoke-DbaDbDecryptObject
Этой штукой расшифровал порядка 300 объектов на прошлой неделе. Бесплатно и консольно.
Сразу совет: экспортировать текст в utf8. Иначе могут побиться юникодные символы в процах и т.п.
Этой штукой расшифровал порядка 300 объектов на прошлой неделе. Бесплатно и консольно.
Сразу совет: экспортировать текст в utf8. Иначе могут побиться юникодные символы в процах и т.п.
ОГ
Всем привет!
Речь о взаимоблокировках.
Думаю легко подскажут коллеги, которые занимаются DWH построенном на MS SQL.
Наткнулся на ситуацию, которую сложно загуглить (один словом не сформулируешь) и не могу догадаться где об этом почитать(книги).
Имеем поток (SSIS), в котором из десятков разных источников наполняем стейджевые таблицы в MS SQL 2019 enterprise.
После каждой загрузки стейджа выполняется индивидуальная процедура, в которой выполняется MERGE стейджа с целевой таблицей.
Так как при MERGE выполняется не только чтение целевой таблицы, но и INSERT, UPDATE - время от времени вылетают дедлоки между этими процедурами.
В MERGE нет возможности указать хинт блокировки таблицы.
Для информации:
- В MERGE связь таблиц происходит по первичному ключу (Кластеризованный индекс) в целевой таблице. А стейдж как "куча" (без индексов).
- Данные из разных источников могут обновлять данные только себе, то есть не пересекаются с данными других источников.
- Процедуры с MERGE отрабатывают в районе 1 - 30 секунд.
Учитываем, что:
- Объёмы данных разные + хотим оставить возможность асинхронной загрузки из источников, по этому ждать завершения загрузки всех стейджей не хотим.
Вижу решения:
1) Уйти от MERGE на отдельные INSERT, UPDATE - тут минус, что придётся в каждой процедуре читать целевую таблицу 2 раза в место одного.
2) Ждать завершения загрузки всех стейджей и последовательно или в одной процедуре (соединив стейжди через UNION ALL) разом грузить. - тут минус, мы лишаемся гибкой возможности прогрузить только часть источников. (можно будет только все сразу)
Что посоветуете попробовать?
Или киньте ссылку, где рассматривается схожая ситуация с (!)найденным решением.
UPD:
Создал на стейджах такой же ключ как на целевой таблице, и при многократном моделировании дедлоки не появляются. Я не понимаю почему это помогло.
Но это не является решением, так как мы должны допускать что в стейдж могут прилететь некорректные данные с источника (ключевые поля со значением NULL ; дублирования по ключу; и т.п.) Все эти ситуации будут отсеиваться в процедуре, и там же будут генерироваться сообщения/логи для ответственных за поток об не валидных записях для исправления из на источнике данных.
Речь о взаимоблокировках.
Думаю легко подскажут коллеги, которые занимаются DWH построенном на MS SQL.
Наткнулся на ситуацию, которую сложно загуглить (один словом не сформулируешь) и не могу догадаться где об этом почитать(книги).
Имеем поток (SSIS), в котором из десятков разных источников наполняем стейджевые таблицы в MS SQL 2019 enterprise.
После каждой загрузки стейджа выполняется индивидуальная процедура, в которой выполняется MERGE стейджа с целевой таблицей.
Так как при MERGE выполняется не только чтение целевой таблицы, но и INSERT, UPDATE - время от времени вылетают дедлоки между этими процедурами.
В MERGE нет возможности указать хинт блокировки таблицы.
Для информации:
- В MERGE связь таблиц происходит по первичному ключу (Кластеризованный индекс) в целевой таблице. А стейдж как "куча" (без индексов).
- Данные из разных источников могут обновлять данные только себе, то есть не пересекаются с данными других источников.
- Процедуры с MERGE отрабатывают в районе 1 - 30 секунд.
Учитываем, что:
- Объёмы данных разные + хотим оставить возможность асинхронной загрузки из источников, по этому ждать завершения загрузки всех стейджей не хотим.
Вижу решения:
1) Уйти от MERGE на отдельные INSERT, UPDATE - тут минус, что придётся в каждой процедуре читать целевую таблицу 2 раза в место одного.
2) Ждать завершения загрузки всех стейджей и последовательно или в одной процедуре (соединив стейжди через UNION ALL) разом грузить. - тут минус, мы лишаемся гибкой возможности прогрузить только часть источников. (можно будет только все сразу)
Что посоветуете попробовать?
Или киньте ссылку, где рассматривается схожая ситуация с (!)найденным решением.
UPD:
Создал на стейджах такой же ключ как на целевой таблице, и при многократном моделировании дедлоки не появляются. Я не понимаю почему это помогло.
Но это не является решением, так как мы должны допускать что в стейдж могут прилететь некорректные данные с источника (ключевые поля со значением NULL ; дублирования по ключу; и т.п.) Все эти ситуации будут отсеиваться в процедуре, и там же будут генерироваться сообщения/логи для ответственных за поток об не валидных записях для исправления из на источнике данных.
АР
Лучше граф дедлока покажите в формате xml (xdl). Это будет гораздо полезнее вербального описания.
O
была у меня такая проблема, правда в OLTP системе. Дело было в том, что мердж сканил таблицу целиком и возникала эскалация. Я навертел все необходимые индексы и отключил эскалацию блокировок на таблице. временами план всё-же слетал опять на скан, когда прилетало очень много данных для обновления. Пришлось зафорсить план через QueryStore. А у вас свитчинг партишенов не используется? данные грузятся очень часто? Обновляемые данные меняются во времени и не только самые свежие данные затрагиваются при мердже?
DI
Часто подобного рода задачи решаются через очередь.
Можно самописную сделать, можно брокером воспользоваться или любой другой штукой которая умеет с очередью работать.
Ну и как посоветовал коллега выше, рассмотрите партишен свитч, если это возможно.
Можно самописную сделать, можно брокером воспользоваться или любой другой штукой которая умеет с очередью работать.
Ну и как посоветовал коллега выше, рассмотрите партишен свитч, если это возможно.
ОГ
В ходе разбора ситуации с Александр .
Попробовали через CTE явно указать сортировку данных в стейдже:
WITH source as
(
SELECT top (cast(0x7fffffffffffffff as bigint))
***
FROM ***
ORDER BY ***
)
MERGE
****
План запроса изменился, но блокировка осталась.
В этот момент Александр , обратил внимание, что блокировка связана с " intra-query parallelism deadlock", и известное решение в данном случае добавить к запросу option (maxdop 1).
Таким образом из плана выполнения запроса ушел параллелизм. Производительность MERGE не изменилась. При многократном тестировании ошибок не появилось. Так же планировщик уже без CTE стал предварительно сортировать данные в стейдже под индекс в целевой таблице, и NESTED LOOPS изменился на MERGE JOIN.
Большое спасибо Александр !
@trootnev , @LuckyDima - благодарю, что откликнулись.
p.s.
@trootnev - подобное решение подойдёт только в ряде ситуаций, когда данные проще перезалить за период и выполнить свич партишен. Не всегда данные можно качественно поделить на секции. Я же стремлюсь получить общий(унифицируемый) подход для всех потоков данных.
@LuckyDima - если бы на проекте активно использовалась очередь, то да, можно было бы как общий стандарт разработки завернуть в эту сторону. Такого нет. И я в таком подходе вижу только дополнительную "точку отказа".
Попробовали через CTE явно указать сортировку данных в стейдже:
WITH source as
(
SELECT top (cast(0x7fffffffffffffff as bigint))
***
FROM ***
ORDER BY ***
)
MERGE
****
План запроса изменился, но блокировка осталась.
В этот момент Александр , обратил внимание, что блокировка связана с " intra-query parallelism deadlock", и известное решение в данном случае добавить к запросу option (maxdop 1).
Таким образом из плана выполнения запроса ушел параллелизм. Производительность MERGE не изменилась. При многократном тестировании ошибок не появилось. Так же планировщик уже без CTE стал предварительно сортировать данные в стейдже под индекс в целевой таблице, и NESTED LOOPS изменился на MERGE JOIN.
Большое спасибо Александр !
@trootnev , @LuckyDima - благодарю, что откликнулись.
p.s.
@trootnev - подобное решение подойдёт только в ряде ситуаций, когда данные проще перезалить за период и выполнить свич партишен. Не всегда данные можно качественно поделить на секции. Я же стремлюсь получить общий(унифицируемый) подход для всех потоков данных.
@LuckyDima - если бы на проекте активно использовалась очередь, то да, можно было бы как общий стандарт разработки завернуть в эту сторону. Такого нет. И я в таком подходе вижу только дополнительную "точку отказа".
O
Если оптимизатор сейчас выбрал MERGE JOIN и сортировку и вы это находите более выгодным - сортируйте данные заранее. Оптимизатор непостоянен в выборе методов доступа и эффект может быть другим на других данных. Ну либо можно хинтом явно прибить MERGE в качестве метода соединения.
ОГ
На рассматриваемом примере прироста производительности не заметил. Но понятно, что этот путь правильнее. Буду наблюдать за этим и другими потоками, сравнивать и т.п.
Если будет польза ощутимая, и не найду другого способа, то рассмотрю добавления хинта.
Если будет польза ощутимая, и не найду другого способа, то рассмотрю добавления хинта.
O
Еще вопрос почему задействовался параллелизм без реальной пользы. Возможно следует поработать с планом запроса чтобы его стоимость была ниже порога параллелизма, либо поднять порог.