Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
2 ggv по-моему Вы не правы допустим один коннекст выполняет запрос Код: plaintext 1. 2. 3. ну или объясните как тут можно выкрутиться ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:45 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
Блин, я же писал - речь не идет о Uncomited Read. Дополняю - речь идет о Cursor Stability,или Read Stability Параметры называются Scip_inserted, scip_deleted, evaluate_uncomited Повторяю опять - используя эти переменные, можно получить набора данных НЕ дожидаясь COMMIT писателей, и выгрузив набор консистентных данных во временную таблицу, транзакция мрожет делать любые действия, в том числе длительные, не влияя на остальные транзакции - так как транзакция уже получила свой набор данных, на котором будет работать. И опять, в таком случае, никакая длительная блокировка не накладывается Ну и поскольку транзакция только читает данные, то ей не потребуется сливать изменения и делать MERGE. Ну сколько можно разжевывать. Эко вас как раздраконила такая фича... Успокойтесь, не все так страшно, забейте на это, и продолжаейте свято верить, что oracle лучший. А тесты просто не смотрите - все равно при выборе платформы под проект, результаты тестов не учитываются, это стопудово. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:49 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
т.е. как выкрутиться понятно - не делать длинных транзакция, а данные заранее прочитать во временную таблицу но полностью съэмулировать версионник не получится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:49 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
SergSuper - ну я же написал, что в блокировочнике db2 транзакция делающая select не обязана зависнуть, если есть незакомиченные транзакции писателей, и это поведение регулируется тремя registry variables (не путать с windows registry) уровня инстанции db2 (ничего общего с инстанцией oracle) То есть я делаю INSERT/UPDATE/DELETE в одной транзакции и не делаю commit, другая транзакция делает select * from table with CS (cersor stability) и получает набор данных без задержки. Да, есть такая возможность, ну что же я, виноват теперь, что ли... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:53 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
Yo!! -- поведение юкона мне абсолютно фиотелово. Как-то так по жизни получилось, что у меня небыло, нет, и не будет, скорее всего, продуктов MS ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:55 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggvSergSuper - ну я же написал, что в блокировочнике db2 транзакция делающая select не обязана зависнуть, если есть незакомиченные транзакции писателей, и это поведение регулируется тремя registry variables (не путать с windows registry) уровня инстанции db2 (ничего общего с инстанцией oracle) То есть я делаю INSERT/UPDATE/DELETE в одной транзакции и не делаю commit, другая транзакция делает select * from table with CS (cersor stability) и получает набор данных без задержки. Да, есть такая возможность, ну что же я, виноват теперь, что ли... замечательно. И что же она вернёт? Последнюю закоммиченную версию? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 11:59 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
вернет набор закомиченных на момент начала транзакций данных То есть незакомиченные будут пропущены. Yo!! могу успокоить, что эти переменные выключены по умолчанию, и подавляющее большинство пользователей (кторые не читают доки) этим не воспользуются. Так же есть всякие ограничения - ну типа, к таблицам системного каталога это не применимо, и тому подобное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:05 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
четсное слово, мне уже начало надоедать, и я, наверное, отвалю с ветки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:06 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggvчетсное слово, мне уже начало надоедать, и я, наверное, отвалю с ветки Насколько я понимаю, незакомиченные изменения будут пропускаться. Это не позволит эмулировать поведение версионника. Либо вам придется самостоятельно делать снапшоты перед любыми изменениями. А в читающей транзакции учитывать, что данные надо брать и из таблицы и из временной таблицы. Как минимум это не удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:17 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
2ggv чесное слово не устраивайте тут детский сад, игра в обиженых и непонятых нам не понятна. а то как ребенок зуб даете что работает а ничерта пояснить не можете, второй день пудрите мозги MERGE. 1. линк на доку с select * from table with CS (cersor stability) 2. вы можете без соплей объяснить откуда селект возьмет "вернет набор закомиченных на момент начала транзакций данных" если с момента начала селекта в базу уже СОТНИ закомиченых транзакций, где хранятся все версии ? то что дб2 может взять последнюю закомиченую никакого интереса не предсталяет, это никоим оьразом не похоже на snapshot ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:22 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggv, не надо сваливать, я хочу разобраться правильно ли я понял: в DB2 можно получать данные как в оракле, на момент начала "чужой" транзакции, либо (в зависимости от настроек) можно ожидать конца текущей транзакции. Т.е. писатель как и в версионнике не блокирует читателя. Теперь доуглй вопрос: может ли читатель может не блокировать писателя? Т.е. первая транзакция Код: plaintext 1. 2. 3. Здесь же 2-я транзакция зависнет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:29 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)[quot ggv] Насколько я понимаю, незакомиченные изменения будут пропускаться. Это не позволит эмулировать поведение версионника. Либо вам придется самостоятельно делать снапшоты перед любыми изменениями. А в читающей транзакции учитывать, что данные надо брать и из таблицы и из временной таблицы. Как минимум это не удобно. Да, незакоммиченные данные будут пропускаться. Читатель ничего не будет знать, про незакомиченные изменения, так же как и в версионнике он ничего про них не знает Yo!! -- ну если уж на личности переходим, то мне уж тут точно делать нечего. Если вы понять не способны, что в db2 писатель не блокирует читателя, то я ничем помочь не могу. Берите официальную доку, благо она доступна, и гризите гранит науки, или гууглите. А то мне вам, как ребенку, уже надоело пояснять. Даже где-то пробегала статья, поясняющая (не польностью) реализацию этого. Я ее пропустил, так как мне потроха не интересны ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:30 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
SergSuper правильно ли я понял: в DB2 можно получать данные как в оракле, на момент начала "чужой" транзакции, либо (в зависимости от настроек) можно ожидать конца текущей транзакции. Т.е. писатель как и в версионнике не блокирует читателя. Да, именно так. И не такое уж свежее нововедение. Если я не ошибаюсь, по требованию фирмы SAP было сделано SergSuper Теперь доуглй вопрос: может ли читатель может не блокировать писателя? Т.е. первая транзакция Код: plaintext 1. 2. 3. Здесь же 2-я транзакция зависнет? Это то, что я описал в пункте 2) - да, может, если после получения набора данных выгрузит их во временную таблицу и снимет блокировки с основной, и нет, не может, если не выгрузит и не снимет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:33 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
2ggv обычно с теми от кого я могу получить что-то новое и полезное я стараюсь не пинать ... но вы извините мне 2 дня пургу про MERGE несли именно это меня несколько и вывело из себя. но ладно, забыли про merge едем дальше: я уже понял что вы не понимаете как это раблотает, но вы можете хотя бы код показать, т.к. из ваших объяснений пока следует что ... 2All судя по всему он рассказывает о IL Cursor Stability авторLike levels RR and RS, level Cursor Stability (CS) ensures that any row that was changed (or a row that is currently locked with an UPDATE row lock) by another activation group using a different commitment definition cannot be read until it is committed. Unlike RR and RS, level CS only ensures that the current row of every updatable cursor is not changed by other activation groups using different commitment definitions. Thus, the rows that were read during a unit of work can be changed by other activation groups that use a different commitment definition. In addition to any exclusive locks, an activation group running at level CS may acquire a share lock for the current row of every cursor. In the SQL 1999 Core standard, Cursor Stability is called Read Committed. DB2 UDB for iSeries supports cursor stability through COMMIT(*CS). http://publib.boulder.ibm.com/infocenter/iseries/v5r3/ic2924/index.htm?info/db2/rbafzmstisol.htm ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:38 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggvДа, незакоммиченные данные будут пропускаться. Читатель ничего не будет знать, про незакомиченные изменения, так же как и в версионнике он ничего про них не знает блокировочник на чтении заблокированной строки: 1. может ждать завершения транзакции 2. может пропустить строку в выборке 3. может прочитать незакоммиченные данные версионник: может прочитать данные строки на момент начала своей транзакции Как Вы собираетесь добиться этой функциональности при помощи временных таблиц с приемлемой производительностью ? Мне это не понятно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 12:43 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ну да, все правильно, он просто указывает CS в select'e авторisolation-clause 7 7 >>-+---------------------------------------+------------------->< 7 '-WITH--+-RR--+---------------------+-+-' 7 | '-lock-request-clause-' | 7 +-RS--+---------------------+-+ 7 | '-lock-request-clause-' | 7 +-CS--------------------------+ 7 '-UR--------------------------' 7 7 7 The optional isolation-clause specifies the isolation 7 level at which the statement is executed, and whether a specific type 7 of lock is to be acquired. 7 7 7 RR - Repeatable Read 7 RS - Read Stability 7 CS - Cursor Stability 7 UR - Uncommitted Read я балдею, ggv вы 2 дня мне доказывали что READ COMMITED замечательно заменит оракловый snapshot :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:10 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
Yo!! -- ничего общего приведенная цицтата с поведением при scip_[inserted/deleted] и evaluate_uncommited не имеет - это другой функционал, ключевые слова для поиска я дал. Gluk - как я уже выше неоднократно пояснял, при использовании вышеупомянутых настроек db2 может прочитать все закомеченные данные на момент начала транзакции, если множество строк было изменено, и изменения не закомичены, то они прочитаны не могут быть, но могут быть пропущены. Для уменьшения влияния длительных блокировок можно использовать временные таблици с последующим merge Это не в полной мере версионник, но я такого и не говорил - поведение приближается к версионнику ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:11 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
Yo!! - извините, но или вы читаете плохо, или туп и не лечитесь. Скорее первое. Ничего общего с Read Commited это не имеет, на этом разрешите прекратить всяческие препинания с вами в одностороннем порядке - устал просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:13 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggvЭто не в полной мере версионник, но я такого и не говорил - поведение приближается к версионнику Ни в каком месте ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:22 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
Gluk - ну хорошо, я уже на все согласен, называйте это как хотите. К тому же IBM нигде и не позиционирует db2 как версионник, просто документирует возможность получить более высокую concurency И это так и есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:29 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggv разрешите прекратить всяческие препинания с вами в одностороннем порядке - устал просто. Но все равно Вы долго смогли продержаться на столь уязвимых позициях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:45 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
vadiminfo - я говорил, лишь то, что я говорил. Начал, правда, с конца, ошибочно полагая что всем известны возможности db2 де-факто, и не надо пояснять про scip_[inserted/deleted] и evaluate_uncommited. Повторю лишь, что главный эффект этих фич - устранение эффекта ожидания транзакций и повышение concurency. И эффект достигнут. В этом смысле (только в этом) поведение db2 становиться похоже на версионное. Кроме того, что указал Gluk, есть еще два момента, которые я не называл, но ожидал что они будут подняты, и в чем есть расхождения. Ну никто не задумался над ними, так что я тоже пропущу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:52 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ggvGluk - ну хорошо, я уже на все согласен, называйте это как хотите. К тому же IBM нигде и не позиционирует db2 как версионник, просто документирует возможность получить более высокую concurency И это так и есть. еще бы, длинный селект в режиме CS прочитает половину таблиц на время 12:00, а вторую на 12:15. и скипнет или не скипнет, mergeнит или не mergeнит это не важно, важно что полезность такого селекта примерно такая же как и при грязном чтении. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 13:53 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
ну если пропустить безумные высказывания Yo!!, то можно составить таблицу поведения db2 и версионника в трех случаях, insert, delete, и update так вот в случае insert поведение будет абсолютно одинаково, в случае delete абсолютно разное, в случае update не так однозначно, и будет зависеть от предикатов select statement ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 14:06 |
|
||
|
Срочно!!! сравнительная характеристика MSSQL2000 и Oraqul 9i
|
|||
|---|---|---|---|
|
#18+
при delete абсолютно противоположное в смысле что в версионнике получим все удаленные строки (так как они не закомичены) а в db2 не получим удаленных строк, даже если удаление незакомичено. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2005, 14:11 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=33290323&tid=1553763]: |
0ms |
get settings: |
8ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
68ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
2ms |
| others: | 230ms |
| total: | 436ms |

| 0 / 0 |
