|
Вопрос на собеседовании (реальный)
|
|||
---|---|---|---|
#18+
Давным давно меня спросили: Как лучше (быстрее) вставить в таблицу миллион записей (тогда это было много). Я ответил так что все были счастливы и довольны и мне даже предложили работу:автор1. Удалить все индексы с таблицы 2. Заливать данные в транзакциях по маленьким кускам в цикле (скажем по 10К) 3. Пересоздать индексы. Сейчас понимаю что ответ был неверный. Думаю что нужно делать совсем по другому: автор1. Вылить вставляемые данные из таблицы в файл 2. Вылить все данные из конечной таблицы в другой файл 3. Создать новую таблицу по типу старой. 4. Залить булк инсертом оба файла в новую таблицу. 5. Воссоздать индексы на новой таблице как на старой (конечной). 6. Залочить старую (конечную) таблицу от любых изменений 7. Применить к новой таблице все изменения что произошли в старой с момента №2. 8. Полностью залочить старую таблицу. 9. Переименовать старую таблицу. 10. Переименовать новую таблицу в имя конечной таблицы. Вся цель состоит в том что время простоя конечной таблицы по записи сводится ко времени внесения изменений в новую, а по чтению только ко переименования обьектов в базе. Покритикуйте пожалуйста если я что-то упустил. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2013, 02:59 |
|
Вопрос на собеседовании (реальный)
|
|||
---|---|---|---|
#18+
автор1. Вылить вставляемые данные из таблицы в файл 2. Вылить все данные из конечной таблицы в другой файл 3. Создать новую таблицу по типу старой. 4. Залить булк инсертом оба файла в новую таблицу.А для чего нужны внешние файлы? Почему бы не использовать сразу SELECT ... INTO, INSERT ... INTO? Еще вы забыли упомянуть про recovery model и прочие условия минимального логирования, ради чего, как я понимаю, всё и затевалось. ЗЫ: ну и протестировать не долго, если так интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2013, 06:07 |
|
Вопрос на собеседовании (реальный)
|
|||
---|---|---|---|
#18+
Ruuuавтор1. Вылить вставляемые данные из таблицы в файл 2. Вылить все данные из конечной таблицы в другой файл 3. Создать новую таблицу по типу старой. 4. Залить булк инсертом оба файла в новую таблицу.А для чего нужны внешние файлы? Почему бы не использовать сразу SELECT ... INTO, INSERT ... INTO? Еще вы забыли упомянуть про recovery model и прочие условия минимального логирования, ради чего, как я понимаю, всё и затевалось. ЗЫ: ну и протестировать не долго, если так интересно. Даже при симпл рековери все изменения пишутся в файл. В нашем случае мы предполагаем что у нас фулл. В очень загруженой OLTP, делая всё через BCP мы тем самым снимаем какую-бы то ни было нагрузку на лог файл. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2013, 06:24 |
|
Вопрос на собеседовании (реальный)
|
|||
---|---|---|---|
#18+
SandalTreeВ нашем случае мы предполагаем что у нас фулл. В очень загруженой OLTP, делая всё через BCP мы тем самым снимаем какую-бы то ни было нагрузку на лог файл.Prerequisites for Minimal Logging in Bulk ImportFor a database under the full recovery model, all row-insert operations that are performed by bulk import are fully logged in the transaction log. Large data imports can cause the transaction log to fill rapidly if the full recovery model is used. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2013, 06:37 |
|
Вопрос на собеседовании (реальный)
|
|||
---|---|---|---|
#18+
RuuuSandalTreeВ нашем случае мы предполагаем что у нас фулл. В очень загруженой OLTP, делая всё через BCP мы тем самым снимаем какую-бы то ни было нагрузку на лог файл.Prerequisites for Minimal Logging in Bulk ImportFor a database under the full recovery model, all row-insert operations that are performed by bulk import are fully logged in the transaction log. Large data imports can cause the transaction log to fill rapidly if the full recovery model is used. Значит я где-то просчитался. Буду править. Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.11.2013, 08:16 |
|
|
start [/forum/topic.php?fid=34&fpage=9&tid=1549974]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
49ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
others: | 251ms |
total: | 382ms |
0 / 0 |