|
|
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
to cdk: Можно создать параллельный способ расчёта, если выяснится что он выполняется в 200 раз быстрее, можно будет смело настаивать на получении премии за рацпредложение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 16:25:31 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2cdk: интересно с чьим билингом ты работаешь:) amdocs, cboss или петерсервис:)? нахождение сумарного телефонного трафика по звонковым таблицам дурацкая мысль, если там десятки миллионов записей то даже если у тебя ora01555 не появится, времени на это уйдет довольно дофига ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 17:08:08 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
to Simon: Даже если сделать промежуточные таблицы, которые содержат суммы по нужным группам и периодически производить расчёт только по новым данным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 17:14:29 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Absolutely agree with softbuilder. This is screaming for a materialized view. SY. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 17:19:14 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
там уже должны быть еще какие-нибудь уровни агрегации информации (т.е я бы на месте cdk обратился бы в техподдержку компании разработчика) при закрытии счета никто как правило не лазит по звонковым таблицам, это ресурсоемко (для миллиона абонентов надо перелопатить несколько 10-ков миллионов записей) для любого сервака это смерть на звонковых таблицах индексы даже не делают (делают только для партиционирования), с индексами инсерты туда проходят гораздо медленней и они места на диске много занимают ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 17:45:11 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Да даже без партиций и материализованных вью можно по уму спроектировать систему. Разделить информацию на оперативную и историческую. Создать отдельно таблицы для только для суточной информации, каждый час скажем расчитывать, переносить её из суточной INSERT /*+APPEND */ .... в месячную итд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 17:59:05 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 Simon ни тот, ни другой, ни третий... поддержка есть, они и предложили либо увеличить сегменты, либо отключить их на время 2 sotbuilder таблицы ессно партиционные, индексы тоже есть на них, глобальные причем. насчет снапшотов... биллинг оффлайновый, иногда приходится (причем в кратчайшие сроки) заново пересчитывать значительные объемы за прошлые периоды ладно, вероятно всего пока ограничусь увеличением малых сегментов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 18:08:45 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 softbuilder: примерно так народ и делает звонковая информация в биллинге нужна только для того чтобы распечатать детализацию звонков клиента, для всех остальных целей она больше не нужна и именно поэтому обращаться к ней дурацкая идея ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2003, 23:07:57 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Я плакалъ 2 Simon >а мне кажется что никаких проблем не будет >если на диске много места >и админ правильно настроит ролбэк сегменты Причем тут сериализуемые транзакции и RBS, если эта самая транзакция работает 15 часов и транзакционная активность высока, проблема в том, чтобы обеспечить ее выполнение и не получить ORA-08177: Can't serialize access for this transaction... Это уже дизайн (и не тривиальный), а человек спрашивает как ему от 01555 избавиться. Не поленюсь скопировать с 1 страницы: ... 2. Выполнить следуюющее: - создать сегменты отката (или изменить существующие) так, чтобы они могли достаточно авторасширяться (это вроде уже имеем); - заблокировать каждый сегмент отката короткой транзакцией: set transaction use rollback segment ... (столько сеансов сколько RBS); - запустить скрипт. ... P.S. (самому ломы писать) Oracle Isolation Levels Oracle provides three transaction isolation levels: read committed This is the default transaction isolation level. Each query executed by a transaction sees only data that was committed before the query (not the transaction) began. An Oracle query will never read dirty (uncommitted) data. Because Oracle does not prevent other transactions from modifying the data read by a query, that data may be changed by other transactions between two executions of the query. Thus, a transaction that executes a given query twice may experience both nonrepeatable read and phantoms. serializable transactions Serializable transactions see only those changes that were committed at the time the transaction began, plus those changes made by the transaction itself through INSERT, UPDATE, and DELETE statements. Serializable transactions do not experience nonrepeatable reads or phantoms. read-only Read-only transactions see only those changes that were committed at the time the transaction began and do not allow INSERT, UPDATE, and DELETE statements. Setting the Isolation Level Application designers, application developers, and database administrators can choose appropriate isolation levels for different transactions, depending on the application and workload. You can set the isolation level of a transaction by using one of these commands at the beginning of a transaction: SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET TRANSACTION ISOLATION LEVEL READ ONLY; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 06:39:02 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
Pregde vsego, moi soboleznovaniya tem, kto ispol'zuet AMDOCS... "..при закрытии счета никто как правило не лазит по звонковым таблицам,.." Eshe kak lazyat! "нахождение сумарного телефонного трафика по звонковым таблицам дурацкая мысль, если там десятки миллионов записей то даже если у тебя ora01555 не появится, времени на это уйдет довольно дофига..." S etim mogno mnogo sporit'... Stoit zelogo topika! V lubom sluchae, eto problema tol'ko logocheskaya.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 09:26:04 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2Angel Выполнить следуюющее: - создать сегменты отката (или изменить существующие) так, чтобы они могли достаточно авторасширяться (это вроде уже имеем); - заблокировать каждый сегмент отката короткой транзакцией: set transaction use rollback segment ... (столько сеансов сколько RBS); - запустить скрипт. авторасширение для ролбэк сегментов не работает при выполнении селектов лучше всего чтобы все ролбэк сегменты были одинакового размера и их было много с сериализацией я согласен-от нее пользы не будет, надо всегда использовать тот уровень изоляции который нужен по логике 2Oracle X-pert AMDOCS лучший биллинг в мире, там есть свои глюки (я ни там ни в вымпелкоме не работаю и никогда не работал, но то что он лучший это факт) если Вы связанны с биллингом и ваша система лазит по звонковым таблицам для того чтобы при пакетной генерации закрыть счет, то большинство систем конкурентов будут быстрей, так как они этого не делают (если только не надо показать детализацию звонков) p.s. мне кажется тема разрослать и пользы от нее никакой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 10:06:46 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
to Angel Странно, а у меня вот так не работает Код: plaintext 1. 2. 3. 4. а только вот так Код: plaintext 1. 2. Может это только для девятки? И еще вот такая штука Код: plaintext 1. 2. 3. 4. Что для sys нельзя работать в режиме serializable? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 10:11:01 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 Simon ( Gal', chto your mail not be reached) Tvoe soobshenie "AMDOCS лучший биллинг в мире" menya radyet! No v tom-to i delo, chto ya byl Rykovoditelem proektnoi gryppu etoi-to sistemy... Spasibo za kompliment i gelay yspexov! ( A vse-taki, v AMDOCS - ne samaya optimal'naya sistema..) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 10:48:24 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2Simon >авторасширение для ролбэк сегментов не работает при выполнении селектов >лучше всего чтобы все ролбэк сегменты были одинакового размера и их было много :) Спасибо, что объяснил. Непонятно только зачем... На счет второго высказывания, нельзя ли поточнее: какого размера и сколько (ну сколько это даже и не важно для конкретной темы) - поделись опытом 2Violina Я не верю, что у тебя нет доки :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 10:48:51 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
to Angel Дока есть. Про уровни изоляции я читала, но про illegal SERIALIZABLE clause specified for user INTERNAL ничего не говорилось. Вы привели пример SET TRANSACTION ISOLATION LEVEL READ COMMITTED; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET TRANSACTION ISOLATION LEVEL READ ONLY; последний у меня не работает, вчера с этим столкнулась. Вот и хотелось узнать SET TRANSACTION ISOLATION LEVEL READ ONLY в принципе не верная команда или просто в 9 вместо нее надо использовать set transaction read only; ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 10:58:16 |
|
||
|
ora01555 - SNAPSHOT TOO OLD
|
|||
|---|---|---|---|
|
#18+
2 Violina Пример для 8i Из доки по 9i: ORA-08178 illegal SERIALIZABLE clause specified for user INTERNAL Cause: Serializable mode is not supported for user INTERNAL. Action: Reconnect as another user and retry the SET TRANSACTION command. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.06.2003, 11:13:17 |
|
||
|
|

start [/forum/topic.php?fid=52&gotonew=1&tid=1989952]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
183ms |
get topic data: |
9ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 490ms |

| 0 / 0 |
