|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
еще раз: где пример хоть на какое-то ускорение благодаря черезжопному хранению? на этот вопрос меня призвали открыть спойлер. в спойлере НЕТ чтения лобов, сплошное инроу, так о чем спор? вы в этой теме громогласно заявляете, почему надо хранить out of row то, что намеренно запихивают в in row, начиная с 2005-ого сервера. вас спрашивают: пример на "ускорение" можно увидеть? а ответ оказывается уже не в спойлере, а в том, что там ваши процедуры читают. вернее, не читают. всем пофигу на ваши процедуры. но вот не надо с трибуны призывать хранить так, чтобы стало медленнее. если строка влазит в 6000, не надо ее как max объявлять. пользы 0, а тормознее станет, вот и все ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:40 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, протрите глаза что ли, или очки. Выше явно показано, что количество logical reads при выборке, в которой строки вообще не участвуют, из таблицы t3 сократилось в 33 раза(!), по сравнению с той же выборкой из t1 и t2 Я пока на практике очень редко сталкивался со случаем, когда строки длинее ~200 символов действительно были бы нужны в более чем 10% запросах. Потому и считаю это скорее исключением, чем правилом. Да, пусть медленнее происходит вставка и выборка таких строк, раз остальные 90% запросов выполняются на порядок быстрее. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:46 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 ...Выше явно показано, что количество logical reads при выборке, в которой строки вообще не участвуют... если чего-то не очень хочется/да и не нужно вообще читать, не добавляйте это что-то в нужный индекс, не добавляйте вообще в таблицу, храните в другой, связь 1 в 1 с основной. зачем же так извращаться? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:58 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 Да, пусть медленнее происходит вставка и выборка таких строк, раз остальные 90% запросов выполняются на порядок быстрее. https://www.brentozar.com/archive/2019/05/9-tips-for-faster-sql-server-applications/Don’t go overboard: SQL Server bases its memory grants in part based on the column definition. Oversize your column, and you’ll oversize your memory grant – which sounds good until you hit concurrency issues. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:05 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, потому что хранение таких строк в другой новой таблице потребует больших затрат, чем просто вынос этих строк в out-of-row. Причем затрат не только сервера, но и времени разработчика. Многие универсальные веб-формы вобще не умеют сохранять одну строку в две связанные таблицы. Нужно добавлять кастомизированную веб-форму. В процедурах ETL это тоже будет заметным усложнением. Одно дело просто в лоб XMLBulkLoad вызвать, а совсем другое - еще и переписывать то, что он сформировал. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:09 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ну тогда и не пойте здесь о скорости. все, что вас подталкивает на извращение, это "усложнение" в виде лени. если надо будет копировать все целиком, на приличном объеме разница в перетаскивании 2ух связанных таблиц, но полностью инроу и одной, но с лобами в виде лобов(b-tree), будет измеряться часами. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:14 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 про вставку я ничего не говорил. В моем случае, это очень редкая операция, по сравнению с выборкой. Да еще и не упоминать, что для принудительного хранения out-of-row нужны дополнительные настройки... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:16 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
invm, про указание принудительного хранения действительно забыл упомянуть. Тут вину признаю. А уж насколько он частный ни я, ни Вы, субъективно судить не можем. В моей практике он скорее общий, чем частный. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:26 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123 ну тогда и не пойте здесь о скорости. все, что вас подталкивает на извращение, это "усложнение" в виде лени. Какое отношение имеет к лени срыв сроков и удорожание проекта из-за дополнительной загрузки разработчиков? При этом, выделение в отдельную таблицу строк длинее, для примера, 200 символов, так же влечет за собой и дополнительную нагрузку на сервер. Я совсем не уверен, что она в итоге окажется меньше, чем простое вытеснение таких строк out-of-row P.S. Если Вы очень хотите прослыть демагогом - продолжайте дальше переходить на личности ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:29 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128, Упоминание только лишь про собственную практику и говорит о частности случая. Написали бы, что в основном нагрузка на чтение и получать строковые данные нужно очень редко - вопросов бы не было. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:38 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 Какое отношение имеет к лени срыв сроков и удорожание проекта из-за дополнительной загрузки разработчиков? а какое отношение ваши проекты имеют к скорости работы с ЛОБами? вы мне рассказываете об ускорении работы с таблицами за счет выноса инроу в оффроу, которые или мизерны, или вообще вам нужны только для приложений, которые не умеют работать с тем или этим. и мне смешно, т.к. мне наоборот пришлось избавлять таблицу от лобов в связи с жуткими тормозами. и как только мне говорят: мой селект возвращает 100 строк за 5 минут, мой первый вопрос это есть ли там треклятые ЛОБы. ЛОБы и скорость это в рамках SQL Server-а понятия ровно противоположные ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:39 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
invm, я честно написал "я предпочитаю" ))) И даже указал почему. Потому что эти строки мне, в подавлющем большинстве случаев, просто неинтересны. А размещение их in-row тормозит 90% выборок. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:44 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123 ptr128 Какое отношение имеет к лени срыв сроков и удорожание проекта из-за дополнительной загрузки разработчиков? а какое отношение ваши проекты имеют к скорости работы с ЛОБами? Сначала ответьте на мой вопрос. Отвечать вопросом на вопрос грубо и бескультурно. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:48 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 я честно написал "я предпочитаю" ))) И даже указал почему. не поверите, в MS посчитали, что наоборот, такие поля читают. и чтобы ускорить процесс, начиная с 2005-ого, на каждом углу пишут не использовать атавизмы в виде text/ntext/image. а использовать вытеснившие сии атавизмы varchar(max)/varbinary(max), которые всячески стараются хранить данные, где возможно, именно в инроу. это дефолтное поведение и его сделали таковым не назло вам, а на благо остальных. так что да, если бы вы написали свой ответ в ключе "а вот когда вы не намерены это читать, можно и этак извратиться", смотрелось бы это совсем по-другому. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:52 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123 и как только мне говорят: мой селект возвращает 100 строк за 5 минут, мой первый вопрос это есть ли там треклятые ЛОБы. Каждому свое ))) А мой первый вопрос: "План выполнения смотрел на предмет наличия table scan?" Второй вопрос: "Давно ли пересчитывались статистики?" Потому что lob могут замедлить запрос в несколько раз от силы. А вот table scan или протухшие статистики - на несколько порядков. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 15:56 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
когда пишут про топ 100 без сортировки, план типа очевиден. но можно, да, придраться, что у меня про топ не было сказано и заново устроить спор. предлагаю тему закрыть. кстати, вы тут видимо недавно, а вот давным-давно обсуждали как раз VARCHAR(MAX) VS VARCHAR(N) на второй странице ответ дает человек, очень хорошо разбирающийся в оптимизаторе. оставлю здесь ссылку: VARCHAR(MAX) VS VARCHAR(N) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 16:13 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, я тут совсем не недавно. Просто в будни у меня совешенно нет времени ходить по форумам, а в короткие еженедельные выходные занят совсем другими делами. Про все плюсы и минусы указания длины для полей я давно в курсе. Этак уже лет 15 ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 16:18 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 Yasha123, я тут совсем не недавно. Просто в будни у меня совешенно нет времени ходить по форумам, а в короткие еженедельные выходные занят совсем другими делами. Про все плюсы и минусы указания длины для полей я давно в курсе. Этак уже лет 15 ))) вот у меня тоже давно нет ни времени, ни желания тут находиться. вас честно говоря, не помню совсем. явно не пересекались. хотя контингент тут вообще поменялся на 90% за последние года 2. и весьма не в лучшую сторону. в старые добрые времена у меня был серый ник о-о. и если вы действительно тут давно, то наверное вспомните, что мне про план объяснять не надо. возможно, кто вас знает, тот тоже по огрызку фразы понял бы, что вы просто не написали про опцию, которой, если честно, мне ни разу не пришлось воспользоваться. а так-то выглядело все как всегда: рассуждения про 6000 символов, которые, если объявить как макс, сразу уйдут в оффроу, а зато по скорости ну сплошные выигрыши. вот отсюда и наезд. надеюсь, теперь можем мирно разойтись по своим делам :) и да,если вы есть на dba.stackexchange, можем списаться и приглашать друга на полную ахинею. там такое бывает, один плюсанет и пошло-поехало, стадное чувство. акину там вижу и тапак раньше был ( вам, товарищи, привет!) думаю, именно акина плюсанул там за ССЗБ, остальные вряд ли поняли, о чем это :) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 16:35 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128, скажите, пожалуйста, честно: эта особенность таблиц (large value types out of row) у ваших систем задокументирована или это сакральное знание, устно передающееся из поколения в поколение? Ее же не найти, если не знать о ней... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 17:05 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
.Евгений, По разному бывало ) На текущем проекте так: Во-первых, 'large value types out of row' = 1 вовсе не у всех таблиц. Есть исключения, хоть их и мало. Во-вторых, для удобства, список таких таблиц хранится в справочнике и этот справочник документирован. При разворачивании установка 'large value types out of row' = 1 производится только для таблиц перечисленных в справочнике. Перестройка таблиц при этом не производится. Удаление элемента из справочника не порождает автоматического сброса флага 'large value types out of row', но будет учтено при следующем разворачивании и флаг будет сброшен. Но опять таки без перестройки всей таблицы. Первоисточник, почему так сделано тут : If you are converting an existing LOB data type column (text, ntext, or image) to small-to-medium large value types (varchar(max), nvarchar(max), or varbinary(max)), and most statements do not reference the large value type columns in your environment, consider changing large_value_types_out_of_row to 1 to gain optimal performance. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 17:19 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123 когда пишут про топ 100 без сортировки, план типа очевиден. но можно, да, придраться, что у меня про топ не было сказано и заново устроить спор. предлагаю тему закрыть. кстати, вы тут видимо недавно, а вот давным-давно обсуждали как раз VARCHAR(MAX) VS VARCHAR(N) на второй странице ответ дает человек, очень хорошо разбирающийся в оптимизаторе. оставлю здесь ссылку: VARCHAR(MAX) VS VARCHAR(N) Вот тут даже не поленились экспериментально подтвердить: https://habr.com/ru/post/489182/ ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 09:55 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ОФФТОП Коллеги! вы сретесь тут хуже чем на полит форумах. такое ощущение, что вы готовы убить за sql server. я так долго живу, что еще помню старый добрый sql.ru форум, на котором старались помочь советом, а не замазать коллегу говном. для Код: sql 1.
не хватает места на диске. 50 Гиг откусывает за 2 минуты. придется просто удалять записи старше 6 месяцев. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 11:04 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser, Вы так и не поняли, что varchar(6000) не уменьшит место хранения по сравнению с varchar(8000)? Операцией замены типа только хуже сделали, как вами убедились. Переписывайте данные в новую таблицу, затем удалите старую, переименуйте новую и воссоздайте права, если необходимо. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 12:50 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser не хватает места на диске. Если таблицу сжать для начала, то места может хватить. Код: sql 1. 2.
потом уже переименуйте таблицу и скопируйте из нее данные в нужном виде. Ну или более трудоемкая альтернатива. bcp в файл, TRUNCATE TABLE, ALTER TABLE, BULK INSERT ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 13:44 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Владислав Колосов RegisteredUser, Вы так и не поняли, что varchar(6000) не уменьшит место хранения по сравнению с varchar(8000)? Операцией замены типа только хуже сделали, как вами убедились. Переписывайте данные в новую таблицу, затем удалите старую, переименуйте новую и воссоздайте права, если необходимо. наверно так и сделаю. спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 15:24 |
|
|
start [/forum/topic.php?fid=46&msg=40033660&tid=1685232]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 12ms |
total: | 154ms |
0 / 0 |