|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovДа конечно, когда видишь, что сервер не в состоянии тривиально развести вставку и удаление разных записей, только и остаётся что пойти чего-нибудь пожевать с горя. не, такую тупость лучше убивать. я же лично тебя мокал носом в ROWDEPENDENCIES ... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 12:46 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!я же лично тебя мокал носом Которое нельзя указать в alter table, да-да... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 12:49 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovКоторое нельзя указать в alter table, да-да... да, тут мне крыть нечем. alter table - большой минус к IL serializable может пойдешь все таки пожувать, вроде и время обеденное ... ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 13:10 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!да, тут мне крыть нечем. alter table - большой минус к IL serializable А с другой стороны, да, чего его менять-то?.. Вопрос "в этой таблицей можно работать в serializable, а с этой - нет" всегда решается ещё на этапе создания БД. Для этого и нужны укуренные пифии. Исторически сложилось, что кроме них никто с Оракулам общаться не может. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 13:34 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!он же неконсистентную кашу выдает.На чём конкретно (кашу выдаёт) ? Yo.!если в трешке обещают починить RC, что там будет вместо оракловых рестартов ? неконсистентная хрень как я понимаю ?Что касается "вместо рестартов", то коннект, добравшийся до залоченной записи, после получения её в свое пользование (для апдейта или делита) будет сравнивать, не изменилась ли она в каком-нить поле. И если изменилась, то он получит исключение lock conflict. И не перетрёт при этом чужое закоммиченное изменение иначе, чем через рестарт. Если же коннект-1 начал длительный апдейт в TIL = RC, а коннект-2 быстро успел добавить и закоммитить новую запись, то коннект-1, конечно же, увидит её, когда доберётся до соотв. места в базе. Но только в RC, в snapshot'e - ни в жизнь :-) PS. И это не в трёшке будет, а так вообще с нуля заложено было. В трёшке обещают починить другое: стейтмент, меняющий поля, входящие в критерий отбора (во where-предикат, например), не должен видеть новые значения этих полей. Но по моей практике, таких запросов всё-таки очень мало встречается. Изменение суррогатных ключей - bad practice. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 13:37 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
ТаблоидНа чём конкретно (кашу выдаёт) ? а вы спросите на форуме FB. там ребята все как на подбор, добрые, отзывчивые ... ТаблоидЧто касается "вместо рестартов", то коннект, добравшийся до залоченной записи, после получения её в свое пользование (для апдейта или делита) будет сравнивать, не изменилась ли она в каком-нить поле. И если изменилась, то он получит исключение lock conflict. И не перетрёт при этом чужое закоммиченное изменение иначе, чем через рестарт. вы начали козырять термином не вьехав в его суть. ТаблоидPS. И это не в трёшке будет, а так вообще с нуля заложено было. В трёшке обещают починить другое: стейтмент, меняющий поля, входящие в критерий отбора (во where-предикат, например), не должен видеть новые значения этих полей. Но по моей практике, таких запросов всё-таки очень мало встречается. Изменение суррогатных ключей - bad practice. у пишушего стейтмента взрослой субд не прокатит видеть базу на момент старта стейтмента, такую хрень могут себе позволить субд третьего эшелона. собственно в этом и есть суть рестарта, на изменяемые записи и оракл ставит блокировки, но что делать если изменились предикаты ? майкрософт на READ_COMMITTED_SNAPSHOT просто лочит предикаты и стопорит всю активность в базе, оракл делает миниоткат и рестат стейтмента, ну а могучий firebird не замарачивается по пустикам. интересно, если в трешке не планируют чинить RC, в чем же смысл волноваться о каких-то предикатах ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 14:40 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!у пишушего стейтмента взрослой субд не прокатит видеть базу на момент старта стейтмента Поэтому в нормальных СУБД он видит нужные данные по состоянию на начало транзакции. Но взрослым СУБД это не понять, они с трудом понимают что такое транзакции вообще, когда те начинаются и когда заканчиваются. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 15:09 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovПоэтому в нормальных СУБД он видит нужные данные по состоянию на начало транзакции. список "нормальных субд", которые на IL Read Committed видят данные по состоянию на начало транзакции в студию ! а может все таки жевать ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 15:14 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!у пишушего стейтмента взрослой субд не прокатит видеть базу на момент старта стейтмента, такую хрень могут себе позволить субд третьего эшелона. собственно в этом и есть суть рестарта, на изменяемые записи и оракл ставит блокировки, но что делать если изменились предикаты ? майкрософт на READ_COMMITTED_SNAPSHOT просто лочит предикаты и стопорит всю активность в базе, оракл делает миниоткат и рестат стейтмента, ну а могучий firebird не замарачивается по пустикам. ..... список "нормальных субд", которые на IL Read Committed видят данные по состоянию на начало транзакции в студию ! О как внезапно SNAPSHOT превращается в Read Committed... Придерживаться уровня изоляции, заданного пользователем это, видимо, ещё одна вещь, которая во взрослых субд не прокатит... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 15:25 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovО как внезапно SNAPSHOT превращается в Read Committed... Придерживаться уровня изоляции, заданного пользователем это, видимо, ещё одна вещь, которая во взрослых субд не прокатит... обезьянка в READ_COMMITTED_SNAPSHOT увидела знакомое слово снепшот и решила еще раз поразить нас своей тупостью ? я угадал ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 15:33 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!а вы спросите на форуме FB. там ребята все как на подбор, добрые, отзывчивые ...я там постоянно отираюсь, надоел уже им всем Yo.!вы начали козырять термином не вьехав в его суть.и какая у него суть, можно узнать ? (про рестарт запущенного оператора) Вот есть таблица в 100500 млн строк, поля: id int pk, f01 int. Вот есть коннект_1, стартующий в режиме RC апдейт этой таблицы, меняет в ней поле f01 на 111 (без всякого where-условия; ну, или с where id>0 :)). Вот есть коннект_2, он успел стартовать и быстро закоммитить вставку записи в эту таблицу с каким-то там "своим" f01. В новой строке появилось id=1234567891234, f01=-222. Через 5 минут коннект_1 добрался до вставленной коннектом_2 записи. И делает рестарт. Простой вопрос: зачем ? чтобы изменилось, если бы коннект_1 просто сразу переписал изменения "своим" значением для f01 ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 15:35 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!я угадал ? Ага, угадал. Я всё время забываю, что если на клетке взрослых субд написано "Слон" - не верь глазам своим... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 16:03 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Таблоидя там постоянно отираюсь, надоел уже им всем я знал, что ты оценишь шутку о чуткости фб-гайз если не прикидываешься - почитай вокруг этого поста http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=173455&msg=1460385 ТаблоидПростой вопрос: зачем ? чтобы изменилось, если бы коннект_1 просто сразу переписал изменения "своим" значением для f01 ? произошла бы порча данных. представь, что там еще был коннект_1.5 который вставил данные в начало таблицы. выходит твой апдейт "заметил" записи коннект_2 и не заметил записи коннект_1.5, который закомитил вставку после начала работы коннект_1, но до коннект_2. т.е. переписав коннект_1 бы увидел базу в таком состоянии, в котором она не была ни в какой момент времени (если были данные коннект_2, значит уже были и коннект_1 данные). оракл же гарантирует консистентность стейтмента и соответсвенно такой хери допустить не может. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 16:05 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!произошла бы порча данных. представь, что там еще был коннект_1.5 который вставил данные в начало таблицы. выходит твой апдейт "заметил" записи коннект_2 и не заметил записи коннект_1.5, который закомитил вставку после начала работы коннект_1 Правильно ли я понимаю, что описывается следующая хронология событий: timesess #1sess #1.5sess #2T1insert into t values(1, 111); -- БЕЗ commit`a!T2insert into t values(99999999999, 999); -- БЕЗ commit`a!T3update t set f01 = 0 where id >=0; Если правильно, и при этом в момент Т1 для добавленной строки была выделена страница (блок) базы номер <самый_наименьший>, то апдейт (Т3) тут же упрётся в эту запись - она же залочена. А если апдейт в sess #1 уже начался, то sess #1.5 не закоммитится до тех пор, пока апдейт не сделает commit/rollback. Где я ошибаюсь ? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 16:32 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Таблоид, неправильно. у вас понятно, что update стопорнет уже на ID=1 я говорил сначала запускается update .. where id>0 (T0), он пошел менять строки и пока он работает параллельные коннекты вставляют строку в начало таблицы + коммит (T1), потом в конец таблицы + коммит (T3). firebird запись в конце проапдейтит, а ту что в начале нет, хотя такого состояния в БД ни в один момент времени не было. в оракле я посмотрел, в столь простой ситуации рестарта не будет. оракл проапдейтит как и полагается только те записи, что были на момент старта апдета. имхо для рестарта более сложный предикат с участием другой таблицы быть обязан. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 17:08 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!коннекты вставляют строку в начало таблицы + коммит (T1), потом в конец таблицы + коммит (T3). firebird запись в конце проапдейтитЕсли под "началом таблицы" понимать физический номер страницы, куда шлёпнется добавленная коннектом_1.5 запись, то такая вставка обломится. Ибо эта страница будет к тому времени уже заблокирована апдейтом. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 17:36 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
ТаблоидЕсли под "началом таблицы" понимать физический номер страницы, куда шлёпнется добавленная коннектом_1.5 запись, то такая вставка обломится. Ибо эта страница будет к тому времени уже заблокирована апдейтом. брехня. оракл блокирует исключительно на уровне строк. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 17:38 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!, я не про оракл сейчас говорю. ФБ заблокирует перед изменением те строки, которые подпадают под критерий отбора. Он *не* будет, разумеется, лочить всю таблицу. Меня заинтересовал ваш пример с коннект_1.5, который вставляет в "начало таблицы", но я не уверен, что правильно его понял. Вы можете "на языке" Oracle его показать ? (я пойму и попробую аналогичное сделать в ФБ) ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 17:48 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
делаем IOT таблицу (что бы гарантировать, что пишем в начало и конец) create table shit (id int primary key, a varchar2(20)) organization index; загоняем туда млн записей начина с ID=2 Код: plsql 1. 2. 3. 4. 5. 6. 7. 8.
сессия1: update shit set a='updated' where id>0 ; пока там шуршит сессия2: insert into shit values (1,'new') ; commit; insert into shit values (1000001,'new') ; commit; сколько записей проапдейтит FB ? практически наверняка, проапдейтит 1000001, а 1 оставит нетронутой. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 17:58 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Yo.!делаем IOT таблицу (что бы гарантировать, что пишем в начало и конец) create table shit (id int primary key, a varchar2(20)) organization index;в ФБ, к сож-ю, нет такого вида таблиц, на сегодня - только heap. Но для проверки того, где сидит запись, в "начале" или в "конце" таблицы, можно юзать системное поле с именем rdb$db_key. Чем оно меньше, тем ближе запись к "началу" таблицы. Что я далее и сделаю. Yo.!сколько записей проапдейтит FB ? практически наверняка, проапдейтит 1000001, а 1 оставит нетронутой.А вот и проверим. Создаём новую базу, наталкиваем в неё 999999 строк: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
Далее запускаем второе isql-окно, и вводим там команду вставки + коммит, но БЕЗ нажатия Enter'a: Код: plaintext 1. 2. 3.
Идём снова в первое окно: Код: plaintext 1. 2.
Переключаемся во второе окно и жамкаем там тоже Enter: Код: plaintext 1. 2.
Ждём окончания выполнения в первом окне, затем вводим там: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
Таким обр., session #1 увидела запись, добавленную в session #2 с id=-1. Я так понимаю, что произошло это из-за добавления этой записи не в дырку, образованную от удаления первых 10 строк, а именно в конец таблицы (см её RDB$DB_KEY). Я не знаю, всегда ли так происходит - это лучше у ФБ-разрабов спросить. Если строка будет добавлена действительно в начало таблицы, то апдейт уже не увидит её, конечно. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 19:12 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
да, получилось поймать этот момент... к сож-ю, в моей любимой СУБД действительно есть проблема с RC в вышеприведенном примере Test: всё тоже самое, только увеличиваем число строк до 2 млн, затем удаляем 1 млн и сразу собираем мусор: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48.
Трейс безжалостен: произошёл апдейт не 1'000'001 строки, а всё того же "старого" 1'000'000: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16.
PS. И еще непонятно вот что: судя по rdb$db_key, эта запись всё равно оказалась в "конце" таблицы: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 19:26 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Таблоиддействительно есть проблема с RC Повторяю ещё раз, медленно: тот, кто понизил TIL с умолчания до RC - ССЗБ. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 19:46 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovТаблоиддействительно есть проблема с RCПовторяю ещё раз, медленно: тот, кто понизил TIL с умолчания до RC - ССЗБ.Не, погодь!.. RC в SQL-стандарте есть или нет ? Есть. По стандарту стейтмент, стартовавший в RC, должен увидеть все изменения, зафиксированные другими транзакциями после своего старта ? Да, должен. Ну, и ? ЗЫ. Я понимаю, что snapshot в IB/FB был гораздо раньше сделан, чем RC. Но на практике-то в OLTP-системах юзают именно RC, как более способствующий производительности. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 20:05 |
|
Что лучше FireBird 2.1 или MS SQL 2000?
|
|||
---|---|---|---|
#18+
Таблоидюзают именно RC, как более способствующий производительности. С какого бы перепугу? Ты эту "разницу в производительности" мерял? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
10.10.2012, 20:09 |
|
|
start [/forum/topic.php?fid=35&msg=37991621&tid=1552514]: |
0ms |
get settings: |
10ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 152ms |
0 / 0 |