Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: Sybase?!?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Ага, я разрабатываю приложение, делаю его, делаю, расчитываю на 50 пользователей одновременно работающих, приложение заработало, но вот после набранных например 1 милиона записей (или еще какойто момент), база завотела повысить уровень блокировки для транзакции какого либо пользователя, а все отальные?

привожу цитату:

Эскалация блокировок сильно увеличивает вероятность захватов.
Например, представьте себе ситуацию, когда система пытается
осуществить эскалацию блокировок от имени транзакции T1, но не
может сделать этого из-за блокировок, удерживаемых транзакцией
T2. Захват произойдет, если транзакции T2 теперь также
потребуется эскалация блокировок; системный "эскалатор" уже
занят транзакцией T1.
18 дек 02, 16:54    [93339]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
Не очень понял что такое захват, предполагаю, что Deadlock.
В таком случае достаточно следовать рекомендациям Microsoft, а именно:
- Access Objects in the Same Order
- Avoid User Interaction in Transactions
- Keep Transactions Short and in One Batch
- Use a Low Isolation Level
- Use Bound Connections
И с умом проектировать приложение, что бы говорить о deadlocks чисто теоретически.
Ваш пример могу себе представить только если в приложение выдается юзеру грид на редактирование с соответствующей блокировкой.

Зато с точки зрения ресурсов эскалация блокировок вполне оправданный механизм.
18 дек 02, 17:09    [93347]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Можно с умом извращаться и с dbf на foxpro, (я такое видел),
ноя видел к чему это приводит когда система становиться сложнее и сложнее, а данных больше и больше
18 дек 02, 18:28    [93431]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
Хотел бы поддержать Genady. Блокировать все по максимуму означает превратить БД в однопользовательскую. Напротив, не имеет смысла ставить блокировки уровня записи в ситуации, когда один юзер работает с таблицей из миллиарда строк. Не знаю, сколько занимает структура типа lock resource block в Oracle, в SQL Server - 64 байта. Ну и зачем менеджеру блокировок в этом случае сжирать под себя 64 гиг, если проще проэскалировать? Не знаю, я считаю, что автоматическое управление гранулярностью блокирования является единственным разумным механизмом, позволяющим добиться компромисса между приемлемой конкурентностью доступа и системными затратами на его обеспечение.
18 дек 02, 18:45    [93446]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>Хотел бы поддержать Genady. Блокировать все по максимуму означает превратить БД в однопользовательскую. Напротив, не имеет смысла ставить блокировки уровня записи в ситуации, когда один юзер работает с таблицей из миллиарда строк. Не знаю, сколько занимает структура типа lock resource block в Oracle, в SQL Server - 64 байта. Ну и зачем менеджеру блокировок в этом случае сжирать под себя 64 гиг, если проще проэскалировать? Не знаю, я считаю, что автоматическое управление гранулярностью блокирования является единственным разумным механизмом, позволяющим добиться компромисса между приемлемой конкурентностью доступа и системными затратами на его обеспечение.

Ну не все так печально.
В Oracle строковая блокировка реализуется через ITL-слот. 24байта. По умолчанию 1 слот на 1 блок (а это реально сотни строк). Если _одновременно_ к блоку за изменением данных обращаются 2 транзакции, дополнительно будет динамически выделен еще один слот, если _одновременно_ 3 - еще один, и так далее. Так что ни о каком пожирании 64G речь не идет. А вот эскалация блокировок - это беда и беда настоящая.
18 дек 02, 19:14    [93471]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
Извините, killed, но по-моему Вы путаете lock resource block c lock owner block. С Вашего позволения, я оперирую в рамках терминологии SQL Server, но смысл, думаю, понятен. Как можно в 24 байта уместить информацию о сотне (как Вы говорите) заблокированных строк? 24 * 8 = 192 бита. Ну пусть по два бита на запись. Один, допустим, выступает флажком, что запись заблокирована. Как в один оставшийся бит уместить бездну информации о lock mode (S, U, X, ...), статусе (грантована, конвертируется, ждет), пойнтер данной записи и многое другое?
18 дек 02, 19:36    [93490]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
Можно с умом извращаться и с dbf на foxpro, (я такое видел),
ноя видел к чему это приводит когда система становиться сложнее и сложнее, а данных больше и больше

Странные вещи Вы говорите, потому как кроме того, что нужно с умом проектировать приложение, нужно с не меньшим умом выбирать инструмент. Foxpro (с которым я в свое время не мало поработал) персональная СУБД!
19 дек 02, 11:55    [93801]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
А вот эскалация блокировок - это беда и беда настоящая.

