|
Как ускорить перенос данных из одной БД в другую?
|
||
|---|---|---|
Участник
Откуда: Москва
Сообщения: 9 956 |
||
| 05.09.2019, 12:51 |
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
Satans ClawsYasha123разница в 4 раза это простая модель в явном виде. типа перевел базу в полную, бэкап сделать "забыл". Сорри за оффтоп (я автор, мне можно :D ), но можно с этого момента подробнее? Я правильно понимаю, что, поскольку в FULL-модели восстановления лог содержит информацию о всех транзакциях с момента последнего бэкапа - то пока бэкапа не будет, логу нет стартовой точки, чтоб начать хранить эту информацию (соответственно, в лог ничего не пишется). Обратный переход (FULL -> SIMPLE) применяется сразу? да, хорошее объяснение. нет смысла писать лог, когда нет начальной точки. ее нельзя взять с потолка, не имея затронутого изменениями куска данных. имея такой лог, ничего откатить нельзя, ведь начатые на момент перевода в полную модель транзакции откатить будет невозможно, лог с записями о них мог перезаписаться, а файл данных на этот момент не забэкаплен. про обратный переход тоже верно, просто дается сигнал логу не удерживать более записи для бэкапа лога ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 10:13 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
Yasha123msLexпропущено... А не встречался ли вам какой-нибудь список условий, при которых включается "постраничное" логирование? По какой-то неясно для меня причине, он не совпадает с условиями минимпльного логирование? мне не встречался, но из соображений здравого смысла: если идет вставка с таблоком и в кучу(пустую или нет неважно), таблица эксклюзивно блокирована и никто другой вставить не может за все время вставки. отсюда вывод: данные будут вставляться страницами. мы валим все подряд и нет никаких причин вставлять их куда-то в середину(т.е. построчно) -> будет логироваться постранично. если вставка в кластерный с tablock и order by таблица пуста, все ровно то же самое, мы валим точно в конец, т.е. пишем новые целые страницы подряд. будет логироваться постранично. ну а вставка в непустой кластерный, хоть бы и отсортированный набор вставляем, может оказаться вставкой вперемежку с уже имеющимся, простейший пример: уже вставлены нечетные числа, а теперь свтавляем четные, хоть бы и упорядоченные. все равно вставка пойдет в уже имеющиеся страницы. вывод: постраничного логирования не будет, только построчное т.е. на первый взгляд все те же условия, что и для минимального логирования в simple и bulk logged. у вас есть примеры, когда не так? думаю, еще есть ограничение на объем. если строк мало, будет построчно в любой модели Здравый смысл мне тоже подсказывает, что постраничное логирование должно происходить при тех же условиях, что и минимальное (с разницей лишь в модели восстановления), но... Я проводил небольшие эксперименты, с целью понять в каких случаях происходит постраничное логирование. За основу брал вот эти условия по минимальному логирования. У меня получалось, что постраничное логирование включается только в двух или трех случаях из указанных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 11:27 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
msLex Я проводил небольшие эксперименты, с целью понять в каких случаях происходит постраничное логирование. За основу брал вот эти условия по минимальному логирования. У меня получалось, что постраничное логирование включается только в двух или трех случаях из указанных. ваша таблица мне подозрительна. вставка в кластерный без таблока не может минимально логироваться, равно как и постранично. возможна же конкурентная вставка, между вашими строками может влезть чужая, это же кластер. поэтому только построчно и уж никак не минимально. вот правильная таблица, она не конфликтует с моими рассуждениями и по опыту соответствует действительности. на картинке: зеленым то, что соответствует минимальному или постраничному логированию (в зависимости от модели) красным: в это я не верю, см. рассуждение выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 11:48 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
да и 2 строки под красным тоже подозрительны. вставка в непустой кластер хоть с таблоком хоть без невозможно минимально логировать. почему именно постранично-то пойдет, может, как раз вставится среди имеющегося(см.пример чет-нечет) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 12:05 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
Yasha123да и 2 строки под красным тоже подозрительны. вставка в непустой кластер хоть с таблоком хоть без невозможно минимально логировать. почему именно постранично-то пойдет, может, как раз вставится среди имеющегося(см.пример чет-нечет) С 2016 TF610 стал работать по умолчанию, и если глянуть на вашу таблицу (но в соседний столбик), то таблицы совпадут. PS Ваша табличка из ссылки на SQL 2008 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 12:37 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
Yasha123вставка в непустой кластер хоть с таблоком хоть без невозможно минимально логировать.Inside Microsoft® SQL Server® 2008: T-SQL QueryingSQL Server 2008 also introduces support for minimal logging when inserting data into a nonempty B-tree (clustered or nonclustered index). Minimal logging is used when inserting new key ranges that allocate and populate new pages while TF-610 is on regardless of whether the TABLOCK hint is specifi ed. For those new key ranges, SQL Server internally takes key-range locks to ensure that other processes don’t run confl icting activities. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 12:51 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
msLexС 2016 TF610 стал работать по умолчанию, и если глянуть на вашу таблицу (но в соседний столбик), то таблицы совпадут. понятно. не было возможности тестировать на 2016-ом, он у меня хоть и стоит локально, руки не доходят. рабочий сервер 2014, и на нем у меня включен TF610. ну что могу сказать. у меня нет куч и нет пустых таблиц. а вставка в непустой кластер + индекс всегда логируется полностью (у нас простая модель), так что не Depends, а постоянное полное логирование. причем не только в индекс, а даже в сам кластерный. это даже при том, что у них тут кластерный везде и всюду по id identity, и любая вставка с таблоком это гарантированные новые страницы в конец таблицы это на тестовом. в прод у меня таблок не пошел вообще, т.к. выигрыша по времени никакого, а блокировать остальных нехорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 12:58 |
|
||
|
Как ускорить перенос данных из одной БД в другую?
|
|||
|---|---|---|---|
|
#18+
invmYasha123вставка в непустой кластер хоть с таблоком хоть без невозможно минимально логировать.Inside Microsoft® SQL Server® 2008: T-SQL QueryingSQL Server 2008 also introduces support for minimal logging when inserting data into a nonempty B-tree (clustered or nonclustered index). Minimal logging is used when inserting new key ranges that allocate and populate new pages while TF-610 is on regardless of whether the TABLOCK hint is specifi ed. For those new key ranges, SQL Server internally takes key-range locks to ensure that other processes don’t run confl icting activities. ну он может и introduces, только у меня inserting data into a nonempty B-tree (clustered or nonclustered index) логирует полностью ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2019, 13:04 |
|
||
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1687323]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
91ms |
get topic data: |
13ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
63ms |
get tp. blocked users: |
2ms |
| others: | 257ms |
| total: | 475ms |
| 0 / 0 |
