Здравствуйте, Mikst, Вы писали:

M>Ну как это?? если во время селекта, некто умудрится успеть изменить и закоммиттить стори которые он еще не прочитал — что тогда увидит пользователь?? Фигню он увидит.
Он увидит фигню только в том случае если строки в таблице зависят друг от друга, а если нет, то эта фигня никого не волнует.

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

M>А апдейт не будет блокировать при изменении amount кроме таблицы и этот самый индекс?
Он будет блокировать в первую очередь индекс.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Ну как это?? если во время селекта, некто умудрится успеть изменить и закоммиттить стори которые он еще не прочитал — что тогда увидит пользователь?? Фигню он увидит.
M>Он увидит фигню только в том случае если строки в таблице зависят друг от друга, а если нет, то эта фигня никого не волнует.

Подкололи Уважаю.. но тем не менее результат — фигня.

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

что я и делаю собственно.

M>>А апдейт не будет блокировать при изменении amount кроме таблицы и этот самый индекс?
M>Он будет блокировать в первую очередь индекс.

а если кроме amount изменяется остальные поля?? все равно блокировка чтения?

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, GlebZ, Вы писали:

GZ>> Стандарт SQL92 (обсуждаемый в статье) писали, прежде всего, ораклоиды.
M>Его писали все подряд, начиная IBM-ерами и заканчивая MS.
Нее. У MS в 92 году своей базы не было. Даже FoxPro они купили позже. Об SQL Server был еще полностью семантековский
Что касается Кайта, то хоть убей не найду где я это читал. На вопрос насколько Oracle поддерживает SQL92 он очень оригинально ответил. Смысл был такой, ребяты, вы что. Мы сами стандарт и писали. И принимали непосредственное участие в этом. Ну и далее стандартно объяснял об уровнях в SQL92 и как поддерживается. Но вот откуда я читал это, не найду.

GZ>>Неплохо было-бы прочитать кто написал эту статью, и где они работают. Когда они начали гнать почему в стандарт не внесли блокировки, я плакал от умиления.
M>Статью написаль довольно известные и уважаемые в мире БД люди. Часть из них работает в MS...
Да, я заметил.
M>И стандарт версии 92го года действительно довольно бестолково написан в разделе уровней изоляции с сильным креном в сторону блокировочников, за что подвергался неоднократной критике.
M>Собственно упомянутая статья является выжимкой всей этой критики и считается классическим обзором уровней изоляции...
M>Только одно но... ее нельзя читать на русском в этом переводе, часть смысла утеряна и, что существенно хуже, искажена.
M>Вот оригинал: A Critique of ANSI SQL Isolation Levels
Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.

С уважением, Gleb.

GZ> Неплохо было-бы прочитать кто написал эту статью, и где они работают. Когда они начали гнать почему в стандарт не внесли блокировки, я плакал от умиления.

GZ>Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.

я балдею

Здравствуйте, Mikst, Вы писали:

M>Подкололи Уважаю.. но тем не менее результат — фигня.
Я не подколол. Если строки в наборе не зависят друг от друга то совершенно не важно, что в выборку попали строки из разных версий. Вы же только что доказывали, что умеете так ловко проектировать, что строки у Вас совершенно независимы.

M>а если кроме amount изменяется остальные поля?? все равно блокировка чтения?
Тогда заблокируюется запись и другие индексы, если они есть...

Здравствуйте, GlebZ, Вы писали:

GZ>Что касается Кайта, то хоть убей не найду где я это читал. На вопрос насколько Oracle поддерживает SQL92 он очень оригинально ответил. Смысл был такой, ребяты, вы что. Мы сами стандарт и писали. И принимали непосредственное участие в этом. Ну и далее стандартно объяснял об уровнях в SQL92 и как поддерживается. Но вот откуда я читал это, не найду.
Кайт действительно входил в комитет по стандарту, но вот работал ли он в то время в Оракл — не уверен. У этого дядьки похоже вообще большой комплекс, по поводу того, что Оракл написали без него...

GZ>Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.
В том-то и прелесть, что это не история, это то с чем мы сталкиваемся регулярно. С той давней поры в подходах к разруливанию consistency problem мало что изменилось — ну придумали несколько незначительных оптимизаций, не больше. Принципиальных сдвигов не произошло и все выкладки этих ребят до сих пор более чем актуальны.

Здравствуйте, Mikst, Вы писали:

M>Что-то как-то я не нашел таких команд в ЕМ Ну Почему sp_change_users_login нельзя сделать прямо из ЕМ??

M>Так и есть. Согласен, но как установить того что я хочу прямо из ЕМ... не дает зараза этого делать.
Ну, просто такой режим работы не предусматривался разработчиками. Не учли, что базу кто-то будет переносить между инстансами сервера.

