Здравствуйте, 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>Пожалуй придется забить на все, сделать через временную таблицу. Как выясняется программистам совершенно не до этой проблемы.
Ну если вы до этого позаписям работали, то даже временные таблицы могут сильно помочь.