Satans ClawsПоскольку в База1 Таблица1 пустая, я её могу даже грохнуть и сделать


а потом создать нужный индекс.
Будет ли это быстрее?
будет, если модель простая или bulk_logged

OBGSatans Claws,
Заблокируйте таблицу (с помощью TABLOCK): https://docs.microsoft.com/ru-ru/sql/relational-databases/import-export/prerequisites-for-minimal-logging-in-bulk-import?view=sql-server-2017
и что?
1. если у него полная модель, то все равно полное логирование обеспечено
2. он написал, на таблице есть индекс.
вот тут правильная таблица: The Data Loading Performance Guide
сходите и убедитесь, что одного таблока точно не хватит,
как минимум нужен TF610,
но по личному опыту: и с флагом тоже при имеющемся индексе будет полное логирование

OBGВот тут http://www.t-sql.ru/post/min_logged_with_full_recovery.aspx есть пример, разница во времени выполнения запросов с TABLOCK и без составляет 25% в базе данных с режимом восстановления FULL.
У меня в этом же примере разница составила почти 4 раза (предварительно увеличил базу до необходимого размера, данные в кэш загрузил):


чукча не читатель?
у ТС на таблице индекс.
а в этом примере нет.
ну навесьте индекс и заново проверьте

OBGВот тут http://www.t-sql.ru/post/min_logged_with_full_recovery.aspx есть пример, разница во времени выполнения запросов с TABLOCK и без составляет 25% в базе данных с режимом восстановления FULL.
У меня в этом же примере разница составила почти 4 раза (предварительно увеличил базу до необходимого размера, данные в кэш загрузил):


да и ваша "полная модель" вызывает сомнения.
база тестовая?
бэкап делали?
липой попахивает

OBGТС пишет, что может удалить не только индекс, но и таблицу:


ТС-то пишет, а вы -- НЕТ.
вы ему советуете голый таблок.

вот вам репро с голым таблоком в присутствии индекса,
с таблицами из той самой ссылки,
которую типа мне надо открыть:

TaPaKавторУ меня в этом же примере разница составила почти 4 раза (предварительно увеличил базу до необходимого размера, данные в кэш загрузил):

ага, ещё лог урезать в минимум и вообще можно не нарадоваться
разница в 4 раза это простая модель в явном виде.
типа перевел базу в полную, бэкап сделать "забыл".
его в явном виде спрашиваешь про бэкап, а в ответ "сам чукча"

OBGКластерный индекс по val varchar(255)?

Модератор: Божественное вложение от мастера скриншотов удалено.
не знаю, какой индекс был у оппонента,
мои индексы некластерные,
это ежику понятно,
ибо если неоговорено противное, индекс дефолтно создается некластерным:
BOLIf not otherwise specified, the default index type is NONCLUSTERED.
CREATE INDEX (Transact-SQL)

в целях завершения дебатов
+ специально для чукчи
повторяю ровно тот самый эксперимент,
что описан по ссылке (см. картинку), без индексов

как видим, никакой разницы в 4 раза нет.
есть те самые 25% экономии по времени,
о которых пишет Князев.

так что

1. привет тем, кто переводит в полную модель без полного бэкапа.
мои поздравления, база ни в какой не в полной модели, она в pseudo simple.
иначе не видать вам приращения скорости в 4 раза.

2. Князев же показал, что базу можно восстановить на произвольный момент времени.
так что никакого минимального логирования в полной модели нет и быть не может.

полная модель -- это такая модель,
при кототрой записи лога позволяют полностью восстановить операцию.
ну так ушедшее в лог при инсерте с таблоком содержит все данные,
потому и возможно восстановление.
это никакое не allocation page, allocation page,..., пустышки, которые только для роллбэка и нужны.

то, о чем тут речь, зовется efficiently logged operation.
когда не построчно записи в лог валятся, а страницы целиком со всем своим содержимым .
еще раз: не пустышки, а страницы целиком

P.S: то, что Князев там пишет про truncate table, извините, неверно,
это тоже полностью логируемая операция,
просто она тоже "эффективно" логируется:
Minimal Logging
RandalTRUNCATE TABLE is not a minimally-logged operation. It's logged exactly the same way in all recovery models. It's fully logged, but very efficiently logged, including using the deferred-drop mechanism.

ну и вот выхлоп из лога от последнего кода,
запущенного после бэкапа лога.
видно, что операций типа LOP_FORMAT_PAGE
в 14 раз меньше, чем LOP_INSERT_ROWS
(других операций в контексте кучи просто нет)
это потому, что на страницу влазят 14 записей вида int + varchar(255),
полностью забитыx 255 символами.

надеюсь, всем видно, что страницы ушли в лог вместо строк,
когда делался инсерт с таблоком.

msLexYasha123efficiently logged operation
А не встречался ли вам какой-нибудь список условий, при которых включается "постраничное" логирование?
По какой-то неясно для меня причине, он не совпадает с условиями минимпльного логирование?
мне не встречался,
но из соображений здравого смысла:

если идет вставка с таблоком и в кучу(пустую или нет неважно),
таблица эксклюзивно блокирована и никто другой вставить не может за все время вставки.
отсюда вывод:
данные будут вставляться страницами.
мы валим все подряд и нет никаких причин вставлять их куда-то в середину(т.е. построчно)
-> будет логироваться постранично.

если вставка в кластерный с tablock и order by таблица пуста, все ровно то же самое,
мы валим точно в конец, т.е. пишем новые целые страницы подряд.
будет логироваться постранично.

ну а вставка в непустой кластерный, хоть бы и отсортированный набор вставляем,
может оказаться вставкой вперемежку с уже имеющимся, простейший пример:
уже вставлены нечетные числа, а теперь свтавляем четные, хоть бы и упорядоченные.
все равно вставка пойдет в уже имеющиеся страницы.
вывод: постраничного логирования не будет, только построчное

т.е. на первый взгляд все те же условия, что и для минимального логирования в simple и bulk logged.
у вас есть примеры, когда не так?

думаю, еще есть ограничение на объем.
если строк мало, будет построчно в любой модели