Oracle не знаю, потому трогать его не буду, :-) для MS SQL это не беда, а всего лишь разумный компромисс. За те 3 года моего общения с MS SQL 7, 2000, я вот только здесь узнал, что это оказывается настоящая беда.
19 дек 02, 12:02    [93814]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
DimaR
Member

Откуда:
Сообщений: 1570
Может и персональная но я знаю довольно крупную фабрику, на которой весь документооборот организован именно на foxpro, протянуто оптоволокно, написан свояь надстройка которая из NT запускает фокспрошные приложения, блокировки и прочая ерунда решаются опять же своими методами (причем сделано все довольно неплохо), куча пользователей
НО КАК ЭТО РАБОТАЕТ!!! надо видеть
19 дек 02, 12:03    [93818]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
2 DimaR

В 1993-94 годах я тоже такой ерундой занимался, пока не почитал об Oracle, Sysbese и т.п., после чего это занятие забросил. То что это работает на конкретной фабрике означает лишь, что им трудно избавиться от предыдущего наследства, как этот пример связан с эскалацией блокировок я так и не понял.
19 дек 02, 12:09    [93825]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
Сорри, немного поспеши, поэтому под Sysbese следует понимать Sybase.
19 дек 02, 12:12    [93828]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>Извините, killed, но по-моему Вы путаете lock resource block c lock owner block. С Вашего позволения, я оперирую в рамках терминологии SQL Server, но смысл, думаю, понятен. Как можно в 24 байта уместить информацию о сотне (как Вы говорите) заблокированных строк? 24 * 8 = 192 бита. Ну пусть по два бита на запись. Один, допустим, выступает флажком, что запись заблокирована. Как в один оставшийся бит уместить бездну информации о lock mode (S, U, X, ...), статусе (грантована, конвертируется, ждет), пойнтер данной записи и многое другое?


Я говорил про блокировку ресурса (строки), что-такое блокировка пользователя в рамках данного треда я не очень понимаю. Блок хранит сотни строк, тогда как в заголовке блока отводится место всего под несколько ITL-слотов. Т.е. вы меня не поняли или я неточно выразился. Зачем отводить место в 64 байта для каждой строки, для миллионов строк таблицы, если в любой момент времени нужно разрешить
конфликт для ограниченного числа транзакций, которые запрашивают разделяемый
ресурс (строку)?

Цитата из книги Oracle8i Internal Services от Стива Адамса (Steve Adams). Это
один из ведущих независимых экспертов по Oracle Internals.

<blockquote>
When a transaction modifies a row, its transaction identifier is recorded in an
entry in the interested transaction list (ITL) in the header of the data block
itself, and the row header is modified to point to that ITL entry. Once these
changes have been made, no lock is retained. The ITL entry for the uncommited
transaction, together with the row header that references it, constitutes an
implicit lock on the row.
When another transaction wants to modify the same row, and sees that an
uncommited transaction has modified that row, that transaction waits, not on a
row-level lock, but on the transaction lock for the blocking transaction.
When the blocking transaction commits or rolls back, its transaction lock will
be released. Its implicit row-level locks are thereby released, and so the
blocked transaction can be proceed
</blockquote>

В хидере строки указатель на ITL-слот + служ. информация занимает 1 байт. Вся остальная информация хранится в памяти в виде массивов фиксированной длины и интенсивно переиспользуется. Реально это несколько десятков мегабайт. Но никак не 64Gb - никакой памяти со свопом не хватит.
19 дек 02, 12:38    [93875]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
>Oracle не знаю, потому трогать его не буду, :-) для MS SQL это не беда, а всего лишь разумный компромисс. За те 3 года моего общения с MS SQL 7, 2000, я вот только здесь узнал, что это оказывается настоящая беда.

У Oracle этих проблем нет, а про уровни изоляции, сериализацию и пр. помнят только люди, имевшие опыт работы с другими системами.
19 дек 02, 12:42    [93880]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
noir
Member

Откуда:
Сообщений: 110
и Interbase с его версионностью. Очевидно под возможностью модификации записей, которые в этот момент кто-то читает, понималась snapshot isolation, т.е. каждая сессия берет себе мгновенный снимок данных на момент начала транзакции и работает с ним обособленно, не мешая другим. Ну т.е. что-то похожее на клиентские курсоры, но разводка делается на уровне сервера. Предположим, каждая сессия что-то поменяла в своем снэпшоте. Как в этом случае происходит сборка данных воедино и как разрешаются конфликты?

Дата: вчера, 13:50