M>"соответствующую закладку " я уже искал, можно ее название пожалуйста.
Извини, я наизусть не помню, а EM у меня не стоит в связи с переходом на новую версию сиквела. Там в таскпаде третья закладка как раз про размеры.

M>"набор хранимок для общения с сервером" .. как я посмотрю в МС без хранимок никуда.... не используем мы их без особой на то надобности.
Отлично. То есть запросы у вас прямо в код зашиты. Тогда расскажи мне, как твой ДБА исправит эти запросы?

M>можно можно, при соответствующем сотрудничестве с ДБА.
Гм. Лично я предпочитаю основные вещи писать не рассчитывая на наличие под рукой ДБА для проверки моих действий.

M>Мазохисты прям

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mikst, Вы писали:

M>>Что-то как-то я не нашел таких команд в ЕМ Ну Почему sp_change_users_login нельзя сделать прямо из ЕМ??

M>>Так и есть. Согласен, но как установить того что я хочу прямо из ЕМ... не дает зараза этого делать.
S>Ну, просто такой режим работы не предусматривался разработчиками. Не учли, что базу кто-то будет переносить между инстансами сервера.

M>>"соответствующую закладку " я уже искал, можно ее название пожалуйста.
S>Извини, я наизусть не помню, а EM у меня не стоит в связи с переходом на новую версию сиквела. Там в таскпаде третья закладка как раз про размеры.


нету... ничего... абсолютно. ну да ладно.

M>>"набор хранимок для общения с сервером" .. как я посмотрю в МС без хранимок никуда.... не используем мы их без особой на то надобности.
S>Отлично. То есть запросы у вас прямо в код зашиты. Тогда расскажи мне, как твой ДБА исправит эти запросы?

Большинтво запросов простые, и нет надобности их исправлять. Сложные — да... тут надо выбирать, можно и ХП (я опять таки подчеркиваю, что не использую их _без особой на то надобности_, это не значит "никогда")


M>>можно можно, при соответствующем сотрудничестве с ДБА.
S>Гм. Лично я предпочитаю основные вещи писать не рассчитывая на наличие под рукой ДБА для проверки моих действий.

А чего их проверять, сидят и пишут себе, и все работает, и не мучиет и головная боль за блокировки и прочую ерундень.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Подкололи Уважаю.. но тем не менее результат — фигня.
M>Я не подколол. Если строки в наборе не зависят друг от друга то совершенно не важно, что в выборку попали строки из разных версий. Вы же только что доказывали, что умеете так ловко проектировать, что строки у Вас совершенно независимы.

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

M>>а если кроме amount изменяется остальные поля?? все равно блокировка чтения?
M>Тогда заблокируюется запись и другие индексы, если они есть...

ну а смысл тогда в таком индексе.. эх. проще все под оракл переписать

Здравствуйте, Mikst, Вы писали:

M> нету... ничего... абсолютно. ну да ладно.
Есть. На базе жмем правую кнопку. View -> TaskPad и наслаждаемся просмотром деталей.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>> нету... ничего... абсолютно. ну да ладно.
H_I>Есть. На базе жмем правую кнопку. View -> TaskPad и наслаждаемся просмотром деталей.

алелуя!! Вот что называется "дружественный интерфейс" )))))) для начала надо было встать на уровень БД потом выбрать в несовсем привычном меню, совершенно непонятную команду... и потом не сразу заметить закладку Table Info

PS: Спасибо.

Здравствуйте, Mikst, Вы писали:

M>алелуя!! Вот что называется "дружественный интерфейс" )))))) для начала надо было встать на уровень БД потом выбрать в несовсем привычном меню, совершенно непонятную команду... и потом не сразу заметить закладку Table Info
Собственно, у Oracle он не менее дружественный... Потому как оракловый EM для человека, впервые видящего Oracle, такой же темный лес. А уж про EM for Oracle 10g — так это вообще нечто! Не так?

M>PS: Спасибо.
Да не за что! Всегда рад помочь...

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>>алелуя!! Вот что называется "дружественный интерфейс" )))))) для начала надо было встать на уровень БД потом выбрать в несовсем привычном меню, совершенно непонятную команду... и потом не сразу заметить закладку Table Info
H_I>Собственно, у Oracle он не менее дружественный... Потому как оракловый EM для человека, впервые видящего Oracle, такой же темный лес. А уж про EM for Oracle 10g — так это вообще нечто! Не так?

Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

Здравствуйте, Mikst, Вы писали:

M>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

H_I>Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

H_I>Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

А если не сильно страшно вспомнить, (для расширения кругозора), какие наибольшие (доставившие более всего хлопот) проблемы были?

Просто сейчас зашла речь про перенос этой програмки на оракл, так как читателю всеравно откуда читать, а писателей можем переписать как нужно.

Здравствуйте, Mikst, Вы писали:

M>Они не зависят в данном случае друг от друга, но они долны быть одной версии,
Так не бывает. Либо они независимы и тогда не важно какой они версии.
Либо зависимы и тогда надо смотреть на эту зависимость.

