Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
Добрый день, вопрос про линкед сервер. линкед сервер создан на стандартных серверах ms sql server ver 2012/2014/2016, и подлючает базу данных на azure (MS Azure SQL database). Код: sql 1. стандартные сервера должны записывать данные в базу данных на azure через линкед сервер, и это единственная возможность связать сервера. select из линкед сервера работает приемлимо, но insert работает катастрофически медленно. причем скорость разная на разных серверах, в зависимости от настороек безопасности и канала. найден такой путь: вставляем строки небольшими порциями: Код: sql 1. 2. 3. 4. 5. на особо медленных серверах наблюдается примерно такая картина: Код: sql 1. 2. 3. 4. 5. (на каждом сервере по разному, это пример) между 6 и 7 строками очень существенная разница. то есть существует какое-то ограничение, по-видимому по размеру передаваемого пакета, связанный именно с линкед сервером либо с azure. (если вставлять строки через SSIS, на том же сервере все работает очень быстро, без проблем.) вопрос: кто сталкивался, что это за ограничение такое? как оно называется, чтобы поискать в документации? спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 12:15 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
valvстандартные сервера должны записывать данные в базу данных на azure через линкед сервер, и это единственная возможность связать сервера. select из линкед сервера работает приемлимо, но insert работает катастрофически медленно. причем скорость разная на разных серверах, в зависимости от настороек безопасности и канала. Коллега, на тарифе P11 скорость журнала будет 43 Мбайт/сек. На всех прочих тарифах, например стандартных S, намного меньше. Сама вставка в облако работает следующим образом. Инстанс в одном ЦОД получает строку, пишет ее в журнал, далее в режиме синхронного Always On пересылает эту строку за океан в другие ЦОД, там записывает в другие инстансы, и только после этого возвращает клиенту сигнал "готов к следующему insert". Так что низкая скорость вставки в облако - это нормально. Не устраивает - переводите в более дорогой тариф и ждите от нескольких минут до суток, чтобы она выросла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 13:39 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
valvвопрос: кто сталкивался, что это за ограничение такое? как оно называется, чтобы поискать в документации? спасибо! Еще в марте 2016 обсуждали тут на форуме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 13:40 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
Andy_OLAP, спасибо, в данном случае скорость не критична. вопрос немного не об этом. вопрос об оптимальном размере пакета. пример, который я привел, показывает: если передавать 200 строк порциями по 4 строки за раз, это займет (200/4)*5sec = 4 min. если же передавать те же 200 строк порциями по 7 строк, (200/7)*2 min = 56 min. мне необходимо понять, как рассчитать этот лимит, или что это такое; почему такая неимоверная разница. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 13:52 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
valvAndy_OLAP, спасибо, в данном случае скорость не критична. вопрос немного не об этом. вопрос об оптимальном размере пакета. пример, который я привел, показывает: если передавать 200 строк порциями по 4 строки за раз, это займет (200/4)*5sec = 4 min. если же передавать те же 200 строк порциями по 7 строк, (200/7)*2 min = 56 min. мне необходимо понять, как рассчитать этот лимит, или что это такое; почему такая неимоверная разница. Смотреть нужно в свой тариф и считать по IOPS. А у Вас тариф то вообще какой? Ну и конечно создавать ВМ в том же регионе. Потому что другие регионы для репликации по факту. Another thing you could to is create a VM in the same region as your SQL Database and run from there to remove the latency ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 14:01 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 14:03 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
valv, И потом - может быть Вам стоит подумать про использование Azure Table storage , если нужно заливать кучу строк в таблицу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 14:06 |
|
||
|
linked server. непонятное ограничение.
|
|||
|---|---|---|---|
|
#18+
Andy_OLAPСмотреть нужно в свой тариф и считать по IOPS. А у Вас тариф то вообще какой? тариф "S3". но даже если бы был "basic", предоставляемых DTU хватает вполне. примерно 20 серверов пару раз в сутки скидывают 1000-1500 строк каждый. если превратить result set в xml, его размер меньше мегабайта. это вообще ничто. Andy_OLAPvalv, Вот тут в одном из комментариев есть нужные ссылки.ага, спасибо. похоже у topic starter'а та же проблема, что и у меня. и ему также советуют то улучшить тариф, то разбить крупные вставки на более мелкие (что он изначально знает). как расчитать размер пакета, и что за ограничение загадочное, вот в чём вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2018, 15:29 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=39579344&tid=1690573]: |
0ms |
get settings: |
7ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
53ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 360ms |

| 0 / 0 |
