|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Всем привет, есть несколько сотен однотипных таблиц, во всех требуется поменять тип поля INT на BIGINT. Есть возможность лочить эти таблицы на какое то время, размер таблиц разный, от 0 до 200млн записей. Есть следующие вопросы: 1. Если я поменяю тип через дизайнер, как я понимаю, все данные из таблицы перельются во временную таблицу, потом таблица пересоздается и из временной таблицы данные зальются обратно? 2. Что будет блокировано в случае п1 кроме самой таблицы? При тестах, я наблюдаю, что в момент перестроения таким образом таблицы, из студии нет возможности просматривать список элементов всей базы, например таблицы, хранимки итд. 3. Или есть более удобные средства для этих задач? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 15:38 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa Всем привет, есть несколько сотен однотипных таблиц, во всех требуется поменять тип поля INT на BIGINT. Есть возможность лочить эти таблицы на какое то время, размер таблиц разный, от 0 до 200млн записей. Есть следующие вопросы: 1. Если я поменяю тип через дизайнер, как я понимаю, все данные из таблицы перельются во временную таблицу, потом таблица пересоздается и из временной таблицы данные зальются обратно? 2. Что будет блокировано в случае п1 кроме самой таблицы? При тестах, я наблюдаю, что в момент перестроения таким образом таблицы, из студии нет возможности просматривать список элементов всей базы, например таблицы, хранимки итд. 3. Или есть более удобные средства для этих задач? 1. Какая тебе разница, если ты по другому не умеешь? 2. Блокировка схемы. Студия ждет. 3. Вангую identity. В прочих случая alter table alter column спасет страдальца. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 15:43 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
aleks222 1. Какая тебе разница, если ты по другому не умеешь? Как например? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 16:01 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa 2. Что будет блокировано в случае п1 кроме самой таблицы? до кучи тех таблиц, у которых ФК смотрели на эту таблицу. ибо кроме перелива данных, сперва скриптуются, затем дропаются, а потом восстанавливаются все ФК, которые на таблицу смотрели. так что сама таблица может быть и из 10 строк каких-то "типов", а ссылающаяся таблица (если не сотня таблиц) в 300Гб, и пока она вся будет проверяться, она будет залочена. что за любовь к GUI? пишите alter table alter column. P.S. если там и правда ФК, все их все равно придется дропать и менять еще и типы в ссылающихся таблицах. P.P.S. а дерьмо с identity лучше сразу на сиквенс переделать ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 16:27 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Yasha123, Через гуи я скрипт изменений сгенерировал, а потом посмотрел, что сервер делать планирует. У меня 7800+таблиц, через гуи это просто не реально реализовать. На интересующую меня таблицу выполнил вот такой запрос: Код: sql 1.
получаю пустой результат. Значит на эту таблицу нет внешних ссылок. Я сейчас планирую, как автоматизировать этот процесс. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:08 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa, Например из всего реестра я сначала выберу таблицы где 0 строк, таких 5887, и по очереди выполню на них: Код: sql 1.
Или альтернатива просто удалить таблицу и пересоздать её новой хранимкой?? Мне кажется, что разница небольшая.. Тк внешних ключей на таблицах нет, схема будет блокироваться на короткое время, правильно я понимаю? Когда схема блокирована, не могут создаваться таблицы, этого хочется избежать, поэтому рейтинг строк можно поднимать до долгих блокировок схемы. Самые тяжелые таблицы нужно смотреть отдельно, тк переливать данные в новую таблицу, а их будет сотня точно, все разом не перелить - упрусь в место на диске, по очереди - может долго получиться. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:21 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Yasha123 а дерьмо с identity лучше сразу на сиквенс переделать обоснование? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:27 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa, составьте себе уже запросы через метаданные Код: 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.
запрос нужно модифицировать если внешний ключ составной (состоящий из более чем одной колонки) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:33 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
felix_ff, Пустой результат: Код: sql 1.
разве не означает, что Код: sql 1.
для данных таблиц не потребуется? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:41 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa teCa, Например из всего реестра я сначала выберу таблицы где 0 строк, таких 5887, и по очереди выполню на них: Код: sql 1.
Когда схема блокирована, не могут создаваться таблицы, этого хочется избежать, поэтому рейтинг строк можно поднимать до долгих блокировок схемы. Вы не понимаете что такое блокировка схемы, это не сущность "схема" в которой живет таблица. это будет навешен тип блокировки Sch-M (Schema Modification) на объекты которая затрагивает инструкция. в данном случае это будут обе таблицы (и мастер и дочерняя). и вот с ними никакие другие сессии ничего выполнить не смогут, ни на каком уровне изоляции (ни ALTER ни тем более SELECT/INSERT/UPDATE/DELETE). а таблицы в схеме в которой живут эти ваши таблицы вы сможете создавать в любой момент. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:41 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa felix_ff, Пустой результат: Код: sql 1.
разве не означает, что Код: sql 1.
для данных таблиц не потребуется? ну так посмотрите что вернет мой запрос, там где внешних ключей на таблице нет, он и не сформирует строки запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:43 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
felix_ff teCa teCa, Например из всего реестра я сначала выберу таблицы где 0 строк, таких 5887, и по очереди выполню на них: Код: sql 1.
Когда схема блокирована, не могут создаваться таблицы, этого хочется избежать, поэтому рейтинг строк можно поднимать до долгих блокировок схемы. Вы не понимаете что такое блокировка схемы, это не сущность "схема" в которой живет таблица. это будет навешен тип блокировки Sch-M (Schema Modification) на объекты которая затрагивает инструкция. в данном случае это будут обе таблицы (и мастер и дочерняя). и вот с ними никакие другие сессии ничего выполнить не смогут, ни на каком уровне изоляции (ни ALTER ни тем более SELECT/INSERT/UPDATE/DELETE). а таблицы в схеме в которой живут эти ваши таблицы вы сможете создавать в любой момент. Спасибо за подробное разъяснение! Меня сбила с толку блокировка студии на объекте в базе, то, что данные были доступны я видел. Это упрощает задачу. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:45 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
felix_ff teCa felix_ff, Пустой результат: Код: sql 1.
разве не означает, что Код: sql 1.
для данных таблиц не потребуется? ну так посмотрите что вернет мой запрос, там где внешних ключей на таблице нет, он и не сформирует строки запроса. Да, пустой результат. Спасибо за скрипт! ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:48 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Критик Yasha123 а дерьмо с identity лучше сразу на сиквенс переделать обоснование? вот чтобы в след. раз возможно было менять такую колонку. и структуру, и данные. и чтобы если уж придется куда переливать, хотя бы чтобы сорта в плане не было, когда упорядоченное в упорядоченное же переливаешь. + еще этот дерьмантин любят вставлять с IDENTITY_INSERT. и это сразу вываливает юзера из обычного db_datawriter и требует ALTER на таблицу. а когда такие таблицы еще и "намечены в будущем", так и на всю схему. что весьма жирно ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 17:50 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa, 1. На основе метаданных получить перечень таких столбцов, исключив вычисляемые. 2. На основе перечня из п.1 сгенерировать скрипты создания для ключей, индексов, ограничений, вычисляемых столбцов, schema-bound объектов, индексированных представлений, куда эти столбцы входят. 3. Удалить все сущности из п.2 4. Для всех столбцов из п.1 сгенерировать и выполнить инструкцию alter table ... alter column ... 5. Пересоздать удаленные сущности скриптами из п.2 6. Для обычных представлений, куда входят столбцы и п.1 выполнить sp_refreshview ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 18:05 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Yasha123 вот чтобы в след. раз возможно было менять такую колонку. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 18:08 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
invm teCa, 1. На основе метаданных получить перечень таких столбцов, исключив вычисляемые. 2. На основе перечня из п.1 сгенерировать скрипты создания для ключей, индексов, ограничений, вычисляемых столбцов, schema-bound объектов, индексированных представлений, куда эти столбцы входят. Если я в студии сгенерирую запрос на изменение, все перечисленные в п2 объекты, должны в этом скрипте быть? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.11.2020, 18:34 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa, Странно, но сервер предлагает в этом случае удалить таблицу и пересоздать новую. Может действительно выгоднее использовать такую конструкцию? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2020, 16:26 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
teCa Всем привет, есть несколько сотен однотипных таблиц, во всех требуется поменять тип поля INT на BIGINT. Есть возможность лочить эти таблицы на какое то время, размер таблиц разный, от 0 до 200млн записей. Есть следующие вопросы: 1. Если я поменяю тип через дизайнер, как я понимаю, все данные из таблицы перельются во временную таблицу, потом таблица пересоздается и из временной таблицы данные зальются обратно? 2. Что будет блокировано в случае п1 кроме самой таблицы? При тестах, я наблюдаю, что в момент перестроения таким образом таблицы, из студии нет возможности просматривать список элементов всей базы, например таблицы, хранимки итд. 3. Или есть более удобные средства для этих задач? у меня 2 года назад была обратная задача в MySQL я менял bigint в int (там цель была уменьшить БД) - и где то 1/3 БД подрезал единственный полезный момент к-й я помню - я вначале сгенерил скрипт alter table для кждого столбца ( метаданные прочитал - и сделал ) а в некоторых таблицах было по 8-9 полей - после ревью чел заметил - что я меняю одну таблицу 8 раз - ну я подфиксил скрпит с одним Alter для одной таблицы - и время апдейта сократилось в 3 раза PS таки вещи конечно делаются в окна (обычно ночью) варианты с дропами и ре-креатами индексов (кроме PK ) понятны тут проще посмотреть на самых больших таблицах - будет ли выигрыш (думаю в зависимости от кол-ва индексов) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2020, 16:29 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Yasha123 teCa 2. Что будет блокировано в случае п1 кроме самой таблицы? до кучи тех таблиц, у которых ФК смотрели на эту таблицу. ибо кроме перелива данных, сперва скриптуются, затем дропаются, а потом восстанавливаются все ФК, которые на таблицу смотрели. так что сама таблица может быть и из 10 строк каких-то "типов", а ссылающаяся таблица (если не сотня таблиц) в 300Гб, и пока она вся будет проверяться, она будет залочена. что за любовь к GUI? пишите alter table alter column. P.S. если там и правда ФК, все их все равно придется дропать и менять еще и типы в ссылающихся таблицах. P.P.S. а дерьмо с identity лучше сразу на сиквенс переделать Веселуха "несколько сотен однотипных таблиц"+"размер таблиц разный, от 0 до 200млн записей." ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2020, 16:31 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Гулин Федор единственный полезный момент к-й я помню - я вначале сгенерил скрипт alter table для кждого столбца ( метаданные прочитал - и сделал ) а в некоторых таблицах было по 8-9 полей - после ревью чел заметил - что я меняю одну таблицу 8 раз - ну я подфиксил скрпит с одним Alter для одной таблицы - и время апдейта сократилось в 3 раза не знаю, что там в MySQL, но у ТС SQL Server, и одним альтером 8 полей он не поменяет. 8 полей, 8 альтеров, и дай ему бог поменять вообще хоть как и не развалить все, с его-то отношением к ФК. которые могут быть каскадными ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2020, 16:41 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Ролг Хупин Веселуха "несколько сотен однотипных таблиц" напоминает творчество моего начальника, у которого все справочники однотипные: id bigint identity + колонка с расшифровкой. при параллельной разработке на девелоперском сервере возникает новый тип, ему генерится новый id, допустим 100. в это время на проде тоже возникает новый тип, но другой, зато ему тоже генерится новый id = 100. а потом они пытаются с дева на прод перенести, и этот id уже занят. текучка кадров постоянная, и каждому приходилось заново объяснять, что identity не апдэйтится. всех прямым ходом к начальнику, чтобы сами колбасились со своей "синхронизацией identity" под его объяснения, зачем всем так нужен identity в справочниках --- теперь начальник сдался и у нас больше нет ни одного справочника с identity. --- кроме гадостей в адрес identity не могу сказать ничего ... |
|||
:
Нравится:
Не нравится:
|
|||
12.11.2020, 16:58 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Yasha123 Критик пропущено... обоснование? вот чтобы в след. раз возможно было менять такую колонку. и структуру, и данные. и чтобы если уж придется куда переливать, хотя бы чтобы сорта в плане не было, когда упорядоченное в упорядоченное же переливаешь. имхо конечно, но ерунда ваше обоснование, изменение такого столбца - дело довольно редкое, в 99% решается просто из SSMS, в 1% скриптами, если таблица большая ) а сиквенс нужен там, где есть 2-5-10 сущностей, которые нужно заполнять в рамках одного идентификатора, лепить их везде просто чтобы было - это так себе решение ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2020, 09:01 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Критик имхо конечно, но ерунда ваше обоснование обоснования всей гадкости identity у меня выше даны. при смене типа в здоровой таблице, которую нельзя было блокировать, ибо все в нее пишут, другого выхода просто не было. переливать пришлось в такую же, но с нужным типом и без идентити. переливаться в такой же кластерный с идентити без сорта сервер противился, а зато в таблицу с сиквенсом без сорта перелилось, сиквенс пустили с началом на 1000000 больше, чем был макс. ид переливаемой таблицы. в старую спокойно писали во время перелива, потом ренэйм и вот все уже пишут в таблицу с сиквенсом, а я спокойно доливаю то, что навставляли во время перелива. а теперь расскажите, как без блокировки основной таблицы с идентити в 100Гб можно было переделать тип столбца с идентити. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2020, 12:48 |
|
Смена типа int на bigint в большом количестве однотипных таблиц?
|
|||
---|---|---|---|
#18+
Критик а сиквенс нужен там, где есть 2-5-10 сущностей, которые нужно заполнять в рамках одного идентификатора, лепить их везде просто чтобы было - это так себе решение совсем даже не обязательно несколько сущностей иметь. у меня, например, логирование процедур построено на паре, идентити + сиквенс. процедура в самом начале отцепляет себе execution_id, это определяет данный вызов процедуры. с этим execution_id заполняются строки лога после каждой выполненной инструкции. а так на таблице есть ид идентити, особо никого не интересующий, но подходит для ПК. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.11.2020, 13:10 |
|
|
start [/forum/topic.php?fid=46&msg=40017279&tid=1685413]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
57ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 303ms |
total: | 456ms |
0 / 0 |