M>ну а смысл тогда в таком индексе..
В том, что при чтении будет блокироваться только этот индекс и само чтение будет быстрым и никому не помешает.

Здравствуйте, Mikst, Вы писали:

M>Здравствуйте, Horror_Infinity, Вы писали:

H_I>>Здравствуйте, Mikst, Вы писали:

M>>>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

H_I>>Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

H_I>>Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

M>А если не сильно страшно вспомнить, (для расширения кругозора), какие наибольшие (доставившие более всего хлопот) проблемы были?
Да почему же? Основной геморрой будет как раз с теми самыми временными таблицами, которых в оракле просто нет. Как результат — либо переписывание заново логики хранимок, либо написание табличных функций, что не добавит производительности. Несовпадение типов данных. VARCHAR2(Oracle) != VARCHAR(MS). Как следствие — изменение метаданных таблиц. Что тоже не есть гуд. И таких мелочей и немелочей довольно много.

M>Просто сейчас зашла речь про перенос этой програмки на оракл, так как читателю всеравно откуда читать, а писателей можем переписать как нужно.
А нужно ли переносить? Работа нудная, кропотливая и довольно длительная.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>>Здравствуйте, Horror_Infinity, Вы писали:

H_I>>>Здравствуйте, Mikst, Вы писали:

M>>>>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

H_I>>>Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

H_I>>>Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

M>>А если не сильно страшно вспомнить, (для расширения кругозора), какие наибольшие (доставившие более всего хлопот) проблемы были?
H_I>Да почему же? Основной геморрой будет как раз с теми самыми временными таблицами, которых в оракле просто нет. Как результат — либо переписывание заново логики хранимок, либо написание табличных функций, что не добавит производительности. Несовпадение типов данных. VARCHAR2(Oracle) != VARCHAR(MS). Как следствие — изменение метаданных таблиц. Что тоже не есть гуд. И таких мелочей и немелочей довольно много.

хранимок и временных таблиц нет. Приложение по сути наипростейшее. стандартный DDL и все.
метаданные все в PowerDisigner, пересоздать схему раз плюнуть. Репликацию думаю тоже сделать не архисложно.

M>>Просто сейчас зашла речь про перенос этой програмки на оракл, так как читателю всеравно откуда читать, а писателей можем переписать как нужно.
H_I>А нужно ли переносить? Работа нудная, кропотливая и довольно длительная.

Зато результат как говорится будет "на лице" (довольном что все работает)

Здравствуйте, Mikst, Вы писали:

M>хранимок и временных таблиц нет. Приложение по сути наипростейшее. стандартный DDL и все.
M>метаданные все в PowerDisigner, пересоздать схему раз плюнуть. Репликацию думаю тоже сделать не архисложно.
Тогда — да. Просто. Остается только проблема совместимости типов данных и иж размерностей. Но это — как повезет. Если нигде нет строковых данных, превышающих оракловые 4000 байт, то и слава Богу. А если есть?

M>Зато результат как говорится будет "на лице" (довольном что все работает)
Ну, заранее этого сказать все ж таки нельзя.

Здравствуйте, Merle, Вы писали:

GZ>>Что касается Кайта, то хоть убей не найду где я это читал. На вопрос насколько Oracle поддерживает SQL92 он очень оригинально ответил. Смысл был такой, ребяты, вы что. Мы сами стандарт и писали. И принимали непосредственное участие в этом. Ну и далее стандартно объяснял об уровнях в SQL92 и как поддерживается. Но вот откуда я читал это, не найду.
M>Кайт действительно входил в комитет по стандарту, но вот работал ли он в то время в Оракл — не уверен. У этого дядьки похоже вообще большой комплекс, по поводу того, что Оракл написали без него...
Кайт писал что работал с Oracle версии 5, следовательно на момент выхода стандарта — уже был ораклистом. С другой стороны, я не видел каких-то теоретических работ мистера Кайта — следовательно как независимый он вряд ли мог появиться в комитете. Отсюда вывод — был в комитете как представитель Oracle.

GZ>>Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.
M>В том-то и прелесть, что это не история, это то с чем мы сталкиваемся регулярно. С той давней поры в подходах к разруливанию consistency problem мало что изменилось — ну придумали несколько незначительных оптимизаций, не больше. Принципиальных сдвигов не произошло и все выкладки этих ребят до сих пор более чем актуальны.
Прочитал. Да, занятная статья. Попробовал по русски сначало прочесть. Понял что это слишком непросто. За перевод убил бы. Пришлось читать буржуйский вариант.
Просто не понял почему в SQL92 крен в сторону блокировочников. Феномены не ограничиваются тремя наиболее известными случаями. И это ясно показывается и доказывается(некоторые феномены еще Дейт раньше описывал). Вроде термин сериализации кардинально поправили в новых стандартах.

С уважением, Gleb.