|
|
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
И Readpast - это не максимальное приближение к snapshot? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 08:58 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
cherrex_DenИ Readpast - это не максимальное приближение к snapshot? А прошу прощения! Мы обходим эти строки, а не читаем их первоначальное значение! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 09:06 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > Подскажите что такое key range lock? частный упрощённый случай предикативной блокировки. Выглядит как ссылка на индекс таблицы значения полей, обозначающих начало блокируемого диапазона значения полей, обозначающих конец блокируемого диапазона ну и вид блокировки (shared, exclusive etc) Если какая-то запись из таблицы (которой принадлежит индекс), на которую наложен лок, попадает в заданный таким образом диапазон, то эта запись считается заблокированной данным образом. Достоинства: экономия локов - используется один хитрый вместо N простых на каждую запись возможность блокирования даже ещё не существующих физически записей в таблице. относительно низкая (относительно обобщённых предикативных блокировок) стоимость реализации - на проверки записей на заблокированность уходит не так много времени. Недостатки: Немного более сложны, чем обычные блокировки. Ну да что ж делать... Применяются key range locks для замены эксклюзивного блокирования таблицы на уровнях изоляции 2 и 3 (в основном наверное всё же 3, т.е. SERIALIZABLE, потому как key range locks призваны бороться прежде всего с фантомами). Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 15:17 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > И Readpast - это не максимальное приближение к snapshot? Наоборот, максимальное удаление, я бы сказал. Но на самом деле "удаление" или "приближение" - сказать трудно. Readpast для читающей транзакции (для других он не имеет смысла) позволяет транзакции не читать запись, если она заблокирована (или не читать всю страницу, если блокировки страничные). Т.е. для читающей транзакции заблокированная запись как бы эффективно является удалённой. Для snapshot заблокированная запись будет дана читающей транзакции в том варианте, в котором эта запись была на начало транзакции (если записи не было - запись не будет видна). Вот и думайте, что тут ближе, что дальше. На самом деле Readpast - некое ухищрение для read commited, позволяющее читающему запросу не зависнуть в ожидании освобождения данных. Но это его немного "сдвигает" как бы в сторону read uncommited. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 15:23 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
То есть (на сколько я понял) в многопользовательской среде всеравно без блокировки не обойтись! Если бы в Оракле с его версионностью все было так классно и безупречно, то зачем разработчики Оракла сделали "select....forupdate"(подобие эксклюзивной блокировки)? И пусть Snapshot возвращает согласованный набор данных, кому он нужен если после завершения транзакций он измениться. Поэтому особой разницы между snapshot и уровнем 0 я не вижу(безусловно разница есть и не малая, но толку всеравно мало). Огромное спасибо MasterZiv за ответы и терпение ко мне! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 16:08 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
cherrex_Den пишет: > То есть (на сколько я понял) в многопользовательской среде всеравно без > блокировки не обойтись! Конечно. Если бы в Оракле с его версионностью все было > так классно и безупречно, то зачем разработчики Оракла сделали > "select....forupdate"(подобие эксклюзивной блокировки)? И пусть Snapshot во-первых, оракл - не чистый версионник. Во-вторых, кажется даже для чистых версионников при изменении данных двумя транзакциями применяются блокировки записей (хотя тут я возможно не прав, но я вот не знаю, как ещё в этом случае обеспечить сериализуемость транзакций). > возвращает согласованный набор данных, кому он нужен если после > завершения транзакций он измениться. Ну, это - философский подход к проблеме (на мой взгляд - правильный). Поэтому особой разницы между > snapshot и уровнем 0 я не вижу(безусловно разница есть и не малая, но Да только вообще во всём этом мало ... Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 16:49 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
cherrex_Den...И пусть Snapshot возвращает согласованный набор данных, кому он нужен если после завершения транзакций он измениться. ... Это нужно всем. Эдесь ключевое слово "согласованный" (по-времени), который симулирует "мгновенное" выполнение select-a (как и должно быть в идеале), что достигается snapshot isolation (default Oracle, без блокировок, не мешая остальным!) или isol.level 3 (Sybase, c блокировками, deadlockami и постановкой других на уши !). T.e. вы всегда можете co 100% гарантией получив отчет утвержать что на момент времени t1 (starta select (regular snapshot isolation) or finish select (flashback query Oracle)-вот это действиельно философсий вопрос:на начало, на конец, какои-то момент, но "мгновенный" снимок, a не смесь состояий таблицы на разные моменты времени !) он верен. Иначе (read commited , default Sybase ASE) - смесь по вренени в отчете, неверные totals, возможность иметь select result ни в какой момент не представленный в таблице вообще (!), а так как проверить в рамках этого isoл.level это невозможно + меняющиеся price (Wall Street) все спокойно удовлетворены, а subprime моргидж кризис продолжается :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 18:54 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
+ Sybase заставляет вас покупать дорогостоящий IQ где со snapshot isolation все OK. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 18:57 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Zhora wrote: > Иначе (read commited , default Sybase ASE) - смесь по вренени в отчете Если ты делаешь отчёт по непрерывно меняющимся данным - какая разница, что именно он выдаст ;)? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 19:01 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Правильно, для аналитических отчетов(я работаю в сфере перевалки грузов) где фигурируют цифры в миллионы тон, +- 5кг не влияют на "ход крейсера". Можно и нужно использовать snapshot и уровень 0. А когда надо с приемного документа списать точное количество тон, то лучше ждать, чем получить не верный набор данных! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2008, 19:41 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Согласен с MasterZiv. Zhora явно жонглирует проблемой, выставляя одну из полезных технологических особенностей/преимуществ как такую, без которой вообще невозможно работать. Если бы это было так, то не существовало бы вообще никакх серверов, кроме оракла. Но это ведь неправда и бизнес работает на всех существующих серверах. Если отчет надо построить по данным, которые постоянно изменяются, т.е. на сейчас, то без использования соответсвующего уровня изоляции не обойтись. Если отчет не затрагивает изменяющиеся данные, то не вижу никаких проблем использовать более низкий уровень изоляции. Т.е. без наличия снапшота можно жить и работать без особых проблем. Использование снэпшот, кстати, ведет к увеличению нагрузки на IO, что влияет на проозводительность транзакционных систем гораздо фатальнее чем блокировки, поэтому и разделяют физически аналитические системы от транзакционных. У IBM есть хороший мануал, в котором описывается особенности реализации системы продажи билетов на самолет на блокировочнике и оракле. Итог их анализа, что в оракле необходимо использовать Select for update, что не делает его сильно отличным от блокировочника. все наши на www.corba.kubsu.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 14:50 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Ggg_old wrote: > У IBM есть хороший мануал, в котором описывается особенности реализации > системы продажи билетов на самолет на блокировочнике и оракле. Итог их > анализа, что в оракле необходимо использовать Select for update, что не > делает его сильно отличным от блокировочника. Можете ссылку дать ? Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 18:32 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Ggg_oldСогласен с MasterZiv. Zhora явно жонглирует проблемой, выставляя одну из полезных технологических особенностей/преимуществ как такую, без которой вообще невозможно работать. Если бы это было так, то не существовало бы вообще никакх серверов, кроме оракла. Но это ведь неправда и бизнес работает на всех существующих серверах. Если отчет надо построить по данным, которые постоянно изменяются, т.е. на сейчас, то без использования соответсвующего уровня изоляции не обойтись. Если отчет не затрагивает изменяющиеся данные, то не вижу никаких проблем использовать более низкий уровень изоляции. Т.е. без наличия снапшота можно жить и работать без особых проблем. Использование снэпшот, кстати, ведет к увеличению нагрузки на IO, что влияет на проозводительность транзакционных систем гораздо фатальнее чем блокировки, поэтому и разделяют физически аналитические системы от транзакционных. У IBM есть хороший мануал, в котором описывается особенности реализации системы продажи билетов на самолет на блокировочнике и оракле. Итог их анализа, что в оракле необходимо использовать Select for update, что не делает его сильно отличным от блокировочника. где ж вы были когда ASCRUS решал нам задачку на блокировочнике и скис ? имхо красиво иллюстрирующий пример какое существенное преимущество дает MVCC. все ведущие разработчики субд уже если не внедрили Snapshot, то уже выпустили какие-то промежуточные хреновины (типа scip locked в db2, last commited informix) для обеспечения неблокируемого чтения и оптимистичной блокировки ... ЗЫ. и/о с легкостью компесируется простоем на блокировках и затрат на менеджмент гигантского кол-ва никому не нужных блокировок на чтение. эволюция тестов Microsoft в TPC-E это красиво демонстрирует ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 19:00 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Прочитал текст аскруса. Сам тред не читал, поэтому буду говорить только за его пост. Первый параграф с табличкой движения по счетам - согласен. Потом он правда для решения задачи получения баланса начал описывать какую-то схему, я не очень понял зачем так сложно. На прошлом месте моей работы, в банковской субд, была табличка с остатками на счетах. Она хранила остатки на начала банковского дня (для каждого дня дата, счет, входящий остаток). Для получения текущего остатка в текущем дне на счете надо было (упрощенно) к остатку входящему на текущий день прибавить кредитовые проводки и вычесть дебетовые из таблицы движений. С такой схемой можно было получить текущий остаток на счете. В зависмости от требований к актуальности остатку, используем разные степени изоляции. Вечером при закрытии дня таблица остатков окончательно пересчитывалась, определялись конечные остатки и на следующий день все повторялось снова. Я не против снэпшот, вещь крайне полезная особенно для всяких статистических запросов. Мне просто не нравится, что значимость снэпшота возводят в абсолют без которого невозможно написать что-либо вообще, что есть не правда. В аса10 снэпшот появился, можно только приветсвовать появление еще одного инструмента. Но лично мне в нем пока нужды нет, задачи не те. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 20:08 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
snapshot это только разновидность получения "грязных данных", согласованных но "грязных". Это только фича которая принципиально не влияет на фундаментальные основы релиационных СУБД. И я согласен с MasterZiv и Ggg_old что snapshot это не панацея и молиться на это ненадо! p.s. и правильно сказал ASCRUS что по мимо использования возможностей СУБД надо еще и думать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 20:21 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Кстати, аскруса давненько не было видно на этом форуме.... все наши на www.corba.kubsu.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.07.2008, 21:11 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
MasterZiv Ggg_old wrote: > У IBM есть хороший мануал, в котором описывается особенности реализации > системы продажи билетов на самолет на блокировочнике и оракле. Итог их > анализа, что в оракле необходимо использовать Select for update, что не > делает его сильно отличным от блокировочника. Можете ссылку дать ? Posted via ActualForum NNTP Server 1.4 ftp://ftp.software.ibm.com/software/data/pubs/papers/readconsistency.pdf Я помнится читал эту статью еще давно, так - отписка. Вот итересно почитать мыслишки почему ИБМ не реализует MVCC (~ snapshot isolation) никак. http://bytes.com/forum/thread635122.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 01:11 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
2Ggg_old так сложно потому, что даже при паре сотен tps к концу дня на вычисление баланса будут уходить гигантские ресурсы, а на изначальную задачу "подсчитать суммарный баланс чековых и сберегательных счетов по большой группе клиентов" придется перелопачивать гигабайты данных ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 12:29 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
ну, не знаю.. глубоко въезжать в проблему задачи в том треде лень. У нас баланс высчитывался на основе проводок за день, поэтому все работало нормально. А если, как писал аскрус для получения остатка надо считать все проводки за месяц или год, то тут никаких ресурсов не хватит, столько данных с диска поднимать. И локи будут далеко не на первом месте. все наши на www.corba.kubsu.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 15:03 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
cherrex_Den wrote: > snapshot это только разновидность получения "грязных данных", > согласованных но "грязных". Нет, тут вы не правы кардинально. Данные там чистые. > Это только фича которая принципиально не > влияет на фундаментальные основы релиационных СУБД. И я согласен с > MasterZiv и Ggg_old что snapshot это не панацея и молиться на это ненадо! Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 16:03 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Yo.!так сложно потому, что даже при паре сотен tps к концу дня на вычисление баланса будут уходить гигантские ресурсы, а на изначальную задачу "подсчитать суммарный баланс чековых и сберегательных счетов по большой группе клиентов" придется перелопачивать гигабайты данных ... Yo.! , ASCRUS вроде бы там написал, что не сталкивался с банковскими технологиями. А в банке существует такое понятие как "Закрытие дня". По закрытию дня никакие проводки больше не делаются и ничто не мешает просчитать остатки по счетам за день и занести их в отдельную таблицу "Остатки". Естественно, в этом случае вообще глубоко фиолетово, какая СУБД используется блокировочник или версионник, т.к. сам бизнес-процесс обеспечивает валидность данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 16:29 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
2Ggg_old вероятно у вас были такие объемы какие позволяли для каждого вычисления баланса поднимать все транзакции счета за день, я не спорю, понятно, что это будет работать. я о том что версионность имеет существенное преимущество как в плане простоты кода (в примере тупо обновляться баланс) так и в плане производительности (и/о и CPU под UNDO на порядок будет меньше чем на каждый чих поднимать все транзакции счета за день). 2Vitafresh я тоже достаточно далек от банковских систем и не совсем понял, что значит "проводки больше не делаются". не может же банк запретить операции со счетом пока что-то "закрывает" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 17:21 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Yo.!2Vitafresh я тоже достаточно далек от банковских систем и не совсем понял, что значит "проводки больше не делаются". не может же банк запретить операции со счетом пока что-то "закрывает" ? Это значит, что данные по текущему операционному дню меняться уже не могут и в "закрытый" день никакая проводка больше не попадет. В соответствии с регламентом такая проводка (т.е. операция со счетом) будет иметь дату следующего операционного дня. Соответственно с текущим "закрытым" днем можно безбоязненно проводить любые расчеты, переносы в архив, вычисление остатков и что душе угодно, без опаски что данные могут измениться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 17:46 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
2Yo: Ну если подсчет текущего остатка на счете нужен для совершения следующей операции со счетом, то здесь снэпшот не поможет, т.к. все остальные операции должны встать в стойло. Проводок по конкретному счету за день не сказть что очень много, так что все транзакции отрабатывали быстро. При наличии таймстампа у документа можно даже читать данные из проводок даже в грязном чтении, т.к. проводка будучи введенная уже почти не изменяется. Отмена или коррекция проводки организуется через сторно-проводку, т.е. новый документ в базе. все наши на www.corba.kubsu.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 19:33 |
|
||
|
Применим прицип Oracle к ASE
|
|||
|---|---|---|---|
|
#18+
Zhora wrote: > Я помнится читал эту статью еще давно, так - отписка. > Вот итересно почитать мыслишки почему ИБМ не реализует MVCC (~ snapshot > isolation) никак. Да потому что на фиг это не надо в большинстве приложений. Т.е. как: Есть - можно использовать. Нет - можно обойтись. А перформанс у блокировочников лучше объективно, если конечно отбросить те транзакции, для которых специально делался snapshot. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.08.2008, 19:54 |
|
||
|
|
start [/forum/topic.php?fid=55&msg=35465294&tid=2011453]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
148ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 220ms |
| total: | 473ms |
| 0 / 0 |