Просто их ИнтерБейс разрешает... Запись в строчку у которой есть версии более новые, чем та, которую "видит" данная транзакция приводит к откату. (Естественно, версии создаются только при записи, а до этого все снапшоты работают с одной и той же версией...) Тут кстати, есть интересная тонкость, связанная с присвоением значений одних строк в другие, но это уже детали.
19 дек 02, 13:18    [93947]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
У Oracle этих проблем нет, а про уровни изоляции, сериализацию и пр. помнят только люди, имевшие опыт работы с другими системами.
Нет этих проблем, значит должны быть другие, за счет которых снимаются эти.
Впрочем подожду лучше ответа Деда Маздая как более компетентного товарища. :-)
19 дек 02, 13:26    [93970]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Zaxx
Guest
2 Genady
>Нет этих проблем, значит должны быть другие, за счет которых снимаются эти.
Эти проблемы в Oracle снимаются не за счёт других проблем, а за счёт механизма roll_back сегментов.
19 дек 02, 17:22    [94313]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
Эти проблемы в Oracle снимаются не за счёт других проблем, а за счёт механизма roll_back сегментов.
А что, эти roll_back сегменты не кушают ресурсы?
Ну что, трудно что ли ответить чуть подробнее, для людей не знакомых с Oracle?
19 дек 02, 17:26    [94322]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Дед Маздай
Member

Откуда:
Сообщений: 655
2noir
"Запись в строчку у которой есть версии более новые, чем та, которую "видит" данная транзакция приводит к откату"
Не понял. Я взял себе снэпшот, работал с ним, работал. Потом говорю - commit. А он в ответ - фиг, потому что там уже кто-то успел сделать более свежую версию. И все, что я в нем наменял, псу под хвост?

2killed
Ага, Вы говорите о том, что в хидере блока (страницы в терминологии MS SQL) Oracle хранит дополнительную информацию о блокированных записях, расположенных внутри данного блока и утверждаете, что ее объем меньше той цифры, которую я привел. Но SQL Server вообще не держит информации о блокировках на страницах данных. Те 64 байта - это чисто in-memory structure. Т.е. то, про что Вы применительно к Oracle говорите "Вся остальная информация хранится в памяти в виде массивов фиксированной длины и интенсивно переиспользуется". Таким образом, Oracle просто разделяет информацию о блокировках и держит ее в двух местах: в памяти и на страницах данных. Я думаю, что это обусловлено чисто историческими причинами. Ведь Oracle появился гораздо раньше, а при тогдашних объемах оперативки другого решения, наверно, не было. Но это очень плохо. Потому что каждая операция блокировки потенциально вызывает дополнительные затраты на disk I/O и получается медленнее, чем в SQL Server. Если же подсчитать суммарный размер информации о блокировке записи - неважно, где она хранится (в памяти, на диске, и там и там), то, вероятно, мы получим примерно схожие цифры что в SQL Server, что в Oracle, что в Sybase, что DB2 и т.д. Вы говорите "У Oracle этих проблем нет, а про уровни изоляции, сериализацию и пр. помнят только люди, имевшие опыт работы с другими системами". Это неверно. Во всех перечисленных серверах в той или иной степени продекларирована поддержка стандарта ANSI SQL. Стало быть, они должны обеспечивать и стандартные уровни изоляции, и все остальное, что прописано в стандарте по этому поводу. А это значит, что с точностью до плюс/минус пары байт размер информации о блокированном ресурсе будет везде примерно одинаков, как бы вы ни хитрили, разбивая ее на куски и упрятывая их в хидер строки, в ITL-слоты, в описание транзакции, в сегменты отмены и т.д.
Кстати, я обратил внимание, что первоначально топик был посвящен Sybase, а сейчас все свелось к обсуждению архитектурных различий MS SQL и Oracle. Как-то неудобно. Может, переместимся в новый топик?
20 дек 02, 11:37    [94646]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Ну во-первых, я не хитрю. Я не работаю на Oracle ;)

2. Цифра в 64Gb - не может получится просто исходя из здравого смысла.

3. Блокировки - это атрибуты транзакций, а не строк. Можно сравнить кол-во транзакций в любой момент времени и кол-во строк в базе. Какая величина меньше - очевидно.

4. <blockquote>...Но это очень плохо. Потому что каждая операция блокировки потенциально вызывает дополнительные затраты на disk I/O и получается медленнее, чем в SQL Server.</blockquote>
Если блок (страница) находится на диске, и вам нужно прочесть строку в этом блоке, то вам по-любому придется прочесть блок в память, а затем уже заблокировать строку. Где здесь дополнительный дисковый ввод/вывод ?

5.<blockquote>Если же подсчитать суммарный размер информации о блокировке записи - неважно, где она хранится (в памяти, на диске, и там и там), то, вероятно, мы получим примерно схожие цифры что в SQL Server, что в Oracle, что в Sybase, что DB2 и т.д</blockquote>
Вот это больше похоже на истину.

