IC
Привет, ты не по адресу, здесь MS SQL
Size: a a a
2020 July 17
v
эм, окей
v
Может кто-нибудь подсказать, как сертификат подключить? SQL Server 2014 SP3, сертификат, который я добавляю через MMC он в SQL Server Config Manager не видит. Думал, что дело в приватном ключе к сертификату, но тоже не получается подключить, хотя пробовал по доке с офсайта. В чем проблема может быть?
IZ
- - этому условию удовлетворяет не более 100к записей
ИМХО, один из простых советов, а попробуйте ка выполнить пакетную заливку данных, по 4999 записей, чтобы не было экалаций разнообразных блокировок таблиц.
ИМХО, один из простых советов, а попробуйте ка выполнить пакетную заливку данных, по 4999 записей, чтобы не было экалаций разнообразных блокировок таблиц.
Эскалации же только лучше перформанс сделают...
Ау него хуже становится
Ау него хуже становится
IZ
у меня легаси небольшой, осталось от code-first-хуяк-хуяк подхода. Там и 200 за глаза, но переделка этого к сожалению отзовется бОльшей попоболью)
Что ты против code first ?
VP
Ну там речь была про разовый перелив данных, здесь эскалации не всегда в пользу, если система жива и проседает не её перфоманс, а сам мердж данных.
Но как видно выше речь была не в блокировках и их эскалациях, а в индексе.
Но как видно выше речь была не в блокировках и их эскалациях, а в индексе.
VP
Меня несколько раз выручал хит с 4999, вот и предложил, не претендую на истину в чужих системах.
I
Может кто-нибудь подсказать, как сертификат подключить? SQL Server 2014 SP3, сертификат, который я добавляю через MMC он в SQL Server Config Manager не видит. Думал, что дело в приватном ключе к сертификату, но тоже не получается подключить, хотя пробовал по доке с офсайта. В чем проблема может быть?
Cn сертификата совпадает с именем сервера?
v
ILYA
Cn сертификата совпадает с именем сервера?
cn?
I
cn?
Subject -> CN -> ?
v
ILYA
Subject -> CN -> ?
Ага, вижу. Спасибо :)
NK
Что ты против code first ?
против хуяк хуяк. строковый тип завели, миграцию запустили, все работает, в ладоши похлопали, а про ограничения и возможные траблы не подумали.
NK
Ну там речь была про разовый перелив данных, здесь эскалации не всегда в пользу, если система жива и проседает не её перфоманс, а сам мердж данных.
Но как видно выше речь была не в блокировках и их эскалациях, а в индексе.
Но как видно выше речь была не в блокировках и их эскалациях, а в индексе.
в итоге я переписал запрос, несмотря на то, что индекс улучшил ситуацию. Выбираю данные, которые участвуют в мердже во временную таблицу, произвожу мердж между двумя временными таблицами и отдельные апдейт/инсерт/delete/
навеяло вот этим https://www.sqlservercentral.com/forums/topic/big-performance-problem-with-merge-statement
In this case, you're using the WHEN NOT MATCHED predicate, which requires a Full Outer Join to include matched rows and unmatched rows in a single pass.
The individual DELETE and UPDATE statements do not suffer from this issue, so they actually perform better.
пы.сы могу быть не прав, но лок стал меньше, так как мердж лочит таблицу на все время, пока сопоставляет. А тут мерджим отдельно на временных таблицах, а отдельные операции вставкм/удаления работают быстро
навеяло вот этим https://www.sqlservercentral.com/forums/topic/big-performance-problem-with-merge-statement
In this case, you're using the WHEN NOT MATCHED predicate, which requires a Full Outer Join to include matched rows and unmatched rows in a single pass.
The individual DELETE and UPDATE statements do not suffer from this issue, so they actually perform better.
пы.сы могу быть не прав, но лок стал меньше, так как мердж лочит таблицу на все время, пока сопоставляет. А тут мерджим отдельно на временных таблицах, а отдельные операции вставкм/удаления работают быстро
NK
может быть оффтоп, но посоветуйте хороший учебник по DAX?
NP
Очень даже не оффтоп
KT
в итоге я переписал запрос, несмотря на то, что индекс улучшил ситуацию. Выбираю данные, которые участвуют в мердже во временную таблицу, произвожу мердж между двумя временными таблицами и отдельные апдейт/инсерт/delete/
навеяло вот этим https://www.sqlservercentral.com/forums/topic/big-performance-problem-with-merge-statement
In this case, you're using the WHEN NOT MATCHED predicate, which requires a Full Outer Join to include matched rows and unmatched rows in a single pass.
The individual DELETE and UPDATE statements do not suffer from this issue, so they actually perform better.
пы.сы могу быть не прав, но лок стал меньше, так как мердж лочит таблицу на все время, пока сопоставляет. А тут мерджим отдельно на временных таблицах, а отдельные операции вставкм/удаления работают быстро
навеяло вот этим https://www.sqlservercentral.com/forums/topic/big-performance-problem-with-merge-statement
In this case, you're using the WHEN NOT MATCHED predicate, which requires a Full Outer Join to include matched rows and unmatched rows in a single pass.
The individual DELETE and UPDATE statements do not suffer from this issue, so they actually perform better.
пы.сы могу быть не прав, но лок стал меньше, так как мердж лочит таблицу на все время, пока сопоставляет. А тут мерджим отдельно на временных таблицах, а отдельные операции вставкм/удаления работают быстро
https://www.tutorialspoint.com/dax_functions/index.htm
и в принципе официальная дока неплохая https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-quickstart-learn-dax-basics
более глубоко здесь - https://powerbi.tips/ и https://www.sqlbi.com/
и в принципе официальная дока неплохая https://docs.microsoft.com/en-us/power-bi/transform-model/desktop-quickstart-learn-dax-basics
более глубоко здесь - https://powerbi.tips/ и https://www.sqlbi.com/
KT
в итоге я переписал запрос, несмотря на то, что индекс улучшил ситуацию. Выбираю данные, которые участвуют в мердже во временную таблицу, произвожу мердж между двумя временными таблицами и отдельные апдейт/инсерт/delete/
навеяло вот этим https://www.sqlservercentral.com/forums/topic/big-performance-problem-with-merge-statement
In this case, you're using the WHEN NOT MATCHED predicate, which requires a Full Outer Join to include matched rows and unmatched rows in a single pass.
The individual DELETE and UPDATE statements do not suffer from this issue, so they actually perform better.
пы.сы могу быть не прав, но лок стал меньше, так как мердж лочит таблицу на все время, пока сопоставляет. А тут мерджим отдельно на временных таблицах, а отдельные операции вставкм/удаления работают быстро
навеяло вот этим https://www.sqlservercentral.com/forums/topic/big-performance-problem-with-merge-statement
In this case, you're using the WHEN NOT MATCHED predicate, which requires a Full Outer Join to include matched rows and unmatched rows in a single pass.
The individual DELETE and UPDATE statements do not suffer from this issue, so they actually perform better.
пы.сы могу быть не прав, но лок стал меньше, так как мердж лочит таблицу на все время, пока сопоставляет. А тут мерджим отдельно на временных таблицах, а отдельные операции вставкм/удаления работают быстро
если прямо учебники нужны - https://www.sqlbi.com/books/
NK
ооо спасибо. а то на power bi форуме люди иногда предлагают решения, которые работют, но не могу понять как)))
ФГ
Везде где авторы Руссо Вебер Феррари что касается
ТАбуляр dax и прочее можно верить. Книжка их была N1 не знаю как счас но думаю вряд ли что лучше есть.
Заодно поищите их блоги.
ТАбуляр dax и прочее можно верить. Книжка их была N1 не знаю как счас но думаю вряд ли что лучше есть.
Заодно поищите их блоги.
VB
коллеги добрый вечерок! подскажите уже голову поломал, на одном из серверов полетели диски и backup, остались только mdf + ldf SQL 2012, но присоединить просто не получается пишет что ldf с ошибками, решил по пробовать восстановить только mdf на SQL 2019, тут тоже пошел по пути восстановить файл mdf но новом сервере 2019 пишет ошибка Не удалось открыть базу данных, версия 706. Обновите базу данных до последней версии. Скажите куда копать?