Господа, такой вопрос.

use database

create table #table

insert into #table 1 миллион записей

update #table 1 миллион записей

В чей лог будут записываться insert и update - в лог database или в лог tempdb?

Если запись будет в лог tempdb, то как избежать его переполнения и не навредить другим процессам использующим туже самую tempdb?

Поделитесь пожалуйста опытом.

Заранее всем большое спасибо

А кто-нибудь пользовался multiple tempdb? На какие грабли здесь можно наступить?

Если tempdb общая, то имеет ли смысл делать большие update временных таблиц в циклах?
Например - создать курсор и в цикле делать update для каждой записи. Параллельно вести счётчик и после, скажем, каждых 1000 update делать check point в tempdb (по умолчанию в ней trunk log on chkp point = true).

Когда-то давно читал, что было такое пороговоре число записей после которого update в цикле работал быстрее.

MasterZiv
> Если tempdb общая, то имеет ли смысл делать большие update временных
> таблиц в циклах?
> Например - создать курсор и в цикле делать update для каждой записи.
> Параллельно вести счётчик и после, скажем, каждых 1000 update делать
> check point в tempdb (по умолчанию в ней trunk log on chkp point = true).

Не checkpoint, а транзакцию коммитить.
Да, имеет.


Если цикл выглядит примерно так:
while @@sqlstatus = 0
begin
update table set ... -- транзакция явно не открывается
fetch..
end
и set chained off (по умолчанию)

то коммитить явно ведь ничего не надо.

Хочется понять что происходит в логе.
В tempdb по умолчанию trunk log on chkp point = true - т.е. при наступлении чекпойнта все записи о законченных транзакциях должны быть удалены.
Но, до чекпойнта все изменённые данные находятся в памяти, и, я так подозреваю, что записи для лога тоже находятся в памяти. Получается, что когда наступает чек пойнт в лог зальются только записи о висящих транзакциях, т.к. нет смысла регистрировать в логе законченные транзакции и сразу их удалять.
Если так, то получается, что в моём случае вообще не надо ничего делать, т.к. эти апдейты и так в лог не попадут.


MasterZiv
> Когда-то давно читал, что было такое пороговоре число записей после
> которого update в цикле работал быстрее.

нет, тут нет "быстрее/медленнее". Один запрос всегда быстрее будет
чем цикл. Тут все дело в "возможно/невозможно". Иногда одним
запросом просто невозможно.
Posted via ActualForum NNTP Server 1.4

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

Кстати интересно как поведут себя блокировки. По идее update всей таблицы должен будет заблокировать всю таблицу до окончания своей работы.

komrad KruА кто-нибудь пользовался multiple tempdb? На какие грабли здесь можно наступить?


если система покупная, то надо внимательно обследовать обычную tempdb на предмет специально добавляемых объектов - пользовательских типов данных, таблиц и прочего.
дважды наступал на такие грабли, но с разных сторон ;)
первый: сервер приложений при старте кладет в tempdb много чего, и когда добавляешь tempdb2 она оказывается в default пуле temp-баз и обычных юзеров (клиентов) начинает закидывать туда через раз где они не находят спец. объектов и ругаются
пришлось tempdb2 выносить из default группы

второй:
апдейты на сервер приложений накатываются частично из-под sa, он попадает в tempdb2 и снова не находит объектов ;)
в общем, отказался я пока от tempdb2, хотя, несомненно, это удобно.

PS чем авторов проги не устроила model в кач-ве хранилища спец. объектов понял чуть позже - при накате фиксов на сервер приложений (+корректировки структуры основной БД) не нужно передергивать Sybase

Огромное спасибо! Очень ценный совет.

MasterZiv
Kru пишет:

> Но, до чекпойнта все изменённые данные находятся в памяти, и, я так
> подозреваю, что записи для лога тоже находятся в памяти. Получается, что

Кто тебе такое сказал ? Нет, конечно. Данные находятся кто где,
кто в кэше, кто уже на диске. А записи лога - только на диске
(конечно в памяти есть для них кэш).

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

Чего ? ничего не понял. Видимо, при неправильных посылках
и выводы соответвующие.


Про чекпойнт почитал - был неправ - "грязные" страницы могут быть как и в памяти так и на диске.
Лог ведётся отдельно и даже может быть причиной дополнительных чекпойнтов (free checkpoint). Открыл для себя что traunc log on checkpoint срабатывает только в случае системного чекпойнта. Сама команда checkpoint лог чистить не будет. Короче с чекпойнтами понятно. В данном случае их трогать вообще не надо.

В общем достаточно будет просто цикла, т.к. лог будет очищаться по системным чекпойнтам.


Вопросов больше по теме нет.

Всем большое спасибо