[закрыто, говнотема] Вы считаете нормальной ситуацию когда СУБД
Смотря что такое нормально в твоем понятии.
Если нормально == удобно, то ситуация ненормальна.
Если нормально == бывает в реальной жизни, то, к сожалению, нормальна.
Если нормально == удобно, то ситуация ненормальна.
Если нормально == бывает в реальной жизни, то, к сожалению, нормальна.
Если нормально == бывает в реальной жизни, то, к сожалению, нормальна.Это именно для db2?
Потому что в постгресе я как-то не могу понять, как такое может произойти..
Смотря что такое нормально в твоем понятии.ни то ни другое
Если нормально == удобно, то ситуация ненормальна.
Если нормально == бывает в реальной жизни, то, к сожалению, нормальна.
дело не в удобстве
в оракле дофига всего неудобного
дело в невыполнении своих обязательств, как-то так...
Потому что в постгресе я как-то не могу понять, как такое может произойти..есть еще такой пример: запрос который будет выполняться слишком долгое время
но изначально имелось ввиду что мы запускаем простейший запрос, который при ненеудачном стечении звезд работает
запрос который будет выполняться слишком долгое времяЯ так понял, у автора треда проблема не в том, что слишком долго чего-то выполняется, а в том, что его просто отпинывают?
ЗЫ: О, придумал, когда такое может быть - при превышении максимального числа коннектов
Че значит не отдает? Oracle вообще то может то же типа не отдавать
Второй запуск уже буш ждать, когда первый закончится.
Имхо нормальная ситуация для многопользовательской БД.
select * from test for update
Второй запуск уже буш ждать, когда первый закончится.
Имхо нормальная ситуация для многопользовательской БД.
нет
не так
я наверна плохо объяснил
происходит вот что:
в первом случае так:
делаю select
жду
жду
жду
отваливается операция по таймауту
во втором так:
делаю select
жду
жду
жду
отваливается операция с ошибкой в ole.dll, при том что эта ole хз что такое
при превышении коннектов мне выдается ошибка: превышено число коннектов
тоесть поведение адекватное
не так
я наверна плохо объяснил
происходит вот что:
в первом случае так:
делаю select
жду
жду
жду
отваливается операция по таймауту
во втором так:
делаю select
жду
жду
жду
отваливается операция с ошибкой в ole.dll, при том что эта ole хз что такое
при превышении коннектов мне выдается ошибка: превышено число коннектов
тоесть поведение адекватное
Второй запуск уже буш ждать, когда первый закончится.с каких это щей то?
запускаем
select * from test for update
запускаем второй запуск
select * from test
все данные нормуль выбираются!
Я и не говорил, что не будет выбираться
Я написал к тому, что по разному работают блокировки. В одной из книг прям с пафосом было написано - Oracle это ништяк система, пока одна транзакиция меняет данные другая может ее не ждать и читать старье, т.е. это не стандартное поведение БД. С for update запросы эмулируют БД с блокировкой таблицы при ее изменении.
select * from test
Я написал к тому, что по разному работают блокировки. В одной из книг прям с пафосом было написано - Oracle это ништяк система, пока одна транзакиция меняет данные другая может ее не ждать и читать старье, т.е. это не стандартное поведение БД. С for update запросы эмулируют БД с блокировкой таблицы при ее изменении.
пока одна транзакиция меняет данные другая может ее не ждать и читать старье, т.е. это не стандартное поведение БДоппа
а я как раз считаю что это стандартное поведение субд
тэкс, где взять определение стандарта СУБД?
В стандарте SQL видимо, тока этот стандарт все забивают и делают как считают нужным (в том числе и Oracle).
читаю вот это
офигеваю все больше и больше
предложили решение проблемы:
офигеваю все больше и больше
предложили решение проблемы:
попробуй select * from table with urи дальше такая приписка:
Только не забывай Commit/Rollback после select * from table with ur
Иногда with ur локирует catalog tables! Причем именно иногда!
From IBM doc - "UR isolation acquires almost no locks "
Лучше иди покури организацию блокировок в DB2 
Том Кайт не зря акцентирует свое внимание, что разрабы зачастую переносят свои привычки с одной системы на другую с печальным результатом.
P.S. Читал как то про блокировки в MS SQL - то же веселая песня
Том Кайт не зря акцентирует свое внимание, что разрабы зачастую переносят свои привычки с одной системы на другую с печальным результатом.
P.S. Читал как то про блокировки в MS SQL - то же веселая песня
В стандарте SQL видимо, тока этот стандарт все забивают и делают как считают нужным (в том числе и Oracle).там нет того что ты утверждаешь
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt
более того
там есть "намеки" на то что ты неправ
это намеки, потому что про запрет чтения там ничего нет, но есть про то что будет читаться если будет читаться
в оракле как раз читается и как раз то что по стандарту
The isolation level of a SQL-transaction is SERIALIZABLE by default.
для SERIALIZABLE P1: Not Possible
Сорри, похоже облажался 
Надо целиком поботать уровни блокировок.
Надо целиком поботать уровни блокировок.почитал еще
в вики есть определение субд
вполне корректное вроде
условие токо одно: P1: база не должна выдать испорченные данные
в оракле достигается тем что выдаются неиспорченные данные
в дб2 достигается тем что не выдаются никакие
определению субд оба не противоречат
так что возвращаемся к первоначальному вопросу: вы считаете нормальным путь дб2?
в вики есть определение субд
вполне корректное вроде
условие токо одно: P1: база не должна выдать испорченные данные
в оракле достигается тем что выдаются неиспорченные данные
в дб2 достигается тем что не выдаются никакие
определению субд оба не противоречат
так что возвращаемся к первоначальному вопросу: вы считаете нормальным путь дб2?
вы считаете нормальным путь дб2?Ну как бы это зависит от.
Например, если тебе нужно гарантированно получить данные - это плохой путь.
А если тебе нужно гарантированно в течение 0.1с ответить клиенту - это хороший путь.
Но пусть того же постгреса, в общем-то, может быть модифицирован в путь дб2 - если ждём больше 0.1с, считаем, что ответа не будет.
почитай дейта
он, сцука, причастен к дб2
он, сцука, причастен к дб2
А ты представляешь, как такое поведение (неблокирующийся select во время update) реализовано?
Я вот не знаю, но у меня есть два варианта:
1) изменённые/добавленные/удалённые версии строк накапливаются в Отдельном Месте в специально заточенном быстром формате, после выполнения запроса таблицы всё-таки блокируются и в них всё переписывается. Выгода получается только в случае каких-нибудь сложных запросов с процедурами, наверное.
2) Или Отдельное Место тесно интегрировано с самой таблицей, фактически, каждая строчка может присутствовать в двойном экземпляре, но проход по таблице хитроумно и централизованно направляется тем или иным образом, а после завершения апдейта и всех pending селектов он направляется другим образом и в бэкграунде удаляется всё лишнее. Бррр.
А необходимость этого всего довольно неочевидна. Зачем тебе долгий апдейт? Или я чего-то не понимаю?
Я вот не знаю, но у меня есть два варианта:
1) изменённые/добавленные/удалённые версии строк накапливаются в Отдельном Месте в специально заточенном быстром формате, после выполнения запроса таблицы всё-таки блокируются и в них всё переписывается. Выгода получается только в случае каких-нибудь сложных запросов с процедурами, наверное.
2) Или Отдельное Место тесно интегрировано с самой таблицей, фактически, каждая строчка может присутствовать в двойном экземпляре, но проход по таблице хитроумно и централизованно направляется тем или иным образом, а после завершения апдейта и всех pending селектов он направляется другим образом и в бэкграунде удаляется всё лишнее. Бррр.
А необходимость этого всего довольно неочевидна. Зачем тебе долгий апдейт? Или я чего-то не понимаю?
Уровни изоляции настрой. Это кстати стандартная ошибка всех ораклистов, работающих с ДБ2. А потом возникают легенды по этому поводу...
Я не работал с Oracle и DB2, только читал немного про транзакции в постгресе. Но есть большое подозрение, что это поведение настраивается.
А ты представляешь, как такое поведение (неблокирующийся select во время update) реализовано?В oracle это реализовано через сегмент отката сегмент отката.
Аффтору треда и сопереживающим: надо ботать что такое ACID, уровни изоляции транзакций и историю хори-вара "версионники vs блокировочники".
Этот бэкграуд imho нужен для эффективного работы с БД...
А необходимость этого всего довольно неочевидна. Зачем тебе долгий апдейт? Или я чего-то не понимаю?странный вопрос задал
по твоему не бывает долгих транзакций?
некторые операции по работе с базо ймогут минут 10 длиться
а некторые могут и час
и все это в одной транзакции
Аффтору треда и сопереживающим: надо ботать что такое ACID, уровни изоляции транзакций и историю хори-вара "версионники vs блокировочники".да знаю я все это худо бедно
Этот бэкграуд imho нужен для эффективного работы с БД...
похоже меня сглючило
просто я уже и сам не понимаю про что хотел поговорить
вроде написал в топикстарте что не хочу про конкретные вещи говорить, а вроде тогда не понятно о чем вообще говорить
закрывайте тему
2) Или Отдельное Место тесно интегрировано с самой таблицей, фактически, каждая строчка может присутствовать в двойном экземпляре, но проход по таблице хитроумно и централизованно направляется тем или иным образом, а после завершения апдейта и всех pending селектов он направляется другим образом и в бэкграунде удаляется всё лишнееНасколько я понимаю, в постгресе как-то так и сделано. Там ещё и версионность какая-то есть.
насколько я понимаю в процитированном втором пункте написан бред2) Или Отдельное Место тесно интегрировано с самой таблицей, фактически, каждая строчка может присутствовать в двойном экземпляре, но проход по таблице хитроумно и централизованно направляется тем или иным образом, а после завершения апдейта и всех pending селектов он направляется другим образом и в бэкграунде удаляется всё лишнееНасколько я понимаю, в постгресе как-то так и сделано. Там ещё и версионность какая-то есть.
также насколько я понимаю, в постгресе бреда не должно быть
Не, там не бред, мне просто влом чётко расписывать было.
Пусть у тебя каждая строка на самом деле представляет собой два указателя на реальные строки, из которых один может быть нуллом. И глобальный переключатель current. Тогда ты делаешь что-то вроде
DataRow Get(int index)
{
DataRow result = rows[index][current];
if (null == result) result = rows[index][!current];
return result;
}
void Set(int index, DataRow row)
{
if (null == rows[index][current])
{
rows[index][current] = rows[index][!current];
}
rows[index][!current] = row;
}
Когда закончился апдейт и все селекты, инициированные во время него, и все селекты, инициированные во время ожидания, ты смело флипаешь current и все последующие селекты чудесным образом видят уже новую версию. А ты в бэкграунде удаляешь ненужные строки, подготавливая таблицу для следующего апдейта (перекидывать ссылки в нетронутых строчках не нужно, это Set делает сам по мере необходимости).
Плюс обработка отдельно особых случаев для удаления/добавления строк (но это уровнем выше может быть, на самом деле плюс индексы скорее всего придётся таки хранить в двух экземплярах.
Дисклеймер: я это всё только что придумал из головы.
Пусть у тебя каждая строка на самом деле представляет собой два указателя на реальные строки, из которых один может быть нуллом. И глобальный переключатель current. Тогда ты делаешь что-то вроде
DataRow Get(int index)
{
DataRow result = rows[index][current];
if (null == result) result = rows[index][!current];
return result;
}
void Set(int index, DataRow row)
{
if (null == rows[index][current])
{
rows[index][current] = rows[index][!current];
}
rows[index][!current] = row;
}
Когда закончился апдейт и все селекты, инициированные во время него, и все селекты, инициированные во время ожидания, ты смело флипаешь current и все последующие селекты чудесным образом видят уже новую версию. А ты в бэкграунде удаляешь ненужные строки, подготавливая таблицу для следующего апдейта (перекидывать ссылки в нетронутых строчках не нужно, это Set делает сам по мере необходимости).
Плюс обработка отдельно особых случаев для удаления/добавления строк (но это уровнем выше может быть, на самом деле плюс индексы скорее всего придётся таки хранить в двух экземплярах.
Дисклеймер: я это всё только что придумал из головы.
А если две транзакции будут менять данные, а третья захочет данные прочитать? )
Потом к примеру первая транзакция откатывается, а вторая фиксируется.
Так копий строк на все транзакции не напасёшься.
Потом к примеру первая транзакция откатывается, а вторая фиксируется.
Так копий строк на все транзакции не напасёшься.
Не, там не бред, мне просто влом чётко расписывать было.и?
щас ты четко расписал бред
транзакций одновременных по твоему только две может быть?
А если две транзакции будут менять данные, а третья захочет данные прочитать?А две транзакции не могут одновременно менять данные.
Если транзакция хочет считать for update/поменять данные, которые уже изменены в другой транзакции - ей придётся подождать коммита/роллбэка.
Да, говно-пример. 
Кучу копий можно наплодить так:
1) Открыть транзакцию читающую данные.
2) Изменить в новой транзакции данные и зафиксировать.
3) Открыть транзакцию читающую данные.
4) Изменить в новой транзакции данные и зафиксировать.
и т.д.
PS Только уровень изоляции транзакций надо поставить SERIALIZABLE.
Кучу копий можно наплодить так:
1) Открыть транзакцию читающую данные.
2) Изменить в новой транзакции данные и зафиксировать.
3) Открыть транзакцию читающую данные.
4) Изменить в новой транзакции данные и зафиксировать.
и т.д.
PS Только уровень изоляции транзакций надо поставить SERIALIZABLE.
Попробуй грязное чтение (тег nolock)
Попробуй грязное чтение (тег nolock)эххх
что за люди
покажи мне где я спрашивал как мне это сделать?
зачем отвечать на вопрос который не задавали?
чтобы выпендриться?
Оставить комментарий
pitrik2
не отдает данные?я ораклист
ни разу не встречал чтобы субд мне не отдавала данные
может у меня опыт маленький просто ...
а щас речь про db2
второй раз уже встречаю такую фигню
первый раз оказалось что ктото незакоммитил данные
сработала блокировка
не вдаваясь в подробности что такое блокировка, как устроена и нафик нужна, вопрос такой:
это нормально что в другом коннекшене нельзя выбрать данные? ладно там изменить, но выбрать?
второй раз только что был
на этот раз не выбирались данные из вьюшки
думала минуту и выдавала какую-то ошибку про ole.dll
оказалось что вьюшка вызывала функции, которые лежали в дополнительной dll и вот эта dll отвалилась
по новой ее зарегистрировали и заработало
правда пришлось еще и индексы пересоздать, они тоже отвалились
хз, почему отвалилась dll, кто в этом виновен, но разве это нормально что субд не сказала в чем трабла?
хотя с какой стати она отвалилась тож интересно, у базы токо один админ, остальные с тонких клиентов лазят и до этого никаких падений не было