C>Если это простой SELECT в случае Oracle блокировки не будет, т.к. запись не блокирует чтение и наоборот. С другими БД SELECT будет блокирован до тех пор, пока не освободятся нужные данные.
Ну, ну.. не Ораклом единым
Есть и другие БД, не блокирующие читателей.
Привет, chabster!
Вы пишешь 13 октября 2005:
>> И еще, кто знает как работает DB2 с этим? >> (Читать доку лениво, так как просто спортивный интерес)
c> SQLServer отпачковался от DB2 так и работает.
Во-первЫх, неверно.
Во-втОрых, что есть "отпАчковался" ?
Здравствуйте, <Аноним>, Вы писали:
А>Вот вот, можно на этом поподробнее, какие еще (из известных публике).
Interbase, Postgree...
А>И еще, кто знает как работает DB2 с этим?
DB2 классический блокировочник, как и MSSQL 2000. Поведение, соответственно, полностью аналогичное — никаких предыдущих версий для него не существует.
А>И вообще, как можно блокировать чтение, это же маразм.
Маразм — это подозревать в маразме других, самому в вопросе не разобравшись.
> Маразм — это подозревать в маразме других, самому в вопросе не разобравшись.
Вы явно его подозреваете
Posted via RSDN NNTP Server 1.9
Блокировка записей в SQL
От:
Аноним
Дата:
12.10.05 07:29
Оценка:
при установках по дефолту
юзер запускает SELECT на выборку данных
Если Select дошел до толко 3 записи
а в это время другой юзер в транзакции отредактировал 5 запись и не закоммитил
что будет ??
Мое мнение что если выборка была запущена до начала транзакции то она вернет первичные данные не остановившись отвергли как неправельное мнение.
мне сказали что для селекта будет блокировка, но ни как не обосновали это
Здравствуйте, Аноним, Вы писали:
А>при установках по дефолту
А>юзер запускает SELECT на выборку данных
А>Если Select дошел до толко 3 записи А>а в это время другой юзер в транзакции отредактировал 5 запись и не закоммитил А>что будет ?? А>Мое мнение что если выборка была запущена до начала транзакции то она вернет первичные данные не остановившись отвергли как неправельное мнение.
А>мне сказали что для селекта будет блокировка, но ни как не обосновали это
А>Мое мнение что если выборка была запущена до начала транзакции то она вернет первичные данные не остановившись отвергли как неправельное мнение. А>мне сказали что для селекта будет блокировка, но ни как не обосновали это
Зависит от сервера БД и реализации механизма Concurrency Control в оном. Может быть как блокировка, так и чтение предыдущего значения.
> мне сказали что для селекта будет блокировка, но ни как не обосновали это
Если это SELECT ... FOR UPDATE брокировка будет в любом случае.
Если это Oracle можно указать опцию NOWAIT и SELECT просто вернет ошибку.
Если это простой SELECT в случае Oracle блокировки не будет, т.к. запись не блокирует чтение и наоборот. С другими БД SELECT будет блокирован до тех пор, пока не освободятся нужные данные.
Здравствуйте, Merle, Вы писали:
А>>Мое мнение что если выборка была запущена до начала транзакции то она вернет первичные данные не остановившись отвергли как неправельное мнение. А>>мне сказали что для селекта будет блокировка, но ни как не обосновали это M>Зависит от сервера БД и реализации механизма Concurrency Control в оном. Может быть как блокировка, так и чтение предыдущего значения.
Сервер MSSQL 2000, если можно подробней. В каких сетуациях это может возникнуть.
Пытался смоделировать данную ситуацию но получил то что и утверждал.
Здравствуйте, AvPyrozhenko, Вы писали:
AP>Сервер MSSQL 2000, если можно подробней. В каких сетуациях это может возникнуть.
Во всех. В MSSQL 2000, предыдущую версию записи select не прочтет никогда, будет либо блокировка, либо чтение "грязных" данных незафиксированной транзакции, в зависимости от уровня изоляции.
AP>Пытался смоделировать данную ситуацию но получил то что и утверждал.
Значит что-то не так с моделированием.
T1:
--- Тестовая таблица
---drop table tst0
create table tst0(i int identity(1,1) PRIMARY KEY, a varchar(50))
insert into tst0 (a)
select top 10 newID() from sysobjects
--- запрос который будет блокировать наш селект до тех пор, пока мы не запустим другую транзакцию,
которая поменяет нашу "запись номер 5"
begin tran
update tst0 set a = 'Fake GUID' where i=3
T2:
--- собственно SELECT
---select * from tst0
Здесь он повиснет на предыдущей транзакции, пока висит, успеем поменять "запись номер 5" в еще одной транзакции, не фиксируя ее...
T3:
begin tran
update tst0 set a = 'Really Fake GUID' where i=5
Открываем еще одно окошко и смотрим блокировки:
SELECT
convert (smallint, req_spid) As spid,
rsc_dbid As dbid,
rsc_objid As ObjId,
so.name as ObjName,
rsc_indid As IndId,
substring (v.name, 1, 4) As Type,
substring (rsc_text, 1, 16) as Resource,
substring (u.name, 1, 8) As Mode,
substring (x.name, 1, 5) As Status
FROM master.dbo.syslockinfo sl
INNER JOIN master.dbo.spt_values v ON sl.rsc_type = v.number
INNER JOIN master.dbo.spt_values x ON sl.req_status = x.number
INNER JOIN master.dbo.spt_values u ON sl.req_mode + 1 = u.number
LEFT JOIN sysobjects so ON sl.rsc_objid = so.ID
WHERE v.type = 'LR' and x.type = 'LS' and u.type = 'L' and so.Name = 'tst0'
ORDER BY spid
Картина примерно следующая, с точностью до констант, ненужные подробности опущены:
SPID TableName Lock Type Status
52 tst0 KEY (03000d8f0ecc) X GRANT <-- Блокировка от первого апдейта
53 tst0 KEY (03000d8f0ecc) S WAIT <-- на ней висит select и ждет, обрати внимание на ID ключа в скобочках
54 tst0 KEY (0500d1d065e9) X GRANT <-- Блокировка второго апдейта
Теперь снимаем блокировку, чтобы select выполнялся дальше:
T1:
rollback
С удивлением обнаруживаем, что select по прежнему висит, опять смотрим блокировки:
SPID TableName Lock Type Status
53 tst0 KEY (0500d1d065e9) S WAIT <-- Теперь select висит на другой блокировке
54 tst0 KEY (0500d1d065e9) X GRANT <-- Блокировка второго апдейта
Теперь фиксируем изменения "записи номер 5" и видим, что селект наконец-то выполнился и прочитал все изменения.
Здравствуйте, Merle, Вы писали:
AP>>Сервер MSSQL 2000, если можно подробней. В каких сетуациях это может возникнуть. M>Во всех. В MSSQL 2000, предыдущую версию записи select не прочтет никогда, будет либо блокировка, либо чтение "грязных" данных незафиксированной транзакции, в зависимости от уровня изоляции.
AP>>Пытался смоделировать данную ситуацию но получил то что и утверждал. M>Значит что-то не так с моделированием.
Вы не совсем правельно поняли:
Выборка запущена до начала транзакции а не после неё как вы описали в примере.
При моделировании у меня вышло
что селект при установках по умолчанию возвращаются первичные данные.
если же запускать select в транзакции с uncomited то возвращаются уже измененные даные.
но влюбом случае select запущенный до начала транзакции не останавливается
Здравствуйте, AvPyrozhenko, Вы писали:
AP>Вы не совсем правельно поняли: AP>Выборка запущена до начала транзакции а не после неё как вы описали в примере.
Там есть две транзакции, одна запущена до начала выборки, другая после. И обе вызывают блокировку выборки.
AP>При моделировании у меня вышло AP>что селект при установках по умолчанию возвращаются первичные данные.
Такого не может быть (за исключением ситуации описанной ниже), если нет ошибок в коде SQL Server-а отвечающего за параллельную обработку данных, во что я признаться не верю.
AP>но влюбом случае select запущенный до начала транзакции не останавливается
Это может быть только в том случае если селект уже выбрал данные, которые меняет транзакция запущенная после селекта.
Выборка не обращается ко всем данным одновременно, а последовательно перебирает все необходимые записи, и если пишущая транзакция поменяет данные, которые селект уже просмотрел, то естественно будет иллюзия, что селект прочитал предыдущую версию. Но если пишущая транзакция поменяет данные, до которых селект еще не добрался, то будет блокировка.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, AvPyrozhenko, Вы писали:
AP>>Вы не совсем правельно поняли: AP>>Выборка запущена до начала транзакции а не после неё как вы описали в примере. M>Там есть две транзакции, одна запущена до начала выборки, другая после. И обе вызывают блокировку выборки.
это я заметил, почему и написал что возможно вы не поняли ситуацию.
AP>>При моделировании у меня вышло AP>>что селект при установках по умолчанию возвращаются первичные данные. M>Такого не может быть (за исключением ситуации описанной ниже), если нет ошибок в коде SQL Server-а отвечающего за параллельную обработку данных, во что я признаться не верю.
не ошибается только тот кто ничего не делает
AP>>но влюбом случае select запущенный до начала транзакции не останавливается M>Это может быть только в том случае если селект уже выбрал данные, которые меняет транзакция запущенная после селекта. M>Выборка не обращается ко всем данным одновременно, а последовательно перебирает все необходимые записи, и если пишущая транзакция поменяет данные, которые селект уже просмотрел, то естественно будет иллюзия, что селект прочитал предыдущую версию. Но если пишущая транзакция поменяет данные, до которых селект еще не добрался, то будет блокировка.
как можно объяснить следуещее (моделирование проводил на 100к записей, менял последнию)
select при установках по умолчанию возвращает первичные данные.
select в транзакции с uncomited возвращает уже измененные даные.
AP>>>При моделировании у меня вышло AP>>>что селект при установках по умолчанию возвращаются первичные данные. M>>Такого не может быть (за исключением ситуации описанной ниже), если нет ошибок в коде SQL Server-а отвечающего за параллельную обработку данных, во что я признаться не верю.
AP>не ошибается только тот кто ничего не делает
Вобще конечно эта фраза здесь как: "не пришей к п...е рукав". Что конкретно ты хотел сказать? Вобще-то совсем непонятно.
Здравствуйте, AvPyrozhenko, Вы писали:
M>>Там есть две транзакции, одна запущена до начала выборки, другая после. И обе вызывают блокировку выборки. AP>это я заметил, почему и написал что возможно вы не поняли ситуацию.
Пример иллюстрирует именно описанную ситуацию. Первая транзакция, запущенная до выборки тормозит выборку, чтобы была возможность второй транзакции запуститься после выборки.
Более того. На самом деле совершенно не важно, началась ли меняющая транзакция до выборки или после, важно лишь успела ли она зафиксироваться к тому моменту, как выборка подошла к измененной записи. Я просто не стал заострять на этом внимание, чтобы не вдаваться в излишние подробности.
AP>не ошибается только тот кто ничего не делает
Больше пяти лет безупречной работы этого кода подсказывают мне то, что вероятность ошибки в нем крайне низка.
AP>как можно объяснить следуещее (моделирование проводил на 100к записей, менял последнию)
Как именно ты определил, что менял последнюю? Сервер не гарантирует порядок обхода записей.
AP>select при установках по умолчанию возвращает первичные данные. AP>select в транзакции с uncomited возвращает уже измененные даные.
В первом случае транзакция стартовала после прохождения select-а по нужной записи во втором до, других вариантов быть не может.
Я уже приводил пример где показано как все работает, 100 тыс. записей не надо (тем более что их тоже можно выбрать достаточно шустро), достаточно притормозить селект, чтобы успеть запустить вторую транзакцию и все сразу станет видно.
У MSSQL2000 просто не существует соответствующих механизмов по извлечению предыдущего значения, либо блокировка (и чтение результата после фиксации или отката меняющей транзакции), либо грязные данные — другого не дано.
Мы уже победили, просто это еще не так заметно...
Re[3]: Блокировка записей в SQL
От:
Аноним
Дата:
13.10.05 13:29
Оценка:
Здравствуйте, Igor Trofimov, Вы писали:
C>>Если это простой SELECT в случае Oracle блокировки не будет, т.к. запись не блокирует чтение и наоборот. С другими БД SELECT будет блокирован до тех пор, пока не освободятся нужные данные.
iT>Ну, ну.. не Ораклом единым iT>Есть и другие БД, не блокирующие читателей.
Вот вот, можно на этом поподробнее, какие еще (из известных публике). И еще, кто знает как работает DB2 с этим? (Читать доку лениво, так как просто спортивный интерес), но была одна история: select * from t в первой сессии, был заблокирован update t set f=3 во второй. Но все бы ничего, но "убив" символом креста вторую сессию, первая так и не ожила, и висела еще 2 часа. Убил и ее, ушел на выходные и в понедельник утром обнаружил в базе 2 активные сессии (да да, те самые) блокирующие таблицу все выходные, в итоге убил уже правильно, средствами БД вторую сессию с этим злосчастным апдейтом. Вопрос в том — либо я криворукий базу неправильно настроил (в визардах плохо Next нажимал), либо такой подход к блокированию принят и в DB2.
И вообще, как можно блокировать чтение, это же маразм.
AP>как можно объяснить следуещее (моделирование проводил на 100к записей, менял последнию) AP>select при установках по умолчанию возвращает первичные данные. AP>select в транзакции с uncomited возвращает уже измененные даные.
Контр-пример. 500к записей,
T1
select * from dbo.fiztax2004 where Comments like '%5%' -- это скан таблицы
T2
begin tran
update dbo.fiztax2004 set Comments = Comments + '___' where ID = 12000000721937
В зависимости от момента запуска 2-й транзакции 1-я блокируется или нет. Соответственно, и с уровнем изоляции read uncommitted результаты будут такие-же, только вместо блокировки будут возвращены либо новые, либо старые данные. Собственно, суть-то проста: SQL2к не хранит версии данных, есть только текущая копия и transaction log со старыми данными для определенной транзакции. Соответственно, если я запускаю T1, затем бегу запускаю T2, она обновляет некую запись (и ставит соответствующую блокировку), и после этого T1 подходит к ее анализу (ну, надо как минимум выяснить, like-то соответствует). При этом выполнение T1 приостанавливается (ну, не понятно, как быть, читать неподтвержденные данные невелено) и ждет окончания T2. После этого продолжает свою работу.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, <Аноним>, Вы писали:
А>>Вот вот, можно на этом поподробнее, какие еще (из известных публике). M>Interbase, Postgree...
Спасибо, буду знать.
А>>И еще, кто знает как работает DB2 с этим? M>DB2 классический блокировочник, как и MSSQL 2000. Поведение, соответственно, полностью аналогичное — никаких предыдущих версий для него не существует.
Печально...
А>>И вообще, как можно блокировать чтение, это же маразм. M>Маразм — это подозревать в маразме других, самому в вопросе не разобравшись.
Здравствуйте, Mikst, Вы писали:
M>Здравствуйте, Merle, Вы писали:
M>>Здравствуйте, <Аноним>, Вы писали:
А>>>Вот вот, можно на этом поподробнее, какие еще (из известных публике). M>>Interbase, Postgree...
M>Спасибо, буду знать.
А>>>И еще, кто знает как работает DB2 с этим? M>>DB2 классический блокировочник, как и MSSQL 2000. Поведение, соответственно, полностью аналогичное — никаких предыдущих версий для него не существует.
M>Печально...
Что печально?
А>>>И вообще, как можно блокировать чтение, это же маразм. M>>Маразм — это подозревать в маразме других, самому в вопросе не разобравшись.
M>Ну и что же хорошего в блокировках чтений?
Иди доки почитай "в вопросе разберись" как правильно заметили — тебя это, как видно, также касается
Здравствуйте, _d_m_, Вы писали:
___>Здравствуйте, Mikst, Вы писали:
M>>Здравствуйте, Merle, Вы писали:
M>>>Здравствуйте, <Аноним>, Вы писали:
А>>>>Вот вот, можно на этом поподробнее, какие еще (из известных публике). M>>>Interbase, Postgree...
M>>Спасибо, буду знать.
А>>>>И еще, кто знает как работает DB2 с этим? M>>>DB2 классический блокировочник, как и MSSQL 2000. Поведение, соответственно, полностью аналогичное — никаких предыдущих версий для него не существует.
M>>Печально...
___>Что печально?
А>>>>И вообще, как можно блокировать чтение, это же маразм. M>>>Маразм — это подозревать в маразме других, самому в вопросе не разобравшись.
M>>Ну и что же хорошего в блокировках чтений?
___>Иди доки почитай "в вопросе разберись" как правильно заметили — тебя это, как видно, также касается
Чего же все посылают то...
Ладно, объясню по другому. Много лет занимался ораклом, и ничем больше. Сейчас по долгу службы пришлось столкнуться с mssql и db2. Все бы ничего, но! Есть реально работающия прога (MS), товары в ней всякие, выбирать можно , короче магазин. И вторая — которая импортирует в базу данные, раз в неделю, но сразу по 20 млн. записей. Когда раньше записей было 2 млн, все было ок. Но теперь при импорте (читай вставка в таблицу кучи строк) вся система "думает" несколько минут, и нельзя ни посмотреть, ни выбрать — НИЧЕГО. Вопрос к знатокам: как от этого избавится? Вопрос к спорщикам: почему на оракле я таких проблем не знал, и зачем они мне в "блокировочниках" ? Или в этом есть свои "невидимые" плюсы? Надеюсь на адекватный исчерпывающий ответ
Чтение док — врятли там про это пишут, а то что оно так работает, я и сам знаю, но вот до сих пор не знаю "для чего это нужно", тут бы статью какую заумную .
Здравствуйте, Mikst, Вы писали:
M> Много лет занимался ораклом, и ничем больше.
Оно и видно..
M> Сейчас по долгу службы пришлось столкнуться с mssql и db2.
Очень помогает для расширения сознания..
M> Вопрос к знатокам: как от этого избавится?
Вариантов много, например, импортировать мелкими партиями по 2 милллиона.
M>Вопрос к спорщикам:
Спорщиков здесь нет.
M>почему на оракле я таких проблем не знал, и зачем они мне в "блокировочниках" ? M> Или в этом есть свои "невидимые" плюсы?
Потому что есть достаточно широкий класс задач, в которых надо, чтобы читатели не могли ничего прочитать, пока данные мняются. И если упрощать и обобщать, то чем ближе задача к чистому OLTP, тем выгоднее использовать блокировочники.
M>Чтение док — врятли там про это пишут, а то что оно так работает, я и сам знаю, но вот до сих пор не знаю "для чего это нужно", тут бы статью какую заумную .
Ни вапрос: Concurrency Control and Recovery in Database Systems, by Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Mikst, Вы писали:
M>> Много лет занимался ораклом, и ничем больше. M>Оно и видно..
M>> Сейчас по долгу службы пришлось столкнуться с mssql и db2. M>Очень помогает для расширения сознания..
Не спорю, самому интересно
M>>почему на оракле я таких проблем не знал, и зачем они мне в "блокировочниках" ? M>> Или в этом есть свои "невидимые" плюсы? M>Потому что есть достаточно широкий класс задач, в которых надо, чтобы читатели не могли ничего прочитать, пока данные мняются. И если упрощать и обобщать, то чем ближе задача к чистому OLTP, тем выгоднее использовать блокировочники.
Ок, не спорю что такое есть, но на практике ни разу не сталкивался, и тем не менее, часто слышу "MSSQL рулез" и в то же время "Как побороть блокировку (а то и deadlock)". Все это приводит к мысли о том, что большинство прикладных задач, которые пишутся именно далеки от чистого OLTP.
И даже когда такое было действительно надо прекрасно работает select for update.
M>>Чтение док — врятли там про это пишут, а то что оно так работает, я и сам знаю, но вот до сих пор не знаю "для чего это нужно", тут бы статью какую заумную . M>Ни вапрос: Concurrency Control and Recovery in Database Systems, by Philip A. Bernstein, Vassos Hadzilacos, Nathan Goodman
Судя по всему на англицком , да еще и 22 многобайта. Ладно, поглядим.
ок, все что выше флейм чистой воды, по существу кто что посоветует?
M>> Вопрос к знатокам: как от этого избавится? M>Вариантов много, например, импортировать мелкими партиями по 2 милллиона.
Скажем так: это не вариант, все должно быть в одной транзакции.
Пожелание 2 — не трогать исходный код импортировщика, хотя как я думаю, именно его и следует переделывать.
Здравствуйте, Mikst, Вы писали:
M>Ок, не спорю что такое есть, но на практике ни разу не сталкивался,
Может быть просто не замечал?..
M> и тем не менее, часто слышу "MSSQL рулез"
Ну и правда рулез.
M> и в то же время "Как побороть блокировку (а то и deadlock)". Все это приводит к мысли о том, что большинство прикладных задач, которые пишутся именно далеки от чистого OLTP.
Да мало ли аналогичных вопросов про Оракл? Там свои тараканы.
M>И даже когда такое было действительно надо прекрасно работает select for update.
for update помимо того, что этот хинт надо указать явно, блокирует такие же for update, что снижает удобство его применения.
M>Скажем так: это не вариант, все должно быть в одной транзакции.
Ну вот здесь можно поразбираться, а почему все в одной транзакции, кто там что такого страшного меняет...
Если действительно в одной транзакции, то это хуже, тут уже надо что-то с временными хранилищами придумывать. А проще подождать пару месяцев и купить SQL 2005, там и Database Mirroring с возможностью переключения версий баз на лету и полноценная поддержка версионного режима.
Такие длинные транзакции действительно слабое место блокировочников и обычно подобные вещи решаются перепроектированием под более короткие транзакции, что естественно требует усилий.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Mikst, Вы писали:
M>>Ок, не спорю что такое есть, но на практике ни разу не сталкивался, M>Может быть просто не замечал?..
даже если не замечал, то вреда от этого тоже не замечал
M>> и тем не менее, часто слышу "MSSQL рулез" M>Ну и правда рулез.
"можно я его стукну и он станет фиолетовым.."
M>> и в то же время "Как побороть блокировку (а то и deadlock)". Все это приводит к мысли о том, что большинство прикладных задач, которые пишутся именно далеки от чистого OLTP. M>Да мало ли аналогичных вопросов про Оракл? Там свои тараканы.
да дело то не в конкретной субд, а в том, что при решинии большинства задач блокировочники сильно усложняют жизнь программистам, а те и рады
M>>И даже когда такое было действительно надо прекрасно работает select for update. M>for update помимо того, что этот хинт надо указать явно, блокирует такие же for update, что снижает удобство его применения.
конечно блокирует, так его и пишут, когда хотят прочитать заведомо незаблокированные занные. ну а то что "указывать явно" — лучше один раз (два/три) указать for update, чем сто (двести/триста) раз думать как это обойти.
M>>Скажем так: это не вариант, все должно быть в одной транзакции. M>Ну вот здесь можно поразбираться, а почему все в одной транзакции, кто там что такого страшного меняет... M>Если действительно в одной транзакции, то это хуже, тут уже надо что-то с временными хранилищами придумывать. А проще подождать пару месяцев и купить SQL 2005, там и Database Mirroring с возможностью переключения версий баз на лету и полноценная поддержка версионного режима. M>Такие длинные транзакции действительно слабое место блокировочников и обычно подобные вещи решаются перепроектированием под более короткие транзакции, что естественно требует усилий.
О чем я и говорю из за этого бывает
Перепроектирование под короткие транзакции — никак нельзя, тогда в промежутках, будут недостоверные данные. Например состояние по складу 10 штук вместо 100, т.к. еще не все импортировалось.
Такой вариант — не быстрее будет все вливать во временную таблицу, а потом одним запросом, переливать из нее в рабочую, так можно сократить время блокировки.
Здравствуйте, Mikst, Вы писали:
M>даже если не замечал, то вреда от этого тоже не замечал
Значит повезло..
M>да дело то не в конкретной субд, а в том, что при решинии большинства задач блокировочники сильно усложняют жизнь программистам, а те и рады
Да не усложняют они... Я вот и с тем и с тем повозился и с уверенностью могу сказать, что хрен редьки не слаще.
M>конечно блокирует,
А надо бы чтобы не блокировал.
M> так его и пишут, когда хотят прочитать заведомо незаблокированные занные.
Никогда нельзя с уверенностью сказать будут данные заблокированы или нет.
M> ну а то что "указывать явно" — лучше один раз (два/три) указать for update, чем сто (двести/триста) раз думать как это обойти.
Не надо думать как это обойти, оно, как правило, и так все работает.
А в идеале надо иметь возможность использовать тот или иной сценарий в зависимости от задачи, именно по этому мне крайне симпатична идея гибридных систем.
M>Перепроектирование под короткие транзакции — никак нельзя, тогда в промежутках, будут недостоверные данные. Например состояние по складу 10 штук вместо 100, т.к. еще не все импортировалось.
А агрегаты на что? Пока мы заливаем данные в основные таблицы End User работает с агрегатами посчитанными по старым значениям, потом одной, достаточно короткой транзакцией обновляются все агрегаты и все гладкои шелковисто... и очень шустро.
При этом транзакция которая обновляет основные данные может быть достаточно длинной, в разумных пределах.
M>Такой вариант — не быстрее будет все вливать во временную таблицу, а потом одним запросом, переливать из нее в рабочую, так можно сократить время блокировки.
А откуда вы получаете данные и каким способом заливаете в базу?
Здравствуйте, Merle, Вы писали:
M>Не надо думать как это обойти, оно, как правило, и так все работает. M>А в идеале надо иметь возможность использовать тот или иной сценарий в зависимости от задачи, именно по этому мне крайне симпатична идея гибридных систем.
Можеть быть, может быть...
M>>Перепроектирование под короткие транзакции — никак нельзя, тогда в промежутках, будут недостоверные данные. Например состояние по складу 10 штук вместо 100, т.к. еще не все импортировалось. M>А агрегаты на что? Пока мы заливаем данные в основные таблицы End User работает с агрегатами посчитанными по старым значениям, потом одной, достаточно короткой транзакцией обновляются все агрегаты и все гладкои шелковисто... и очень шустро. M>При этом транзакция которая обновляет основные данные может быть достаточно длинной, в разумных пределах.
Агрегаты не помогут, людям хочется не только суммы и количества видеть, но и сами данные, а когда все стоит — некоторые начинают сильно психовать
M>>Такой вариант — не быстрее будет все вливать во временную таблицу, а потом одним запросом, переливать из нее в рабочую, так можно сократить время блокировки. M>А откуда вы получаете данные и каким способом заливаете в базу?
Данные присылаются в виде дампа для оракла, мы их раздампиваем, ну а прога импортер читает из оракла, преобрахует как надо и делает инсерт в мсскл. Т.е. каждая строка отдельным оператором.
Здравствуйте, Mikst, Вы писали:
M>Агрегаты не помогут, людям хочется не только суммы и количества видеть, но и сами данные, а когда все стоит — некоторые начинают сильно психовать
А сами данные не разъедутся, если их по частям заливать?
M>Данные присылаются в виде дампа для оракла, мы их раздампиваем, ну а прога импортер читает из оракла, преобрахует как надо и делает инсерт в мсскл. Т.е. каждая строка отдельным оператором.
Оох, и все в одной транзакции? Есть такая штука, Bulk Insert, легко может повысить производительность вставки больших объемов данных порядка на два.
Здравствуйте, Merle, Вы писали:
M>Здравствуйте, Mikst, Вы писали:
M>>Агрегаты не помогут, людям хочется не только суммы и количества видеть, но и сами данные, а когда все стоит — некоторые начинают сильно психовать M>А сами данные не разъедутся, если их по частям заливать?
В том то и дело, что если что-то произойдет (коннект оборвется например) и половина данный будет закоммичена, то это будет совершенно не гуд Причем для админов системы можно сказать смертельно
M>>Данные присылаются в виде дампа для оракла, мы их раздампиваем, ну а прога импортер читает из оракла, преобрахует как надо и делает инсерт в мсскл. Т.е. каждая строка отдельным оператором. M>Оох, и все в одной транзакции? Есть такая штука, Bulk Insert, легко может повысить производительность вставки больших объемов данных порядка на два.
пытался поискать, но или не там искал или что. Пишут про DTS и Bulk Insert Task но это не совсем то что нужно, даже скорее совсем не то. Пожалуй придется забить на все, сделать через временную таблицу. Как выясняется программистам совершенно не до этой проблемы.
Здравствуйте, Mikst, Вы писали:
M>В том то и дело, что если что-то произойдет (коннект оборвется например) и половина данный будет закоммичена, то это будет совершенно не гуд Причем для админов системы можно сказать смертельно
Ну он же не на всегда оборвется, и если опасаетесь обрыва, то можно придумать более хитрую схему, заливая все во временные таблицы, а потом кусками перенося в основные данные.
M>пытался поискать, но или не там искал или что. Пишут про DTS и Bulk Insert Task но это не совсем то что нужно, даже скорее совсем не то. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_ba-bz_4fec.asp
M>Пожалуй придется забить на все, сделать через временную таблицу. Как выясняется программистам совершенно не до этой проблемы.
Ну если вы до этого позаписям работали, то даже временные таблицы могут сильно помочь.
Мы уже победили, просто это еще не так заметно...
.
пойду застрелюсь.
