|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
по-моему все кто занимался Ораклом просто-напросто с детству запуганы Томом Кайтом и грязным чтением...(( Я вообще не понимаю каков смысл получать long-running report по данным, которые в настоящий момент меняются? Ведь если запустить такой отчет сразу же после первого выполнения - вся картина все равно поменяется. А в основном все длинные отчеты получаются из уже закомиченных данных. А в этом случае - что грязное чтение, что serialazible - один и тот же результат будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 08:52 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Nothing to say. I may repeat only I could not get a deadlock in my example. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 08:55 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
gardenmanпо-моему все кто занимался Ораклом просто-напросто с детству запуганы Томом Кайтом и грязным чтением...(( Я вообще не понимаю каков смысл получать long-running report по данным, которые в настоящий момент меняются? Ведь если запустить такой отчет сразу же после первого выполнения - вся картина все равно поменяется. Ну вообще-то нет. Или - смотря что называть "картиной". Если "картина"="результат запроса", то на serialazible она не должна поменяться (в той же транзакции). Правда, не знаю, сколько в этом пользы. А в основном все длинные отчеты получаются из уже закомиченных данных. А в этом случае - что грязное чтение, что serialazible - один и тот же результат будет. Да, у нас тоже так. А можно вообще (постулировать|разработывать модели, требующие), что данные нельзя UPDATE/DELETE, а можно только INSERT, и строить отчеты на записях с TIMESTAMP'ом не выше некоего заданного (скажем, на начало построения отчета). ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 09:53 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
gardenmanпо-моему все кто занимался Ораклом просто-напросто с детству запуганы Томом Кайтом и грязным чтением... Уважаемый, пожалуйста, посоветуйте какую-нибудь литературу, чтобы "не бояться" грязного чтения! Буду Вам при много благодарен! ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 12:38 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Ну, вот в паре наших баз сперва добавляются данные, затем строятся отчеты (добавляются за январь, считаются за декабрь). Потому уровень изоляции можно ставить какой угодно. В append only базе вместо январь/декабрь может быть сейчас/минутуназад - принцип тот же. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.01.2005, 22:03 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Viktor: not always possible to have a database add-only. We have a VoIP billing system where the info about each call depends from the several packet from several VoIP gateways. Each packet from gateways kept in one table, and the info about calls calculated on the fly and inserted/updated in another table with each coming packet (through MQ queue). But there are two things: 1) the table with packets from the gateway is add-only and it's absolutely safe to use UR to it because if a packet is in the queue it will be inserted. 2) For hourly/daily/weekly/monthly reports based on calls table we are not interesting in last second/minute/hour/day Actualy we could reach a huge throughput without deadlocks having a lot of insert/update/select after we got a business logic and made a proper design. It might be the answer to kdima71 - your business logic only may help you to understand when/where you may use UR. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2005, 08:44 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
А не сталкивался ли кто со следующей проблемой с грязным чтением: есть активно (порядка сотен транзакций в минуту) пополняемая табличка (appendOnly). На ней есть несколько индексов типа номер счета + что-то еще, то есть активно модифицируемые по всему объему. Если запрос из приложения имеет план исполнения, использующий 2 индекса для отбора данных, то он с заметной вероятностью (до 30-50%) падает с ошибкой Invalid cursor state. Поборолось это шаманскими плясками так, чтобы план исполнения использовал только один индекс. Интересно 1) можно ли с этим бороться более регулярными методами? (Перевести репортинг с UR невозможно) 2)вообще, у кого был опыт с подобным безобразием? Db2 8.1.6, Windows 2003 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2005, 18:19 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
that sounds strange. I had a system with much more than 100 transactions per second, and a table with SELECT/INSERT/UPDATE, and more then 2 indexes, and different queries with accesing several indexes. Never got invalid cursor state. db2 v 8.1.4 Looks like a bug if it is truth. Or something other goes wrong. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.01.2005, 22:07 |
|
UNION ALL: правило старшинства или порядок выполнения
|
|||
---|---|---|---|
#18+
Lana Zapornikova...(Перевести репортинг с UR невозможно) Здравствуйте Lana! Меня заинтересовала Ваша проблема! 1. Мне интересно знать, только при уровне изоляции UR происходит эта ошибка? 2. Могли бы Вы объяснить причину, невозможности использования в вашей системе отчетов другого уровне изоляции, отличного от UR? 3. Могли бы Вы привести более подробный отчет о вашей проблеме и способы, которые вы использовали для её решения? Заранее благодарю за ответы! С уважением kdima71. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.01.2005, 12:03 |
|
|
start [/forum/topic.php?fid=43&msg=32862170&tid=1606029]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
others: | 288ms |
total: | 406ms |
0 / 0 |