|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
почему так получилось: - почистил немного данные в БД, а в одной из таблиц еще решил уменьшить длину поля ReqJson (было varchar 8000) Выполнил Код: sql 1.
До начала операции на диске было свободно более 65Гб. я наблюдал за ростом файла БД и лога пока длилась операция Операция прошла успешно, лог урезался, а вот файл БД на диске так и остался большим (свободное место сейчас чуть более 47Гб). Почему так? И что можно сделать, чтобы освободить место на диске? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 22:38 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser, Шринк? Лучше смотрите не место на диске, а свойства базы данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 22:50 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
godsql RegisteredUser, Шринк? Лучше смотрите не место на диске, а свойства базы данных. лог урезался как раз после DBCC SHRINKDATABASE ([JMProd]); а вот mdf остался большим ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 23:04 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser, А почему должна была уменьшиться база? varchar указывает на максимально допустимый размер, который может быть выделен при сохранении строки. Очевидно, Вы путаете с char типом. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 23:08 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
проблема локализовна: - созданы доп. файлы tempdb что с ними делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 23:10 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser, Это правильно, количество файлов должно зависеть от количества ядер. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 23:30 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Владислав Колосов, тогда вопрос остается открытым - данных стало меньше, а размер БД вырос гиг на 15 после alter column ... |
|||
:
Нравится:
Не нравится:
|
|||
04.01.2021, 23:38 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser Владислав Колосов, тогда вопрос остается открытым - данных стало меньше, а размер БД вырос гиг на 15 после alter column Ты, наверное, думаешь, что трансформация таблицы производится сферическим святым духом в вакууме? Наивняк. Был создан новый столбец в таблице, скопированы туда данные, а затем старый столбец удален. Вот тебе, бабушка, и 15 Гб. А тот чего бы сервер жужжал диском столько долго... ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 08:36 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser файл БД на диске так и остался большим RegisteredUser размер БД вырос гиг на 15 после alter column aleks222 Был создан новый столбец в таблице, скопированы туда данные, а затем старый столбец удален. Там же только метаданные меняются. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 10:11 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
alexeyvg Там же только метаданные меняются. За чем же тогда "наблюдал" страдалец? Создание пустого столбца "не понаблюдаешь". ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 10:17 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser Почему так? И что можно сделать, чтобы освободить место на диске? Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 11:05 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
А что делать - так страдальцу и не сказали! Код: sql 1.
спасет отца русской демократии! ЗЫ: Размер поменял зря. Ни пользы от этого, ни удовольствия. Размер varchar должен быть примерно в 2 раза больше средней длины хранящихся в поле данных, при этом, разумеется, не меньше максимально возможного размера данных, которые там предстоит хранить. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 12:16 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
uaggster, так как подобные поля очень редко нуждаются в индексации, то я предпочитаю сразу делать их [n]varchar(max). Как плюс, места в кортежах они почти не занимают (24 байта на каждое) и обслуживание таблиц ускоряется. Как минус, нужно помнить о лимите в 8060 байт для сортировки. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 12:42 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 uaggster, так как подобные поля очень редко нуждаются в индексации, то я предпочитаю сразу делать их [n]varchar(max). Как плюс, места в кортежах они почти не занимают (24 байта на каждое) и обслуживание таблиц ускоряется. Как минус, нужно помнить о лимите в 8060 байт для сортировки. лажа это, прости господи. если значение поля влазит в инроу, то там и будет размещено. так что если значения по длине не превышают 6000 символов, как ни объявляй, varchar(6000) или varchar(max), покуда длина строки не превысит 8060, размещение будет одинаковым. и уж ни о каком ускорении речи не идет вовсе. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 13:56 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 так как подобные поля очень редко нуждаются в индексации, то я предпочитаю сразу делать их [n]varchar(max). Как плюс, места в кортежах они почти не занимают (24 байта на каждое) и обслуживание таблиц ускоряется. 2. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8.
... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 13:57 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123 лажа это, прости господи. если значение поля влазит в инроу, то там и будет размещено. Если чего-то не знаете, то из этого не следует, что этого нет ))) invm create table dbo.t3 (id int identity primary key, s varchar(max)); exec sp_tableoption 'dbo.t3', 'large value types out of row', 1; ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:07 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
invm, про вставку я ничего не говорил. В моем случае, это очень редкая операция, по сравнению с выборкой. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60.
... (1 row affected) Table 't1'. Scan count 1, logical reads 1295, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 2 ms. SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. (1 row affected) Table 't2'. Scan count 1, logical reads 1295, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 2 ms. SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. (1 row affected) Table 't3'. Scan count 1, logical reads 39, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. SQL Server Execution Times: CPU time = 0 ms, elapsed time = 1 ms. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:14 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 Yasha123 лажа это, прости господи. если значение поля влазит в инроу, то там и будет размещено. Если чего-то не знаете, то из этого не следует, что этого нет ))) invm create table dbo.t3 (id int identity primary key, s varchar(max)); exec sp_tableoption 'dbo.t3', 'large value types out of row', 1; чего уж так извращаться-то, объявляйте сразу text. а лучше и вовсе на 2000-ый переходите, ваша логика его достойна. кстати, что там про ускорение-то? жду тест, когда благодаря вашему извращению хоть что-то ускорится (что замедлится как вставка, так и выборка, я вам на раз продемонстрирую) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:16 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, откройте спойлер выше. На примере от invm - в два раза! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:19 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
о, да это песня, мало того, что в приведенном тесте вообще читаются только инроу-страницы, так товарищ еще и не в курсе, что читать лобы будет куда дольше. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:19 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, я отлично знаю, что чтение out-of-row будет медленней. Но когда на практике в 90% запросов они не читаются, так как содежат всяческие комментарии для пользователей или тому подобный текст, но зато тормозят обработку данных и обслуживание индексов, я выбираю out-of-row. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:23 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 Yasha123, откройте спойлер выше. На примере от invm - в два раза! дарагуля, в спойлере выше все строки есть инроу (lob logical reads 0) расхотелось уже хранить свои максы в лобах или пример со сменой способа хранения лобов только мне показал, а себе применить забыл? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:24 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, читать научитесь. Полезно будет ))) exec sp_tableoption 'dbo.t3', 'large value types out of row', 1 ... Table 't1'. Scan count 1, logical reads 1295 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 't2'. Scan count 1, logical reads 1295 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 't3'. Scan count 1, logical reads 39 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Просто на практике у меня выборки в хранимых процедурах в 90% out-of-row не используют ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:26 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
ptr128 Yasha123, читать научитесь. Полезно будет ))) exec sp_tableoption 'dbo.t3', 'large value types out of row', 1 ... Table 't1'. Scan count 1, logical reads 1295 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 't2'. Scan count 1, logical reads 1295 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Table 't3'. Scan count 1, logical reads 39 , physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. Просто на практике у меня выборки в хранимых процедурах в 90% out-of-row не используют ))) ну давай вместе поучимся: авторTable 't1'. Scan count 1, logical reads 1295 , physical reads 0, read-ahead reads 0, lob logical reads 0 , lob physical reads 0, lob read-ahead reads 0. Table 't2'. Scan count 1, logical reads 1295 , physical reads 0, read-ahead reads 0, lob logical reads 0 , lob physical reads 0, lob read-ahead reads 0. Table 't3'. Scan count 1, logical reads 39 , physical reads 0, read-ahead reads 0, lob logical reads 0 , lob physical reads 0, lob read-ahead reads 0. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:29 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Yasha123, Лично для Вас фонт покрупнее. Может со зрением плохо? на практике у меня выборки в хранимых процедурах в 90% out-of-row не используют Table 't1'. Scan count 1, logical reads 1295 Table 't2'. Scan count 1, logical reads 1295 Table 't3'. Scan count 1, logical reads 39 То есть, за счет того, что в последней таблице строки были вынесены out-of-row, количество logical reads при выборке из этой таблице, в которой эти строки не участвуют, сократилось в 33 раза! ... |
|||
:
Нравится:
Не нравится:
|
|||
05.01.2021, 14:33 |
|
Почему файл БД вырос после 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 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
RegisteredUser наверно так и сделаю. Ребилд таблицы и есть создание новой и удаление старой. Без лишних приседаний, озвученных Владиславом Колосовым. Так что, если ребилд не помог, то и ручное переписывание не поможет. Есть такой вариант: 1. Выгрузить данные с помощью bcp туда, где есть место 2. Очистить таблицу truncate'ом 3. Поменять длину столбца 4. Если модель восстановления full - перевести БД в bulk_logged или simple 5. Выгруженные в п.1 данные залить обратно. 6. При необходимости вернуть модель восстановления full ЗЫ: См. в документации порядок действий, необходимый для смены full в bulk_logged или simple. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 16:11 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 16:16 |
|
Почему файл БД вырос после alter column
|
|||
---|---|---|---|
#18+
Владислав Колосов RegisteredUser, Вы так и не поняли, что varchar(6000) не уменьшит место хранения по сравнению с varchar(8000)? Операцией замены типа только хуже сделали, как вами убедились. Переписывайте данные в новую таблицу, затем удалите старую, переименуйте новую и воссоздайте права, если необходимо. RegisteredUser для Код: sql 1.
не хватает места на диске. 50 Гиг откусывает за 2 минуты. Не, старый добрый SQL-форум инфаркт хватит. От таких советов. Шо, копия таблицы места не занимает? Зы. Вот тредстартеру неймется. Спи спокойно, дарагой товарисчЪ. Со временем, старые записи будут удалены, страницы освобождены, а вместе с ними и старый столбец. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.01.2021, 16:21 |
|
|
start [/forum/topic.php?all=1&fid=46&tid=1685232]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
60ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
71ms |
get tp. blocked users: |
1ms |
others: | 290ms |
total: | 466ms |
0 / 0 |