6.<blockquote>Вы говорите "У Oracle этих проблем нет, а про уровни изоляции, сериализацию и пр. помнят только люди, имевшие опыт работы с другими системами". Это неверно. Во всех перечисленных серверах в той или иной степени продекларирована поддержка стандарта ANSI SQL. Стало быть, они должны обеспечивать и стандартные уровни изоляции, и все остальное, что прописано в стандарте по этому поводу.</blockquote>
Я не спорю с этим. Я говорил лишь о том, что для тех, кто работает с Oracle, этот вопрос не актуален. Это можно проверить в оракловом форуме.


Если есть интерес, дополнительную информацию можно почерпнуть в Oracle Concepts (возможно попросят зарегистрироваться (бесплатно) ) http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/toc.htm

Мои извинения поклонникам Sybase
20 дек 02, 12:56    [94728]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
Genady
Member

Откуда: Москва
Сообщений: 2005
Я не спорю с этим. Я говорил лишь о том, что для тех, кто работает с Oracle, этот вопрос не актуален.

Вы будете удивлены, но я работаю с MS SQL и тоже не задумываюсь об уровнях изоляции, вернее мне пришлось об этом задуматься за все время один раз.

P.S. Предлагаю следующему, кто захочет попобсуждать различия архитектуры MS SQL и Oracle открыть новый топик, мы здесь уже давно в офтопе.
20 дек 02, 14:09    [94791]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
ppp
Member

Откуда:
Сообщений: 278
Nu uchitivaja chto mehanizm blokirovok v Sybase i MS SQL ochenj pohozij ,
mozno i tut disskusiju prodolzatj , tem bolee chto tema poleznaja.
20 дек 02, 17:10    [94945]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
IBMer
Guest
>Ну во-первых, я не хитрю. Я не работаю на Oracle ;)

>5.<blockquote>Если же подсчитать суммарный размер информации о >блокировке записи - неважно, где она хранится (в памяти, на диске, и там и >там), то, вероятно, мы получим примерно схожие цифры что в SQL Server, что >в Oracle, что в Sybase, что DB2 и т.д</blockquote>
>Вот это больше похоже на истину.

Не думаю.
Хороший документик без рекламной чешуи сравнивающий системы блокировки DB2 и Oracle.

http://www-3.ibm.com/software/data/pubs/papers/locking/locking.pdf

6.<blockquote>Вы говорите "У Oracle этих проблем нет, а про уровни изоляции, сериализацию и пр. помнят только люди, имевшие опыт работы с другими системами". Это неверно. Во всех перечисленных серверах в той или иной степени продекларирована поддержка стандарта ANSI SQL. Стало быть, они должны обеспечивать и стандартные уровни изоляции, и все остальное, что прописано в стандарте по этому поводу.</blockquote>
Я не спорю с этим. Я говорил лишь о том, что для тех, кто работает с Oracle, этот вопрос не актуален. Это можно проверить в оракловом форуме.

Не верю, чудес не бывает. Как на счет ORA-1555 Snapshot Too Old???
24 мар 03, 20:37    [155293]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
eNose
Member

Откуда:
Сообщений: 183063
IBMer:
... Хороший документик без рекламной чешуи сравнивающий системы блокировки DB2 и Oracle.
http://www-3.ibm.com/software/data/pubs/papers/locking/locking.pdf ...


Ну да, конечно! Без рекламной чешуи
Сравнение от IBM. Можно даже не сомневаться, кто у них впереди планеты всей
25 мар 03, 08:05    [155413]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
2 Дед Маздай о блокировках в оракуле.

В оракуле просто нет понятия таблиц или областей блокровок. Информация о блокировках хранится вместе с самими данными внутри блока. Информация о транзакции пишется в itl-списке в заголовке блока, как и сказал killed, а в строке пишется, какая по счету транзакция в этом списке блокирует строку. Тогда на одну 24-байтную конструкцию в заголовке может ссылаться множество строк. Поэтому в оракуле нет эскалации блокировок, как в sybase или ms. Кроме того, такой механизм позволяет выбить блок на диск при нехватке места в кэше, а потом его загрузить обратно с сохранением всей информации о транзакциях/блокировках. Подобный механизм, как мне кажется работает и в db2 (просто в оракл ушли разработчики r-system из ibm).

Уровни изоляции транзакций в оракле есть, но serializable используется крайне редко.

А вообще-то на небольших квази-реалтаймовских базах sybase работает побыстрее оракла, но с большими объемами данных или со сложныи программами, выполняемыми на сервере он справляется хуже. Поэтому часто встречается вариант хранения оперативных данных на sybase и перенос их в "большую" базу на оракле.
25 мар 03, 12:59    [155826]     Ответить | Цитировать Сообщить модератору
 Re: Sybase?!?  [new]
IBMer
Guest
Enoise. Ты документ-то читал????
26 мар 03, 19:09    [157351]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить